My comments, below...
> -----Original Message-----
> From: owner-ifx@pwg.org [mailto:owner-ifx@pwg.org] On Behalf
> Of Buckley, Robert R
> Sent: Friday, December 20, 2002 7:42 AM
> To: 'ifx@pwg.org'
> Cc: 'martin.bailey@globalgraphics.com'
> Subject: IFX> More comments on PDF/is
>
>
> 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.
I had been considering removing PDF/X-3. It will be removed from version
0.6.
>
> 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)?
That entry should have said "Graphics State Parameter Dictionaries"
(ExtGState). I fixed the document.
>
> 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.
Good point. I've added a reference to this object in the document trailer.
>
> 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.
The color profile 'tree' was removed in version 0.5 of the spec, so this
issue no longer applies.
>
> 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.
This again was already changed in Version 0.5 of the spec. CalGray and
CalRGB were replaced with DeviceGray and DeviceRGB.
>
> 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?
Yes, it is at the discretion of the reader. Since the format does not
contain an annotation for the D-Sig (something to display) there was no need
to specify whether or not it should be displayed. The Dsig handling is up
to the consumer. If they wish to verify the Dsig and display some message
as to the Dsig's validity, they are free to do so. The form that the
display of the Dsig actually takes on is up to the consuming device.
Putting a full Annotation (image and text) of a Dsig into the format would
make the implementation of Dsigs too heavy-weight, in my opinion. As an
example of how it would work, if you open a Signed, PDF/is conforming
document in Acrobat, you can view and verify the Dsig information under the
"Signatures" tab, but it does not display on the document itself.
>
> F) Section 3.4.1 - what value should be used for the /Fis-Cache key?
This has also been fixed in version 0.5 of the spec. To answer your
question, an empty array.
>
> G) Section 3.4.2 - should the cache be released before or
> after rendering
> the page on which the Fis_Cache key is present?
I thought the example I gave made it clear: before.
>
> 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?
Yes, I agree. This will be changed in 0.6.
Thanks for your comments.
-Rick
>
This archive was generated by hypermail 2b29 : Fri Dec 20 2002 - 11:47:07 EST