Rick and all,
Here are some comments that Martin Bailey offered in the spirit of
constructive and positive criticism when I brought the PDF/is Ver. 0.4 spec
to his attention. Martin is the chair of the CGATS and ISO PDF/X task
forces.
Rob
____________________________
* PDF/X-3:2002 is based on PDF 1.3, not PDF 1.4. That means that masked
images and JBIG2 compression would make the file non-conforming with
PDF/X-3. Given that issue I think it unwise for this specification to
require that
GTS_PDFXVersion be set to (PDF/X-3:2002) in table 3-28. It would be better
to recommend that the key be present and set if the creator knows that the
file is compliant.
A revision to PDF/X-3 is in DIS ballot at the moment, which will probably
be approved in May next year as PDF/X-3:2003, and published Q3 next year.
The new revision is based on PDF 1.4, and may be a more appropriate
reference
from PDF/is.
A) Table 3-5 prohibits the "graphics state". That's simply not possible -
there is *always* a graphics state when interpreting a PDF page, even if
it's just one big image and that graphics state is the default. Did you
mean to capture the prohibition of ExtGState objects ([pdf] 4.3.4, and
PDF/is tables 3-20 & 3-21) and graphics state operators ([pdf] 4.3.3 and
PDF/is table 3-20)?
B) Section 3.3.1 - I think somebody has misunderstood Appendix E of [pdf].
The 'PDF Name Registry' is a database held by Adobe at their offices, it
does not form a part of a PDF file at all. From the rest of the document it
appears that it should be a sort of "free-floating" object at the beginning
of the file and not referenced from any other object. Is that correct? If
so, is there a requirement that it be generation 0 of object 1 (PDF does
not require that objects be recorded within the file in numerical order)?
An object with no set number and generation, and not accessible by tracing
a path of object references from the trailer, may be extremely difficult
for some tools to access.
C) Table 3-9. This table does not provide a mechanism for a reader to
support, for instance <IDX>-<RGB> without also supporting <IDX>-<LAB> and
<IDX>-<ICC> when <LAB> or <ICC> is also used. In terms of defining sensible
profiles that's probably appropriate, but it contradicts section 3.1.3.
D) I'm intrigued that the DeviceGray color space is prohibited in a file
designed to be printed on a monochrome device. The use of CalGray implies
transformation to an XYZ color space ([pdf] fig 4.15), and then into the
device's output space. A monochrome device simply cannot accurately
represent the additional data provided by a CalGray space over DeviceGray.
Of course, that implies that a file using DeviceGray should only be made
for output on a monochrome device, but there are many other requirements in
the specification that imply that the file is a single-use object and
should be generated for a specific output device.
E) Table 3-26 states that the reader should ignore the F flag in an
annotation field dictionary. I'm left unclear as to what the <DIG-SIG>
profile is intended to accomplish because the signature may or may not be
printed on the media at the discretion of the reader. The basic premise of
a streaming format means that the reader cannot decide not to print the
document if a digital signature is invalid - so what is the reader supposed
to do with it?
F) Section 3.4.1 - what value should be used for the /Fis-Cache key?
G) Section 3.4.2 - should the cache be released before or after rendering
the page on which the Fis_Cache key is present?
H) 4.2. Point 4 implies a communications mechanism, which is not described
in this specification. Would it be better handled in the IPPFax
specification rather than here?