Many thanks Michael. Hope all is going well.
Bill W.
-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Michael
Sweet
Sent: Thursday, August 29, 2013 4:42 PM
To: Semantic Model 3.0 Workgroup discussion list
Subject: Re: [SM3] PWG Print Job Ticket and Associated Capabilities
Candidate Standard
Importance: High
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.orghttps://www.pwg.org/mailman/listinfo/sm3