CUPS 2.4.2 creates new printers with "Option print-color-mode monochrome" as default

[akorobkin]

Debian testing/bookworm, CUPS 2.4.2-1, cups-filters 1.28.15-1+build1. cupsd.conf, cups-files.conf are the debian default ones.

How to reproduce:

1. Create a new printer using a PPD that has DefaultColorModel: CMYK:

sudo lpadmin -p colorprintertest -E -m openprinting-ppds:0/ppd/openprinting/Ricoh/PS/Ricoh-MP_C3004_PS.ppd -v socket://printer 

2. Make sure its DefaultColorModel was CMYK from the start:

$ grep DefaultColorModel /etc/cups/ppd/colorprintertest.ppd
*DefaultColorModel: CMYK
$

2. Look into /etc/cups/printers.conf for the current printer options:

$ sudo cat /etc/cups/printers.conf 
# Printer configuration file for CUPS v2.4.2
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
NextPrinterId 2
<Printer colorprintertest>
PrinterId 1
UUID urn:uuid:e8403a11-9879-3a3d-7502-679f436a9976
Info colorprintertest
MakeModel Ricoh MP C3004 PS
DeviceURI socket://printer
State Idle
StateTime 1656009700
ConfigTime 1656009700
Type 8434172
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
Option print-color-mode monochrome
</Printer>

I see option Option print-color-mode monochrome is at the bottom for no apparent reason. How does it get there, and why monochrome, if the PPD is CMYK by default?

The printer thinks it is BW by default, too:

$ lpoptions -p colorprintertest -l | grep ColorModel
ColorModel/Color Mode: CMYK *Gray

[zdohnal]

Hi @akorobkin ,

this is an issue connected to our recent changes regarding sharing the default color model from server to clients (because some users don't check their settings before printing, so admins would like to set the default to monochrome - issue #277 ).

I think I see the reason - when we load PPD in scheduler/printers.c we don't take PPD default into account, only printer-color-mode.

I will try to create a fix today or at the start of the next week.

[akorobkin]

How do admins do it centrally? By setting print-color-mode-default per printer, or is there a new cupsd.conf keyword for it?

[michaelrsweet]

@akorobkin The defaults are per-printer. We could look at adding something in CUPS 2.5.x for a cupsd.conf override/default, but whatever we add I'd want to make sure it would carry over to CUPS 3.0's servers...

[ghewson]

Is there a workaround? Several people report that after upgrading to Ubuntu 22.04, they can't print in colour, and it seems to me that's related to this issue.

I'm using the Kubuntu variant, also version 22.04, with Gutenprint v5.3.3 on a Canon Pixma iP4850. The CUPS version is 2.4.1op1-1ubuntu4.1; I see that the change for Issue #277 was introduced in v2.4.1.

I tried:

lpadmin -p Canon_iP4800_series -o ColorModel=CMYK

but this had no effect; a test page is printed in greyscale. In fact, whatever option I put into the above command, only /etc/cups/ppd/Canon_iP4800_series.ppd is changed, and not /etc/cups/printers.conf. As with the OP, this file contains at the bottom:

Option print-color-mode monochrome

Using Kubuntu System Settings to change the configuration has the same effect (or non-effect) as lpadmin.

Any suggestions for a quick fix?

[michaelrsweet]

@ghewson Try:

lpadmin -p PRINTER -o print-color-mode-default=color

[ghewson]

@michaelrsweet Thanks, that works.

[csfjeff]

I'm the guy that requested the ability to set the print-color-mode-default attribute, and unfortunately I don't think the updates are quite doing what I was hoping for... it seems what should be 2 independent options: print-color-mode and print-color-mode-default are somewhat linked together...

The way I understand it, setting the print-color-mode to monochrome on CUPS applies a setting that forces every job to monochrome, and in my testing with Mac and iPad clients actually makes it completely impossible to print color. The print-color-mode-default attribute on the other hand, should just tell clients that they should choose monochrome as the starting option. That's how it seems to work with a real IPP Everywhere printer anyway.

Unfortunately with the recent CUPS changes it seems setting the print-color-mode-default also kicks in the print-color-mode, so it both tells clients to default to monochrome, but then also makes it impossible to print in color. The two settings should not be linked like that.

I'm guessing this is similar to what others are seeing where clients are unable to print to color.

I've started doing a bit more testing and definitely seeing some oddities around color printing with CUPS 2.4.2 - like initial testing seems to be suggesting that I can print color from MacOS but not from iPadOS, but I haven't dug into that very far.

[zdohnal]

Hi all,

I have prepared a fix for this problem at https://github.com/zdohnal/cups/tree/change_defaults . The testing verified the following design during printing:

• if no options are sent from application, cupsd uses the PPD default - in case there's no PPD default, use print-color-mode-default
• if there is a color related option from application, prefer it over PPD and print-color-mode in cups
• PPD and print-color-mode color settings are in synch - if you change one setting, the other will be updated to the new value as well

Then I've tested the fix in my environment and it worked (the correct color printout) in following scenarios:

Printing as directly to the actual printer:

• printing via lp without ColorModel (the PPD default was used), with ColorModel=Gray (got the gray output), with ColorModel=RGB (got the color output), regardless the default PPD option
• printing via evince - both colored and grayscale from print dialog, regardless of the default option (the option from print dialog got priority)
• printing via firefox - printing color if your default is gray doesn't work, reported to firefox in Fedora https://bugzilla.redhat.com/show_bug.cgi?id=2112314 , otherwise the printout is in expected
• the permanent driverless queue can have its default color option changed, the change survives reboot and is applied during printing

Printing in client+server setup - server shares the printer, client picks up a queue and print - either via permanent or temporary queue:

• server shares the color settings - if client creates a permanent queue, the PPD default is as it is set as it is shared from server, and the temporary queue respects the default as well (meaning when printing from 'lp' without options, it uses the default - applications can still set a different option...)
• 'lpoptions -p <temp_queue> -l' on client shows the default propagated from server

@akorobkin so in the end the option print-color-mode won't disappear from printers.conf, because it is needed there for cupsd to remember the default color option for possible sharing over network. However, the option will be now in synch with PPD default option and options from applications are prioritized.

Currently I have sent the fix for testing to Fedora users which had the problems with setting different defaults and printing color/monochrome and if it works for them, I'll create a PR here for review. After it is merged, I will release 2.4.3 with fix.

[zdohnal]

@csfjeff

it seems what should be 2 independent options: print-color-mode and print-color-mode-default are somewhat linked together...

AFAIU it is expected by design of IPP - if there is an attribute which supports multiple values and user can choose only one value, two attributes are passed during get-printer-attributes response - <attribute-name>-default=value and <attribute-name>-supported={values-list} - then a client (application) either adds <attribute-name>=<value_chosen_by_user_in_dialog> or doesn't add anything and value of <attribute_name>-default is used (its value is assigned to <attribute-name> and passed to the IPP packet). (Ed.: Formatting added to make IPP attribute usage schemes readable, please put any code between backticks.)

The way I understand it, setting the print-color-mode to monochrome on CUPS applies a setting that forces every job to monochrome, and in my testing with Mac and iPad clients actually makes it completely impossible to print color.

The similar response I got in Fedora - I've probably forgot to test the previous fix with applications and PPD options (because applications still pass PPD options into IPP requests instead of attributes).

The fix now lives on the private branch of my CUPS fork - in case you could compile CUPS it would be great if you tested it as well.

The print-color-mode-default attribute on the other hand, should just tell clients that they should choose monochrome as the starting option. That's how it seems to work with a real IPP Everywhere printer anyway.

That's how it is designed to work - however CUPS API cannot influence how it is implemented in applications - in case the application ignore the default settings and f.e. offers an option from previous session.

Unfortunately with the recent CUPS changes it seems setting the print-color-mode-default also kicks in the print-color-mode, so it both tells clients to default to monochrome, but then also makes it impossible to print in color.

The problem was about CUPS ignored color PPD option (which is deprecated) which is usually sent by applications - if the application had sent print-color-mode attribute, color printing would have worked.

[michaelrsweet]

@zdonal I think you want to put these changes into _cupsConvertOptions in cups/ppd-cache.c, since you probably want the same "explicit ColorModel overrides print-color-mode" logic applied everywhere.

@csfjeff The "xxx-default" attributes provide late binding of default values. So for your IPP Everywhere printer, if the Client doesn't specify the "print-color-mode" attribute then the current "print-color-mode-default" value is used at time of processing. Where things get tricky is that "print-color-mode" values are mapped to "ColorModel" values for PPD-based printers, so we need to only use "print-color-mode-default" if "ColorModel" is not specified.

[zdohnal]

@michaelrsweet AFAIU the commit https://github.com/OpenPrinting/cups/commit/b0f1a00a02e9f92f8a3c42ec90806ba4e4e532ec should do the trick in _cupsConvertOptions() for color printing. However configuration tools sends the ColorModel as well when they set a different default via CUPS-Add-Modify printer, so we need this conversion hack in add_printer() as well...

[zdohnal]

I've got feedback from one user, so I've created a new PR with fix - #451 .

[zdohnal]

Fixed by #451 - the option in printers.conf now properly reflex any changes regarding ColorModel or print-color-mode.

[akorobkin]

I compiled CUPS 2.4.2-1 (package from Debian Sid) with patches b0f1a00 and #451, restarted CUPS and added a new printer in exactly the same way as it's explained in the issue description. The printer again received an option Option print-color-mode monochrome in printers.conf file, even though the PPD has DefaultColorModel set to CMYK. Is it expected?

[zdohnal]

@akorobkin ahh... I have been using IPP generated PPDs in my testing, so I've totally missed the case when a person passes a classic PPD file or PPD generator... reopening, the printer creation supposes to reflect the default PPD option as well.

Thank you for checking this!

[csfjeff]

Hello, I'm hoping participate in testing this as well, as it has definitely impacted my environment. However while I'm somewhat competent with Linux, I'm shaky when it gets to compiling things and I'm having a hard time figuring out how to get this compiled and working.

Any pointers to some instructions or guidelines on how to get a test setup going ?

I generally use Ubuntu Server and have so far already tried the following:

1. A fresh Ubuntu, use apt to install cups, then download and compile CUPS from source. I can login to the UI, but whenever I try to add a printer after the last step it crashes and then I can't restart the service.
2. Again on a fresh Ubuntu install, use the snapcraft snap instructions to try and compile and install a snap version of cups, but despite managing to do this in the past, now I get a "Meson build error" saying that Make was not found, and a run-time dependency libsoup-3.0 was also not found.

[zdohnal]

@csfjeff IMO the most difficult part is the installation of dependencies which CUPS uses - I (since I'm on RPM based distro - Ubuntu will have something similar) use:

$ dnf download --source cups
$ sudo dnf -y builddep <downloaded_srpm>

It is not a bulletproof solution (the dependencies differ in case you will use different configure options than the package from OS), but still gives you an automatic dependency installation to some extent.

Then I try to remove CUPS provided by OS - this step I really do in a VM, because some components from desktop environments can depend on cups-libs, and cups-libs removal might remove your GUI in such cases :) - this step I do just to be sure my local compiled CUPS will be used.

In the end I call ./configure with options I chose (see ./configure -h), f.e.:

./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --with-rundir=/run --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-docdir=/usr/share/cups/www --enable-debug --enable-lspp --with-exe-file-perm=0755 --with-cupsd-file-perm=0755 --with-log-file-perm=0600 --enable-relro --with-dbusdir=/etc/dbus-1 --with-dnssd=avahi --with-tls=gnutls --enable-webif --with-xinetd=no --with-access-log-level=actions --enable-page-logging localedir=/usr/share/locale

, make and sudo make install - with the configure options above I get CUPS into the exactly same locations as it would be from CUPS package in Fedora Linux OS.

Regarding SNAP I cannot help you - I haven't compiled any SNAP package yet.

[zdohnal]

@akorobkin I came up with the fix for this - PPD default should be respected now with #500 .

[akorobkin]

@akorobkin I came up with the fix for this - PPD default should be respected now with #500 .

Thank you. Looks like it is working for my PPDs.

[jarau-de]

Unfortunately

lpadmin -p PRINTER -o print-color-mode-default=color

is not permanent. Same for editing 'printers.conf'. After printing it switches back to monochrome. This is rather annoying and I hope that it will be fixed soon. For meantime is there a simple way to make it permanent?

[Coeur-Noir]

Will this help in these situations : ⋅ https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1987528 ⋅ https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242

…and when ? For the moment I can't « upgrade x my machines to ×buntu 22.04 because of that issue with printing.

I don't « urge » in any way, could you give me an idea of the « process » ?

[zdohnal]

@Coeur-Noir This issue has already several use cases fixed in the current master branch, which your distro maintainers can backport and fix those use cases in *buntu. The links to the commits you can find in this issue.

The only corner case which is missing is the case when applications don't check the default options of the printer (if they still work with PPD options, they have to check for its IPP attribute counterpart), blindly puts another color related option into the list of options for the job and the destination is a remote CUPS server, which uses IPP protocol in communication with printer, but not IPP Everywhere driver. Since there is no adjusting of the option values, printout comes in a value set by IPP attribute and not in a value set by PPD option from application. This fix for this is in progress as PR #461.

If you want a new CUPS version with all fixes, there are three things I would like to tackle before new version:

• PR #461
• issue #619 which is regression from 2.4.1
• ippfind PR #620

Once those are fixed, I will proceed with a new version.

Unfortunately I'm currently stuck with packaging new cups-filters architecture into Fedora, so I don't have much time for it - if a new version or the corner case fix is urgent for you, it would be great if you looked into those issues and created PR, which I can review.

[zeus86]

unfortunately ubuntu doesn't seem to have adopted this into jammy/22.04 yet (https://packages.ubuntu.com/source/jammy/cups). I hope they eventually will. In my case for my kyocera-laser-printer it was necessary to set the color model for the printer with print-color-mode-default as well as print-color-mode, to be able to print in color, but it seemed to be persistent from then on (cups-2.4.1).

[haunma]

Please let me know if I should open a separate issue for this, but I think I am still having a similar problem with CUPS 2.4.7 in Void Linux. I am not 100% certain what version I had back in early December when I was successfully printing in color on a Canon ImageRunner office copier. I had to scrounge a PPD file to install the printer, and I print via Samba to a Windows queue maintained by our IT dept.

Today I noticed that I couldn't print in color no matter the ColorModel= setting. I compared the new/old printers.conf from a system update on December 27th and the only difference was the new (updated) printers.conf had the dreaded

Option print-color-mode monochrome

which was not there before.

To regain color printing ability I needed to delete that line and restart cupsd.

[akorobkin]

I have the same issue occurring randomly. Out of hundreds of printers on CUPS 2.4.7, a few would randomly get the print-color-mode option added in the printers.conf file. So far I can't figure out what is causing it and how to reproduce it reliably. -Alex

[luisvalenzuelar]

The suggested workaround (lpadmin -p PRINTER -o print-color-mode-default=color) does not work for me (Xubuntu 22.04.01). When running the command, I cannot access the printer's properties (click does nothing). Trying to access the properties opening the settings' GUI through command line (system-config-printer) gives this error:

TypeError: debugprint() takes 1 positional argument but 2 were given

Also, I cannot regain access to printer' setting by restarting CUPS. I need to manually remove the added line (Option print-color-mode color) from printers.conf in /etc/cups/and then restart CUPS to access printer's settings again.

[zdohnal]

@luisvalenzuelar Ubuntu 22.04 has version 2.4.1, which, unless the fixes were backported, does not contain any fixes regarding the issue. Contact your distro about the fixes.

[luisvalenzuelar]

@zdohnal So cups 2.4.6 (in upcoming ubuntu release) has solved the issue?

[zdohnal]

It should have - however, some applications can override the settings by passing printing option of different value. I have tested it with Fedora with CUPS 2.4.7 via lp today and it worked.