Keeps and breaks

1. keep-together
2. keep strength with larger than a page content



Ken Holman

>I have got an XSL:FO problem with tables.
><xsl:template match="tr">
>    <fo:table-row keep-together.within-page="always">

Note that "always" does not mean "a very big number for keep strength".

>      <xsl:apply-templates/>
>    </fo:table-row>
>And now to my problem - when a table row is to big for one page, i get an 
>area overflow!
>How can i solve this???

By using a number for keep strength and not the value "always". A numbered value for keep strength will break if there is no room for the construct, and it will be flowed after the previous construct as if the keep was not specified.

Note that in XSL-FO 1.0 there is no way to have an item that is too long for a page begin at the top of a page ... once the numeric value breaks, it is flowed as if there were no keep ... but "always" means just that "always" even if it doesn't fit, so if it doesn't fit, it must be an overflow.


keep strength with larger than a page content

G. Ken Holman

>How do people usually handle cases where table rows or list items 
>contain more content that what will fit into a single page, but still 
>want to keep the content together in smaller rows and list items? Do 
>you try to "artificially" create break-points by chopping the content 
>into blocks that will most probably fit into a single page?

I hope I've understood your question, because I believe XSL-FO supplies the answer.

The idea of "keep strength" allows you to wrap smaller portions of your flow with higher strengths. As blocks of content with low strength values break because they don't fit on a page, smaller blocks with higher values of strength are the next "breaking points" for blocks of flow.

You could nest a flow with a keep-together="1" with consecutive flows of keep-together="2" where you will allow breaks only if necessary, and then break up any flow with keep-together="2" with consecutive flows of keep-together="3" where you will allow breaks in those only if necessary, and so on.

The catch is that I don't think any of the engines implement numeric values of keep strength and they only support "always" ... which has a different semantic than "a very big number". If you use "always" and it doesn't fit, then it is considered a runtime overflow error.