Requesting change to print-color-mode-default IPP Attribute

[csfjeff]

Quick context: I'm with a school district that's moved to CUPS and IPP-Everywhere/Airprint as our backend print servers. We have quite a few color printers, but unfortunately color printing can get quite expensive, especially when we're talking a scale of 40,000-70,000 pages per day, so I would like to request the ability to either configure how CUPS advertises the "print-color-mode-default" attribute or default to monochrome, as currently it seems to be hard coded to color within CUPS itself.

With an IPP-Everywhere printer I can set the default on the printer to be monochrome or color, which changes the IPP-Everywhere attribute "print-color-mode-default". Devices query this attribute and can use it to present the appropriate default for users when they open a print dialog.

Unfortunately on a print queue shared via CUPS this value seems to be hard coded to match the capability of the printer - so if it's a color printer it defaults to color with no ability to configure that setting.

I think I've found the bit of code in /cups/scheduler/printers.c at line 4471. It would be nice to have some way to configure this, but barring that I would suggest that defaulting to monochrome would make sense for saving costs while still allowing users to choose color when they actually wanted it.

[zdohnal]

Hi @csfjeff ,

I've set up a testing environment at my home - one CUPS server advertising (Fedora 34) a queue for color device, one client which sees the advertised queue (Fedora 33) - and I'm able to set a paper color option in GTK print dialog (evince) to a different values.

Or did I misunderstand the problem? You have the all options, but you want to default to monochrome instead of color for queues which you see on client and they're advertised from CUPS server?

[csfjeff]

Hey @zdohnal, thanks for taking a look at this.

Most of my users are on Mac or iPads, when I point my Mac direct to the printer and have the default set to monochrome, the Mac print dialog comes up with B&W printing automatically chosen. If the user wants colour they have to deselect the B&W option. Unfortunately the IPP option that allows this, "print-color-mode-default", is hard coded into CUPS – if the printer supports colour, the default is colour.

My initial thought was that it's fairly easy to choose B&W in the print dialogue, but unfortunately it seems our users keep forgetting / don't pay attention / or just aren't smart enough to choose black and white for the 90% of print jobs where that's what they should be choosing. We're talking about thousands of extra, unnecessary colour pages every day, which adds up to a lot of extra money, especially on our leased copiers where we pay based on pages / colour / monochrome as part of our contract. It's really starting to hurt our school budgets.

So I would like the CUPS server to advertise the "print-color-mode-default=monochrome" setting exactly like I can do direct from the printers. It would be amazing if this could be set per print queue, but I realize that would take a lot of work on the programming side to make happen (UI or some kind of flag to set the option, and then the logic to support that). The much easier option would be to simply set the default to monochrome even for colour printers - I think based on what I see of the code, it would just be a matter of changing the "colour" to "monochrome" on the line of code mentioned above.

[zdohnal]

Ok, so you can choose the color mode, good - and you would like to default or have a way to default to a different value which CUPS set by default for color devices...

Regarding setting 'monochrome' for color printers by default - IMHO it would lead to reports from users which expect color printout without setting anything, so I wouldn't go there for now.
Regarding sharing print-color-mode-default - IIUC CUPS already shares the attribute (@michaelrsweet please correct me if I'm wrong here). I can see the attribute if I do get-printer-attributes request on the queue - when CUPS looks for queues on the local network, it checks mDNS messages, takes txt entries from it and local hostname - and in the end it does the request to the printer/server - but here I will really need to see the packet capture to be sure here.

If the presumption above is correct, then the source of the problem can be that _ppdCreateFromIPP2() function doesn't check the attribute, so it doesn't take it into account when setting the defaults for the user (which would have needed a fix in CUPS from Apple for you).

I'll check the packet capture whether the attribute is really passed in the response and then try to fix _ppdCreateFromIPP2() function to honor the defaults from the server.

The other thing which is maybe connected is that the following command:

$ lpadmin -p <queue> -o print-color-mode-default=monochrome

doesn't work for me - maybe it is connected.

[debiantriage]

@zdohnal Have you tried -o print-color-mode=monochrome?
`

[zdohnal]

Hi Brian,

I haven't tried it yet, because I wanted to set a default settings, so I went for '-default' option - I'll check, but it didn't come to my mind a default could be set by non-default option.

[csfjeff]

Just adding that if you look at the line of code I mention, it seems to me that CUPS hard codes the IPP attribute it shares based on whether the printer is capable of color or not. IE: if the printer can do color, that IPP attribute is always hard coded to color. There is no option to adjust what CUPS is advertising via a get-attributes to clients.

/cups/scheduler/printers.c lines 4456 - 4483, where it seems to literally be:
if printer is color, then set print-color-mode-default to color. It doesn't query the printer to see what the default should be, nor offer a way to adjust the default.

   /*
    * print-color-mode...
    */

    if (ppd->color_device)
    {
      static const char * const color_modes[] =
      {
        "monochrome",
	"color"
      };

      ippAddStrings(p->ppd_attrs, IPP_TAG_PRINTER, IPP_TAG_KEYWORD,
                    "print-color-mode-supported", 2, NULL, color_modes);
      ippAddString(p->ppd_attrs, IPP_TAG_PRINTER, IPP_TAG_KEYWORD,
                   "print-color-mode-default", NULL, "color");
      ippAddStrings(p->ppd_attrs, IPP_TAG_PRINTER, IPP_TAG_KEYWORD, "pwg-raster-document-type-supported", 3, NULL, pwg_raster_document_types);

      urf[num_urf ++] = "SRGB24";
    }
    else
    {
      ippAddString(p->ppd_attrs, IPP_TAG_PRINTER, IPP_TAG_KEYWORD,
                   "print-color-mode-supported", NULL, "monochrome");
      ippAddString(p->ppd_attrs, IPP_TAG_PRINTER, IPP_TAG_KEYWORD,
                   "print-color-mode-default", NULL, "monochrome");
      ippAddStrings(p->ppd_attrs, IPP_TAG_PRINTER, IPP_TAG_KEYWORD, "pwg-raster-document-type-supported", 2, NULL, pwg_raster_document_types);
    }

I also tried to go only the CUPS web UI and set the default for the printer to monochrome. But then users can't print in color at all anymore, so that's not an option either.

[zdohnal]

@csfjeff
In the end you can set the different print-color-mode-default, however CUPS doesn't change the original value, but adds a new one... :) I did:

$ lpadmin -p <color_printer> -o print-color-mode-default=monochrome

and then checked get-printer-attributes response via ipptool:

print-color-mode-default (keyword) = monochrome
...
print-color-mode-default (keyword) = color

This is one of the effect of hardcoding the attribute as you've found out previously, but it is only a part of the problem. What we need to ensure:

• 'color' is set only when the attribute value is 'auto' or 'color' for colored devices and there is no print-color-mode-default beforehand
• you can set a different print-color-mode-default without current duplicity -> updating existing attribute if the new value is from print-color-mode-supported
• 'print-color-mode-default' is shared
• the clients can process 'print-color-mode-default' attribute and transfer it to 'DefaultColorModel'
• this created 'DefaultColorModel' from shared attribute is not overridden by hard coded 'color' in load_ppd().

I'm currently debugging the code to see how it all works in reality.

[csfjeff]

That would be amazing if you were able to get that sorted out. Thank you so much for looking into it - I do a bit of programming, but mostly at the scripting level (Ruby and Bash) so while I could sort of figure out what was happening, I would have no idea how to do much more than switch the default to hard code it to monochrome ;).

[csfjeff]

Just touching base on this - this is still a problem for us that I haven't found a way to work around. Especially with the current global toner shortage I'm getting a LOT of flack from users because I can't set monochrome as the default while still allowing colour printing. It's costing us a lot of extra money across the school district multiplied by 30,000-60,000 pages a day.

[debiantriage]

I set up this queue:

lpadmin -p testq -v ipp://... -E -m everywhere

and then edited its PPD to have

*DefaultColorModel: Gray

Suits my Firefox, Evince and Okular.

[csfjeff]

Hmmm, I may be able to script that for my 2500 Macs, but doesn't help for my 5000 iPads. 1/3 is better than nothing though so I'll definitely see if I can work that in somehow.

[csfjeff]

No go, although very strange results on Mac... I can create the PPD and edit it with the *DefaultColorModel: Gray option, then use lpadmin to add the printer with the modded PPD. When I pull up a print dialog, the "B&W" option is checked, but the print preview shows color, and if I print it comes out in color. Strangely if I turn off B&W and then click it again everything is good.

Either this specific edit of the PPD is triggering a Mac bug, or perhaps it's because the Mac is querying the IPP-Everywhere queue and seeing that the default color mode on the IPP queue is color.

There may still be some kind of strange workaround, but the reality is that this is supposed to be set on the server/printer side - a printer doing a direct IPP / Bonjour / Airprint advertisement can do this and then any iPad or Mac automatically gets the right settings.

Unfortunately CUPS itself running as a server gets this very wrong.

[michaelrsweet]

@csfjeff I've pushed changes that should fix this for you:

[master 98ac865] Fix print-color-mode-default support so that it can be configured and defaults to the printer's value (Issue #277)

Note that I think there are still some issues with the macOS/iOS handling of default color mode - if you experience them with these changes, please contact Apple to report the problem to them since they don't monitor OpenPrinting... :/

[csfjeff]

Oooh, that's very exciting :). Thank you. I'm wrapping up another project right now but will hopefully get a chance to test this out next week.

[tillkamppeter]

I am also using print-color-mode-default to determine the default for ColorModel in the PPD generator of cups-filters (for cups-browsed and for the driverless utility), both in master and 1.x, also included in today's 1.28.11 release.

[zdohnal]

I've verified the fix Mike created. The steps for verification were:

2 machines - server and client

Server:

• install color printer

# lpadmin -p test -v ipp://<printer_ip>:631/ipp/print -m everywhere -E
# cupsctl --remote-any
# lpadmin -p test -o print-color-mode-default=monochrome

Now both commands - lpoptions -p test -l and lpoptions -p test - show monochrome/gray settings.

Client:
$ lpadmin -p local_test -v ipp://<server_ip>:631/printers/<remote_name> -m everywhere -E

Now lpoptions -p local_test and lpoptions -p local_test -l show gray or monochrome settings right after installation.

The same happens for temporary queue (although job options aren't available from lpoptions -p test_fedora) which is created from the data shared from server:

[user@fedora cups]$ lpstat -e
test_fedora
[user@fedora cups]$ lpoptions -p test_fedora -l
...
ColorModel/Output Mode: *Gray RGB
...

I've checked the print dialog in Evince and the temp queue has grayscale color mode by default.

@csfjeff however as Mike mentioned you need to have this fix applied in CUPS at sharing server and on clients as well, so to get this properly fixed in your environment you need to distribute the fixed CUPS you've built locally to all clients, or request Apple support to create an official update.

From OpenPrinting view, the bug is fixed by commit 98ac865 .