--- Comment #25 from Andreas L. Delmelle <>  2009-06-12 
08:02:52 PST ---

Some more progress: the undesired behavior is also eliminated in case all of
the columns of the first page are occupied.
Trying to explain this a bit better, if you look at the sample result with 3
columns, the behavior is triggered because the block with id 'block-1' occupies
only 1 column and a part. If we make it 2 columns plus some more, the following
block is correctly moved to the next page, where it overflows the first column.
In the current state, the column-break nodes will be deactivated, but priority
will be given to the first page-break, which is the one that is remembered as
the restart point. Strictly speaking not incorrect, but
PBA.recoverFromTooLong() creates a node that turns an illegal break (in between
two boxes, always to be kept together due to widows/orphans) into a feasible
one. Then it appends a few more for the column-break nodes. Commenting out the
specialized recoverFromTooLong(), it works neatly for the first case, but still
produces incorrect results for the third case (integer keep.within-column with
nested forced keep.within-page).

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

Reply via email to