CUPS: end-user usability issues

[Georgi Kuzmanov]

CUPS seems to have some usability problems from an end-user perspective.  Reading the documentation did not help me with these issues.  The currently installed CUPS version is 1.1.20, but these problems have been seen on other CUPS versions such as 1.1.19 as well.  Here is a hypothetical situation.

A user is printing from a client machine cupsclnt1 which is running cupsd and has no local printers but is connected to two print servers cupssrv1 and cupssrv2.  The first server is on the same subnet detected through a subnet local broadcast.  The first server also browses and re-exports the printers found on the second server.  All the user knows is the name of the printer or printers (s)he is printing to using the CUPS "lpr" command.  The user's print jobs are fifth and seventh in a list of nine print jobs on the queue of a printer named, for example, ljet1.  The server spooling jobs for ljet1 might happen to be cupssrv2 (not on the user's subnet), but the user shouldn't need to know that.

Missing functionality 1 ("smart"/recursive lpq)
===================================
What is the single command that the user can use from a command line to find out the list of jobs waiting to be printed on ljet1 and the order in which they will be submitted to the printer?  I have not found an answer which does not involve firing up a web browser and/or finding out the server where the job got spooled.  With other printing systems (for example, LPRng), it is enough to type:

lpq -Pljet1

but CUPS comes up with this misguiding message instead:

ljet1 is ready
no entries

apparently because it just lists the jobs in the (empty) local queue.

Yes, for the knowledgeable user there may be lengthier workarounds, such as:

- starting a web browser and going to http://localhost:631/printers and then following links to ljet1 on cupssrv2

- finding out where ljet1 is spooled and typing lpstat -h cupssrv2 -o ljet1

- finding out where ljet1 is spooled and typing CUPS_SERVER=cupssrv2 lpq -Pljet1

- (if the user has shell login on cupssrv2): ssh cupssrv2 lpq -Pljet1

but the functionality of finding the list and sequence of jobs on a printer you are using by a single command line that requires you to know just the name of your printer seems to be missing.

Missing functionality 2 (aliases or exportable printer instances)
==============================================
Only locally defined printer instances are visible clientside.  Continuing with the previous example, suppose ljet1 has four instances defined on cupssrv2:

ljet1/1 (single-sided printing on A4 paper)
ljet1/t (single-sided pirnting on A4 transparencies)
ljet1/2 (duplex/long-edge-flip double-sided A4 printing)
ljet1/2t (tumble duplex/short-edge-flip double-sided A4 printing)

these instances are not visible on the web interface or when querying the server remotely using lpstat, so instances would appear to be a client-only feature.   Short of replicating these instances in each client machine's etc/cups/lpoptions or each user's $HOME/.lpoptions , is there a way to create and "publish" instances of a printer with different settings/options?  There should be a server-side (or at least server-configured but client-visible) equivalent of instances - perhaps aliases?

There is a hack where an alias can be partially emulated using a single-member printer class, but this does not allow for different printer settings.

Creating completely separate queues is another hack but it has several disadvantages, one of which is there is no obvious single point of control/inspection for a printer and no way to list the jobs pending for just that printer.

Problematic / inconsistent functionality 3 (removing jobs from a queue)
====================================================
Our user has just five minutes to the next bus home and decides against waiting for the two submitted jobs to print out but doesn't want to waste print quota on print jobs that are likely to end up in a recycle bin by the next morning.

Trying "lprm -Pljet1 -" (BSD-style "remove all my jobs from that printer queue") keeps asking for the user's password, and, if that is entered correctly, asks again and again, until it is entered incorrectly two or three times in a row, and then gives up.  However, if the specific job id numbers are known (for example, 312 and 314), the following SysV-style commands:

cancel -h cupssrv2 312
cancel -h cupssrv2 314

seem to do the job without asking for a password even once.  If this were a server mis-configuration, I would expect both commands to work (or to fail) in the same (or at least similar) way.