On Friday 20 July 2007 01:11, Andreas L Delmelle wrote:
> On Jul 19, 2007, at 18:45, Manuel Mall wrote:
> >> <snip />
> >> And in doing so, we would eventually end up back where FOP Trunk
> >> started in 2002: a monolithic black box, which becomes harder and
> >> harder to maintain and extend over time.
> >>
> >> That's more the nature of my concern: that we do not fall prey to
> >> bad old habits.
> >
> > I don't get your point in this context.  What is different to
> > binding the Font, Alignment, Color, ... properties to FOText to
> > binding the Keep-together property to it?
>
> Nothing. I just don't like those being bound to the text either...
> Why duplicate the font-, alignment- and other info on the FOText
> descendant? Either there is no need to store them at the higher level
> at all, or they are always available from the parent so there is no
> compelling reason to bind them to the FOText as well.

The main reason is that our object hierarchy does not easily allow to 
retrieve that without messy tests instanceof tests and typecasts. If 
you want to re-architect the object hierarchy within the fo tree just 
to avoid the need to bind against FOText, please by my guest.

> Looking back at something like font-selection strategy: the more I
> look at it, the more I agree with the initial suggestion to deal with
> it during the layout-phase. Instead of generating multiple FOText
> instances that are tied to different fonts, the CommonFont
> information should precisely be moved away from the FOText.
>

This has more to do with CommonFont not being designed to handle list of 
fonts then its binding to FOText. If the logic for font selection is 
better placed in the TextLM we just need to give it the required data 
to be able to do so. If CommonFont can't do it we either need to 
redesign CommonFont or have another object that models font lists.

> > Same principle, nothing new introduced here that wasn't there
> > before.
>
> My point exactly.
>

Good, so why all the fuss about this particular relatively small commit 
then?

<snip/>

> Cheers
>
> Andreas

Manuel

Reply via email to