[Omniprint-developer] Thoughts on Drivers, Early and Late Binding, When to Do Conversion

[Patrick P. <pap...@as...>]

Due to time problems,  I have not been an active submitter to this
list.  I would like to make some comments on some topics that have
been under discussions.

WHAT IS A DRIVER?

The problem here is that the term 'driver' is a semantically loaded
word.  In the Microsoft Windows environment,  printing is done VIA
a 'printer device',  which just happens to look very similar from
an IO standpoint to a real device.  You can send data to the device
(well, anybody with any sanity will use the graphics library:-),
and there are a well supported set of IO operations API's defined
to support them as well.

But you are really doing IO operations that magically get translated
into stuff in a file that is then sent to a printer.

To make things work right,  you need to get device parameters and
discover the magic things that need to be done in what order.  Most
of the work of the API library support is making this job easier
for the user.

One way to 'simplify' UNIX printing is to clone this type of
operation:  come up with a standard set of 'drawing operations'
and you are finished.

This is REALLY REALLY appealing.  In fact,  several systems have
been designed and papers written on how to do this in the UNIX
environment.  In fact,  some folks tried to do this VIA the X
environment,  by setting up a virtual X device that was such a
printer.  So....  all we need to do is extend the X Server so that
it has:

  a)  Open a print job
  b)  Set the 'visual characteristics' of the current 'page image'
  c)  Get the 'visual characteristics' of the current 'page image'
  d)  Throw crud on the screen^H^H^H^H^H 'page image'
  e)  Finish/terminate the current page
  f)  Finish/terminate the current 'print job'
  g)  Commit the print job to the 'printer'

The 'driver API' can then simply be the set of X library functions
that do low level graphics operations,  extended by the various
printing stuff.


EARLY BINDING and LATE BINDING

The big headache in printing is trying to decide how and when
to bind your printing job image to the printer.

Early binding:
  At the time of 'print job submission' you do absolutely everything
to nail the job/output/format/whatever to the output device.
You can,  given knowlege of the communications channel to the device,
do various things in real time,  such as request paper to be loaded,
operator to put covers into printer, etc.


  Disadvantages:
   This requires that as much information as possible,  including
   all raster conversions, data formats, communication channel
   operations, etc.,  be known to the 'early binding' process.
  
  Advantages:
   The print job generator can take advantage of special device options
   that are available to her.

Late Binding:
  As little as possible is done to make the print job depend on the
output device.  In fact,  some sort of 'generic print job' format
is used,  and then the last stage in the printing process will
convert this to the output format and/or commands compatible
with a specific printer.

  Disadvantages:
   You need a special 'generic language' that does not depend
   on the printer,  and conventions about 'format requests'
   and 'print job options' to be passed as part of the print
   job.
  
  Advantages:
   You do not need to have intimate knowledge of the printer,
  just of the &*(()*& 'generic language'.

What is Best?

That depends on what you are doing.  HOWEVER...  I like the
following:

a) Bind the 'graphical image size' as early as possible.
   That is, generate your print jobs with intimate knowledge
   of the graphical image size.

  This means:
    'select page size and printable area first' 

b) Do paper or media selection as LATE as possible.
  That is, pass requests for paper type, paper size
  (actually, you may need to do this together with a)),
  duplex, finishing, etc., as late as possible.

   This means:
     'do not embed these options in the output from a)'

c) Do rasterization, font selection, etc. etc., at the most
   appropriate point.  This can be done AFTER a) or AFTER b)

Initial Submission Does Raster 
   NEED: page size (generate image + rasterize)
      OUTPUT:  'raster for device'
       ->  Late binding media selection stuff
          -> device
       Note - this makes a lot of sense for devices that
   do not do rasterization or whose basic rasterization
   stuff is terrible.

      Example:
        Images -> raster for some printers
            (Gimp folks do a great job here)


Initial Submission Does Generic  
   NEED: page size (generate image in 'generic format')
      OUTPUT:  'generic format'
       ->  Late binding media selection stuff
          -> device
              -> device does rasterization

     Example:
       text -> PostScript
         (Font definiitions added to the job)
           ->  Late binding media selection stuff
              -> device
                 Postscript interpreter in device
                 does rasterization

But really,  we want the ability to do both:

Initial Submission Does Generic +
   Middle Does Raster
                
   NEED: page size (generate image in 'generic format')
      OUTPUT:  'generic format'
       -> Raster converter and fixer upper
          ->  Late binding media selection stuff
             -> device

This is the model that is used for most GhostScript
based converters - you generate the job in PostScript,
fling it at a conversion system^H^H^H^H^H^H print spooler,
the conversion system does the rasterization based on the
output device it will choose to print the job on,
and then send it to the device.


I think that there is a need to support all three of these
models in whatever folks propose.
Patrick Powell                 Astart Technologies,
pap...@as...            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   858-874-6543 FAX 858-279-8424 
LPRng - Print Spooler (http://www.lprng.com)