[Printing-architecture] Use of binary printer capabilities for mobile

[Petrie, Glen]

All,

 

I continue address the issues for mobile print in connection with
LF/OpenPrinting.   The current area-of-interest is printer capabilities.


Yes, I could simpley follow the PWG work that will use IPP (Everywhere);
and, through a series of Pascal/XML data exchanges, the printer
capabilities can be obtained.  This, however, causes a burden to the
mobile device and printer to understand and support the IPP and to
contain dictionary (string) parsers.   While the overhead may be
acceptable; it is still burdensome.  

 

The use of PPD files is possible but they have the same complexity as
above.

 

My proposal, in an attempt to simplify matters, is encode printer
capabilities, using the JTAPI attributes and values, such that the
printer capabilities are binary state information (i.e. yes/no or
have/don't-have or etc).  While this method does not provide the
infinite (or at least a very large) number of possibilities for every
possible printer on the market today or will be on the market in the
future; it does provide sufficient information for 90+% (95+%) of
printing need from mobile devices.   There is no dictionary (string)
parsers required.  The binary state capability data can be retrieved
from numerous sources, including the printer, will minimal overhead and
is usable by the mobile device OS, application, print manager and print
dialog.

 

I have created a couple of c code header files and following are
samples.

 

Example: 

    /************************************************************

     * StitchingType

     *

     * Whether or not to stitch and where to place the stitch. 

     * 

     ***********************************************************/

    typedef struct 

    {

       GP_BIT32 FSGJT_ST_NOT_SUPPORTED  : 1;    /* bit 0        */

       GP_BIT32 FSGJT_ST_NONE           : 1;    /* bit 1        */

       GP_BIT32 FSGJT_ST_CORNER         : 1;    /* bit 2        */

       GP_BIT32 FSGJT_ST_SADDLE         : 1;    /* bit 3        */

       GP_BIT32 FSGJT_ST_SIDE           : 1;    /* bit 4        */

    } fsgjt_stitching_type_cap;

 

In this example of a single attribute, the possible values are
translated into capability states.  Somewhere (Firmware, cloud, or etc)
the following is defined

 

    /****************************************************************/

    /*** StitchingType                                              */

    /*** ---------------------------------------------------------- */

    ptrCap->stitchingTypeCap.FSGJT_ST_NOT_SUPPORTED = 0;/* bit 0    */

    ptrCap->stitchingTypeCap.FSGJT_ST_NONE          = 0;/* bit 1    */

    ptrCap->stitchingTypeCap.FSGJT_ST_CORNER        = 1;/* bit 2    */

    ptrCap->stitchingTypeCap.FSGJT_ST_SADDLE        = 1;/* bit 3    */

    ptrCap->stitchingTypeCap.FSGJT_ST_SIDE          = 0;/* bit 4    */

 

Thus, this printer can support corner and saddle stitching.

 

To make this concept work in general, the extensible feature of the
JTAPI attribute was removed.  Mobile needs to prints and not worry about
variations upon variations.  The LF/OpenPrinting should review the now
fixed list of values for the pervious extensible attributes to determine
if the list of values needs to be updated.

 

To make this concept work, I also added MediaSizeCap.   This is a very,
very short list of the standard media size (A4, letter, legal and 4x6)
that represents 80% to 90% of printing needs.

 

But I have also defined another media header file to provide more
detailed media support.  The first definition defines the size and print
modes (graphic, text, etc versus draft, normal, high quality).  The
second extents the media type with the existing JTAPI coating type
attributes.

 

Finally, the proposed simplification allow for a much easy print dialog
and predefined job-ticket implementations.

 

I will post my c files after I do some additional testing and clean up.

 

Glen

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20110627/65ba78ce/attachment.htm