Mike,
Did you produce a "show changes" version of the new documents?
glen
-----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
All,
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
_______________________________________________
sm3 mailing list
sm3 at pwg.orghttps://www.pwg.org/mailman/listinfo/sm3