As I recall, in the original original version, the complete FO tree was built before the Area tree construction was started. When Mark Lillywhite looked at the code, his most important contribution was to realize that the FO tree could be broken up into page-sequences, and the construction of the page-sequence Area subtree could be commenced at the end of each page-sequence.
In my original design, I intended to run parsing, FO tree building and Area tree building in parallel, linked together by producer/consumer buffers. I've done that for parsing and FO tree building, but my concepts of how to link FO tree and Area tree have been in a state of flux for some time.
It seems to me, however, that the key to 1) solving the layout dependencies of FO property expressions, and 2) reducing footprint, particularly for those long documents which are naturally expressed with very large fo:flow trees in a few page-sequences, is to have the areas generated by the FOs as soon as the FOs are parsed and entered into the FO tree.
If this were done, then there would *always* exist a reference area for the percentage expressions, even if that area could not always be dimensioned. Having a reference for the expression makes it straightforward to resolve the expression as soon as the referent is dimensioned, and also makes feasible the re-dimensioning of the referring areas if the referent is required to change (e.g., by virtue of being forced onto a new page with different margins.)
Some of my other preoccupations I have mentioned before. Line-areas should be filled from the bottom-up, while dimensions filter down from the top. E.g. my procedure for resolving footnotes implies that individual line-areas are passed up to the page level (region-body, at least) along with any impacts (footnotes, before-floats) associated with the line area. When side-floats occur, the line, and its impact (which is, I think, the entire side-float, which must therefore be resolved when encountered) are passed back to the ancestor reference area.
My focus in this is on the *page*-area-tree, which establishes a subtree of containers. These containers are then filled from the bottom up by line-areas, themselves filled from the bottom up by the atoms of the flow. While the page-area-tree is structured, and dimension issues can be resolved within it, there remains a close connection with the corresponding FO subtree, which itself is a subtree of the fo:flow subtree. Both the page-area-tree and the flow subtree can be very complex. Think of multi-column layout including tables with footnotes, and a list or two thrown in for good measure.
The containers of the page-area-subtree are filled from bottom-level FO nodes. The bottom-level FO nodes must be able to sensibly construct line-areas, including all of the line-breaking logic that is required. They know nothing of pages, however. When the page-area-tree fills, a page is ready for rendering or intermediate storage, so the page-area-tree "goes-away". That leaves the flow subtree in a suspended state, with the low-level FO nodes demanding space for the next line-area. (Note that blocks aren't "broken" - instead, areas are filled until a line-area comes along which would cause overflow. The offending line-area and its components are conceptually pushed back for reprocessing on the next page. It is this pushed-back line-area which generates the initial demand for more space.)
This demand percolates up through the flow active ancestry until it results in a demand for a new page. The page factory associated with the page-sequence and the layout-master-set through the page-sequence master-reference, generates a new page container set, and the relevant area and its dimensions are passed to the flow FO. From here the container availability percolates back down the active flow descendants, with the FO nodes generating new sub-areas, and attaching percentage expressions to their reference areas as control descends. At the bottom, the line-area generators are given new dimensions to deal with, and the bottom-up filling process begins again.
I want to diagram this, and look more closely at the nasty cases as I do, but comments are, as always welcome. Victor will be upset, I know, but I can't see the separation of FO tree building and Area tree building. Keiron may be screaming, "That's what I was doing," in which case my apologies.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
