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

Helge Blischke helgeblischke at web.de
Wed Jul 18 04:18:41 PDT 2018


> Am 16.07.2018 um 23:44 schrieb Till Kamppeter <till.kamppeter at gmail.com>:
> 
> 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

I think the ppdgenerator (cups filters/ppdgenerator.c) should check if a "driverless“ printer is in fact a cups queue and then (at least) skip mapping application/vnd.cups-pdf 
to application/pdf to avoid executing the same filter(s) on both the client and the server.
Maybe there are other items to check – I didn’t do an extensive investigation thereupon.

Helge



More information about the cups-devel mailing list