https://issues.apache.org/bugzilla/show_bug.cgi?id=46486
--- Comment #10 from Andreas L. Delmelle <[email protected]> 2009-04-14 16:23:59 PST --- Some more notes... Seems I'm unfortunately going to have to put this aside for the moment. It seems like I either sorely underestimated the complexity of the issue, or I'm overlooking something very obvious. Even the closest attempt yet, still breaks some 50 other tests. Up to now, my changes are localized to AbstractBreaker and PageBreaker. The basic idea is to somehow recreate the exact sequence of events that would be generated when the FlowLM returns due to a span change. By this, I'm attempting to make use of the fact that AbstractBreaker already has a blockLists member that can hold multiple elements over which the for-loop in doLayout() will iterate. Currently, the blockLists member is cleared with every iteration, so in practice *always* contains one element. By itself, it is rather easy to have PageBreaker's doPhase3(), under certain conditions, defer the sub-list corresponding to the part after the last break until the next iteration in doLayout(). The hard part --still have not figured that out yet-- is how to get the span changes across. The doPhase3() method has been merged to allow (theoretically) to do a restart with column-balancing for a part on the last page. BlockSequence has been equipped with an extra span member, so the span of the original list is not lost. The main loop in doLayout() has been refactored to do special processing of the block lists that are remnants of a previous iteration. Still, not enough... maybe I'm completely misunderstanding the mechanism behind span changes here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
