[cups] MacOS clients using n-up printing to CUPS server doubles up the n-up option

[Jeff Dyck]

Oooh, this sounds very intriguing…

So just to confirm: this seems to be a side effect of not advertising the queues as _cups (which I definitely am not doing), but changing that to add the _cups PTR would resolve this issue while adding new ones.  The other option is to custom compile CUPS with your patch to skip this (and some other) attribute when the incoming print job is via IPP/Airprint…

Now I just need to figure out how to compile CUPS and add the patch ;).  That may be complicated somewhat in that I’ve got CUPS within a Docker container… I’ll play around and see what I can figure out.

Jeff

> On Feb 22, 2024, at 2:32 PM, Douglas Kosovic <doug at uq.edu.au> wrote:
> 
> Hi Jeff,
> 
>> Mostly Apple shop here (education) and we print via IPP Everywhere /
>> AirPrint through CUPS servers that are advertised via DNS-SD records.
>> I've recently received complaints about the number-up printer option
>> when printing from MacOS…
> 
> I believe the issue is related to not advertising the _cups dns-sd subtype to let macOS clients know they are talking to a CUPS shared print queue instead of a printer.
> 
> CUPS shared print queues appear as "Bonjour Shared" on the macOS clients if the _cups dns-sd subtype is used.
> 
> But there are complications if you use the _cups dns-sd subtype as you won't be able to have macOS clients automatically add the queues as AirPrint queues, see:
> https://github.com/OpenPrinting/cups/discussions/841
> 
> But this approach works fine if you use other mechanisms to add the queues as either AirPrint or IPP Everywhere queues.
> 
>> Basically after some investigation, when a user on MacOS chooses to
>> print say 4 pages per physical piece of paper (number-up=4),
>> MacOS automatically generates a PDF that is already set to 4 pages
>> per page, but then it sends that to the CUPS server with the
>> number-up=4 attribute, so CUPS takes the PDF that already has 4
>> pages per page and manipulates that to be 4 pages of 4 pages per
>> page, so 16 pages per page total.
>> 
>> Is there some way to configure CUPS to ignore that option?
>> Or other ideas to make this so it doesn’t stack these options
>> and prints correctly?
> 
> I've been using the following patch to avoid applying options twice with macOS clients :
> https://github.com/eait-cups-printing/cups/blob/main/cups-exclude-filter-options.patch
> 
> For the patch to work, you need to explicitly let the CUPS server know that the _cups dns-sd subtype is not being used by explicitly setting BrowseDNSSDSubTypes in cupsd.conf, e.g. :
> 
> BrowseDNSSDSubTypes _print,_universal
> 
> 
> I haven't submitted a bug report yet. I also haven't tested the patch with iOS or iPadOS clients, nor have I tested if the "collate" option should also be excluded.
> 
> 
> 
> 
> 
> Cheers,
> Doug
> 
> 
> _______________________________________________
> cups mailing list
> cups at cups.org
> https://lists.cups.org/mailman/listinfo/cups