CUPS: end-user usability issues

[Michael Sweet]

Georgi Kuzmanov wrote:
> ...
> 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.

With LPRng, it actually talks to the remote server, since in this
scenario you would have told it to send all jobs for ljet1 to the
remote server (and only that server - no failover, no auto-discovery,
etc.)

With CUPS, each client has local queues which hold the job for that
system; the local jobs are forwarded to a server for printing when
that server is ready for them.  This method ensures that print files
are not lost if a server goes down, and allows us to provide failsafe
and load-balanced printing "for free".

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!

In short, we can't provide a live, global view of a shared queue
because there is no central queue.  About all we could do is see
that a remote job is printing and perhaps then query the server to
see the ranking on the server (e.g. "spooled to server, 2nd job in
server queue") for that job.  Similarly, if a remote printer is
processing, we can (and do) show that it is printing job such-and-
such, even if that job is not local.

We do understand the desire for network-wide job tracking/status,
and we are working on tools and changes that will support that in
CUPS 1.2, however the core functionality provided by lpq/lpstat
probably won't change because there is no central queue or
respository of job information.

> Missing functionality 2 (aliases or exportable printer instances) 
> ==============================================
 > ...
> 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 no way to publish printer instances on a network at this
time.  You can use tools like NIS and rsync to distribute a standard
/etc/cups/lpoptions file to client machines, however we don't have
a standard CUPS mechanism in place to do that.

> 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.

This limitation will be gone in CUPS 1.2, since you'll be able
to define -default attributes for all job options, and these
attributes will be used for all incoming jobs.

> 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

The "lprm -Pprinter -" command uses the IPP_PURGE_JOBS operation,
which is only available to adminstrative users.  You can pass job
IDs on the command-line to cancel specific jobs, or pass none to
cancel the current job.

CUPS 1.2 will add a new IPP operation to cancel all jobs for a
specific user without requiring admin privs (the IPP_PURGE_JOBS
operation also removes the job history, which is why it is an
admin operation)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com