Andreas L. Delmelle wrote:
<snip/>
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.
Definitely worth considering.
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).
Huh? This is not true. Follow the link you provided to the spec. table-rows can have background and border properties (when border-collapse is on)
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 (?)
Conversely, what about column spans specific just to one row !?!
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.
yes, keep-* properties also apply to rows. On reflection I'm inclided to say it looks easier to stay as we are at the moment. Your idea is definitely worth considering, but since its primary goal is optimization, and at this time our primary objective really should be to get a working layout. That doesnt mean dont consider optimization, I just mean working layout takes priority over an optimized one. And it looks like it will be harder to achieve a working layout with your suggested changes.
<snip/>
Chris
