Mathup: Easy MathML authoring tool with a quick to write syntax
mathup.xyz
mathup.xyz
I think Google's Chrome team's choices of priorities bear a significant portion of the blame for this. They refused to implement MathML for the longest time, and even when it was implemented, it was partly done and financed by a third party. Without MathML, LaTeX-to-HTML JavaScript hacks became the norm, solidifying LaTeX as the standard even for non-typesetting use cases. Had MathML been implemented by Chrome early on, a more direct and easier translation from something ASCII-like to MathML would likely have been adopted.
I want this to be the default (or at least an option) in all markdown text editors (obsidian, github, etc.) I mean, as an intermediate: in the end MathJax rendering is much prettier than plain MathML.
TeX's design was finalised in 1982, when the computational resources were different by a few orders of magnitude. There is a very strong culture of backward compatibility (search for "A torture test for TeX") and there are so many equations written in TeX documents that it would be impossible to change the parsing now.
That said, something like MathJax would be free to create their own TeX-like syntax where parentheses are automatically paired.
I for one often find myself wanting more control, writing `\bigr]` or `\biggr]` instead of `\right]` to get the rendered equation to look good.
> And while rendering `(a+b)/a` as a `\frac` is opinionated, honestly, the only reason why this occurs in my notes is when I was too lazy to type `\frac{}{}`.
Plain TeX has the much nicer syntax `{a+b \over a}` but for some obscure reason LaTeX recommends against that.
When your write LaTeX you maintain some structure for complex equations, while here you kind of take the quickest route possible and very quickly loose your footing in the equation’s complexity. In LaTeX you can very easily write out a very complex equation with nothing but your text editor, but here once you are maybe 6 or 7 terms deep you loose your place and will probably need to see a visual rendering to find your footing and continue. Mathup makes this problem worse than in AsciiMath proper, because in AsciiMath proper you are forced to at least parenthesize many of your sub-expressions, while here you are free to go wild with the whitespace.
The whitespace grouping is actually even more powerful than just for fractions, e.g. you can use it group terms around any infix (incl. sub- and superscripts) as well as after any prefix (such as sqrt): `e ^ -x^2/2 / sqrt 2pi` will give you the standard normal distribution. The rule is that if there is space between the operator and the operand it will operate on everything until the next applicable whitespace, the space between sqrt and 2pi applies the the sqrt prefix, and is not applicable to the fraction, but the space before slash is applicable to the ^ so the sqrt 2pi term are not apart of the superscript. I actually don’t recommend relying on this and just use parentheses for all but the simplest expressions (it is fine in sub-expressions though).
But like I said the target usecase is quick and easy expressions, so people that write a+b / c+d are favored over the ones that write `(e^(-(x^2)/2))/sqrt(2pi)` - but honestly I would write this as `e^(-(x^2)/2) / sqrt(2pi)`.
It's a great way to take content that's actually pretty humanly readable in the HTML, and translate it to an even better rendered format in the UI. It's good for progressive enhancement and framework support at the same time.
1: https://github.com/runarberg/markdown-it-mathblock
This space is pretty dominated by LaTeX whom almost all professionals use, but is pretty verbose and not exactly easy to use for beginners (or even non-frequent users). Other than LaTeX we have Office Math, which is a GUI, and AsciiMath. This tool is a dialect of AsciiMath[1] and builds on top of that. If you know AsciiMath, you know this. There is also UnicodeMathML[2], but that has another goal than this or AsciiMath, where the focus is on readability of authored expressions, rather than writability here.
On specific tools I've also liked https://www.imatheq.com/imatheq/com/imatheq/math-equation-ed... for quick casual use since it's just a webpage but still a decent GUI editor.
Some sort of keyboard only markup language for inputting complexe math calculation seem like something worthwhile at first glance. But then you realize that you still need some specialized keyboard keys (and/or macro) if you really want to have completely "inline" (single line).
But at the end you get something that's extremely unreadable and you find out that what's actually needed is computing software that both has a way to write and compute math as we used to on paper.
The 3D aspect is extremely important for comprehension/readability, the only time it makes sense to lay out the equation in some sort of inline markup is for rendering when it's part of a larger document compilation process. And plenty of people use Microsoft Word or some other sort of GUI to avoid even doing this...
Also, you realize that nowadays, pen tablets are extremely cheap and pen input is very simple, so what is really needed is the same type of software that exists on tablets to convert math pen input into formalized markup representation that the computer can understand (no need for the end user to see the underlying mechanics). And voilà, you can have math input without wasting too much time with a markup language.
Wait, really? Do you have good primary sources to back up that claim?
This is really no different from SVG. The design of the SVG markup language did not take considerations of people writing SVG images by hand, instead they designed the language to be a handy compiler target. Which it is, you can draw nice SVG images from a GUI like inkscape as well as nice graphs from a javascript library like d3.
1: https://developer.mozilla.org/en-US/docs/Web/MathML/Guides/A...
What I like about the typist math dialect is that they seem to go even further than me away from AsciiMath. I was a bit conservative in trying to follow AsciiMath (at least in the beginning).
EDTI: A link to typst math module - https://github.com/typst/typst/blob/main/crates/typst-librar...
p/s: It has nothing to do with Tex or Emacs, just a poor naming combination.
[1] Welcome to GNU TeXmacs:
mathup's tiny, clean API makes it easy to integrate the project in all sorts of processing workflows, both in-browser and scripting.
Aside, I love this expression that you landed on. The Gamma distribution is one of the reason I started writing this library 10 years ago. The way the original AsciiMath can’t have arbitrary identifiers (only texts) was a deal breaker for me. The Gamma distribution is a very nice showcase for capabilities of an authoring tool like this because the name is usually written using latin letters `Gamma` while its density function also includes the gamma function which is usually written with a greek capital gamma (Γ). In the original AsciiMath writing Gamma just gives you the greek letter. The gamma distribution is also just a very cool distribution, or rather it contains some very cool distributions (in particular the Chi-squared distribution).
Second difference is with supported MathML target output. Mathup is far more expressive (we even have tensor index notation in mathup). In mathup you can target your preferred MathML output in a way you can’t in AsciiMath. For example in mathup you can purposefully write any token element you want except <ms>. (`<mi>`, \`<mo>`, "<mtext>", and #`<mn>`), in AsciiMath if you want to wrote Gamma as an identifier (as opposed having it turn into the greek letter) or int as an operator (as opposed to an integral) you have to do it with <mtext>. Here you can do `Gamma` for <mi>Gamma</mi> or \int for <mo>int</mo>.
Thirdly is some differences in syntax. Most noticeable is matrix notation, in AsciiMath you write [(row, one), (row, two)], while in mathup you write [row, one; row, two]. Another major syntax difference is how whitespace works. In mathup you can group pars of your expression together with whitespace, so a+b / c+d is not the same as a + b/c + d. In AsciiMath, you have to use parenthesis to do this.
Maybe it's a server load issue.
Sorry, I should've taken a screenshot.
What might have happened is that your browser might have refreshed or something and loaded a different but the listener which reacts to the input changes (as well as page load) may have failed for an unknown reason.
I misrembered, the theta was in the (unrelated) rendered version.
No big deal, just some glitch.
Another missing feature which quite alot mobile users expect is jump to top. I personally never use it, but many mobile users do.
Code blocks also have kind of excessive margins, and I should probably shrink the font-size so that more users could read the entire thing without horizontal scrolling, though I think this is fairly minor.
Finally, what I can think of, is the content it self. I made the choice when writing the docs, to teach the reader a little about MathML as I demonstrate the project. I think this was a solid choice but it puts the simplest most unimpressive expressions at the top. On desktop this is fine because you can see more impressive expressions further down, but on mobile these are hidden in a horizontal scroll, so the user might be left unimpressed.