[Omniprint-developer] proposal of what features the communication to a printer driver should suppor

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

I propose to call this communication PDC for Printer Driver Communication.

If you want to start coding testcases, the omni driver supports this
proposal.  The source code is freely available and is located at
http://www.sourceforge.net/projects/omniprint/ under the following files:
   OmniServer.[hc]pp, OmniPDCProxy.[hc]pp, DeviceTester8.cpp,
   PrinterCommand.[hc]pp

What license should this code be under?  We can rerelease it under any
license that the group decides.

I also propose that an equivalent linked library version header file of this
communication format be defined.  This should be easy to create if the
group agrees.

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

PDCCMD_INITIALIZE_SESSION "Version"
   The first command should be a hand-shaking of the versions.
   A good response is:
      PDCCMD_ACK "Version"

PDCCMD_TERMINATE_SESSION
   Close the session.
   There is no response.

PDCCMD_IS_CMD_SUPPORTED cmd
   This command exists so that a client can query if a server supports a
   command.  This provides more information/granularity than the version
   string.
   A good response is:
      PDCCMD_ACK

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

PDCCMD_ENUM_DEVICES [PDLLevel PDLSubLevel PDLMajorRevisionLevel PDLMinorRevisionLevel]
   Enumerate all supported devices that a printer driver supports.
   You can optionally pass in a set of PDL information to match against.
   You receive a space separated list of device names.
   NOTE:  This can either the entire list or what subset is installed.
   A good response is:
      PDCCMD_ACK "Brother.Brother HJ-100i ..."

PDCCMD_SET_DEVICE_NAME "DeviceName"
   Associate a device name to the communications.  This is a required command
   for the rest of the following commands in this document.  This must be
   the name of a supported device.
   A good response is:
      PDCCMD_ACK

PDCCMD_GET_PDL_LEVEL
PDCCMD_GET_PDL_SUBLEVEL
PDCCMD_GET_PDL_MAJOR_REVISION_LEVEL
PDCCMD_GET_PDL_MINOR_REVISION_LEVEL
   Query a device's programatic language description. (PCL, ESC/P2, PS, HG/GL).
   This of course is a proposal of a simple way to determine a printer driver's
   language.
   NOTE:  This can allow spoolers to move jobs between similar print queues.
   A good response is:
      PDCCMD_ACK integer

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.

PDCCMD_SET_JOB_PROPERTIES "JobProperties"
   Set the job properties for a session.  The job properties is a space
   separated list of key=value entries.
   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.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_JOB_PROPERTIES
   Query the current job properties.  This returns a list of common and
   driver specific job properties.
   NOTE: This can happen both before and after the job properties are set.
   A good response is:
      PDCCMD_ACK "orientation=... form=... tray=... ..."

PDCCMD_LIST_JOB_PROPERTY_KEYS
   Enumerate the set of common job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "orientation form tray ..."

PDCCMD_LIST_DEVICE_JOB_PROPERTY_KEYS
   Enumerate the device specific job properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "scaling ..."

PDCCMD_GET_JOB_PROPERTY key
   Enumerate the options for a job property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "landscape portrait ..."

PDCCMD_GET_JOB_PROPERTY_TYPE key
   Enumerate the type of a job property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string portrait"

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

PDCCMD_SET_PRINTER_PROPERTIES "PrinterProperties"
   Set the printer properties.
   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 printer properties if some or none of the
         printer properties are set.
   A good response is:
      PDCCMD_ACK

PDCCMD_QUERY_CURRENT_PRINTER_PROPERTIES
   Query the printer properties.  This returns a list of common and
   driver specific printer properties.
   NOTE: This can happen both before and after the printer properties are
         set.
   A good response is:
      PDCCMD_ACK "duplexer=... memory=... ..."

PDCCMD_LIST_PRINTER_PROPERTY_KEYS
   Enumerate the common printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "duplexer memory ..."

PDCCMD_LIST_DEVICE_PRINTER_PROPERTY_KEYS
   Enumerate the device specific printer properties.  This returns a space
   separated list of key entries.
   A good response is:
      PDCCMD_ACK "stapler ..."

PDCCMD_GET_PRINTER_PROPERTY key
   Enumerate the options for a printer property.  This returns a space
   separated list of value entries.
   A good response is:
      PDCCMD_ACK "on off ..."

PDCCMD_GET_PRINTER_PROPERTY_TYPE key
   Enumerate the type of a printer property.  This returns the type followed
   by the default optionally followed by the minimum range and the maximum
   range.  The type can be the following: integer, string, float, or
   boolean.  This is only a proposal.  Comments are welcome.
   A good response is:
      PDCCMD_ACK "string on"

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

PDCCMD_BEGIN_JOB
   Start a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_START_PAGE
   Start a page.
   NOTE: You can optionally change the properties for the page by calling
         PDCCMD_SET_JOB_PROPERTIES "JobProperties" before this command.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_PAGE
   End a page.
   A good response is:
      PDCCMD_ACK

PDCCMD_END_JOB
   End a job.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_PAGE
   Abort a page.
   NOTE: This is optional.  If this fails then one must abort the
         entire page.
   A good response is:
      PDCCMD_ACK

PDCCMD_ABORT_JOB
   Abort a job.
   NOTE: This is required.
   A good response is:
      PDCCMD_ACK

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

PDCCMD_MODE_IS_RENDERER boolean
   This command indentifies to the printer driver that a renderer is
   talking to it.  This command is optional.  The default is false
   (an application is talking to it).
   A good response is:
      PDCCMD_ACK

PDCCMD_ATTACH_BUFFER1 id
PDCCMD_ATTACH_BUFFER2 id
PDCCMD_DETACH_BUFFER1 id
PDCCMD_DETACH_BUFFER2 id
PDCCMD_RASTERIZE
   These commands are shared for printing a series (1 or more) of bitmaps
   of any color depth and for a series of banded bitmaps of the page.
   The first is a structure that describes the bitmap data.  It contains:
      cx             - the width of the bitmap data
      cy             - the height of the bitmap data
      cPlanes        - the number of planes in the bitmap
      cBitCount      - the color depth of the bitmap
      ulCompresstion - the compression of the bitmap data
      cclrUsed       - the number of colors used in the bitmap
      cclrImportant  - the number of colors that are important
      argbColor      - the color table if there is one
      We should add a bitmap type field that contains the alignment
      and direction.
   The second contains the bits of the bitmap.
   First the client attaches both buffers, then it will call
   PDCCMD_RASTERIZE.
   A good response is:
      PDCCMD_ACK

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

PDCCMD_ TBD
   Query printable area.

PDCCMD_ TBD
   Font metric information.

PDCCMD_ TBD
   Resolution of the page.

Capabilities Information
------------------------

This section is for applications or dialog code that wants to know what
the capabilities are for a device.

PDCCMD_IS_ORIENTATION_SUPPORTED id
PDCCMD_IS_FORM_SUPPORTED id
PDCCMD_IS_TRAY_SUPPORTED id
PDCCMD_IS_MEDIA_SUPPORTED id
PDCCMD_IS_RESOLUTION_SUPPORTED id
PDCCMD_IS_PRINT_MODE_SUPPORTED id
   This says if an id is supported for the current printer that has been
   associated to the communications
   A good response is:
      PDCCMD_ACK

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

PDCCMD_ TBD
   Error reporting.  (Printer offline, busy, out of ink)

PDCCMD_ TBD
   Device reporting.  (Printer name)

Mark

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

[Omniprint-developer] proposal of what features the communication to a printer driver should suppor

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