On Sep 16, 2008, at 12:05, Vincent Hennebert wrote:
I think this is negligible, precisely because we’re not talking about
a lot of missing cells. This would start to be noticeable if we were
dealing with huge empty tables, and in that case there’s probably
something wrong with the source document.
Not necessarily. Maybe the author was just trying to be creative
(avoiding a trip through SVG, by using tables as a medium-resolution
grid; something like that?)
At any rate, this is not worth
the additional maintenance required by specific code.
Could be right here, but such considerations are always worth some
thought...
What is the more precise description of this 'additional maintenance'
in this case?
Is it really /that/ much that it justifies the generation of
additional relatively large and long-lived objects so early in the
process? (Objects that basically correspond to nothing at all; maybe
due to code that was added just to make the code look cleaner... ;-))
If still yes, then is there really no other approach?
If no, then would it be better to do it now (before refactoring the
layoutengine) or after?
Maybe if we leave it, but take note for now, a better solution will
become apparent once the refactoring is done (?)
<snip />
[Jeremias: ]
RowPainter is area-generation stage. My solution is just making sure
areas are generated with the information that is available anyway.
It's
not doing anything in a place where it shouldn't do it.
RowPainter deals with rows, not cells. All it does is select the cells
for which it’s time to create areas, then it delegates to TableCellLM
the actual area creation. With the change we’re discussing there
are now
two places where areas for cells are created: in TableCellLM /and/
in RowPainter. This is redundant, confusing and increases the
maintenance code.
Hmm... maybe an idea to consolidate those parts into a CellPainter,
then? Just a vague idea (?)
Also an additional object, but for the empty cells, can be tailored
to be as lean/light as possible, and it is only created at the
appropriate time in the process.
The idea I offered earlier (a special type of FONode to represent
empty cells) would still generate completely unnecessary
TableCellLMs, and would be a pest to implement, if I estimate
correctly (?)
<snip />
Cheers
Andreas
