W3C home > Mailing lists > Public > www-xsl-fo@w3.org > July 2010

Page-Break and keep-together.within-page

From: Michael Seeberger <Michael.Seeberger@isys-software.de>
Date: Wed, 30 Jun 2010 14:12:31 +0200
Message-ID: <4C2B34AF.5090007@isys-software.de>
To: www-xsl-fo@w3.org
Hi there,

i'm using Apache-Fop Version 0.95 and i'm having problems to get my 
report created the way i want it to.
The problem lies in the behaviour of Apache-FOP and the 

The report i want to create consists of several fo:block-Elements in 
which i use fo:table-elements to layout the report and
the behaviour of Apache-FOP as i want it to be should be something like 
     Condition 1. if a fo:block fits completely on a page then it should 
stay there.
     Condition 2. if a fo:block won't fit completely on a page then 
Apache-FOP should insert a page-break and print it on the next page (i 
implemented this by using keep-together.within-page="always" and it works).
     Condition 3. if a fo:block is to large for a single page Apache-FOP 
should insert a page-break where necessary (won't work if condition 2 is 

But until now i've not been able to get Apache-FOP working this way 
because FOP seems to have a problem with the combination of condition 1 
and condition 2. When a fo:block won't fit on a page FOP inserts a 
when using keep-together but if this fo:block is to large for a single 
page it won't insert another page-break where necessary but overflows 
the page.

The Reason for this seems to be the attribute-value "always", as my 
Google-research tells me "always" means that when using this value an 
fo:xxx-Element stays together no matter what even when this leads to an 
I've also tried using keep-together.with-next or 
keep-together.with-previous but it didn't work either and using 
integer-values instead of always isn't supported by Apache-FOP 0.95 as 
far as i know.

And heres my Question: Is there really no way to make Apache-FOP create 
the report the way i want it to?

thx in advance
Michael Seeberger
Received on Friday, 2 July 2010 09:12:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:33 UTC