Moving TableRowIterator to the FO Tree and Resolving Borders There

[Vincent Hennebert <vi...@anyware-tech.com>]

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

Re: Moving TableRowIterator to the FO Tree and Resolving Borders There

[Andreas L Delmelle <a_...@pandora.be>]

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
>