Peter B. West wrote:
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.
I missed the import of this when I built the alt.design parser on top of the maintenance branch parser code. This is what I am trying to achieve. If it already exists, so much the better. Where does repeated evaluation of the parse tree occur? Is there a parse tree object?
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
