[Omniprint-user] proposal of what features the communication to a printer driver should support

[Mark H. <ha...@us...>]

Here is a proposal of what features the communication to a printer
driver should support.

Rather than giving a list of low-level omni commands, I have provided
a high level overview.

Session management
------------------

 - The first command should be a handshaking of the versions.
 - Close the session.

Device management
-----------------

 - Enumerate all supported devices that a printer driver supports.
   NOTE:  This can either the entire list or what subset is installed.
 - Query a device's programmatic language description. (PCL, ESC/P2, PS,
HG/GL)
   NOTE:  This can allow spoolers to move jobs between similar print
queues.
 - Enumerate all devices for a language.
 - Start a print job for a device.
   NOTE: This should be a required command and should invalidate the
         session if a non-supported device should be selected.

Job Properties
--------------

Drivers should support a set of core properties.  For example, at a
minimum,
a driver should support (note: this is only a sample):
   form
   media
   tray
   resolution
   orientation
   color/monochrome

For the core properties, a driver should support a set of standardized
selections.  This will help in moving jobs between different printer
drivers that support a printer.  For example:
   form
      Here is a sample proposal from IPP/UPDF/UPnP.
        na_letter_8.5x11in
        na_legal_8.5x14in
        iso_a3_297x420mm
        jis_b4_257x364mm
        jpn_hagaki_100x148mm
      It has some good points to it:
        All forms have a name to it.  If, in the future, a new form is
          created, then a program would not know how to call a form
          that was selected with only its size (6.12x7.59 is called what?).
        More information is returned.  The size of the form is returned
          with the name.
      Some bad points are:
        Hard copy clipping information should also be returned.
   media
     Here is a sample proposal from UPDF
       stationery
       stationery-coated
       stationery-inkjet
       stationery-preprinted

The driver should also have a set of driver specific properties.

 - Set the job properties for a session.
   NOTE: I think that all the properties should be set in one command.  I
         can envision scenarios where individual sets could paint the
         driver into a corner.
         There should be default job properties if some or none of the
         job properties are set.
 - Query the current job properties.
   NOTE: This can happen both before and after the job properties are set.
 - Enumerating the job properties.
 - Enumerating the options for a job property.
 - Enumerating the type of a job property.

Printer Properties
------------------

Drivers need to know about what optional features are installed for
a printer.

Perhaps there can be a core set of printer properties.  For example,
   a duplexer is installed
   extra memory is installed
   an extra tray is installed or is configured to hold certain paper

 - Set the printer properties.
 - Query the printer properties.
 - Enumerate the printer properties.
 - Enumerate the options for a printer property.
 - Enumerate the type of a printer property.

Job Control
-----------

 - Start a job.
 - Start a page.
 - End a page.
 - Optionally change the properties for the next page.
 - End a job.
 - Abort a job.
   NOTE: I think that it is easier to abort a print job rather than
         aborting a print page.  How do you recover and still keep
         printing new pages?

Job Data
--------

Here is where you have to ask yourself:  Are you a graphics engine
that is talking to a printer driver or are you an application that
is talking to a printer driver.

If you are a graphics engine, then you will want to allow the
device to accelerate high level commands (Ex: drawing a box with rounded
corners).  Every command that is not supported at a high level will be
rasterized into a series of banded bitmaps and then sent down to the
device.  It should be drawn into the bitmap format that the device
wants  (Ex: RGB, CMYK, CcMmYK; 1, 8, 24 bits per pel; 8 or 32 bit scan
line aligned; top or bottom orientation; etc).

If you are an application, you want to print simply.  Some examples are:
   a series (1 or more) of bitmaps of any color depth
   postscript commands
   printer specific data
   plain text

Job Information
---------------

 - Query printable area.
 - Font metric information.
 - Resolution of the page.


Bidirectional information
-------------------------

 - Error reporting.  (Printer offline, busy, out of ink)
 - Device reporting.  (Printer name)

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/