This may be related to bug 43616. However, 43616 has already been fixed (I am using rev-588275). The attached XSL-FO, converted to PDF, will have the last paragraph broken to the next page even though there still is plenty of space in the current page for the extra two lines:
Created attachment 21052 [details] XSL-FO that demonstrates the problem
Hi Isaac, thanks for reporting the problem. This is not related to bug 43616. I strongly suspect that this is due to the fact that collapsed borders are not considered to lie half in the before and after margin for tables which are inside another table. You can circumvent the problem by specifying border-collapse="separate" on the inner tables. You will have to rework your border specifications a bit, but you should still be able to achieve the layout you need. Please ask on fop-users if you need more explanations. Details: the merging algorithm seems to forget that the border-before/after on a table with collapsing borders lie half in the margin. Thus the total size of the merged sequence is bigger than expected, and overflows the page size. Whereas when adding the areas, borders are actually put half in the margins, so that on the visual results it looks like there is still room for the last 2 lines.
My bad, the problem was totally unrelated... border-collapse is an inheritable property, so if it is set to "separate" on an outer table it will also be set to "separate" on inner tables. I've checked and it works properly. The problem here was due to a bug that I fixed in revision 596727: the height of some elements was counted twice, once in a glue and once in a box. The attached sample looks fine now. Vincent
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed