[xep-support] Re: Strange break of long table cell across multiple pages

At 2014-03-07 12:36 -0500, David Clunie wrote:
>I did try 'keep-together="always"' on the enclosing row instead
>of 'keep-together.within-column' on the block, but that did nothing
>with XEP, and if I add 'keep-together="always"' on the cell
>it has the same effect as I reported.
>
>With AH, I found that 'keep-together="always"' did force everything
>onto the one page, but then made the table too wide to fit on the
>page, whereas keep-together.within-column="always" on the cell
>forced it on to the same page but it ran off the bottom edge.

Did you try keep-together.within-column= on the table row? If you
simply use keep-together= then you are simultaneously also setting
keep-together.within-line= which makes lines too long.

>I guess this is a problem with the "keep-together" concept, when a
>cell happens to be too large to fit on a page, though I thought that
>the numeric keep "strength" was supposed to assist with this?

Nope ... numeric strength comes into play when there are nested keeps.

There is helpful information and a useful diagram on page 325 of my
XSL-FO book that is available for free download on a "try and buy"
basis at http://www.CraneSoftwrights.com/training/#pfux ... if you
decide not to pay for the book, please delete the copy that you
download for free.

>What advice do you have for this sort of situation (other than
>to make the contents of the offending cell smaller or treat it
>specially)?

Try again on the row without using keep-together= but with
keep-together.within-column=.

If that doesn't work, then I would weigh the ugliness of what you
have with the ugliness of no keeps.

>It would be nice if there was enough look ahead to decide that if
>"there is no room in the column for the set of blocks AND there is
>no room in the column for the set of blocks ON THE NEXT PAGE EITHER"
>that it would treat it as if keep-together.within-column was not
>set.

You could suggest that the W3C PPL group:

   http://www.w3.org/community/ppl/

>I assume there must be some special case handling when it doesn't
>fit on the next page either anyway, otherwise it would keep on
>infinitely pushing it to a next page.

Indeed there is ... just that the keep that forced the movement to
the next page "breaks" and any nested keeps of the given strength (or
lower) are then ignored. A nested keep of a higher strength than
what just broke remains intact. And the process recursively works
its way through all of the nested keeps. I've depicted this in my book.

I hope this helps.

. . . . . . . . Ken

--
Public XSLT, XSL-FO, UBL & code list classes: Melbourne, AU May 2014 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/f/ |
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com |
Google+ profile:      http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
!DSPAM:87,531a15249851269718496!
_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html