On Friday 20 July 2007 00:29, Andreas L Delmelle wrote: > 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. > 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? Same principle, nothing new introduced here that wasn't there before. FOText is the generic descendant of anything that can have text content being it a block, an inline, a wrapper, .... I admit I am lost in your reasoning.
> > Cheers > > Andreas Manuel
