tikz support [was: mathjax graphics]

[rhl-]

mathjax should support tikz graphics and animations!
tikz animations are javascript!!

[nthiery]

Support for tikz, even partial, would be a great addition indeed!

It would be particularly useful for viewing graphs (in combination
with dot2tex and graphviz) and other combinatorial objects in Sage, in
particular when they occur within larger formulas. See
http://wiki.sagemath.org/combinat/CoolPictures for some examples.

We would be happy to provide code samples and to participate to
alpha/beta testing.

  Nicolas (coordinator of Sage-Combinat: combinat.sagemath.org)

[huahaiy]

Vote for this one.

[Stryden]

👍

[pkra]

Thanks for the interest. We would love to have something like that but it would be a huge endeavor and really a separate library b/c tikz is very different from math-mode TeX/LaTeX.

There is a third party extension implementing much of xypic which you can access from the CDN.

[Lakedaemon]

If I remember correctly, Tikz has a system layer (in TeX) and most high level stuff is implemented as another layer on top of that, with different drivers for output.

With the level of TeX support mathJax has, would it be a huge endeavor to support Tikz's system layer for the svg driver ?
Most Tikz primitives should store data and/or write them to text, right ?

[dpvc]

With the level of TeX support mathJax has, would it be a huge endeavor to support Tikz's system layer for the svg driver ?

Yes.

Most Tikz primitives should store data and/or write them to text, right ?

I'm not sure I understand the question.

[jeremykentbgross]

I been doing some digging because of my own hypothetical use case and found some info possibly relevant to this thread, along with a few brainstorm ideas to add. If any parts are not seen as so relevant, my apologies in advance, this just seemed a likely appropriate place to brain dump some of my research results on this subject:

If I understand correctly from looking here: (https://www.ctan.org/pkg/pgf?lang=en) Tikz is built on PGF, and both are largely built with LaTeX macros. It looks like there is some C/C++ code and some LUA in the project source (https://www.ctan.org/tex-archive/graphics/pgf/base) but most of it looks to be tons of TeX files containing macros (https://www.ctan.org/tex-archive/graphics/pgf/base/tex).

If my admittedly limited understanding is correct (LaTeX, PSTricks, PGF and TIKS are all new to me as of about 48 hours ago) maybe all that would be needed is porting some of the LUA and C/C++ code to javascript (or maybe compiling them 'as is' for a Nodejs plugin?) and then the functionality could just be lifted from the TeX files in the original project.

Issues with this I can currently guess at are:

1. That the huge amount of TeX macros in the PGF project might take a long time to (pre?)process as there are many of them, and some of them look pretty large.

2. I don't think any of this stuff was originally built with real time rendering in mind, which might be a problem if Tikz/PGF in browser is then supposed to support real time changes. Seems there are also 3D rendering packages for these (like for visualizing volume integrals and much more, etc), but these are almost probably built with software rasterizing through TeX 2D drawing commands (admittedly this is a guess on my part). A web implementation would want to use WebGL if it was going to show real time changes, although even draws to a 2D canvas would presumably be faster than making SVG and the other current formats.

Just brainstorming here, but maybe some javascript regex could easily convert <LaTeX/PGF/TIKS/other...> scripts to a JSON parsable object array of interpret-able commands describing render calls to Canvas and/or WebGL. That might be relatively fast and get an initial implementation working. However it will not solve the obvious optimization problems when using existing macros for rendering 3D via 2D TeX/PGF that exist from the old-school packages. On the other hand, once the common existing Macros/Packages were identified, a WebGL implementation of them could come with the system or be plug-able side project spin-offs for the main system.

Anyway, just some thoughts after a couple days of pondering and researching the subject. Hopefully they help somebody or strike a new idea/approach for somebody reading.

[pkra]

Thanks for sharing your thoughts on this. Just a few points form our end, kind of a summary of what we (the MathJax team's) have encountered in discussions around this.

• Reach out to tikz's author.
  • As we've written in the past, the team does not have sufficient expertise to even consider re-implementing pgf/tikz. It solves a radically different problem than TeX math mode does so it doesn't fit into MathJax architecture at this time (which focuses entirely on math mode).
  • We had a meeting with Till Tantau a few months ago. He's great, he's interested in the problem of making tikz happen on the web; he lacks time / resources.
• Like TeX, pgf/tikz is tool for print layout. There will be many features that do not make sense on the web. (For example, referencing nodes outside the current picture, cf. section 16.13ff in the pgf manual.)
• if you only need server-side processing in nodejs, then perhaps building a latex bridge is the better choice (a generic one like https://www.npmjs.com/package/latex-file, or a specialized one like https://www.npmjs.com/package/flowtex). tikz already has a tex4ht driver that generates SVG.
  • of course you can also try to transpile all the things, cf. https://github.com/manuels/texlive.js.
• There are sufficiently good web-based tools for most tikz use cases. If you walk through the tutorial section of the tikz manual, it's hard to find something you don't have multiple options for already: for geometry, jsxgraph, geogebra, mathbox etc; for petri-nets, UML etc there is jointjs, js-sequence diagrams, jsplumb and many others; for graphs, bar, and pie charts there are a gazillion things out of the data visualization world. So, just like MathJax, one idea might be to look for a suitable subset of tikz and focus on high-quality conversion instead of faithful implementation. That is, use it as an API to generate code to feed into one of the major graphics libraries supports. Doing this for narrow tizk-based packages might also be an option (e.g. chemfig).

In any case, we're happy to help and share our knowledge. But MathJax does not have any plans (or resources) to pursue graphics at this time.

[shalec]

What about setting up a mathjax-based tikzjax?