https://issues.apache.org/bugzilla/show_bug.cgi?id=46905
--- Comment #4 from Andreas L. Delmelle <adelme...@apache.org> 2009-04-16 15:55:11 PST --- (In reply to comment #0) > * keeps have been implemented such that a keep.within-line implies a > keep.within-column, which implies a keep.within-page. This is almost always > true except if, for example, keep.within-page is set to always and > keep.within-column to an integer value. The integer value from the column > component will override the always value from the page component, possibly > leading to an 'illegal' page break. Are you referring to case block_keep-with-next_integers_1 here? If so, the most straightforward solution seems to be a change in the implementation of Keep.compare(). First check whether either keep is forced before doing the rest. In the patch, BlockStackingLM.getKeepTogether() will return the parent's keep-together if it has a lower priority. That is definitely incorrect if the child's keep is forced. Roughly: /* check forced keep first, regardless of priority */ if (strength == STRENGTH_ALWAYS) { return this; } else if (other.strength == STRENGTH_ALWAYS) { return other; } int pThis = getKeepContextPriority(this.context); int pOther = getKeepContextPriority(other.context); /* equal priority: strongest wins */ if (pThis == pOther) { return (strength >= other.strength) ? this : other; } /* different priority: lowest priority wins * (line wins over column wins over page) */ return (pThis < pOther) ? this : other; would make only 6 failing tests here (provided the two fixed by the uncommenting weren't a fluke) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.