[Bug] Mermaid rendering: lines cross boxes

[alexpGH]

Description

The mermaid rendering draws line through boxes.

Environment

• OS: Debian
• Ferrite version: 0.2.6-hotfix1
• Rust version:
• Installation method: pre-built binary

Steps to Reproduce

1. add the following code and see preview:

graph TD
    linkStyle default interpolate basis
    A[Enter Chart Definition] --> B(Preview)
    B --> C{decide}
    C --> D[Keep]
    C --> E[Edit Definition]
    E --> B
    D --> F[Save Image and Code]
    F --> B

Loading

flowchart TD
    A[Christmas] -->|Get money| B(Go shopping)
    B --> C{Let me think}
    C -->|One| D[Laptop]
    C -->|Two| E[iPhone]
    C -->|Three| F[fa:fa-car Car]

Loading

[alexpGH]

Mermaid live and github renders the same, while Ferrite renders differently (I think you do actually not use themermaid library?) and produces an a bit awkward look.

[OlaProeis]

Good catch, and you're absolutely right - we don't use the Mermaid JS library. Ferrite has its own native Mermaid renderer built from scratch in Rust (using egui's drawing primitives), which means we're essentially reimplementing the layout and rendering logic ourselves. The upside is zero JavaScript dependencies and it works offline; the downside is exactly what you're seeing - our edge routing isn't as sophisticated as the official Mermaid library yet.

Specifically, the issue here is with edge routing. Our current implementation uses fairly simple path calculation that doesn't account for node bounding boxes when routing edges, so lines can cross through nodes instead of going around them. The Sugiyama-based layout algorithm we use handles vertical layering, but the edge path routing between layers needs improvement.

This is a known limitation we're actively working to improve. The fix involves implementing proper edge-node collision avoidance in the rendering pass. It's on the roadmap but I don't have an ETA yet since the edge routing logic is non-trivial to get right.

Thanks for the detailed examples and screenshots - they're great test cases for when we work on this!

[meden]

Hello, I'm totally new to the project, and not even a Rust programmer, so pardon me if I say nonsense.

Did you consider to use an external library to render Mermaid? E.g. mmdr. It can be used as a library, and it produces SVGs, which I guess can be directly rendered in the preview, somehow.

[OlaProeis]

Hello @meden
Not a nonsense question at all,

We're aware of mmdr now, but it didn't exist when we started building our Mermaid renderer. Our mermaid module shipped in Ferrite v0.2.5 on January 16, 2026, mmdr's first release (v0.1.0) was published to crates.io a week later on January 23rd. So this was a case of parallel independent work rather than an oversight.

That said, we've looked into whether it makes sense to switch, and the architecture is fundamentally different in a way that makes it a poor fit for our use case:

• Ferrite renders directly to egui primitives, our render_mermaid_diagram() draws natively into egui's immediate-mode UI. Diagrams automatically respect the current theme (dark/light), font settings, and integrate into the layout system with no intermediate steps.
• mmdr outputs SVG strings, to use it in Ferrite, we'd need an additional SVG→egui translation pipeline (either parsing SVG into draw commands or rasterizing to a texture). This adds complexity and we'd lose the native theme integration and interactivity potential.

mmdr is impressive work (23 diagram types, incredible performance vs mermaid-cli), but since we don't need to render to SVG/PNG, we need to paint into an egui panel, the performance characteristics that make mmdr shine (eliminating browser overhead) aren't really relevant here. We already have zero browser overhead since we parse and render natively.

What we may explore in the future is using mmdr's parser for broader Mermaid syntax coverage while keeping our own egui rendering layer. But for now, our approach of direct egui rendering is the right fit for an embedded editor preview.

Thanks for the suggestion, it's always good to know what's available in the ecosystem!

[meden]

Thanks for the explanation, and indeed my actual question was why you choose for an in-house development: it is quite clear from the quality of your work that you did a proper analysis... 🙂

mmdr outputs SVG strings, to use it in Ferrite, we'd need an additional SVG→egui translation pipeline

Understandable. I read about an egui_extras crate, though, which may be useful to overcome this limitation. I hope it may be useful.

In any case, thanks for your effort!

[OlaProeis]

@meden
Thanks for the kind words! And good find on egui_extras, it does have SVG support via image loaders (egui_extras::install_image_loaders() + resvg), so the pipeline would be:

mmdr renders SVG string → resvg rasterizes to bitmap → load as egui texture → display as image

This is a viable quick path for basic previewing, but it wouldn't work for where we're heading. One of our planned features is drag-to-reposition nodes directly in the rendered view, you'd grab a node, move it, and Ferrite would write position hints back into the Mermaid source (e.g. %% @pos node_id x y). That requires diagrams to be native egui widgets with individual hit-testing per node, not opaque bitmap images.

That said, we've added an evaluation of mmdr's parser to our v0.3.0 roadmap, their syntax coverage (23 diagram types!) is impressive. We've also opened an issue with the mmdr author to discuss potential collaboration on making the parser/IR reusable for alternative rendering backends. Fingers crossed!

Thanks again for pointing us in this direction!