AW: [Desktop_printing] Role of CUPS and error handling

Stark, Jens Jens.Stark at
Thu Mar 23 09:14:05 PST 2006


It appears that, in order to make things "simpler" on the interface, you bl=
ame CUPS for not providing a lot of things that CUPS has no or little influ=
ence in.
Autodetection is a *relatively* simple topic when it comes to locally conne=
cted printers. YMMV, though.
Printers on the network are a totally different thing. There are a number o=
f different approaches to this - from SNMP broadcasts to Zeroconf, not to m=
ention a load of proprietary approaches. =

Manufacturers often seem to reinvent the wheel when it comes to that.
In addition, a networked printer might not be MEANT to be directly used by =
any client that is able to locate and identify it. What about print servers=
? Some of them do network->network stuff, working on the data stream in the=
 meantime ? Accounting solutions ? Follow-me printing ?

Printer autodetection on the network is

- non-trivial
- not made easier by dumbing down the interface

When it comes to error reporting, there is somewhat an established standard=
 - use SNMP.
IPP support is coming, but it needs to be simple to implement to make sense=
 to the people writing the network stuff. (And why should they do it, if th=
e corporates usually use something based on SNMP for now ?)

The major issue with CUPS interfaces is that there is more than one. SUSE d=
idn't handle this too nice.
Others have their own interfaces, instead of just using or replicating the =
CUPS web interface or agreeing on a *COMMON STANDARD*.


-----Urspr=FCngliche Nachricht-----
Von: desktop_printing-bounces at
[mailto:desktop_printing-bounces at]Im Auftrag von Ellen
Gesendet am: Donnerstag, 23. M=E4rz 2006 17:46
An: desktop_printing at
Betreff: [Desktop_printing] Role of CUPS and error handling

Hash: SHA1


In order to make printing usable, we need to make sure that the technic
works. A huge amount of the current dissatisfaction with printing is not
because of the interface, but because it something does not work (no
auto-detection, wrong driver that produces mostly blank papers with few
cryptic text, no 'ink/paper empty' notifications on most systems, ...).

Surely a less complex interface with better defaults that diminishes the
number of difficult choices a user has to decide on increase the success
rate and therefore user satisfaction. But in order to do so we need to
reduce the degrees of freedom.

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?

- - How does it perform in mixed environments (windows, linux, mac)?

- - CUPS itself may be very complex, for example when it comes to
server-client relations.
- -- Can we facilitate those concepts for the user?
- -- 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?
- -- 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)?
- - 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?

- - Assuming the above points won't cause problems, is relying purely on
CUPS the solution to concentrate on? Or are there further reservations?

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
(, I couldn't find
the error codes. Did I miss them, or are they stated elsewhere?

- - Are there guidelines for the manufacturers for the special error code


- --


Ellen Reitmayr          email: reitmayr at
Usability Engineer      mobil: +49.177.3325867
relevantive AG          fon:   +49.30.23455630
Saarbruecker Str. 38    fax:   +49.30.23455639
10405 Berlin            web:
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

Desktop_printing mailing list
Desktop_printing at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Printing-summit mailing list