While this little group effort has given some interesting insights into 90's printer protocols, the practical side of things has yet to be completely satisfied! While we have prodded our ancient laser-printer tanks in all sorts of interesting ways, I at least am still not able to determine by a shell script if the printer is actually done.

Last thing we tried was to determine is power-save mode was on via a PJL command that gets the current status which includes the display text. For me this text was always the "processing job" text, so that was completely useless.

I did notice one odd behavior which was when I set the "ready message" by the PJL command: @PJL RDYMSG DISPLAY = "Some Text" , the status would not return the job message, but the new message. In itself, this is also not very helpful, but then I started to thing how CUPS talks to the printer.

Effectively, CUPS does not do a whole lot different than we did via Telnet or Netcat. It opens up a connection to the printer via port 9100 and essentially just dumps the job data there. After that is done, CUPS really could not care less as the printer will handle the rest.

Here is my latest idea to abuse PJL to get this working. What if we could attach a PJL command before the data stream and afterwards as well? The stream is just another bunch on commands that are executed mostly in a serial manner.

Suppose we'd start the data with setting a RDYMSG that reads "printing". Then the data is send and at the end of it, after the last command that has anything to do with the document itself, we set RDYMSG to something like "Bazinga".

Assuming all commands are executed in serial and the last command will always signal the end of the job, using the Netcat method to poll status would only resolve "Bazinga" if the job is actually done. Any fault would cease operation so jams and paper out scenarios won't cause premature power-off.

Anybody out there with experience in messing with CUPS printer drivers?