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.

Reply via email to