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.
Cheers
Andreas
