Previously, if a footnote triggered an overflow (that is, it was too
large for the containing space), but footnote-policy didn't make us push
down the line containing it, any subsequent footnotes in the same
linebox would not be set into a footnote area, because they would never
be passed to layout_footnote and report_footnote. (Their call sites
would be set, but their content would not be.)
This also fixes a potential infinite loop where using footnote-policy
could have forced the first line of a page to be pushed to the next
page: that will just result in an infinite loop, so instead we set the
line and move on if we are on the first line of a page. (This behavior
is not specified in GCPM, but no other behavior seems practical: the
only alternative would be to expand the page, which is almost certainly
less desirable.)
Previously, if a footnote triggered an overflow (that is, it was too
large for the containing space), but footnote-policy didn't make us push
down the line containing it, any subsequent footnotes in the same
linebox would not be set into a footnote area, because they would never
be passed to layout_footnote and report_footnote. (Their call sites
would be set, but their content would not be.)
This also fixes a potential infinite loop where using footnote-policy
could have forced the first line of a page to be pushed to the next
page: that will just result in an infinite loop, so instead we set the
line and move on if we are on the first line of a page. (This behavior
is not specified in GCPM, but no other behavior seems practical: the
only alternative would be to expand the page, which is almost certainly
less desirable.)
The text-decoration-* properties are not inherited anymore, they are propagated
according to specific rules.
This commit removes the inheritance, but it doesn’t follow all the rules
defined by the specification. The new behavior is not perfect, but it should be
at least better than the previous code and opens the possibility to fix this
issue correctly in the future.
Failing tests have been added.
Fix#1621.
The default "2" value for orphans and widows is really useful for real
documents, but it can be very disturbing for tests and introduce false
negatives and false positives.
The primary change here is that the column calculation algorithm now
attempts to render columns as if they were the full remaining height on
the page, rather than to render the entire content regardless of how
long the page is.
The worst-case behavior is effectively the same as that of the previous
algorithm (as at least one additional pass would be required to
determine how high balanced columns should be, but this applies in both
cases), but if content would not fit on the page, this can bail and set
the page immediately, rather than continuing significantly more
calculations.
As an associated benefit, this closes#1020, as we now handle multiple
column breaks (which would force a page break) correctly. A test for
this behavior is included.
Previously, this would throw an error because absolute_layout hadn't had
a chance to lay out the boxes. Now we do the block level layout for
footnotes *before* doing layout for absolute boxes (or fixed boxes) and
add any positioned boxes to positioned_boxes so they can be put onto the
page correctly.
When a box would break over the edge of a page, its height is extended
to the bottom of that page (per
https://www.w3.org/TR/css-break-3/#box-splitting , primarily to allow
backgrounds and borders to continue to the end of the page).
When this happened, sometimes the values that would be calculated for
the height of the extended element would be rounded *over* the
calculated height that remained on the page, forcing the entire
containing box to wrap to the next page.
Rather than trying to carefully manage the order of operations to try to
be safe in IEEE floats for directions, we apply a small "fudge factor":
if an element fits very nearly (within a thousandth of a pixel) into the
remaining space, it is still accepted.
This fixes a bug accidentally introduced in #1566, where we would try to
unlayout a footnote that had not yet been laid out, if the algorithm
decided that there would be insufficient space on a page before laying
out a further footnote.
If a footnote has been output but we then decide to cancel the line it
was output on, we should cancel the output of the footnote itself.
This requires a bit of extra bookkeeping, so we know which footnotes are
relevant, but otherwise largely works using the existing
remove_placeholders code.
Includes a minor refactor of footnote area management in LayoutContext,
and a new testing utility: `tree_position`.
Closes#1564.
This commit:
- fixes the trailing space detection, by handling all trailing spacing
characters that could be ignored by Pango’s line break algorithm;
- tries harder to break waiting children when a line break occurs in an
inline block that can’t be separated from the previous one.
Fix#1562.
When a box would break over the edge of a page, its height is extended
to the bottom of that page (per
https://www.w3.org/TR/css-break-3/#box-splitting , primarily to allow
backgrounds and borders to continue to the end of the page).
When this happened, sometimes the values that would be calculated for
the height of the extended element would be rounded *over* the
calculated height that remained on the page, forcing the entire
containing box to wrap to the next page.
Rather than trying to carefully manage the order of operations to try to
be safe in IEEE floats for directions, we apply a small "fudge factor":
if an element fits very nearly (within a thousandth of a pixel) into the
remaining space, it is still accepted.
Previously, if `overflow-wrap: anywhere` (or `break-word`) was set on an
inline element (like an `<a>` or `<span>`) whose first word occurred
towards the end of a line, it would have broken that word, even if doing
so wasn't necessary (and wouldn't have happened were it not for the
wrapping element).
This pipes through a `is_line_start` argument to `split_text_box` that
only allows the break on a word if it's the first word in a line.
When we calculate the minimum width of an inline block, the size of the
trailing space is already removed by split_first_line. There’s no need to
remove it twice.
We should probably fix split_first_line to remove the trailing space only when
it’s been asked to. But there’s no obvious situation when we want the minimum
width to include trailing spaces, as the minimum size requires line breaks
everywhere, including after each space.
At least, this commit doesn’t remove trailing spaces twice.
Related to #1520.
