Jim Fowler seemed like Calculus' biggest hype man when the MOOC ball was just starting to roll. If you're looking to brush up and like the more energetic/engaging style I'd recommend checking out his videos on YouTube or elsewhere.
> 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.
Thanks for the recommendation, this is really cool!
apetresc 8 days ago [-]
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.
kisonecat 7 days ago [-]
As the author of TikZJax, I can certainly apologize for not making more progress on this.
I need to get back to this project! I'd very much like to clean up the build process.
steventhedev 8 days ago [-]
Apparently there are some forks that offer more features and fix some of those bugs. Maybe one of those can help you?
It’s also notoriously fragile and non-portable on native targets; I’m curious how one implements it under webassembly, and how it compares.
drfuchs 8 days ago [-]
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.
kisonecat 7 days ago [-]
Resurrecting this workflow was one of the funniest things in implementing TikZJax.
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.
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.
steventhedev 7 days ago [-]
I'm fond of using KaTeX for my personal blog posts. There is support for server side rendering for KaTeX (but not on GitHub pages because it necessarily opens it to arbitrary code execution - I asked).
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)
Garlef 8 days ago [-]
Hm. Either that page or the tech itself is not great on mobile.
ano-ther 8 days ago [-]
Takes a second or so to load on mine (iOS Safari). But then it shows correctly, even if the second diagram is a bit small (it fits in a quarter of the 1in circle).
frumplestlatz 8 days ago [-]
It crashes (“a problem repeatedly occurred”) a few seconds after loading everything on my device (also iOS Safari).
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.
kccqzy 8 days ago [-]
Well iOS Safari is in general buggy and tends to display the "a problem repeatedly occurred" message on many other slightly heavy web pages. This web page shouldn't be blamed for causing Safari to crash.
frumplestlatz 8 days ago [-]
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.
kccqzy 8 days ago [-]
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.
Jaxan 8 days ago [-]
It doesn’t crash, but tells me there is a problem. To me,this seems like a safe way to deal with buggy websites.
frumplestlatz 8 days ago [-]
Safari will terminate a page for using excess resources with the same message.
kccqzy 8 days ago [-]
So? Still Safari's problem for not displaying a proper error message.
frumplestlatz 8 days ago [-]
Sounds like you just dislike Safari. Doesn’t seem to be much help here.
kccqzy 7 days ago [-]
No. Safari chose the exact wrong way to handle this case. Let's suppose some webpage is in fact allocating too much memory. It is the user agent's job to inform the user of this fact. What does Safari do? It silently crashes. It's not even about displaying the wrong error message here: the handler for the crash is to simply refresh the page and render it again. But this is exactly the wrong way to handle out-of-memory errors: chances are the web page will again allocate too much memory and crash yet again. In the end the final displayed error message is "a problem repeatedly occurred" with no reference to the nature of the problem.
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.
revskill 8 days ago [-]
The author does not have an iphone to test.
klabetron 7 days ago [-]
Holy smokes. That’s a name I haven’t heard in a while. I submitted many calculus homework assignments in LaTeX because Jim introduced it to me back at our high school. (Go Mankato West Scarlets!)
kisonecat 7 days ago [-]
Matt Klaber?! If so, great to run into you!
I mean, I'm guessing from "klabetron"... Unfortunately I don't think my "kisonecat" gives much clue to "Fowler".
klabetron 5 days ago [-]
lol yep
ycombinatrix 7 days ago [-]
this looks cool. i guess i would generally prefer to do the SVG rendering on the server rather than on the client.
unit149 8 days ago [-]
[dead]
Rendered at 19:00:02 GMT+0000 (Coordinated Universal Time) with Vercel.
> 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.
I mean, I'm guessing from "klabetron"... Unfortunately I don't think my "kisonecat" gives much clue to "Fowler".