xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Re: Open issue: table-columns from first row?
Date Wed, 03 Jan 2007 19:52:43 GMT
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

Mime
View raw message