https://issues.apache.org/bugzilla/show_bug.cgi?id=51304
--- Comment #5 from Andreas L. Delmelle <adelme...@apache.org> 2011-07-05 19:03:29 UTC --- Update: there was still something lacking in the overall picture as sketched in the previous comment. The additional step should actually take the form of a *forced* restart, at the point of the next unavoidable page-break. The reason I misread it is that, at first, I overlooked that the algorithm behaves slightly differently if the available width is such that each break fits exactly (e.g. 72pt available, and all lines are 12pt --assuming no stretch/shrink). As soon as the width is increased or decreased (say to 73, resp. 71pt), there is a restart on every unavoidable page/column-break. When a line is reached that would generate overflow, there is a break-plus-restart from the position after the last line that still fits. In such a scenario, it is conceivable to alter the mode of the restart, so it jumps back to the last page-break, and retries the complete page, with a different set of parameters. If every unavoidable break is 'perfect', however, a restart is never triggered, and thus it would have to be forced somehow. Given that the cycle is just node-activation and -deactivation, it likely means overriding deactivateNode() in PageBreakingAlgorithm. Around every unavoidable break, there is a brief moment at which there are two active nodes, which then gets reduced to one, so the outer loop in findBreakingPoints() just continues with the next element. At the point where a page-break node is being deactivated, there can be a rather simple check, going back to the first column-break and comparing that node's totalFootnotes with the footnotes for the node that is about to be deactivated. If they are not equal, it means footnotes were added after the first column. The next node should then be deactivated as well, so that we end up with 0 active nodes, and a restart is forced higher up. Provided that we then also properly set the lastTooShort and/or lastDeactivated node(s), the rest of the solution as sketched earlier should suffice to handle the rest. I am even thinking that we can already infer at that point whether the last box with anchors --for the last (set of) footnote(s)-- can still fit with all footnote content, or whether part of the last footnote needs to be deferred. Updated patch likely to follow soon. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.