third_party/WebKit/LayoutTests/printing/multicol-2-pages.html - Issue 1492143002: Add support for printing multicol containers, and enable it.

Side by Side Diff: third_party/WebKit/LayoutTests/printing/multicol-2-pages.html

Issue 1492143002: Add support for printing multicol containers, and enable it. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Okay, bots. You won this round! Created 5 years ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« no previous file with comments | « third_party/WebKit/LayoutTests/printing/multicol.html ('k') | third_party/WebKit/LayoutTests/printing/multicol-2-pages-expected.html » ('j') | third_party/WebKit/Source/core/layout/LayoutView.cpp » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <script>

	3 if (window.testRunner)

	4 testRunner.setPrinting();

	5 if (window.internals)

	6 internals.settings.setShouldPrintBackgrounds(true);

	7 </script>

	8 <!-- TODO(mstensho): Try to come up with something that doesn't make assumptions about page

	9 height. Currently, there's no way of specifying it for layout tests. This t est currently

	10 assumes that 5 lines will fit in each column on the first page, and the rem aining ones on the
	leviw_travelin_and_unemployed 2015/12/08 19:00:55 D'oh :( We could add a testRunner feature to enabl D'oh :( We could add a testRunner feature to enable that :-/ mstensho (USE GERRIT) 2015/12/08 20:09:12 Uh... yeah, I'd like that. I actually tried to jus Show quoted text On 2015/12/08 19:00:55, leviw wrote: > D'oh :( We could add a testRunner feature to enable that :-/ Uh... yeah, I'd like that. I actually tried to just make testRunner handle @page { size:<...>; }. That's pretty straight-forward, but it turned out that the code is generally confused when it comes to page size. I managed to make this work, but what I specified in @page wasn't exactly the page size I got in practice. Off by a few percents or so. I stepped through the code (in Chrome). If you have @page { size:200px; } Document::pageSizeAndMarginsInPixels() does exactly what it says. I don't remember now who called it, but I think it was on behalf of non-Blink code. The first thing we do afterwards is convert it to points. There are some complicated dance steps to follow here, but we end up with 150pt. This makes sense, since CSS says that DPI is always 96, so 200px == 150pt. Then we call some Blink API (don't remember which one), which specifies the page parameters with struct WebPrintParams, where all values are in pt, and we also get this right. Then, back on the Blink side, probably in WebLocalFrameImpl::printBegin(), we are told to make 150pt wide and tall pages. So far so good. We pass this to PrintContext::begin(), which calls deeper into Blink. At this point, everyone thinks we have the values specified in pixels, so we'd end up with 150px, not 150pt. But wait! There's more! PrintContext::begin() scales the size by 1.25 (printingMinimumShrinkFactor), because.... PRINTING! So if @page asks for a 200px by 200px page, we get a 187.5px by 187.5px one. Pretty close, indeed, given the circumstances. Long story short: Better clean up this before attempting to make reliable tests.
	11 next page. -->

	12 <p>There should be three columns in this document - on this page, and on the nex t page. The numbers

	13 should be in ascending order when reading columns from left to right, page b y page.</p>

	14 <div style="-webkit-columns:3; -webkit-column-gap:11px; -webkit-column-rule:3px solid hotpink; width:622px; font-size:112px; background:papayawhip;">

	15 01<br>

	16 02<br>

	17 03<br>

	18 04<br>

	19 05<br>

	20 06<br>

	21 07<br>

	22 08<br>

	23 09<br>

	24 10<br>

	25 11<br>

	26 12<br>

	27 13<br>

	28 14<br>

	29 15<br>

	30 16<br>

	31 17<br>

	32 18<br>

	33 19<br>

	34 20<br>

	35 21<br>

	36 22<br>

	37 23<br>

	38 </div>

OLD	NEW