Re: draft-rfc-image-files-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Saturday, 23 August, 2008 19:37 +0200 Frank Ellermann
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz@xxxxxxxxx> wrote:

>...
> Creating PDF/A is the key for "open and fair".  At one
> point John even wrote "author or editor" where I think
> he meant "author or reader".  But this also stresses
> my point:  Can everybody *create* PDF/A ?  With free
> tools on any platform they care about, maybe limited
> to "modern" non-mobile platforms of this millennium ?

Actually, you don't care because there should be no requirement
that the image file come to the RFC Editor in PDF/A and the
document deliberately does not impose that requirement (it
doesn't even require PDF/A output, just recommends it as an
example).

What goes to the RFC Editor is

	(i) A text file and maybe xml or nroff that the RFC
	Editor is willing to edit/process.
	
	(ii) An image file in some format the RFC Editor is
	willing to deal with.  Certainly standard PDF would be
	an appropriate input format, but there could be
	others... and there is no strong requirement for PDF/A.
	Note that, as the spec is now written, the only free
	text in that image file is figure titles, captions, and
	numbers and that it is certainly within the "style
	manual" discretion of the RFC Editor to make
	requirements about the fonts to be used (excluding,
	e.g., 22ndCenturyPostModernObscura).

The RFC Editor takes (i) and processes it more or less as they
do today.  They take (ii), merge in header and footer blocks,
and produce an output file.  That output file is expected (more
or less, see above) to be in PDF/A.  

But that means that one needs exactly one copy of one tool that
can read in PDF (or another approved image file format), overlay
header and footer blocks, and produce PDF/A.   The rest of us do
not need to create that format at all, so how available the
tools are isn't a major concern.

And, yes, I believe that you are correct that Acroread 3 cannot
read PDF/A files, or anything else with embedded fonts.  Neither
can "cat" do a reasonable job of mapping such files to standard
output and having something useful show up on the screen.  I
don't know if I want to go as far as to say "so what?", but,
unless we can move forward enough to accommodate this fairly
minor --but, IMO, powerful) extension, then there is no way
forward. Please also remember that, in sufficiently unusual
circumstances, it is possible to publish an RFC in Postscript
(with its significant interoperability problems) or PDF with no
ASCII base form at all.  So, if you can't read PDF (or
Postscript), those RFCs are inaccessible to you in their
entirety today.   Not much new here.

     john

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]