Bug 1991678

Hi Grant,

I'm sorry for my late answer. I've tried to reproduce this before but it worked for me and still does. Do you experience the issue with updated system yet?
This could be related to the issue in https://bugzilla.redhat.com/show_bug.cgi?id=1904405.

Do you see the issue if you Add the printer via gnome-control-center's Printers panel?

Thanks

Sorry for the delay. I was on vacation when you replied.

On my updated (F35) system, if I reinstall the printer using "lpadmin -p NewKM -E -v ipp://172.16.8.38/ipp -m everywhere", then I still get garbled printing when I print that arxiv pdf from within evince, but not when printing to the same printer using lpr. If I print the file to a new pdf file from within evince, then the new pdf will be garbled if I print it using lpr, too.

If I use the gnome settings Printers panel, and put in the IP address, then the printer is found in jet-direct and lpd versions. I picked jet-direct, and then selected Minolta and the KONICA MINOLTA C550 PS(P) driver. Printing the same article to the newly installed printer, from within evince, does print correctly, although the printer options aren't quite right. (Automatically getting the printer options right was the reason I wanted to use ipp everywhere in the first place. Well, that and the LWN article on ipp everywhere.)

Hope that helps some. Please let me know if there's anything I can do to help.

Thank you for the answer. I'll ask maintainer of cups and cups-filters for help here as it could be related to the printer itself.

Zdenek, do you know what could cause this issue?

Hi Marek,

IMO it could be connected to https://bugzilla.redhat.com/show_bug.cgi?id=1938109 as well. #1904405 introduced a workaround when PPD generator from cups-filters ('driverless' executable) is used - the workaround is based on preference of Apple Raster document format if available, but I haven't applied it to CUPS.

Grant, it would be great if you tried rpms from the following link https://koji.fedoraproject.org/koji/taskinfo?taskID=79973836 and tell us whether it helps - you will have to reinstall the queue to regenerate the PPD for the permanent queue.

Hi, Zdenek.  Thanks for looking into this for me.

I downloaded all of the rpms (except the srpm) from koji, and dnf tells me that I would be upgrading cups, cups-client, cups-filesystem, cups-ipptool, and cups-libs, and installing for the first time cups-lpd, cups-printerapp, and the -devel and -debug stuff. I'm happy to do that, but I thought I'd check first in case there's something I shouldn't install, or if you want me to install the non-test cups-lpd and cups-printerapp first?

Thanks again!

Grant,

just upgrading cups, cups-client, cups-filesystem, cups-ipptool and cups-libs suffices.

Do let me know if it helps.

No joy.

I updated cups, cups-client, cups-filesystem, cups-ipptool, and cups-libs, and restarted cups. I also created a new print queue for the printer. Printing that same pdf from firefox works fine. Printing from firefox, but using the system dialog, also works fine. Printing from evince looks terrible, and despite me telling the dialog that it should print to US Letter, the printer asks me to chose the paper size before it will print. (I suspect the pdf I'm printing is a4 instead of US Letter, by default.)

I'm not sure if that's helpful or not.

Thanks,
Grant

Thanks, Grant!

Would you mind turning on cups debug logging by (the command expects your LogLevel to be 'warn' - update the command if needed):

$ sudo sed -i 's,LogLevel warn,LogLevel debug2,' /etc/cups/cupsd.conf

printing with the testing rpms again and then attach the logs here as an attachment?

You can get job logs by:

$ journalctl -u cups JID=<job number, use the latest one> > job_log

and then attach the job log to the bugzilla.


I would like to check whether really a raster format was used during printing (you can find out by filters which were used during printing).


If the workaround with changing final document format doesn't work, it looks like cairo (PDF generator used by evince) creates a PDF incompatible/garbled for your printer, which even converting to other format doesn't fix. In that case it would be great if cairo maintainer looked into it.

Created attachment 1846608 [details]
cups job log

Here's the job log when printing this pdf from evince. Looks like it runs through pdftopdf and ipp, but I could be missing something in the 2500 lines of log!

Created attachment 1846609 [details]
cups job log when printing from firefox

Job log when printing from firefox instead of evince. There are some differences between the logs, so hopefully this will be helpful.

Ok, Apple Raster hasn't kicked in during printing.

Would you mind attaching the PPD for the new queue? It is in /etc/cups/ppd.

Created attachment 1846610 [details]
IPP everywhere printer ppd

Ok, so the patch was applied, but weighs on other filters were still to high, so pdf was preferred.

Please try rpms from here https://koji.fedoraproject.org/koji/taskinfo?taskID=80089728 once the task finishes. (again queue reinstallation will be needed)

Created attachment 1846629 [details]
Cups log for test2 rpms

Created attachment 1846630 [details]
PPD after updating rpms to test2

Looks like that worked. The printed page now looks the same as it does in evince when printing from evince--it's no longer garbled.

I still seem to have a problem where the printer is now asking me what size paper I should use, despite setting explicitly setting it to US Letter (setting "shrink to fit") in the print dialog, but that's tolerable (and possibly user error).

Many thanks!

Created upstream PR https://github.com/OpenPrinting/cups/pull/310 .

Ok, turning to raster for all PDF by default is not the solution we can use - it will cause performance regressions (much bigger files to sent to the printer, losing quality etc.). I'll revert the fix in cups-filters as well in the future.

According upstream the fix should happen in cairo or in the printer firmware itself.

If the issue cannot be fixed in cairo we will look into other possibilities how to deal with it in the filtering chain (like vectorizing only the specific font which makes problems, or introducing an option which will force PDF rasterization if set).

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.

Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.