SM> JDF FileSpec/@FileFormatVersion and IPP "document-format-version" for PDF/X and TIFF/IT

SM> JDF FileSpec/@FileFormatVersion and IPP "document-format-version" for PDF/X and TIFF/IT

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Mar 18 21:31:32 EST 2003


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



More information about the Sm mailing list