[SM3] PWG Print Job Ticket and Associated Capabilities Candidate Standard

[SM3] PWG Print Job Ticket and Associated Capabilities Candidate Standard

[SM3] PWG Print Job Ticket and Associated Capabilities Candidate Standard

Michael Sweet msweet at apple.com
Thu Aug 29 20:41:52 UTC 2013


Bill,

On 2013-08-23, at 2:06 PM, William A Wagner <wamwagner at comcast.net> wrote:
> ...
> .         There are some minor editorial problems in the posted candidate
> standard which might raise questions on the state of the specification:
> 
> a.      Status on the first page is Stable rather than approved.
> 
> b.      Line numbers are retains, which we normally do not do in approved
> candidate standards
> 
> c.       Figure 21 Caption separated from figure

I can re-generate the PDF and fix these issues pretty easily.  Will do so next Tuesday when I am back in the office...

> .         With great foresight, the document is labeled Version 1.0. This
> suggests the question of what  is envisioned for subsequent versions.
> (corrections, expansion (of what), ?)

I think it would be appropriate to add a short FAQ for this on the new web site; we can list PJT as one of the technologies and provide a FAQ for PJT specifically.

> .         There is explanation of the various, perhaps contradictory
> instructions  and the increasing  priority in  PrintServiceDefaults,
> Document Data  embedded , PrintJobTicket, and PrintDocumentTicket. There is
> a nod to the fact that override of  Document Data  embedded instructions is
> iffy, with recent discussion suggesting the override is a difficult issue.
> This is not  straightforward and non-complicated discussion for someone
> Would it be reasonable to say that the PWG  provides for Job Tickets
> relating to the identification, description and user processing intent for a
> job; and that, should the job contain multiple documents for which different
> processing instructions apply, document specific Document Tickets may be
> provided. Naturally, if processing parameters are not supplied, there is a
> default set of parameter-values pairs. And,  it is most desirable that the
> document data not include processing information, since the override of such
> information is uncertain.

Yes.  Again, we can include a FAQ on this for now and then (once we have the issue tracker online) include this in the pending errata.

> .         Someone interested in what the Print Job Ticket covers will be
> primarily interested in Table 4. The introduction to this table indicates
> that  it includes:
> 
> 1 - Document Processing
> 
> 2 - Job Description
> 
> 3 - Job Processing
> 
> 4 - Document Description 
> 
> 5 - Print Service Description
> 
> 6 - Operational Elements. 
> 
> Processing and Description elements  seem appropriate for a job ticket..but
> why Print Service Description and Operational elements?

The operational elements apply to the document or job (DocumentFormat, DocumentUri, RequestingUserName, etc.)  I'm not sure why Print Service Description is here but will re-read to see what is intended.

Certainly parenthetical statements could be added to clarify things, and the ordering could be made more consistent...

> Further, the document has a Table 5 which appears to cover Print Service
> Capabilities Elements. The listing of Print Service elements (of which there
> are 9) and Operational Elements (1) under the Print Job Ticket is confusing
> particularly since  the distinction between Print Service Description and
> Print Service Capabilities eludes me.  Something like
> DocumentPasswordSupported and Color Supported sound like Capabilities but
> are listed under Print Job Ticket Elements and not Print Service
> Capabilities.
> 
> .         Color management is an important issue, but seems minimally
> supported.      Print Color Mode (color or bi-level)and
> PrintRenderingIntent (handling of out-of-gamut colors) appear to be the only
> non-media color parameters, other than PwgRasterDocumentTypeSupported which
> defined color space for raster coded documents. This assumes that all color
> definition is in the (non raster) document data.

There is also the IccProfiles group in the capabilities.

In any case, color management really just comes down to the device color space definition and the document color space definition - that allows a color management system to map document color to device color in a consistent way.  The rendering intent and color mode are the only additional controls we are supplying.

Common elements like brightness, contrast, hue, and saturation are generally not used with ICC-based color management systems - the transforms depend too much on the document color space - and I wouldn't want to add them as general document processing elements.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




More information about the sm3 mailing list