Bug 1985917

Hi Attila,

thank you for reporting the issue!

It would be great if you provided your model name and how your printer is installed (permanent/temp queue, if permanent then driverless/driver) at least.

Then I could have directed you to the specific steps how to get data I will need to investigate, so now I will provide broader instructions:

A) If your printer is installed permanently with driver and backend from hplip (you get this usually using 'hp-setup' for creating a queue), do follow the steps from [1]

B) If your printer is not installed via hplip, provide the date from [2].


Thank you in advance!


[1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#I_have_HP_printer.2C_installed_it_with_HPLIP_and_have_a_problem_with_it
[2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#My_printer_doesn.27t_print_correctly_or_at_all.2C_but_I_can_see_the_printer_in_print_dialog

Created attachment 1807095 [details]
CUPS log Job ID

Created attachment 1807096 [details]
CUPS log

Created attachment 1807097 [details]
Testpage

Created attachment 1807098 [details]
PPD file

Hi,

thank you for your quick reply.
The model of the printer is: Hewlett-Packard HP Color LaserJet flow MFP M880.
I didn't mention the model because even "print to PDF" ignores "black and white".

You will find the requested data for investigations attached. Here you go.
Let me know if the data is not complete.

Thank you for the data!

I checked with my colleague who has an access to colored printer (I have only grayscale printer at home, we have Canon imageRunner at the office), and grayscale printing worked for him, so the issue doesn't affect everyone (it will a driver specific).

I've checked your driver - you use driver from HPLIP on your IPP queue - did you try if grayscale works for IPP everywhere/Airprint (if your device supports it)?

It would be great if you tested the two following queues:

$ lpadmin -p hp-eve-m880-1 -v ipp://192.168.2.23:631/ipp/print -m everywhere -E

$ lpadmin -p hp-eve-m880-2 -v ipp://192.168.2.23:631/ipp/print -m driverless:ipp://192.168.2.23:631/ipp/print -E

Ad job log - I see 'ColorModel=Gray' is applied as a job option, but no such option is defined in PPD - so I would like to see how the printer reacts in driverless scenarios.

Here the results.

1. lpadmin -p hp-eve-m880-1 -v ipp://192.168.2.23:631/ipp/print -m everywhere -E

-> The printout is coloured

2. lpadmin -p hp-eve-m880-2 -v ipp://192.168.2.23:631/ipp/print -m driverless:ipp://192.168.2.23:631/ipp/print -E

-> It doesn't work. No printout.

Your colleague could produce a black and white printout on a colour printer, but even if it sounds strange I don't think the issue is driver specific. Is that Fedora specific?

Now I ask you to do me a favour. Could you please print a document of your choice to a file "print to PDF" and check the printout? I think we don't need a real printer to investigate this issue, because "print to PDF" will do the job. This is the same issue I mentioned in my description "even "print to PDF" produces colour output".

Thanks in advance.

(In reply to Attila from comment #8)
> Your colleague could produce a black and white printout on a colour printer,
> but even if it sounds strange I don't think the issue is driver specific. Is
> that Fedora specific?

He has Fedora 34, otherwise I wouldn't have asked him to test. So IMO it is a driver/model specific.

> 
> Now I ask you to do me a favour. Could you please print a document of your
> choice to a file "print to PDF" and check the printout? I think we don't
> need a real printer to investigate this issue, because "print to PDF" will
> do the job. This is the same issue I mentioned in my description "even
> "print to PDF" produces colour output".

"print to PDF" destination doesn't go via CUPS, it is a GTK specific thing, I'm not sure how color management is applied there. I would focus on the real printers.

I've tested with other colored printer available in our office with help of my other colleague with F34 - grayscale works for him, but if I send the job on the printer with lp, I got colored printout.

Looks like it is something within our configuration/installation.

I'll look into it more once I'm at the office.

I have tried something else. When I login to the server where all the printers are installed, the printout come out black and white as expected. So far so good, that works.

What doesn't work is to print from any client. I have never installed any printer or driver on the client side because the printers are served by server.
I have noticed that the PPD-File on the client side is by far smaller then on the server side. I think this one is generated by the service cups-browsed.

Can this additional information help you to come up with new ideas? let me know if you need more details.

(In reply to Attila from comment #10)
> What doesn't work is to print from any client. I have never installed any
> printer or driver on the client side because the printers are served by
> server.

Interesting - that would have meant your local print queue is temporary (if the server is in the same LAN) or the queue is created by cups-browsed (if it is running).

But none of those makes sense regarding the logs and data you provided - a temporary queue wouldn't have had a PPD (the queue is always cleaned up after printing) and a queue created by cups-browsed would have had an implicitclass backend instead of ipp which your logs show.

> I have noticed that the PPD-File on the client side is by far smaller then
> on the server side. I think this one is generated by the service
> cups-browsed.
> 

It can be - however as I wrote above, it doesn't match with data you provided. Are they accurate, taken from the client?

Because right now logs show it is an IPP queue with HPLIP PPD, which you can get only by manual installation (lpadmin/CUPS web ui/any print settings tool).

Created attachment 1810752 [details]
Client CUPS log Job ID

Created attachment 1810754 [details]
Client CUPS log

Created attachment 1810755 [details]
Client PPD file

I have attached the logs from the client side. Hope this will help.

Ok, now the logs show the queue is created by cups-browsed.

So is the first set of data you uploaded connected to some job from client? I mean if they are CUPS logs which were reported once a job from client arrived.

If they are, it would be great to see logs for job you issued on the server directly and went out gray.

My current idea is that there is a difference in which filters are run - some don't do color management for the file.

Created attachment 1810810 [details]
Server CUPS log

Created attachment 1810811 [details]
Server CUPS log Job ID

The first set of data I have uploaded were generated on the server but printed on client. The printout is in colour.

The second set of data I have uploaded were generated on the client and printed on client. The printout is in colour.

The third set of data I have uploaded were generated on the server and printed on server. The printout is black and white as expected.

What I have seen so far is the following:

- The printout is colour when ColorModel=Gray is passed to argv[]
- The printout is black and white when HPColorAsGray is passed to argv[]

Have you been able to inspect the logs in the meantime?

Sorry - I haven't looked into the issue since the last time, sorry. The last finding is that 'print-color-mode=color' is set as a default job option, which is set in some ocassions, but wasn't able to track when and why it is set.

The default job options can be listed by:

$ lpoptions -p <queue>

On the client:
lpoptions -p HPM880
copies=1 cups-browsed=true device-uri=implicitclass://HPM880/ finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 media=iso_a4_210x297mm number-up=1 orientation-requested=0 output-bin=none print-color-mode=color printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info=HPM880 printer-is-accepting-jobs=true printer-is-shared=false printer-is-temporary=false printer-location printer-make-and-model='HP Color LaserJet flow MFP M880 Postscript (recommended), driverless, cups-filters 1.28.9' printer-state=3 printer-state-change-time=1629093261 printer-state-reasons=none printer-type=10661982 printer-uri-supported=ipp://localhost/printers/HPM880 sides=one-sided

On the server:
lpoptions -p HPM880
copies=1 device-uri=ipp://192.168.2.23/ipp/ finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=ReportLevels printer-info='Hewlett-Packard HP Color LaserJet flow MFP M880' printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location='###' printer-make-and-model='HP Color LaserJet flow MFP M880 Postscript (recommended)' printer-state=3 printer-state-change-time=1629111843 printer-state-reasons=none printer-type=8564956 printer-uri-supported=ipp://localhost/printers/HPM880

I have changed the default setting on the server from colour to black and white. I am not able to print in colour with this default settings from the client. So it does really matter what settings are made on the server and this specifications overwrite the options I choose on the client.

(In reply to Zdenek Dohnal from comment #9)
> I've tested with other colored printer available in our office with help of
> my other colleague with F34 - grayscale works for him, but if I send the job
> on the printer with lp, I got colored printout.
> 
> Looks like it is something within our configuration/installation.
> 
> I'll look into it more once I'm at the office.

Have you been to the office to look more into the issue?
Are there any new findings?
I am really interested in a fix.

Sorry, I didn't have much time for the issue, but here is something I've found in the last hour or two:

I'm able to print grayscale from evince, but not from classic lp commands - and 'lpoptions -p' shows 'print-color-mode-color' either way, but it doesn't get into the job options if I print from evince.

I set _cupsGetDests() to ignore print-color-mode-default attribute and the printouts are correct for color and grayscale.


What I haven't still managed to find out is when the attribute is set on the print queue, because the attribute shows up only on my full workstation, but I don't see it in my VM which was primary non-GUI, so my guess it is somehow related to colord and the communication with it...

I hope I'll get into this soon, but still I have a lot of stuff on the plate :( .

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Hi Attila,

I have been working in CUPS upstream on similar issue which raised during release of version 2.4.1, and tried to reproduce my solution with your setup - and I was able to get the correct color with it.

Have you upgraded to Fedora 36? I have the fix prepared on private upstream branch, and currently I'm building testing rpms for F36, so I can pass the testing rpms right away if you have F36 already...

In case you are still on F35, let me know and I will try to backport the fix.

Hi,

Cups 2.4.2-1 is available On Fedora 36.

I have tested the printing in black and white from various application like Libreoffice, Firefox, Thunderbird, KWrite, Gwenview and Master PDF Editor. The output is black and white as expected.

There is one exception so far as I can see and this is Okular. Okular still prints in colour.

Let me know if you want me to test a higher version of Cups.

Just to be sure - color printing works as well? There are bugs in F36 which are about not being able to switch color settings, so I would like to know whether it works for you.

Can you attach the debug log when you print from Okular?

Thank you in advance!

Thank you for your quick reply.

(In reply to Zdenek Dohnal from comment #29)
> Just to be sure - color printing works as well? There are bugs in F36 which
> are about not being able to switch color settings, so I would like to know
> whether it works for you.

Yes, colour printing works.

> 
> Can you attach the debug log when you print from Okular?

Please check for the printer HPM880 in the attached file.

> 
> Thank you in advance!

Created attachment 1903500 [details]
Cups debug from client (print from Okular)

Ok, it seems the fixed rpms should help you - can you try them (F36) https://koji.fedoraproject.org/koji/taskinfo?taskID=90399669 ?

Hi,

here is what I did:

dnf update cups-2.4.2-3.fc36.test.x86_64.rpm cups-client-2.4.2-3.fc36.test.x86_64.rpm cups-filesystem-2.4.2-3.fc36.test.noarch.rpm cups-ipptool-2.4.2-3.fc36.test.x86_64.rpm cups-libs-2.4.2-3.fc36.test.x86_64.rpm

The good news is, the fixed rpms work as well like the official rpms by Fedora.
The bad news is, Okular still print in colour. I think this is a bug in Okular, because when I print to file the result is always in colour. What do you think?

(In reply to Attila from comment #33)
> The bad news is, Okular still print in colour. I think this is a bug in
> Okular, because when I print to file the result is always in colour. What do
> you think?

Ok, I've set up the environment for reproducing the issue - and I've found out that okular can't do temporary queues and reported it here https://bugzilla.redhat.com/show_bug.cgi?id=2117478 .

So I had to use cups-browsed or install the shared destination permanently to reproduce.

After all of that, I've found out Okular does not sanitize the options it sends to CUPS, so it sends duplicated value for color - ColorModel from print dialog, and print-color-mode from printer defaults, and doesn't check/update options based on user's choice.

I'll try to merge those two options on other place in IPP backend, so it should work even for this use case.

Thank you for all the efforts and explanation you made. I have to praise you and give you 10 of 10 points.

Hi Attila,

here we go again - this time the build should work even for Okular - https://koji.fedoraproject.org/koji/taskinfo?taskID=91210382 - upgrading CUPS on client should be sufficient.

Would you mind testing it and telling me whether it helps?

Thank you in advance!

Hi,

sure I will test it. Unfortunately I don't have access to the printer right now. I will report back in 14 days.
Thanks anyway in advance.

Created attachment 1907498 [details]
Testing rpms

Attila,

thank you for letting me know! The scratch build will disappear in the meantime, so I've uploaded the testing rpms for now.

Since I have a feedback from a different bug as well, I will pass the fixes upstream as well - maybe the fix will be in testing repo or even in stable once you get to the printer.

Hi,

I was able to test the "testing rpms" (cups-2.4.2-4.fc36.test.1.x86_64.rpm).
It works now for Okular as well. You did an excellent job. Many thanks.
I am melting away, because it just works.

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

FEDORA-2023-fa7bac0197 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa7bac0197

FEDORA-2023-d212cc5f13 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d212cc5f13

FEDORA-2023-fa7bac0197 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-fa7bac0197`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa7bac0197

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-d212cc5f13 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d212cc5f13`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d212cc5f13

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-fa7bac0197 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-d212cc5f13 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.