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
