Save as PDF incorrectly formats CSS-generated counters
Reported by
gardne...@gmail.com,
Nov 19 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0 Steps to reproduce the problem: 1. Open the attached test.html document in Chrome. 2. Save as PDF using the Print dialog, with default options. 3. Compare the formatting of "Item 2" between Chrome and the PDF. What is the expected behavior? The number "2." preceding the "Item 2" header should be on the same line in both versions. What went wrong? In the PDF, the "Item 2" header is displayed on a separate line from its number, breaking the formatting. Did this work before? N/A Chrome version: Version 62.0.3202.94 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.13 Flash Version: For reference, I've also attached the results of saving this document as a PDF on my own machine. I observed the same behavior using the system print dialog's "Save to PDF" feature on Mac, as well as with Chromium 62.0.3202.89 on Debian sid. Firefox and Safari (current versions on Mac) do not display this behavior. I used the following (default) print options: Pages: All Layout: Portrait Paper size: Letter Margins: Default Scale: 100 Options: Headers and footers on, Background graphics off
,
Nov 28 2017
Able to reproduce the issue on Windows-7,Windows-10,Mac-10.12.6 and Linux Ubuntu-14.04 using chrome latest stable version #62.0.3202.94 and on latest canary #64.0.3279.0 with the steps mentioned in comment#0 Below is the bisect information: Good Build Revision: 56.0.2889.0(424926) Bad Build Revision : 56.0.2890.0(425218) CHANGE-LOG URL: --------------- https://chromium.googlesource.com/chromium/src/+log/e0a1c1bd1456928a05a582c78210a81f8fe30859..c2025efb0537e16c304c37b1df4d687ec698cd68 Suspecting https://codereview.chromium.org/2412923002 from changelog @mstensho: Could you please take a look into this issue and reassign if this issue is not related to your change. Thanks..!!
,
Nov 28 2017
Believe it or not, but this is intentional behavior. Attaching a couple of demos. This was introduced by https://codereview.chromium.org/2412923002 The counter becomes a short table cell, which is next to another potentially tall table cell. Edge does the same. If there's a page (or column) break inside any of the table cells, we ignore the requested vertical alignment, and top-align everything. Otherwise, the vertical alignment and fragmentation machineries might start to fight - cyclic dependencies. Fragmentation (pagination) affects the height of the content. The height of the content affects vertical alignment. Vertical re-alignment may affect where we're allowed to fragment, which may mean that we have to re-fragment, which may give us a new height, so that we may re-re-align. And so on. |
|||
►
Sign in to add a comment |
|||
Comment 1 by manoranj...@chromium.org
, Nov 20 2017