--- Comment #6 from Vincent Hennebert <>  2009-05-07 
02:38:41 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > The bug is this second penalty that shouldn't be generated in the first 
> > place,
> > since breaks win over keeps. There may be an opportunity to fix that in the
> > same time as bug #46905.
> Agreed. As I remember from another similar issue I fixed recently in
> FlowLayoutManager, it could turn out to be a very straightforward fix. I'll 
> see
> if I can confirm later tonight.
> At some point in getNextKnuthElements(), the parentLM adds a break in between
> the sequences returned by two consecutive childLMs. It's likely to be a simple
> matter of :
> if (!ElementListUtils.endsWithForcedBreak(returnedList)) {
>   //add in-between break
> }

I think a LayoutManager shouldn't generate a Penalty element for a
break-before/after. That's the job of the enclosing LayoutManager, when its
addInBetweenBreak method is called. It's there that all the information about
break-after on the current childLM, break-before on the next childLM,
keep-with-next/with-previous/together can be collected, and a proper Penalty
element can (optionally) be generated. I say optionally because no element
needs be generated at all if a break-after is set on the last block of a
page-sequence, for example.
That's what I did in tables (see TableContentLM.getKnuthElementsForRowIterator)
and it works pretty well.


Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to