quintu5 17 hours ago

One major downside of native rendering is the lack of layout consistency if you’re editing natively and then sharing anywhere else where the diagram will be rendered by mermaid.js.

  • bananaboy 16 hours ago

    Yes that's true. For my use-case I want to render the diagram out to a png though and embed it in a confluence page.

    • OlaProis 14 hours ago

      This is a perfect use case! The v0.3.0 crate will have: - parse() → AST - layout() → positioned elements - render_svg() → SVG string - render_png() → via resvg (no browser needed)

      CLI usage would be something like:

      mermaid-rs diagram.mmd -o diagram.png> # or pipe from stdin> cat diagram.mmd | mermaid-rs --format svg > output.svg>

      For your mark integration, you'd be able to call it as a subprocess or use it as a Rust library directly if you're building in Rust.

      If you want to follow progress or have input on the API, feel free to open an issue on the repo!

OlaProis 16 hours ago

Valid point! Native rendering won't be pixel-perfect with mermaid.js. The trade-off is speed and no JS runtime. For documents staying in Ferrite, it's great. For sharing, we're adding SVG export in v0.3.0 so you can use mermaid.js for final renders if needed.