Open Bug 1674682 Opened 1 year ago Updated 10 months ago

Content overlap when fragmenting with fixed height content

Categories

(Core :: Printing: Output, defect, P3)

80 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: bug-str, Unassigned)

Details

(Whiteboard: [frag2020])

Attachments

(13 files)

968.00 KB, application/pdf
Details
377.96 KB, image/png
Details
50.78 KB, image/jpeg
Details
63.69 KB, image/jpeg
Details
45.80 KB, image/jpeg
Details
51.05 KB, image/jpeg
Details
68.63 KB, image/jpeg
Details
61.32 KB, image/jpeg
Details
48.31 KB, image/jpeg
Details
62.21 KB, image/jpeg
Details
42.72 KB, image/jpeg
Details
83.73 KB, image/jpeg
Details
107.51 KB, image/jpeg
Details

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

Steps to reproduce:

Firefox has problems keeping the same (or even similar) layout while printing - as the one on the screen.
Here is just one of numerous pages that gets scrambled: with the text elements going over others, while they don't do that on the screen.

Actual results:

Text elements go on top of other, moving up as far as to another printed page (from p.7 to page 6):
https://www.admta.org/wp/event/solo-contest/
Also the text bounding box got shrunk and goes over the text.

This is relatively mild example. In some cases (ticket booking, etc.) the results are even worth, - but those are dynamically generated pages, and I cannot send you examples that you can view easily.

Expected results:

The printed pages should be close to how they are displayed on screen, at the very least, the text should not overlap.

This screenshot shows good rendering on the screen (as opposed to the PDF of the printout that is reported).

Component: Untriaged → Printing: Output
Product: Firefox → Core

Thanks for reporting this! At least for the example provided, most of the content is sitting in a <div> with a fixed height in pixels (4550px) but there's not a good reason for the site to be doing this. I believe this is causing the overlap when we fragment the content and adjust for margins, etc. However, comparing with Chrome, Firefox's output is arguably a bit better (when disabling printing of background images). If you do have other examples, please feel free to add them as comments here.

It's worth noting that print layout is not going to be exactly as what is visible on screen, due the nature of switching mediums and having to accommodate for page sizes, margins, etc.

Will leave this open as an example bug where we could do a bit better in the case of fixed height elements, and bug 1640197 may help improve things hopefully in the Firefox 85 time frame.

Severity: -- → S4
Priority: -- → P3
Summary: Firefox scrambles the pages when printing → Content overlap when fragmenting with fixed height content
Whiteboard: [frag2020]

Yes, I saw that Chrome also messes it up.
And while I understand that the layout of the printout can be different from that of the screen, I think, if the screen rendering can avoid elements overlap, so should the printout.

Since you have confirmed this, would you like to change the status from "UNCONFIRMED"?

Also, I've just reported a somewhat similar problem (at least visually) with the screenshot functionality. (I am not sure if the culprit is the same or not, though.) Bug#1675803

I don't know if it is the same problem intrinsically or a different one.
(Observed with 84.0.2 (64-bit) on Windows 10)

In this case, I see several problems:

  1. As reported in this bug, - the elements overlap
  2. The first page has large portion ("header") that is completely empty, besides the top banner. And the last (3rd) page is also empty in a similar way.
  3. If I choose "fit to the page" in scaling, a large portion of the text is skipped completely. I had to reduce to 64% to have the relevant information printed. The same problem happens at 100%.
  4. Print layout is unstable with respect to the history of the selected printers.
    First, I had my real printer (Xerox Phaser), and while trying to print, I chose Foxit Reader PDF printer. In that case the header was repeated on all 3 pages.
    Then I printed it to PDF, and the printer was remembered by Firefox. When I tried to repeat, all behavior was still the same, except that the header was present only on the first page.

I am attaching screenshots to illustrate all this problems below.

Page 1 shows only the header (top banner), and empty for the most part.

Elements overlap on this page. The header (top banner) is present again.

This page is mostly empty, except for the header and the footer.

Page one at "Fit-to-page" (automatic) scale - again, only the header (top banner), and the rest of the page is empty.

Page 2 - at "Fit-to-page" (automatic) scale - again, the header (top banner) is repeated, and the main text elements overlap. Lots of information is cut-out at the bottom, and not wrapped up to the next page.

Page 3 - at "Fit-to-page" (automatic) scale - again, the header (top banner) is repeated, there is no spill-over of the information from the previous page, only the footer is printed.

At 64% Page 1 preview - after printing to the PDF printer was completed (as shown with previous screenshots) - and the PDF printer was remembered (preselected)
In this case - again, only the header (top banner) is printed on this page, but not on the subsequent pages, as it was before.

After the PDF printer was inherited from the previous printing, - the header (top banner) is no longer shown on p.2 (and p.3), - but the elements still overlap.

After the PDF printer was inherited from the previous printing, - the header (top banner) is no longer shown on p.2 (and p.3), - but the elements still overlap.

The page is correctly rendered on the screen - at 50% of the webpage (different scale here, not the printing scale), - to show most of the page.
Next one is a small portion (at 100%)

The page is correctly rendered on the screen - at full (100%) scale of the webpage (different scale here, not the printing scale), - to show a smaller portion of the page but properly aligned.

You need to log in before you can comment on or make changes to this bug.