When "slicing" printing-improvement preserves overflow from a clipped line-box or grid row, shift down the line or grid row on the next page to leave space for the expected overflow
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox85 | --- | fixed |
People
(Reporter: dholbert, Assigned: MatsPalmgren_bugz)
References
Details
(Whiteboard: [print2020_v85][frag2020])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Before the improvements in bug 1640197 can ship to release, we need to add some special handling to prevent the newly-painted content from stomping on top of content on the next page.
Specifically: in cases where we've got block-axis-stacked unfragmentable boxes (like line-boxes and grid rows) that don't overlap on-screen, and would normally get clipped at the bottom of a page, and where the subsequent box would be aligned at the top of the next page, that's a scenario where we're at risk of bug 1640197 creating new/bad overlap and that's something we should address here.
In these cases, we'll now need to watch for when we exceed the available BSize, and see how much of our box (the line box or grid row) was clipped; and we need to offset the next one (on the next page) by that amount, to create room for the projected overflow.
Special considerations:
-
This offset might be multiple page-heights in size, e.g. if the clipped line contains an extremely tall thing (like if it contains an inline-block that holds the majority of the page's content, for example).
-
There also might be cases where we want to reduce this offset; e.g. if there's an extremely tall line that doesn't have anything painted below a certain point, then maybe we don't need to bother offsetting beyond that point.
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Comment 3•4 years ago
|
||
bugherder |
Description
•