ippeveprinter and *cupsManualCopies: True

[debiantriage]

ippeveprinter is set up like this:

/usr/sbin/ippeveprinter -c /usr/local/bin/pdftopdfa -f application/pdf "Print to PDFA"

pdftopda converts a PDF to PDF/A. No problem with that.

ippfind gives a URI of Iipp://test-new.local:8001/ipp/prin. A permanent queue is created:

lpadmin -p pdfa-q -v URI -E -m everywhere

and printer to.

lp -d pdfa-q FILE.pdf

works very nicely. Not so with -n 5 added to the lp commandline. There is only one copy produced.

/etc/cups/ppd/pdfa-q.pdf was edited to have cupsManualCopies: True added. CUPS was restarted. That works to give multiple copies.

Should the PPD be generated with *cupsManualCopies: True in it?

This issue appears to affect the Printer Applications too.

[zdohnal]

Hi @debiantriage ,

this is the current CUPS code where we generate PPD:

3417     is_pdf   = ippContainsString(attr, "application/pdf");
...
3424     if (is_pdf)
3425     {
3426      /*
3427       * Don't locally filter PDF content when printing to a CUPS shared
3428       * printer, otherwise the options will be applied twice...
3429       */
3430 
3431       if (ippContainsString(attr, "application/vnd.cups-pdf"))
3432         cupsFilePuts(fp, "*cupsFilter2: \"application/pdf application/pdf 0 -\"\n");
3433       else
3434         cupsFilePuts(fp, "*cupsFilter2: \"application/vnd.cups-pdf application/pdf 10 -\"\n");
3435     }
3436     else
3437       cupsFilePuts(fp, "*cupsManualCopies: True\n");

, as I can see, we don't generate the PPD keyword if the destination printer claims to support "application/pdf" (which most IPP Everywhere printers support by default and you define it as acceptable input for printer app by option -f).

Per https://openprinting.github.io/cups/doc/spec-ppd.html#cupsManualCopies I see the keyword is used when we want to declare the destination does not support copies - so as a far as I see it, CUPS expects any destination which we generate PPD by Get-Printer-Attributes request for and which claims to support application/pdf to support copies by default.

I'm not sure what is an expectation regarding ippeveprinter here - I would say the specified command, PPD file or destination (if the destination is a device) should support making copies. @michaelrsweet wdyt?

[zdohnal]

Looks like some real printers https://github.com/OpenPrinting/cups-filters/issues/543 are not capable of automatic copies as well :( . Is it a firmware bug, @michaelrsweet ?

We could work this around for a time by adding the keyword into PPD, but it will stop working once we get rid of PPD - @michaelrsweet would it be adding the keyword into generated PPD harmful?

To be honest I didn't find a place where we create the additional copies in CUPS in case cupsManualCopies is used - I saw some usage in pstops, but that's not a filter we usually run during printing a PDF.

[debiantriage]

Replacing -f application/pdf with -f image/urf sees a PPD generated with *cupsManualCopies: True in it.

I also have a snap of the Gutenprint Printer Application with an Epson RX420 set up. Printing to it or running lpoptions -p rx420 -l does not get a temporary PPD with *cupsManualCopies: True present.

[michaelrsweet]

@zdonal All IPP Everywhere/AirPrint/Mopria printers with PDF support MUST support copies for PDF output. If they aren't, that is a serious bug (and I'd appreciate identifying those models and reporting the issue to the appropriate vendors)

I don't want to add support for printers that are this broken. If they actually support PDF, then they also are perfectly capable of producing copies since a) general PDF cannot be stream-printed like Apple raster/PWG raster/PCLm/PDF-is can, and b) since the PDF file is stored on the device (in memory or on SSD/hard disk), the printer can easily render the file N times to produce N copies.

WRT using ippeveprinter to produce archivable PDF output, it really isn't designed to support that. Rather, the print command you provide to ippeveprinter is responsible...

[debiantriage]

@michaelrsweet

WRT using ippeveprinter to produce archivable PDF output, it really isn't designed to support that. Rather, the print command you provide to ippeveprinter is responsible...

The ippeveprinter manual says

• ippeveprinter is a simple Internet Printing Protocol (IPP) serve...that runs a command for every job that is printed.

Producing archivable PDF output was a use example. It could have equally as well have been a command to print to a legacy printer or, as the manual indicates, evaluate /usr/bin/file. Is CUPS even aware of the nature of the command executed?

I thought that, in conforming to the IPP Everywhere specification, ippeveprinter would have a PPD generated that is similar to the one from an ENY 4500 (which does not have PDF as a PDL). I wasn't asking for or expecting any support for a command that is run.

[michaelrsweet]

Is CUPS even aware of the nature of the command executed?

No, the interface is intentionally simple and ippeveprinter doesn't know what the command does aside from conforming to the interface.

I thought that, in conforming to the IPP Everywhere specification, ippeveprinter would have a PPD generated that is similar to the one from an ENY 4500 (which does not have PDF as a PDL). I wasn't asking for or expecting any support for a command that is run.

IPP Everywhere conformance includes printers with PDF support, not just raster printers like the ENVY. The "everywhere" PPD generator in CUPS adapts to the capabilities of the printer so that you get the full functionality of the printer. Printers that support PDF and JPEG must support copy generation for those formats, per IPP Everywhere.