Chromium cannot print any png file or a page with png in it

Support
,
1

Hello,

EDITED: Update: This was not the solution actually!
I realized the print preview works on some pages, and fails on some others.
I used AI to step by step figure out what causes it.
I tried a simple page: www.google.com on which print preview would fail and as a result, the save button to save the page as pdf was also failing.
I used developer tools to block the assets of that page one after another and print preview kept failing until one asset:
A png file
So I tried:
Downloading the specific png and opening the downloaded file on chromium:
file:///tmp/unnamed.png
And print preview on that failed as well!
Then I opened the png file in krita, resized it to 1000x400 pixels and saved it again. Then opening the resized png file on chromium and print preview on that failed as well!
Then I saved the resized png file in krita, as a jpg file. Then opening the jpg file on chromium and print preview worked this time!
Then I just created a simple png file in Krita from scratch with a black dot in middle of it! And print preview on that failed as well!
Then I download some sample png file from a random website and opened that in chromium and print dialog failed as well.

Conclusion
At this point, chromium is unable to print png files or any page that has a png file in it. Any idea is highly appreciated.

My Post Before Edit

Chromium has a built-in print dialog where you can print a page as pdf. For me that was failing.
Then I used Ctrl+Shift+P to use the external system print dialog. But that one was showing no printers at all. That gave me some clue.
First I made sure cups-pdf is installed:

$ dnf list installed | grep cups-pdf
cups-pdf.znver1                                         3.0.1-1                   @rolling-znver1-extra

Then I followed instruction from AI:

  • Open your web browser and go to the CUPS interface: http://localhost:631/
  • Go to the “Administration” tab and click on “Add Printer”.
  • You might be prompted for your username and password. Use your Linux user account that has administrative (sudo) privileges.
  • Select a Printer:
  • Under “Local Printers”, look for an option like “CUPS-PDF (Virtual PDF Printer)”, “Generic CUPS-PDF Printer”, or similar. Select it and click “Continue”.
  • If you don’t see a direct CUPS-PDF option, you might try “LPD/LPR Host or Printer” and see if you can specify cups-pdf:/ as the device URI, or choose a generic PostScript printer. However, cups-pdf usually registers itself for easier addition.
  • Printer Details:
  • Name: PrintToFile (or any name you prefer, like PDF_Printer)
  • Description: Print to PDF File
  • Location: Local (or leave blank)
  • Sharing: Uncheck “Share This Printer” (unless you specifically want to share it on your network).
  • Click “Continue”.
  • Select Make/Manufacturer:
  • Choose “Generic” or look for “CUPS-PDF”. Click “Continue”.
  • Select Model:
  • Select something like “Generic CUPS-PDF Printer (en)”, “Generic PostScript Printer (en)”, or a similar generic driver. The CUPS-PDF printer doesn’t need a device-specific driver.
  • Click “Add Printer”.
  • Set Default Options (if prompted): You can usually leave these as default. Click “Set Default Options”.

And that solved the problem.

4 Likes
2

Maybe it is connected to random crashes of chromium and brave that other people experience.
The only commonality I see is they too are using znver1 version.

2 Likes
3

I thought it was znver1 as well. I went so far as to format this machine and install x86_64 on it and right off the bat, Brave crashed.

1 Like
4

Then what is left is the CPU itself.
It might not be connected to znver optimizations, but rather to something related to the compiled code as it runs on AMD CPU.
The Brave and Chromium in OM repos are compiled with LLVM right?
Can you try flatpak versions of chromium/brave?

1 Like
5

I don’t know, but I can try the flatpaks. The crashing is random and it might take a bit.

1 Like
6

My issue is not crashing at all. It’s stable for me. Thank God for that. But as I said, printing of png files fails.

1 Like
7

Ok. I got some strace log and I gave to AI to analyze it and it gave me a considerable response that can be used for a bug report:
Okay, thank you for that timeline! Knowing that you pressed Ctrl+P almost immediately after the a.png tab reopened, and then Ctrl+C about 3 seconds after that, is very helpful for focusing the analysis of the strace log.

This means the critical period in the trace is a very short window. The “struggling” for a few seconds before you hit Ctrl+C aligns perfectly with the repeated poll timeouts I observed in PID 627573 (and potentially other related processes) while interacting with the CUPS socket after attempting to send the document.

Here’s how your timeline refines the interpretation:

  1. Reopen a.png (Ctrl+Shift+T): The trace would show file access to /tmp/a.png, initial rendering activity, loading of libpng16.so.16, etc. This part seems to work fine, as the image displays.

    ...
627568 openat(AT_FDCWD, "/tmp/a.png", O_RDONLY) = 75
627568 read(75, "\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0...", ...) = ...
...

  2. Press Ctrl+P (immediately after tab reopens): This would trigger a new sequence of events:

    • Chromium’s print preview mechanism kicks in.
    • It likely tries to take the already decoded PNG data (or re-processes the file) and convert it into a format suitable for preview and for the “Save as PDF” backend. This is where Skia would be heavily involved in rendering the PNG to an internal PDF representation.
    • Processes (like 627573) start communicating with CUPS (/var/run/cups/cups.sock), querying printers, creating a job for the virtual “Print_to_PDF” printer, and then attempting to send the document data.
    ...
627573 connect(131, {sa_family=AF_UNIX, sun_path="/var/run/cups/cups.sock"}, 26) = 0
627573 sendmsg(131, ... "CUPS_GET_PPD" ... "Print_to_PDF" ...) = ...
627573 sendmsg(131, ... "CREATE_JOB" ... "Print_to_PDF" ...) = ...
627573 sendmsg(131, ... "SEND_DOCUMENT" ... "application/pdf" ...) = ...

  3. “Struggling” for ~3 seconds: This is the period where the trace shows PID 627573 (and possibly others) repeatedly calling poll on the CUPS socket and getting timeouts:

    ...
627573 poll([{fd=131, events=POLLIN}], 1, 1000) = 0 (Timeout)  // Waiting for 1 second
627573 poll([{fd=131, events=POLLIN}], 1, 1000) = 0 (Timeout)  // Waiting for 1 second
627573 poll([{fd=131, events=POLLIN}], 1, 1000) = 0 (Timeout)  // Waiting for 1 second
... (and other poll calls with different timeouts, also potentially timing out) ...

    This sequence of timeouts easily accounts for the ~3 seconds of “struggling.” The process is stuck waiting for data that isn’t arriving, presumably because the PNG-to-PDF rendering step within Chromium/Skia has failed or hung.

  4. Press Ctrl+C in the terminal: This sends SIGINT to the main strace process and its initial child (PID 627525). strace then often terminates the other child processes it was tracing, leading to the +++ killed by SIGTRAP (core dumped) +++ messages at the very end of the log. This is just the cleanup after you manually stopped it and not indicative of the original error.

Confirmation:

The timeline you provided perfectly matches the poll timeout pattern observed in the strace log. The system isn’t crashing due to a low-level error like a missing library (no ENOENT for critical libs) or a segfault before the timeout. Instead, it’s getting stuck in a waiting state because a preceding internal step (very likely the conversion of the PNG to a printable PDF format by Skia) is not completing or signaling its completion/data readiness.

This makes the bug report to Chromium even stronger:
“When attempting to print any PNG file (either directly opened or on a webpage) to PDF, the print preview generation hangs. strace reveals that Chromium processes involved in CUPS communication enter a loop of poll() timeouts on the CUPS socket after a SEND_DOCUMENT (with application/pdf format) operation is initiated for the ‘Print_to_PDF’ virtual printer. This occurs consistently for PNGs, while JPGs print correctly, suggesting a failure in the internal PNG-to-PDF rendering stage (likely Skia-related) which prevents data from being available to the print pipeline, leading to the observed timeouts and hung preview.”

You’ve done a great job isolating this and gathering evidence!

1 Like
8

Thank you for this breakdown of the issue. I have the problem as well and have not had the time to focus on it and could never have gone as deep into it as you have. The problem for me was trying to print a section of a google map and had to copy and paste it into a doc and print that.

1 Like
9

I cannot recall a time where Chromium based browsers and CUPS worked properly on any distro I have used in the past decade. I have a feeling this is an upstream/won’t fix.

12

I cannot recall a time where Chromium based browsers and CUPS worked properly on any distro I have used in the past decade. I have a feeling this is an upstream/won’t fix.

Even save as pdf with chromium internal print dialog was not working for you on any distro? Because that’s what I originally want to achieve. It works currently. But as long as there is no png file involved. I don’t think it’s an upstream issue.

13

No, “Save as PDF,” is how I work around the problem of it not talking to CUPS properly. Then I just print to a printer from the PDF file. “Save as PDF” has always worked for me.

We would also appreciate it if you didn’t Delete Spam the forum. It makes topics longer than they need to be which makes reading things and finding answers more difficult than it should be. If the issue is edit time limits, @rugyada may know how to remedy that.

14

@zeroability I tried to quote your last message but for some reason the quote feature did not work here.

Please mention your installed version of Chromium. Is it flatpack or installed via dnf? and please check whether you can save a PNG file using your installed chromium as PDF.

15

It has been every Chromium based browser package from several Linux distributions. I couldn’t begin to give you version numbers.

I can always save to PDF from browsers I have used. In this case, it’s Brave.