On 24.03.2005 02:21:59 Andreas L. Delmelle wrote:
> > -----Original Message-----
> > From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> >
> (Just trying to join in the conversation with no specific knowledge about
> the code yet --still catching up on the recent changes--, but I remember
> that, a while ago, I had also been struggling with tables. The code will
> have changed a lot I guess, but some of the options I considered could be of
> use... I hope)
> > I tend to think by now that the first approach I presented earlier is
> > illusory and too complicated. The second should work out just fine, even
> > with row span.
> Speaking of rowspan: I don't really know if it's even possible, but one of
> the options that kept haunting me --and thus, seemed promising to me-- was
> to not create a rowLM for every cell-list (to bridge the gap between
> 'rowless' and 'explicit rows'), but rather use one rowLM as a sort of 'comb'
> (if the analogy makes sense).
> A cellLM for a fo:table-cell spanning multiple rows --and its children--
> would remain in the rowLM until the cellLM's 'remaining' rowspan becomes
> zero (span here being relative to the page to accommodate cells spanning
> multiple pages). The rowLM _can_ receive its properties from the current
> fo:row, if there is one. If not, these props can be null-ified.
> WRT the column props, my attention had been drawn to the fact that a
> columnList was created for _every_ row, since these:

the columns variable is only a reference to the column list. It's not
rebuilt for every row. What is rebuilt is the gridUnits list but that's
necessary because the borders in collapsing border model [1] depend on
the individual grid units. Each and every segment of a cell border must
be evaluated according to the rules in the spec.

[1] http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel

>  a. basically stay the same for the whole table in the easiest cases
>  b. for the harder cases they are (very) roughly constant for a
> cross-section of
>    1. region of the page (static or flow; possibly multi-column itself)
>    2. (table-header +) table-body (+ table-footer)
> Recreating a reference to a list with references to the columns for every
> row seemed to be inefficient somehow --very much so in case of a table
> spanning across many pages containing hundreds, possibly thousands of rows,
> even with only seven or eight columns...

Yes, but I don't think this can be avoided.

> My main motivation for considering such a construct was the fact that, at
> the Area Tree level, there *is* no row, only the union of the areas
> generated by its children, so it seemed to make sense to diminish the
> importance of the row-concept when progressing from FO Tree --multiple-- to
> Layout Tree --one, maybe two or three, but no more-- to Area Tree --zero.
> With a few helper rows, it also seemed attractive from the POV of 'marking'
> the earlier described cross-section. Convenient to iterate --in both
> directions-- over the elements in the table (body|header|footer)'s element
> list (the cellLMs), and perform multiple passes, since the first and last
> row on a page contain the necessary references to the bounding elements in
> the element-sublist in question. Go for a 'rough sketch' pass first, if this
> is not sufficient --which conditions exactly?--, iterate over the altered
> elements.
> > I'll start with the helpers for keeping track of accumulated BPD.
> > In the meantime I hope there's enough time so you guys can comment on
> this.
> Well, possibly more detailed, code-oriented description to follow...
> I hope there's a 'Aha!-Erlebnis' in there somewhere for someone.
> If not, I hope you at least enjoyed the rant :-)
> If not --errm... my apologies.

I haven't understood everything you wrote, yet. I think there's a spark
of an idea in there but ATM I can't get hold of it. I'd appreciate if
you could look at the current table layout code. The change from
first-fit to Knuth approach doesn't invalidate much of it. 

Jeremias Maerki

Reply via email to