User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

1. Open any webpage (I provide an HTML document as attachment for reference)

2. Ctrl+P or click on hamburger menu then click on "Print...", the printing dialog appears

3. In the drop-down list under "Destination", select "Save to PDF" or any other print-to-document printer, all other options do not influence the result as far as I aware

4. Save the generated PDF file to your chosen destination and open it

Actual results:

At this point you will notice several issues with the resulting document:

• text that was selectable in the original HTML is unselectable in the generated PDF
• links and image links are non-clickable (this is a supported feature of PDF documents)
• some images are missing

It almost looks like Firefox does a (bad) printscreen of the webpage before exporting the image as a PDF, instead of trying to generate a well-formed PDF document.

Expected results:

In the resulting PDF:

• text should be selectable and searchable
• links and image links should work as well
• dynamic elements (like interactive images) should be rendered into static images

Exemples of rendered PDFs by different applications for comparison.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Printing' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Text is selectable here on Linux fwiw... Maybe this is Windows-specific?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Created attachment 9282395 [details]
mini-rapport-deconv-from-firefox-linux.pdf

Text is selectable here on Linux fwiw... Maybe this is Windows-specific?

Text is selectable indeed. Although images are still pretty distorted.

Does anyone know if Firefox is using its own HTML to PDF converter, or if it simply calls one available on the host system ?

We use our own rendering. "Save as PDF" uses cairo on the final step, "Microsoft print-to-pdf" etc use Windows printing APIs.

So the possibility exists that Firefox's "Save as PDF" creates a PDF with selectable text, but then "Microsoft print-to-pdf" ruins that ?

Still, the way images are distorted during the conversion phase is still an issue.

I think the issue is that Chrome is not squishing the canvas but we are.

Chrome's preview takes forever here, but it draws correctly-sized canvases which overflow the viewport. We instead draw wrongly-sized canvases. None of those are ideal. Part of the issue is that the page is built using absolute pixel values, but doesn't react to print so we end up with a bunch of elements sized to the size of the original page's viewport. Print output in Firefox is much more reasonable if you shrink your window to an aspect-ratio that matches the print paper size.

So this is a mix of a page issue (there's not much we can do if the page says "this canvas is 2000px wide" and then listens to resize events) and an interop issue with Chrome (haven't dug into which browser is right according to the spec).

(In reply to petr.kisselev from comment #8)

So the possibility exists that Firefox's "Save as PDF" creates a PDF with selectable text, but then "Microsoft print-to-pdf" ruins that ?

Scratch that, Firefox's "Save as PDF" and "Microsoft print-to-pdf" appear as different printers in Firefox's printing interface. So this might be a Windows specific issue with cairo or whatever Firefox's "Save as PDF" relies on.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

I think the issue is that Chrome is not squishing the canvas but we are.

Chrome's preview takes forever here, but it draws correctly-sized canvases which overflow the viewport. We instead draw wrongly-sized canvases. None of those are ideal. Part of the issue is that the page is built using absolute pixel values, but doesn't react to print so we end up with a bunch of elements sized to the size of the original page's viewport. Print output in Firefox is much more reasonable if you shrink your window to an aspect-ratio that matches the print paper size.

So this is a mix of a page issue (there's not much we can do if the page says "this canvas is 2000px wide" and then listens to resize events) and an interop issue with Chrome (haven't dug into which browser is right according to the spec).

I'm not sure if I agree with this assessment. Even when you shrink the window width to something resembling a paper's aspect ratio, Firefox tries to squeeze the image vertically and while the top part of an image is rendered with correct proportion, the bottom part of the image gets vertically squeezed out of existence. Also, the blank space left at the top of the next page hints at Firefox leaving it for the bottom part of the image that didn't fit on the previous page.

The severity field is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.

I wonder if the hack in bug 774398 improves this one.

It seems to.