Georg Datterl wrote:
This is normal and due to the 'orphans' and 'widows' properties...
Errr... no, this is not normal at all actually. There's enough space to put the
last two lines of the 'L' paragraph on the first column.
And, speaking about that, the 'orphans' property on the 'U' paragraph is at its default value of 2, so there shouldn't be just one line of that
paragraph at the bottom of page 3.
AbstractBreaker.doLayout() creates a blockList for the fo:block. This list contains (I guess) a KnuthBlockBox for each line and a KnuthPenalty for each possible break. This list is correct, there are two boxes before the first break and two boxes after the last break, as required by orphan and widow parameter. Obviously the break after the first line is introduced later, I guess somewhere down doPhase3(). I had a look, but I didn't find the offending break, probably because I don't know what it would look like. There are lots of addAreas and Positions, LayoutManagers and Markers.
I had a short debugging session and the problem has to do with the fact
that a forced breaking point has to be chosen because there is not
enough space on the page to make the first two lines of the spanning
block fit. Normally this mechanism should defer the content to the next
page but for some reason this doesn’t happen. Apparently the bug doesn’t
appear when column balancing operates and the same conditions are
re-created (space available for only one line at the bottom of the
page). Sorry, at this point I would need to dive further into the code
but I don’t have the time ATM. You can create a bug report attaching
a sample file showing the issue, so that it’s kept in track.
Where could this break possibly get inserted and what would it look like in a