[SM3] PWG Print Job Ticket and Associated CapabilitiesCandidate Standard

[SM3] PWG Print Job Ticket and Associated CapabilitiesCandidate Standard

[SM3] PWG Print Job Ticket and Associated CapabilitiesCandidate Standard

Petrie, Glen glen.petrie at eitc.epson.com
Tue Sep 3 16:33:15 UTC 2013


Did you produce a "show changes" version of the new documents?  


-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of
Michael Sweet
Sent: Tuesday, September 03, 2013 8:11 AM
To: Semantic Model 3.0 Workgroup discussion list
Subject: Re: [SM3] PWG Print Job Ticket and Associated
CapabilitiesCandidate Standard
Importance: High


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>
>> ...
>> .         There are some minor editorial problems in the posted
>> standard which might raise questions on the state of the
>> a.      Status on the first page is Stable rather than approved.
>> b.      Line numbers are retains, which we normally do not do in
>> 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.
>> 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
>> This is not  straightforward and non-complicated discussion for
>> 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
>> processing instructions apply, document specific Document Tickets may
>> 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
>> primarily interested in Table 4. The introduction to this table
>> 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
>> 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
>> Capabilities Elements. The listing of Print Service elements (of
which there
>> are 9) and Operational Elements (1) under the Print Job Ticket is
>> particularly since  the distinction between Print Service Description
>> Print Service Capabilities eludes me.  Something like
>> DocumentPasswordSupported and Color Supported sound like Capabilities
>> 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
>> defined color space for raster coded documents. This assumes that all
>> 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

sm3 mailing list
sm3 at pwg.org

More information about the sm3 mailing list