[Cloud] Comments on first part of the print job ticket spec dated 2011.11.28

[Cloud] Comments on first part of the print job ticket spec dated 2011.11.28

[Cloud] Comments on first part of the print job ticket spec dated 2011.11.28

Petrie, Glen glen.petrie at eitc.epson.com
Tue Nov 29 18:44:44 UTC 2011


Comments on first part of the print job ticket spec dated 2011.11.28

 

 I believe the word "datatype" used through out the document is really
two words "data type".  In many case the term "data type" can be dropped
with loss of understanding or meaning. 

 

I find the first couple of paragraphs of the overview to be confusing.
(lines 258  -> 273)

 

The discussion talks about a PrintDocumentTicket but it is not shown in
the Figure 2; so there is no context to understand its relationship.
From later discussion it looks like PrintDocumentProcessing, in Figure
2, should be replaced with PrintDocumentTicket.  And, there would be
0...Inf number of PrintDocumentTickets. I find the title
PrintDocumentTicket confusing, the only other name I can come with is
"Docket").  I would think that there should only be one Ticket object;
namely, the PrintJobTicket.]

 

//removed picture; too large// in Figure 2, just replace
PrintDocumentProcessing  with PrintDocumentDocket  (with 0 .. inf)

 

Now the paragraph starting at 258  -> 273 becomes.

 

========

The PrintJobTicket of the PrintJob contains elements for job and
document processing and descriptive properties.  The PrintJobDescription
and PrintJobProcessing elements apply to the entire PrintJob.  The
elements of a first PrintDocumentDocket shall apply to all Documents
within the PrintJob unless overridden by an individual
PrintDocumentDocket.   In other words, the first PrintDocumentDocket
within a PrintJobTicket contains the default element values for all the
contained Documents while individual Document's PrintDocumentDocket will
override the element values specified in the default (the first)
PrintDocumentDocket.  The most common PrintJobTicket will contain only a
single Document and a single PrintDocumentDocket. 

========

 

Line 274 should "associated with" be "associated within"

 

Line 275 change start of the line to be - Print Intent: The
PrintJobTicket data type is used in the job submission ....

 

Line 279 change start of the line to be - Validated PrintJobTicket: The
PrintJobTicket data type is used in a PrintJob to indicate the accepted
request.

 

Line 282 change start of the line to be - PrintJobReceipt: The
PrintJobTicket data type is used to record the applied ....

 

Line 288 change start of the line to be - PrintService Defaults:  The
PrintJobTicket data type contains the default value for the Print
Service. ....

 

Line 311, 315, 316, 317,319,  I believe "Printer" should be "Print
Service"   (for cloud or mobile, there may be no (should not be any)
direct "printer" communication)

 

Line 312 Should the entity "User" really be the "Print Client" or just
"Client" ?

 

Line 349 The discussion is about the entity called "PrinterCapabilities"
but in the new paradigm the Print Client can not tell or cares about the
distinction between the Printer and the PrintService; that is, the
"Capabilities" are the capabilities of the printer and the PrintService.
We no longer send a PrintJob to a Printer, we sent the PrintJob to a
PrintService even if the PrintService resides in the physical printer.
This level of abstraction is needed to support cloud and mobile printing
(scan, coping, faxing) going forward.

 

More comments later. 

 

 

 

Glen

 

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20111129/ebe94406/attachment-0002.html>


More information about the cloud mailing list