-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UnicodeMath implementation reference #2
Comments
Current intended solution is to specialize '/' and '_', '^', so that they automatically raise the precedence of the unary-able operators behind them. I still need more testing on MS Word |
Found a really good project to be a reference https://github.com/doersino/UnicodeMathML After going through its implementation. I think the following solution might work for this project:
The rationale is that:
Why not let the parser parse backward for the interactive mode?
|
Some other ambiguities related to separators (Tested in MS Word):
|
Here is a dedicated issue for the implementation of UnicodeMath spec.
After some quick experiment, I find some quite burning discrepencies in the UnicodeMath. The following discrepencies will directly affect parser design and behavior. I will document them within this issue and the docs.
Current Plan
There are two areas of UnicodeMath input support currently under consideration: user input, or a string input. The plan is to support both by treating string input as a stream of user character inputs (with the cursor fixed on end). (This behavior is not guaranteed by the spec itself, but it seems good.)
The UnicodeMath spec itself proposed a reference parsing algorithm in Appendix A. However there are some conflicts in the UnicodeMath spec.
Conflicts and Decision
Spec-wise, this reference algorithm deviates from the spec:
Also, MS Word's implementation deviates from the reference:
Reference algorithm proposed by spec
← ‘||’ exp ‘||’
← ‘|’ exp ‘|’
The text was updated successfully, but these errors were encountered: