https://issues.apache.org/bugzilla/show_bug.cgi?id=44328
Andreas L. Delmelle <adelme...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #26800|0 |1
is obsolete| |
--- Comment #8 from Andreas L. Delmelle <adelme...@apache.org> 2011-03-31
14:23:09 EDT ---
Created an attachment (id=26820)
--> (https://issues.apache.org/bugzilla/attachment.cgi?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.
Notes:
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
ElementListUtils:
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: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
