AW: [Desktop_printing] Role of CUPS and error handling

Kurt Pfeifle k1pfeifle at
Sat Apr 1 10:59:24 PST 2006

On Saturday 01 April 2006 02:26, Robert L Krawitz wrote:
>    From: Kurt Pfeifle <k1pfeifle at>
>    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, 


>    Actually, it is much, much, much more easy, thanks to CUPS.
> Not as easy as you might think. 

Maybe I should have said "CUPS-1.2". But even for CUPS 1.1 it was already 
much more easy. It really is nothing more than to provide 2 files (1 in 
the case of PostScript printers):

 * a PPD (and this file is largely the same as used for Windows -- that's
          why PostScript printing never posed a problemd with CUPS on Linux)

 * a CUPS-genericraster-to-the-printers-native-format converter

That's it; and with that, you have more than basic printing on Linux, for 
any printer type that is also sold to Windows desktop users.

I know I repeated myself here. But I did this for the record: people from
vendors may some time in the future read the archives of this list, and 
your reply to my mail may make them think it is more difficult than it is.

> Let's look at the steps in the chain: 
> 1) Compiling the driver. 

Hmmm.... looks like you are looking at it from the point of view of an
end user building from source, or from a distro packager's p.o.v.

*I* was talking about *creating* that source in the first place.  ;-)

I was talking about printer manufacturers providing printer drivers for
Linux, and what is involved for them to get those working.

(And I was not even mentioning the CUPS Driver DDK, which should make
developing such drivers pretty straightforward.)

>    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.)

Note that I was deliberately *not* addressing the issue of source
availability or not, nor that of the respective licensing.

I was only talking about the scope of the technical task. And that
is the same for each: provide a compiled "raster-to-myprinter" filter 
(source or not), drop it into the standard CUPS directory, and povide
a PPD that calls this filter. Everything else will be taken care of
by CUPS.

> 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.)

Well if Redhat doesnt provide or support PPDs in their printer setup
tool, it is their problem in the first place. Sad for their users, 
though... (But RH users could always still use a non-Redhat tool or 
the lpadmin command line to install their printer; a vendor knowing 
about this b0rkenness of Redhat printing can also find an easy way to 
work around this; plus, talk to Redhat marketing to get it fixed ASAP).

> 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.

I think that is solved in CUPS-1.2. And even for CUPS-1.1 you make it
sound harder than it is. (Note again: I talk about vendors and their 
driver developers; these are supposedly software engineers. You are 
completely right if you talk about Aunt Tillie, or my brother, tasked 
to set up an unknown printer model with no vendor CD on their parallel 
or USB port...)

> 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.

CUPS-1.2 doesnt need to be restarted to find the new PPD file. A vendor
setup knowing where the PPD is, wouldnt even need CUPS-1.1 to know the
PPD in advance, nor to restart it... (Restart of CUPS is only needed if
you add a PPD and want to make it visible in the web interface, or via
the "lpadmin -m" switch; "lpadmin -P" does always work...)

> 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). 

...and this despite of the fact that Gutenprint's installation is not
meant to support just 1 printer, from 1 vendor -- you're dealing with
a situation were you install a software that supports about 600 printer
models, from a dozen manufacturers, who do not give you any official

> 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. 

True; but CUPS-1.2 improves that. Bidi communication is a bit more
advanced than "printing with all device specific printout options". 

But "make it print" with "and support all of the device specific 
printout options" is really only the 2 files I talked about (plus,
leveraging the CUPS framework of course).

> 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. 

Which one?

PPDs *are* an accepted industry standard. Despite of all the spec's 
weaknesses. Adobe seemed to be unwilling, since many years, to add
desired features to their specification (even though not only CUPS,
but also some printer vendors desired so).

Your "generic beef" does not help. You have to deal with PPDs. A
replacement from scratch is not anywhere close, AFAICS. Should it
ever happen (because some influencial working group of hardware
vendors create one), it should be not too difficult to support it
from Linux and OSS.

Until that time, it looks to me like the proposals for the "CUPS
PPD Extensions" would do most of what you wanted in the past for
Gutenprint. And it even looks like Apple is supporting these
extensions (since I have not heard that they're keeping CUPS-1.1 
or going back to LPR/LPD...)  :-)  

> Read my 
> slides for more on that. 

I did so.

>From what I can see, your beef should have become a thing of the 
past once CUPS-1.2 is adopted by most distros, and by Apple...  :-)

> 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 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 prefer to read current lists, which center around software that
provides these functions based on CUPS, Ghostscript, Gutenprint and
the like  :-)

> 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.

I didnt say so. I mentioned PostScript and PDF printers just for 
completeness in my reasoning.

> 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.

Of course.

And CUPS, with the filters it ships itself, and with all the Free
raster-to-whatever filters provided by third parties (such as 
Gutenprint) *IS* in fact such a host based RIP, combined with
an IPP-based spooler, combined with a backward-compatible LPD-
client supporting spooler, combined with some more utilities.

Hardware vendors wanting to provide Linux drivers for their devices
do not have to do much in order to make their models work perfectly
inside that framework.

In fact I dare to claim that adding perfect printout support in
Linux to any of their models is much more easy to vendors today 
than adding perfect printout support for the same model in Windows 

>    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.

I don't agree.

>    > 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?


More information about the Printing-summit mailing list