TikZJax: Embedding LaTeX Drawings in HTML(tikzjax.com) |
TikZJax: Embedding LaTeX Drawings in HTML(tikzjax.com) |
> Using web2js, the Pascal source of tex is compiled to WebAssembly; the latex format is loaded (without all the hyphenation data), and [...] is executed. Then core is dumped; the resulting core is compressed, and by reloading the dumped core in the browser, it is possible to very quickly get to a point where TikZ can be executed. By using an SVG driver for PGF along with dvi2html, the DVI output is converted to an SVG.
This is the kind of hack I'm here for.
But maybe for a coding audience https://www.youtube.com/watch?v=MVtlD22Y8SQ is more entertaining.
Overall, I'm impressed by how seamlessly it works when it does work. But it's not perfect:
- Some core library functions (for example, most types of fill patterns) simply don't work or aren't implemented for some reason.
- There are a few long-standing bugs. For instance, if using the intersections library to compute the intersection of a line and a circle, it straight-up crashes the entire TikZJax process. Intersections of two lines or two circles are fine, but circle+line fails. My attempts at diagnosing this seem to indicate that it's running out of stack space, so maybe the original TikZ code uses some inefficient recursive algorithm to compute this intersection, and this exceeds some stack size limit that the WebAssembly version introduces. I'm not sure and I haven't been able to get much traction.
- The project doesn't seem to get any love from the original developers anymore. I've filed multiple bugs for months now that never get any form of acknowledgement.
- The build process is pretty convoluted and difficult to reproduce (to try to fix those aforementioned bugs myself), which I guess is what you'd expect from a project that attempts to cross-compile a 20-year-old macro package for a 50-year-old Pascal codebase for rendering in the browser.
Overall I'm very glad TikZJax exists and there's still no better-looking and convenient-to-author diagramming language than TikZ itself. But there's definitely rough edges.
I need to get back to this project! I'd very much like to clean up the build process.
This is the one that was shared on lobsters, but there are likely more: https://bill-ion.github.io/tikzjax-live/
It’s also notoriously fragile and non-portable on native targets; I’m curious how one implements it under webassembly, and how it compares.
It came as a bit of a shock at the time that all the Unix-y systems had no such native concept, and that fragile, non-portable user-space schemes were required to mimic this functionality.
I'm endlessly distracted by other things at work, but I believe this same idea could also be used to provide real-time compilation of TeX'd documents as they're typed. Simon Rubinstein-Salzedo had suggested wanting something like a real-time Overleaf to teach his classes at https://eulercircle.com/ Interrupting and resurrecting the TeX-in-the-browser would let you render a document as it is typed.
But it notably lacks tikz support and if it can emit SVGs I'm beginning to wonder why I even use KaTeX and not something like this (beyond my personal anti-JS sentiment)
I love tikz, but lightweight it is not; it’s not a huge surprise it takes a few seconds to render.
No idea what’s causing the crash, though.
I could just as easily say that Safari shouldn’t be blamed for a buggy website, but I’d be overreaching just as much as you just did.
It may have security implications, or it may not. It might just be an innocent case of someone using assertions instead of proper error reporting. Nevertheless it's a bug in the browser.
I hate this trend of hiding error messages from the user. Apple as a company known for its attention to detail in UI, should have been the one company especially dedicated to presenting a good error message without overwhelming the user with technical details—it is supposed to be the master in user communication. And it is not. Hence my disappointment.