cupsManualCopies is not set by _ppdCreateFromIPP

[tillkamppeter]

The pdftopdf does a wide range of page management options (multiple copies, N-up, page-ranges, page-set, ...) but modern IPP printers do many of the page management, too. This often leads to cases where an option supplied to the job is applied twice, for example instead of the requested n copies one gets n*n copies.
What is needed is that pdftopdf gets somehow informed about which options the printer already supports and therefore should not get applied by pdftopdf. As pdftopdf cannot IPP-query the printer to check by itself (it even does not know whether the printer is an IPP printer) and as the printer's capabilities do not change, the probably best way is to use the PPD file.
So the PPD generator for auto generation of the PPDs for driverless printing should put hints into the PPD about which options the printer already takes care of internally, so that pdftopdf can skip these options.
The options handles by pdftopdf are the following:

• copies
• print-scaling/fitplot/fit-to-page
• orientation-requested/landscape
• number-up
• number-up-layout
• page-border
• page-delivery/output-order/OutputOrder
• page-label
• page-set (even/odd)
• page-ranges
• mirror/MirrorPrint
• booklet
• booklet-signature
• position
• collate/Collate
• scaling
• natural-scaling

AFAIK Copies and OutputOrder are already handled. Am I correct that I should let pdftopdf only generate copies if the PPD has the entry *cupsManualCopies: True?
So for the other options we would need entries in the generated PPD, telling which options pdftopdf should skip.
In addition, there should be an entry added to the PPD, telling that the printer is an IPP driverless printer, so that options which are done by all IPP printers do not need to get mentioned individually.
Once we have this facility in the PPD generator I can add appropriate support to pdftopdf.

[RobertKrawitz]

Some of these options might be handled most efficiently on the host even if the printer supports them. In particular, applying page-ranges on the host will reduce the amount of network traffic.

(Remember also that we're getting away from PPD files. Finally.)

[michaelrsweet]

@tillkamppeter To address the specific list of options/attributes:

• copies, collate/Collate, page-delivery/output-order/OutputOrder, and orientation-requested/landscape are generally handled by the filters unless the printer natively supports the format and copy generation.
• print-scaling should be handled by the filter, although we may also pass it to the printer (if supported). fitplot, fit-to-page, scaling, and natural-scaling are OBSOLETE and are replaced by print-scaling.
• number-up is best done on the client; few printers support it and NONE does it consistently/well.
• number-up-layout is CUPS-specific and has to be handled by the client - the "standard" IPP attribute is presentation-direction-number-up but is not widely supported.
• page-border is CUPS-specific and has to be handled by the client.
• page-label is CUPS-specific and has to be handled by the client.
• page-set is CUPS-specific and has to be handled by the client.
• page-ranges is, as noted by Robert, best handled by the client. Many printers only support a single page-ranges value, and then only for PDF printers (since it is required for AirPrint conformance).
• mirror/MirrorPrint is CUPS-specific and has to be handled by the client.
• position is CUPS-specific and has to be handled by the client.

In short, we already have exposed what is needed in PPD files for IPP Everywhere and won't be trying to further optimize that path - the future of CUPS does not include PPD files.

[tillkamppeter]

I did a test job:

echo " " | lp -d Printer -n 2 -o collate

with the printer Printer being an HP OfficeJet Pro 8730 set up with auto-generated driverless PPD file and IPP URI. According to the get-printer-attributes IPP response the printer supports multiple copies and collate in hardware.
The command results in 4 sheets coming out of the printer, not 2. So the request for 2 copies was fulfilled twice, resulting in 2^2 copies.
The error_log shows only 1 page being logged with 2 copies ("PAGE: 1 2"), meaning that the pdftopdf generated two copies, not four.
Looking into the source code of pdftopdf, it uses software copies when it has to do collate in software. And it does collate in software as it has no hint about whether the printer does hardware collate. It knows though that the printer does hardware copies, as the PPD is missing a "*cupsManualCopies: True" line. In addition, pdftopdf is not able to suppress IPP-initiated hardware copies if it does software copies (it suppresses PostScript-initiated hardware copies though).
What I need from CUPS to fix this is, either a hint (by the PPD or any other means) that pdftopdf knows that the printer does also hardware collate, or if all IPP driverless printers which do hardware copies do also hardware collate, a hint to pdftopdf that the printer is a driverless IPP printer. With this I could make pdftopdf skip both copies and collate to leave it to the printer to do these tasks.
Or should I open a separate issue for this?

[tillkamppeter]

Attached is my printers's response to the get-printer-attributes IPP request.
HP-OfficeJet-Pro-8730-ipp-attrs.txt

[michaelrsweet]

@tillkamppeter PDF-capable printers are always capable of collated/uncollated copies, so your filter should NEVER generate the copies itself unless you see cupsManualCopies: True (which indicates a non-PDF printer that needs copies to be generated).

[tillkamppeter]

Now my questions are:

• Do ALL IPP driverless printers (including the non-PDF ones) which support hardware copies also support hardware collate?
• Are there old, non-IPP printers which support hardware copies but no hardware collate?

If both questions can be answered with yes, I would need some way for pdftopdf know whether the printer is an IPP driverless printer, In this case I would assume hardware collate when hardware copies are supported.
If the first question's answer is yes and the second question's no, it is easy and I never do software collate if the printer supports hardware copies.
If the first question's answer is no, pdftopdf need a hint from CUPS whether hardware collate is available on the printer.
What is the exact situation?

[michaelrsweet]

PDF = copies supported
JPEG = copies supported
Others = assume no copies supported

cupsManualCopies is true if the printer can’t do both collated and uncollated copies. It is all you need.

[tillkamppeter]

The PPD generator of CUPS never sets "*cupsManualCopies: True". Does it mean that ALL IPP driverless printers, including Apple-Raster-only ones do support copies and collate in the printer?

[michaelrsweet]

Renaming this bug and re-opening - this keyword should be set for raster printers.

[tillkamppeter]

Another remark: You recommend all page management operations except copies, collate, and output-order be done by the client. Does the IPP backend filter the appropriate options (in the 5th command line argument) to not being passed on to the IPP printer to avoid duplicate application?

[michaelrsweet]

@tillkamppeter Yes, the backend omits attributes when sending raster data streamed to the backend.