Hi Vincent,
Sometimes it seemd like a space-after property was ignored in the table
(because it was at the start of the page) but not ignored in the calculation of
the table height. But I am not sure, since other changes changed the behaviour
as well.
The outer table is a simple table with three columns used to align the inner
table.
<fo:table-column
column-number="1"
column-width="proportional-column-width("+(horizontalAlignment==ALIGN_RIGHT
||horizontalAlignment==ALIGN_CENTER?1:0)+") />
<fo:table-column
column-number="2"
column-width="+(percent||contentWidth<0?"99%":(format(contentWidth)+"pt"))+" />
<fo:table-column
column-number="3"
column-width="proportional-column-width("+(horizontalAlignment==ALIGN_LEFT||horizontalAlignment==ALIGN_CENTER?0:1)+")
/>
If there's a better way, I might get rid of the table.
Regards,
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: Dienstag, 11. August 2009 13:30
An: [email protected]
Betreff: Re: Strange table behaviour
Hi Georg,
Georg Datterl wrote:
> Hi everybody, it's me again and as usual, I have a fascinating little fo file
> for you.
Fascinating... Indeed...
> Todays topic: creating blank space without padding-* or space-*, whether you
> want it or not.
> In my fo file, I have an outer table with one cell and a bottom border.
> Inside I have a middle table with three rows and two columns.
> Row one, cell one contains a simple block.
> Row one, cell two spans all three rows and contains blocks and a table. This
> cell contains most of the data and should define the height of the outer
> table.
> Row two, cell one contains a block with fixed height and a block with
> break-before=page. This makes the block move to the next page and break the
> table in row one, cell two at the height of the fixed-height block.
> Row three, cell one contains a block which should sit at the foot height of
> the table in row one, cell two, just above the bottom line of the outer
> table.
>
> Now, if it worked, I wouldn't write this. Funny thing is: Everything looks as
> expected, only the bottom line of the outer table is way below the bottom
> line of the inner table. And I don't see a reason. Maybe somebody else wants
> to play around with it and tell me why there's a gap.
I'm not going to enter the details, but there seems to be a flaw in the
algorithm that deals with tables. There are many weird situations that can
occur with tables, and the algorithm tries to account for all of them, and it
basically fails at that. Basic cases are simple, but when you introduce forced
breaks, fixed row heights, row-spanning cells, etc., you quickly reach the
limits of the approach.
I attached to this message a version of your FO file that I simplified in order
to ease debugging. The following computations have been made based on that file.
Basically, at the page break, the algorithm believes that there is more of the
second column to lay out on the second page than is actually the case.
If there were no forced break, the whole table would fit on a single page, and
the rows would resp. have the following heights: 10pt, 86pt, 90pt.
But there is a forced break. But the second column can't be broken before the
first cell of the inner table. So all that content (112.5pt) must be put on the
first page. Which makes the first row have a height of 10pt, and the second row
a height of 102.5pt on the first page, and 10pt on the second page. There are
73.5pt of content from the second column to be put on the second page, so the
third row will grow accordingly to 73.5pt minus the height of the second row,
so 63.5pt...
But the algorithm will still make it 90pt high. Hence the additional white
space at the bottom of the table cell.
If you remove the surrounding table the problem disappears, but I guess you
have a good reason for it being there. I have no other workaround in mind at
the moment, but I'll try to think about that.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
