[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 michael.r.sweet at gmail.com
Tue Sep 3 15:11:06 UTC 2013


The published PDF for PWG PJT has been updated...

On 2013-08-29, at 4:41 PM, Michael Sweet <msweet at apple.com> wrote:

> 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
> _______________________________________________
> sm3 mailing list
> sm3 at pwg.org
> https://www.pwg.org/mailman/listinfo/sm3

Michael Sweet

More information about the sm3 mailing list