Live data from Hacker News

TikZJax: Embedding LaTeX Drawings in HTML

tikzjax.com

11–20 of 33 posts

Re: TikZJax: Embedding LaTeX Drawings in HTML

#12

Using a “core dump” (dumping the webassembly heap) is an interesting optimization approach with historical precedent both in TeX itself and projects like Emacs (dump/unexec) — https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... It’s also notoriously fragile and non-portable on native targets; I’m curious how one implements it under webassembly, and how it compares.

Being able to start a process, have it run for a bit to, say, read in initialization data, populating dynamic data structures along the way, and then interrupt the process and save the whole state as a new executable, was a feature built into DEC’s Tops10 and Tops20 operating systems / standard runtimes, along with related custom systems like Waits, under which TeX was developed. It took just two lines of code for TeX to implement its side of this feature on those first platforms.

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.

Re: TikZJax: Embedding LaTeX Drawings in HTML

#13
Funny seeing this on the front page – I'm coding a project as I'm browsing this that makes heavy use of TikZJax.

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.

Re: TikZJax: Embedding LaTeX Drawings in HTML

#14
post #9

Earlier quoted context omitted.

By definition buggy websites that crash the browser are bugs in the browser. 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.

Safari will terminate a page for using excess resources with the same message.

So? Still Safari's problem for not displaying a proper error message.

Re: TikZJax: Embedding LaTeX Drawings in HTML

#16

Funny seeing this on the front page – I'm coding a project as I'm browsing this that makes heavy use of TikZJax. 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…

Apparently there are some forks that offer more features and fix some of those bugs. Maybe one of those can help you?

This is the one that was shared on lobsters, but there are likely more: https://bill-ion.github.io/tikzjax-live/

Re: TikZJax: Embedding LaTeX Drawings in HTML

#17
post #14

Earlier quoted context omitted.

Safari will terminate a page for using excess resources with the same message.

So? Still Safari's problem for not displaying a proper error message.

Sounds like you just dislike Safari. Doesn’t seem to be much help here.

Re: TikZJax: Embedding LaTeX Drawings in HTML

#19

While live rendering is nice, I suppose that generating static SVGs that are embedded in a static webpage generator are more fruitful for the typical case. A quick search yielded this: https://polbarrachina.com/2022/05/23/latex-and-tikz-in-jekyl...

In a wiki setting for example, it might be nice as it makes the direct human edition more accessible. Not as accessible as an embedded SVG editor of course. But still, compare how latex formula are used in Wikipedia, compared to mathml, or SVG.

Re: TikZJax: Embedding LaTeX Drawings in HTML

#20
post #9

Earlier quoted context omitted.

Nobody is assigning blame, we don’t know the root cause. 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.

By definition buggy websites that crash the browser are bugs in the browser. 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.

It doesn’t crash, but tells me there is a problem. To me,this seems like a safe way to deal with buggy websites.
Post reply on HN