Printing to auto-discovered remote CUPS printers - pdftopdf runs twice and applies options twice

[tillkamppeter]

I have a CUPS server and a CUPS client, both running the current upstream GIT snapshot of CUPS. Operating system is Ubuntu Cosmic (which will get 18.10 in October) and cups-filters is 1.20.4. cups-browsed is not running for this test.
The CUPS server shares a print queue and I print from the client on this queue, without explicitly creating a print queue on the client. The client has also access to IPP network printers.
I am creating a PDF print job on the client, it is recognized as application/pdf by the client's CUPS. The PPD for the auto-generated (by CUPS), temporary print queue on the client contains several cupsFilter lines dependent on the destination printer. If the destination is a remote CUPS queue, in my case the shared printer on the CUPS server (which understands PDF, PDL list in DNS-SD TXT record contains "application/pdf") a line like

*cupsFilter2: "application/vnd.cups-pdf application/pdf 10 -"

is in the PPD and it gets selected by the client's CUPS when determining the filtering of the job. The client then needs to filter the incoming application/pdf to the application/vnd.cups-pdf requested by the PPD file and for that pdftopdf is called as the only filter.
The server's CUPS daemon then receives the job and recognizes it as application/pdf again (I do not know now whether via *.types files or told by the client). The PPD here is for the physical printer, but the nature of the *.convs rules on the server makes up a filter chain which starts with pdftopdf, so pdftopdf is called twice, once on the client and once on the server.
If an option handled by pdftopdf (like number-up=4) is supplied to the job on the client it gets applied twice, once by the client's pdftopdf and once by the server's.
The problem is now for the client to find out which options are already taken care of by the server, when the client considers the server simply as a driverless IPP printer and does not distinguish whether the server is a CUPS server or an IPP network printer. As CUPS runs pdftopdf for processing jobs a shared CUPS printer supports all of these options (number-up, number-up-layout, page-border, collate, mirror, page-set, fit-to-page, scaling, ...), an IPP network printer some or none of them depending on the printer's sophistication.
A first step to address this is already done as the support of such options is listed in the response which CUPS gives to a get-printer-attributes IPP request of the client (see issue #5340), but the pdftopdf of the client has no access to this info, as a client's filter is not supposed to do an IPP request on the server (am I right?). The only way in the current architecture of CUPS for a filter knowing about the print queue is the PPD file. So there needs to be one of the following two things to be done:

1. The PPD generator of CUPS has to add all these options to the PPD. If pdftopdf finds such an option in the PPD it does not execute this option by itself as it assumes that the printer (server in our case) will execute it. You call most of these options already "PPD options" in issue Question: Regarding cups API functions for cups standard/common options. #5340.
2. When CUPS creates a temporary queue for an IPP network printer or remote CUPS printer, it does a get-printer-attributes request for generating the PPD. It should store the original response in a way so that the filters can access it (would also be good for a future removal of the PPD concept).

One of these changes need to be done to avoid

1. The client's pdftopdf having to somehow recognize whether the server is a CUPS server and in this case not execute the options. Would break with IPP network printers which support some of these options.
2. The client's pdftopdf has to mark its output with a comment so that a subsequent pdftopdf (in our case the server's) passes the job through unchanged instead of processing it again.

These two are not really IPP-conforming but dirty workarounds.

[michaelrsweet]

I won't be able to address this for another month, but basically you need to report support for the application/vnd.cups-pdf MIME media type so that the client doesn't send the PDF as application/pdf.

[michaelrsweet]

I think the solution here is to not have the client do any local filtering, e.g.:

*cupsFilter: "application/pdf application/pdf 0 -"

instead of using the application/vnd.cups-pdf media type. Changes will be to ppd-cache.c...

[michaelrsweet]

[branch-2.2 b729765] Fix shared printing using the IPP Everywhere driver (Issue #5361)

[master fd7190c] Fix shared printing using the IPP Everywhere driver (Issue #5361)

[tillkamppeter]

I have tested this change and now it works correctly, when the destination IPP printer is a remote CUPS queue on the local machine the input is only turned into PDF if needed, with texttopdf, imagetopdf, ... pdftopdf is not run any more. With a physical printer as destination IPP printer pdftopdf is run as usual.
Thank you very much.
I have applied it to Ubuntu 18.10 now.