The published PDF for PWG PJT has been updated...
On 2013-08-29, at 4:41 PM, Michael Sweet <msweet at apple.com> wrote:
>> 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
>>>> . 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