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(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--