Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: sequential footnotes could disappear when overflowing #1636

Merged
merged 1 commit into from
May 2, 2022

Conversation

aschmitz
Copy link
Contributor

@aschmitz aschmitz commented May 2, 2022

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.)
@liZe liZe merged commit 48b1605 into Kozea:master May 2, 2022
@liZe liZe added this to the 55.0 milestone May 2, 2022
@liZe liZe added the bug Existing features not working as expected label May 2, 2022
aschmitz referenced this pull request May 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Existing features not working as expected
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants