Glen,
No, the only changes were to change the status to "Approved", remove the line numbers from the content pages, and fix the pagination around a few of the figures (captions separated from the figures...)
There are no actual content changes besides the status on the cover page.
The remaining issues that Bill brought up will need to be done as an errata (PJT 1.1) at some point in the future...
On 2013-09-03, at 12:33 PM, "Petrie, Glen" <glen.petrie at eitc.epson.com> wrote:
> 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.org>https://www.pwg.org/mailman/listinfo/sm3> _______________________________________________
> sm3 mailing list
>sm3 at pwg.org>https://www.pwg.org/mailman/listinfo/sm3
_____________
Michael Sweet