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

Reply via email to