AW: [Desktop_printing] Role of CUPS and error handling

Johannes Meixner jsmeix at
Mon Apr 3 05:15:29 PDT 2006


On Apr 1 15:20 Robert L Krawitz wrote (shortened):
> From: Kurt Pfeifle <k1pfeifle at>
> > On Friday 31 March 2006 21:11, Bastian, Waldo wrote:
> > > 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,
>    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
>     * a CUPS-genericraster-to-the-printers-native-format converter
>    That's it; and with that, you have more than basic printing on Linux

There is one file missing:
The manufacturer's setup program on his driver CD.

You many now think "Nooo! Not even more setup tools!"
But let me describe: 

A manufacturer's driver CD contains only the following files:
* setup program
* for each supported language a PPD file
* for each supported architecture a ready-to-use-compiled
  CUPS-genericraster-to-the-printers-native-format filter program

In the printer box and on the CD there is a nice printed text
how the user can run the setup program from the CD for the
various Linux distributions.

The setup program does the following:

Test the architecture ("uname -a" may help)
and if the architecture is not supported by the manufacturer's
driver, tell the user in the user's language (according
to the user's locale setting) that he has bought a printer
from a manufacturer which doesn't want to get his models
supported on any architecture by providing free driver sources
and that the manufacturer is neither interested in a free driver
nor in the user because he has already paid his money ;-)

Test that the effective user id is 0
otherwise tell the user in the user's language
that he must switch to root before running the setup program.

Get argv[0] to know the path to the setup program
from which the path to the PPD file and to the
filter program can be derived.

Test where the CUPS backends are installed:
Test the various locations for the various distributions
(first of all try to use cups-config, then test a list of
well known directories like /usr/lib[64]/cups/backend/
or /usr/local/ to detect even for self-compiled CUPS)
and if all fails it may run "find" and if even this fails
it shows an explanatory error message (perhaps there is
no CUPS installed at all) in the user's language and exit.

Run the matching CUPS backends (normally only parallel and usb)
to find the printer and remember the DeviceURI which is shown
by the CUPS backend.
If the printer is not found show an explanatory error message
(perhaps the printer is not switched on or the system should
be rebootet with the printer switched on to get kernel modules
loaded automatically) in the user's language and exit.

Test where the CUPS filters are installed:
Test the various locations for the various distributions
(first of all try to use cups-config, then test a list of
well known directories like /usr/lib[64]/cups/filter/)
and if all fails run "find" and if even this fails
use an appropriate /usr/local/ or ~$USER directory
as fallback.

According to the architecture install the right filter program
into the directory which was determined in step 6.

Generate a queue name (normally derived from the model name
but test whether such a queue already exists) and run
lpadmin -p <queue name> \
        -v <DeviceURI from step 4.> \
        -P <path from step 3. / language from step 1 / file.ppd> \

Note the basic idea behind it:

A manufacturer does not need to care about the printer installation
tools of the target system - it is perfectly allowed when the
manufacturer provides its own printer installation tool provided
this tool sets up a queue in compliance to CUPS.

Of course the manufacturer tool may also install the PPD(s)
in two similar steps like step 6. and 7. or it may even install
the tool itself - I only wanted to point out that this is not
required to set up a queue via a manufacturer driver CD.

Finally note that a manufacturer tool on a manufacturer driver CD
can avoid any user-dialog (except for error conditions) because
this tool knows for which exact printer models it is made
and it knows (via arfv[0]) the file locations on the CD.

Normally all the user would have to do is to switch to root
(no problem for those users who are allowed to install a
new printer queue on their computers) and run the tool.
Then normally all happens full-automated when there are
no hard errors.
I cannot imagine any problems regarding usability here.

> Ulrich was talking about something quite different: setting up a
> printer in Windows is "Insert the printer manufacturer driver CD and
> follow the directions".  Depositing the files in /usr/lib/cups/filters
> and /usr/share/cups/model doesn't get you there: there's still the
> matter of discovering the printer and creating/configuring the queue.
> And there's also the little matter of doing it as root, which may seem
> trivial to us but which may not be to some people.

I may have missed something in my proposal above but I don't see
why it cannot work in general.

> Does CUPS (1.2) automatically detect that the new PPD file has been
> installed

Not needed for a manufacturer's driver on a manufacturer's CD.
See above:
Don't install the PPD but use it directly from the CD.

> >  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...
> Again, I'm going back to what Ulrich and Waldo were talking about:
> Waldo said (and I agree with him) that he thinks that a lot of vendors
> think it is very difficult to write drivers for Linux that work *out
> of the box across different distributions* (my emphasis).  Red Hat's
> printing architecture may be borked, but that doesn't help their users
> and customers will still blame the printer vendor for it not working. 

A manufacturer's setup tool can ignore whatever there is broken
with whichever other setup tools.
It would only fail if the CUPS installation is broken.

> > 3) Finding the printer.  This gets harder.
> >    Different distributions/operating systems use different naming
> >    conventions and different ownerships for printer devices.

If you mean /dev/lp0 or whatever/there/is/for/USB with "printer devices":
There is no need to care about the low-level device name.
Simply run the matching backend and rely on its URI output.
This is also true if the manufacturer provides its own backend
(which will be installed in two similar steps like step 6. and 7.
and additional similar steps to determine how to re-start the cupsd
and then actually re-start the cupsd) - in the end it is the same:
Run the matching backend and use exactly the URI which it outputs.
If the backend doesn't find the printer, it cannot work at all
(regardless of any low-level device detection) - therefore the
explanatory error message and exit in step 5. above.

By the way:
I described our point of view regarding drivers from manufacturers:

In particular note our point of view regarding non-free drivers.
Note that we regard it as perfectly o.k. when a manufacturer does not
provide a free driver but on the other hand we expect that everybody
accepts our point of view that we decide which drivers we like to
support out-of-the-box and which we don't like.
If a manufacturer pays us for our efforts, we can integrate almost
everything into our products ;-)

Kind Regards,
Johannes Meixner
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at
90409 Nuernberg, Germany                    WWW:

More information about the Printing-summit mailing list