Added ability to request CUPS Job Number and the amount of pages printed

[MaxWinsemius]

I found myself in the need of retrieving the job number from CUPS, therefore I implemented it. I added guards for the Printer class, as if it is not using a CupsPrinterConnector it should not return these values. I found the amount of files was also returned, so I added it as well.

The command lp -d <queue name> <file name> returns in the format request id is <queue name>-<job name> (<amt of files> file(s)). As the job name never contains a dash, we can safely say that the last part of this word, after the last dash, will be the job number. The "word" containing the amount of files is only preceded by a (, thus stripping the first letter of this string should always return the number given.

I was not sure if you are okay with these functions residing also inside of the Printer. But you can remove them if you feel that's nicer, as it functionality for a specific connector (but I felt this data should come from the printer, and not the connector).

[Muraveiko]

Sorry.
But this will only work with a USB connection.
With a network exchange between the cups and the printer:
The server always returns success after the job is sent to the device.
You will only see the statuses: 'in the queue" and "success".
The problem is that thermal printers are connected using "send and fire" protocols (no feedback through 9100).

Am I wrong?

[MaxWinsemius]

For how I understand what you mean, the question is if this will still work if the end device is still online.

I have just tested with a setup that includes a network host (A) with my printer connected over usb, and a client (B) that connects to the cups server on A. Thus both run cups servers, and A sends his jobs directly to the printer and B sends jobs to A.

If I have the printer online (powered), I am able to send jobs from both systems and get the expected output:

max@a $ lp -d CT_S2000 test
request id is CT_S2000-1376 (1 file(s))
max@b $ lp -d CT_S2000 test
request id is CT_S2000-892 (1 file(s))

If I have the printer offline (unpowered), I get similar results:

max@a $ lp -d CT_S2000 test
request id is CT_S2000-1379 (1 file(s))
max@b $ lp -d CT_S2000 test
request id is CT_S2000-893 (1 file(s))

So to my knowledge there will be no case that the cups server does not return a line with request information.

If you mean that this will not succeed if the cups server is not running: that's definetly true, but that should be caught earlier in the system (and my guess would be it is, but I have not researched the code base too much).