Position absolute elements are not predictable during pdf printing
Reported by
anand.an...@gmail.com,
Apr 28 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. Open page https://anandanand84.github.io/chrome-pdf-issue/ 2. Use print view, Make sure page size is Letter and margin is none, scroll down the pages above 40. 3. You can see the page numbers being offset from the top as the page count increases What is the expected behavior? The page numbers positioned using position absolute for corresponding page for the corresponding size should be at the top of every page. The page numbers displayed were gradually offsets from the top as the no of pages increases. What went wrong? In the example the page number elements are positioned absolute at the corresponding mm for the page, in this case for Letter assuming the height of 279.4mm. Elements are positioned at 279.4mm, 558.8 and so on and is expected to be at the top of every page. If this is working as expected what is the logic or the size that should be used to position elements exactly at the top of every page. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 58.0.3029.81 Channel: stable OS Version: OS X 10.12.3 Flash Version:
,
Apr 28 2017
ligimole: Not sure why you labeled this as P1 / Needs-Bisect.
,
Apr 28 2017
Our team picks up for triaging and bisecting based on the priority.So to get immediate attention tagged with the above labels.
,
Apr 28 2017
This is not a regression, so we don't need to bisect. Blink layout folks should triage, as Blink is doing the layout.
,
May 1 2017
Looks like the mm measurements are rounded incorrectly and the error accumulates. Not quite sure where the error happens but adding atotic as he knows our abs pos code quite well by now.
,
May 2 2017
It is not a cummulative rounding error. I've tried the above code using 1056px page size, instead of 279.4mm, same problem. The numbers line up perfectly if I assume page size is 1054px. Turns out the rounding error is in C++. Fix comming up.
,
May 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/78d293247b9fdde885702c3e9a879e8710e131f8 commit 78d293247b9fdde885702c3e9a879e8710e131f8 Author: atotic <atotic@chromium.org> Date: Tue May 02 23:49:13 2017 Fix incorrectly rounded page size. Internal page size for Letter sized pages was 1054px instead of 1056px. kPrintingMinimumShrinkFactor of 1.333f was not enough precision. It caused incorrect rounding inside of ResizePageRectsKeepingRatio. Changing the constant makes page size correct. BUG= 716548 Review-Url: https://codereview.chromium.org/2854143003 Cr-Commit-Position: refs/heads/master@{#468823} [modify] https://crrev.com/78d293247b9fdde885702c3e9a879e8710e131f8/third_party/WebKit/Source/core/page/PrintContext.cpp [modify] https://crrev.com/78d293247b9fdde885702c3e9a879e8710e131f8/third_party/WebKit/Source/web/tests/WebViewTest.cpp
,
May 3 2017
Thanks for the quick fix. Time to close?
,
May 3 2017
Will the precision fix work across all paper sizes? I believe this happens not only in Letter but also in other paper sizes like A4 as well. https://anandanand84.github.io/chrome-pdf-issue/A4
,
May 3 2017
+robhogan FYI.
,
May 3 2017
Just tested A4, and it did not work when page size was 297mm. But it did work when page size is 1122px. This happens because page size is rounded down in layout to nearest pixel. A4 paper size is: 210 x 297 mm 8.26772 x 11.6929 in 1in = 96px per css 793.70112 x 1122.5184 px In Layout, Chrome thinks each page is 793 x 1122px. If you are absolutely positioning wrt 0,0 and expect page numbers to line up, you have to go with these numbers. Any objections to closing the bug?
,
May 3 2017
If we have a predictable behavior which is if we use pixel value instead of mm then I think we can close this issue. Thanks for such a quick turnaround.
,
May 3 2017
,
Apr 17 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by ligim...@chromium.org
, Apr 28 2017Components: Internals>Plugins>PDF
Labels: -Pri-2 Needs-Bisect Needs-Triage-M58 Prestable-58.0.3029.81 Pri-1