Fix#1666.
Note that the added test doesn’t test this problem, because the "hash" function
is stable when we use the same process. If someone finds a nice way to solve
this…
Before this commit, when we had to break previously rendered waiting children
in a line, we re-rendered the already-rendered children. That was bad, because
the tree of the children that were already rendered were different from the
original tree, that may include leading spaces for example. It also required a
complex mix of the original resume-at with the original skip-stack.
This new solution includes both the original child (to render it from a fresh
start) and the already-rendered child (to get the previous positions). The
skip-stack mix is now useless, removing a lot of complex code.
This change is scary and will probably break some corner cases. But tests pass,
and a new one has been added to avoid future regressions.
Fix#1638.
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.)
