Peter B. West wrote: > >>>Yes, this is the real issue. > >> > >>Only one of the real issues, I'm afraid. > > > > > > OK, what are the others? > > > > The thorns that immediately stick in my finger are
The topic at hand is what API is needed for the FO Tree to be able to pass property values to its clients. > 1) markers > I have a pretty well-developed idea of how to implement the FO tree > building side of this in alt.design. It involves > static-content-specific changes to the current FO tree building > algorithm, and a slight generalization of the SyncedFoXmlEventsBuffer > class to allow events to be read from a variety of sources. In a word, > grafting. OK, I have addressed this. > 2) Area tree dependencies for FO expressions. Basically, length > calculations involving percentages. OK, I proposed passing the relevant Area to the "get" method. > 2a) Handling the expressions. This can all be done within the FO Tree. > 2b) Designing the interaction between the FO builder and the Area tree > builder. OK. I proposed the following, which you have not addressed: <from-previous-posting> Your experience and insight on this issue are extremely important. If Areas know how to find their FOTree heritage as well as their AreaTree heritage, can you think of any concept that is missing to do Property resolution, assuming that the relevant Area is passed to the "get" method on the FOTree side? </from-previous-posting> > 3) Layout look-ahead and backtracking. Closely related to 2b. AFACT, these would become simply re-"get"ting the value from the FO Tree, passing a new Area as a parameter. > 4) Managing the association out-of-line areas (footnotes and floats) > with the FONode/Area in which it was defined and the higher-level areas > (e.g. before-float-reference-area, footnote-reference-area, > main-reference-area) which are juggled as a result of the lower-level > contents. Is this not just a specialized case for the general case #2 above? Victor Mote
