[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