PrintToPdf Incorrect size calculations for elements outside page
Reported by
asonc...@gmail.com,
Mar 7 2018
|
|||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36
Steps to reproduce the problem:
1. Print the attached HTML document with the following parameters:
printToPdf({
landscape: true,
displayHeaderFooter: false,
printBackground: true,
scale: 1,
paperHeight: 4,
paperWidth: 3,
marginTop: 0,
marginLeft: 0,
marginRight: 0,
marginBottom: 0,
pageRanges: '',
preferCSSPageSize: true
})
2. Open the document side-by-side with the resulting PDF in a browser.
3. Note the pages 1 and 2 look different than the browser render.
What is the expected behavior?
All 3 .page-content (yellow area) should have a height equal to the full height of the container. This works on the third page (.bleed.ok) if we remove the negative top and bottom styles, but is broken on pages 1 and 2.
What went wrong?
It seems like any element that has top or bottom edges outside of the page has its dimensions incorrectly calculated (e.g. height is ignored) even with overflow: hidden; style on the page.
Unfortunately for this use case, we need to have a 'bleed' area, which requires the inner .page-content to be outside of the wrapping .page.
Note that there is also a misalignment in the height of the yellow block on tile 2, aside from the fact that it is not 100% height, it also slightly lower than the block on page 1.
Did this work before? N/A
Chrome version: 64.0.3282.186 Channel: stable
OS Version:
Flash Version:
I've been following this bug since Chrome 61. Please also see:
https://bugs.chromium.org/p/chromium/issues/detail?id=774970
and
https://bugs.chromium.org/p/chromium/issues/detail?id=772685
,
Mar 7 2018
,
Mar 7 2018
,
Mar 7 2018
Just wanted to mention: I did not see it ever working before Chrome 61 -- I've just noted it has been broken since at least then.
,
Mar 7 2018
Removing bisect label based on comment #4. Is this another headless bug, because on linux M-65 the print preview looks fine as does the resulting pdf? Thanks for filing all these printing issues. We do appreciate it.
,
Mar 7 2018
This is a Chrome Headless issue. Per my other comment -- "I am using node.js with 'Remote Chrome Interface' adapter (https://github.com/cyrus-and/chrome-remote-interface). You can also use Puppeteer to achieve the same (https://github.com/GoogleChrome/puppeteer)."
,
Mar 7 2018
I'll look into setting up the necessary infrastructure by end of week. It's not the first time I've needed node.js to triage a bug.
,
Mar 7 2018
I've setup a repo for testing Headless issues - Linux + Docker + nodejs. This might save you some time: https://github.com/soncodi/chromium-headless-printtopdf Please let me know how I can help!
,
Mar 8 2018
,
Mar 8 2018
As per comment #6, this is Chrome Headless issue. Hence adding appropriate component and labels. Thanks..
,
Mar 8 2018
Thanks very much for the testing repo.
,
Mar 12 2018
Issue still appears in nightly Chromium 67.0.3369.0 (64-bit)
,
Mar 13 2018
This doesn't seem to be a SkPDF issue. If I print to a mskp file, then run that through skia's raster backend, I still get the problem. Probably a blink issue.
,
Mar 27 2018
Hello, should I post the issue elsewhere and/or to whom should I forward it?
,
Apr 30 2018
Hi, any update on this issue? Thanks!
,
May 29 2018
Hello, any update on this issue? Thank you.
,
May 30 2018
This issue and related https://bugs.chromium.org/p/chromium/issues/detail?id=774970 are impacting a large percentage of our users in production. This is of critical priority to us. We can help with testing and infrastructure setup. Please let us know what can be done to fast-track this.
,
Jun 28 2018
Hello, any update on this?
,
Jun 29 2018
Best estimate right now is a fix for Chrome 69.
,
Jul 20
Would love to see this fixed
,
Jul 25
Hi, is there any progress around this issue?
,
Aug 17
Any update on this issue?
,
Aug 20
We're starting to look into this but the fix is likely to be complex. There's a significant rewrite happening in this are of the code and we might just wait to fix it with that project.
,
Aug 29
Any ETA/Chromium version for a possible fix? Are there any known workarounds at this time? We've tried everything from position to translate() etc..
,
Sep 12
@schenney which fixes did you think would help to resolve this bug?
,
Nov 9
Hello, any further updates on this issue? This essentially breaks any use-cases where page bleed is simulated during design and hidden during print, making it impractical to use Chromium for executing professional prints.
,
Nov 10
Sorry, too much else going on that is too important, even though I understand this is important too. I'm adding the Layout component because the related issues are really part of layout when printing.
,
Jan 7
Hello and happy new year! Where can I track the rewrite you mentioned earlier (comment 23)? Any hints on whether progress there is likely to close this ticket? |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by asonc...@gmail.com
, Mar 7 201816.5 KB
16.5 KB Download