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! :-)


Reply via email to