Andreas L. Delmelle wrote:
Hmm.. Yes, but... these properties are not specifically meant for the rows
themselves. They are meant to be propagated to/combined with those defined
on the table-cells contained by it.
( IIC, resolving the possible conflicts WRT backgrounds/borders can be
settled, for a large part, at FOTree building time. )
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 !?!
They will be stored in the table-cells, just as they are now.
Another good point.
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.
Something I'm very concerned about, which is why I haven't started any work
on it yet... wanted to gather your opinions first.
Theres no harm in doing work locally and then formulating a patch for review.
Right now, I just have a very clear-cut idea on what exactly needs to be
done, and if I'm not mistaken, the required changes to Layout will be
minimal (see the upcoming follow-up message: will post that one later
tonight). For the most part, it will work exactly as it does now, only the
code for *creating* the Row and Cell LM's will need a little adjusting
(serveTableRow() and serveTableCell() in AddLMVisitor?)