div with same height as @page printed across two pages |
||||||||||
Issue descriptionChrome Version: 57.0.2987.110 (Official Build) (64-bit) OS: Linux What steps will reproduce the problem? 1. Open the attached HTML file. 2. View the document in print preview with background graphics on. What is the expected result? One page is printed, containing the entire tall skinny div. I expect this because the div height and the @page height are the same. What happens instead? Two pages are printed. A few pixels of the tall skinny div are on the second page. (If the div width is increased to 300pt then it prints on one page as expected, possibly because resizePageRectsKeepingRatio rounding the height differently?).
,
Mar 30 2017
> If you change the margin from Default to None, then it fits. I can see this when printing to a printer, but not when "Save as PDF" is selected. When "save as PDF" is selected I get two pages either way. > Does this sound like bug 424742? It's possible, but it does not sound like it to me. Are there any pointers to how I could verify one way or another (I'm comfortable debugging / navigating code if needed)? (My initial guess was that this is a "rounding" issue between resizePageRectsKeepingRatio and printingMinimumShrinkFactor)
,
Mar 30 2017
,
Apr 5 2017
Tested the issue on chrome Stable #57.0.2987.133, Canary 59.0.3063.0 in Ubuntu 14.04 and was able to reproduce the issue. This is a Non-Regression issue since seeing this from M35 #35.0.1849.0, Making the status to Untriaged so that the issue would get addressed. Note : Able to reproduce the issue in MAC 10.12 and Windows 10.0 & 7. Thank you.
,
Apr 25 2017
Yes, I agree it is weird with "Save As PDF" that minimal margins does not work.
,
Apr 25 2017
+robhogan if interested.
,
May 8 2017
Another place with a possible rounding issue: https://cs.chromium.org/chromium/src/components/printing/renderer/print_web_view_helper.cc?rcl=0f727a7e734fbbf7f018cda55a97bb751d8bcdac&l=249 Since this (I think) is used to calculate page layout size, flooring the result of the conversion could potentially cause the page to be laid out with too small dimensions. BTW a few more fun real world test cases attached that fail with margin default or margin none.
,
Jul 3 2017
Is there any progress on this? With the release of headless chrome it is very hard to export PDF with correct size because of this bug.
,
Jul 4 2017
Examples in #7 use "page-break-after: always;" for the page divs -- so yes there will be a blank page in any case! Did you mean "page-break-after: auto;" to see if 1122px may fit within 1122.52px height?.
,
Jul 4 2017
Example #1 "pagefillingdiv.html" Can't reproduce the blank page when saving to PDF with Default/None/Minimal print margins. Tested on 59.0.3071.104 (64-bit) Linux. Q: What DPI are you using (GUESS: > 100?)
,
Jul 4 2017
I'm seeing similar issues but for me a 297mm tall div does not fit a 297mm tall page completely. Attaching a test file calculating px/mm ratios for 100 (page filling) div elements ... Q: I'm not supposed to see 2 different ratios for 297mm tall divs -- am I? Example: a4page100.html:10 body: 3.781144781144781 3.780952380952381 a4page100.html:16 elem: 3.781144781144781 3.780952380952381 <-- ok a4page100.html:16 elem: 3.7777777777777777 3.780952380952381 <-- too small! a4page100.html:16 elem: 3.781144781144781 3.780952380952381 <-- ok […] Result: Scroll down the Print-Preview ... May someone please check attached file and take a look into the console? I doubt that page filling div elements should report _different!_ px/mm ratios for their height. I'm seeing
,
Jul 5 2017
Re comment #9, maybe I'm understanding what should happen wrong, but I meant page-break-after:always. This is what I expected would happen: Expected behavior: The div fits inside the page defined by CSS. The div has a page break after it, causing pagination to layout the next div on the start of the next page, with no completely or mostly blank pages in-between. In other words the page break happens near the end of the first page. Actual behavior: The second page is mostly or completely blank, as if the first div was on the second page a bit; pushing the page-break to near the start of the second page as well. Attached is what I see, and what I expect to see for portrait_a4_pt.html If the actual behavior is in-line with the spec then that's OK.
,
Jul 5 2017
Re comment #11, > Q: I'm not supposed to see 2 different ratios for 297mm tall divs -- am I? The "ok" line has height 1122px, the "too small" line has height 1123px. With elem.getBoundingClientRect().height, it is always 1122.515625px (a bit smaller than 297mm due to conversion to fixed point CSS units). The CSS value is awfully close to 1122.5, so maybe it's just rounding down sometimes due to floating point calculations near [1] or something? For example I see that AdjustLayoutUnitForAbsoluteZoom uses single-precision division. Anyway to me (not being a layout or printing expert) 1123px seems like a reasonable value here. Even in cases where clientHeight rounded down, the actual div is around 1122.5px. [1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Element.cpp?rcl=d4945f6278ba6d1c93d5fa8afd8b08d0a59cbfd3&l=855
,
Jul 5 2017
Re comment #10, I'm pretty sure it's 96, though Linux is confusing me a bit. $ xdpyinfo | grep dots resolution: 96x96 dots per inch $ xrdb -query | grep dpi Xft.dpi: 96 $ grep DPI /var/log/Xorg.0.log [ 2036.685] (--) NVIDIA(0): DPI set to (101, 101); computed from "UseEdidDpi" X config I attached what I see while printing.
,
Jul 5 2017
#12 - CSS2.1 [1] only mentions a page box that consists of the page area and margin area whereas the margin is being defined in the page at-rule. Furthermore it states "The size of a page box cannot be specified in CSS2.1.".
The page-break-after: always instructs to break the current page box and layout the siblings into new page boxes. So speaking strictly about CSS2.1 blank pages may occur or may not as the UA decides about the page box size. In your case the box seems to be too small.
Interestingly adding a body { width: 300pt; height: 300pt; } declaration matching what you have specified in the page at-rule size declaration fixes your issue, but sadly not mine :|
As chromium implements the CSS3 page at-rule size declaration [2] (among other features as the :left and :right pseudo selectors) it should be well aware about the page box size and honor that.
In my opinion using @page { size: 1122.52px ... } and placing 3 div elements with height: 1122.5px having page-break-after: always declaration should result in 3 pages and not 4 or 5 with blank pages inserted in between. If the div height would have been set to 1122.52px (exactly the page box) there should be 5 pages as specified in [1] 13.3.4.
Furthermore using @page { size: 297mm ... } and placing multiple (see my 100 page example in #11) div elements with height: 297mm not using forced page breaks should not result in any overlapping of any div on multiple pages as observed in attached a4page-overlap.png. I'm using page-at and body size rules being exactly the same so there must be a rounding issue somewhere.
[1] https://www.w3.org/TR/CSS2/page.html
[2] https://www.w3.org/TR/css3-page/#page-size-prop
,
Jul 6
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
,
Oct 25
,
Nov 1
This does not repro for me. Looks like r468823 fixed this for bug 716548 . Can you confirm?
,
Nov 1
I can still reproduce this issue with the "portrait_executive_px.html" and "portrait_a4_pt.html " test cases from comment#7 at head.
Version: 72.0.3599.0 (Developer Build) (64-bit)
8b5745026eb8c4a628155cc10ac0576e354e4105-refs/heads/master@{#604742}
OS: Debian (gLinux)
Steps to reproduce:
1. Launch Chrome.
2. Navigate to one of the HTML documents mentioned above
3. Select "Print..." on the menu to open the print preview dialog.
4. Make sure destination is PDF, and that background graphics are shown
(In my experience it might also help to toggle destination PDF off and on again,
if the settings are in an unexpected state)
5. Observe that the print preview shows blank pages. Optionally print the PDF and see the same behavior in a PDF viewer.
Attached is a screenshot.
,
Nov 2
For portrait_a4_pt.html, every browser that I tried renders 8 pages when I selected A4 paper.
,
Nov 2
,
Dec 3
Mac triage: to thestig@ - is this fixed/WAI? I can't tell from the comment thread.
,
Dec 3
I still think the remaining issues are WontFix per comment 20. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by thestig@chromium.org
, Mar 30 2017