Feasability Study: Rendering TeX Math
Other platforms, notably the web, have support for rendering LaTeX math, or some subset of it. The utility of being able to do this is self-evident. This documents my (Charles) research on this topic, presenting several approaches that I do not feel are feasible, and one that I do. I hope it may prove as a useful jumping-off point for others (or myself) who want to do work in this space in the future.
Considered approaches:
- Call out to texlive
- Embed KaTeX or MathJax
- cLaTeXmath
- lasem
Based on my research, I believe the best approach of those considered would be to use lasem.
This approach would involve simply calling a LaTeX installation installed on the host system. This would guarantee compatibility and does not require FFI, however it would functionally preclude the use of TeX rendering on mobile as well as require the installation of an additional large program on the user's computer. Further, this approach is likely to have fairly high overhead for each equation compiled. Therefore, I do not believe this is a sensible approach.
go-latex provides a Go library which offers the relevant functionality.
KaTeX and MathJax represent the state of the art in from-scratch re-implementations of TeX math rendering. Both are written in JavaScript, and target the web. However, KaTex does not support SVG generation, and can instead only emit HTML+CSS, thus it can be eliminated from the running on this basis alone.
There are two implementations of JavaScript for Go: otto and goja. As MathJax supports running in NodeJS, one could in principle run it in one of these Go based JS interpreters. Though there may be some performance overhead, it would likely be much faster than calling out to an external program, and would allow TeX rendering to work on any platform supported by Go without requiring FFI.
I was not able to get MathJax to run under either Otto or Goja, even after bundling it into a single file and using Babel. Both implementations failed with syntax errors before even beginning to run the MathJax code. I do not have the background in JS to postulate on whether this could be fixed.
cLaTeXMath offers a C++17 implementation of a significant subset of TeX. C bindings could be written for this library, then accessed using CGo. While cLaTeX math appears to be a good solution on the surface, supporting SVG output would require implementing a new graphics interface in the upstream, or else embedding Skia or Cairo. Additionally, this approach would limit to support to only platforms with working C++17 compilers.
It is worth noting that the current version of cLaTeXMath may GPL projects which embed it, though the upstream is aware of this and has plans to address it.
The lasem project, a part of GNOME, offers a MathML renderer written in C, which embeds itex2mml to support TeX inputs. It has working support for SVG generation from either MathML or TeX. The fact that it is pure C means that writing additional shims shouldn't be needed, and CGo can be used directly.
itex2mml is abandoned, however mtex2mml offers a maintained fork.
It is worth noting that lasem is GPLv2 licensed, so it is not a candidate for embedding in core.
I believe that the most practical approach to implementing a TeX math widget in Fyne would be to create a widget either in fyne-x or it's own library (to avoid embedding GPLv2 in core) which embeds lasem via CGo which can in turn simply render the generated SVGs. This would have the bonus of also supporting MathML. This method would require relatively new code, just writing CGo bindings for lasem.