[Omniprint-developer] printer driver interface

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

I was thinking about what is necessary to implement a generic application
or
rendering engine to printer driver interface.  This is based on a
comparison of
some of the features that are in Omni's implementation of IJS and
Ghostscript's
implementation of IJS.

Setting the device name
-----------------------

The manufacturer and model name should be required as one of the first
commands that are sent.  It is the only way to know what device information
to use.  There will be instances where the user would like to select the
driver that they want to use to send output to a device.  In these
instances, the device should be selectable.  This flexibility could be
needed if the printer had the ability to support multiple personalities and
the user would have liked to select one of the personalities (typically
driver/ language related) prior to printing the job

   IJS seems to get the device name from a bidi query.  Therefore, it is
      optional and may not work if bidi is not supported.
   Omni has multiple printer drivers underneath and uses the device name
      to choose which driver to select.  The device name is required.

Querying information about the printer
--------------------------------------

Some spoolers may want a programmatic way of querying the printer driver's
language.  This is useful to find a matching or compatible printer driver
for functions like moving a job between print queues.  Reference previous
item "Setting the device name"

   Omni can describe its device in terms of a PDL (Page Description
Language).

Setting Job Properties
----------------------

Job properties should be grouped into two sets.  The first set should be
common between all drivers.  This includes the name of the form and the
tray.  The second set is printer driver and device specific.  Currently
there is discussion about a SET_PARAM and GET_PARAM but no clear definition
as to their use.  Typically a drivers state is set in one pass so singular
settings are not needed.  With the SET_PARAM it implies that the driver can
set individual parameters and there is no guarantee of a tie in to all the
parameters since some may get defaulted disallowing others set by the user
to be valid.

   IJS supports form size, dpi and print mode.
   Omni supports form, tray, media, resolution, dithering, print mode, and
      device specific options.

Enumerating Job Properties
--------------------------

Print dialogs need to be able to enumerate every settable job property.
For
each property, it needs to be ably to query it type, range, and default.

   IJS may support it through IJS_ENUM_PARAM.  If the device name is
unknown,
      then it could only return general instead of specific information.
   Omni supports enumerating all job properties that are specific for a
      particular device.

Querying Job Properties
-----------------------

An application needs to be able to query specific information about each
job
property.  From the current proposal, the interface is for the renderer to
setup the driver.  This concept needs to be extended to allow the
application the ability to know about the output page and format the output
for correct placement within the page boundaries.

   Omni will return all the information about a property that it does
through
      the old method of interacting with applications.

Form name as Job Property
-------------------------

There should be a grouping of the form, tray, and media in the print job.
These should be set all at once and not individually.  In many
environments,
people configure a form name based on the form size, color, and finish
option.  The form name will tie all these parameters together to allow for
the selection of specifically what the user wanted which many times will
tie
into changes that are needed for the color management, paper handling, and
tray selection functions.  Also, constraint logic needs the form name.

   IJS uses a Postscript W.WWxH.HH description.  Custom forms with the same
      size may have problems.  The paper size can be unknown in the common
      case.
   Omni is using a new standard that is common with IPP, UPDF, and UPnP.

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

Each job should be associated with a new instance of or connection to the
server.  Multiplexing between different print jobs in one stream will
serialize the processing.

   IJS is page oriented.
   Omni is job oriented.  Job properties can change on a page by page
basis.

Job data
--------

An application can print individual bitmaps easily.  However, there is a
lot
of work involved in formatting the input bitmap data to a printer driver.
The entire printable area of the page must be broken up into sections to
lessen the memory requirements.  Sometimes, the printer driver needs a
multiple of rows to generate print data so the band size must be a multiple
of the print head size.  Also, the things that are drawn on the page by an
application will have to be journalled.  That is recorded and played back
(with appropriate offsets) for each band on the page.  In memory
constrained
devices or when doing higher performance printing, the utilization of a
page
location and direction for the bitmap can greatly increase the performance
of printing the job along with reducing substantially the amount of memory
needed to render the output since a complete band is not necessarily
needed.

   IJS sends only a banded page bitmap.
   Omni supports a generic bitblt mode and a banded page bitmap mode.

Mark

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