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