Printers fail to report issues to CUPS

Question

CUPS has 3 fields that are used in issue reporting,

1. printer-state (enum): Either idle, processing or stopped.
2. printer-state-message: Plain text human readable explanation.
3. printer-state-reasons: Listed description of the printer state, as described in RFC8011 p.152 this is where the real issue reporting happens. It has a list of comma delimited keywords describing the state of a printer eg. 'media-needed' or 'toner-low'

When testing a Zebra LP 2844 on Ubuntu 16.04 (and mac but let's keep this simple for now) using the Zebra EPL2 Label Printer driver, I get the following results.

----Printer out of paper----
Status Enum: processing
Status Message: printer-state-message: 1 textWithoutLanguage {Waiting for 
printer to become available.}
Status Reason: printer-state-reasons: 1 keyword {none}

----Printer rejecting jobs----
Status Enum: idle
Status Message: printer-state-message: 1 textWithoutLanguage {Rejecting Jobs}
Status Reason: printer-state-reasons: 1 keyword {none}

As you can see, the 'Printer out of paper' issue and most issues that prevent the printer from printing resolve as 'processing' and never give me more information. You could figure out how long the printer has been 'processing' and deduce if there is a problem from there, but besides that being janky, the cause of the issue would remain unknown.

Meanwhile, the 'Printer rejecting jobs' state tells me absolutely nothing (remember, the Status Message is just human readable plain text and is not parsable due to there being no guidelines on what is put there). Besides hiring someone to read state-message there is no way for my program to know there is an issue.

This is not the case with all printers, for example, this is the output from a Brother HL-L2380DW

----Printer out of paper----
Status Enum: processing
Status Message: printer-state-message: 1 textWithoutLanguage {Waiting for job to complete.}
Status Reason: printer-state-reasons: 2 keyword {cups-waiting-for-job-completed, media-needed-error} 

Of the 3 printers tested so far (HP, Brother, and Zebra), the Brother HL-L2380DW was the only printer to properly communicate issues. If you wish to test it yourself you can run this crude CUPS tool I tossed together in java https://github.com/Vzor-/cupstool More data helps!

I do not know if the issue lies with cups or with the manufacturers. Either way I need a way forward, be it as a fix or a group I can help to make a fix.

Edit: It seems Zebra does not make or maintain its own Linux drivers.

Answer 1

From Michael Sweet,

Kyle,

Status reporting is complicated, but in general the problem with driver-based queues can come from the driver not implementing STATE: message support (typically because the printer's communication channel does not provide support) or from the printer itself not supporting any kind of status reporting.

In the case of the Zebra printer, it does not support in-band status reporting so the CUPS-bundled driver has no way of getting status from the printer that way. It also does not support the SNMP Printer MIB for status, so we don't even get out-of-band status... :/ Sadly, these kind of printers often do not support status reporting, which is funny given that many are deployed in industrial settings where remote monitoring is common...

Printers that implement IPP (typically all printers these days except label printers - so 98%+ of printers) support the IPP printer-state-reasons keywords for status, in addition to other IPP attributes and (in many cases) SNMP Printer MIB properties as well.

So it seems this is mostly just an issue with some label printers.