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
>> 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
   * 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

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-)


>> 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.


Reply via email to