Tom,
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:
PDF/X-1:2001
PDF/X-1a:2001
PDF/X-2:2001
PDF/X-3:2001
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
string.
TIFF/IT files also have several possible conformance levels.
TIFF/IT conformance strings (given in section 5 of ISO 12639)
are:
TIFF/IT
TIFF/IT-CT
TIFF/IT-LW
TIFF/IT-HC
TIFF/IT-MP
TIFF/IT-BP
TIFF/IT-BL
TIFF/IT-P1
TIFF/IT-CT/P1
TIFF/IT-LW/P1
TIFF/IT-HC/P1
TIFF/IT-MP/P1
TIFF/IT-BP/P1
TIFF/IT-BL/P1
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
--------------------------------------------------------------------
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; sm at pwg.org
Cc: CIP4 Capabilities WG [capabilities at cip4.org]; 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
of:
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
"application/pdf".
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?
Tom
-----Original Message-----
From: McCarthy, Ann L
Sent: Tuesday, March 18, 2003 10:09
To: Zehler, Peter; Hastings, Tom N; sm at pwg.org
Subject: RE: SM> My response to some of the 18 Document
issues...Comments?
All,
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 [mailto:PZehler at crt.xerox.com]
Sent: Tuesday, March 18, 2003 9:52 AM
To: Hastings, Tom N; sm at pwg.org
Subject: SM> My response to some of the 18 Document issues...Comments?
All,
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?
Pete
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
CreateJob-Document
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?
<PZ>Yes</>
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"
attribute?
<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
attribute?
<PZ>Yes</>
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
support?
<PZ>Yes</>
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
format.
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]
§3.2.1.1 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.
<PZ>OK</>
ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx
in the IANA Registration of Document Template attributes.
<PZ>OK</>
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.
<PZ>OK</>
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.
<PZ>OK</>
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler at crt.xerox.com
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
<snip>
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf
<snip>
Send any comments to the SM mailing list.
Thanks,
Tom