On 11.09.2005 12:47:03 Andreas L Delmelle wrote: > On Sep 11, 2005, at 11:52, Jeremias Maerki wrote: > > Hi, > > > On 10.09.2005 01:41:05 Andreas L Delmelle wrote: > > >> This kind of on-the-fly normalization of the tree structure has > >> advantages for layout in that the table-grid co-ordinates will be > >> readily available (no interpretation needed, just pick up the cells as > >> building-blocks and map them onto the grid without too much effort). > > > > Huh? But that's already the case with the TableRowIterator!? > > Yes, but that class is situated in the layout package. So, this doesn't > exactly provide the TableCell or TableColumn with the correct initial > value for column-number (as described in the Rec). It leaves this up to > the layout engine. In the short-term, this may not be too much of a > problem, but if the long-term goal is still to provide the possibility > of plugging in different layout engines, any such engine would have to > take into account that FOP's tree structure will be lacking the correct > initial property values here...
There's nothing special about FOP's tree structure. It's just the exact representation of the FO file without any normalization. Anyway, if I hadn't introduced the TableCellLM in the PrimaryGridUnit you could simply move TableRowIterator and the GridUnit classes into the FO package because they have no dependency on the layout classes except for the little exception above. I imagine you will need to reproduce exactly what I implemented in TableRowIterator again in the FO tree. > <snip /> > >> To allow for a > >> straightforward way to map between the List index and the > >> column-number, we'd need to create a List containing 7 elements, 5 of > >> which aren't real elements at all... and that's still leaving > >> number-columns-spanned out of the picture. > > > > Remember that number-columns-spanned on table-column don't actually > > span > > cells but only define column groups and provide a value for > > from-table-column(). > > OK, I overlooked this tiny detail... Thanks for pointing that out. > Even then, I guess my concern was the combination of > number-columns-spanned and number-columns-repeated. If you have a > spanning column that is repeated, the column-numbers for the repeated > columns will have to consider the value for number-columns-spanned. > see: Rec 7.26.12 number-columns-repeated > "The 'column-number' property, for all but the first, is the > column-number of the previous one plus its value of the > 'number-columns-spanned' property." Hmm, to me that sounds like a mistake in the spec. This is completely illogical. At the very least, this sentence is in the wrong place. It doesn't even refer to the number-columns-repeated property. IMO this sentence creates a conflict between number-columns-repeated, number-columns-spanned and column-number for table-column. Note that the same sentence is also found in XSL 1.1WD. What do I miss? > >> The larger the gaps and the more spanning columns, the more > >> unnecessary > >> nulls to add. > > > > Right, but how many times does it happen? > > Yep. Precisely the reason I'm asking... Ok, to answer my question: IMO not so often. > >> So, basically two questions here: > >> 1) Anyone opposed to moving column-numbering, number-columns-repeated, > >> implicit columns over to the FOTree side? (I already have a pretty > >> good > >> idea of what needs to be done, so I can start immediately on that.) > > > > Not opposed, but I don't really see how exactly you are going to do it. > > For the column-numbers: tracking the columns as they are added to the > tree, and increasing the column index should do the trick. The default > value for the column-number property will be available as the column > index of the parent table. In case a column-number was explicitly > specified, and deviates from the initial value (the column index), the > index will be forced to that column's column-number, so that it is > correct for the next column. > > For the repeating columns: insert new TableColumns immediately into the > tree structure. The only problem I'm facing here is that the properties > can't actually be the same instances as those of the first column > --this is currently the only case that will break the border-collapsing > strategy I have in mind. (not going into details here; expect a > separate post on that) That's also the big problem I see. I never actually figured out how to properly and manually create FO nodes. I'm sure there's an answer to that. > For creating columns from the cells in the first row: still > investigating... I don't think this is a big problem. Just check for the availability of a column set once the first row is available and create the column setup if necessary. > >> 2) Anyone opposed to using a Map to store the columns instead of a > >> List? (Key = Integer or Numeric (column-number); Value = TableColumn) > > > > I wonder if the Map not actually uses more space or creates more object > > instances than the List approach with a few null values. > > Exactly why I'm asking. If this doesn't occur too much, it would indeed > be a waste of resources... All things considered, this may indeed not > be such a good idea. IMO, yes, not such a good idea. FWIW, it's also easier while debugging. Jeremias Maerki
