--- Comment #7 from Vincent Hennebert <>  2009-04-24 
08:43:40 PST ---
(In reply to comment #3)
> (In reply to comment #0)
> > * the deferring mechanism may also conflict with regular node recovery
> > (restarting from the last deactivated/too short/too long node when the 
> > number
> > of active nodes falls to zero). See commented out code in BreakingAlgorithm.
> > It's not clear yet what may happen when.
> Not sure if I interpret it entirely correctly, but the effects seemed to show
> in the (alphabetically) first failing testcase, where the algorithm chooses a
> layout with less lines, in spite of the fact that the last line is too long.
> So, I naively tried uncommenting that bit, and that brings the number of
> failures down to 7. Is that expected?

(Sorry for the delay.)

I had to comment that part because it was preventing the
PageBreakingAlgorithm.recoverFromTooLong method from properly working. Instead
of taking as lastTooLong the node that overflows the second column because of
page-unbreakable content, it would take the node that overflowed the first
column, and that was deactivated following the normal process of the algorithm.
That doesn't mean that the first column can't be laid out, just that starting
from that node no content could be squeezed into the first column any more.
That piece of code needs to be re-enabled and collaborate nicely with

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to