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. :-)



Reply via email to