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
+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

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.



Reply via email to