sile icon indicating copy to clipboard operation
sile copied to clipboard

Balanced columns can overflow

Open alerque opened this issue 9 years ago • 2 comments

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 avatar Jun 29 '15 13:06 alerque

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 avatar Jul 02 '15 13:07 simoncozens

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.

simoncozens avatar Mar 21 '16 12:03 simoncozens