IFX Mail Archive: IFX> More comments on PDF/is

IFX Mail Archive: IFX> More comments on PDF/is

IFX> More comments on PDF/is

From: Buckley, Robert R (RBuckley@crt.xerox.com)
Date: Fri Dec 20 2002 - 10:42:28 EST

  • Next message: thrasher@lexmark.com: "IFX> Additional IFX Comments"

    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?



    This archive was generated by hypermail 2b29 : Fri Dec 20 2002 - 10:42:55 EST