Jeremias Maerki wrote: > On 11.09.2008 22:59:31 Vincent Hennebert wrote: >> Jeremias Maerki wrote: >>> I knew full well when I committed this that there's a certain >>> probability that you're not going to be happy with how I dit it. It's >>> hard to please you these days. So, is this post of yours a veto? >> Depends. The thing is, this issue will most probably show up also with >> the new layout approach, and it would be good to have it sorted out >> before. >> >> >>> At any rate, I don't think that generating FOs for missing table cells >>> is the right approach. >> Why? > > Elaborating on "additional overhead": You would generate additional FOs > for non-existent table-cells. For each FO, a layout manager is created > which will also need to be called. Table layout will need to run through > more cells per row than necessary even though they're empty. More > objects, more CPU cycles. Granted we're probably not talking about a lot > of empty table-cells but still.
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. At any rate, this is not worth the additional maintenance required by specific code. Other areas in the code have much more potential for cpu and memory savings. > 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. > The change is > confined to a narrow space. Your solution spans FO tree, layout and area > generation. Code modification would be in the FO tree only. We get the rest for free, handled by code that exists for normal cells and is already well tested. No need for additional testcases, except making sure that TableCell elemnts are created at the right place. This is much lighter in maintenance than a area tree testcase. > So I'm not convinced that my solution is bad See last sentence below. > or that your solution is > better. > >>> As can be seen in my commit, it is perfectly >>> possible to do without the additional overhead involved with your >>> solution. >> But not without additional code duplication. Vincent