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:

Does this make sense? Any thoughts?



Reply via email to