CUPS is manually creating copies even when cupsManualCopies is false

slp commented

2025-01-02 16:49:24 -05:00

Owner

Upstream report: https://github.com/OpenPrinting/cups-filters/issues/613

This happens if the print job requested collation, but the printer doesn't report that it supports collation while claiming support for copy generation -- CUPS will manually create copies but still tells Gutenprint (+filter) to produce its own copies. So instead of N copies you end up with N*N or N^2 copies.

Upstream report: https://github.com/OpenPrinting/cups-filters/issues/613 This happens if the print job requested collation, but the printer doesn't report that it supports collation while claiming support for copy generation -- CUPS will manually create copies but still tells Gutenprint (+filter) to produce its own copies. So instead of N copies you end up with N*N or N^2 copies.

slp added the

bug

Upstream

labels 2025-01-02 16:49:30 -05:00

slp commented

2025-01-02 16:50:14 -05:00

Author

Owner

I have a potential workaround but it needs to be tested still.

slp commented

2025-01-16 18:22:38 -05:00

Author

Owner

It appears that the problem is twofold. The short version is that Gutenprint is indeed doing things wrong. The backend (or indeed, Gutenprint itself) should NOT be paying attention to the copies argument passed in on the command line and instead use the NumCopies argument in the cupsraser header.

Only if the printer supports collation should we be paying attention to the global NumCopies.

It appears that the problem is twofold. The short version is that Gutenprint is indeed doing things wrong. The backend (or indeed, Gutenprint itself) should NOT be paying attention to the copies argument passed in on the command line and instead use the NumCopies argument in the cupsraser header. Only if the printer supports collation should we be paying attention to the global NumCopies.

slp closed this issue

2025-01-16 18:22:38 -05:00

CUPS is manually creating copies even when cupsManualCopies is false #53