Diagramming tool integrations? PlantUML, svgbob, graphviz, etc

I would find it very valuable to be able to include generated diagrams in pages generated by Zola. In the past I’ve happily made diagrams with svgbob, PlantUML, and (admittedly a bit less happily) graphviz.

I’d really love to define the diagram contents inline with my markdown, like these VSCode plugins support:



Similarly for svgbob, perhaps other formats?

Does this seem feasible to consider?


svgbob is a Rust library so it could happen, not so much for the other formats unless a Rust integration exists.

svgbob alone would be a huge win, IMO.


Woah, svgbob is really cool – thanks for clueing me in.

It would be pretty cool to encode the diagrams as plaintext in markdown files, and know either the .md file or the rendered .html would be readable and complete. However, it doesn’t seem like the most urgent inclusion. Who really needs to distribute their plaintext .md files?

like this, svgbob for markdown render

1 Like

Hi, I’m using https://mermaid-js.github.io/mermaid/#/

1 Like

I logged in this forum just to ask about svgbob support, so yes, it would be wonderful

I’m also interested in some species of integration with diagramming tools. My goal would be to have Mermaid (or hypothetically some other diagramming language) rendered to SVG in the output HTML, using a configurable local tool rather than an external web service.

To avoid creating actual dependencies between Zola and external tools, what I had in mind was:

  1. Allow Zola to be configured to pass code blocks with a specific fence (e.g., ```mermaid`) to a shortcode.
  2. Allow shortcodes to call local executables, in much the same way they can make HTTP calls.

So in config.toml something like

code_fence_shortcodes = {
    fence = "mermaid", shortcode = "process_mermaid"

and then in process_mermaid.html something like

{% set data = load_data(command="mmdc --input -", stdin=body %}

{{ data | safe }}

An alternate approach might be to just declare the executable in config.toml and have Zola run it directly, but it seems like a natural extension point for shortcodes and an opportunity to support more complex manipulation.

I’d be interested in working on implementing this or a better idea towards the same goal, if it’d be accepted.

@keats Do you have any thoughts on the above proposal?

A potential first step could be to just allow load_data() to call an executable, which could then allow users to write shortcodes to process Mermaid and other diagram notation without using code fences. I don’t like that quite as much because it diminishes the ability of authoring tools to show previews, but it’s a smaller code intervention.

Not a huge fan tbh. It’s hard to integrate external tools in Zola since there are so many different cases:

  • run before zola
  • run on each zola serve, sometimes only if file changes match some glob
  • run once and reuse results in all template rendering
  • run everytime on markdown changes
  • run after zola is done building

In general i don’t like external cmd calls during a zola run