O well, the perils of staying awake late...Good question. Make it font-size="12pt+2%+0.8*(from-parent(height) div 32)" though.
This is why I was talking some time ago about a PropertyValue type which is an RPN-style expression, which can be rapidly resolved without recourse to the general parser.
I'm not quite sure what the intend of this sentence is. The maintenance branch uses a recursive descending parser to parse the property expressions as defined in the spec in section 5.9 (complications due to shorthand lists and font lists aside). The parser generates a tree of property expression objects. If the property value is inquired, the expression is evaluated, and the various subexpressions pull necessary context values from their associated FOs. I vaguely remember PropertyList and PropertyManager work somewhat differently, and this is for example the reason why percentages still don't work for table columns and why it is not possible to define a leader length as 2cm+30% (you can have either 2cm or 30%), despite the expression is parsed correctly. Note that while expressions may be *evaluated* repeatedly, they are *parsed* exactly once.
Without it, we have to carry at least some expressions around in the raw, after having first parsed them in order to determine that we can't resolve them, and then throw them to the parser again whenever a) we have sufficient context, or b) the page is re-laid.
We don't have to carry the expression as string and reparse every time, parsing into an expression tree and evaluating as necessary works just fine. A possible concern could be memory waste, for example if people write start-indent="2cm + 0.8*( 10.4cm div 2)" this would create a tree sum + length 2cm + mul + number 0.8 + div + length 10.4cm + number 2 or 7 objects. Compilers use "constant folding", i.e. using arithmetic laws for rearranging and possibly combining terms in the expression. A valid length expression would be canonicalized into a sum of an absolute length measure, a percentage and unresolvable functions. Whether building a constant folding mechanism is worthwile is quite another matter. I didn't see complicated expressions all that often, and optimizing the parsed tree may as well cost more time than is saved later. Anyway, the folding mechanism will detect a lot of invalid expressions early during parsing, which may be an advantage.
Just don't do it.The idea of performing a full parse on a given expression more than once makes me nauseous.
The approach I am thinking about with such expressions is to associate the expression, and therefore the FO node, with the *area* which will provide the context for the resolution of the percentage component(s) of the expression. (It may be enough to use the parent area of the areas that the node generates, and to work back to the appropriate reference area or other dimension when the parent dimensions are resolved.)
When the dimensions of such an area are resolved, the list of attached FO property expressions can also be resolved. Exactly how to do this I am not yet sure, but I am thinking of something along the lines of a co-routine, implemented by message-passing queues, similar to the existing structure of the parser/FOtree-builder interaction.
Sorry, I think this is overcomplicated.
J.Pietschmann
