https://issues.apache.org/bugzilla/show_bug.cgi?id=46905
--- Comment #8 from Andreas L. Delmelle <[email protected]> 2009-05-03 14:45:03 PST --- (In reply to comment #7) > (Sorry for the delay.) (Me too ;-)) > > 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 > recoverFromTooLong. So.. the implementation, without comments, uses the last deactivated node as lastTooLong, but since the (Page)BreakingAlgorithm is actually not breaking pages but columns, this turns out to be the last deactivated column-break node, instead of a page-break node. Maybe it's a matter of checking the node, before deactivating. IOW: never deactivate column-breaks, so the algorithm always restarts from the last page-break (?) Then again, this could get messy, given that changes in BreakingAlgorithm also influence line-breaking, where the distinction is irrelevant. The cleanest solution is probably to override compareNodes() in PageBreakingAlgorithm, so it always returns the last true page-break, rather than the last (plain) break. The default implementation in BreakingAlgorithm simply returns the break with the last position (or the one yielding the best demerits in case of equal position). If overridden, the later break can then be deactivated, but not stored as lastDeactivatedNode. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
