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