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.
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.
Same principle, nothing new introduced here that wasn't there before.
My point exactly.
FOText is the generic descendant of anything that can have text
content
being it a block, an inline, a wrapper, ....
One could answer here that FOText corresponds to PCDATA in the source
document, and PCDATA has no properties.
FOText being indeed the 'generic descendant' results in there being
roughly as many of those in any page-sequence as there are blocks,
inlines, wrappers... put together (most likely even more: two or
three FOTexts for a block with nested inlines or wrappers is not
uncommon).
Given that their ancestors already contain the exact same CommonFont
info, I see no good reason at all to propagate all that info to FOText.
I admit I am lost in your reasoning.
Don't worry, I get that a lot. :-)
Cheers
Andreas
