[SM3] PWG Print Job Ticket and Associated Capabilities Candidate Standard

[SM3] PWG Print Job Ticket and Associated Capabilities Candidate Standard

[SM3] PWG Print Job Ticket and Associated Capabilities Candidate Standard

William A Wagner wamwagner at comcast.net
Fri Aug 23 18:06:04 UTC 2013


By my understanding, the point we wish to make to the W3C publishing
conference is that the PWG knows how, has developed a model and has, in the
PWG Print Job Ticket, clearly documented a set of elements which allow a
user to specify print intent. Since this model is an abstraction of the IPP,
which is supported by virtually every network printer, this set of elements
and values is a consistent, unambiguous and , from a Print Device viewpoint,
an almost universally understood way of expressing User Print Processing
intent. The PWG Print Job Ticket and Associated Capabilities Candidate
Standard is the key document defining this element set. 

 

However, in  looking at this document after a year, there are a few things
which someone  from the W3C workshop may find off-putting. Although it is
unreasonable to attempt to address or clarify these items in the document
before the September meeting, perhaps some can be resolved in the near
future. Meanwhile, some discussion may help me better explain these things
should the subject come up.

 

.         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

 

.         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), ?)

.         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.

.         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?

 

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.

Thanks,

Bill Wagner




More information about the sm3 mailing list