Content overlap when fragmenting with fixed height content
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
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 | |
 AT 64% scale, - p1 - After PDF printer selection was inherited - Firefox-PrintoutWalmart-64-p1-2.jpg
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).
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
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.
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:
- As reported in this bug, - the elements overlap
- 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.
- 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%.
- 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.
|
Reporter | |
Comment 10•5 years ago
|
||
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.
|
|
Reporter | |
Comment 11•5 years ago
|
||
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.
|
|
Reporter | |
Comment 12•5 years ago
|
||
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.
|
|
Reporter | |
Comment 13•5 years ago
|
||
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.
|
|
Reporter | |
Comment 14•5 years ago
|
||
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%)
|
|
Reporter | |
Comment 15•5 years ago
|
||
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.
Description
•