Thanks, Luca. Looks like my intuition was right. I'll have a look at it shortly.
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
