[cups-devel] Printing to auto-discovered remote CUPS printers - pdftopdf runs twice

Till Kamppeter till.kamppeter at gmail.com
Mon Jul 16 14:44:19 PDT 2018


Hi,

I am running into a problem with network printing printing. If one 
shares a printer on a CUPS server for a client an IPP (Everywhere) 
printer is appearing (via DNS-SD) and the client's CUPS provides a 
temporary print queue when accessing this printer.

When a job is sent it happens the following:

The temporary CUPS queue on the client is set up for a driverless PDF 
printer (PDF is the lowest-cost multi-page format here):

*cupsFilter2: "image/jpeg image/jpeg 0 -"
*cupsFilter2: "image/png image/png 0 -"
*cupsFilter2: "application/vnd.cups-pdf application/pdf 10 -"
*cupsFilter2: "image/urf image/urf 100 -"

This means that the client turns all incoming jobs into PDF and as the 
exact format requested by the PPD is application/vnd.cups-pdf the 
pdftopdf filter gets called, right before the job gets sent off to the 
server, via the IPP CUPS backend.

On the server we have a CUPS queue with PPD. The final format does not 
matter, the MIME conversion rules of CUPS and cups-filters make the 
input always turned to PDF (is already PDF in our case), then passed 
through pdftopdf, and afterwards turned into the format which the 
printer needs.

So pdftopdf runs on both the client and the server. The problem here is 
that if you apply some page management option, like N-up, reverse order, 
selected pages, ... these options are applied twice.

The first pdftopdf needs to know which of these options the "printer" 
does by itself. If the "printer" is an actual network printer some of 
these options are done by the printer, others not. But if the printer is 
a remote CUPS queue all options are done by the printer as the CUPS 
queue runs its own pdftopdf.

Assuming we do not let the client's CUPS (or cups-browsed) check whether 
the remote printer is a CUPS queue or not we can only base ourselves on 
the result of a get-printer-attributes IPP request, so CUPS on the 
server needs to put all needed info into the answer to this request. I 
assume that therefore the following commit was done on CUPS (following 
https://github.com/apple/cups/issues/5340):

https://github.com/apple/cups/commit/91505c0a326ec53ef6d2b82c9efd8029fac7ae01

Am I right? Does a CUPS server now provide the complete info needed?

The client's CUPS only does the get-printer-attributes IPP request when 
creating the temporary queue and puts the resulting information into the 
PPD file for the temporary queue. The filters (including pdftopdf) do 
not do any IPP request during job execution, they solely use the PPD 
file of the queue to know what they have to do.

So pdftopdf has to find out via the PPD file which options are already 
done by the printer as it does not do IPP requests. So the PPD file 
needs either lines to describe the appropriate capability or an option, 
like the option "Collate" as the CUPS queue does collate already with 
its own pdftopdf.

For OutputOrder I have therefore posted 
https://github.com/apple/cups/pull/5345

Now my question is: How should we proceed here?

Should we

- Let the PPD generated on the client contain all of these 
options/keywords as found from the answer to the get-printer-attributes 
IPP request so that the client's pdftopdf already knows what the printer 
does and so what it should not do by itself (probably this is the 
"cleanest" approach).

- Let pdftopdf on the client do a get-printer-attributes IPP request by 
itself (does a filter no the backend/destination URI) before starting to 
process the job (a little bit strange this idea).

- Let the client's pdftopdf get somehow note (by the PPD file) that the 
destination is a CUPS queue. This would be a bad idea as it somehow 
breaks the symmetry and it does not help if a sophisticated network 
printer does many of the options by itself.

- Let the client's pdftopdf do all the options by itself and mark the 
PDF with a comment that the options are done. This is also a bad idea as 
it only works with a remote CUPS queue, not with an IPP network printer 
which does some of these options. It also breaks the CUPS principle of 
doing all the job processing on the server.

I think the first method is the best one? WDYT? Or is there another 
(better) way to solve this problem?

    Till


More information about the cups-devel mailing list