> Implementing all of AsTeR's recognition on top of the extensibility model > allowed AsTeR to gain a similar advantage when it came to rendering the > structure --rendering a teX builtin construct like \over was no different > and no more complex than rendering the \legendre. This makes a lot of sense to me. It seems relatively straightforward to have a file containing the set of operators and templates for mapping the parse trees into the corresponding trees based on the rendering schema. I wish I had a good student to work on this, as I am too busy to make rapid progress on this on my own. Defining operators is easy enough. This needs to be supplemented by productions for matching pairs of operators, e.g. left/right brackets, and integral signs and differential `d's. This too is straightforward. The next piece is the templates for mapping the input parse tree to the schema tree. The tricky part is the syntax for variables. In my first attempt, I used "var(variable_name)" as in: map((var(a) over var(b)) becomes over(var(a), var(b))). This is kind of cumbersome. Prolog treats atoms as variables if they start with an upper case letter. This option isn't open to us though. Maybe a modifier character would work, e.g. "$a". If type restrictions on variables are needed, then it may be worth introducing separate rules for defining these, as otherwise the number of map rules will multiply enormously. I will work further on these ideas. It may be worth spending time on coding them up in C with the Arena browser. Regards, -- Dave Raggett <dsr@w3.org> tel: +1 (617) 258 5741 fax: +1 (617) 258 5999 World Wide Web Consortium, 545 Technology Square, Cambridge, MA 02139 url = http://www.w3.org/People/RaggettReceived on Tuesday, 21 May 1996 18:32:25 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:56 UTC