-----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.
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).
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
(?)
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. 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.
The larger the gaps and the more spanning columns, the more unnecessary
nulls to add.
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.)
2) Anyone opposed to using a Map to store the columns instead of a
List? (Key = Integer or Numeric (column-number); Value = TableColumn)
Cheers,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDIh2byHTbFO9b8aARAmxiAJwOmZ20noM4AASe1yX+NEEJQFCT5wCdGdK0
l5ruWzp04zIKuFakiBQMr6I=
=dpCF
-----END PGP SIGNATURE-----
