https://issues.apache.org/bugzilla/show_bug.cgi?id=46905





--- Comment #8 from Andreas L. Delmelle <adelme...@apache.org>  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.

Reply via email to