Glen,
I believe some of the confusion comes from the differences in various
environments on what constitutes a print job. There are many
environments that model only single document jobs. For example this is
what is used in Windows and Google Cloud Print. Other environment
support multi-document Jobs. IPP and WS-Print support multiple
document jobs.
Another source of confusion seems to be where a Print Job exists. It is
my understanding that the Print Job does not exist until a job creation
request (e.g. CreateJob, PrintJob, PrintUri) is accepted by a Printer
and a Job is created based on the information in the job creation
request.
I would modify your single document job model slightly
| Print Job Status
Print Job => | Print Job Content (by value or reference)
| Print Job Ticket => | Print Job Description
| Print Job
Processing
|Print
Document Processing
Where the Print Job is the job object created by the Print Service and
contains the job attributes and state
Where the Print Job Status is the set of attributes maintained by
automata for the job (e.g., JobState, ImpressionsCompleted)
Where the Print Job Content is the Document data
Where Print Job Ticket is the container element for the accepted
descriptive and processing intent
Where the Print Job Description is the Job level descriptive elements
(e.g., JobName, DocumentFormatSupplied). (your Print Job Info and Job
Content)
Where the Print Job Processing is the set of Job level processing
intents (e.g., JobPriority). (your Print Job Info)
Where the Print Document Processing is the set of attributes applied the
Print Job Content (e.g., Sides, Copies) (your Print Job Ticket).
In a single document job submission the Client supplies the Print Job
Content and optionally a Print Job Ticket in the job creation request.
The Printer copies, ignores or substitutes as appropriate when creating
the Print Job.
The multiple document job model looks like
Print Job => | Print Job Status
| Print Job Ticket => | Print Job Description
| | Print Job
Processing
| |Print Document
Processing
|Print Documents=> |Print Document=> | Print
Document Status
| Print Document Content (by value or reference)
| Print Document Ticket => | Print Document Description
|Print Document Processing
Where the Print Job is the job object created by the Print Service and
contains the job attributes and state
Where the Print Job Status is the set of attributes maintained by
automata for the job (e.g., JobState, ImpressionsCompleted)
Where Print Job Ticket is the container element for the accepted
descriptive and processing intent
Where the Print Job Description is the Job level descriptive elements
(e.g., JobName, DocumentFormatSupplied). (your Print Job Info and Job
Content)
Where the Print Job Processing is the set of Job level processing
intents (e.g., JobPriority). (your Print Job Info)
Where the Print Document Processing is the set of attributes applied the
Print Document Content (e.g., Sides, Copies) (your Print Job Ticket).
(Note: These values are used unless overridden at the document level)
Where the Print Documents is the container object created by the Print
Service for the contained Document(s)
Where the Print Document is the document object created by the Print
Service and contains the document attributes and state
Where the Print Document Status is the set of attributes maintained by
automata for the Document (e.g., DocumentState, ImpressionsCompleted)
Where the Print Document Content is the Document data
Where the Print Document Description is the Job level descriptive
elements (e.g., JobName, DocumentFormatSupplied). (your Job Content)
Where the Print Document Processing is the set of attributes applied the
Print Document Content (e.g., Sides, Copies) (your Print Job Ticket).
In a multiple document job submission the Client optionally supplies a
Print Job Ticket on the job creation request. The Print Document
Content and optionally the Print Document Ticket are supplied in the
add document/uri request. The Printer copies, ignores or substitutes as
appropriate when creating the Print Job or Print Document.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: Petrie, Glen [mailto:glen.petrie at eitc.epson.com]
Sent: Wednesday, November 30, 2011 12:30 PM
To: cloud at pwg.org; Zehler, Peter
Subject: About PWG Print Job Ticket
Peter,
After reviewing of the later content of the Print Job Ticket
specification, I realize what is called a Print Job Ticket in the
specification is what I have always understood to mean the Print Job.
And, what is called the Document Ticket is what I have always understood
to mean the Print Job Ticket. For example, in JTAPI, the attribute in
the specification that are associated with the Document Ticket are those
associated in JTAPI with a Print Job Ticket.
Perhaps you can provide me a reference for a Print Job.
My understanding is that a Client submits a Print Job to a Print
Service. A Print Job consists of a Print Job Ticket and Print Job
Content (Document) and Print Job Info (parts of what you call
PrintJobDescription and PrintJobProcessing).
My model
| Print Job Info
Print Job => | Print Job Ticket
| Print Job Content
Where the Print Job Info is the set of attributes you have that start
with 'Job'.
Where the Print Job Ticket is the set of attributes applied the Print
Job Content; what you call DocumentTicket/Processing.
Where the Print Job Content is the set of "documents" and attributes
that you generally have that start with 'Document'
In the specification the model is sort of like mine but the 'labels' are
different and some elements/attributes moved around. The closet analog
is
| Print Job Processing
Print Job Ticket => | Print Document Processing (could be Print
Document Ticket)
| Print Job Description
Since the PWG:PJT models, object and attributes are, I assume, based on
IPP-isms and naming conventions; I believe the best solution is mapping
of the PWG:PJT in binding code for support of the PWG:PJT.
So, I retracted my comments made yesterday and I will focus on bindings
and/or mappings of the PWG:PJT.
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/20111130/5f69132d/attachment-0002.html>