[Cloud] RE: About PWG Print Job Ticket

[Cloud] RE: About PWG Print Job Ticket

[Cloud] RE: About PWG Print Job Ticket

Petrie, Glen glen.petrie at eitc.epson.com
Wed Nov 30 21:33:36 UTC 2011


Peter,

 

Thanks for providing your model.  While I understand it; from your
description, I now have an even more fundamental difference than just
the Print Job Ticket.

 

I would like to continue our dialog as it really helps in understand the
model that you and others are using; but, if you want to take it off the
mail list; that would be ok with me.

 

My fundamental difference is the role and responsibilities you discuss.

 

I equate your "Client" with an Application and your "Print Service" with
a "Print Client"!  That is, the Application invokes a Print Client
(think of the old Print Dialog).  The Print Client, along with the Print
Service capabilities (how that is obtained is another mail thread),
provides the user (or maybe the application) with a set of settable
print (service, printing) options for each document the user (or maybe
the application) wants to print as part of the Print Job.  It is the
Print Client that creates the Print Job (object).  The Print Client
submits the Print Job to the selected Print Service.  The Print Service
can then reject or acceptance the Print Job Request.    If accepted the
Print Service put the Print Job in the Print Service's print queue.  I
believe this what you refer to a "job creation".  In my model, only the
Print Client can create Print Jobs and only the Print Service can
execute Print Jobs; it is a simple and distinct separation of roles and
responsibilities.   In both the Cloud and mobile environments, this
separate enables a simpler API implementation.

 

While I did not discuss Print Status initially, it may or may not be
desirable to record job, print-service, printing status in the actual
Print Job Ticket; to me, that is just recording keeping and the print
status could be recorded in a number of places.  To me, the questions
are: Does the Application care about print status - no.  Does the Print
Client care about print status - no.  Only the user care about print
status.   If the Print Job fails, the User will have to invoke a new
print request once the failure has been resolved.   This makes it
possible (maybe desirable) for the Print Service to send status data to
a completely separate and independent Print Status Service!!  This
atomic approach works well in Cloud and mobile where the location of the
individual entities can be anywhere and in different security domains. 

 

Back to the question of how to use your model in/with my model.   For
any Print Service I create would have a binding to what I call the Print
Client or I create a Print Manager that acts as your Print Service.

 

glen

 

________________________________

From: Zehler, Peter [mailto:Peter.Zehler at xerox.com] 
Sent: Wednesday, November 30, 2011 11:00 AM
To: Petrie, Glen; cloud at pwg.org
Subject: RE: About PWG Print Job Ticket

 

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/d1f13d95/attachment-0002.html>


More information about the cloud mailing list