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 ). 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 ... :-)