Fedora Account System
Red Hat Associate
Red Hat Customer
I've recently switched from to Fedora 42 (from Fedora 40). Since the upgrade, printing PDF files containing "š" and "ž" characters results in printouts that have small rectangles where characters "š" and "ž" should be printed. I've had a similar issue ~4.5 years ago with the same printer after upgrading to Fedora 33. See https://bugzilla.redhat.com/show_bug.cgi?id=1904405. Reproducible: Always Steps to Reproduce: 1. Set up HP ColorLaserJet MFP M281fdw via Gnome Settings (it defaults to "HP ColorLaserJet MFP M278-M281, driverless" driver). 2. Print the attached issue-with-šž-characters.pdf with Evince. Actual Results: Printed pages contain small rectangles in place of "š" and "ž" characters. Expected Results: Printed pages look the same as the PDFs viewed in Evince. Additional Information: Version of selected components: cups-filters-2.0.1-3.fc42.x86_64 Interestingly, my other Fedora 40 system (where printing works correctly) has: cups-filters-2.0.1-3.fc40.x86_64 Does this indicate an issue with some other component in the "printing stack"?
Created attachment 2092575 [details] A Slovene PDF with "č", "š" and "ž" characters. Only "č" characters printer correctly.
Created attachment 2092576 [details] A Slovene PDF with "č", "š" and "ž" characters. Only "č" characters printer correctly. Actual printer output.
Hi Tadej, long time no see :) - cups-filters got separated into 5 components - cups-filters, libcupsfilters, libppd, cups-browsed, and braille-printer-app, so there can be different version for one of other components. This is what I feared from https://github.com/OpenPrinting/libppd/issues/42 - we were working around the issue you reported in the past by prefering raster, but it broke some other functionality... see the libppd ticket. I've tried to reproduce the issue at that time to see if the issue disappeared, but it worked fine for me that day. I will see what I can do here.
Can you upload your PPD file, turn on debug logging in CUPS by 'cupsctl LogLevel=debug2', print the file and attach the debug logs? By default they are in journal on Fedora (journalctl -u cups JID=<job number>). Basically what I want to check is what final content type is used - I suspect it is PDF, which did not work for you. You can try to reinstall the printer with IPP Everywhere driver and see if the issue is present (lpadmin -p your-printer -v ipp://<ip>/ipp/print -m everywhere -E), but I suspect it will not make a difference, but it is good to try.
I'm able to reproduce the issue from evince with my HP printer, but not with my Canon one. It looks like it is really caused by PDF 1.7 generated by cairo from Evince, and only older devices (around 2018) or HP are affected - I have sent the input PDF generated by cairo to the printers without filtering and my HP showed the issue, while Canon (the newer model) did not. I will try to come up with a way how you can enforce rasterization for the job via command line, whether GTK will adopt any of it, I'm not sure.
I've come up with working solution - https://github.com/OpenPrinting/cups/pull/1282 - this way you can provide 'force-raster' to the job and printout will include diacritics.
@zdohnal, it has been a long time indeed :). Thanks for looking into this so quickly! I see that the upstream pull request got a quick review, too. Once things are in testable state, please let me know how I can test them on my end.
I've cleared all needinfo requests. Zdenek, please let me know if you need more info from my side.
I see that the upstream PR https://github.com/OpenPrinting/cups/pull/1282 has been merged. Is there a way I could use the new version with my Fedora 42, e.g. through a backported patch?
Hey Zdenek, would it be possible to backport the fix to Fedora 42's CUPS package? Probably it will take some time for the upstream to release the fix since it will be part of the upcoming 2.5 release (https://github.com/OpenPrinting/cups/milestone/6)?
Hi Tadej, I'm sorry - there are other emergencies I have to take care of, but I'm planning to release new CUPS project release, which will include the feature - and I will bring it into Fedora 42 as well (F41 too). Please bear with me until it happens - I hope I can release the version and make update in Fedora by the end of the week or at the beginning of the next. I'm sorry for inconvenience, Zdenek
Hi Zdenek, (In reply to Zdenek Dohnal from comment #11) > Hi Tadej, > > I'm sorry - there are other emergencies I have to take care of, but I'm > planning to release new CUPS project release, which will include the feature > - and I will bring it into Fedora 42 as well (F41 too). > > Please bear with me until it happens - I hope I can release the version and > make update in Fedora by the end of the week or at the beginning of the next. > > I'm sorry for inconvenience, thanks for your quick reply and thanks for sharing the plans for the upcoming CUPS release. I'm looking forward to it.
Hi Tadej! The feature is part of the current CUPS 2.4.14, which is now in Fedora 42 - you should be able to print with 'print-as-raster' option to lp command, or when you set the option as default for your print queue. Does the feature work for you?
Hi Zdenek, thanks for the info about the new CUPS release that includes the fix. I've upgraded my cups package to version 2.4.14. Can you help me with more detailed instructions on how to print my documents with the lp command and how to pass the 'print-as-raster' option? I don't see the option if I go to the printer's setting in the CUPS web configuration tool: http://localhost:631/printers/HP-ColorLaserJet-MFP-M278-M281 This is what I see: Description: HP Color LaserJet MFP M281fdw (36B6F0) Location: Doma Driver: HP Printer, driverless, 2.1.1 (color, 2-sided printing) Connection: dnssd://HP%20Color%20LaserJet%20MFP%20M281fdw%20(36B6F0)._ipp._tcp.local/?uuid=564e424e-4b39-3042-5332-48ba4e36b6f0 Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided
Printing should happen via "lp -d <printer> -o print-as-raster <file>" - it is described in "man lp". Setting it as default for the queue works via lpadmin - "lpadmin -p <printer> -o print-as-raster-default=true" - it is server option for cupsd for specific print queue (generic option how to set or remove server side option is described in 'man lpadmin'). I hope it helps - let me know if there are problems.
Hi Zdenek, thanks for specifying the commands I should try more precisely. The results are NOT how I expected them to be. 1. If I print the test document by running: 'lp -d HP-ColorLaserJet-MFP-M278-M281 issue-with-šž-characters.pdf' the printer prints diacritics just fine (i.e. output is OK). I'm attaching the corresponding CUPS logs for Job 103: lp_command_without_print_as_raster-output_ok.job103.log 2. If I print the test document by running: 'lp -d HP-ColorLaserJet-MFP-M278-M281 -o print-as-raster=true issue-with-šž-characters.pdf ' CUPS errors with (nothing is printed out): cupsd[165746]: [Job 104] Applying default options... cupsd[165746]: [Job 104] Adding start banner page "none". cupsd[165746]: [Job 104] Queued on "HP-ColorLaserJet-MFP-M278-M281" by "tadej". cupsd[165746]: [Job 104] Auto-typing file... cupsd[165746]: [Job 104] Request file type is application/pdf. cupsd[165746]: [Job 104] File of type application/pdf queued by "tadej". cupsd[165746]: [Job 104] Adding end banner page "none". cupsd[165746]: [Job 104] time-at-processing=1758229171 cupsd[165746]: [Job 104] Unable to print job using a supported raster format. cupsd[165746]: [Job 104] Unable to convert file 0 to printable format. cupsd[165746]: [Job 104] time-at-completed=1758229171 cupsd[165746]: [Job 104] Aborting job because it cannot be printed. cupsd[165746]: [Job 104] Unloading... 3. If I print the test document with Evince, the printer does NOT print diacritics OK (same squares as in the originaly attached document). I'm attaching the corresponding CUPS logs for Job 105: evince_output_bad.job105.log
Created attachment 2106960 [details] lp_command_without_print_as_raster-output_ok.job103.log
Created attachment 2106961 [details] evince_output_bad.job105.log
(In reply to Tadej Janež from comment #16) > 1. If I print the test document by running: > 'lp -d HP-ColorLaserJet-MFP-M278-M281 issue-with-šž-characters.pdf' > the printer prints diacritics just fine (i.e. output is OK). Good :) > > I'm attaching the corresponding CUPS logs for Job 103: > lp_command_without_print_as_raster-output_ok.job103.log > > 2. If I print the test document by running: > 'lp -d HP-ColorLaserJet-MFP-M278-M281 -o print-as-raster=true > issue-with-šž-characters.pdf ' > CUPS errors with (nothing is printed out): > cupsd[165746]: [Job 104] Applying default options... > cupsd[165746]: [Job 104] Adding start banner page "none". > cupsd[165746]: [Job 104] Queued on "HP-ColorLaserJet-MFP-M278-M281" by > "tadej". > cupsd[165746]: [Job 104] Auto-typing file... > cupsd[165746]: [Job 104] Request file type is application/pdf. > cupsd[165746]: [Job 104] File of type application/pdf queued by "tadej". > cupsd[165746]: [Job 104] Adding end banner page "none". > cupsd[165746]: [Job 104] time-at-processing=1758229171 > cupsd[165746]: [Job 104] Unable to print job using a supported raster format. > cupsd[165746]: [Job 104] Unable to convert file 0 to printable format. > cupsd[165746]: [Job 104] time-at-completed=1758229171 > cupsd[165746]: [Job 104] Aborting job because it cannot be printed. > cupsd[165746]: [Job 104] Unloading... This is strange - you did print as raster before, right? To be honest I tested the feature with CUPS IPP Everywhere driver, not with cups-filters' driverless one - it looks like cups-filters' PPD generator does not put image/urf or image/pwg-raster into PPD if PDF is supported. Would you mind trying reinstalling your printer with IPP Everywhere driver from CUPS? $ lpadmin -p <printer> -v 'dnssd://HP%20Color%20LaserJet%20MFP%20M281fdw%20(36B6F0)._ipp._tcp.local/?uuid=564e424e-4b39-3042-5332-48ba4e36b6f0' -m everywhere -E and trying if print-as-raster work for you then? > > 3. If I print the test document with Evince, the printer does NOT print > diacritics OK (same squares as in the originaly attached document). Yes, this is expected unless you set the server default for your print queue (the lpadmin command from my previous comment) which has IPP Everywhere driver. > > I'm attaching the corresponding CUPS logs for Job 105: > evince_output_bad.job105.log
(In reply to Zdenek Dohnal from comment #19) > > This is strange - you did print as raster before, right? I wouldn't know? > To be honest I tested the feature with CUPS IPP Everywhere driver, not with > cups-filters' driverless one - it looks like cups-filters' PPD generator > does not put image/urf or image/pwg-raster into PPD if PDF is supported. > > Would you mind trying reinstalling your printer with IPP Everywhere driver > from CUPS? Yes, I can try that. > $ lpadmin -p <printer> -v > 'dnssd://HP%20Color%20LaserJet%20MFP%20M281fdw%20(36B6F0)._ipp._tcp.local/ > ?uuid=564e424e-4b39-3042-5332-48ba4e36b6f0' -m everywhere -E I reinstalled my printer with IPP Everywhere driver. > and trying if print-as-raster work for you then? Now running 'lp -d HP-ColorLaserJet-MFP-M278-M281 -o print-as-raster=true issue-with-šž-characters.pdf' prints diacritics fine (i.e. output is OK). I'm attaching the corresponding CUPS logs: lp_command_with_print_as_raster-output_ok.job109.log The output is visually different from the 'lp -d HP-ColorLaserJet-MFP-M278-M281 issue-with-šž-characters.pdf' command though. I'm attaching the scans for and logs for both jobs. 1. lp_command_without_print_as_raster-output_ok.job108.log 2. lp_command_without_print_as_raster-output_ok.job108.actual_output.pdf 3. lp_command_with_print_as_raster-output_ok.job109.log 4. lp_command_with_print_as_raster-output_ok.job109.actual_output.pdf I'm interested in why the output is so different?
Created attachment 2106996 [details] lp_command_without_print_as_raster-output_ok.job108.log
Created attachment 2106997 [details] lp_command_without_print_as_raster-output_ok.job108.actual_output.pdf
Created attachment 2106998 [details] lp_command_with_print_as_raster-output_ok.job109.log
Created attachment 2106999 [details] lp_command_with_print_as_raster-output_ok.job109.actual_output.pdf
(In reply to Zdenek Dohnal from comment #15) > > Setting it as default for the queue works via lpadmin - "lpadmin -p > <printer> -o print-as-raster-default=true" - it is server option for cupsd > for specific print queue (generic option how to set or remove server side > option is described in 'man lpadmin'). I run 'lpadmin -p HP-ColorLaserJet-MFP-M278-M281 -o print-as-raster-default=true' to set the 'print-as-raster' option to 'true' by default. I validated the above setting by running the 'lpoptions' command. Here is the output: copies=1 device-uri=ipp://NPI36B6F0.local:631/ipp/print finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=1758280307 marker-colors=#00FFFF,#FF00FF,#FFFF00,#000000 marker-high-levels=100,100,100,100 marker-levels=52,98,10,0 marker-low-levels=10,10,10,10 marker-names='Cyan\ Cartridge\ HP\ CF541A,Magenta\ Cartridge\ HP\ CF543A,Yellow\ Cartridge\ HP\ CF542A,Black\ Cartridge\ HP\ CF540A' marker-types=toner,toner,toner,toner number-up=1 print-as-raster=true print-color-mode=color printer-commands=none printer-info='HP Color LaserJet MFP M281fdw (36B6F0)' printer-is-accepting-jobs=true printer-is-shared=true printer-is-temporary=false printer-location=Doma printer-make-and-model='ColorLaserJet MFP M278-M281 - IPP Everywhere' printer-state=3 printer-state-change-time=1758280322 printer-state-reasons=toner-low-warning printer-type=168028 printer-uri-supported=ipp://localhost/printers/HP-ColorLaserJet-MFP-M278-M281 However, printing the document with Evince still doesn't work (i.e. the printer does NOT print diacritics correctly). I'm attaching the corresponding CUPS logs: evince_output_bad.job112.log Didn't my 'lpadmin' command above not set the 'print-as-raster=true'?
Created attachment 2107000 [details] evince_output_bad.job112.log
(In reply to Tadej Janež from comment #20) > The output is visually different from the 'lp -d > HP-ColorLaserJet-MFP-M278-M281 issue-with-šž-characters.pdf' command though. I see difference in bold text, but I don't know which of those outputs follows the original PDF and which not. I would suspect either there is a firmware issue in the printer regarding PDF, or the PDF itself includes issue/oddity. The latter output went via Ghostscript to rasterize the data, so GS changes the data in PDF which caused changes in boldness. (In reply to Tadej Janež from comment #25) > However, printing the document with Evince still doesn't work (i.e. the > printer does NOT print diacritics correctly). > > I'm attaching the corresponding CUPS logs: > evince_output_bad.job112.log > > Didn't my 'lpadmin' command above not set the 'print-as-raster=true'? Aha, Evince does not set default attributes in IPP request as lp does - per https://openprinting.github.io/cups/doc/cupspm.html#submitting-a-print-job sending the defaults is not required to be added into print job request, so I have to handle this - the current solution just expects it being in the request. I have verified the fix from this scratch build this locally - https://koji.fedoraproject.org/koji/taskinfo?taskID=137382742 - would you mind testing it? Thank you in advance!
(In reply to Zdenek Dohnal from comment #27) > (In reply to Tadej Janež from comment #20) > > The output is visually different from the 'lp -d > > HP-ColorLaserJet-MFP-M278-M281 issue-with-šž-characters.pdf' command though. > > I see difference in bold text, but I don't know which of those outputs > follows the original PDF and which not. I think the 'print-as-raster' output seen in https://bugzilla-attachments.redhat.com/attachment.cgi?id=2106999 is closer to the original PDF (https://bugzilla-attachments.redhat.com/attachment.cgi?id=2092575). The original PDF doesn't have any bold text, everything should be the regular. > I would suspect either there is a firmware issue in the printer regarding > PDF, or the PDF itself includes issue/oddity. Yes, that might be the case. If you look at the output of 'lp -d HP-ColorLaserJet-MFP-M278-M281 issue-with-šž-characters.pdf' (https://bugzilla-attachments.redhat.com/attachment.cgi?id=2106997), you will see some text being printed as bold and some as regular. This unevenness makes the output look quite bad. > (In reply to Tadej Janež from comment #25) > > However, printing the document with Evince still doesn't work (i.e. the > > printer does NOT print diacritics correctly). > > > > I'm attaching the corresponding CUPS logs: > > evince_output_bad.job112.log > > > > Didn't my 'lpadmin' command above not set the 'print-as-raster=true'? > > Aha, Evince does not set default attributes in IPP request as lp does - per > https://openprinting.github.io/cups/doc/cupspm.html#submitting-a-print-job > sending the defaults is not required to be added into print job request, so > I have to handle this - the current solution just expects it being in the > request. Aha, thanks for the explanation. > I have verified the fix from this scratch build this locally - > https://koji.fedoraproject.org/koji/taskinfo?taskID=137382742 - would you > mind testing it? I'm happy to test it out. I've installed cups from the scratch build above, restarted cups and now Evince printed the testing PDF correctly. The output is the same as in https://bugzilla-attachments.redhat.com/attachment.cgi?id=2106999.
Ok, the patch was merged upstream, so I will make a new build with the patch.
FEDORA-2025-b4b5fbdddc (cups-2.4.14-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-b4b5fbdddc
FEDORA-2025-8be6653a2a (cups-2.4.14-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-8be6653a2a
FEDORA-2025-1abbc41388 (cups-2.4.14-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-1abbc41388
FEDORA-2025-48160c10cd (cups-2.4.14-2.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-48160c10cd
FEDORA-2025-b4b5fbdddc (cups-2.4.14-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Zdenek Dohnal from comment #29) > Ok, the patch was merged upstream, so I will make a new build with the patch. Thanks, Zdenek! One thing is still worrying me. What are now the steps to make printing work out of the box for Fedora users of HP ColorLaserJet MFP M281fdw? As far as I understand: 1. One would need to reinstall their printer with IPP Everywhere driver from CUPS by running: $ lpadmin -p HP-ColorLaserJet-MFP-M278-M281 -v 'dnssd://HP%20Color%20LaserJet%20MFP%20M281fdw%20(<id>)._ipp._tcp.local/?uuid=<uuid>' -m everywhere -E 2. And then set the 'print-as-raster' option to 'true' by default by running: $ lpadmin -p HP-ColorLaserJet-MFP-M278-M281 -o print-as-raster-default=true Should I file a new issue to tackle setting this by default for new users?
Ok, I thought I mentioned it earlier, but to reiterate - I do not expect the option to be turned on by default for this issue because: - not all users print documents with diacritics - although I'm one of such nation with diacritics :) , I don't want to impose this by default to others, especially the issue looks to be sometimes connected to specific PDF source and specific devices, - switch to raster is workaround, not a fix - it breaks other things (and it is expected to do not work with raster) which work with PDF completely fine, as finishings, so you don't want to hardcode rasterization into pipeline as we did in the past, - in general IMO it is a firmware issue which should be handled by firmware update if the device does not print correctly certain characters. So my idea behind this was to have a way how to force rasterization, but do not make it system wide default for a specific device - each user can decide whether it is something they want to set as default based on their use cases, knowing the cons of such decision. I could try to update libppd (driverless) PPD generator to show raster as well, so users are not locked in for IPP Everywhere and mention the issue in docs - https://pagure.io/fedora-docs/quick-docs/pull-request/897 - but I don't plan doing anything to change defaults, since it can unnecessary break other things.
FEDORA-2025-8be6653a2a has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-8be6653a2a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-8be6653a2a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-1abbc41388 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-1abbc41388` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-1abbc41388 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-48160c10cd has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-48160c10cd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-48160c10cd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-1abbc41388 (cups-2.4.14-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-48160c10cd (cups-2.4.14-2.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-8be6653a2a (cups-2.4.14-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Zdenek Dohnal from comment #36) > > I could try to update libppd (driverless) PPD generator to show raster as > well, so users are not locked in for IPP Everywhere I've created a follow up issue for this at https://bugzilla.redhat.com/show_bug.cgi?id=2413322.