Hi all, This one is for FO tree and Layout Managers specialists.
It seems to me that TableRowIterator should act during the FO-tree building rather than layout, as is currently the case. The main reason is that some validation like spanning cells that overlap can only be done once we start iterating over the rows/cells. Currently the TableBody and TableRow FObj do nothing but enqueuing their children elements. I think the row building could be done right in their addChildNode methods. That way validation errors could be thrown early instead of at the layout stage. Anyway, validation pertains much more to the FO tree building rather than the layout process IMO; that latter should be able to assume that it is working on valid FO elements. As to the border resolution, I’m slightly hesitant. One might argue that that belongs to the layout process, as borders may change whether the table is broken or not. Currently start- and end-borders are resolved in TableRowIterator (so, more at the FO tree building), and before- and after-borders during layout. In fact each cell could hold two different values for its border-before and -after: one for the “normal” case where the cell is not broken, and one for when it is. For example, given a cell inside the body of a table (not on the first nor the last row), it could have two border-befores: - no-break case: resolution between: - border-before of the fo:table-cell - border-before of the fo:table-row - border-after of the previous fo:table-row - border-after of the previous fo:table-cell - break case: resolution between: - border-before of the fo:table-cell - border-before of the fo:table-row - border-before of the fo:table-body - border-after of the fo:table-header - border-after of the header’s last fo:table-row - border-after of the fo:table-cell in the header’s last fo:table-row Does anyone feel against me implementing that in the FO tree? Thanks, Vincent
