J.Pietschmann wrote:
Peter B. West wrote:
That could be done fairly simply without creating too many extra
objects by adding an operator field as a string to the
length/percentage PropertyValues, and building a list from the
expression.
...
What's wrong with parse trees produced by a recursive descendence
parser like ANTLR produces, or perhaps a LALR(1) parser? (The
XSLFO property expression grammar should be LR(1), I think).
Of course, there are actually three grammars at work:
- whitespace separated lists for some of the shorthand properties,
- the comma separated, optional whitespace list for font-family
- all the rest, with fallback to the original lexical string
if the type of the expression turns out to be wrong or some other
problem occurs (like hyphenation-char="-" [syntax error] or
page-number-format="01")
Constant folding can be applied to the tree, either during
construction or afterwards. This also solves the problem of
the get-nearest-specified() stuff nicely, just replace the
function call with the parse tree from the referenced property
and redirect the base of the percentage values. Of course
markers have to keep the call.
Basically, because there are three grammars at work. I've been through
the agony of extending the parser to cope with the bizarre syntax
requirements of the Rec, and I don't particularly want to start again.
However, if you see a better way, please explore. I tried to get
immediately useful output from the parsing, but there is still an
refineParsing stage to decode complex attribute values, like "font".
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
|
