Interpretation of relative keep strength

Good morning!

Please find below a post that I made to the XSL list this morning.

Attached is my test file showing that I think relative keep strength is not 
being implemented properly by a number of processors (I have only tested 
three, but no two of them do the same thing and none of them do what I 
think they should do).

I look forward to any comment you have on my interpretations of relative 
keep strength and of "always", as this is what I'm teaching my students 
about XSL-FO.

I have a test XSL-FO instance and an illustration from my book in the 
attached ZIP file.  I have a number of blocks, with nested keeps on various 
sets of blocks.  My interpretation hinges on the last paragraph of 4.8 
Keeps and Breaks.  The key phrase is "maximal satisfiable subset of 
conditions of that strength must be satisfied".

BTW, my diagram shows a page-level context but to be succinct my test is 
using a column-level context.

(1) Please look at the blocks labeled "B" and "C" ... there is enough room 
to fit the five blocks of "C" in a context, but in my diagram I show the 
first three blocks of "B" being kept together and fitting under "A" on the 
page.  This is because that is the maximal subset of "B" of strength 2 
being kept together before the blocks in "E" at higher strength 3 are being 
kept together.

I feel it would be incorrect to keep the "C" blocks together because even 
though the "C" blocks fit together in the context, they have a lesser keep 
strength of "1" than the "B" blocks and strength "2" has already been broken.

The maximal subset of "B" would be, I believe, "B1, C1 and C2", all of 
which fit in the same context as "A" without changing context, so the page 
doesn't break until "B4" which is also "E1".  The "B" maximal subset is 
more important to keep together than the "C" maximal subset, and that which 
is kept together fits in the first context.

(2) On the next page, please look at the blocks labelled "Y".  The set of 
blocks is longer than the context but the keep strength is "always".  Some 
processors break this and flow the blocks with a maximal subset in the next 
available context and remaining subsets in subsequent pages.

One implementation enforces "always" by flowing beyond the context (in this 
test file beyond the limit of the region-body) and respects the overflow= 
condition on the region-body as to whether or not this overflow is hidden 
or visible.  As a result,

I think I prefer that one implementation to the others, but I don't know if 
that is an acceptable interpretation according to the specification.

Could you please comment on the two interpretations above?

Thanks for any help you can be!

. . . . . . . . . . Ken

>Date: Sun, 12 Jun 2005 09:15:05 -0400
>To: xsl-list@lists.mulberrytech.com
>From: "G. Ken Holman" <gkholman@cranesoftwrights.com>
>Subject: Re: [xsl] XSL FO keep-together=int Implementation?
>
>Consider layout rules that might be associated with information presenting 
>tasks, steps and cautions and warnings.  You may wish to have a task 
>presented entirely on a page so that the person undertaking a repair can 
>just take one page out of a manual and take it with them to go and do the 
>repair.  So, you need a keep-strength on the list so that it stays 
>together on a given page.
>
>But, some tasks are longer than a page and cannot be kept together, so it 
>is okay to sacrifice the keep for the list if the information will not 
>fit.  So then you want to keep steps together so that at least steps would 
>fit on a single page.  But, some steps are longer than a page and cannot 
>be kept together.
>
>Then again, in the middle of your task might be some cautions or warnings, 
>and for safety reasons you need to keep the caution or warning together, 
>even if the list keep breaks or the step keep breaks.
>
>For this reason you cannot just have a binary "keep or don't keep" 
>flag.  You need varying strengths of keeps ... a given strength that keeps 
>the list together, a higher strength that keeps the step together, and a 
>yet-higher strength that keeps the cautions and warnings together even 
>when the lower list or step strength has to break.  The spec says that if 
>any keep of a given strength has to break then all nested keeps of lesser 
>strength are considered broken and don't have to keep together.  Any 
>nested keeps of higher strength are still attempted to be respected by 
>attempting to keep together.
>
>XSL-FO has "auto" (no keeps), strength (integer numbers), and "always" 
>(which empirically appears to be more than just "a big number", though is 
>documented only to be bigger than any number).
>
>I document what I say above in my book, but with my tests I have yet to 
>find any processor that implements differing strengths of keep.  But I 
>have come across differing interpretations of "always".
>
>Most implementations just break "always" and the amount that doesn't fit 
>in the first context just flows to the next context.
>
>One implementation will never break "always" and will move as much of the 
>information into the next available context and then overflow the context 
>with the information that doesn't fit ... that gives me the control to 
>either allow the overflow to go beyond the context boundary (default) or I 
>can set overflow="hidden" on the context and have the information cut 
>off.  As if to say "I always want this kept together and it will *never* 
>break even if it doesn't fit in the context, it will just overflow the 
>context and then I can control what happens with the overflow".  If I 
>don't want that behaviour, then I just don't use "always" and I would use 
>a very large number.
>
>I don't know which interpretation of "always" is correct, but I think I 
>like the more elaborate second one since that matches the English meaning 
>of "always" as in "don't ever break".  This is what I've documented in my 
>book.  Unfortunately, according to my tests that processor doesn't appear 
>to support relative keep strength.
>
>I've been anxious to find implementations of relative keep strength in 
>order to improve the presentation of the annexes of my XSL-FO book, but I 
>haven't seen any yet.  I would have liked to help Alex by citing an 
>implementation, but I didn't have anything to contribute to his question.
>
>I hope this helps.
>
>. . . . . . . . . Ken
>
>At 2005-06-12 10:22 +0200, J.Pietschmann wrote:
>>Alex Milowski wrote:
>>>I really want to be able to specify an integer value so that long program
>>>listings can get broken across a page but short ones will cause a page
>>>break.
>>
>>Wow! Would you mind sharing your idea how to achieve this with keep
>>precedence levels? I could use this.
>>
>>J.Pietschmann

--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/m/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/m/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal