On Jul 19, 2007, at 18:10, Andreas L Delmelle wrote:

<snip />

There is not need for the inline obj to bind to the properties as its LM
does not use them.
The bind is done only for the FOText as it is the
only object whose LM is currently making processing decisions on it.

See? And why is that? Because you decided to implement it that way. :-)

Before your patch the property was not present on FOText, and was not dealt with by the TextLM, but now it is... Keeps and breaks on fo:blocks are definitely handled by the corresponding LM, so in that respect, your solution seems to introduce inconsistencies.

Just to clarify: what I mean is, in the end, we could just as well scrap the entire FO Tree and rewrite FOP to generate layoutmanagers from the input directly. Who needs FONodes after all? What is their use, if ultimately everything is handled by the LM anyway?

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.



Reply via email to