[karatestomp]

I'd rather have graphviz expose a kind of layout engine such that it can take the size each node will occupy (determined by whatever's going to draw them) and use that to create a layout, feeding path info to something that can handle the actual drawing, than have more drawing options in Graphviz itself. I think that doing so is (so far as I could tell, last time I tried) extremely awkward at best is why it's not embedded in basically everything that has any need whatsoever to draw graphs.

So, I guess:

> - it would be a big effort, but move the core algorithms to a framework that supports interaction with layout generation

If that's what you mean by that.

It'd make it way easier to pretty up Graphviz output. I'd rather have "renderer" applications that run on top of Graphviz and have Graphviz itself lose all but its most basic build-in drawing capabilities, than have more of that built into Graphviz itself.

[derefr]

One problem with this is that—at least in some Graphviz layout engines—"the size each node is going to occupy" is chosen to minimize the energy/stress of the graph, sort of like how line breaks on TeX pages are chosen to optimize for whole-page metrics.

For example, in a graph with only two nodes, where each node contains a long text string, there is no "pressure" on the nodes, so the default result might be to not break the text, creating two wide, short node-boxes, and then to arrange them with one above the other. Whereas if you have many such nodes in a densely-connected web, the text in them will likely be wrapped in order to make the nodes more box-shaped, so that nodes can fit between the cuts of the pairwise-acute spirograph-like edge lines.

In order to resolve this sort of layout, Graphviz has to understand a lot of things about fonts, padding, and borders (just like TeX does.) It's already doing "rendering" at that point, even if the result gets thrown away.

[Karliss]

I have used Graphviz that way. It wasn't too bad. The most annoying part was inconsistency in input and output units. Some properties expect values in pixels, some are in inches, and dpi for input and output are different with only one of them being configurable. Otherwise code was quite straight-forward: create context, create nodes, create edges, set attributes, run layout, read positions and edge path coordinates, do the cleanup.

[cm2187]

Doesn't the export to plain give you what you need in term of location and size of the different items?

https://graphviz.org/doc/info/output.html#d:plain

[karatestomp]

That doesn't let you tell graphviz how large you want to draw each node, right? Just how large graphviz would draw them? What I'd like is a way to take styling and drawing outside GraphViz. It's important (for what I'd like) that graphviz know how large each node is going to be so it can route around them. If you apply, say, a typeface or padding even very slightly different than what graphviz was using, or if there are just slight differences in, say, how a given browser renders a <div>, it could change the size of the rendered nodes, and you end up with edges drawn under/over nodes.

Much cleaner (and way more useful) to be able to tell graphviz "this is how large I need this node to be, and that one this size, and the other one such-and-such, and they are connected thusly, now please give me coords for a layout"

This isn't just for looks, either: if you want the resulting graph to be interactive, and perhaps even graphically (drag-n-drop) editable after the initial graphviz auto-arranging, you're probably wanting output that's not exactly in graphviz's wheelhouse. You want to tell it node sizes and have it tell you where to put them.

[cm2187]

I think you can have fixed size nodes where you can specify the dimensions.