Andrew Sullivan wrote:
On Thu, Mar 11, 2010 at 11:37:55PM -0500, Donald Eastlake wrote:
PDF/A is a deliberately-limited format designed specifically for
archival purposes.
And is clearly a non-starter because I have no idea how to produce PDF
so limited, not idea how to test a PDF to see if its "PDF/A", etc. On
the other hand, since I produced my first ID sometime in 1992, I've
had no particular problem producing them with nroff and I've never had
to hunt for, write, debug, or install a single piece of software. It's
just there already, including in Mac OS X.
Wait a minute. That argument just boils down to, "I don't know how to
do this, so it's obviously wrong."
First, that you don't know how to do something is by no means evidence
that it can't be done, and done easily.
What it means, is that it is neither easy, nor intuitive, and will
require new tools that have to be built and are therefore only going
to be for a small number of new platforms, but not for a huge part
of the installed base.
Second, I'm sure it won't come as a complete surprise that many people
find nroff to be cryptic, arcane, hard to use, and designed for an era
when the primary publication mechanism was ink on paper using output
mechanisms with limited capabilities.
The use of the nroff authoring format doesn't mean that you have
to do everything yourself manually, as with xml2rfc.
Just try NRoffEdit once. It's simple and intuitive, and it
will convert an existing ascii-formatted I-D back into
nroff-authoring with ease. I was amazed just how simple and
powerful this tool is when I wrote my first I-D.
With xml2rfc, I gave up on trying to install an hour after
downloading it. With NRoffEdit, I was writing page 3 an hour
after downloading it.
Third -- and this is a point since made in this thread by others more
clearly than I originally made it -- the IETF format _is not_ plain
ASCII. It's a page layout format that happens to restrict itself also
to ASCII characters only. So there are completely separate issues to
address here, and we shouldn't conflate them.
The format is plain ASCII, in that all formatting is done with
only two(three) ASCII control characters. End-Of-Line is represented
by CR+LF, Pagebreaks by an VF (Vertical Feed, Form Feed) character.
and all other positioning with ASCII space characters.
There is the archival format issue. In my view, if we really want to
have a format for archival purposes, then something other than files
made for printing on a printer (with paper not even widely available
in parts of the world) would be an improvement. PDF/A is one
candidate format, standardized by another SDO and apparently embraced
by a community (librarians) that really know about long-term archives
and who already have extensive experience with the pain of supporting
old computer formats.
A number of the other SDOs are in the publishing business. They
charge you for every copy of the document and you're not allowed
redistribute or to create derivative works at your leisure from
their publications. And for their working documents,
the circulation/distribution may even be limited, occasionally
by some kind of NDA.
This is a significant difference to IETF documents, RFCs and I-Ds,
where the purpuse is explicitly that they're distributed, discussed,
improved, parts re-used, and derivative works created.
PDF and PDF/A may be OK for "publish and forget" documents,
but I think they're not useful for IETF documents because
of the severe limitations to anything beyond "pretty publication".
Moreover, from a process point of view, I've had at least one
contributor in DNSEXT recently refuse to update a draft because the
idnits tool checks for both form and content. This makes the exact
formatting conventions of the page into a problem that contributors
have to worry about when trying to hammer out technical details of a
protocol. Every contributor has to be an amateur typesetter, only
still targetting a technology that was a significant step backwards in
typeset quality compared to things professional typesetters had been
doing for centuries.
If we were using a more feature rich document format, the constraints
that the submission tool would have to enforce would make this
one-time software logistics lapse a recurring experience for
each and every I-D author and every submission.
If you have troubles with idnits, you should really try NRoffEdit.
There were a number of things that I bothered with when writing
my first I-D last November. Getting started, formatting the
document and passing idnits were complete non-issues with NRoffEdit.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf