Created attachment 146347 [details] KDE Plasma - Print Color Settings Print Color Mode setting in the print dialogue is not reflected in print-out & all prints are in normal color mode STEPS TO REPRODUCE 1. Open a PDF in Okular 2. Open Print Dialogue: CTRL+P 3. select a physical (non PDF) printer 4. go to "properties" right next to printer name 5. go to "Advanced" tab 6. Switch "Print Color Mode" to monochrome 7. Print OBSERVED RESULT Print-out is color EXPECTED RESULT Print-out is black & white SOFTWARE/OS VERSIONS Operating System: Kubuntu 21.10 KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
Created attachment 146348 [details] KDE Plasma - Print Color Setting not available Sometimes, when selecting a different entry for the same physical printer model, the settings tab "Advanced" is not even available. Not understandable.
Created attachment 146350 [details] Firefox Print Dialogue Ironically, the following works: 1) open PDF file in Firefox 2) Open print dialogue (CTRL+P) 3) Change setting to color mode "black-white" 4) Print Outcome: Printout is in black-white.
I confirm this bug for: - Okular 21.12.3 - KDE Frameworks 5.92.0 - Qt 5.15.3 When "Mono" printing is selected via the "Properties" printer configuration dialog, output is in color anyways. In the past, Okular had a "Color Mode" selection in the "Options" tab of the print dialog (checked for Okular 0.20.2 in KDE 4.14.2). This no longer exists. It seems like okular somehow overrides the printer's settings with this kind of "Color Mode" selection, even though it doesn't exist in the print dialog anymore.
Created attachment 156547 [details] Print to PDF as grayscale I confirm this bug for: - Okular 22.08.3 - KDE Frameworks 5.102.0 - Qt 5.15.6 When "Mono" printing is selected via the "Properties" printer configuration dialog, output is in color anyways (Brother printer). The bug is present if you print to a PDF file too and you select grayscale in "Options", cf. OkularPrintPdfGrayscale.png attached file.
I have the opposite problem. Setting "Color Mode" to "Color", I always get a grayscale print. Seems to be a general problem with how Okular is transmitting color settings?
I can confirm this still happens for me with the latest KDE 6 on Arch. Is this a KDE or Qt bug after all? Anyone found a way to work around this?
Oddly enough, this happens if I use IPP Everywhere driver. In I use "deprecated" CUPS driver, then things work as expected. My printer is Brother DCP-L3550CDW, "deprecated" CUPS driver is https://aur.archlinux.org/packages/brother-dcpl3550cdw (repack of an official 32-bit one).
*** Bug 478631 has been marked as a duplicate of this bug. ***
Created attachment 171292 [details] system-config-printer printer option window on job options page with print-color-mode option highlighted My guess is, that this bug is related to a changed CUPS behavior. See https://github.com/OpenPrinting/cups/issues/421 and https://github.com/OpenPrinting/system-config-printer/issues/312. Namely, a default job option is set (print-color-mode monochrome/color) that does not seem to be overridden when selecting the color mode in the Advanced settings tab. It is not clear to me whether Okular is at fault here, but it possibly is, as system-config-printer does expose this job option. In any case—but this is likely bigger than this bug—it would be good if the print dialog also exposes the color mode for physical printers as it now does for print-to-pdf in the Options tab, next to the Double Sided Printing option.
(In reply to Erik Quaeghebeur from comment #9) > In any case—but this is likely bigger than this bug—it would be good if the > print dialog also exposes the color mode for physical printers as it now > does for print-to-pdf in the Options tab, next to the Double Sided Printing > option. This used to be the case until KDE 4 at least. The feature was subsequently removed for reasons unknown to me.
The bug is still present. Recently I had to set the printer as monochrome, due to the run-out of the color cartridge. but now, after changing the cartridge, I cannot manage to set back the Okular to the Color mode. It seems Okular doesn't keep the setting and continue keeping the old monochrome setting. Other applications like Gimp or Firefox work with my current color setting.
(In reply to mippo from comment #11) > The bug is still present. Recently I had to set the printer as monochrome, > due to the run-out of the color cartridge. but now, after changing the > cartridge, I cannot manage to set back the Okular to the Color mode. It > seems Okular doesn't keep the setting and continue keeping the old > monochrome setting. > Other applications like Gimp or Firefox work with my current color setting. System General Settings: Operating System: KDE neon 6.2 KDE Plasma Version: 6.2.1 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.8.0-47-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 7.5 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: Dell Inc. Product Name: Inspiron 7373
*** Bug 497746 has been marked as a duplicate of this bug. ***
Issue still present when printing to a PDF file using Okular 25.04.03. Is not everyone experiencing this problem? Operating System: KDE neon User Edition KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.11.0-29-generic (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 8 GiB of RAM (7.5 GiB usable) Graphics Processor: Intel® Xe Graphics Manufacturer: Dell Inc. Product Name: XPS 13 9305
A couple of comments: 1. In /some/ cases, the problem can be worked around by ticking the entry in the print dialog that "forces rasterization". Probably this happens because when you rasterize /before/ printing, the rasterization itself happens in BW. However, even when this trick works, it is rather sub-optimal because it may slow down printing significantly and decrease the print quality. 2. If you open the `system-config-printer` application and you double click on the printer, you will see a dialog from which you can configure the (default) "job options". Typically, you will find there an option regarding the print color mode. Changing the default option from this dialogue will generally make the printer switch from color mode to BW and viceversa as expected. So it looks like there is a problem in the qt print dialog that does not pass the print color mode option to the printing backend in a way that is suitable for overriding the default. Maybe, but this is just a hypothesis, this is because the print color mode is not managed at all by the Qt-print dialog as a job option (like duplex for example), but as an advanced printer property.
(In reply to Sergio from comment #15) > A couple of comments: > > 1. In /some/ cases, the problem can be worked around by ticking the entry in > the print dialog that "forces rasterization". Probably this happens because > when you rasterize /before/ printing, the rasterization itself happens in > BW. However, even when this trick works, it is rather sub-optimal because it > may slow down printing significantly and decrease the print quality. > > 2. If you open the `system-config-printer` application and you double click > on the printer, you will see a dialog from which you can configure the > (default) "job options". Typically, you will find there an option regarding > the print color mode. Changing the default option from this dialogue will > generally make the printer switch from color mode to BW and viceversa as > expected. So it looks like there is a problem in the qt print dialog that > does not pass the print color mode option to the printing backend in a way > that is suitable for overriding the default. Maybe, but this is just a > hypothesis, this is because the print color mode is not managed at all by > the Qt-print dialog as a job option (like duplex for example), but as an > advanced printer property. Hi Sergio, Your 'Force rasterisation' suggestion works a treat, and with no discernible impact on print speed or quality. As a matter of possible interest, my motivation was that printing a colour document to my black and white printer was giving a blank - not black, interestingly - page. Converting it to a grayscale PDF file first was a workaround for that. Thank you. P
I have looked a bit more into this. My conclusions: 1. I do not think that this is an issue in okular at all. 2. The problem is with cups, but won't be fixed because cups developers think they are right and that printer manufacturers are wrong. See the exchange at https://github.com/OpenPrinting/cups/issues/1364#issuecomment-3292398029. They seem not to care very much about the fact that you need to print on real world printer that work in the way their manufacturers choose. They might well not be right either. But still "don'tfix". 3. You see the issue with okular and not with other PDF viewers, because when you ask to print in B/W, okular passes the original job to the printer driver telling it to print in B/W, while most viewers rasterize it in B/W to start with. But I think that the okular behavior is the correct one. 4. Given the fact that the problem in cups won't be fixed, at this point there are only two possible solutions. The first one is to use printers only via driverless printing for which the color/BW selection works. Unfortunately, this is often not something that can be done. Not all printers support driverless operation and even for those that do, cups in this mode often gives you an unacceptably bad rasterization (experiencing this with Brother and Canon printers). The second solution is to set up two different queues, one for B/W printing and the other one for color printing. This is basically, installing each printer twice and set the color/BW mode at the printer install time (i.e. at the queue level). Also horrible, but probably the best solution.
My two cents are: consider closing the issue in okular as invalid, because the issue is almost certainly not in okular.
As a final note: Assuming that cups developers maintain their point that they will not consider users who have printers that use "non standard" option keywords in their advanced options to choose between color and B/W printing, one way to work around the problem would be to have the cups printer dialog itself enhanced to let one control the "print-color-mode" (IPP) attribute.
Sorry for the typo: not the cups print dialog, the QT print dialog. But again, this is no okular problem, but a Qt one.