FYI, I've started coding a TableRowIterator which incrementally fetches rows from the FO tree. I've (locally) disabled the code that replaces groups cells into rows. GridUnit is a class I've written earlier. It can be reused here and gets a reference to the TableCell element. From there you can look up an optional row and the body it belongs to by inspecting the parents. Furthermore the GridUnit will receive the resolved borders (once for the non-break and once for the break case). The effective half-border-width for the cell will be set on the primary cell of a spanned cell (see "max border width / 2" comment in http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel), also for both cases. I will probably subclass GridUnit to PrimaryGridUnit to save runtime memory for the spanned grid units that don't need this info.
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 furthermore it's lightweight (a list of arrays of GridUnit instances). The TableContentLM is probably something like Andreas' reusable RowLM. It looks like I can pack a lot of preparational work into that TableRowIterator thus making the TableContentLM lighter (which will probably be a blessing): - starts-row|ends-row resolution - border resolution including "half max border width" calculation - cell overlap check - implicit column handling (columns will also get their own container) - GridUnit factory including setup for CellLM on primary cells - easy navigation on the grid for the TCLM 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. 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. On 01.04.2005 11:33:58 Jeremias Maerki wrote: > 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 Jeremias Maerki
