Now that I'm mostly finished with the element generation for tables I can have another look at this because I need to implement all this now. On second thought, I'd like to go into more detail here because I think it might indeed be worthwhile to consider going down that road.
Overall, I found exactly one point that needs attention when going away from always iterating over rows: The background of a row. This one is painted separately and will need some special attention, although I think this should be no big problem. I've disregarded visibility="collapse" for the moment which is interested only for interactive use. This can be done later. Earlier, I implemented a normalizer in the FO tree that converts a rucksack full of cells into rows with their cells at the right position. If we take this out we have to move the functionality into a special iterator that puts the cells in the appropriate slots at any given step/row. Andreas hinted at that already. What I still think will be necessary is to have a grid for all grid units so we can handle the border resolution (and painting) right. This means total no. of effective row * total no. of effective columns grid unit instances. But parts of the array can be freed when the addAreas stage is over. The array can also be used to jump to a position during addAreas; we simply need to keep track what index the first row in the array has after previous rows have been released. Possibly the array will also be instrumental when we get around to implement auto layout. Based on the element generation for tables I wrote I will also need to find and remember row groups (not those defined in the spec but those defined in the Wiki). Apart from the RowLM we can also get rid of the BodyLM because it's mostly the same issue. The body is mostly relevant for border resolution and background painting. The only problem there are header and footer. I'm thinking along the lines of creating a class owned by the TableLM that handles the whole table contents. Headers and footers will probably be handled in a special sublass. So in the end we have the TableLM, a TableContentLM (or something like that) and CellLM which handles the contents of each cell. I'm still in the process if figuring out how exactly to implement all this and I don't know if I'm making any sense here. But feedback and help is appreciated. On 26.03.2005 16:05:46 Andreas L. Delmelle wrote: > > -----Original Message----- > > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > > > <snip /> > > 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. > > Just did. > > > The change from first-fit to Knuth approach doesn't invalidate much of it. > > Indeed not. What I'm referring to goes more in the direction of 'interaction > between FOTree and Layout', not so much the workings of the Layout system > itself --although it's bound to have *some* impact on it, this should be > minimal (and may even facilitate some of the work, but that's still a > question-mark for me) > It appears to me more an alternative to the current solution for bridging > the gap between tables with and without table-rows. > > Currently both possiblities lead to the same structure in the FOTree, which > is perfectly legitimate --RenderX performs table-normalizing in a > pre-processing XSLT step, which deals with this amongst others (if I > remember correctly.. I only had a very quick look and that was quite some > time ago.) > > However, instead of mapping both possibilities to a structure with rows, we > could go almost the other way round by using a structure with cells as > direct descendants from the body, where the first cell of each row would be > a special type (a subclass of TableCell?) that has the ability to store the > row's properties (if fo:table-rows are explicitly used). The 'starts-row' > property is there anyway, so it can be put to good use... > > In the Layout Tree the RowLM's initialization would be triggered by these > row-starting cells, but the RowLM would operate on the cells as direct > descendants of the body. So the RowLM's cell-list would not correspond to > the unique list of descendants of a corresponding TableRow, but rather to a > sublist of the unique list of descendants of its parentLM's > TableBody/-Header/-Footer. (IOW: the RowLM's could be made re-usable; at > least, there would not *necessarily* have to be a one-to-one relation > between fo:table-row, TableRow and RowLM --although it still remains > possible where it *is* needed.) > > I'm still not sure whether it makes sense... > > Cheers, > > Andreas Jeremias Maerki
