mermaid VS graphviz

MermaidJS

Another solution which I prefer is - maintaining diagrams as code which live in the same repos as the code. There are many tools these days which help us author diagrams from code. My favorites are Mermaid and PlantUML. Now your code can live in the repo and evolve along with the codebase. You might need to do additional setup if you'd like the diagrams to be generated as part of your CI/CD. I like to maintain these in a /docs folder within the project repo.

Individual diagrams have their grammar in a .jison file.

Flowchart: https://github.com/mermaid-js/mermaid/blob/develop/packages/...

A single grammar to support all the different use cases would be challenging. But we did have some plans to introduce guidelines to make different diagram syntaxes more consistent.

This would really be a good UX improvement.

But the implementation might be a little tricky.

Please raise an issue so we can discuss further, and add it to roadmap if feasible.

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

This is so cool. It reminds me of Markdown and Mermaid (https://github.com/mermaid-js/mermaid), which can do a similar thing within a plain text file. Keep it up; looking forward to trying it out.

KeenWrite[0], the FOSS Markdown text editor I’ve been working on, includes the ability to render plain text diagrams via Kroki[1]†. See the screenshots[2] for examples. Here’s a sample Markdown document that was typeset[3] using ConTeXt[4] (and an early version of the Solare[5] theme).

One reason I developed KeenWrite was to use variables inside of plain text diagrams. In the genealogy diagram, when any character name (that’s within the diagram) is updated, the diagram regenerates automatically. (The variables are defined in an external YAML file, allowing for integration with build pipelines.)

Version 3.x containerizes the typesetting system, which greatly simplifies the installation instructions that allow typesetting Markdown into PDF files. It also opens the door to moving Kroki into the container so that diagram descriptions aren’t pushed over the Internet to be rendered.

†Kroki, ergo KeenWrite, supports BlockDiag (BlockDiag, SeqDiag, ActDiag, NwDiag, PacketDiag, RackDiag), BPMN, Bytefield, C4 (with PlantUML), Ditaa, Erd, Excalidraw, GraphViz, Nomnoml, Pikchr, PlantUML, Structurizr, SvgBob, UMLet, Vega, Vega-Lite, and WaveDrom.

Note that Mermaid diagrams generate non-conforming SVG[6], so they don’t render outside of web browsers. There is work being done to address[7] this problem.

[0]: https://github.com/DaveJarvis/keenwrite

[1]: https://kroki.io/

[2]: https://github.com/DaveJarvis/keenwrite/blob/main/docs/scree...

[3]: https://pdfhost.io/v/4FeAGGasj_SepiSolar_Highlevel_Software_...

[4]: https://wiki.contextgarden.net/Main_Page

[5]: https://github.com/DaveJarvis/keenwrite-themes/

[6]: https://github.com/mermaid-js/mermaid/issues/2485

[7]: https://github.com/yuzutech/kroki/issues/1410

Useful resources: GitHub repository Package size: 24.9 MB License: MIT

Or, this one: https://github.com/mermaid-js/mermaid

That's interesting. It's not hard to see the problem. HTML labels don't help, either. How do other languages solve this? Like, a shell HERE document that has one fixed string as a terminator? The graphviz lexer https://gitlab.com/graphviz/graphviz/-/blob/main/lib/cgraph/... seems hackable but disabling downstream processing of escapes elsewhere would be necessary too. Possibly this would mean bypassing some of the processing in the function make_label in https://gitlab.com/graphviz/graphviz/-/blob/main/lib/common/...

It's a disappointment or even failure of our current language scanning and parsing tools or, really, the way we used them, that this is not an easy exercise.

If you have bug fix or enhancement requests, try https://gitlab.com/graphviz/graphviz/-/issues?scope=all&stat...

"Very poor" seems harsh, but, yes, it hurts us, too. (That, and text with slightly-off baselines.)

The relevant code starts around https://gitlab.com/graphviz/graphviz/-/blob/main/lib/common/... If this isn't right, maybe somebody can figure out why. Perhaps the loop stops sometimes on the wrong side of the boundary? Anyway, it's equally possible that when the endpoint coord is handed off to a lower level driver, the arrowhead mitering is wrong. There is no question there was once upon time explicit code to try to cope with this problem, at least in the native PSgen, but I can't find it now. Maybe it wore away as waves of open source development washed over it, along with static tables for a bunch of "standard" PS fonts.

For more background, see for example https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/s...

In the worst case, this has to be debugged for all the drivers in https://gitlab.com/graphviz/graphviz/-/tree/main/plugin

No doubt there are more details if anyone can remember them.

Diagrams as Code based on graphviz; for prototyping cloud system architectures