Semantic Model Mail Archive: SM> RE: JDF FileSpec/@FileForma

Semantic Model Mail Archive: SM> RE: JDF FileSpec/@FileForma

SM> RE: JDF FileSpec/@FileFormatVersion and IPP "document-format-vers ion" for PDF/X and TIFF/IT

From: McCarthy, Ann L (
Date: Wed Mar 19 2003 - 10:19:10 EST

  • Next message: Hastings, Tom N: "SM> RE: JDF FileSpec/@FileFormatVersionand IPP "document-format-versi on"for PDF/X and TIFF/IT"


    I am rethinking the recommendation to use the ISO standard name.
    When we established that idea originally we were dealing with media
    standards. Media measurement standards and other physical system
    standards can be designated by the ISO or other selected standard name.

    I now realize that file formats need to be treated differently.
    In the file format case - each file format standard itself specifies
    a conformance string value that must be used in the file to identify
    the specific standard to which the file conforms. JDF should use those
    same conformance identifier strings.

    So for PDF/X the conformance values are:
    One of these string values will appear in the PDF/X key "GTS_PDFXVersion"
    (with the exception of PDF/X-1a:2001). If the PDF/X file is X-1a conforming
    then 'PDF/X-1:2001' will appear in the "GTS_PDFXVersion" key and the
    'PDF/X-1a:2001' string will appear in the additional key
    "GTS_PDFXConformance". So X-1a pdf files are identified by a combination of
    these two keys within the pdf file. JDF should be able to use a single

    TIFF/IT files also have several possible conformance levels.
    TIFF/IT conformance strings (given in section 5 of ISO 12639)

    Each of these informs the reader of specific constraints or file
    interpretation requirements.

    We may be able to reduce the list of TIFF/IT strings if someone
    more familiar with the exchange of TIFF/IT can identify a case
    that never occurs. Absent that - JDF should duplicate the
    conformance level identifiers given in the ISO 12639 standard.

    My apologies for the back-and-forth on this. After looking at the
    file format standards I think that one consistent way
    of specifying all standards is less important than adhering to
    previously defined conformance identification methods when they
    are available.

    Best regards,

    Ann L. McCarthy
    XIG/SSTC Imaging Systems Architect
    Internal:8*221-8701 External: 585-231-8701
    FAX: 585-265-8871 Mailcode: B128-30E

    -----Original Message-----
    From: Hastings, Tom N
    Sent: Tuesday, March 18, 2003 9:32 PM
    To: McCarthy, Ann L;
    Cc: CIP4 Capabilities WG []; Masinter, Larry at Adobe
    Subject: JDF FileSpec/@FileFormatVersion and IPP "document-format-version"
    for PDF/X and TIFF/IT

    I did a google search to find out what the ISO designation is for the
    PDF/X-1 and TIFF/IT ISO standards.

    We're trying to define which values should be used for JDF
    FileSpec/@MimeType and FileSpec/@FileFormatVersion attributes, assuming that
    we've collapsed FileFormatStandard into FileFormatVersion as suggested.

    Same question for IPP "document-format" (mimeMediaType) and
    "document-format-version" (text(127)) attributes, assuming that we've
    collapsed "document-format-standard" into "document-format-version"
    (text(127)) as suggested.

    This is what I found from google:

    1. PDF/X:

    ISO 15930-1:2001 Graphic technology -- Prepress digital data exchange -- Use
    of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a)

    So this sounds great to use the value of "ISO 15930-1:2001" for the value

      FileSpec/@FileFormatVersion attribute in JDF

      "document-format-version" attribute in the IPP Document object spec

    instead of "PDF/X-1:2001". And the MimeType attribute value will be

    ISSUE: But how do you specify PDF/X-1 versus PDF/X-1a? We can't distinguish
    them in either the MimeType or FileFormatVersion attribute?

    2. TIFF/IT:

    ISO 12639:1998 Graphic technology -- Prepress digital data exchange -- Tag
    image file format for image technology (TIFF/IT).

    So use the value "ISO 12639-1998" for the value of:

      FileSpec/@FileFormatVersion attribute in JDF

      "document-format-version" attribute in the IPP Document object spec

    Since TIFF/IT doesn't yet have a MIME type registered, the JDF
    FileSpec/@MimeType attribute will be omitted and the IPP "document-format"
    attribute will be omitted, OK?


    -----Original Message-----
    From: McCarthy, Ann L
    Sent: Tuesday, March 18, 2003 10:09
    To: Zehler, Peter; Hastings, Tom N;
    Subject: RE: SM> My response to some of the 18 Document


    WRT 12: recommend "ISO nnnnn.n-2001" as in JDF.

    Ann L. McCarthy
    XIG/SSTC Imaging Systems Architect
    Internal:8*221-8701 External: 585-231-8701
    FAX: 585-265-8871 Mailcode: B128-30E

    -----Original Message-----
    From: Zehler, Peter []
    Sent: Tuesday, March 18, 2003 9:52 AM
    To: Hastings, Tom N;
    Subject: SM> My response to some of the 18 Document issues...Comments?


    I saw many of the issues as "low hanging fruit". I have my responses to
    issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on
    and issues 14 to 17 are basically work to be done. This leaves issues 9 and
    11. These involve how to represent the supported values for the document
    format detail attributes. I think we will need to dedicate a large chunk of
    time for this issue in Thursday's teleconference.

    Are there any comments on these issues or my responses?


    ISSUE 00: Or should we just delete "input-document-number" operation
    attribute when we republish pwg5100.4 without "document-overrides?
    <PZ>Delete "input-document-number". Document numbers start at 1 and
    monotonically increment as documents are added to the Job.</PZ>

    ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the
    object on which it operates?
    <PZ>No, keep it Send-Data. I see no reason for the longer name. The only
    data we send is associated with a Document. We don't have
    or Create-Printer-Job.</PZ>

    ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support
    it, since PSI is using it?

    ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute
    for a Printer to support (if it supports the Document object)? Otherwise,
    clients won't support it and will be stuck with the "ipp-attribute-fidelity"
    <PZ>It should be an OPTIONAL Operation Attribute that a Printer MUST support
    if the Printer supports the Document Object.</PZ>

    ISSUE 04: The "document-overrides" attribute is also useful in combination
    with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the
    Input Page stream concatenated across the Input Documents into separate
    Output Documents. For example, making every 10 Input Pages be a separate
    Output Document but the client only wants to staple the first Output
    Document. ISSUE 04: But what about Subset Finishing? Can we it be done
    without "document-overrides"?
    <PZ>Get rid of "document-overrides" in favor of the Document. Place the
    burden of the example corner case on the Client. The results can be easily
    achieved through the use of Documents and page-overrides.</PZ>

    ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE
    the Printer to continue to support the "page-overrides" as an operation
    attribute in Send-Document and Send-URI as well as a Document Template

    ISSUE 06: OK that "document-container-summary" is only one level deep?
    <PZ>Yes, this information is not a manifest of the contained documents.
    It is used to determine if a Printer can process the Document. Clients
    are free to send individual compressed Documents if a manifest of a Job's
    contents is required.</PZ>

    ISSUE 07: Is the description of "document-container-summary" attribute OK?
    <PZ>Clarify that a manifest can be accomplished by the Client sending
    individually compressed Documents.</PZ>

    ISSUE 08: Are the conformance requirements for the
    "document-container-summary" attributes OK?
    <PZ>No opinion</>

    ISSUE: 09: How can a Printer indicate which combinations of
    document-creator-application-name (name(MAX)),
    document-creator-application-version (text(127)), document-creator-os-name
    (name(40)), document-creator-os-version (text(40)),
    document-format-device-id (text(127)), document-format-version (text(127),
    document-format (mimeMediaType) and "document-natural-language
    (naturalLanguage) are supported?

    ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to

    ISSUE: 11: The problem with separating "document-format" and
    "document-format-version" is how can a Printer describe what versions are
    supported, since the versions have to be associated with the document

    ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X.
    ISSUE 12: Or should the official ISO standard number, part number and date,
    be used instead, e.g., "ISO nnnnn.n-2001"?
    <PZ>No opinion</>

    ISSUE 13: The definition of "document-natural-language" in [rfc2911] and [pwg5100.4] 5.1.7 is single-valued. OK that this Document
    Description attribute isn't 1setOf? Or should we extend
    "document-natural-language" to 1setOf naturalLanguage) and keep the same
    name? Or change the name to "document-natural-languages"?
    <PZ>Keep single-valued. It will handle the vast majority of cases and
    keep things simple</PZ>

    ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table
    14 that go with the Document Template attributes.

    ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx
    in the IANA Registration of Document Template attributes.

    ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx
    in the IANA Registration of Job Template attributes being defined.

    ISSUE 17: TBD - Need to list the keyword attribute values in the IANA
    Registration section. Do so by reference to the values registered for
    corresponding attributes.


                                    Peter Zehler
                                    Xerox Architecture Center
                                    Voice: (585) 265-8755
                                    FAX: (585) 265-8871
                                    US Mail: Peter Zehler
                                                    Xerox Corp.
                                                    800 Phillips Rd.
                                                    M/S 128-30E
                                                    Webster NY, 14580-9701

    Send any comments to the SM mailing list.


    This archive was generated by hypermail 2b29 : Wed Mar 19 2003 - 10:19:17 EST