# LaTeX for the web

07 August 2024

How can mathematical notation be accessible on the web?

If you're viewing this post in a web browser that handles SVG elements, chances are this probably looks pretty good:

But if you're looking at this in a feed reader like newsboat, which uses lynx to render the HTML content, then you're at the mercy of how well you can visualize LaTeX in your head. The same source is presented to both, but lynx foregoes displaying SVG elements, and instead sees the `<desc>`

tag in the SVG and displays that. The browser user enjoys the beautifully rendered equations as vector images, whilst the plain text content retains some of the meaning if the image cannot be drawn. But without the image, it's not ideal. If you're trying to go through this post with assistive technology, neither of those representations are going to be much use either.

Can we do better?

## Images, SVG, and the semantic web

The semantic web is a standardisation from W3C to give better contextual meaning to content we see on the web. It focuses on the intention of a word in a sentence, for example, and on annotating that word to disambiguate its significance. The word "*bolt*" in "*to bolt down*" or "*lightning bolt*" have entirely different semantics, and so we would annotate the word with extra meaning, conventionally with some kind of XML.

In HTML, a practical example of what this looks like might be the `alt`

descriptor in `<img>`

tags that fediverse users are rightfully very proud of. If the image cannot be displayed, or the reader is visually impaired, the alt text describes what would have been there, or better, what the meaning of the image is. When content has semantic meaning represented in a machine readable way, it lends itself to being understood and transformed quickly into different formats such that it minimizes loss or corruption of meaning. This is the basis of how and why assistive technology works, and why you can (almost) enjoy browsing the web in plain text.

HTML and XMLs generally have limitations but for describing the meaning of things it's got a lot going. With deliberate and parsimonious use of tags, you can give context to any specific element of a page, each link in a paragraph, every heading and its relation to the other headings, and so on. Because HTML is machine readable it can then be transformed into the web page you see, or into plain text, or even read out with meaningful pauses between sections. HTML used to be something we wrote by hand, but now it's all abstracted and generated for us, and to some extent, the result of this is that the modern web is a dense, dark forest of `div`

tags that serve very little to no purpose. Much of the semantic meaning of any given tag is lost.

Accessibility requires that those able are attentive and do a little something more. You have to go a short distance out of your way to write an `alt`

field, but that small effort might mean the difference between someone being able to enjoy your work, or being entirely excluded from it. If we focus on images, there are a great number of things someone posting an image can do to properly describe its content in sentences, but not necessarily in a way that has good semantics. If the semantic web has anything to do with information transform, then a paragraph describing a `.jpg`

image only goes so far in its ability to be transformed. To describe details you need to refer to them in relation to other details ("the cat is next to the cow"), or using concepts of direction ("top left is a frog, bottom right is a copy of the anarchist's cookbook"). You cannot interlace a description of the content within the image format.

SVG marries graphics with XML. It gives us a way to compose an image from simple geometry, and lets us annotate what those things are. Consider this example

```
<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
<circle cx="50" cy="50" r="40" fill="currentColor"/>
<circle cx="40" cy="60" r="5" fill="grey"/>
</svg>
```

That's two circles, that's what the tags say. If I only had an `.jpg`

image of this, that's all there would be.

```
<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
<title>Transit of Venus</title>
<desc>This image shows venus transiting in front of the Sun</desc>
<circle id="The Sun" cx="50" cy="50" r="40" fill="currentColor"/>
<circle id="Venus" cx="40" cy="60" r="5" fill="grey"/>
</svg>
```

This is an `alt`

descriptor *within* the image. But with SVG we can identify the specific components of the image in a deliberate manner, here using `id`

. A machine can read this and transform the image and its components. You could hide Venus, or turn the Sun orange, or adjust the scale of individual components, so that the *meaning* is accessible to you.

I recently learned that SVG supports an `<animate>`

tag which means we can even do something like this (if your browser is modern enough):

```
<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
<title>Transit of Venus</title>
<desc>This image shows venus transiting in front of the Sun</desc>
<circle id="The Sun" cx="50" cy="50" r="40" fill="currentColor"/>
<circle id="Venus" cx="40" cy="60" r="5" fill="grey">
<animate attributeName="cx" begin="0s" dur="8s" from="10" to="90" repeatCount="indefinite" id="The passage of time"/>
</circle>
</svg>
```

Even if that doesn't render for you, the machine readable description would allow an algorithm to transform it into a format other than an image that you could *understand*. It could describe it to you, without the need for visuals.

Annotating plots or graphics in this way is something I want to work on automating.

## Born of complexity

I've been adding a LaTeX renderer to my website, so it got me thinking about how mathematics is represented, both symbolically and on the web. I am avoiding JavaScript on my website due to the abhorrent complexities it presents for the low tech user, and as an experiment to learn about other technologies. Rendering mathematics for the web before the likes of MathJax and KaTeX went something like: compile it with a LaTeX compiler, then somehow turn that into an image, and `<img>`

tag it to load it. JavaScript has done wonders for mathematics, in that we can now ship the LaTeX code to the reader and let a sophisticated library compile and renderer it on their machine. But other things haven't changed much.

How can mathematics be presented so that if the symbols cannot be rendered it is still comprehensible?

How can mathematics be presented so that it is meaningful?

Mathematics is something that is only really well defined in some kind of written form. The ambiguity present in saying "x plus y squared" as or I think is illustrative, and the problem only gets worse when the equations get more complex. Furthermore we often understand equations *as images*: some of you may recognise the geodesic equation at the top of this post; the syntax may be different from what you have seen before, but the locations of the symbols on the page might be enough for you to recognise it. Mathematics, like scripture, must be rendered to be comprehensible. If you only see the LaTeX formula, you may know the geodesic equation, but you may not immediately recognise it. Mathematicians are good at looking for and finding patterns, so it is only natural that understanding the language requires the same skill. Some patterns are logically beautiful (Fourier theory, for example), this logical beauty is represented with mathematical symbols, and the resulting scripture can itself transcend its semantics and become something aesthetic. Some equations look beautiful when they are written down. Often, our first interaction with new mathematics is momentarily picturesque before we understand its meaning. Our first interactions are with the art of the script.

To semantically represent mathematics, LaTeX is poor. You might argue LaTeX isn't supposed to do semantics, it's for rendering equations. It's a drawing language. Like with `.jpg`

images, rendered LaTeX equations lack semantics. What is ? What is ? I wrote an `alt`

for the above image but it's difficult to describe what the operations are without the language sounding clunky. "*The change of the Langrangian with respect to the momentum, with respect to time, is equal to the change of the Lagrangian with respect to position*". Awful. How do I verbally differentiate the partial derivative from the full derivative? What exactly am I taking the time derivative of? How do I convey this information without writing the symbols, without drawing the picture? On top of that, the picture does not define *where* these derivatives are being taken, and bears no context for the symbols. Is it only the Euler-Lagrange equation because it looks like it? What does it mean for an equation to *be* the Euler-Lagrange equation?

Gerald Sussman spends some time talking about how the Euler-Lagrange equation illustrates what is wrong with symbolic mathematical notation. To quote from the preface of "Functional Differential Geometry":

[Mathematicians] are insufficiently precise to convey an idea to a person who does not share our culture.

I often misquote him as having said "*Mathematics is a fantastic language for understanding the universe, but mathematics is a terrible language for understanding mathematics*". I can't find where I thought he said that.

One thing that KaTeX, the JavaScript LaTeX rendering library, does really well is that it builds a MathML representation of the equations; a marriage of mathematics with XML.

To give an example of MathML, here's Euler's formula for planar graphs:

```
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mi>v</mi>
<mo>−</mo>
</mrow>
<mrow>
<mi>e</mi>
<mo>+</mo>
</mrow>
<mrow>
<mi>f</mi>
<mo>=</mo>
</mrow>
<mrow>
<mn>2</mn>
</mrow>
</math>
```

$v-e+f=2$
I'd not heard of MathML until I started looking at what KaTeX spits out. I read MathML has been around since 1998, supported on pretty much all browsers, and even partially in lynx. Now it's something I want to eventually add to my website generators as a fallback.

But generated MathML is for rendering. It does not know what you *are* doing, and, unless you are insert it by hand like with SVG, therefore cannot populate the markup with any semantic meaning. In the end it's effectively syntax highlighting.

Sussman's solution to ambiguity in mathematical notation is to use a functional programming language, in his case Scheme. The idea is a good one, as it removes much of the ambiguity, is machine readable, and can be transformed into other representations -- including transforming by evaluation to see what the mathematics is doing. It's appealing therefore also in its immediate pragmatism.

```
(define ((Lagrange-equations L) path)
(- (D (compose ((partial 2) L) (State path)))
(compose ((partial 1) L) (State path))))
```

Already this could be more useful than equivalent LaTeX or MathML representations. We could run symbolic variables through this expression, even for a specific realization of the Lagrangian, and render the resulting symbols. It's simpler to write than direclty writing XML. We can even have a compiler check that the expressions are valid, and can infer semantic meaning from the variable names.

Alternatively, we can translate the Scheme function to MathML directly, given the equivalence of S-expressions and XML. This could render the MathML and augment the tags with semantics from the function. It might be worth exploring that for myself as a way of generating more meaningful MathML expressions.

## The current server side LaTeX

I want to render mathematical expressions in the web in a way that is meaningful.

LaTeX is likely the most popular way of writing mathematics, but I am wondering whether it's the most useful.

My current solution starts with the tried and tested rendering an image from a LaTeX expression, and including it in the page. I'm using MicroTeX to transform LaTeX into font paths, which I then render as an SVG. I lose the text that generated the SVG since I am only drawing paths, not writing characters. My temporary solution to keep the text nearby is to include the LaTeX code that generated a given SVG in the `<desc>`

tag, which is what lets newsboat write the code when it cannot draw the graphic.

This was my first time doing anything with fonts and font rendering, and it has given me much appreciation for the complexities involved. By doing this myself, it gives me control over the parser and therefore lets me alter what the end transformation looks like, and what metadata and semantics I might be able to encode. One thing I am planning to add are equation titles to my modified Markdown parser, so that things like the `<title>`

and `<desc>`

field of the resulting SVG can be more meaningful. Imagine something like

```
```maths TITLE: ALT
EXPRESSION
```
```maths Pythagorean Theorem: relates the sides of a right-angled triangle.
a^2 + b^2 = c^2
```
```

You already know what the Pythagorean theorem *means* before someone tries to describe the equation to you. The context from the name is clear too; we think of triangles and trigonometry. That information is lost if you are just presented with .

Then, maybe, if none of the equation to could be realized, if the symbols can not be drawn, and there is no clear way to unambiguously read the expression, at least something stays behind that could be understood.