Andreas L. Delmelle <> changed:

           What    |Removed                     |Added
  Attachment #26800|0                           |1
        is obsolete|                            |

--- Comment #8 from Andreas L. Delmelle <> 2011-03-31 
14:23:09 EDT ---
Created an attachment (id=26820)
 --> (
new patch, handling widows/orphans at block-level

The new patch should result in a correct rendering of the test. 20 pages
demonstrating some possibilities of widows/orphans.
One scenario I still need to look into is the case of tables/list nested in
blocks. All seems to work pretty well when they are direct flow descendants,
but I somehow still expect trouble...
All unit tests pass, nevertheless.

Trying to fix this, I was tempted to try and reuse the existing code in
ElementListUtils.removeLegalBreaks(), that is used for fox:orphan-content-limit
and fox:widow-content-limit, but got to wondering... Why not at the same time
try to improve/optimize a little bit? For now, I added similar code inside
BlockLayoutManager, using a slightly different approach. The duplication I am
still going to address, but it might go a bit further than that. 
We should be able to share code more efficiently by:
- using a plain removeLegalBreaks() method, period. No fromEnd/fromStart, or
differentiation between content-limit in length or lines. That should be
determined by the caller.
- use one pre-process iteration to determine the limit, then just hand off the
corresponding sub-list to the above method. No need to juggle with
next/previous = less confusion.

Also, the following additions are made in comparison to the existing variant in
In the existing method, If we encounter a penalty (or BreakElement), we set it
to infinite to avoid a break. If I interpret correctly, and the element appears
in between two boxes, the more appropriate response would be to just remove it
(or if possible, as it happens currently in LineLM: do not add it in the first
place). This would make the eventual element lists simpler for the
BreakingAlgorithm. By design, a box is never a legal break, so adding an
infinite penalty in between two boxes is plain redundancy, and is bound to
confuse the algorithm in some scenarios.

In dealing with glues, I noticed the following two sequences:

box - box[aux., w=x] - box
box - penalty[inf, w=0] - glue[w=x] - box

Again, an opportunity for optimization here. The above two are equivalent in
case the glue is not stretchable, and if I interpret correctly, there currently
is no case where --during raw element list generation, i.e. /before/
space-resolution-- stretchable glues are used in block-level layout. Less
elements means less positions, means less computations...

Having chosen the above approach to remove the legal breaks, I did manage to
upset quite a few test cases. I have already included them in the patch.
In the end for some, I chose the 'lazy' fix, which means "set widows and
orphans to 1" to allow breaking before the last line or after the first. Just a
convenient way to trigger the same behavior as before. Others I have adapted to
the correct behavior, like region-body_column-count_bug37828. Interesting case,
that one, since it shows that the change upsets the balance, but I believe it
is entirely correct to do that. No column-break allowed, so we get an empty
second column.

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

Reply via email to