Here are some really good comments from Martin Bailey about a number of
recent emails about the FileSpec proposal for JDF from Ann McCarthy, Bob
Taylor, and myself.
Martin,
One thing I left out of the proposal by mistake was how to indicate which
types of fonts:
"Type 1"
"TrueType"
"OpenType"
...
I think we should just add another attribut to FileSpec, say, FontType
(string) that has meaning when FileClass = Font.
I like yours and Ann's suggestion not to use the ISO standard designation
("ISO nnnn-part:year") when the ISO standard has a versioning mechanism
specified as part of it, as does TIFF/IT and PDF/X (see below).
Also I forgot to include DCS (Desktop Color Separation version 2). It
doesn't have an ISO standard, right?
Tom
-----Original Message-----
From: Martin Bailey [mailto:Martin.Bailey@globalgraphics.com]
Sent: Thursday, March 20, 2003 03:03
To: hastings@cp10.es.xerox.com
Subject: CIP4 Forum Capabilities: Re:JDF FileSpec/@FileFormatVersionand
IPP "document-format-version"for PDF/X and TIFF/IT
Hi Tom
Responses in-line.
At 02:37 19/03/2003, Tom Hastings wrote:
>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?
I would go back to the suggestion that I originally made, which matches the
strings that are used inside the file to uniquely identify the conformance
level: "PDF/X-1a:2001", "PDF/X-3:2002", etc.
At 19:02 19/03/2003, Tom Hastings wrote:
>1. Should we also list in JDF the "PDF/X-1:1999" value as well? Its
mention
>in the 2001 ISO standard as an "older version".
Given that the list we will include in the standard is, almost by
definition, incomplete, no - I would not include that. It's an obsolete
file format, defined in a standard that has been withdrawn. If somebody
really wants to include it they could figure out from the other values in
the list what the right string should be.
>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:
That would be "ISO 12639:1998", colon rather than hyphen.
> 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?
OK, but how do you plan to distinguish between the sub-file types (FP, CT,
LW, HC) and between baseline TIFF/IT and TIFF/IT-P1?
Those are important questions when it comes to capabilities reporting
because many tools will only read P1, and not baseline, and many can't read
all of the sub-file types.
I made some suggestions for those in my original mail.
At 15:27 19/03/2003, Ann McCarthy wrote:
>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.
Ann's suggested list is almost what we need:
- I'm not sure what "TIFF/IT" on its own means in that context - did you
mean 'FP'? I know FP isn't normative in the 1998 standard (it is in the
2003 revision), but that doesn't stop people using it :-)
- there's a 2003 revision of 12639 in ballot at the moment, so we need a
date suffix on all of the above. In theory the P1 subset has not been
changed in that revision (we tried not leave it unchanged, anyway), but I'd
feel safer with a date suffix still, although that might complicate
capabilities reporting somewhat. The revision also adds a new file subtype
(SD), and a new conformance level (P2). The full list therefore gets a bit
long:
TIFF/IT-FP:1998
TIFF/IT-CT:1998
TIFF/IT-LW:1998
TIFF/IT-HC:1998
TIFF/IT-MP:1998
TIFF/IT-BP:1998
TIFF/IT-BL:1998
TIFF/IT-FP/P1:1998
TIFF/IT-CT/P1:1998
TIFF/IT-LW/P1:1998
TIFF/IT-HC/P1:1998
TIFF/IT-MP/P1:1998
TIFF/IT-BP/P1:1998
TIFF/IT-BL/P1:1998
TIFF/IT-FP:2003
TIFF/IT-CT:2003
TIFF/IT-LW:2003
TIFF/IT-HC:2003
TIFF/IT-MP:2003
TIFF/IT-BP:2003
TIFF/IT-BL:2003
TIFF/IT-SD:2003
TIFF/IT-FP/P1:2003
TIFF/IT-CT/P1:2003
TIFF/IT-LW/P1:2003
TIFF/IT-HC/P1:2003
TIFF/IT-MP/P1:2003
TIFF/IT-BP/P1:2003
TIFF/IT-BL/P1:2003
(no P1 conformance level of SD)
TIFF/IT-FP/P2:2003
TIFF/IT-CT/P2:2003
TIFF/IT-LW/P2:2003
TIFF/IT-HC/P2:2003
TIFF/IT-MP/P2:2003
TIFF/IT-BP/P2:2003
TIFF/IT-BL/P2:2003
TIFF/IT-SD/P2:2003
But, as I commented above, the list in the spec can only be regarded as
incomplete, so it might be better to explicitly make it a set of examples
and include only some of these?
At 07:32 19/03/2003, Bob Taylor wrote:
><bt>
>I would think we'd just use the TIFF MIME type for these (application/TIFF
>?).
></bt>
No, because most TIFF/IT subfile types are not valid TIFF.
Martin
>Tom
>
>
>
>-----Original Message-----
>From: McCarthy, Ann L
>Sent: Tuesday, March 18, 2003 10:09
>To: Zehler, Peter; Hastings, Tom N; sm@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@crt.xerox.com]
>Sent: Tuesday, March 18, 2003 9:52 AM
>To: Hastings, Tom N; sm@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@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
>
>
>-----
>This message was submitted by Tom Hastings (Xerox)
>Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5383
>Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1
-----
This message was submitted by Martin Bailey (Global Graphics Software)
Message URL: http://www.cip4.org/intern/groups/email_details.php?eid=5407
Forum URL: http://www.cip4.org/intern/groups/email_forum.php?gid=1
This archive was generated by hypermail 2b29 : Thu Mar 20 2003 - 10:35:57 EST