On Jan 3, 2007, at 10:17, Vincent Hennebert wrote:
Hi Vincent,
<snip />
<fo:table>
<fo:table-body>
<fo:table-cell width="2in" number-columns-spanned="2">
...
In this case, two implicit columns are created, but the cell's width
is not yet distributed over the two columns.
I'll add a testcase demonstrating what still goes wrong, but the
issue
probably needs to put in a slightly different wording, indicating
that
it works apart from the above reservation.
I'm curious about your testcase, actually, because after quick
testing I
haven't been able to reproduce it (attached fo file, first table,
works
fine).
I see two possibilities:
Either the layoutengine fully compensates for this, or it just
happens to go unnoticed since you have a specified absolute width of
7.5cm for the whole table.
I think I'll put my money on the latter.
Explanation:
By the time layout starts, we'll actually have three table-columns,
all with a default width of 'proportional-column-width(1)' (= FOP's
proprietary default, as this is not mandated by the XSL-FO Rec; the
Rec says the initial value is 'auto' which comes down to the same
thing).
Try setting the table's width to 10cm. If all would go as expected,
we'd have to end up with two columns of 2.5cm and one of 5cm. FOP
currently makes them all about 3.33cm, I think...
In the meantime, I've locally patched FOP to correctly deal with
this.
Patch consists of a few changes in TableBody, TableRow and
PercentLength. The latter only because I needed to have some way
to be
able to get the percentage value of the cell-width, divide it by the
number of columns spanned, and construct a new PercentLength with the
percentage distributed over the number of columns.
Full patch below.
No objection, some code was obviously lacking at that place, anyway
(nothing done when colspan != 1).
For absolute widths, it is not so much of a hassle to distribute the
widths. When it came to the percentages, however, I began to slow
down... It seems a pesky job to create correct relative-numerics: the
percentages themselves are actually rather simple --percentage value
of the original cell divided by the column-span. It's creating the
LengthBase to go with it that I'm still struggling with (a percentage
of what?)
Not unsolvable, but a bit more work than that tiny patch I proposed
at first.
That made me think of the testcase showed in the second table in the
attached file. There is a colspan on the first row, which sets the
width
of the first two columns. But we might want to refine that on the
second
row, by specifying a different width for each column individually.
That
testcase fails...
WDYT?
Interesting idea, BUT...
One of the key intentions of the fixed table-layout algorithm is
precisely that a formatter is able to determine the column-widths for
the whole table based on the first row.
Strictly speaking, the behaviour you describe --to take into account
the second row as well-- would even violate the rules prescribed by CSS.
In 17.5.2, it says:
"In the fixed table layout algorithm, the width of each column is
determined as follows:
1) A column element with a value other than 'auto' for the 'width'
property sets the width for that column.
2) Otherwise, a cell in the first row with a value other than 'auto'
for the 'width' property sets the width for that column. If the cell
spans more than one column, the width is divided over the columns.
3) Any remaining columns equally divide the remaining horizontal
table space (minus borders or cell spacing)."
In your example, I'd say that following the Rec means ignoring any
width attributes on cells that are not in the first row. The widths
in the second row are not supposed to have any effect.
Cheers,
Andreas
