[Desktop_printing] Role of CUPS and error handling
mike at easysw.com
Thu Mar 23 11:24:05 PST 2006
Ellen Reitmayr wrote:
> A crucial question is the role of CUPS in the future:
> - - Can we make sure it will be the technic of choice for the major distros?
I believe it already is, however the integration of CUPS with each
distro is different...
> - - How does it perform in mixed environments (windows, linux, mac)?
In general, it is very good. The usual problems are Samba-related
(i.e. Samba is not configured properly to work with CUPS) and are
a distro integration issue.
Mac to Linux running CUPS is a no-brainer - they both run CUPS.
There are occasional N^2 copy issues when printing from legacy
Quickdraw-based apps on MacOS X, but I believe Apple will have
this issue finally fixed in 10.5...
> - - CUPS itself may be very complex, for example when it comes to
> server-client relations.
The whole point of CUPS is to hide that complexity - printers are
automatically discovered on the network and look like local queues,
so the user a) doesn't have to configure anything and b) doesn't
have to know where the server is.
> - -- Can we facilitate those concepts for the user?
What do you mean?
> - -- Can we get rid of the notion 'server' and 'client', but simply
> connecting to printers that happen to be connected to a computer or
> directly to the network?
First, CUPS doesn't make this distinction at the user level. You
have a list of destinations that you print to. A local printer is
the same as a remote printer.
Second, a rose of any other name would still amount to client/server.
"Dumbing down" the user interface is not the answer. Presenting
the information in an understandable and/or useful way *is*.
For example, when printing a user may not care what "server" is
handling the print job, just the destination itself ("HP LaserJet
4000"). However, if there is more than one destination with that
name (very common in most businesses), the user *will* need some
additional amount of information such as the server or location
associated with the printer so that they can make a choice.
> - -- Can we make sure we don't run into trouble if the same computer
> happens to be server and client (CUPS client only versus IPP Using
> Broadcast in SUSE)?
What trouble would you run into? Like I said, CUPS doesn't make
any distinction between local and remote printers.
> - - How much of the device recognition in the CUPS web interface can be
> made automatically? When manually setting up a printer, there are many
> choices a user has to decide on (ipp, http, socket, ....). Is something
> like 'scan network' or automatic recognition when a usb printer is
> connected something CUPS can do, or is it the OS? if it's the OS, is it
> a problem for us?
As Jens has pointed out, local printer detection is pretty simple -
just enumerate the connected devices. CUPS will show the newly
connected printer, you click on "Add This Printer", confirm the
driver selection, and then you can print. 2 or 3 clicks to setup
However, network printers pose a challenge in that they don't follow
a single standard, or even a handful of standards. Every major
manufacturer has done their own thing. You can brute-force a
network scan, however that kind of scanning is generally frowned
upon and we will *not* ship software to do this in the standard
Now before Ira jumps all over me, there are some new PWG-sponsored
standards that are starting to be implemented that may make this
problem simpler in the future, however that doesn't help for
The CUPS design specifically allows for multiple protocol support,
and specifically for proxy backends which can enumerate printers
on the network using whatever protocol is desired. Printer vendors
can either supply documentation or code for discovering their
network printers, and then we can add a corresponding proxy backend
to do the device discovery. Apple already does this in MacOS X
10.4 to do Bonjour/Zeroconf printer discovery, and it works quite
well for printers that support it.
In short, local printer discovery already works, network printer
discovery needs some work still.
> - - Assuming the above points won't cause problems, is relying purely on
> CUPS the solution to concentrate on? Or are there further reservations?
CUPS provides the server or "service" part of the printing
environment. Users do not interface directly with the server,
but instead use something else - GUI applications, web interfaces,
command-line interfaces, etc.
At its heart, CUPS is designed to be extended. We provide a
common set of interfaces and programs, but in most cases it is
not used by itself, but in combination with other software.
When you print there are usually many non-CUPS components
involved: the application itself, GNOME/KDE, ESP Ghostscript,
a printer driver such as the HPIJS or Gutenprint drivers, and
often a driver-specific backend. CUPS manages the communication
between all of these things and hides the complexity from the
The user just prints.
So, even today you are not relying purely on CUPS. You are
relying on the integration of dozens of software packages to
get something printed from your application.
Printing is not easy, we just want it to look that way!
> Another aspect is error handling:
> When something goes wrong, it is crucial to provide proper error
> messages and directions how to go on. You wrote there are specifications
> for the error codes in the IPP specs and the CUPS IPP implementation
> guide. Also, you wrote that manufacturers can send their own guis for
> special error codes.
> - - In the CUPS implementation guide
> (http://www.cups.org/documentation.php/spec-ipp.html), I couldn't find
> the error codes. Did I miss them, or are they stated elsewhere?
Look to the referenced RFC's, specifically RFC 2911 for most of
Also look at the filter and backend man pages and the CUPS Book
for discussion of how you provide error messages and state feedback
to the user/scheduler.
> - - Are there guidelines for the manufacturers for the special error code
The PPD spec provides several attributes that manufacturers can
use *today* with CUPS on MacOS X to provide human-readable error
messages for their own error codes. It is up to the Linux desktop
folks to use them in their own GUIs...
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
More information about the Printing-summit