I appreciate the author's goal of not requiring readers' browsers to run Javascript to render the mathematics. The tradeoffs between images, SVG, and MathML are also unfortunately as stated.

Note though that another option is to use MathJax or KaTeX at build time (e.g. as preprocessing or postprocessing to the Hugo build here), to generate a static page that does not require Javascript to render.

MathJax: https://docs.mathjax.org/en/latest/server/start.html

KaTeX: https://katex.org/docs/api#server-side-rendering-or-renderin...

Hey all--the author here.

I just want to clarify one thing that I didn't think to mention (but probably should have) in the article itself. I went out of my way to use eqn specifically because I wanted to use that particular tool here. I write LaTex a lot on a day to day basis, and wanted to play around with something else. So this wasn't a case of picking eqn because I thought it was the best tool for the job.

Hmm, looks like https://savannah.gnu.org/bugs/?40720 is just lengthy explanations of how the unicode issues are hard to fix in the current code base; savannah doesn't seem to have bug search, but I didn't see any more specific tickets for the other unicode problems mentioned. (On a whim, I tried eqn -T MathML -d'«»' but it failed in a goofy but unsurprising way.)

I use KaTex (https://katex.org/) as part of static site generation, and I get LaTeX quality output (because it duplicates LaTeX's algorithm) using only CSS.

Using the eqn and troff suite in 2025 ... I'll just say there's a better way. LaTeX is arcane enough, but at least it is a universal standard in mathematical publication that it pays off to learn a little.

Considering the requirements, perhaps a LaTeX static site generator would have been a good fit.

I guess that authoring in MathML, and rendering MathML into images for browsers that do not support it, would have helped to avoid the mentioned inconsistency.