Peter B. West wrote:...
The topic at hand is what API is needed for the FO Tree to be able to pass property values to its clients.
Ok. The trouble is that the relationship between FO Tree and Area Tree is, for me, still very much an unresolved question. When we start talking about these things, I go back to thinking about the details of the interaction between FO Nodes and Areas in the Area Tree.
Isn't part of your rationale in this "get" method to provide for the feedback of FO data to the Areas? At what points do you see the method being invoked?
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.
We do have very different grafting methodologies.
2) Area tree dependencies for FO expressions. Basically, length calculations involving percentages.
OK, I proposed passing the relevant Area to the "get" method.
Is this happening when an area is looking for information about its generating FO?
But, if I understand you correctly, only with reference to the Area Tree (via the passing of Area parameters in 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>
This seems to me to be begging the question to some extent. Rather than the Areas knowing how to find their FOTree heritage, isn't it necessary for the FOs to be able to find the AreaTree ancestry of the Areas that the FOs are generating? Isn't that what passing the relevant area in the "get" is all about? At the same time, however, it does get us thinking about the precise nature of this interaction.
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?
Very specialized. These things can force re-layout of the existing page, and can even ramify to previous pages, as we move towards a more "intelligent" layout strategy. There are two problematical aspects:
Layout look-ahead, to determine layout "errors" (e.g. footnote overflow, last page), and
Layout lookahead to determine actual dimensions ("auto" table layout.)
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
