keep-with-next="always" not honored on a group of table rows

[Olivier Lange <ol...@petit-atelier.ch>]

I would like to keep together on a same page a "group" of table rows. I used
keep-with-next="always" and all except the last fo:table-row elements of the
"group", but for the attached XFO document (a course schedule), a page-break
occurs in the middle of a group of 9 rows (16:15), between pages 2 and 3.
Obviously, the group of rows would hold within a single page, so why is this
page break occuring?

How should the keep-with-next property be specified on a fo:table-row?
I saw from previous postings that keep-with-next="always" was used; the
XLSFO REC 1.0 spec rather mentions keep-with-next.within-page="always". I
tried the two but it didn't work either.

I did read from J. Pietschmann
(http://marc.theaimsgroup.com/?l=fop-user&m=101950534709263&w=2) that the
keep-with-next property should work for table rows.

Is this true for FOP 0.20.3 or should I get the latest CVS version?

Or did I overlook something?

I joined the source XFO, as it is rather lengthy, and marked the group of
row which spans across pages 2 and 3 with the '[BEGIN]' and '[END]' text
markers. As there is a keep-with-next="always" on each row, but the last, I
would expect the group to be rendered on start of page 3. Please note that
there are external references to small SVG glyphs. I also joined the
resulting PDF document; the "offending" page break occurs within the group
of rows labeled "16:15", at end of page 2.

I tried with FOP 0.20.3, binary distribution, JDK 1.3.1_02 (win2K).

Any kind of advice would be greatly appreciated!

Kind regards
Olivier Lange

Some history:

For the same document, I first had trouble with this group of rows in a
table, were the first cell spanned across a group of 9 rows; the group of
rows with the spanned cell crosses the page boundary, but no page break
occurred. I found that there was already a bug #6997 "Row-spanned row data
breaks over a page within a column" filled in the Apache bug database, so I
added my source document as broken testcase; there is also the resulting
broken PDF document: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6997