Hi fellas, As I awoke recently, trying to pick up where I left off end of January this year (see bug 25933), and started digging deeper into the current status of table-processing in HEAD, noticed the following in the FO Tree:
A TableRow FONode is created for every fo:table-row, and it is added as child to the TableBody corresponding to the parent fo:table-body. The TableCell objects are added as children to the TableRow nodes. Since you have to access the column-widths of the parent Table, you have to create a reference to its columns List for each of the TableRows. Now, I'm wondering, since the spec states that an fo:table-row doesn't generate any reference areas and since it can contain only TableCells, whether it wouldn't be more interesting (heap-wise :) ) to create just one TableRow object per TableBody, use it to process the TableCell objects in sets, but add the latter objects directly to the TableBody and reset the TableRow every time. IIC, a similar adjustment should then also be made to the Row LM. IOW: as I understand it, right now processing the TableBody iterates over the TableRows (i.e. simply catches the SAX events and blindly maps them to the corresponding Tree structure), as opposed to using a TableRow (catching a first SAX Event into a mutable member variable?) and iterate over groups of TableCells. Since the spec does provide for the starts-row property for fo:table-cells, it shouldn't be that difficult to set these to true to allow the Body and Row LM to determine which Cells are returned by the fo:table-row... The properties of the fo:table-row can be stored in the separate TableCells where applicable (there are no properties specifically meant for fo:table-rows; this occasion could also be used to settle background and border issues). I also have a hunch that this would be very convenient WRT managing rowspans... In that case, TableCells could be added to the TableRow directly, but only temporarily, to defer their finishing (?) If I judge correctly this could save a significant amount in memory usage in case of tables with a large number of rows, and could make implementing the table layout algorithms as defined in the CSS spec a lot easier (--at least, it seems more natural, since it's possible that there are no fo:table-rows specified at all, to consider them as optional, rather than having to perform all sorts of ugly tricks to be able to process a fo:table without them --which is a wall I bounced into) OTOH: I do see a challenge in the break-* and keep-* properties on table-rows, but I guess these could as well be stored in the row-starting cells somehow. Related links: http://www.w3.org/TR/xsl/slice6.html#fo_table-row http://www.w3.org/TR/REC-CSS2/tables.html#propdef-table-layout Does this make sense? Any thoughts? Greetz, Andreas
