AW: [Desktop_printing] Role of CUPS and error handling

[Robert L Krawitz]

   From: Kurt Pfeifle <k1pfeifle at gmx.net>
   Date: Fri, 31 Mar 2006 22:43:07 +0000

   On Friday 31 March 2006 21:11, Bastian, Waldo wrote:
   > >Hello,
   > >
   > >On Mar 30 12:32 Ulrich Wehner wrote (shortened):
   > >> most people know how to set up a printer under windows
   > >
   > >Of course:
   > >Insert the printer manufacturer driver CD and follow the instructions.
   > >
   > >Where are the printer manufacturer driver CDs for Linux?
   > 
   > I think that's a very good question that I would like to hear answers on
   > at the printing summit. I suspect that the answer from many vendors will
   > be that it is very difficult to write drivers for Linux that work out of
   > the box across different distributions, 

It really isn't that difficult to write the code, in my opinion.  The
hardest part about "out of the box across different distributions" is
the different administration tools provided by vendors.  We
(Gutenprint) provide PPD files that we know work with CUPS, but people
still have setup problems and we still have to deal with
<insert_vendor's_choice_of_tool>.

   Actually, it is much, much, much more easy, thanks to CUPS.

Not as easy as you might think.  Let's look at the steps in the chain:

1) Compiling the driver.  If it's sensibly written, configure; make;
   will work on any POSIX-type system.  It's not particularly hard to
   make the PPD files install in the correct place, either.

   (Note that I'm deliberately not addressing the issue of
   proprietary, binary-only drivers.  I don't think that as an "Open
   Source Development Lab" forum we should be particularly encouraging
   binary-only drivers.  Aside from philosophical issues that people
   won't agree on, there's the practical problem that "binary-only"
   drivers for platforms other than Windows and the Mac tends to mean
   "Linux+glibc 2.3/x86-only", whereas the actual ecosystem is a lot
   richer than that.  There are other at least somewhat open source
   platforms: Linux/x86-64, *BSD, x86/Solaris, SPARC/Linux,
   SPARC/Solaris, and so forth, and there are older versions of Linux
   floating around.)

2) Installing the PPD files and driver binaries: again, make install
   tends to work for reasonably well-written packages.  Even if not,
   it's not too hard to find the CUPS PPD source directory and driver
   directory and plop the necessary things down there.

   (Of course, if the distribution is based on Foomatic rather than
   native CUPS drivers, this breaks.  The PPD files will install, but
   the distribution printer management tools won't see them.)

3) Finding the printer.  This gets harder.

   Different distributions/operating systems use different naming
   conventions and different ownerships for printer devices.  There's
   still the problem that if the printer's not turned on when CUPS is
   started it isn't visible to CUPS.

4) Bouncing CUPS to get it to recognize the new PPD file.  This is
   somewhat vendor-specific; for starters, BSD-init systems do it very
   differently from sysvinit-based systems.  Service management seems
   to be an area for vendor creativity, also.

5) Helping the user configure and install the printer.  Now things get
   really interesting, due to the variety of vendor-specific tools for
   printer administration.  We had that little discussion yesterday
   :-).

   If the distribution's tools simply use the CUPS data in /etc/cups
   for everything it won't be too bad (issues of file ownership and
   tool unfamiliarity aside), but if the tools create the CUPS data
   from somewhere else (which I think at least some distributions do),
   we're back to a Foomatic-type problem.

Gutenprint gets away with doing only (1) and (2).  We do provide an
upgrade tool (cups-genppdupdate), which knows about Gutenprint PPD
files, but still tells you at the end to restart cupsd.  For OS X, we
also provide a setup tool, but it doesn't seem to be entirely robust.

   A printer driver developer for a particular model does need to
   provide only 2 files, at most, to make his non-PostScript device
   work with Linux (and more OSes, like Mac OS X):

    * a "raster-to-my-proprietary-format" converter/filter. This one
      could take its input from CUPS, which provides the well-defined
      "CUPS-raster" format. Just throw anything that is printable (in
      the widest sense of it) -- ASCII Text, PostScript, PDF, JPEG,
      PNG, GIF, HP/GL, TIFF, Sun-Raster,..... and more -- to it.  CUPS
      then takes care to convert that input into its own generic
      raster format, that is geared to satisfy any needs a printer
      vendor may have. From that point on, take over from CUPS (plug
      the "raster-to-my-proprietary-format" converter into the CUPS
      filtering chain).

It's a bit harder than that if you want to do bidirectional
communication with the printer.  A lot of Windows users are used to
their printer status panel and regularly complain to us that either we
don't provide one or that the generic Epson panel doesn't work with
Gimp-Print/Gutenprint on the Mac.  Actually, it's a lot harder than
that: the back end has no channel to the user other than through very
simple status messages delivered through the CUPS log which CUPS knows
how to interpret.  It could be done through something like mtink
(which is Epson-specific, but vendors could write their own), but it
gets messy.

    * provide a PPD that contains a) all printer specific options to
      be presented to the user, plus b) the code that makes the device
      do what it is asked, and last, c) the statement that tells CUPS
      about the "raster-to-my-proprietary-format" filter to be applied
      after CUPS' filtering is ready with its generic raster.

I won't get too far into my generic beef with PPD files here.  Read my
slides for more on that.  I do think that we want to be moving toward
an architecture that doesn't restrict us to very simple options.  If
you read high-end printer lists (such as the old
epson-inkjet at leben.com list, which unfortunately disappeared several
years ago) you'll read about all kinds of very expensive, extremely
proprietary third-party RIP's that were written to get around
limitations in the vendor-supplied drivers.  I don't want to force
users to either have to settle for basic adjustments or buy
expensive proprietary programs to drive their printers.

   Call these 2 things a "driver" if you want.

   For PostScript or PDF consuming devices, the first item obviously is 
   not needed at all.

Very few if any low-end devices handle PostScript or PDF directly, and
I don't see that changing.  Including a RIP inside the printer costs
money; it's cheaper to just do it on the host.  I think it's generally
preferable, too; it's easier to upgrade or add new features that way.

   But they should already know this by now; most vendors do already offer
   "drivers" for Mac OS X (not for all devices, though).

   The item "insert the manufacturer CD" feature is still a desireable 
   thing: it would reassure the user that the "driver" he is going to
   install now is indeed the vendor recommended one (and guaranteed to
   work).

As I explained above, it's tough to guarantee that on anything more
than a distribution-by-distribution basis as it is.

   > and if that is indeed the case 
   > then I think that we should use the Printing Summit to start addressing
   > that problem. LSB today offers great standards to start from, can we
   > identify the additional missing pieces that would be needed to provide
   > printer manufacturers with a set of APIs that they can rely on when
   > providing their Linux drivers?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton