--On Friday, June 16, 2006 12:34 -0700 Carl Malamud
<carl@xxxxxxxxx> wrote:
I could not agree with John more on the desirablilty of a
tighter definition of PDF and the reasonableness of "plates
in the back".
The problem with tightly defining which piece of PDF you will
support is that most clients don't give the user choice on
what they do. A user gets a "export to PDF" button, but they
don't get a "export to PDF/A and make sure all fonts are
self-contained and don't include embedded video."
I understand that. But it leaves us in an odd state. On the
one hand, some of us have experience with PDF files created in
some applications not opening in others and, in particular, not
opening in the presumably-normative Adobe Reader. Then we have
RFC 3778 and PDF/A, which more or less specify profiles for PDF
(although whether or not those profiles are appropriate for our
purpose here is a separate question).
To the extent to which a user is not able to specify those, or
other, profiles, or options that would cause them to be created,
the argument that PDF is widely supported by multiple vendors
breaks down in practice and, with it, the argument that PDF is
really ready for prime time and/or applications that require
stability over very long timelines.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf