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.


Jeremias Maerki

Reply via email to