CUPS does not appear to respect the 'cupsManualCopies' PPD parameter when printing AirPrint-supplied jobs with multiple copies #613
Comments
|
Not sure what is going on here, but the CUPS server is getting a PDF file from the Mac so it should just be pdftopdf adding the copies? Moving to the cups-filters project to debug... (not a CUPS problem...) |
|
@speachy could you please test the following
I have a report of a similar issue, but I can't reproduce it on macOS 13 and 10.15. With collate=on, if PPD does not have |
|
OpenPrinting/libcupsfilters#53 may be relevant |
|
The MacOS print dialog (or at least the photo preview application) doesn't give the option of collating or not. It appears that it automatically requests collation if you request more than one copy, even if you are printing only one page. For these dye-sublimation photo printers, multi-page jobs are exceedingly rare, but most models support producing multiple copies of a single image and this feature is widely used in practice due to the performance/throughput benefits. I guess a least-PITA workaround in the short term is to claim support for hardware collation on the models that support hardware copies. That doesn't change the underlying problem that we shoudn't be manually making copies without also telling the later parts of the filter chain that only one copy is requested. |
It does, open "paper handling" tab in the printing dialog. It is present in "preview" app when printing jpeg, at least in macOS 13.
Unfortunately, I'm unable to reproduce this issue on macOS 13 and 10.15. The user who has reported this issue to me (I'm not a part of cups/cups-filters project, but i'm selling print servers) is using brlaser driver (which accepts cups-raster only, manualcopies=false, no collation in ppd), poppler instead of ghostscript is configured in cups. The user reports the issue on macOS 14 and 10.15, when printing pdfs and webpages from safari. I'm waiting for more info from the user, but if you have any additional details and peculiarities on how to reproduce this issue, please post. FYI, the print server is running Debian 12: cups 2.4.2-3 (+debian patches), cups-filters 1.28.17-3 (+debian patches). |
Ah, the "tab" that's not actually a tab. Not exactly the most discoverable interface.. Turning off collation resulted in the desired outcome. Interestingly, editing the PPD to specify '*Collate: False' (or True) seems to have no effect; if collation is requested by the application, the filter chain appears to produces its own copies no matter what. (I need to double-check this though, I don't think I added it properly)
The Mac in question is currently running Big Sur (11.7) and printing from the built-in photo preview application. After running out of paper with the Joyspace U826 I originally reported this against, I switched to a Kodak 605 which exhibits the same problem -- It is trivially recreateable with any Gutenprint-supported dyesub model that can produce its own copies. |
|
cups-filters does the expected thing with a construct like this added to the PPD: I've altered Gutenprint's PPD generator to add something similar for all models that report "cupsManualCopies: False", but this is still just a workaround. |
|
Unfortunately I still not able to reproduce it on my Debian 12 system with the output to a The output document presumably has 2 pages with copies=1 in the header, as checked with hexdump: What's strange is that in your log, NumCopies is also 1, but your log also has Skimming through Gutenprint code, I can see that So apparently it is not reproducible with CUPS documentations says the following:
Could this be the bug in |
|
Guess I found the mistake, grep by |
No, that's not the mistake. or at least not THE mistake. (Line 1351-2 of rastertogutenprint.c) Backing up a step; from the logs above, you can see that both Gutenprint and Ghostscript are handed two pages, the PPD option NumCopies is set to 2, and '2' is the copy count handed to all filters (including the backend) on the command line. HOWEVER, the 'NumCopies' argument cups_page_header_t/cups_page_header2_t on each individual page handed to gutenprint is set to 1. The salient question -- Should the NumCopies in the page header always take precedence over the PPD NumCopies setting (and/or the filter cmdline argument?) Either way, how exactly is the backend supposed to know, given that it doesn't have access to the page header, just the cmdline (and PPD) which specify two copies? Going back to the the backend's "use larger of" logic -- that was put there for backwards compatibility reasons at the time that gutenprint gained the ability to parse NumCopies itself. Additionally, the backend actually implements manual copy creation (on printers that normally can do it completely in hardware) in some circumstances. |
|
Yes, I understand, I can see this irregularity myself. splix, brlaser, some other filters all use the value from cups_page_header2_t, and don't use argv[4] at all anywhere. @michaelrsweet ^^^ |
|
@speachy @ValdikSS A filter or backend is only responsible for producing copies when they are given a file to print. If they are reading data from stdin, they should assume that the number of copies (on the command-line) has been applied. For a backend the only time you normally see it producing copies is when doing so-called "raw" printing of printer-ready data. You can't depend on the NumCopies field in the raster page header because it represents the number of uncollated copies the printer should produce, and then only if the PPD file contains the "cupsManualCopies: false" keyword/value (a value of "true" means the printer can't make its own copies so the RIP filter needs to generate them at all times...) A separate PPD keyword (cupsMaxCopies) tells the RIP filter the maximum number of copies the printer supports... |
But that's all the filters I checked do, and it works as intended for both cupsManualCopies=true and false, collated and uncollated printouts. Do you have an example how it should be done then? Could you describe which logic gutenprint with its filter+backend architecture should use? Or did you mean argv[4], not raster header data? |
|
@ValdikSS As a raster driver (filter), you look at NumCopies and generate copies if NumCopies > 1. This should always work as expected with the usual cups-filters and when you (as the driver developer) provide the correct values in the PPD file. I say "you can't depend on NumCopies" to know whether a job is producing multiple copies. All it tells you is, as a driver filter, whether you need to produce an (uncollated) copy of this page - nothing more, nothing less. The Gutenprint backend should only be producing copies of files supplied on the command-line ("raw" printing) and otherwise not producing copies at all. It is up to the Gutenprint raster filter to do any (uncollated) copy generation. |
|
If I'm understanding this correctly, the NumCopies PPD option applies to the job as a whole, but the NumCopies value in the cupsraster page header is only for the specific page in a given job? Consequently, a rastertoPRINTER filter should only pay attention to the NumCopies PPD option if it supports job Collation? Meanwhile, with respect to the backend, it's been long enough that dropping the backwards compatibility workarounds for page copy generation is warranted. But it seems that no matter which way I go I'm going to cause regressions for some folks. I'll have the backend ignore argv[4] if no filename is supplied, and work through the fallout..) |
|
@speachy The per-page header field
No, rastertoPRINTER filters should only pay attention to the |
|
Okay, I've rejiggered things so that rastertogutenprint only uses the NumCopies from cups_page_header_t, and will pass that information in-band to the printer (if supported/appropriate), and the backend will now only care about argv4[] if a file is passed on the filter command line. ...I still have yet to run this stuff through any sort of regression/smoke tests. I guess we can consider this resolved. |
This is with CUPS 2.4.11 and cups-filters 2.0.1, from MacOS 10.14 (I think?) client, and the latest gutenprint snapshot.
Using the Apple preview application, if you tell it to print two copies of a single image, by the time the job passed to the rastertogutenprint filter has two pages, yet the 'copies' argument on the filter command line is still 2. The PPD specifies 'cupsManualCopies: false' which means the "hardware" (ie not CUPS or its filter chain) is responsible for generating copies.
I can't be sure the problem isn't with the Apple preview application or MacOS's AirPrint client implementation, but I do not consider that likely.
Attached are:
Here's an excerpt of the logs, showing the arguments passed to the filters:
It shows that MacOS is requesting two copies of one page, but it looks like the universal filter's pdftopdf step is apparently doubling this up to two pages, passing that to ghostscript, before eventually sending that to rastertogutenprint (which takes the 'copies' argument from the command line and tells the printer to generate two copies)
I haven't figured out how to enable more verbose debugging of the pdftopdf or ghostscript filters yet, if I can I'll update this with more info.
attrs.txt
cups.log.txt
U826.ppd.txt
The text was updated successfully, but these errors were encountered: