[Omniprint-user] Re: [printing-driver] Re: [printing-cap] Re: [Inkjet-list] Re: Taking a step back

[Michael S. <mi...@ea...>]

On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote:
> ...
> This all really depends on what set of problems you want to solve.
> If you look at several scenarios it will better define the components
> that are needed and the way you could handle most of the scenarios.
> We need to handle:
> -  Device configuration information dynamic from the printer
> -  Status information returned from the printer
> -  Local configured printer
> -  Network configured printer

I would argue that we do not want to distinguish between a local and
network printer.  All printers should be treated the same, and an
application that communicates with a local print queue should be
able to access a network print queue the same way.  Again, I'm
harping on network transparency!

> 1. Local printer configuration and capabilities
>
>   The local printing (single user) scenario is fairly easily handled
>   when utilizing IPC mechanisms.  Latency and information about the
>   printer go away in this scenario because you don't have to worry
>   about the 100 user scenarios.

I would argue that even a single user will have multiple windows, etc.
open that want to access a printer at the same time, especially to
check the current status.

>   Information does not necessarily need to be statically maintained
>   unless the printer does not handle bi-directional information
>   that fully describes its configuration.  If the printer does not

Most printers cannot "fully describe" their configuration.  The smartest
inkjets provide a model ID (which often is too general to be of use),
installed inkset, paper status, and ink levels.  That is enough if you
know which driver to use, etc., but not which variety of ESC/P, PCL,
etc. to use, and what capabilities the printer has.

> ...
>   It can be done by reading a PPD or it can be done by calling a
> printer driver and getting the current information back.  In either
> scenario, it would be a very good idea to have an API that can return
> the information in a STANDARD format to a calling application.  It

Right, and currently the best match for that "standard" format is a
PPD file, which is supported by a lot of applications and adequately
describes most options.  I'm not saying PPD is the best format in
the world (there are many issues, and I'm quite sure that Adobe would
be interested in addressing them in a new rev of the spec), but it
is the best supported format, both under Linux and other operating
systems.  It is also already in use in all of the scenarios that have
been brought up.

> ...
>    Local printer status information
>
>   When doing local printing, the status should be immediate and any
>   device specific protocol converter (daemon) of the data be manage
>   the flow to and from the printer to always maintain an accurate
>   account of the status of the job and printer state.

The device daemon should *not* try to understand the data to/from the
printer, nor should we expect it to track printer or job status.
Specialization leads to bloat and all sorts of implementation problems.

> ...
>   - An IPC mechanism for getting dynamic information from the driver
> and subsystem will be mandatory for licensing purposes.  It would
> likely be simpler if a singular interface could be used by both an
> application and the renderer.
> ...

I would argue that an IPC mechanism at the application level has
already been defined and implemented - IPP.  Between driver and
device, the interface to use is the pipe/socket: that abstracts
the device IO into simple modules that can be reused for many
drivers and devices.  The printer-specific stuff is then handled
entirely by the printer driver, which has to be specialized...

As for licensing issues, simpler public interfaces eliminate this
problem - if a vendor doesn't like the license the "standard"
implementation uses, it can roll its own interfaces.  The TurboPrint
folks do this for their CUPS drivers, for example, since they don't
want to link to the CUPS imaging library (which is GPL'd, while the
rest of the CUPS API is LGPL'd...) to read the raster data.  Instead,
they rolled their own read-header/pixels code.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com