On 04.04.2005 20:39:43 Andreas L. Delmelle wrote:
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> > FYI, I've started coding a TableRowIterator which
> > incrementally fetches rows from the FO tree.
> <snip what="very interesting stuff" />
> > In so far it seems I don't really follow Andreas' suggestions even
> > though I borrowed a few ideas. I think the unit grid is necessary
> > because of the algorithm for combining element lists and of course
> > because of border resolution.
> ...and background-resolution --> see below
> AFAICT, this would indeed be the optimal way to implement what I was getting
> <snip />
> > What I'm not sure of yet is where to put background handling for table,
> > bodies, columns and rows. It'll be either TLM or TCLM.
> I'd say the TCLM, since that is by definition the context in which you have
> a reference to all the involved background-properties on all of the
> components of the table. In the most extreme cases, where all or most of the
> different backgrounds are partly visible, the TCLM seems to be the one that
> has access to all data necessary to 'draw' these on top of each other
> (table->body->column->row->cell?) in exactly the right proportions (taking
> into account resolved borders, padding ...)
Yes, I agree, although the real TableLM gets quite slim this way. But
I'll better just get on a bit and see where it leads. FYI, I've already
got rudimentary element list combination (i.e. without row-spanning).
I've been able to reuse most of my column/grid setup code. I expect the
same will be possible for border resolution. I'm currently determining
how best to do the addAreas stage with the infos I get from the Position
objects. The stuff is all carved into little pieces and I now have to
put it together again.
> > If you think I'm completely on the wrong track, stop me soon. The train
> > starts to roll now.... :-) I'm in a hurry. Sorry.
> Absolutely not! Train seems to be very much on the right track.
Good to hear. Thanks for the feedback!