Luca,

your pointers were 100% on target! It took a few other things around
that but the issue seems to be fixed now.

If you look at the code, you can see that this functionality could
theoretically also be useful for line-breaking. Especially when we have
side floats some day this could be very useful to avoid text to overflow
into the side-flow. Even today, there are some constellations where this
behaviour would make sense. But I think we'd need some additional code
to handle every situation properly. For the moment, I've disabled the
"part overflow recovery" (for lack of a better description) for line
breaking.

I've also disabled it for side region layout and block-containers since
we want the overflow in these areas. Parts n > 0 will just be dropped
anyway.

Thanks for your help.

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

Reply via email to