Peter B. West wrote: > > 1. improved property handling > > 2. pull-parsing instead of an FO Tree (but with some data > stored in memory) > > 3. a different layout approach
... > > Re #2: this is the one that I don't yet understand. Peter and I > had a thread > > about six months ago that tried to resolve this, and I think he > will respond > > to this when he has time. > > That thread was as much (or more) about #3, IIRC. Yes, alt.design uses > pull parsing, but it definitely builds a tree, using the Tree and > related classes that I wrote when I first became involved. The major > difference is not with pull parsing (although it necessitates a > different approach for extensions), but with the layout dependencies > that I see as unavoidable for property resolution. (See below.) OK. I am using "FO Tree" in a specific sense, i.e. the FOP FO Tree. I think you are referring to a different data structure of your own making. The point is that if John or anyone else wants to help integrate your work into the trunk line of development, either 1) the existing FOP FO Tree has to be scrapped, or 2) your Tree structure must exist in parallel with the existing FOP FO Tree. Is that not correct? > > Re #3: we have now implemented LayoutStrategy, which means that > alternative > > layout systems can at least theoretically be dropped into FOP. See > > subsequent announcement for more information on this aspect. > > And thereby hangs a tale. I started (FOP)life as a believer in the > separation of property resolution and layout as sequential stages, as > the Rec seems to state very clearly. In the process of trying to code > the property resolution, it gradually dawned on me that such separation > cannot occur. Going back to the Rec, I found the editors' escape > clause. Dialogue with the editors has since confirmed that they were > aware of the layout dependency for property resolution. I just spent some time reviewing some of the doc in alt.design again. I looked for but did not see documentation about your thought process here (i.e. why FO Tree should be abandoned in favor of your system). I know it is embedded in the archives, but do you have a well-written summary of the whole thing somewhere that I could use to refresh my memory? There is a lot of "what" in the doc -- if you could add some "why" it would be a big help. > The question for me was, "Do I kludge around this dependency and > introduce back-door methods of solving the layout feedback issues for > property resolution, or do I look for a design that is up-front about > this?" I was engaged in that search. The process will not be simple > and clean, because the problem is not. I'll settle for coherency, > robustness and comprehensibility, if I can achieve them. I will freely admit that I don't know as much about this problem as you do. Your position is that the devil in the details makes FOP's high-level design a "kludge". Since I am (regrettably and much to my frustration) knee-deep in the high-level design issues, I *really, really* want to make sure that we are on the right track with them. IOW, lets try again to resolve this, if you have time. Victor Mote
