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

Hi Ken

Thanks for the reply.

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.

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?

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)?

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.

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.

David

On 3/7/14 10:44 AM, G. Ken Holman wrote:
> I think the issue is obvious in your XSL-FO:
>
> <fo:table-cell ....>
> <fo:block keep-together.within-column="always">
> <fo:block space-before.optimum="1em"
> space-before.minimum="0.8em" space-before.maximum="1.2em"
> >A character string encoded using a 5 component
> convention. The character code 5CH (the BACKSLASH "\" in
>
> Since there is no room in the column for the set of blocks the entire
> content is moved to the next area, per the specification.
>
> As with all other keeps, if there is no room in the next area, the keep
> is broken but there is no backtracking to the original print position.
>
> So it is my opinion that what you are seeing is what the standard says
> you should be getting.
>
> I hope this helps.
>
> . . . . . . . Ken
>
> At 2014-03-07 06:40 -0500, David Clunie wrote:
>> Any thoughts on this?
>>
>> David
>>
>> On 2/27/14 10:17 AM, David Clunie wrote:
>>> Hi guys
>>>
>>> I have a particularly long cell in a multi-column table that spans
>>> pages, with cells in adjacent columns that are not so long
>>>
>>> When it is rendered by XEP, the first line of the very long cell
>>> does not get rendered until the second page, which is very ugly.
>>>
>>> See the attached example (DocBook, stylesheet, FO and PDF).
>>>
>>> David
>
>
> --
> 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,531a043c9859036710427!

_______________________________________________
(*) 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
Received on Fri Mar 7 09:39:12 2014