Add PGF/TikZ support

[rfdonnelly]

This change adds support for converting PGF/TikZ to JPEG, PDF, PNG, and SVG.

The user input is lightly pre-processed. If the user input contains a \docmentclass command, the user input is passed to latex untouched. Otherwise, a \documentclass command is derived from the output format and prepended to the user input then passed to latex.

The flow from here is as follows:

• For JPEG and PNG: Use latex to convert the user input to PDF. Then convert the PDF to JPEG or PNG using pdftocairo.
• For PDF: Use latex to convert the user input to PDF.
• For SVG: Use latex to convert the user input to DVI. Then convert the DVI to SVG using dvisvgm.

I also considered pdftocairo and pdf2svg to generate SVG. pdf2svg is no longer maintained and the author recommends pdftocairo over pdf2svg. dvisvgm was chosen over pdftocairo because of its superior text handling and smaller, better-optimized SVGs. dvisvgm has the ability to render text using fonts while pdftocairo converts text to paths. This allows text selection in browsers and enables smaller file sizes. In one case, pdftocairo produced a 1.4MB SVG while dvisvgm produced a 60KB SVG for the same image with little to no visible differences.

Closes #5

[rfdonnelly]

I resolved the merge conflict introduced by WireViz and fixed a misrender of the SVG periodic table example by upgrading dvisvgm.

This PR is ready to merge from my perspective. If there is anything else it needs from a project perspective, let me know at your convenience.

To render the periodic table example, I found that I needed to increase KROKI_MAX_URI_LENGTH to >= 5488.

[ggrossetie]

Awesome @rfdonnelly 👍🏻

To render the periodic table example, I found that I needed to increase KROKI_MAX_URI_LENGTH to >= 5488.

You can also use a POST request.

This PR is ready to merge from my perspective. If there is anything else it needs from a project perspective, let me know at your convenience.

I will carefully review your work next week 👀

[ggrossetie]

Hey @rfdonnelly!
I've rebased your branch on top of main (force push). Would you be able to build tikz against Ubuntu (instead of Alpine) since the gateway server is now based on Ubuntu. Hopefully, it will compile just fine on Ubuntu 🤞🏻
Thanks!

[rfdonnelly]

Hi @ggrossetie, I modified server/ops/docker/jdk11-jammy/Dockerfile to migrate TikZ support from Alpine to Ubuntu then rebased again to remove all references of Alpine from this branch and to resolve a new merge conflict introduce by the UMLet change on main. All other files remain unchanged from my previous push.

[ggrossetie]

Awesome, thanks 🎉

[rfdonnelly]

I'll update the docs in a subsequent PR.

[ggrossetie]

@rfdonnelly I just deployed a new version including tikz. I believe that some computations take more than a few seconds and as a result they exceed the default timeout of 5 seconds.

I tried to render https://tikz.net/nautilus/ and https://tikz.net/intersection/ but I get a timeout.

Maybe 5 seconds is a bit too aggressive but I don't want to increase it too much because the public instance is not meant to do "heavy" math computation.

What are your thoughts?

[rfdonnelly]

@ggrossetie very cool to see it deployed.

There are definitely some limitations with PGF/TikZ for Kroki. In particular, input size and processing time. For example, the https://tikz.net/periodic-table/ example exceeds the 4kB URI length limit and the computational heavy diagrams you found exceed the 5-second timeout. For what it's worth, https: //tikz.net/nautilus also times out on tikz.net when I try the "RUN LATEX HERE" button.

I think this is par for the course with PGF/TikZ due to the nature of the format. It is much less constrained than the more domain-specific diagrams-as-code languages. It allows complex diagrams to be created with low-level primitives and some computationally expensive logic.

IMHO these limitations are fine for the public Kroki instance. Bandwidth and CPU time aren't free after all. Even with these limitations, quite a bit can be done with PGF/TikZ.