[cups.general] Can CUPS pass through the printer status somehow

[Johannes Meixner]

Hello,

On Dec 13 17:52 Ambrose Li wrote (shortened):
> Maybe this is a "feature" request, but I wonder if CUPS can somehow
> pass through the remote printer's status. This must be doable, at least
> for some backends, because all lpr-based systems do such a thing.

LPR/LPD-based systems cannot do it based upon the LPD protocol
because the LPD protocol knows only about queues (a queue is
the software representation of whatever there is outside of the
machine which we usually call a "printer").

When you want to get the status of a printer, you must use software
which knows how to ask the printer for its status.

In general printer state stuff is very model specific.
Each kind of printer models report their state (e.g. busy/idle,
online/offline, out of paper/ink/toner, paper jam, ...)
in various different ways (see my other mail with the
subject 'What is "printer state" exactly?').

Therefore the generic CUPS backends cannot support it.
They can only support the status of the software to which
they talk to (e.g. a LPD queue, a IPP queue, a SMB share,
a TCP socket, a USB kernel device node or a USB kernel driver,
a device node for the parallel port, ...).

But a special backend made by the manufacturer of the printer
can of course provide much more device specific features.
In particular for HP printers which are supported by the HPLIP
software (http://hplip.sourceforge.net/) there is the "hp" backend
(see my other mail with the subject 'What is "printer state" exactly?').
But even here there are limitations because some printer hardware
don't support the very final state of the printing engine inside
the printer (i.e. the markup engine and whatever kind of further
paper processing engines like duplexer, puncher, stapler, sorter
there are in the printer).


> Since CUPS is supposed to be better than LPR, not being able to ask
> the network printer for its queue will always feel like a bug

Above you asked for the printer state, now you ask for a queue state.
What exactly do you really mean?

The generic CUPS backends lpd, ipp, and socket do query the state
of the remote recipient (i.e. the remote LPD queue, the remote
IPP queue, and the remote socket) but they cannot query the state
of what is behind the remote recipient (i.e. the printer).

Only if a network printer with a built-in LPD or IPP server
does report the state of its printing unit as the state of
its LPD or IPP queue, the CUPS lpd or ipp backend should show
the state of the printing unit - otherwise not.


Additionally an independent seperated communication channel
might be needed to be able to query the state of the printer
at any time because the primary communication channel (which
is used to send the data which is to be printed) may be blocked
because of whatever problem inside the printer (e.g. paper jam)
so that no printer state query would reach the printer.
If the printer does not continuously report its state even when
no state query was sent to it, an independent seperated
communication channel is needed to query the printer state
even if the primary communication channel is blocked.
For network printers this is usually SNMP.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/