Print layout not correct
Categories
(Core :: Printing: Output, defect)
Tracking
()
People
(Reporter: dannyfox, Unassigned)
References
Details
Attachments
(4 files, 1 obsolete file)
FF-90_BadPrintLayout_(BAD)_(HP-M118dw).jpg
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:90.0) Gecko/20100101 Firefox/90.0
Steps to reproduce:
Trying to print web pages that used to work OK. For example:
- Amazon order details
- My bank's listing of account transactions
Try same things to other printers & devices.
Try same things to PDF.
Try same things on Google Chrome.
Actual results:
The bank transactions went flaky several months (a few versions) ago and I complained to them, then suddenly with a FF update, all was well. (Meanwhile worked fine on Google Chrome.)
Lately, bank transactions are weird -- whole lines missed, page breaks too long or pages start way down the page. Seems to work correctly on GC.
Then tonight (first time printing since update to FF 90.0 this morning), printing Amazon Order Details -- which has always worked well and scaled up & down nicely -- suddenly goes bizarre. Scaling down makes things fit but then starts truncating lines, or starts working, or truncates again. Works fine on GC -- that's what I had to use to get my work done tonight!
Running on Windows 7/32 Pro. Using HP M118dw printer, but fails similarly with HP5P driver )which I've used for decades) and several other drivers. A few (like two different PDF generators) work fine.
Expected results:
PRINT (or print preview) should work properly as programmed and expected.
|
Reporter | |
Comment 1•4 years ago
|
||
Comment on attachment 9231272 [details]
FF-90_BadPrintLayout_(BAD)_(HP-M118dw).jpg
Please ignore this first image -- the file was inadvertently overwritten with the CHROME version (which prints OK).
|
|
Reporter | |
Comment 2•4 years ago
|
||
Note that part of right-side text is truncated compared to "OK" images from CHROME and for PDF.
|
|
Reporter | |
Comment 3•4 years ago
|
||
Note that part of right-side text is truncated compared to "OK" images from CHROME and for PDF, in the same manner as per HP M118dw printer.
|
|
Reporter | |
Comment 4•4 years ago
|
||
Page image is complete and fits to page properly (or scales down properly when adjusted).
Compare to versions on FF 90.0 which chop and truncate the page text.
|
|
Reporter | |
Comment 5•4 years ago
|
||
Page image is complete and correct (as per Google Chrome's prints). PDF and various other device drivers render the page image correctly (and scale up & down properly). Some devices -- including HP M118dw (my current printer) and HP5P (not connected at the moment but has worked for decades) -- do not render well. See other examples attached here.
|
||
Comment 6•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
|
Reporter | |
Comment 7•4 years ago
|
||
Note that this issue is NOT a duplicate of Bug 1595793 which describes missing or truncated headers & footers.
|
||
Comment 8•4 years ago
|
||
Can you make sure you've got the 90.0.2 update and retest? There was a printing fix that landed for that version that may be responsible for this.
|
|
Reporter | |
Comment 9•4 years ago
|
||
I definitely have FF 90.0.2 installed and running. I don't think the printing fix fixes my issue -- pretty sure I tested it when installed and it made no difference. (Then I left town for awhile and haven't used it until now...)
When I print my banking transactions to paper on my HP M118dw LaserJet (fit-to-page selected), the line-item details show perfectly in the print-preview window, but the paper output is gradually shifted down the page and some line-items are not present in the output.
The same print in Google Chrome (using "default", which seems to be GC's equivalent for fit-to-page) works almost perfectly. The paper matches the preview, and all detail lines are present. There is an appearance issue in the application which causes the first page to run long (but not overflow) and crowd the footer on the page -- probably a margin issue with the app, because this has existed for some time and they know about it.
|
||
Comment 10•3 years ago
|
||
Hi Dan -- sorry this went quiet for a while. Would you mind re-testing in up-to-date Firefox and seeing if this is still an issue? I wonder if (/ hope that) maybe we fixed this in the time that's passed since your last post here.
|
|
Reporter | |
Comment 11•3 years ago
|
||
Thanks, Daniel, for following up. Running FF 98.0.1 just installed yesterday from standard HELP, ABOUT releases...
I was shocked to discover that fit-to-page almost works now! In my banking app (which is most critical and which highlights the problem), I used to see perfect rendition of the page in the preview screen, but the actual print would drift significantly, losing -- that is, NOT printing -- one, two, three blocks of line-item detail. A printout would consist of fewer & fewer lines per page as the whole page image slid down, several centimeters or inches at a time.
Now, the print preview is not quite perfect. Second page starts to split a line horizontally, and the image gradually creeps down the page maybe a constant/consistent millimeter or two at a time. Every few pages there is a split line for a page or two as the downward migration happens, then everything fits, then splits a line again. BUT... The output on paper is now a very faithful rendition of the print preview, which has never been the case. The preview contains the splits, the hardcopy does too, in exactly the same spots -- exactly as it should do (although not correct). And if I print to PDF ("save as PDF" in the printer select drop-down), I get EXACTLY the same almost-perfect slightly wandering image. Of course by creating a PDF I can quickly page up & down and watch the page-images creep downward (or back upward).
Testing on Google CHROME -- not my preferred browser but which I have to use as it's been the only reliable way to print my transactions -- I see only a minor change, and for the better. Whereas I used to scale at 65% to avoid running detail into the footer line, I can run "default" (which is GC's fit-to-page) or manually set to 66%, and it runs it PERFECTLY either way -- no split lines, no crashing into footers, no wandering down the page. (Please... make the Fox do this!!)
I'm sure the banking group has tinkered their page generation again to work around issues -- something resolved the footer crashes on GC, for example so print on GC now works perfectly. But no matter what I do in FF, I get the page creep -- nowhere near as bad, at least it isn't missing wholesale blocks of lines -- but still not correct either. Much much better than it was -- I'll reluctantly say it's a better workaround than what we had -- but it isn't there yet.
|
|
||
Comment 12•3 years ago
|
||
(In reply to Dan Pernokis from comment #11)
the actual print would drift significantly, losing -- that is, NOT printing -- one, two, three blocks of line-item detail. A printout would consist of fewer & fewer lines per page as the whole page image slid down, several centimeters or inches at a time.
Great - this sounds like it was a version of bug 1740304 (which fortunately is now fixed).
Now, the print preview is not quite perfect. Second page starts to split a line horizontally
Yeah, splitting a line (i.e. upper half of the characters on one page, lower half on the next page) is a known issue that we run into for some sorts of containers that we can't "properly" fragment for a variety of reasons -- that was added in bug 1640197. It's sort-of like we print to a virtual unbroken sheet of paper, and then we slice it at pagebreaks (which is imperfect due to line-slicing, but better than losing content from having it run off of a page into oblivion).
and the image gradually creeps down the page maybe a constant/consistent millimeter or two at a time.
To clarify, with this "creeping" -- is there any lost or duplicated content? (I hope not?)
If I understand correctly, you're just talking about the "slicing" behavior, with not-a-whole-number-of-lines fitting on each page, so the first line is at a slightly different position on each page -- is that right?
(My testcase at https://bug1740304.bmoattachments.org/attachment.cgi?id=9260929 might give you similar results, if I understand you correctly.)
If so, then I think the behavior you're describing is essentially our "expected result" for the time being, at least for certain buckets of web content. (It's hard to know which bucket your bank falls into without having analyzed it, but there are several known types of containers that can trigger this behavior.)
|
|
Reporter | |
Comment 13•3 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #12)
To clarify, with this "creeping" -- is there any lost or duplicated content? (I hope not?)
No, nothing lost, nothing duplicated -- and yes, "slicing behaviour" sounds exactly right, starting slightly farther down each page. It happens that the content is 2-3 lines of text per transaction plus a little gap between, so there are not-quite-a-whole-number of transactions per page, with the sliced lines as you call them -- and the slice could come between the lines that make up a transaction, so the page looks OK but isn't quite. (Previously, parts of these transaction lines -- and even whole transactions -- would evaporate from the print stream by the time the paper came out.) And finally, yes your test case presents the same slicing.
I presume the footers are not part of the "printed page" image that FF generates -- because they always go in exactly the same position every page, with no slicing.
If you need to talk to somebody technical, my bank is CIBC (Canadian Imperial Bank of Commerce): https://www.cibconline.cibc.com/
Their contact info is all there, but like any bank, the people you need are impossible to reach. :(
Unless you know somebody already...
|
|
||
Comment 14•3 years ago
|
||
Thanks for clarifying/confirming that.
RE footers -- I assume you're referring to e.g. the page number and datestamp (the default footer data that we print in the bottom margin on each page). Indeed, those are separate from the page-content and aren't subject to the "slicing".
I suspect we won't be able to get the bank site fixed, especially without having an account where we can investigate & tell them precisely what's wrong. (Though: if you're interested to hop on Zoom and don't mind screen-sharing while looking at an affected bit of content, we might be able to figure out which "bucket" the site is in, and potentially we could come up with a workaround that you could apply locally if you like, and which we could suggest to the bank if they're willing. If you're open to that, email me dholbert at mozilla dot com and we can coordinate something.)
In the meantime: we probably should have a bug on file to track the fact that "slicing" is a not-great experience, as a catch-all where we might be able to take action in the future; and I think we can close this bug here as a duplicate of bug 1740304, with the slicing bug (which I'll file) tracking the remaining irksomeness.
|
|
||
Comment 15•3 years ago
•
|
||
(In reply to Daniel Holbert [:dholbert] from comment #14)
we can close this bug here as a duplicate of bug 1740304
--> doing that
with the slicing bug (which I'll file) tracking the remaining irksomeness.
--> filed bug 1759926
|
|
||
Comment 16•3 years ago
|
||
(In reply to Dan Pernokis from comment #13)
No, nothing lost, nothing duplicated -- and yes, "slicing behaviour" sounds exactly right
BTW, Dan and I looked at the affected site (CIBC) in Firefox's devtools, and we isolated the issue that's causing us to lean on our "slicing" fallback. It's a version of bug 1417615, where we encounter an extremely-tall grid-row (containing a whole range of bank-transaction history in this case); and we don't support splitting individual grid-rows across pages, so we fall back to our slicing approach. (And at one point in the past i.e. when bug 1417615 was filed, we would have just let the content run off the first or second page and disappear entirely.)
At this CIBC case, the relevant CSS is here:
.page-wide.main-section{display:-ms-grid;display:grid;
This CSS rule is for an element that contains the transaction history, which ends up in a single tall grid-row, which we can't fragment.
If we apply display:block to this element to turn it into a block instead of a grid, then the layout is essentially unchanged, and it prints just fine.
|
|
||
Comment 17•3 years ago
|
||
(I filed https://github.com/webcompat/web-bugs/issues/101143 as a place we can use for possible outreach to the bank, if we can find any contacts at CIBC, BTW.)
Description
•