Pandoc developer here. Two comments: (1) to convert equations pandoc uses the texmath library, which I also wrote (https://github.com/jgm/texmath). Compiling texmath with `-fexecutable` will give you a standalone executable that just converts the equation (and doesn't add the `<p>` element or anything extraneous). Compiling it with `-fserver` will give you a webserver that converts equations. (2) Regarding the bug, note that it's not an empty `<mo></mo>`. There's an invisible U+2061 character ("function application") inside. We don't want to take that out, but it looks like putting the `<mi>` and the `<mo>` together in an `<mrow>` will also solve the problem. I'll fix this.
The limit formatting the author doesn’t like isn’t a bug in pandoc I don’t think - it looks to me as if they have just written it ambiguously in latex.
If you write a limit as \lim_{n \to \infty} etc etc then LaTex gets to decide whether to write your limit in inline style (next to the limit) or below. If you want it always to be below then you need to write
> If you write a limit as \lim_{n \to \infty} etc etc then LaTex gets to decide whether to write your limit in inline style (next to the limit) or below. If you want it always to be below then you need to write
In display mode, without modifications, LaTeX has no choice; `$$\lim_{n \to \infty}$$` in the default LaTeX compiler will always put `{n \to \infty}` below `\lim`, unless you or some package have monkeyed with things to change that default behavior. (In inline mode, similarly, $\lim_{n \to \infty}$ will by default always place `{n \to \infty}` as a subscript of `\lim`, unless you or some package have changed the default behavior.)
One problem I ran into a long time ago (2021) is that MathML was not well supported in Chrome and other browsers, but seemed well supported in Firefox.
After trying many Pandoc options [1] I ended up selecting a very small implementation by Preet [2] which was some ~70kB [3] compared to other implementations at about 10x (i.e. MathJax [4]). I use it with the Polyfill to check if it is already supported. If you checkout the torture test, it really performs quite well [5].
In the future I still want to convert to SVG vectors (with bitmap backups) and include those instead, but I'm not yet pleased with the offerings. My concern with JS is that it seems to be on the way out, I think it will eventually go the way of Flash in favour of something else.
With the current solutions for rendering equations you either have this ridiculous wrapper around LaTeX or similar, or some other weirdness. If I get bored for a few days I might end up writing a parser to convert MathML to such outputs. It shouldn't take insane efforts to pass some torture tests.
I love how Keyboard Maestro comes into play. Instead of some Markdown extension doing the conversion on render, the author selects and converts each equation manually. I think it's a good idea to keep MathML rather than LaTeX in Markdown source.
I have written an AutoHotkey script for my own use that does something similar, but for converting Markdown to HTML — so that I can write in Markdown, but fall back to embedded HTML easily if Markdown is not enough. Maybe I shall replace its pulldown_cmark backend with pandoc to get support for MathML.
Pandoc can be painful (mostly due to the complexity of all the tools it orchestrates in my opinion), but I find it very hard to beat once you get in non-trivial publishing territory and you refuse to use TeX/LaTeX-style processors.
The learning curve is worth it imo (if you often work on documents and publications).
The author's construction for a piecewise definition will work, but the preferred LaTeX construct is `\begin{cases} … \end{cases}`. (Actually, I think it's from AMSLaTeX.) I believe it always left aligns columns, and doesn't obey multiple `&`s, so it doesn't exactly reproduce the author's construction—but, from my point of view, that means that the specifics of the author's construction are not standard practice, at least within the domain of the AMS. Otherwise it would be formatted as
\[
f(x) = \begin{cases}
-1, & x < 0 \\
0, & x = 0 \\
1, & x > 0.
\end{cases}
\]
Pandoc developer here. Two comments: (1) to convert equations pandoc uses the texmath library, which I also wrote (https://github.com/jgm/texmath). Compiling texmath with `-fexecutable` will give you a standalone executable that just converts the equation (and doesn't add the `<p>` element or anything extraneous). Compiling it with `-fserver` will give you a webserver that converts equations. (2) Regarding the bug, note that it's not an empty `<mo></mo>`. There's an invisible U+2061 character ("function application") inside. We don't want to take that out, but it looks like putting the `<mi>` and the `<mo>` together in an `<mrow>` will also solve the problem. I'll fix this.
The limit formatting the author doesn’t like isn’t a bug in pandoc I don’t think - it looks to me as if they have just written it ambiguously in latex.
If you write a limit as \lim_{n \to \infty} etc etc then LaTex gets to decide whether to write your limit in inline style (next to the limit) or below. If you want it always to be below then you need to write
\lim\limits_{n \to \infty}
It’s the same deal with summations and integrals.
> If you write a limit as \lim_{n \to \infty} etc etc then LaTex gets to decide whether to write your limit in inline style (next to the limit) or below. If you want it always to be below then you need to write
In display mode, without modifications, LaTeX has no choice; `$$\lim_{n \to \infty}$$` in the default LaTeX compiler will always put `{n \to \infty}` below `\lim`, unless you or some package have monkeyed with things to change that default behavior. (In inline mode, similarly, $\lim_{n \to \infty}$ will by default always place `{n \to \infty}` as a subscript of `\lim`, unless you or some package have changed the default behavior.)
One problem I ran into a long time ago (2021) is that MathML was not well supported in Chrome and other browsers, but seemed well supported in Firefox.
After trying many Pandoc options [1] I ended up selecting a very small implementation by Preet [2] which was some ~70kB [3] compared to other implementations at about 10x (i.e. MathJax [4]). I use it with the Polyfill to check if it is already supported. If you checkout the torture test, it really performs quite well [5].
In the future I still want to convert to SVG vectors (with bitmap backups) and include those instead, but I'm not yet pleased with the offerings. My concern with JS is that it seems to be on the way out, I think it will eventually go the way of Flash in favour of something else.
With the current solutions for rendering equations you either have this ridiculous wrapper around LaTeX or similar, or some other weirdness. If I get bored for a few days I might end up writing a parser to convert MathML to such outputs. It shouldn't take insane efforts to pass some torture tests.
[1] https://coffeespace.org.uk/projects/mathml-render.html
[2] https://github.com/pshihn
[3] https://github.com/pshihn/math-ml
[4] https://www.mathjax.org/
[5] https://pshihn.github.io/math-ml/examples/torture.html
I love how Keyboard Maestro comes into play. Instead of some Markdown extension doing the conversion on render, the author selects and converts each equation manually. I think it's a good idea to keep MathML rather than LaTeX in Markdown source.
I have written an AutoHotkey script for my own use that does something similar, but for converting Markdown to HTML — so that I can write in Markdown, but fall back to embedded HTML easily if Markdown is not enough. Maybe I shall replace its pulldown_cmark backend with pandoc to get support for MathML.
GitHub has also switched to MathML recently (or I've just noticed it). It is a nice comeback.
From MathJax? Why, it's mature enough?
Anyone here know whether there are other converters too? I like Pandoc but find it not so nice to run in production. I don’t remember why though.
Pandoc can be painful (mostly due to the complexity of all the tools it orchestrates in my opinion), but I find it very hard to beat once you get in non-trivial publishing territory and you refuse to use TeX/LaTeX-style processors.
The learning curve is worth it imo (if you often work on documents and publications).
There is a list of conversion tools at https://www.w3.org/wiki/Math_Tools. Mine is at Temml.org.
The author's construction for a piecewise definition will work, but the preferred LaTeX construct is `\begin{cases} … \end{cases}`. (Actually, I think it's from AMSLaTeX.) I believe it always left aligns columns, and doesn't obey multiple `&`s, so it doesn't exactly reproduce the author's construction—but, from my point of view, that means that the specifics of the author's construction are not standard practice, at least within the domain of the AMS. Otherwise it would be formatted as