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

[Till Kamppeter]

On 18/07/18 02:37, Michael Sweet wrote:
> Till,
> 
> I'm guessing this might be caused by mapping application/vnd.cups-pdf to application/pdf if the remote printer doesn't support it?
> 

I am creating a PDF print job on the client, it is recognized as 
application/pdf by CUPS. The PPD for the auto-generated (by CUPS) print 
queue contains several cupsFilter lines dependent on the destination 
printer. If the destination is a remote CUPS queue (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 whe determining 
the filtering of the job. The cleint 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.

My question is now how we should avoid this. Therefore the client needs 
to know which of these options would be already handled by the server 
and so do not need to get handled on the client.

    Till