Hi Andreas,
Andreas L Delmelle a écrit :
> On Oct 31, 2007, at 11:33, Vincent Hennebert wrote:
>
> Hi Vincent
>
>> Following an old thread:
>> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200703.mbox/[EMAIL
>> PROTECTED]
>>
>>
>> In my moving of TableRowIterator into the FO tree code I’ll implement
>> stronger checks for column numbers. I think there is consensus on this,
>> but as a reminder, and following the HTML 4.01 recommendation:
>> - if an fo:table has explicit fo:table-column children, those fix the
>> number of columns in the table, and an error will be thrown for any
>> row that has more columns;
>> - otherwise, the number of columns for the table will be set by the row
>> that has the greatest number of columns.
>
> Nope. For table-layout="fixed", the number of columns is in that case
> determined by the number of cells in the first row (see also CSS)
Sorry, but I don’t agree :-P
There is nothing in the CSS2 spec related to the calculation of the
number of columns in a table. However, there is the following excerpt in
section 11.2.4 of the HTML 4.01 specification: “
There are two ways to determine the number of columns in a table (in
order of precedence):
1. If the TABLE element contains any COLGROUP or COL elements, user
agents should calculate the number of columns by summing the
following:
* For each COL element, take the value of its span attribute (default
value 1).
* For each COLGROUP element containing at least one COL element,
ignore the span attribute for the COLGROUP element. For each COL
element, perform the calculation of step 1.
* For each empty COLGROUP element, take the value of its span
attribute (default value 1).
2. Otherwise, if the TABLE element contains no COLGROUP or COL elements,
user agents should base the number of columns on what is required by
the rows. The number of columns is equal to the number of columns
required by the row with the most columns, including cells that span
multiple columns. For any row that has fewer than this number of
columns, the end of that row should be padded with empty cells. The
"end" of a row depends on the table directionality.
It is an error if a table contains COLGROUP or COL elements and the two
calculations do not result in the same number of columns.
”
Which, translated into FO terms, should give the version I suggested
above.
Note that I’m not speaking of column widths here! For which, indeed,
widths specified on cells of the first row do count. As I was near to
make the confusion myself, I thought I’d just remind that 8-)
Agreed?
>> That should make most users happy: those who want speed (once some kind
>> of progressive layout is implemented, of course) will simply have to
>> specify explicit columns; those who want flexibility will have it.
>
> Convenience is one thing. Choosing the path of non-compliance another...
> For the flexibility you're referring, there is always table-layout="auto".
>
> Just my 2 cents
Thanks for the double-checking, anyway.
Cheers,
Vincent
