Re: [xsl] XSL FO keep-together=int Implementation?

Subject: Re: [xsl] XSL FO keep-together=int Implementation?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 12 Jun 2005 09:15:05 -0400
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

Wow! Would you mind sharing your idea how to achieve this with keep precedence levels? I could use this.


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

Current Thread