Created attachment 1736401 [details] A Slovene PDF with čžš characters. Description of problem: Printing a PDF with Slovene accented characters (i.e. čžš) results in some of them printed as squares. Version-Release number of selected component (if applicable): cups-filters-1.28.5-3.fc33.x86_64 How 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
Created attachment 1736404 [details] lpstat -t
Created attachment 1736405 [details] sudo lpinfo -l -v
Created attachment 1736407 [details] HP-ColorLaserJet-MFP-M278-M281.ppd
Created attachment 1736408 [details] sudo journalctl -u cups JID=19
Created attachment 1736409 [details] /var/spool/cups/d00019-001
Created attachment 1736410 [details] Scan of actual Slovene PDF with čžš characters printout
Created attachment 1736411 [details] /tmp/ps of command 'sudo lpadmin -p test-printer -v file:/tmp/ps -P /etc/cups/ppd/HP-ColorLaserJet-MFP-M278-M281.ppd -E'
Hi Tadej, thank you for reporting the issue and providing the data at the start! It helps a lot! I tried to print the file with your ppd to file device printer and got the same result as you - the file has the special characters shown correctly after filtering. So my suspicion is: 1) it is a printer bug (I would say more probable) 2) (this is just a theory, because it is only two things remaining for the job to get to the printer, but their main purpose is transport, not playing with file encoding...) dnssd and ipp backends does something with encoding Please try the following: ========================= 1) Would you mind trying to reinstall the print queue in a way to have IPP backend instead of DNSSD backend and then trying to print? If GNOME doesn't provide a print queue with IPP, you can install it via CLI: Prereq: get IPP device uri from 'sudo lpinfo -l -v' - it can look like: ipp://<service_name>._ipp._tcp.local/ , ipp://<mdns_hostname>:631/ipp/print , ipp://<hostname>:631/ipp/print or ipp://<ip>:631/ipp/print Then: $ sudo lpadmin -p <name> -v <ipp_uri> -m driverless:<ipp_uri> -E 2) Would you mind attaching output of ipptool output for ipp uri? It will contain attributes which your printer advertises and PPD is generated based on them, so I can see if there is any error during generating PPD. Thank you in advance!
Created attachment 1738353 [details] ipptool_log Output of: ipptool -tv "ipps://HP%20Color%20LaserJet%20MFP%20M281fdw%20(36B6F0)._ipps._tcp.local/" get-printer-attributes.test &> ipptool_log
Hi Zdenek, thanks for looking into this. (In reply to Zdenek Dohnal from comment #8) > > So my suspicion is: > > 1) it is a printer bug (I would say more probable) Huh... I recently upgraded from Fedora 31 and in Fedora 31 (and previous versions) I had the option to use the "classical", non-driverless driver for my HP M281fdw printer. I had no issues with čžš characters with that driver. Is that driver not available anymore in Fedora 33? > 2) (this is just a theory, because it is only two things remaining for the > job to get to the printer, but their main purpose is transport, not playing > with file encoding...) dnssd and ipp backends does something with encoding > > Please try the following: > ========================= > > 1) Would you mind trying to reinstall the print queue in a way to have IPP > backend instead of DNSSD backend and then trying to print? If GNOME doesn't > provide a print queue with IPP, you can install it via CLI: > > Prereq: get IPP device uri from 'sudo lpinfo -l -v' - it can look like: > ipp://<service_name>._ipp._tcp.local/ , ipp://<mdns_hostname>:631/ipp/print > , ipp://<hostname>:631/ipp/print or ipp://<ip>:631/ipp/print > > Then: > $ sudo lpadmin -p <name> -v <ipp_uri> -m driverless:<ipp_uri> -E > I managed to install it via GNOME Settings by manually entering printer's IP. The IPP URI is: ipps://HP%20Color%20LaserJet%20MFP%20M281fdw%20(36B6F0)._ipps._tcp.local/ > 2) Would you mind attaching output of ipptool output for ipp uri? It will > contain attributes which your printer advertises and PPD is generated based > on them, so I can see if there is any error during generating PPD. > I've attached the output of the ipptool. I hope it helps! Thanks!
(In reply to Tadej Janež from comment #10) > > So my suspicion is: > > > > 1) it is a printer bug (I would say more probable) > > Huh... I recently upgraded from Fedora 31 and in Fedora 31 (and previous > versions) I had the option to use the "classical", non-driverless driver for > my HP M281fdw printer. > I had no issues with čžš characters with that driver. > > Is that driver not available anymore in Fedora 33? > It should be. From F33 machine (if hplip installed): # lpinfo -l -m | grep -i m281 Model: name = lsb/usr/HP/hp-color_laserjet_mfp_m278-m281-ps.ppd.gz make-and-model = HP ColorLaserJet MFP M278-M281 Postscript device-id = MFG:Hewlett-Packard;MDL:hp-color_laserjet_mfp_m278-m281; Although I would like to solve the issue for driverless printing, because it is the modern way of printing. I'll contact upstream with the data.
You can try: $ lp -d <printer> -oraw <'d' file from /var/spool/cups> which sends the file unfiltered in the meantime and tell me if it helps - the file in /var/spool/cups is a pdf and the printer tells it supports pdf, so it should be okay. This should tell us whether there is a really issue in filter chain, although evince shows the correct character when printing to file.
Reported here https://github.com/OpenPrinting/cups-filters/issues/331
Tadej, would you mind trying the following steps too? 1) Send the original pdf to the printer unfiltered $ lp -d <printer> -o raw <original_pdf,not_d_file> 2) Send the file, which was filtered by filter chain, to the printer unfiltered $ lp -d <printer> -o raw <tmp_ps_file> Together with printing 'd file' unfiltered (mark is as 0. step here) will gives the following piece of information: - if 1) prints ok and 0. prints bad, then PDF viewer makes a change in PDF, which printer doesn't like - if 1) and 0. prints ok, but 2) prints bad, then filter chain makes a change in PDF, which printer doesn't like
Created attachment 1739423 [details] Scan of printout of command: 'lp -d HP-ColorLaserJet-MFP-M278-M281 -o raw d00019-001'
Created attachment 1739424 [details] Scan of printout of command: 'lp -d HP-ColorLaserJet-MFP-M278-M281 -o raw issue-with-čžš-characters.pdf'
Created attachment 1739425 [details] Scan of printout of command: 'lp -d HP-ColorLaserJet-MFP-M278-M281 -o raw ps'
Zdenek, thanks for following up and reporting this to cups-filters upstream. (In reply to Zdenek Dohnal from comment #14) > > Together with printing 'd file' unfiltered (mark is as 0. step here) will > gives the following piece of information: > > - if 1) prints ok and 0. prints bad, then PDF viewer makes a change in PDF, > which printer doesn't like This indeed appears to be this case. As you can see from the attached scanned printouts, 0. prints bad and 1. prints čžš characters ok. However, the fonts on 1. seem to be different from what is shown with the PDF viewer (Evince). Also, some things appear to be in bold face and some not, whereas the PDF viewer shows them all in the case (non-bold) face... > - if 1) and 0. prints ok, but 2) prints bad, then filter chain makes a > change in PDF, which printer doesn't like In my experiment, 2. prints the same as 0.
(In reply to Zdenek Dohnal from comment #11) > (In reply to Tadej Janež from comment #10) > > > So my suspicion is: > > > > > > 1) it is a printer bug (I would say more probable) > > > > Huh... I recently upgraded from Fedora 31 and in Fedora 31 (and previous > > versions) I had the option to use the "classical", non-driverless driver for > > my HP M281fdw printer. > > I had no issues with čžš characters with that driver. > > > > Is that driver not available anymore in Fedora 33? > > > > It should be. From F33 machine (if hplip installed): > > # lpinfo -l -m | grep -i m281 > Model: name = lsb/usr/HP/hp-color_laserjet_mfp_m278-m281-ps.ppd.gz > make-and-model = HP ColorLaserJet MFP M278-M281 Postscript > device-id = MFG:Hewlett-Packard;MDL:hp-color_laserjet_mfp_m278-m281; Thanks for this info. I've manually switched the driver to this one and the test PDF (A Slovene PDF with čžš characters) prints čžš characters as it should and the printout's font also matches what I see in the PDF viewer (Evince).
Created attachment 1739450 [details] Scan of Slovene PDF with čžš characters printout obtained via HP ColorLaserJet MFP M278-M281 Postscript driver
It seems like a combination of printer bug (doesn't work properly with some fonts within PDF) and a font bug (probably fontforge). The printer bug is connected only to PDF document format (the format which printer accepts without additional conversion), because printing with postscript document format works fine (classic driver uses postscript as the document format). Do you have a way to try upgrading firmware for your printer before we take it to fontforge? I checked some HP reports about upgrading firmware and it should be available on device web site. If you manage to upgrade firmware, please try printing with driverless again. In all case please let me know if it helps or not.
(In reply to Zdenek Dohnal from comment #21) > > Do you have a way to try upgrading firmware for your printer before we take > it to fontforge? I checked some HP reports about upgrading firmware and it > should be available on device web site. > > If you manage to upgrade firmware, please try printing with driverless > again. In all case please let me know if it helps or not. I've upgraded the firmware on the printer from datecode 20171210 to datecode 20200612. I've upgraded directly on the printer via: Setup > Service > LaserJet Update. Note that the official web site says there is a newer firmware datecode available, namely 20201021: https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-color-laserjet-pro-m280-m281-multifunction-printer-series/14142489/model/14142491/swItemId/Im-194878-7 But the LaserJet Update on-printer utility reports the printer's firmware is up-to-date. The results/printer's output didn't change and are the same as in comment #18.
Hi Tadej, thank you for trying the firmware update. It really looks like an printer bug for PDF document format - upstream attempts to workaround the issue by changing filter priorities - now image/urf as the Apple raster will be preferred. Would you mind testing the following rpms if they help? https://koji.fedoraproject.org/koji/taskinfo?taskID=59435558 You will need to reinstall the queue with 'driverless' driver again, because the PPD has to be regenerated.
Hi Zdenek, thanks for providing the new cups-filters RPMs. I've installed them and reinstalled the printer. Unfortunately, the new cups-filters package doesn't fix the issue. What is printed is the same as in https://bugzilla.redhat.com/attachment.cgi?id=1736410. I've double checked the new PPD file and it looks correct (I'll attach it to the report.)
Created attachment 1747771 [details] HP-ColorLaserJet-MFP-M278-M281-cups-filters-1.28.7-1.ppd
Thanks for the info, Tadej! Can you upload job log for this job? I checked the job log with file device queue and only pdftopdf filter was run - I thought rastertopdf should be run if image/urf is preferred. I would like to check if it is the same with a real printer. I'll pass the info to upstream and create bug on evince.
Created attachment 1748834 [details] sudo journalctl -u cups JID=62 (In reply to Zdenek Dohnal from comment #26) > Thanks for the info, Tadej! Can you upload job log for this job? I'm uploading the job's log file. > I checked the job log with file device queue and only pdftopdf filter was > run - I thought rastertopdf should be run if image/urf is preferred. I would > like to check if it is the same with a real printer. Hmm... from what I can see, rastertopdf was not run on my end either?
(In reply to Tadej Janež from comment #27) > > I checked the job log with file device queue and only pdftopdf filter was > > run - I thought rastertopdf should be run if image/urf is preferred. I would > > like to check if it is the same with a real printer. > > Hmm... from what I can see, rastertopdf was not run on my end either? Yep, that's the case - I thought rastertopdf should be run (it is the filter mentioned in --with-apple-raster configure option), but according Till (cups-filters author) pdftoraster or gstoraster should be run, so it is really interesting. Would you mind going through the steps in comments #12 and #14 with new cups-filters? What I mean: 1) print the original file unfiltered via lp to the real printer- does 'the bold issue' showed itself? 2) print via evince to file device print queue (created with ppd HP-ColorLaserJet-MFP-M278-M281-cups-filters-1.28.7-1.ppd) 3) check the current 'd' file in /var/spool/cups - open it in viewer and check for diacritics - tell me the results and send the file unfiltered to the real printer - are diacritics missing? 4) now we should check output of filters, but currently there is only one filter used, so we can use /tmp/ps file - check it via viewer, are diactirics missing? And send to the printer unfiltered - are diacritics missing? And in the end please attach the current 'd' file here. Thank you again for your cooperation! I know it is demanding, but the problem is it is manifested only during printing :( ... Tip: ---- I myself had a similar issue (I am Czech and tried to print out czech taxes docs :D ) with my printer and an other pdf - what helped me was running the original pdf via ghostscript: $ gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=out.pdf input.pdf and then print it via 'lp' $ lp -d <print_queue> out.pdf The original PDF is created in Adobe and I wasn't capable of printing the correct document regardless of the client (lp, evince, libreoffice). Fontforge couldn't open the pdf too, only regenerating the pdf via ghostscript helped and lp didn't touch the pdf as evince or libreoffice does...
The filter which we need to run has a high cost in coversion table (CUPS has its own conversion table for deciding which filters are run for a specific files), so we need to raise cost of application/pdf line in your ppd. So before you do the stuff from comment above: 1) stop cups 2) change line from: *cupsFilter2: "application/vnd.cups-pdf application/pdf 100 -" to *cupsFilter2: "application/vnd.cups-pdf application/pdf 200 -" 3) restart cups (changing this started the expected filters for my file device queue) Now please try to print the original pdf from evince. Please let me know if it helps - if it doesn't, please reupload the job log and do the steps from comment #28.
Ok, so I've tried this first. (In reply to Zdenek Dohnal from comment #29) > The filter which we need to run has a high cost in coversion table (CUPS has > its own conversion table for deciding which filters are run for a specific > files), so we need to raise cost of application/pdf line in your ppd. > > So before you do the stuff from comment above: > > 1) stop cups > > 2) change line from: > > *cupsFilter2: "application/vnd.cups-pdf application/pdf 100 -" > > to > > *cupsFilter2: "application/vnd.cups-pdf application/pdf 200 -" > > 3) restart cups > > (changing this started the expected filters for my file device queue) > > Now please try to print the original pdf from evince. > > Please let me know if it helps - if it doesn't, please reupload the job log > and do the steps from comment #28. It looks like raising the cost to 200 causes different filter priorities: ... 5 filters for job: pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66) gstoraster (application/vnd.cups-pdf to application/vnd.cups-raster, cost 99) rastertopwg (application/vnd.cups-raster to image/urf, cost 100) - (image/urf to printer/HP-ColorLaserJet-MFP-M278-M281/image/urf, cost 0) - (printer/HP-ColorLaserJet-MFP-M278-M281/image/urf to printer/HP-ColorLaserJet-MFP-M278-M281, cost 0) ... (I'll attach the full logs later.) And indeed, the š and ž characters are printed correctly. However, after changing the filter priorities, the 1. print job failed in the middle with an error and only approximately half of the page was printed. When I restarted the printer in Gnome Settings and printed the same thing again, the 2. print job completed successfully. I'll attach the logs of both jobs.
Created attachment 1749345 [details] sudo journalctl -u cups JID=70 This job printed š and ž characters correctly, but failed with an error in the middle. Only approximately half of the page was printed.
Created attachment 1749346 [details] Scan of actual Slovene PDF with čžš characters printout for JID=70 (error, only half page) The š and ž characters are printed correctly but only approximately half of the page is printed.
Created attachment 1749347 [details] sudo journalctl -u cups JID=71 This job printed š and ž characters correctly and completed successfully.
Hi Tadej, the logs looks identical except for the Send-Document error - the process shouldn't fail there, especially after Validate-Job was fine and Create-Job passed too... it looks to me as printer bug :( . Are you able to reproduce the issue again? I will need a network traffic capture - that's the more detailed way for debugging failures in backends. You can how to capture the traffic in https://fedoraproject.org/wiki/How_to_debug_printing_problems#Backend_.28job_transport.29 . Thank you in advance!
I would say the transport error is a different issue. Tadej, would you mind opening a new bugzilla for cups regarding the transport error, if you are able to reproduce? And please upload there network traffic capture.
FEDORA-2021-8555bc4518 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8555bc4518
FEDORA-2021-ac537b3853 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ac537b3853
FEDORA-2021-ac537b3853 has been pushed to the Fedora 32 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ac537b3853` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ac537b3853 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8555bc4518 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8555bc4518` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8555bc4518 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hi Zdenek, (In reply to Zdenek Dohnal from comment #34) > > Are you able to reproduce the issue again? I will need a network traffic > capture - that's the more detailed way for debugging failures in backends. > > You can how to capture the traffic in > https://fedoraproject.org/wiki/How_to_debug_printing_problems#Backend_. > 28job_transport.29 . Yes, unfortunately, it appears very frequently. So frequently that with this new update/fix I'm practically unable to print anything successfully. Printing just errors and stops in the middle of a page. (In reply to Zdenek Dohnal from comment #35) > I would say the transport error is a different issue. Agreed. But it appears that this update/fix exposes it in such a way that printing becomes unusable. > Tadej, would you mind opening a new bugzilla for cups regarding the > transport error, if you are able to reproduce? And please upload there > network traffic capture. Yes, I can create a new bug report and attach the network traffic capture.
I unpushed the fix for now, only clean 1.28.7 will now arrive.
(In reply to Zdenek Dohnal from comment #41) > I unpushed the fix for now, only clean 1.28.7 will now arrive. Yeah, I think this makes sense. I'll create a new bug report and attach the network traffic capture later today.
Hi Tadej, any update about network traffic capture for your failing print job (the one which just printed half a page)? Switching to PWG Raster is now in the latest release, so I would need to remove that specific patch to make it working for you, so it would be best to solve it beforehand. Please remove your print queue before installing new rpms. The following command will remove every installed print queue, so if you have other queues connected to different devices, update the command accordingly (it expects you have gawk installed): for i in `lpstat -a | awk '{print $1}'`; do lpadmin -x $i; done Then please install https://koji.fedoraproject.org/koji/taskinfo?taskID=66839798 . Since you are on F33, gtk there already supports temporary queues, so would you mind trying those at first and then installing a permanent queue?
The clean 1.28.7 fixes your issue and I didn't get any more info regarding the issue caused by the current upstream fix, so closing this issue as CURRENTRELEASE.
Just to follow up. I've recently upgraded to Fedora 35 and used the driverless driver without issues. Thanks Zdenek!