Start moving AsciiMath to native #1420
Conversation
Update readme for v4
MathJax v4.1.0 release
Running Tests on Windows
Still need to look over the legacy optable and apply that if needed
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1420 +/- ##
===========================================
- Coverage 86.54% 86.51% -0.03%
===========================================
Files 340 340
Lines 85993 85993
Branches 4837 3184 -1653
===========================================
- Hits 74422 74397 -25
- Misses 11548 11596 +48
+ Partials 23 0 -23 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…onalSymbols Allow configuring decimalsign and displaystyle in the mathjax config. Also add a new additionalSymbols to replace the old hacky startup method of using MathJax.InputJax.AsciiMath.newsymbol() in startup. additionalSymbols is an array of new symbols in the same object format as before, but with ttype as a string, since we don't have access to the enum values.
|
Made another commit to get the options working for decimalsign and displaystyle, and added a new one for additionalSymbols to add symbols in a less hacky way. |
Original asciimath used <mstyle> tag with mathvariant. MathML has deprecated that approach and prefers unicode, which MathJax output processor was handling automatically for the stuff asciimath wasn't. This change builds the mapping of characters to their unicode values internal to asciimath, and doesn't set any mathvariant.
|
And another change implementing alternate handling of font changes. Original asciimath used tag with mathvariant for font changes, with some limited character mapping. MathML has deprecated using mathvariant and prefers Unicode. The MathJax output processor was handling some of that automatically, but this change builds the mapping of characters to their Unicode values into the Asciimath parser, and doesn't use mstyle or mathvariant at all. |
|
David, thanks for putting the effort into making this PR. Moving Asciimath to a proper v3/v4 input jax has been at the back of my mind for a while, so I'm glad you have made this start. I have only had the chance to look briefly at the code, but it looks pretty good. I will have to look deeper, of course. I'm wondering about the relationship of this to the main AsciiMath codebase, and how it is to be kept in sync. one option you might consider is making a npm package that exports the needed parser and tables so that other javascript code (including MathJax) could call it. Then all the maintenance would be on the AsciiMath side, and MathJax could just be a consumer of that. Since you have already converted the code to Typescript for MathJax, you might consider using that for AsciiMath as well. What would allow you to compile to ES5 or ES6, for example (or both). In the past, keeping MathJax's AsciiMath input jax up-to-date with the AsciiMath repository meant copying changes from your repository into the slightly modified copy in MathJax, and that was fragile and not always done because of that. it wold be great if we could work out a mechanism were that wasn't necessary. We have an attachment like that with the mhchem parser, for example, which is not maintained by us, but we just link to the npm package version. |
|
I'm not sure how to do what you're suggesting, but I'm open to the idea :) |
3 participants
This is by no means a complete PR. I'm just making it to share the progress I made in case it might be useful, and to see whether it would be worth me spending any more time on this.
This is an attempt to start rewriting the AsciiMath input jax using MathJax 4 native methods, rather than needing the legacy shim. I've verified the MathML generated by this code (via
asciimath2mml) match the asciimath repo unit tests for expected output. This is obviously not super important or a priority, since the existing legacy method is working.Some things that still need work:
\mathbband other font change commands. It's not clear to me what the correct way to handle this is now, as it seems like MathJax has built-in mappings for these, but they didn't seem to work.