Hi Vincent,
> Entering the details would be too complicated, but the problem is basically
> due to the repeated header of the inner table at page breaks.
Well, if I don't have a blank block in the left column, everything works fine.
I guess, I could reduce the height of the blank block by the height of the
table header, which I could get by adding an id attribute to the table-header
entry. Then my problem would be, what if the image is smaller than the table
header? In that case, the image would move from page 3 to page 2, I assume. A
break-after at the blank block would lead to same problems I had before.
Would it theoretically help, if I get the table header height, subtract it from
the blank block height and add it as space-before to the image?
It would be easier than finding the number of rows in the table and splitting
the table in two, although that should be possible too, somehow.
> 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 the end of the block is interesting too? I thought, only the beginning. So
here
<block>
<marker1 />
<block>
<marker2 />
</block>
</block>
<retrieve-marker last>
would find marker1?
Mit freundlichen Grüßen
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Vincent Hennebert [mailto:[email protected]]
Gesendet: Mittwoch, 19. August 2009 18:55
An: [email protected]
Betreff: Re: Strange table behaviour
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
