You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Andreas L Delmelle <a_...@pandora.be> on 2005/09/10 01:41:05 UTC
Tables, Columns... : FOTree or Layout?
-----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-----
Re: Tables, Columns... : FOTree or Layout?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 10, 2005, at 21:33, Simon Pepping wrote:
Hi Simon,
> You are asking a lot of questions. To most I have no answer, but I
> have one reservation.
>
> On Sat, Sep 10, 2005 at 01:41:05AM +0200, Andreas L Delmelle wrote:
>> 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.
>
> This bothers me. It may hinder proper calculation of property value
> inheritance, which follows the tree as given by the user. We do
> property refinement on the tree; other than that it is a precise
> reflection of the user's fo document. I am reluctant to change that.
I understand your reluctance. I have similar reservations, which is
exactly why I'd rather gather more opinions on the matter before
proceeding.
Let me explain a bit further...
My idea is inspired by the way XEP performs this kind of normalization.
It does so by performing a pre-processing XSL transform on the FO
source document --so the actual input for XEP isn't always an exact
copy of the tree as defined in the user's document.
Since we have no such pre-processing step --and, of course, stealing
that idea is out of the question--, the only place we could perform
such normalization is precisely in our FOTree.
Besides that, nothing changes WRT hierarchy. The relationships between
the elements will stay the same, so inheritance/property refinement
shouldn't pose a problem.
Almost on the contrary, in a certain way, not performing such
normalization and deferring those matters to the layout package seems
to have precisely the effect of not being able to correctly refine the
properties in the FOTree itself --we'd always have to wait for layout,
which in turn seems to contradict the idea of having a FOTree module
that doesn't depend on any particular layout engine (if this idea is
still relevant, that is...).
IMO, the least the FOTree should be able to provide is the correct
initial values for the properties, which becomes next to impossible if
the mentioned issues are dealt with only when layout begins.
Cheers,
Andreas
Re: Tables, Columns... : FOTree or Layout?
Posted by Simon Pepping <sp...@leverkruid.nl>.
Andreas,
You are asking a lot of questions. To most I have no answer, but I
have one reservation.
On Sat, Sep 10, 2005 at 01:41:05AM +0200, Andreas L Delmelle wrote:
> 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.
This bothers me. It may hinder proper calculation of property value
inheritance, which follows the tree as given by the user. We do
property refinement on the tree; other than that it is a precise
reflection of the user's fo document. I am reluctant to change that.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Tables, Columns... : FOTree or Layout?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 11, 2005, at 16:05, Jeremias Maerki wrote:
<snip />
> I'm feeling stupid but I keep having problems following you. Maybe it
> would be worthwhile if you put your work in a branch so everyone could
> have a look.
Well, don't feel stupid. I keep having problems expressing it in plain
English as well.
About putting the work in a branch: that's due for sometime this week.
Got this week off from work, so I'll have plenty of time to finish it
up.
Cheers,
Andreas
Re: Tables, Columns... : FOTree or Layout?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 11.09.2005 15:01:30 Andreas L Delmelle wrote:
> On Sep 11, 2005, at 13:19, Jeremias Maerki wrote:
>
> > On 11.09.2005 12:47:03 Andreas L Delmelle wrote:
>
> > There's nothing special about FOP's tree structure.
>
> ... except that it currently doesn't provide the correct initial values
> for the mentioned properties :-)
Right, sorry.
> > 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.
>
> That may be an idea worth investigating: only implement it in the
> FOTree, and make it available to the layout package, so that layout can
> also use it --*if* it still needs to...
> IMO this would make the layout code massively more transparent.
>
> But anyway, currently the balance is:
> +2 for having the tree structure exactly resemble the FO source document
> versus
> +1 for performing normalization as the tree is built
I think the first doesn't necessarily exclude the second. Maybe the
normalized structure can be made available through the table element.
This way you'd still have the normalized table available in the FO tree
and to the FOEventHandlers while preserving the original FO tree. Plus
my +1 on the first item is not a full +1, only perhaps a +0.5 as I'm
fully aware that certain problem can only be resolved if some of the
normalization happens in the FO tree already. We probably still haven't
found the "right" design.
> Based on that, if no other devs jump in to support me, it seems I may
> have to abandon my plans for collapsing borders there altogether, as
> this would also mean that the BorderInfos for the table elements are
> altered (so they wouldn't correspond exactly to what was specified in
> the source document) :-(
>
> WRT efficiency, I still think it would be worthwhile to end up with a
> table tree structure with elements referring to the very same
> BorderInfo instance for a given side (losing BorderInfo instances for
> certain elements would be immediately discarded and replaced with a
> reference to the winning BorderInfo)
> Think of a table with 100+ rows, with the table's start-border
> dominating over all other elements' start-borders. First table-column,
> every table-body, every table-row, and all the first cells in every row
> would simply get a reference to the table's BorderInfo for that side.
> The idea behind it is that:
> a) the user shouldn't have supplied the losing border-specs in the
> first place (i.e. it would make no difference if he hadn't --his source
> document would produce exactly the same result), but
> b) this is often not under the user's control --think of a stylesheet
> that conveniently uses the same attribute-set for all cells in a given
> row, regardless of whether they share an edge with higher
> table-elements.
I'm feeling stupid but I keep having problems following you. Maybe it
would be worthwhile if you put your work in a branch so everyone could
have a look.
<snip/>
Jeremias Maerki
Re: Tables, Columns... : FOTree or Layout?
Posted by Manuel Mall <mm...@arcus.com.au>.
On Sun, 11 Sep 2005 09:01 pm, Andreas L Delmelle wrote:
> On Sep 11, 2005, at 13:19, Jeremias Maerki wrote:
> > On 11.09.2005 12:47:03 Andreas L Delmelle wrote:
<snip/>
> But anyway, currently the balance is:
> +2 for having the tree structure exactly resemble the FO source
> document versus
> +1 for performing normalization as the tree is built
>
Apologies, but my understanding of this area is far too limited to give
an opinion either way.
Manuel
Re: Tables, Columns... : FOTree or Layout?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 11, 2005, at 13:19, Jeremias Maerki wrote:
> On 11.09.2005 12:47:03 Andreas L Delmelle wrote:
> There's nothing special about FOP's tree structure.
... except that it currently doesn't provide the correct initial values
for the mentioned properties :-)
> 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.
That may be an idea worth investigating: only implement it in the
FOTree, and make it available to the layout package, so that layout can
also use it --*if* it still needs to...
IMO this would make the layout code massively more transparent.
But anyway, currently the balance is:
+2 for having the tree structure exactly resemble the FO source document
versus
+1 for performing normalization as the tree is built
Based on that, if no other devs jump in to support me, it seems I may
have to abandon my plans for collapsing borders there altogether, as
this would also mean that the BorderInfos for the table elements are
altered (so they wouldn't correspond exactly to what was specified in
the source document) :-(
WRT efficiency, I still think it would be worthwhile to end up with a
table tree structure with elements referring to the very same
BorderInfo instance for a given side (losing BorderInfo instances for
certain elements would be immediately discarded and replaced with a
reference to the winning BorderInfo)
Think of a table with 100+ rows, with the table's start-border
dominating over all other elements' start-borders. First table-column,
every table-body, every table-row, and all the first cells in every row
would simply get a reference to the table's BorderInfo for that side.
The idea behind it is that:
a) the user shouldn't have supplied the losing border-specs in the
first place (i.e. it would make no difference if he hadn't --his source
document would produce exactly the same result), but
b) this is often not under the user's control --think of a stylesheet
that conveniently uses the same attribute-set for all cells in a given
row, regardless of whether they share an edge with higher
table-elements.
<snip />
>> 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?
Not missing anything, I guess, because indeed the description of the
initial value for the column-number property on table-columns simply
states "the column-number of the previous column plus one". Either this
should be "the column-number of the previous column plus its
number-columns-spanned", or the sentence under number-columns-repeated
should be revised/omitted...
<snip />
>> 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.
Well, in this case, we'd need a clone of the original column, and
FONode does override the default clone() method --which immediately
calls addChildNode() as well... Might be an idea.
Still contemplating.
> 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.
Yep, and if I interpret correctly, the only property that such columns
would get from the cells is the ipd/width, so this shouldn't prove to
be too difficult.
Thanks again for the valuable input.
Cheers,
Andreas
Re: Tables, Columns... : FOTree or Layout?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: Tables, Columns... : FOTree or Layout?
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Re: Tables, Columns... : FOTree or Layout?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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