On Thu, 2026-01-15 at 10:04 -0500, Frank Bures wrote: > I do not print too often, mostly bank transactions receipts. Yes, I > observed this "solution", but lately it stopped working as well. It would > not print from google-chrome-stable directly at all. Even after many tries. > The only workaround is the PDF printing. As I said, I print only > occasionally so the problem does not warrant in-depth investigation. My > experience is that these things tend to disappear by themselves after some > time :-)
Perhaps just a problem with Chrome itself? I wonder if it's producing garbage results that can't print, but perhaps encapsulating its output in a PDF file skips the problem? Quick searching for chrome won't print, produces the usual cargo-cult mantras of clearing the cache and cookies, disable extensions, and reset things. That sort of nonsense advice is only going to get work with Artificial Idiot content creation, unintelligently playing copy and paste. You could try it, but I don't think any of that advice is based on fact, it just seems to be try a bunch of things, and try printing again, for any problem with a web browser. You may as well turn around on the spot hopping on one foot while whistling Bring Me Sunshine. When it came to my printing problems with MuseScore (an appimage) it wouldn't print through CUPs (things went through the motions on the computer, but the printer just sat smugly idle). However, it *might* print to printers it'd discovered through mDNS/ZeroConf (my printers are network printers, connected via ethernet cable). This seems the opposite of something mentioned in known issues for CUPS (old data, but but shows the mDNS interference in printers): https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_fixed_in_f33_and_later_firefox_evince_pdf_viewer_gvim_gedit_gnome_control_center_show_a_dummyduplicate_print_queue_which_doesnt_work --------------------- begin paste ----------------------------- [Fixed in F33 and later] Firefox, Evince (PDF viewer), GVim, Gedit, Gnome Control Center show a 'dummy'/duplicate print queue, which doesn’t work This bug is connected to every application which uses GTK print dialog. GTK dialog decided to take information about available from two sources - mDNS messages from Avahi and CUPS - this dummy/duplicate print queue is a print queue GTK created in its dialog based on Avahi messages, but it doesn’t exist in CUPS, because no one created it, and later GTK behaves like it exists in CUPS. So every time an user wants to print, GTK sends a request to CUPS for this queue, but it gets dropped by CUPS because the queue doesn’t exist. The feature which GTK is trying to do here is called CUPS temporary queues - GTK developers is currently working on a immediate fix in this bugzilla. The future plan is to use cpdb-backend-cups backend in GTK, but right now we are focusing on the intermediate fix. ----------------------- end paste ----------------------------- -- uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 (yes, this is the output from uname for this PC when I posted) Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
