The speed of KaTeX is great, but the lack of support for diagrams (a la tikz-cd) is what makes KaTeX unsuitable for general adoption by mathematicians (e.g., mathoverflow.net and all online mathematical wikis I know use MathJax). KaTeX has some rudimentary support for diagrams though the {CD} environment, but something more fully fledged akin to tizk-cd or xymatrix is needed. There's been some discussion on their github (https://github.com/KaTeX/KaTeX/issues/219), but I wouldn't hold my breath.
Would you consider adding a web font with the proper OpenType features to render the MathML content? The Igalia work in Chrome is quite decent when the font is good, but for now it needs to be set via CSS (presumably Chrome does not feel like bundling a math font just yet).
This is amazing. Probably the final nail in the coffin of MathML; what’s the point of a non-human readable intermediary language that other higher-level languages get compiled to, that only works in certain browsers (and with browser-dependent rendering/implementation), when you can instead write directly in LaTeX and have KaTeX work identically everywhere?
MathML support in Chrome has been greatly enhanced just in January [1].
I don't have strong opinions, but I guess the advantage over TeX is, as always, that MathML is much better integrated with the web stack and markup such that you can target math formulas using CSS, that it has much better accessibility, internationalization, and search, that you can use JS/DOM access with MathML for educational and science presentation apps, etc.
It's not like TeX is uncontroversially better (eg Turing completeness, terse, lacking editor support, print-oriented, purely presentational, ...)
Edit: arguably MathML is excessive as well but at least its XMLism such as insistence on enclosing every operand in tags as the primary source of bloat and incomprehensibility in presentational math can be somewhat mitigated using SGML, as was already suggested with MathML's precursor in 1995 or so [2] for high school math and/or custom math fragments.
I don't understand MathML's intent; likely because I have a different design mentality or model.
I like to represent things like this in 3 forms:
#1: Rendered notation for reading; what all these tools produce for people reading the document
#2: A clean, well-documented API for writing. This is the Latex, Mathjax, katex syntax etc, replete with backslashes.
#3: A representation in a computing language used to create the rendered form from the API. Depends on the language, but ie something like a set of structs and enums that can be manipulated by a compiler.
MathML is none of these; it's neither readable, nor writable, nor manipulable natively by a programming language.
Think of MathML like SVG. It is a target language which browsers understand. With SVG you can write it in hand, but most likely you are gonna use a special editor (Inkscape) or a library (d3).
With MathML you can write your equations e.g. in libreOffice or pick a library like MathJax or TeXZilla.
In fact I wrote a library my self which compiles a AsciiMath derived language to MathML, it was my first time writing a compiler, and it was an absolute joy targeting MathML. The mapping between DOM nodes and XML nodes is a perfect fit for the web as it allows my to implement DOM as a direct target (`mathup(expression).toString()` vs. `mathup(expression).toDOM()` and even `mathup(expression).updateDOM(parentNode)`.
The documentation for MathML on MDN if fine actually, good enough for me to write a compiler. The structure of the language is much easier to compile to than LaTeX by nature of actually having a standard (as opposed to an implementation which functions as a standard).
MathML is a unique fit for what it was intended to do, which is a targeting language which browsers understand.
MathML is not just for presentation. It encodes a lot of semantic information that Latex leaves out, and that information can be useful for accessibility, computer algebra system interoperability, etc. That said, I don't think it's used much for those things. I had really high hopes for MathML when it was first announced, but the poor browser support and consequential lack of use has been really disappointing.
Marking up the semantic structure of all your mathematical formulas is about as likely as marking up the parse tree and parts of speech for all your regular prose sentences. Presentational MathML is the only thing that matters; Semantic MathML is W3C semantic web wank.
The first hit in Google for "latex mathml converter" is https://temml.org/ . The list of supported LaTeX constructs looks fine, but the output… The example LaTeX converts to 67 lines of MathML. The vectors (arrows above B, l, E) are built like this:
Markdown is great, but I can always take the HTML produced by a Markdown→HTML converter and edit it by hand, since HTML is human-readable and human-editable. MathML is neither.
The output of MathML is also uglier than KaTeX’s, with wonky spacing. In Firefox, there’s an ugly space after all \d's (derivative sign). It’s better in Edgium, but there is still an ugly space in \d\vec{l}.
If I need an intermediary tooling/format for math, I’d prefer beautiful LaTeX-esque output, and keep LaTeX code that wold be converted by KaTeX on the fly to whatever ugly HTML is required.
I guess <mover> is semantic enough, actually? Though I don't get why the engine doesn't just know to render the arrow appropriately and it needs all those <mo stretchy> things with inline styling.
> Presentational MathML is the only thing that matters; Semantic MathML is W3C semantic web wank.
No. There are situations where a semantic interpretation is beneficial. A simple example is ‘(x + y) / z’. The best rendering (inline or full line) depends on the context.
People can discuss the tradeoffs without exaggerations and calling names. Let’s try.
That's a presentational consideration, whether you want a fraction that can stretch into {a \over b} or shrink into a/b, or if it always stays a/b.
Semantics means whether the / denotes eg division of real numbers or a group quotient. Semantic MathML basically wants you to provide a URI pointing to the definition of / you are using, eg. http://www.openmath.org/cd/arith1#divide. This is nonsense and about as likely as getting humans to mark up every word in your sentences with a URL for the numbered dictionary definition of the word you are using.
Could you clarify (dare I say markup) which sense of 'nonsense' do you mean?
1. spoken or written words that have no meaning or make no sense: he was talking absolute nonsense.
2. foolish or unacceptable behavior: put a stop to that nonsense, will you?
I'm not trying to just be pedantic: driving out ambiguity has value; even more so in mathematics.
Whether a particular technical suggestion for reducing ambiguity seems practical to you is quite different from it being understandable from some point of view and/or having internal consistency; i.e. making sense.
Let's move away from squishy, vague notions comparing semantic math markup vs English markup. Let's talk about some objective differences:
* "who": audience: mathematicians appreciate and deal in formality orders of magnitude more than English-speakers in general (perhaps second only to lawyers and grammar teachers?)
* "what": First, dictionary size: 1600 in OpenMath vs ~600K English words.
* "how": For a particular math document, it is likely that each operators used tends to have a common semantic. So it would make sense to state a mapping from certain operators to their semantics up-front and reuse these definitions throughout the document. See the bottom of this comment for some ideas on how this might be done.
* "why" : computability / reasoning: If mathematical is sufficiently formalized, it can be reasoned over very effectively, limited only by the computational algorithms. Reasoning over English sentences is fraught because English is frightfully ambiguous.
Conclusion: the 'who', 'what', and 'why' differ substantially.
P.S. Regarding the "how" discussion, here is a conversation with ChatGPT 4.0:
> In Semantic MathML, what mechanisms (if any) exist so that one math document does not have to restate the semantics of a particular operator repeatedly?
> "In Semantic MathML, use the <csymbol> element and Content Dictionaries (CDs) to avoid restating the semantics of an operator multiple times in a document. The <csymbol> element refers to an operator in a CD, which provides the operator's semantics. This way, you can reuse the operator without redefining its semantics in the document."
> Please double check this.
> Apologies for the confusion earlier. In Semantic MathML, there isn't a built-in mechanism to globally define the semantics of an operator for the entire document. However, you can use XML entities to create a shorthand reference for operators, and their semantics can be defined using the <apply> and <ci> elements, which encapsulate the semantic content. This will help reduce redundancy while still preserving the semantics of the operators throughout the document.
I'll spare you the rest of the chat log; the syntax is not pretty.
Semantic MathML is not useful. Consider a simple statement like
> Given any positive integers r and k, there is some number N such that if the integers {1, 2, ..., N} are colored, each with one of r different colors, then there are at least k integers in arithmetic progression whose elements are of the same color.
The majority of the semantics of this statement are part of the prose. Even having perfect "semantic" information about the formulas gets you absolutely nothing. You cannot reason about this without being able to reason about human language in general like a human can, in which case you do not need the "machine-readable semantics" of MathML at all.
The division of math into "ambiguous" English and "formal" formulae/symbolism is semantically artificial. Both of these are human languages. There is not some fully marked up form which is mechanically unambiguous that you can produce if you try hard enough. Presentationally the distinction is that special typesetting facilities are needed for the appearance of mathematical formulae and this is why presentational MathML is useful, but the semantics flow from the same source that the semantics of all written language flow from. It is not fundamentally different than, say, an Egyptologist who requires special facilities to typeset hieroglyphics.
>> Given any positive integers r and k, there is some number N such that if the integers {1, 2, ..., N} are colored, each with one of r different colors, then there are at least k integers in arithmetic progression whose elements are of the same color.
> The majority of the semantics of this statement are part of the prose.
The semantics can be expressed as prose if you like. They can also be expressed formally. As you know, 'color' is used here for the convenience of the reader. The underlying semantics works independently of the English notion of 'color'. You know this. What do you think is not formalizable about your example? "Given / assume": no problem. Introducing variables: no problem. Specifying variable types: no problem. Various mathematical structures (sets, sequences): no problem. "there are / there exits": no problem. "at least": no problem. And so on.
> Even having perfect "semantic" information about the formulas gets you absolutely nothing.
You have shared some good counterarguments, and I appreciate it, but "nothing" is an exaggeration here. It doesn't advance your argument.
> You cannot reason about this without being able to reason about human language in general like a human can
This is incorrect. You sound knowledgeable about mathematics, so I'm quite surprised you would make such a claim. Are your emotions (perhaps a loathing of Semantic MathML? -- your comments suggest this story) clouding your logic here? Deductive reasoning is well studied in computer science. To state a previous point again: there are many formal systems that can be reasoned over to various degrees. Such systems are still useful and quite different than English.
Earlier, you said it was both nonsense and unlikely to ever work. Now you say it is not useful. You are moving the goal posts. Your comments have had a mix of thoughtful examples (thanks) with some exaggeration and rant. I'm trying to tease these apart, but it isn't easy. I can see you have a strong negative reaction to Semantic MathML, but so far, your writing hasn't been persuasive.
I understand the parent's sentiment though. Every few years when I need to use Tex for something it always take me a second to remember that it is not a computer algebra system, just a rendering engine hyper focused on rendering 2D math notation that predates web rendering engines by about two decades. For some reason it surprises me that CSS did not grow to eat the publication rendering use case. I get that Tex has solved that problem quite well, but it seems like the sheer number of people who used CSS would mean that those capabilities would be ported to the language. But no, didn't happen. So we still have the two rendering languages.
> as likely as marking up the parse tree and parts of speech for all your regular prose sentences
That sounds completely doable with modern NLP like GPT-4. Maybe we should start doing more design experiments with how one could exploit such semantics? There's no reason to think that syntax-free writing ought to be ideal, any more than space-free and punctuation-free writing was the ideal form of writing which could not be improved...
Yes it does, so there's no reason to mark it up. The failure of the semantic web was trying to lower human text to the level the machine could operate on it. The success of LLMs is to raise the machine to level it can operate on ordinary human text.
You mark it up with the LLM so you can do something with it. A LLM like GPT-4 is still just emitting text tokens, it's not also generating pixels to push to your monitor. If you want to do something involving semantics like part-of-speech tagging, you'd obviously use the LLM to parse & annotate it, and then do stuff like use CSS to style nouns differently from verbs, or whatever. Maybe you don't distribute that, but run it locally, but you still have to do that at some point!
> Marking up the semantic structure of all your mathematical formulas is about as likely as marking up the parse tree and parts of speech for all your regular prose sentences.
No. The semantics of math are simpler than English prose.
My above comment may not be useful or interesting. I'm not complaining; rather, I'm seeking feedback. Is there a strong substantive argument against what I said? I'm happy to be proven wrong, or to be shown that I'm missing the point. Learning and seeing a new point of view is more enjoyable that pointing out weak argumentation. I push back to see if there is any there there.
To the substance: If one wants to argue that Semantic MathML ("SMML") will not be adopted, one would need to define a metric. Then we can model and forecast. I don't think the parent poster nor I have the time or interest to do this. I'll leave this heady analysis to the mysterious proprietary commercialized no-one-gets-fired wisdom of the Gartner Magic Quadrant [1].
Now we shift to utility. To argue SMML is not useful, you have to explain the costs and benefits of specific aspects.
* Of course markup has cost, but what are they specifically? It depends on many things, but the key ones seem to be the format/markup itself and tooling to help with it. Hopefully we can steer clear of holy wars here (aka the semantic analogue of the tabs versus spaces forever-war).
* And what are the benefits? I see three intertwined benefits: driving out ambiguity, easier categorization, and improved reasoning. Reasoning over mathematics can help find mistakes, prove theorems, connect previously disparate proofs and even fields, and lots more.
I haven't seen a convincing argument against the value of such benefits, other than arguing against their likelihood. But the latter seems hollow; such benefits can and do happen with human minds reasoning over mathematics. It is clear that computers can assist, at the very least, and perhaps even lead. I'm inclined to think that AI can scale up mathematical reasoning beyond human capabilities, even if the AI is quite far from human intelligence.
One might argue impossibility of one purported benefit of reasoning. Of course, this is downstream of the for what question, above. In sibling threads, I see what seems to be a false equivalence between formalization of mathematics and English. That argument seems to imply that formalization is "too costly" or "too difficult" or possibly even impossible. It offers shallow dismissals of the benefits at best. In summary, it doesn't make a convincing cost versus benefits argument.
That's better, but it generates a lot of markup, causing the sites to be very heavy (several megabytes). I know this because I'm using pre-rendered KaTeX to write my school notes, see for example: https://kmlinux.fjfi.cvut.cz/~blazead5/school/difr/ Notice that the page takes a while to load, even though it's mostly text.
I have tried out a few readers, none I tried so far support it in satisfying quality comparable to what katex would deliver. Maybe koreader is an exception, but I doubt it. Will give it a try at some point.
You're comparing real world working implementations based on mathml with your hopeful expectations of how you wish katex could work in an epub implementation.
It's good to have hopes and dreams and a positive outlook, but your perceived solution does not exist. It's hardly relevant to present it as a better alternative.
I have no need for real-world implementations that do not work as well as I need them to work. KaTeX is proof that math can be displayed properly in a browser-like environment. Anything less will not do it, at least for me. That's why I have exclusively PDFs in my digital library, except for books that are just text, like fiction.
No hopes and dreams needed, just use PDF. But making epub work properly for math is not a problem in principle, just make katex work in an epub reader, problem solved.
And people who are satisfied with substandard solutions are actually part of the problem, not the solution.
And that's one reason why the majority of ebooks purchased by consumers aren't in epub format.[1]
For the vast majority of fiction a format constrained to bold, italicize, paragraph break, chapter heading, and chapter break allows a far superior user experience.
JavaScript isn't a necessary component of ePub readers. Besides a handful of apps like Adobe Digital Editions and Apple iBooks, most don't. Kobo doesn't in their eReaders. JavaScript is only used in ePubs for multimedia crap. Fiction ePubs don't bother either.
Kindle books generally start their life as ePubs that Amazon then converts to their formats before they list them. They don't even let you publish in mobi anymore.
Kindle's lack of MathML support actually makes the user experience worse for everyone. Publishers often make 1 ePub they submit to multiple stores so rather than make a MathML version and a shitty image version for Kindle they just make a shitty image version and now you have a math textbook that's larger than the PDF would have been AND the equation text isn't resizable defeating the whole point of a reflowable ebook.
> Kindle books generally start their life as ePubs that Amazon then converts to their formats before they list them. They don't even let you publish in mobi anymore.
Morally speaking they start as Kindle ePubs that support a very very limited subset of the ePub standard.
If you need it to be pixel-perfect it will probably disappoint, yes. It's good enough for the few times I have made use of it. (It's also open-source, so you can always contribute improvements)
Never understood that need to contribute to open-source. Why would I try to meddle with somebody else's messed up implementation? I have enough messes of my own to clean up!
> Unfortunately MathML doesn't get you proper typesetting in epubs (...)
Wrong. MathML is a part of the Epub3 specification. All e-reader implementations that comply with the epub3 specs get you proper typesetting in books published in epub3 format.
I guess it is you that is living in a dream world. There are no epub3 compliant implementations then, because none of them display math properly. If they were compliant, they would also run KaTeX just fine, because Javascript and HTML are part of the standard, too.
> I guess it is you that is living in a dream world. There are no epub3 compliant implementations then, because none of them display math properly.
To start off, you already have posts in this very discussion rejecting your misconception.
Secondly, mathml works fine when we have an epub3 reader opening a epub3 doc created by epub3 generators from epub3+mathml input. If any of those requirements aren't met, you get issues. This happens with each and every single typesetting feature, not just mathml. Would you claim that epub fails to support tables if you open an epub doc with broken tables?
Thirdly, a typical implementation shortcut taken by epub readers is to reuse whatever WebView they pick. If your epub reader uses an outdated or shitty WebView implementation, you get shitty epub docs.
I am not that familiar with MathML, but I can imagine programmatically manipulate math expressions with MathML; can TeX math expressions be manipulated in the same way?
It is fast, I was previously using mathjax, and for a significant document I had to wait for a few seconds until the formulas were parsed and rendered. For the same document with katex, everything happens in less than a second.
I love the websites like katex.org - so useful while being static. If you take a look under the cover, you'll find that the website is built using Docusaurus - yet another cool project. So so useful. I want to live in the Web like that, without SEO noise, ads, cookie popups and all that nonsense.
Personally this is what I call Web 3.0 - fast, useful, mostly static websites.
I really like Katex. I used to use MathJax for my blog, but the page reflow was annoying. Now I use Katex with server-side rendering, and even pages with a lot of math load quickly and without reflow.
This is a bold claim. In theory any library that defers rendering to MathML should be faster (including my own MathUp https://runarberg.github.io/mathup/). Has anyone run benchmarks to test this claim?
Nice! I hadn't heard of this. I have a plainly coded blog that uses math notation. MathJax was previously the speed limfac. I replaced the mathjax script with the ones recommended on the Katex installation page; drop-in replacement.
This is also a great aid to learing LaTex. I wonder if anyone has ever tried to make an OCR system that generates the appropriate LaTex from an picture of an equation?
KeenWrite can produce web pages from Markdown with the TeX commands included as either as plain TeX macros (usable by JavaScript TeX renderers) or as pre-rendered SVG elements (no JavaScript required).
I am working on a project that needs to put latex in a browser. We are currently trying out different libraries, but so far Katex does seem the fastest.
If by "this" you mean "no reflowing", yes. If the maths is laid out client-side at run time, the exact dimensions of the formula are not known until the Latex code is interpreted.
Thanks. I was hoping there was a way to manipulate the DOM on the client before it is rendered, but this seems to be impossible with JS. Currently, I render various things during page load with NodeObserver. It mostly performs well on modern devices, but it can get sluggish on very large HTML pages (like 5MB+ of HTML code), so it looks like I have to resort to infinite scrolling with automatic unloading.
Its pretty much lingua franca for type setting mathematical formula. In my experience most math graduates already know it from typesetting their own work for assessment submission or publication.
It is the lingua franca for type setting mathematical formula. It doesn't make it good. ASCIImath is easier to write, and easier to read in plain text, for example in e-mails (/reddit/HN/fb/discord/whatever people use).
MathJax for example eats ASCIImath, I don't know if KaTeX can do that.
I would be really surprised to hear of a single undergrad math major hitting 300-level math without learning at least the basics of LaTeX syntax. For better or worse, TeX is to math what SQL is to databases. It might be old and have some serious challenges surrounding it, but it’s managed to remain better than anything that’s tried to dethrone it. I can remember how mysterious all the backslashes looked when I first started working with TeX in 1986, but they quickly disappear into the background.
Honestly, I don't see any difference in difficulty between LaTeX's syntax and Asciimath's one. The former has more backslashes and curly braces where the latter uses spaces and parens.
I personally find LaTeX easier to read because I immediately recognize that a curly brace is not part of the formula but just of its representation, while with Asciimath I'm left to guess if a parenthesis was put just to group a subexpression or if it carries a mathematical meaning. For example:
\frac{abc}{def}
It's clearly "abc" over "def".
(abc)/(def)
Is the numerator "abc" or "(abc)"? Parentheses often do matter: does the following describe a derivative of order 2n or a power?
Hey, shameless plug. I actually wrote a language derived from AsciiMath trying to fix some of these. I use spaces heavily to derive intentions meaning you can write stuff like:
It makes typing simple equations very simple, and if it gets complicated I could always write more explicitly/fall back to latex syntax which it parses as well.
It's kinda similar to the philosophy of Markdown -- make simple things easy and allow an escape hatch for when you need to be unambiguous.
Well\believe\it\or\not,\people\usually\read\text\separated\by spaces\rather\than\backslashes. Wouldn't it make sense to carry that over into a programming and markup languages as well? There's no point in redefining something so ubiquitous unless you have a damn good reason for it, or you're just inflating the learning curve. That goes for all language rules.
You seem to misunderstand the use of \ in LaTeX. It's not a separator, it's used to introduce a keyword.
Everything stems from the need to tell apart the text from the non-textual information, or structure. For example you don't add phrases like "the next word in italics" to mark parts of the document, because the reader will not understand if those are part of the text. Instead you must use either symbols that one wouldn't find in the text, like "*", or well-marked keywords, like "\em" or "<b>". Markdown prefers symbols, which look prettier for pure text, but unfortunately in maths nearly all symbols are already taken. LaTeX opted for keywords and chose a leading "\" to mark them, plus some rarely used symbols like "{" for grouping.
Asciimath uses neither uncommon symbols nor well-marked keywords, but rather words like "int" and common symbols like "(". I find it really confusing. In this way if you read "int", you don't immediately know if it stands for an integral sign or a function called "int" or the product of 3 variables called "i", "n", and "t". And when you find a pair of parentheses you don't know if they are part of the formula or if they were added just to group a subexpression.
I think this is called in-band signaling.
Asciimath does have some good points, though. The use of " to mark elements that must rendered as text and not maths is simple and effective. I tend to use it quite often for things like e (2.72), i (imaginary unit), d (differential) that are not variables and thus should be rendered with an upright roman font, not slanted or italics. LaTeX is worse because it forces you to write {\rm i} or \text{i}.
In my experience, LaTeX has the advantage of being able to handle even very complex documents and books. LaTeX can be challenging to master, but in return it can produce amazing results. See some of the references below. In particular take a look at [4] (it's a 1200 page LaTeX document) and consider if it could be written in Markdown and Asciimath. The hundreds of graphics appearing in [4] are also produced by LaTeX--the document is the manual for pgf/TikZ a popular graphic package that is itself a set of LaTeX macros.
In my experience of writing my BSc thesis in it, it's an absolute trainwreck to work with, especially with Overleaf. Takes forever to compile, won't ever give you a single useful error message, as for Tikz I'd much rather make a proper svg in literally anything else and then import it.
One can also produce amazing results programming in assembly, but I sure as fuck ain't doing that for anything I actually need to get done.
Being able to render latex super fast is very important for us as we use it for live tutoring.
Shameless plug: We currently offer 2 free tutoring for Fractions and Calculus. Perfect to revise or even learn those topics. The cool thing is, Amy will find knowledge gaps from previous years/subjects as well. (No account need to try it out)
