While I was investigating this earlier I modified AbstractBreaker to set the "force" parameter to "false" on the findBreakingPoints() call. I found out now that this had the interesting side-effect that footnotes7.xml produces the same footnotes on both page 1 and page 2. It seems that the footnote handling relies on the force parameter to be set to "true". Don't know if this means anything. I simply thought I'd share this. I reverted that change on my working copy.
On 22.06.2005 14:42:42 Luca Furini wrote: > Jeremias Maerki wrote: > > > Before I waste a lot of time trying to figure out how I should fix that, > > I thought I'd just drop in a test case. Luca, for you it's probably very > > easy to say at which point I should hook in to create pages with empty > > content so the non-fitting content is simply pushed to the next page. In > > the end, that "pushing-loop" need an upper limit (like 50 iterations or > > so) after which it throws a layout exception complaining about too > > little room to place content (This check used to be in FlowLM [1]). I'm > > somewhat stuck in PageBreakingAlgorithm.removeNode(). Intuitively, I'd > > say I'd have to create a new KnuthNode that somehow results in an empty > > page or something like that. > > At the moment, the test fails because the algorithm stops and restarts > from lastTooLong (a page break involving content overflow), so I think > that the right point could be BreakingAlgorithm.findBreakingPoints() > at line #368. > > Instead of using lastTooLong, a node representing an empty page should be > created and lastForced should be made equal to that new node. > > I did not try if this works, but here is my idea to do that: > > - lastTooLong would create a page whose content overflows, so the last > "good" break poing is lastTooLong.previous > - create a new node whose .position is lastTooLong.previous.position, > .line is lastTooLong.previous.line + 1, .previous is > lastTooLong.previous (the other values could be 0, I think) > - this could be the node representing an empty page, from which the > algorithm can restart > > > BTW, Luca, I haven't forgotten your post about keep-with-previous in > > tables. Thank you for that one. ATM I'm swimming in another lake trying > > to remain on top. :-) > > I know that kind of situation ... :-) > > Regards > Luca > Jeremias Maerki