[Printing-architecture] Conceptual Model for Common Mobile Print Dialog (Client)

[Petrie, Glen]

All, 

 

below is my current conceptual model for Mobile Common Print Dialog.  I
would like feedback so that I go continue to defining the details.   I
would also like to discuss it at the next phone conference meeting. 

 

The very first thing I would like to do is change the name of the Common
Mobile Print Dialog to Common Mobile Print Client (CMPC)

 

Need/Requirements:

1.      Provide a Print Client usable by any Application or the
Operating System.

2.      Provide a Print Client with a common User experience

3.      Provide a Print Client requiring minimum resources suitable for
mobile solutions

4.      Processing/Processes should minimize interaction to minimize
connectivity complexities. 

 

 

Preconditions:

1.      The Application is not concerned with the mechanic, outcome or
status of printing. 

2.      The CMPC is not concerned with the outcome or status of
printing. 

3.      The CMPC may not be in the same security domain as the
Application or Print Preview Service

4.      A Print Service may not be in the same security as other print
entities

5.      The CMPC, by extending meaning of common, is usable by all
Applications. 

 

Definitions:

Application-Page-Size: 

This is the page size (not print page size) used by the Application
formatted the content within the application.

Print-Page-Size:

This is the page size of the printed Print Content.

 

 

Identify Entities Associated with the Mobile print chain.

Application:                            The creator of the Print
Content.

Common Mobile Print Client: The creator of a Print Job.

Print Preview Service:          The entity to display a preview of the
Print Content

            Print Service:                         The entity that
executes a Print Job

            Print Status Service:              The entity that displays
status to the user.

 

Identify Major Data Objects

Print Job

Print Job Info 

Print Job Ticket

Print Content

Print Content Properties

Print Service Capabilities 

Print Preview Data

Print State, Status, Error Data

 

Overview Discussion: In a nutshell

This conceptual model identifies and defines the roles and
responsibilities to the principle entities in a mobile print chain with
the goal of defining the Common Mobile Print Client (CMPC) and
associated Print Preview Service (PPS).  

When an Application supports Print Preview, the Application generates
both the Print Content (in standard format and for access by reference)
and a Print Preview Data (File).  The Application then invokes the Print
Preview Service.  The Print Preview Service will then invoke the CMPC to
establish a communication channel (which is solution/binding dependent).
Based on the capability data of the user selected Print Service, the
CMPC will provide a mechanism for the User to select Print Job
options/settings.   Any Print Job options/settings that affect the Print
Preview are communicated to the Print Preview Service to update the
preview.   When the User is done (presses the OK button) the CMPC will
generate a Print Job (Print Job Info + Print Job Ticket + Print Content)
in the format specified in the Print Service Capability data.   The CMPC
then sends the Print Job to the specified Print Service.   During
printing, the Print Service will send Print Job, Printer, Printing
state, status and error data to the Print Status Service. 

 

When the Application does not support Print Preview, the Application
generates the Print Content Data (in standard format and for access by
reference) and directly invokes the CMPC.  There is no feed back to the
Application from the CMPC.  Once the User is done setting Print Job
options/settings, operations proceed as described above. 

 

To provide secure operations it is necessary that the Print Preview
Service be in the same security domain as the Application.  This means
that the Print Content is at no increased security risk when being
displayed by the Print Preview Service.   The CMPC does not receive or
need the actual Print Content; the CMPC only needs the Print Content
URL, Print Content access credentials (if any) and Print Content
properties (number of pages, page size, etc).   Thus, the CMPC does not
have to be in the same security domain and needs no special security
functionality.  This also supports the concept of a single (common) CMPC
that can be used by all applications.   The Print Service for mobile and
cloud environments, in many cases, will not be in the same domain or
security domain as the Application or even the CMPC.  Thus, the Print
Service uses the data from the Print Content object of the Print Job to
access the actual Print Content.   (When in the same domain, this is
quite simple; while when there a multiple domains or differing security
domains, this is more complex and may require secure connectivity.)

 

 

Roles and Responsibilities of individual Entities

Application: The creator of the Print Content.

Applications, in general, do not care about printing or whether printing
succeeded or failed.  Applications want to support printing with minimal
efforts AND with little or no change over time.   To meet this need,
entities involved in the print chain must be independent from the
Application and the Application only has to provide two required data
objects and one optional data object.  The two required data objects are
the Print Content and the Print Content Properties.   The optional data
is the Print Preview data. 

 

Since it impossible to support all Application data format types, the
Application Content must be rendered by the Application in to one of the
support standard Print Content Formats; namely, PDF, PWG:Raster, jpeg.
Other formats may be added at a later date.   A critical issue is that
the Print Content rendered by the Application is formatted according the
Application Content Attributes.  This means that Application renders the
content based on the Application's (or system's default) page size,
margins, and so forth.  This applies simple text document and web pages.


 

[If the Application were to interact with the CMPC to obtain media size
attributes, it would require a complex interaction of the CMPC, the user
and one or more Print Services.   So, if the User wants the Print Page
Size to be equal to the Application Page Size, the User must set, within
the Application, the Application Page Size to match the Print Page Size.
Note if the CMPC were part of the Application, this would be a non issue
but we don't want every Application to have or need to provide its own
CMPC.  Thus, Applications must provide support for setting the
Application's Page Size information independent of any print entity.  In
the worst case the Application must obtain a default "Application Page
Size" from the operating system.]

 

The Print Content Properties are a description of the Print Content
versus the actual content.  This allows the CMPC to be in a separate
domain from the Application and does not require the CMPC to (correctly)
extract properties from the Print Content directly.   Beyond the basic
content properties the Print Content Properties contains the information
required in the Print Job Ticket on how to access the actual Print
Content. 

 

The optional Print Preview data is used by Print Preview Service.
After experimentation, it has determined that a very simple, low dpi
representation of the Print Content is all that is required for the
preview functionality.   Because the Application will render the Print
Content based on the Application's page attributes and not the Print's
page attributes, the Application only has to generate the Print Preview
Content ONCE!  

 

Print Preview Service: The entity to display a preview of the Print
Content

The functionality of the Print Preview Service is to provide the user
with a preview of their content in the form factor as it will printed.
With the independent concepts of the Application Page Size and the Print
Page Size; the Print Preview Service requires no feedback from the
Application (!) only from the CMPC.  What the Print Preview Service
needs from the Application is a representation of the Print Content in a
common format.   After some experimentation it was determined that a
simplified version of the PWG:Raster format could be used.   The preview
format produces a very small file to minimize resource needs on the
mobile device. 

 

Why must the Print Preview Service call the CMPC?  This is to establish
communication and connectivity between the two entities.  If the
Application were to invoke the Print Preview Service and the CMPC
independently; then there would need for a method for each entity to
communicate with the other.  If the Print Preview Service invokes the
CMPC, then the Print Preview Service can provide the CMPC with
communication information.  (For example, in the case of pipes on the
same system, the Print Preview Service launches the CMPC as a service to
itself.) 

 

The Print Preview Service never sends Print Content information or data
to the CMPC.  The Print Preview Service only accepts print attributes
and values that would directly affect the preview.  Examples include
N-up, print in black, page-range, scaling, rotation and so forth.  These
are all attributes that the Print Preview Service can render to the
Print Preview data independent of the Application.

 

Common Mobile Print Client: The creator of a Print Job.

[Note: While I have conceptual model for how the CMPC obtains the Print
Services Capabilities, it will not be discussed here.  For this
discussion it is assumed the User has selected a Print Service and the
Print Service Capability data has been provided to the CMPC.]

 

The CMPC is responsible for providing the User with a mechanism to set
print/printing attributes and to create (generate) a Print Job (Object).
The "mechanism" is a discussion for another email thread because it has
at least or maybe more complexity in the "how" that is done.   The only
important item, for this discussion, about the interaction with the User
in the setting of print/printing attributes is that (asynchronously)
print/printing attributes that affect the preview are communicated with
the Print Preview Service. 

 

Once the User has completed setting print/printing attributes, the CMPC
generate a Print Job consisting of Print Job Info, Print Job Ticket and
Print Content (Info).  At this point the CMPC makes a request to the
Print Service for a new job.   To allow for independent and isolation of
responsibilities, the Print Status Service will receive an update if the
job was accepted or not.   For the CMPC there are two choices.  The
first (the one I favor) is to signal the Print Preview Service to end
and for the CMPC to end.  (If the Print Job fails the User must fix the
problem and, via the Application, do a new print request.  The
alternative is the CMPC waits for a reply from the Print Service on
acceptance of the Print Job.  If the Print Job is rejected, the CMPC
informs the User and allows the User to change the print/printing
settings or to cancel the print request.   No matter what, if the Print
Job is accept by the Print Service the CMPC (and the Print Preview
Service) terminate. 

 

What about the issue or difference between the Application Page Size and
the Print Page Size.  The User would have a setting for scaling or
cropping when the two page size are different.   Thus, there is a
transform process when different and the transform is performed BY THE
PRINT SERVICE. 

 

 

            Print Service: The entity that executes a Print Job

A Print Service executes a Print Job.  At this level of discussion, we
do not care how it does it; only that it does.  The only interaction
with another entity is with the Print Status Service.

 

            Print Status Service:  The entity that displays status to
the user.

This is an independent entity that the display or provides to the User
feedback (state, status, errors) concerning the Print Job that the User
selected (wanted) to be informed of.

 

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20111201/9e5784b6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simplifed CMPC.pdf
Type: application/octet-stream
Size: 175869 bytes
Desc: simplifed CMPC.pdf
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20111201/9e5784b6/attachment-0001.obj>