Hi Georg, Georg Datterl wrote: > Hi Vincent, > > I tried your suggestion and it works nearly perfectly. Maybe you can take > another look at the resulting fo and answer me two questions: > > * Why is the table breaking incorrectly on the second page? The table is > painting into the footer area (which starts at the red marker), but judging > from the gap on page three, it seems like the break was correct when > generating the area tree, so the addition of the pink blank block seems to > influence the break rules. Reducing the height of the blank block does > influence the break, but i have to reduce the blank block by around 100pt to > get a correct break in the table.
You are hitting FOP’s fundamental limitation about tables. The table algorithm works well only when the table is broken over maximum two pages. Beyond that there can be glitches as the one you see on your document. You may want to have a look at the following page for an illustration of the process (although it’s targeted at developers): http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnownProblems Entering the details would be too complicated, but the problem is basically due to the repeated header of the inner table at page breaks. The algorithm doesn’t realise that space must be accounted for it on the second page. See it like this: the algorithm assumes that the table will be broken at most twice, so the header will appear at most twice. But actually the table is broken 3 times, so the header must appear 3 times... which is not handled. This is a simplified view but roughly corresponds to what happens. One workaround could be to split the table into several sub-tables that would fit on two pages. Since you’re working with the area tree, you could detect that the table is split in 3, and put the 3rt part into a new table. Not sure how feasible that would be though :-\ > * I want a "table continues on next page" marker for the whole image/table > construct. So I set a (for this example) red marker at the beginning of the > text block (second column, the magenta colored ones) and a green marker at > the beginning of the PF-number block (first column, red blocks), because I > always have text and the PF-Number always has to be on the last page. I'm > quite sure I should get a red marker on the first page, because I have a > magenta block after a red block, obviously I get a red marker on the second > page, although there's neither a magenta nor a red block, but I'm positive I > don't like the red block on the last page. I guess I can solve that problem > by placing the marker differently, but I'd like to understand what happens > here. You put the red marker as a child of the block that surrounds the whole content of the spanning cell, and the green marker inside the cell on row 3, column 1. Both end at roughly the same moment when the end of the surrounding table is reached. They are ‘competing’ when the marker is retrieved and it appears that the red one wins. If you put the green marker in an empty block after the big surrounding block that contains the red one, that should work. > So, if you are not too busy, I'd be gratefull for some more input. > > Regards, > > Georg Datterl <snip/> HTH, Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
