Printing web page as multipage PDF results in improper pages alignment
Reported by
vladysla...@gmail.com,
May 5 2017
|
||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36
Steps to reproduce the problem:
1. Specify print page size with @page css rule:
@page {
size: 200px 315px;
padding: 0;
margin: 0;
}
2. Specify div.page to have the same size:
div.page {
width: 200px;
height: 315px;
overflow: hidden;
}
3. Set body margin and padding to 0:
body {
margin: 0;
padding: 0;
}
4. Add multiple div.page element into html body:
<body>
<div class="page"></div>
<div class="page"></div>
</body>
4. Print page and save it as PDF
What is the expected behavior?
The PDF should contain two pages with size 200x315px.
What went wrong?
The PDF contain three pages with size 200x315px.
The content of the two pages gets misaligned. The most bottom layer of pixels of each page gets moved on the top of the next page, leaving a white line on the page it belongs. Third page gets added to contain shifted content from the second page.
Did this work before? No
Does this work in other browsers? Yes
Chrome version: 58.0.3029.96 Channel: stable
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 25.0 r0
Two online examples that mark pages with different colours to make the issue more obvious.
Simple example: https://jsfiddle.net/1zr1o7am/
Multipage example: https://jsfiddle.net/eegvzaus/
,
May 8 2017
Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.96 and canary 60.0.3091.0. This is non regression issue as the issue observed from M30 old builds. Marking it as Untriaged. Thanks,
,
May 9 2017
The bug reproduces with different page sizes, but not with all. With rough estimate it affects about 10-25% width and height combinations.
Taking a look into internals of the printed PDF, it seems that page bounds and the content are affected by some rounding error and they are rounded differently.
For example for the given example the page size is 200x315px, which is 150x236.25pt.
Matrix concatenation instruction uses height value of 236(pt) instead of 236.25pt:
1 0 0 -1 0 236 cm % (concatenate matrix to current transformation matrix)
Clipping path is built with height 235.5pt, which is exactly 314px - 1 pixels less than the desired height:
0 0 150 235.5 re % (append rectangle to path)
W* % (set clipping path using even-odd rule)
n % (end path without filling or stroking)
,
May 19 2017
Yes, it's a rounding error. In blink::PrintContext::ComputePageRects(), one of the heights ends up as 314 instead of 315. I tried rounding up just to see what would happen, but that causes other test pages to round the wrong way.
,
May 26 2017
+robhogan if interested.
,
Jun 27 2017
,
Jun 28 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 1
,
Aug 1
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kavvaru@chromium.org
, May 5 2017