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...
<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."
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...
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)
For creating columns from the cells in the first row: still
investigating...
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.
Thanks for your input.
Cheers,
Andreas
