pdftopdf produces unwanted copies

[psz2036]

When manual_copies is off and sending to a PostScript printer, pdftopdf still produces software copies, resulting in N*N copies. Issue observed at version 1.28.17 in Debian bookworm, present still in current "master" version. Patch tested against Debian; below, re-written for current version (in plain-text and as attached file).

Cheers, Paul

Paul Szabo psz@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of Sydney Australia

--- cupsfilters/pdftopdf/pdftopdf.cxx.ORIG  2024-03-08 04:27:06.000000000 +1100
+++ cupsfilters/pdftopdf/pdftopdf.cxx   2024-04-01 07:01:22.243473122 +1100
@@ -730,9 +730,20 @@
       // of a driverless IPP printer (PDF, Apple Raster, PWG Raster, PCLm).
       // These printers do always hardware collate if they do hardware copies.
       // https://github.com/apple/cups/issues/5433
+      /* PSz  4 Mar 24
+       *  - Surely PostScript printers also can collate? Modern printers
+       *    accept either/both PDF and/or PS, with similar features.
+       *  - Should an inability to collate give us licence to override
+       *    the explicit PPD request of "no sw copies"? An override will
+       *    likely result in N*N copies, when HW does it also.
+       *  - Why pretend to know what the printer can do?
+       * Accepting PostScript also, as a partial (wrong?) fix.
+       */
       hw_collate = (final_content_type &&
            (strcasestr(final_content_type, "/pdf") ||
             strcasestr(final_content_type, "/vnd.cups-pdf") ||
+            strcasestr(final_content_type, "/postscript") ||
+            strcasestr(final_content_type, "/vnd.cups-postscript") ||
             strcasestr(final_content_type, "/pwg-raster") ||
             strcasestr(final_content_type, "/urf") ||
             strcasestr(final_content_type, "/PCLm")));

psz-patch.txt

[Editor's note: Edited for readability]