On Aug 5, 2007, at 21:07, Vincent Hennebert wrote:
Hi Vincent,
Sorry for chiming in so late...
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.
I'm all pro. Most of the overlap-situations are in fact currently
already caught at parse-time. This is handled in the treatment/
creation of column-numbers. Rowspans are also taken into account
there, so normally, one should not receive such errors during layout
anymore. IIRC, the error-text in that case indicates that it "should
have been caught during FOTree validation".
The only notable exception (yet again) being tables in markers: their
column-numbers will be created during layout.
<snip .>
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.
I've always looked at it as: the final step is reserved for layout,
but the resolution-logic itself belongs more to the FOTree or the
property resolution.
In the worst case, all that belongs in the layoutengine is a final
comparison between 'border-segments' at the cell-level to determine
the ultimate winner.
Currently start- and end-borders are resolved in
TableRowIterator (so, more at the FO tree building)
Hmm... for me this is --in the current situation-- not FO tree
building. Actually, the FO subtree representing the table will
already be completely built before a TableRowIterator is even
constructed. But you are definitely right that start and end borders
could be handled almost entirely in the FOTree.
For before and after borders, the following comparisons can be made/
dealt with in the FOTree:
table/before vs. header/before or body/before
table/after vs. footer/after or body/after
body/before (already resolved w/ table-border) vs. column/before
body/after (id.) vs. column/after
column/before vs. first-row/before
column/after vs. last-row/after
row/before vs. cell/before
row/after vs. cell/after
Note: stop at the cell level, and don't compare cells in two
consecutive rows here yet. Or rows in two consecutive bodies etc.
Only header and footer can be resolved entirely, apart from their
first-row/before (footer) or last-row/after (header) border.
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.
Not certain that this is necessary, although an interesting suggestion.
I'm thinking that if you give the layoutengine an access point to the
border-resolution logic, from where it can obtain the winning border,
it becomes unnecessary to store two borders on each cell.
Something in the form of a static method, into which table-layout
could pass two borders, and then gets the winner back (?)
<snip />
Does anyone feel against me implementing that in the FO tree?
Absolutely --NOT! :-)
Thanks,
Vincent
