Rudolf Adamkovič <salu...@me.com> writes: > Hello smart people! > > With all the talk about Emacs 29, I figured we should update Org Mode to > use MathJax 3, to catch up with the rest of the world. > > From the documentation (for MathJax 3.0 released in 2019): > >> Version 3.0 of MathJax is a complete rewrite of MathJax from the >> ground up, and its usage and configuration is significantly different >> from that of MathJax version 2. > > In practice, MathJax 3.2 renders mathematics faster and better, plus it > significantly improves LaTeX support. For instance, one can typeset > calculus with the built-in (!) 'physics' package, like in LaTeX. > > More information on the recent progress (made in 2019-2021): > > https://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.html > https://docs.mathjax.org/en/latest/upgrading/whats-new-3.1.html > https://docs.mathjax.org/en/latest/upgrading/whats-new-3.2.html
Thanks a lot for this patch! > See the attached [working, but WIP] patch. > > My question for you: > > How do we change the 'org-html-mathjax-options'? > > - 'scale' has now the value in [0, 1] and not in [0, 100] > - 'scale' should exist as a number and not string > - 'font' did not make it to MathJax 3 [*] > - 'linebreaks' did not make it to MathJax 3 [*] > - 'autonumber' has the values in lowercase now > - 'autonumber' became 'tags' in MathJax terminology > > [*] coming in MathJax 4, currently in alpha > > How does Org mode approach these kind of breaking changes? The general rule is "do not break working Org files" or backwards compatibility in other words. See https://bzg.fr/en/the-software-maintainers-pledge/ In particular, it means that the existing #+HTML_MATHJAX options should not be broken when a user uses default value of org-html-mathjax-options and org-html-mathjax-template. WRT this patch, we can employ two different approaches: 1. Keep old Mathjax as default, but add MathJax 3 to customization options and parse the other options depending on the MathJax version in the :path. 2. Change the defaults to MathJax 3. Then, we will also need to make sure that incompatible option syntax in historic Org files does not break the export. The option (1) is easy. We just need to choose two different sets of options in custom interface for org-html-mathjax-options and org-html-mathjax-template. The in-buffer options will then be parsed depending on the :path. The option (2) will make Org export nicer by default, but more tricky to implement. In (2), all the aspects of (1) should still be retained. But in addition, you will also need to detect option values incompatible with MathJax 3 during export. If there is mismatch between the option format and the MathJax version, (a) try to convert the options, which should be possible e.g. for scale and autonumber. (b) if conversion is not possible (say, the options contain font setting), throw a warning and fallback to compatible MathJax version. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>