[random_i]

I was a big Mermaid fan, but no longer.

It is very difficult to save the images as bitmap (.jpeg, .mpng) or vector (.svg).

You basically have to use a headless browser rendering toolkit, and guess what? The images aren't consistent (different rendering styles).

I'm switching to Graphviz (DOT-based) which can look just as nice and has tons of file save features.

[sidharthv]

We are doing some fundamental changes to how diagrams are rendered, which would enable us to support more renderers. This will enable us to do server side rendering without a browser.

The main reason why we need a browser currently is size calculations of the SVG boxes, which libraries like jsdom does not support.

[teruakohatu]

Please don't take the, in my opinion, excessive criticism to heart. Mermaid is fantastic. It would be even better if it supported more renderers but as it stands to day its an invaluable tool.

[doublesocket]

FWIW I gave up trying to render SVG for our project and switched to using fabric.js (and node-canvas for server side rendering). For us it was mostly because it had far better text support.

[otherflavors]

PlantUML also has gantt chart (https://plantuml.com/gantt-diagram ) support. unfortunately does not scale below days. There is a chronology diagram(https://plantuml.com/chronology-diagram) available but not linked from the main documentation or documented very much at all. Though it looks like the correct diagram in plantuml for the data in OP is a timing diagram (https://plantuml.com/timing-diagram)

[strken]

I was going to point to https://github.com/mermaid-js/mermaid-cli, but it uses puppeteer and chromium under the hood. That seems...excessive, to render an SVG.

[mananaysiempre]

SVG is in a bit of an awkward place. It’s mostly used as a graphics file format. It actually is (when opened by a web browser) a full application environment, the nonreflowable counterpart to the reflowable HTML, or the open version of Flash with worse authoring tools: there’s support for full JavaScript, MathML, CSS, animations without CSS... You can probably stick RDFa somewhere in there too. And while XML is outwardly simple, I’ve heard an XML parser author say Adobe tools exporting SVGs like to define parsed entities in the internal DTD subset (did you know XML inherited a full textual macro system from SGML?).

There’s a reason why there’s SVG then there’s SVG Tiny then (recently, not approved by any standards process) there’s SVG Tiny PS. But as far as I can tell, there still isn’t any broad agreement on what subset of SVG is sane for dumb graphics consumed by (relatively) dumb rasterizers.

[arminiusreturns]

May I suggest my favorite: blockdiag (including seqdiag, nwdiag, and actdiag, and rackdiag (rackdiag super slept on!))

I've evaluated every diagrams-as-code tool in existence just about, and revisit them every year or two, and I keep coming back to blockdiag. Mermaid looked nice but had many issues I ran into.

blockdiag doesn't look as pretty out of the box, but when done right it looks really good, especially as an SVG

[el_oni]

I've been using d2 recently [0] It's similar enough to mermaid but with the CLI you can output svg and png and have some decent looking diagrams.

[0] https://d2lang.com/

[otikik]

When I have needed a static image I have just taken a screenshot. I would still put the mermaid code and style next to it in case future modifications were needed. Worked reasonably well.

[thangalin]

https://github.com/mermaid-js/mermaid/issues/2485

Mermaid diagrams do not render correctly using the following programs and libraries:

    Adobe FrameMaker 2020
    Apache Batik
    EchoSVG
    svgSalamander
    resvg
    rsvg-convert
    svglib
    prawn-svg
    CairoSVG
    ConTeXt
    QtSVG
    MS Word
    PlutoSVG

[mahdi7d1]

Graphviz is hard. I only need a graph making tool three or four times a year and when I go back to mermaid, only 5 minutes of going through the documentation get's me up to speed. But graphviz is much more complex in a way I often don't need. It's also pretty verbose; You first need to define nodes then the connections while in mermaid both are done in a single line.

However mermaid's experience and output is definitely subpar. Under the saved graphs section you find randomly saved graphs and there is no way to organize multiple graphs in the web editor.

I've even thought of writing a simple script to translate mermaid charts into dot language.

[Karliss]

You can define nodes and edges on the same line in graphviz. Here is an example: https://viz-js.com/?dot=ZGlncmFwaCB7CiAgYSAtPiBiIC0-IGMgLT4g... Of course depending on complexity of graph you might want to do it separately.

A potentially much bigger difference in verbosity comes from graphviz being a general purpose graph drawing software, while mermaid is more of a software for drawing software development related diagrams (not just graphs and tables). This is well reflected by the fact that in graphviz the diagram types are categorized by layout engine (hierarchical drawing, spring model, force directed placement, circular layout,...), but in Mermaid they are categorized by what data the diagram represents (flowchart, sequence diagram, class diagram, state diagram, entity relationship diagram, gant diagram). You can draw many of those types of diagrams in Graphviz but you will have to potentially do a lot more of reinventing the wheel and low level manual formatting (arrow and node shapes, line style, etc.), while Mermaid documentation uses more of diagram specific terms like cardinality, visibility(public, private, ...) and many others.

That's like comparing Excel with purpose built accounting software or an inventory management system. Excel might be a lot more flexible, but if the usecase specific software matches your needs it can be a lot more streamlined and less error prone.

So the conclusions will very much depend on your use case. If you are trying to draw one of the standard software engineering diagrams as part of design documentation, Mermaid can be great. For less formal design diagrams or quickly visualizing the state of some algorithm it's much more even playing field.

[prepend]

Comically, the way I save mermaid images are through screenshots.

But this is only if I need to put it in a paper or something as otherwise just point the user to the diagram in a browser.

It is still much better than any alternative I can think of.

[boomskats]

The thing that's problematic is rendering Mermaid SVGs outside of a browser environment - i.e. what static site generators need in order to generate JS-free HTML docs from Markdown content.

If you're looking at a rendered Mermaid diagram on your screen, you probably already have the SVG in your browser's dom. You can just right click -> view source -> find element -> view as html -> save that to a file. I expect this is how the SVG export on the Mermaid live editor[0] works.

(the Mermaid live editor is great, it's where I tend to go if I want an SVG export)

[0]:https://mermaid.live/

[breck]

I work on Scroll (https://scroll.pub), which currently compiles to HTML/TXT et cetera.

Compiling to JPG, SVG, PDF, MKV, MP4, et cetera, are high on my todo list, but I really haven't seen a standout way to do that, beyond that would run through Chromium.

I wonder if Ladybird (https://ladybird.org/) might be appropriate for that use case? Not sure if it's a new rendering engine or what.

[steve1977]

I don’t disagree, but aren’t we actually using kind of a headless browser rendering toolkit for SVG anyway?

[coldtea]

>It is very difficult to save the images as bitmap (.jpeg, .mpng) or vector (.svg)

Huh? It's quite trivial, and even some tools for VS Code and other environments support it.

>You basically have to use a headless browser rendering toolkit, and guess what? The images aren't consistent (different rendering styles)

Is your problem saving Mermaid as images or lamenting cross browser rendering consistency?

If it's the former, why is the latter a problem? Use a single headless browser rendering toolkit and stick with it. Who said you need to use multiple and compare?

And there are other ways to do it, like exporting from an actual in-browser render, or even a VS Code extension - it can also be found in other tools based on Electron.