Some notes about the implementation and the current status
converted to 1.6 markup
|No differences found!|
This page describes how we will do multi-column layout using the Knuth approach.
the "span" property: http://www.w3.org/TR/xsl/slice7.html#span
the "column-count" property: http://www.w3.org/TR/xsl/slice7.html#column-count
the "column-gap" property: http://www.w3.org/TR/xsl/slice7.html#column-gap
While creating the element list we have to be on the lookout for changing span values. When a chance is encountered, the creation of the element list has to be stopped, the content generated up to the point of the change, then restarted with the new IPD. (solved)
When a span change occurs, the columns have to be balanced. That means we actually don't have a fixed available BPD. The BPD used by a set of columns before a "span-change" depends on the break decisions. (solved, may have to be improved if it turns out not to be good enough)
column breaks need to be handled appropriately. (solved)
Handling footnotes on multi-column pages and mixed single-/multicolumn pages (OPEN)
Column balancing can probably be handled by using a special badness functions which forces breaks that result in more or less balanced columns. The effective BPD of the column set will then be the maximum of all the used BPDs in the set.
Most changes happened in PageSequenceLayoutManager which is responsible to handle span changes and to initiate column balancing using a special subclass of PageBreakingAlgorithm, called BalancingColumnBreakingAlgorithm, which essentially replaces the badness/demerit function for the breaking algorithm to encourage choosing breaks that result in balanced columns. The PageViewportProvider (in PSLM) was adjusted to report the correct available BPD in mixed single-/multicolumn situations.
Footnotes always span the whole width of the region-body so footnotes from every column add up on the space used by footnotes. The difficulty is the fact that you might get a footnote on the second column while you more or less decided on the break position on the first column already. The code currently doesn't decide on the right breaks on the non-last columns. Luca suggested a possible approach: