Unexpected PDF page dimensions and page-break behavior with vertical writing mode. |
|||||||||
Issue descriptionChrome Version: 60.0.3112.101 (Official Build) (64-bit) OS: Linux Ubuntu What steps will reproduce the problem? (1) Browse to attached HTML (2) Look at the "Save as PDF" print preview (custom margins, custom page size, or a physical printer must not be selected to get the page's @page CSS) (3) Note the location of the blue rectangle, the yellow rectangle, and the two "Z" characters in the text. What is the expected result? The first page should contain the green rectangle reflecting the dimensions in the CSS "@page" rule. The first Z at the end of the first page should not be spliced across the first and second page. The second Z in the middle of the second page should not be followed by a gap. What happens instead? The first page just includes the blue rectangle, 3/4ths too small according to the "@page" rule. The first Z is spliced across pages. The text appears to have a gap in the middle of the second page after the second Z. Also things seem to work as expected in the default horizontal writing mode. It's possible this is another case of me misunderstanding CSS specs; but it looks like there's a layout page break is put in the middle of the second PDF page, which seems incorrect. Not sure if this is a printing issue, or a layout issue, or a little of both.
,
Aug 29 2017
,
Aug 29 2017
,
Aug 29 2017
,
Aug 29 2017
Issue 760216 has been merged into this issue.
,
Aug 29 2017
,
Aug 29 2017
,
Aug 30 2017
If you are curious about the code, blink::PrintContext::ComputePageRects() and blink::LocalFrame::ResizePageRectsKeepingRatio() may be of interest.
,
Aug 30 2017
Yeah I've been looking at it. If I use (3000,4000) instead of the document rect in PrintContext::ComputePageRects then everything seems to work as expected. I think wires are getting crossed somewhere from dealing with logical dimensions, but I'm not quite sure how. By the way it might also work as expected before this change, I'll double-check tomorrow: https://codereview.chromium.org/1423643002
,
Aug 30 2017
Correct me if I've made any bad assumptions, but could the issue be with LayoutView::GetLayoutSize? LayoutView::PageLogicalHeight is described as being used to split the content into pages [1]. Since it's logical, in vertical writing mode it should be the width of the page (makes sense as page breaks are between pages horizontally). In printing mode LayoutView::GetLayoutSize returns (view width, page logical height) [2]. In vertical mode the Document's LayoutView's physical dimensions are set as follows: * width is set to the view width from [3]. * height is set to the page logical height from [4] In horizontal mode the dimensions are instead: * width is again set to view width from [4] * height is again set to page logical height from [3] Note how the height is the logical height in both cases. This means that vertical mode is more like: * width is set to the view width from [3]. * height is set to the page width from [4] Which seems wrong... do you think LayoutView::GetLayoutSize should return (page logical height, view height) in the vertical writing case to reflect the page's initial containing block? But I still don't understand how the change I linked above could have broke it in the first place. Layout code makes my head spin a bit. [1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutView.h?rcl=0397489124ce7e6aced020f8b85f5034c7d5f49b&l=291 [2] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutView.cpp?rcl=bbcbac2763e4d3bd5b1f3a627a89aa0fbfc87523&l=747 [3] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutView.cpp?rcl=a9c25d0f8c2e1904a8e4c0baa61c3e58b4258524&l=200 [4] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutView.cpp?rcl=a9c25d0f8c2e1904a8e4c0baa61c3e58b4258524&l=204
,
Aug 31
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
,
Sep 10
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 Deleted