> -----Original Message-----
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
<snip />
> it would be easy to determine col number in Table.addChild. This number
> could then be replaced in TableColumn.doSetup only if Column Number has
> actually been specified in the FO. I'm not sure I would be keen on
> working out any spanning related stuff in the FO Tree classes as it
> seems the wrong place for such computations. But that is just an opinion.
>

No, I guess you're right that the computations themselves should be left to
Layout, although *that* seems a bit silly if the respective property values
are already given in their absolute form at parse time.

To explain what I do see handled at FOTree level: in case of rowspan (r),
the cells with index >= the current cell in the subsequent (r-1) rows should
have their column-number increased by a value of colspan. I think this could
definitely be tracked when the FOTree is built...

Then further on in the Layout process, the xoffsets for all cells in the row
can be very quickly derived from the column-number ( sum of all
column-widths < cell-column-number )

<snip />
>
> >
> > The RowSpanMgr in maintenance *is* indeed very interesting...
> still no luck
> > here, though
>

Maintenance has a class (lemme see, ...) in fop.fo.flow called RowSpanMgr,
which I don't see reappearing in HEAD (unless someone has put it in a less
obvious location... Glen? You been moving some stuff around again??? ;) Jus'
kidding, of course...)
This class seems to be used to keep track of all rowspans. Haven't studied
in detail yet, but I guess one of these gets created for every table
(body/header/footer?), and it looks like the kind of thing I had in mind to
handle rowspans, so lucky me :)

Does anyone recall a thread where such was discussed? Or were tables
something 'to be figured out at an indefinite point in the future'? Well
then: No time like the present!


Cheers,

Andreas

Reply via email to