[MFD] RE: "Support Levels" for the SM2.0/PWG:PJT

[MFD] RE: "Support Levels" for the SM2.0/PWG:PJT

[MFD] RE: "Support Levels" for the SM2.0/PWG:PJT

Petrie, Glen glen.petrie at eitc.epson.com
Thu Feb 14 14:16:20 UTC 2013


Pete,

 

I have pretty much the same understanding as you do; as perhaps all the
individual how are regularly involved with PWG specifications.  However,
others, that is, someone new trying to create a Print Client may not
have the same understanding.   So I believe my action item was to
identify a few definitive Print Client support levels.   Perhaps the
action item is not needed or I have misunderstood what was requested.


 

Glen

 

 

________________________________

From: Zehler, Peter [mailto:Peter.Zehler at xerox.com] 
Sent: Thursday, February 14, 2013 3:53 AM
To: Petrie, Glen; mfd at pwg.org; cloud at pwg.org
Subject: RE: "Support Levels" for the SM2.0/PWG:PJT

 

Glen,

 

The semantic model, and IPP, has never had the position of "requiring
all Applications and Print Clients in the various environments to
support the complete set of PWG: PJT objects, elements, attributes and
values".  Anything a Print Client does not understand can be silently
dropped on the floor.  (The model does define some mandatory elements.
Those are 22 Printer Status and Description elements and 9 Job Status
and Description elements.  Most of those deal with charsets, languages,
state and identifying information.)  There is no requirement that
Printers or Clients must even support a PJT.  If a PJT is supported only
1 element must be supported (i.e., JobName).  If a Print Document Ticket
is supported then only 2 elements must be supported (i.e.,
DocumentFormatSupplied  and LastDocument).

 

There is no requirement that "Print Client must support all PWG:PJT
objects, elements, attributes and values that any Print Service could
potentially provide as a capability".  For that matter there is no
requirement that the Print Service must support all the PWG:PJT.  The
Client can be coded to only understand a small subset of the model, the
entire model, a superset of the model or even a subset with extensions.
When the Client encounters an element it does not understand it silently
ignores it.  The end user will only see the intersection of the set of
elements supported by the Client and those implemented by the Printer.

 

Then again maybe I don't understand the problem you are trying to solve.

 

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: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Petrie, Glen
Sent: Wednesday, February 13, 2013 1:29 PM
To: mfd at pwg.org; cloud at pwg.org
Subject: [Cloud] "Support Levels" for the SM2.0/PWG:PJT

 

All 

 

I was asked to provide a set of (call them) support levels for the
SM2.0/PWG:PJT.   I have completed the top level objects and would like
feed back on my proposal levels.

 

All of my documentation is done as C-Code for now.   [For BJSON, JSON,
XML or whatever, as you will see later, my code contains a "def" struct
for each element/attribute/value which are used for converting internal
binary (struct) data.]

 

 

Wording for Support Levels:

 

The Print Job Ticket (PJT) consist of a rich set of printing objects,
attributes, elements and values that support the simplest level of
printing to most complex.  It supports printing from/in embedded,
mobile, home-office, business office and production environments.
However, requiring all Applications and Print Clients in the various
environments to support the complete set of PWG: PJT objects, elements,
attributes and values would be a burden.   While a Print Service only
needs to provide capability information that is supports; currently, a
Print Client must support all PWG:PJT objects, elements, attributes and
values that any Print Service could potentially provide as a capability;
this is just not practical in all situations and environments.   This
section provides a solution by defining several Support Levels that a
Print Client can advertise to Print Services.         

 

An individual Support Level consist of proper subset of the complete set
of PWG:PJT objects, elements, attributes and values.  Currently, there
are three Support Levels.   The first level represent "Simple" printing
needs, the second level supports nominal/typical office printing and,
the third level, represent the full PWG:PJT specification. 

 


Any Print Client or Print Service may elect to implement (advertise and
comply to) one of the SM2.0/PWG:PJT Support Levels.  When a Print Client
or Print Service declares implementation of a Support Level, the Print
Client or Print Service MUST be capable of supporting all objects,
elements, attributes and values for that Support Level.  If a Print
Client does not declare a specific Support Level implementation, the
Print Client SHALL have an assumed Support Level of the most
encompassing (all objects, elements, attributes and values) Support
Level. 

 

A Print Client MAY advertise to a End-User an object, element, attribute
and/or value at a higher Support Level only if the Print Client directly
supports that object, element, attribute and/or value.  

 

For example, a Print Client at Support Level 1 MAY advertise "Front
Cover" support (a Support Level 2 element); but, the Print Client MUST
provide all internal implementation to support a Front Cover.   This is
analogous to Print Service with no Front Cover capability but with Print
Client support. 

 

A Print Service MUST NOT provide capability data or Print Job Ticket at
the Support Level above that of the Print Client.   The Print Client MAY
either:

i)                   Reject the Print Job Ticket in it entirety, or

ii)                 Reject the Print Job Ticket for unsupported
MUST_HONOR elements, or

iii)               Ignore the unsupported object, element, attribute
and/or value.

 

Please review info at 

ftp://ftp.pwg.org/pub/pwg/mfd/white/Proposed.PWG.PJT.Support.Level-2013.
02.13.zip 

 

(did not mean to put the last one in cloud directory)

 

glen

 

 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


-- 
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/mfd/attachments/20130214/84fb1deb/attachment-0002.html>


More information about the mfd mailing list