--On Sunday, 08 January, 2006 14:42 +0200 Yaakov Stein
<yaakov_s(_at_)rad(_dot_)com> wrote:
While I personally like PDF for many things, I find PDF to be
a poor
choice for IETF works-in-progress,
or even for RFCs because they lack many of the
characteristics that
ASCII files offer.
Don't you mean that ASCII lacks many of the features PDF offers
(font faces, font styles, diagrams, etc. etc. etc.) ?
The characteristic you apparently want, i.e. being easy to
plug into SW that accepts only ASCII characters, is recovered
by "text selection" in the PDF viewer.
Yaakov, while I think most of this thread has continued past
usefulness without a new, and narrower, proposal, because I
remain interested in the potential of PDF for some purposes...
I think this helps make it clear that any "use PDF" proposal,
especially for I-Ds, needs to be very specific about a PDF
profile and required feature set. It is possible to create
perfectly good PDF files from which "text selection" won't work
at all. It is possible to create PDF files that imbed font
faces and styles from which text copying and pasting won't work
in many operating systems even if "text selection" is available.
Extracting a diagram from a PDF file so that _it_ can be edited
is rarely an obvious operation. And so on.
Unless those things are available, PDF may be fine for
representing a finished document where the only requirement is
accurate rendering, but it is fairly terrible for working
documents, which I think is what David was trying to suggest.
Even with them, it may be worse than importing ASCII into the
editor of your choice, even if that editor is MS Word.
One way to look at this is that one of the advantages of ASCII
is that it is sufficiently feature-poor as to not require any
(or much -- we still have the line-end problem) versioning or
profiling. From that point of view, part of the problem with
either PDF or Word is that they are feature-rich and growing
(new versions are being produced with additional capabilities).
So, to use them effectively in a contract in which material must
be selected and worked on, one has to get into the business of
specifying particular versions, features and must or must not be
used, and so on. While XML formats can get quite complex, one
of the advantages of that particular model is that it is
extremely easy to test for whether any prohibited features have
been used. My guess it that, for these complex and
feature-rich systems, we will find it even harder to reach
agreement on those profiling issues than on whether to permit
these formats.
As an example, assuming you would still like to see MS Word
accepted as a submission and display format, suppose we agreed
on Word 95's features and file formats. There might actually be
some reasons for doing so, starting from the observation that
Word<-> RTF conversions were much less likely to lose
information than might be the case for Word 2003. But I can't
go to the store and buy a copy of Word 95, no one is supporting
it, and so on. Conversely, while I think Word 2003 claims to be
able to write out Word 95-compatible files, we have no
guarantees that capability will exist in Word 2006 or Word 2008
(?): your own observation about Microsoft's incentives about new
versions would suggest that the backward support will be dropped
at some stage. Worse, it is not easy to tell a Word 2003 file
from a Word 97 one, at least without some serious
reverse-engineering, so it is fair to predict that we would see
leakage and other side effects, some with significant ill
effects.
So, while applauding your current I-D as a useful first step (I
_really_ dislike having these discussions in the absence of a
draft), if you want to propose PDF, I think it is time that you
(or others) produce a starting-point draft that specifies or
discusses at least:
* What the PDF is to be used for (several people, not
just myself, have pointed out that the rules might
plausibly be different for I-Ds and RFCs)
* What version of the file format is to be used.
* Consistent with that version, what features are
required to be supported in the PDF file
* Consistent with that version, what features are
prohibited in the PDF file.
* What is to be required about font-embedding and
whether any restrictions on fonts and styles or the size
and definition of image are needed.
* Probably answers to some other questions I don't know
enough to ask
* How, or if, it is possible to design and build good,
multiplatform, tools to test for whether or not those
requirements have been met.
I think it would also be helpful if the draft would identify a
selection of tools, for a variety of platforms, that could be
used to create the relevant documents and, ideally, enforce
whatever requirements are specified. If that list implies a
requirement for any tools that require high-powered machines,
large amounts of disk space or memory, particular versions of
particular operating systems, and/or expensive per-machine
licenses, then we need to know, and consider, that as well.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf