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 />



Reply via email to