CUPS: end-user usability issues

[Georgi Kuzmanov]

Kurt

pipitas wrote:
> m.stonebank at surrey.ac.uk wrote:
> > In a business/educational/realworld environment, people don't want their
> > print job sitting on their local box for x number of hours when the print
> > server is down.  They want their printout NOW.
>
> This truely is the case in *some* or even *most* environments.
Even if not "most", at least "many" should be enough to make the point - that there is useful functionality missing from the presently available versions of CUPS that is important to a reasonable proportion of its user base.  Even "corner cases" or "niche applications" should not necessarily be ignored, but sometimes that is just not practical because it is impossible to be all things to all people and if ten people in the whole world want "feature X" that badly, they can probably write it themselves.

However, it is not an unreasonable expectation or a corner case, given a destination (instance/printer/class name), to be able to use a single command to locate print jobs that are still "in transit" within the local CUPS system, or at least in any portions thereof that can be queried directly by the client machine.

> > They want to see the state
> > of the print server to see if its up, if it has a large queue.
>
> They can do this with CUPS if they are interested.
>From the command line - with some difficulty.  They have to be familiar with the printing mechanism of CUPS, then find the chain of CUPS servers their print job is likely to traverse, and then list each individual queue.

Alternatively, they have to use a web browser and point it to the correct URL.

> > That way
> > if there is a problem, they can decide to print elsewhere.
>
> They can do this with CUPS if they are interested.
Yes, they can.  But finding that the problem lies with that particular printer and not with your local subnet CUPS server (whose identity you don't necessarily know) might be a bit difficult.

> > The state it is now, you print and wait and wonder.
>
> No -- even now you can query local as well as remote CUPS
> servers for the jobs they have queued. Please have look at
> the man page and the "-h" parameter" for lpstat. (I am sure
> you already know about the web interface too). -- Admittedly
> this is not yet the most userfriendly way to get the info.
> In an ideal world a user would type (or click the analog
> action in a GUI) "where is my last printjob now?" and get
> the answer: "it was send off your workstation 7 minutes
> ago to spool to printserver XYZ. XYZ forwarded it to server
> ABC, where it is currently ranked as the 5th job to be printed
> on printer 123".
>
> So what are you doing to help implement such a user-friendly
> printing system?
I am reporting a genuine shortcoming of the existing CUPS system.  This can, in fact, be a sufficient contribution from a system's end user.  However, I have gone one step further and posted a sample implementation (STR#988) of a traversal like the one you mentioned above.  It is a proof of concept, not a finished feature, but it demonstrates job tracking does not have to be a long and complicated process under CUPS.

> >> One side-effect of this architecture is that users won't see the
> >> server queue state, however even if we changed lpq/lpstat to query
> >> the remote server you still wouldn't have a true queue status since
> >> the server queue will not show all of the jobs that are queued on
> >> other clients at the same time!
This is correct.  But it is possible to find and query any CUPS servers donwstream of the particular client's local cupsd.  In many (most?) cases this is sufficient for the task the user/administrator has in mind.

>
> If you want things behave like LPRng -- use LPRng.
There is no need to get defensive at the first mention of another UNIX printing system.  LPRng is a mature printing system and there are some things that it gets right.  For example, if the printer name you are querying is in fact a bounce queue, LPRng lpq does not say "yep, the local bounce queue is still accepting jobs and there are no jobs stuck in the local spool directory" and then unhelpfully shut up.

It dutifully trundles along to the bounce target queue on the server, traverses any further bounces found there (following them to a second, third and fourth server if necessary), and finally lists any jobs waiting in the final queue running up to being sent to the appsocket port or the parallel port of the printer or the carrier pigeons.  It also prints a rough approximation (in %) to the proportion of the job being printed that has already been sent to the USB port / parallel port / 9100/tcp.

If one of the queues along the way admits it is in a bad state, lpq prints a one-line summary of the latest error condition which is sometimes useless, but frequently saves the administrator having to go through log files to find out what/where the problem is.

I am not saying any of this to disparage CUPS.  There are many aspects in which CUPS is an improvement over alternative printing systems.  I believe there is no architectural reason for CUPS to be incapable of doing all of the above.  It just hasn't been implemented yet.  I would like to help make CUPS superior to its alternatives, and I cannot do that if all I get in response is "don't use CUPS then!"

Cheers,
Georgi