I’ve been working on zigraph, a modular DAG layout engine. It started as a port of my rust library ascii-dag, but has evolved into something more ambitious i.e. graph layout layout infrastructure where each component can be used independently
Currently supports: Sugiyama layout (Median Heuristic, Barycenter) with Brandes-Kopf positioning
output supported are internal IR, terminal, SVG, JSON
BYOA (Bring your own Algorithm) - trying to be modular as much as I can
This is 0.2.0. Next version will remove addEdge() in favour of addDiEdge and add addUnDiEdge for better understanding. FDG uses Q16.16 by default for calculation for determinism but can be changed as per need. FDG may not be as polished as Sugiyama layout. Next 3-4 version will be breaking in terms of DX and IR. I’m trying to front load architectural changes so that later things become stabilized for users.
Next version will be about, renderer modularity and subgraph support.
At that point you could parse and render dot, which would be pretty handy, a remarkable number of tools emit it.
I’m sure you’re well aware! Consider this a vote for dot input. “ports” and compass points can feasibly be ignored, or handled later, they’re treated more like requests than commands by graphViz.
Thank you for the compliment!
To be honest, I did think about .dot file. I will support it as a secondary file input. .dot file is good and widely adopted but has limitations. I was thinking to create a new DSL for this but after probably around or after 0.6.0.
Because parsing dot is tricky and it forces users to choose a graph type (you can do mixed but it is clanky). I was thinking in terms of supporting graph as mixed by default. I am aware of the pipeline like Sugiyama depends on direction would need special handling. But designing this custom flat DSL is little far.
Out of Ports and Compass point support, I might support port, given my aim is to have custom node shape in svg renderer.
That said I did think about things, but let’s see how execution happens.
That’s very much what I meant, just for the convenience of how many tools are already equipped to create it. The most useful subset for that purpose is mostly what you already have, plus subgraphs.
So a policy of “parse but ignore” would go pretty far, add attributes as they come up, assume that structurally valid .dot is semantically correct, because if it’s from a tool it will be. Doesn’t need all 3,111,696 arrow shapes.
In any case
Always, I’m sure you’ll take the project in the direction which makes the most sense to you.
I’m trying to create reproducible graph layouts across all the environments zig supports. But f32/f64 are deterministic only in same platform, same execution model. they are not deterministic across platforms, since graphs are iterative these small differences accumulate over iterations and can lead to very different outcomes. So I am favoring bit-for-bit determinism here. It does have its own drawbacks.