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
