On 10.09.2005 01:41:05 Andreas L Delmelle wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > In my attempt to facilitate an implementation of the collapsing border > model on tables by moving the lion's share of the logic from > layoutmgr.table over to the fo.flow package, I stumbled upon some other > parts that are currently dealt with at layout stage while I feel they > don't really belong there. > > To put it generally: there are questions about a table's structure that > can be answered by looking *solely* at the tree structure itself (i.e. > no details about the how, when or even if of layout are required). > > The other ones I encountered so far: implicit columns (from cells in > first row), column-number and number-columns-repeated. > > Especially the second seems out of place in layout, since it is needed > by the (currently unimplemented) function from-table-column(). If the > column-numbering is deferred until layout, it seems to become all the > more difficult to provide an eventual implementation for this function. > The other two are closely related to this, since they are necessary to > get the column-numbers right.
Point. But I somehow share Simon's reservation about moving table normalization into the FO tree. I share his view that the FO tree should represent the FO document like a DOM. On the other side, the FOEventHandlers (RTF, for example) could profit from the table normalization available on the FO tree level. But then the FOEventHandler could easily reuse the TableRowIterator. I'm not a big help here but after all I think the current table normalization works fine except that the from-table-column() method will be difficult to implement. > 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!? > The only downside is that certain information is lost. The tree > structure won't be the structure as specified in the source document, > but will actually correspond to another structure that yields exactly > the same results. > > Another related issue then, is that of storing the columns as a List. > Currently, in layoutmgr.table.ColumnSetup, an error message is logged > when there is a gap (i.e. non-occupied column-numbers). According to > the Rec, this is no error, since "there is no need for column-numbers > to be monotonically increasing from one formatting object to the next" > (see: 7.26.8 column-number) This is probably why no exception is thrown > (?) Yes, that should actually be no error, only maybe a hint to the user that default values will be used for a certain column. The problem is creating a TableColumn instance for the gaps. The case that more columns a required than are defined is handled differently by returning the last specified TableColumn. > I take this to mean that an author can decide to number the first > column as "3", and specify a number of "7" for the next. Yes. > 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(). > The larger the gaps and the more spanning columns, the more unnecessary > nulls to add. Right, but how many times does it happen? > 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. > 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. Jeremias Maerki
