Hi Andreas, Thanks for your answer (and sorry for the delay...).
While I still don’t agree with you, at that point I can agree to disagree. Although I’m still not happy with your arguments, you do have valid points, and in the end it’s one approach with drawbacks versus another approach with other drawbacks. A few comments below, but to sum up: I’ll see if I can provide a satisfying fix for the FO tree (using a flyweight pattern if possible —only one set of table-cell/block objects for all holes). Not right now, however... Otherwise I’ll try to find a better fix in the layout engine, but then it’s indeed best to wait for the implementation of the new approach. Andreas Delmelle wrote: > On Sep 17, 2008, at 13:26, Vincent Hennebert wrote: <snip /> >> Now /that/ is maybe the place for optimizations: improve the FO tree. >> For example make sure that no object is created if a property has its >> default value; > > Well, you'll be pleased to know that is *exactly* what happens now. 8-) Oh, I see. Well, good news... > My point is not so much the objects for the properties. It is the > reference to them that is reserved in the containing FONode. /That/ is > what makes the instance size of a Block rather large ATM, since it has > quite a few of those. ... and then it’s even less a problem IMO. But I get your point. <snip/> > Sure. I very much agree that code duplication needs to be avoided. The > architecture of FOP, OTOH, is precisely not to be viewed as one picture. > Much effort has been made in the past to more clearly draw the > distinction between the parsing/layout/rendering modules, exactly to > make implementing new features easier. If a feature can be implemented > by modifying one of those modules, then why spread the modifications the > other(s)? Well, absolutely: if the feature can be implemented in the FO tree only, why spread it over the layout engine? Right now, EmptyGridUnits are added at the FO tree stage /then/ handled at the layout stage. <snip/> > Ultimately, as I recall, it was always the long-term intention that > the > layout package would contain no hard references to FOP's own fo package > (apart from in classes like LayoutManagerMapping, maybe), but the FO > tree would be exposed as a set of interfaces (possibly to be made > standard among FO processors; I recall Victor Mote trying to raise a > discussion about this quite some time ago). One FO tree implementor may > choose to use SAX events to build a FO tree structure (as FOP's does), > another might choose to build a FO tree backed by a proprietary lazy DOM > (or collection thereof?). Yet another may choose an entirely different > approach, perhaps only remotely related to any known XML API. As long as > it could be mapped to standard interfaces, it wouldn't matter /where/ > the FOs come from exactly, the layoutengine would ideally always be able > to work with it. Point, however standard interfaces would come with a contract: “The FO tree /may/ return tables with holes in them”, or OTOH “The Layout Engine /must/ be given a table without any hole in it”, etc. <snip/> Vincent
