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

Balanced columns can overflow #118

Open
alerque opened this issue Jun 29, 2015 · 2 comments
Open

Balanced columns can overflow #118

alerque opened this issue Jun 29, 2015 · 2 comments
Labels
bug Software bug issue
Milestone

Comments

@alerque
Copy link
Member

alerque commented Jun 29, 2015

Most of the time it seems to work out fine, but for some reason in edge cases where the second frame ends up a line longer than the first frame, it can wrap the line back into the first frame. Case in point, playing with fonts in the tests/balanced.sil netted me this:

balanced pdf_023

See 6bd7bf7 for the tweak where I first saw this, but I'll try to work up a better test case later.

alerque added a commit to alerque/sile that referenced this issue Jun 29, 2015
@simoncozens
Copy link
Member

OK, I see why this is happening. It's not actually wrapping into the first frame, but it's spilling into the next frame (where "Chapter 3" is).

What is happening, in a bit more detail: The balancer works by shipping out pages as normal as much as possible until it gets to a page that needs to have a balanced column at the end of it. When it does, it calculates the total height of the material, divides it by the number of columns, and sets the height of the columns to be that number, then calls the ordinary page builder to lay out the material across the columns. All the columns are equal height and the material is evenly divided between them, so balanced columns, right?

Wrong. Because let's say you have 40pts of material and you make two 20pt-high columns, but actually your material is made up of one 8pt line, and two 16pt lines, the second line won't fit in column 1 and will be shunted onto column 2, and now the third line won't fit on column 2 and will overflow.

The situation is just about OK when you have a good number of lines and also you're typesetting on a grid (so that your content does end up evenly spaced and hopefully evenly divisible between your number of columns), but a proper solution needs a better algorithm for balancing the material, that also takes into account the number of lines (and inter-paragraph skips, which is the tricky bit) in the layout process.

@simoncozens
Copy link
Member

Something else weird is happening with this bug. If the baselineskip has no stretch, then the right-hand column is always smaller than the left-hand one. But if it has some stretch, the right-hand column is always at least one line longer than the left-hand one.

@alerque alerque added this to the v0.9.5 milestone Mar 21, 2016
@alerque alerque modified the milestones: v0.9.5, v0.9.6 Aug 12, 2016
@simoncozens simoncozens added bug Software bug issue high priority labels Sep 6, 2016
@alerque alerque modified the milestones: v0.9.6, v0.9.7 Jan 11, 2019
@alerque alerque modified the milestones: v0.11.2, v0.11.x Sep 16, 2021
@alerque alerque modified the milestones: v0.12.1, v0.12.x Jan 12, 2022
@alerque alerque modified the milestones: v0.12.3, v0.12.x Mar 2, 2022
@alerque alerque removed this from the v0.12.x milestone Apr 18, 2022
@alerque alerque added this to the v0.x.y milestone Dec 13, 2022
@alerque alerque modified the milestones: v0.x.y, v1.0.0 Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Software bug issue
Projects
None yet
Development

No branches or pull requests

2 participants