Thanks! TeX math support ($...$ and $$...$$) is planned for v0.4.0. We're going pure Rust (no JS runtimes), targeting common LaTeX syntax. See the planning doc on github (docs folder) for details.
I tried to add it for this release but hit a wall with the font rendering dependencies (freetype, fontconfig). GUI apps need these for text display, and they don't play well with fully static musl linking - the build system wants a musl C++ cross-compiler and static versions of system libraries that aren't readily available in CI.
We'll keep looking into options - possibly a Docker-based build with a proper musl toolchain, or investigating if we can make fontconfig use dlopen at runtime. For now the glibc build (Ubuntu 22.04) should run on most Linux distros.
If anyone has experience with static musl builds for Rust GUI apps, we'd love to hear what's worked!
WYSIWYG — This is where it gets nuanced. Ferrite has three modes:
- Rendered mode — Click-to-edit rendered Markdown (closest to WYSIWYG)
- Split view — Raw editor + live preview side-by-side
- Raw mode — Plain text editing
It's not pure "type and it formats inline" like Typora or Confluence. The Rendered mode lets you click elements to edit them, but it's not seamless WYSIWYG yet.
If you're looking for true inline WYSIWYG, Typora is probably closest. But if split view + rendered mode works for you, give Ferrite a try — it hits the other criteria well.
Interesting use case! Mermaid doesn't have native AWS icons, but for v0.3.0's standalone crate, we could potentially support custom shapes/icons. D2 has better icon support if you need that now.
What specific diagram types do you need — network topology, service flows, infrastructure layout?
You're right, neither Mermaid nor D2 really nail AWS architecture diagrams out of the box. Mermaid lacks icons entirely, and D2's AWS pack is more 'icons exist' than 'architecture patterns are easy.'
Honestly, this is a gap in the ecosystem. For now, most people either:
- Use draw.io/Excalidraw despite the pain
- Build diagrams programmatically (Diagrams-as-code Python library has good AWS support)
- Just accept text-based flowcharts without icons
If I add custom icon/shape support to Ferrite's Mermaid renderer (v0.3.0+), AWS icons could be a good test case. No promises, but I hear the frustration.
Good question! A few reasons for egui over gtk-rs/iced/others:
- Immediate mode — egui redraws every frame, which makes state management simpler (no callback hell). Great for prototyping.
- Pure Rust, minimal deps — egui is self-contained. gtk-rs requires GTK installed on the system.
- Cross-platform out of the box — Same code runs on Windows/Linux/macOS/Web
- Rapid iteration — Hot reload-friendly, easy to experiment with layouts
Trade-offs: egui's TextEdit isn't designed for code editors (no multi-cursor, can't hide folded text), which is why v0.3.0 will replace it with a custom widget.
This is my only public Rust repo — I have some ongoing private projects in Rust, so I'm familiar with the ecosystem (cargo, crates, the borrow checker experience, etc.).
That said, to be fully transparent: as I disclosed elsewhere in this thread, the Ferrite codebase is 100% AI-generated (Claude via Cursor). I direct the development, test, and iterate, but I haven't written the Rust by hand for this project.
So my Rust experience is more "ecosystem familiarity + reading AI-generated code" than "battle-hardened Rustacean." This project is partly a learning exercise — seeing how far AI-assisted development can go while picking up Rust patterns along the way.
LaTeX support is a reasonable request! It's not on the immediate roadmap, but here's my thinking:
Options considered:
- KaTeX/MathJax-style rendering (would need a Rust math renderer or JS bridge)
- Typst integration (Rust-native, modern alternative to LaTeX)
- External tool pipeline (render via pandoc/LaTeX CLI)
Typst is interesting since it's also Rust-based and simpler than full LaTeX. Would inline math ($x^2$) and display math ($$...$$) cover your use case, or do you need full document features?
Added to the roadmap consideration list. Thanks for the feedback!
Good to know! Inline + display math is a more tractable scope. Typst or a Rust KaTeX port could handle that without needing full LaTeX. Added to the consideration list with that clarification.
Currently Mermaid doesn't support manual positioning — the layout is algorithmic (Sugiyama-style for flowcharts). Some workarounds:
- Use subgraph blocks to cluster related nodes
- Adjust edge order in source to influence layout
- D2 (another diagram language) has better manual positioning
For v0.3.0's standalone crate, I'm considering whether to expose layout hints. What specific use case do you have — documentation, architecture diagrams?
Mostly clustering and sorting, but most importantly, I use diagrams not only as a tool for communication, but also as a tool to think visually. Moving boxes around would be a huge benefit for that use case, while I still want to have the diagram as code for version control etc pp
Actually, this is going on the v0.3.0 roadmap. I've been looking for ways to make the standalone mermaid-rs crate genuinely better than just 'mermaid.js but Rust.'
The plan: use %% comments as layout hints. Something like:
%% @pos NodeA 100 200>
Mermaid.js ignores these, so the diagram stays portable. But Ferrite (and anyone using mermaid-rs) could parse them for manual positioning.
You'd be able to drag nodes around in Ferrite, have positions saved to the source, and still share with mermaid.js users (they'd get auto-layout).
If you want to follow progress or have input on the syntax, feel free to open an issue on the repo!
The challenge is Mermaid is declarative — layout is computed, not specified. Some options I'm considering:
1. layout hints/constraints in the syntax,
2. export to SVG then use a proper editor like Excalidraw for repositioning. For now, influencing layout via subgraphs and edge ordering is the best workaround."
3. separate system for that, maybe to be included in the crate, would only work in Ferrite in the start
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!
reply