Peter B. West wrote:
2% of what? Of a reference area. Of what actually gets laid out on a page. If a single flow object gets laid out over more than one page, that reference may vary, but nothing changes in the FO Tree. It makes o sense to second-guess the Area tree within the FO tree. It's within the Area tree that all of these floe objects begin to take on concrete dimensions.
Sec. 7.8.4 indicate that font-size percentages apply to the parent element's font size, which would be from the FOTree, not from areas.
However, I fear that in the general case you may be right. The relative column-width problem in tables may fall into this category. If so, then the solution is to pass the relevant Area object to the "get" method so that it can see more of the Area's context. Any Area can (or should) be able to see not only its Area Tree ancestry, but its FOTree ancestry as well.
See Section 7.3 Reference Rectangle for Percentage Computations http://www.w3.org/TR/xsl/slice7.html#percrule
are maintained in spite of any to-ing and fro-ing with the Area Tree. Markers are an exception, and because marker properties are resolved in the context of the static-content into which they are eventually placed, all the information required for from-nearest-specified() must be available in the static-content FO subtrees.
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
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.
2) Area tree dependencies for FO expressions. Basically, length calculations involving percentages.
2a) Handling the expressions. 2b) Designing the interaction between the FO builder and the Area tree builder.
3) Layout look-ahead and backtracking. Closely related to 2b.
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.
More on these design issues in a subsequent post. -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
