That said, I have spent entirely too much time manually searching through the 100-odd dimensional Graphviz parameter space trying to get aesthetic results. So much time in fact that occasionally it's easier to fire up Omnigraph and draw the thing manually.

Graphviz would be ideal if it had some kind of meta-parameter settings that could reduce the tendency of its output to resemble an unreadable rats nest when the number of nodes exceeds about 20. I know that's part of the point of neato vs. dot, and that some parameters are effectively meta-parameters, but Graphviz still needs a better "porcelain" (in git-speak) with fewer dimensions.

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.

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.

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

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.

THANK YOU for making this wonderful program.

Also special thanks to the emscripten team for their wonderful transcompiler.

I am constantly amazed at all the WONDERFUL software that exists on unix as single threaded applications (required for emscriptem asm.js output). There could be a whole sub-culture of webdev which uses these old unix programs. I feel like it's an untapped resource, truly.

Thanks for your hard work on it!

My favourite personal use of Graphviz: A few years ago I inherited a large, legacy codebase that was very hard to understand -- full of global state modified from dozens of functions, obscure function names, etc. I used a C parser (forget which one) to convert the code to a set of ASTs, and then hacked up a Web-based, interactive graph generator, using Graphviz to create the interactive SVGs. The "app" let you click on a function (node) and zoom in to examine its callers, callees, global accesses, global mutations, etc., with a "radius" parameter to decide how much of the large graph you wanted to see. Every node was clickable, and would ask the Web app to generate a new graph centered on that node.

It was an awful, throwaway hack, and was only about 90% accurate due to parsing/preprocessor challenges. (At times I resorted to annotating the code with magic comments to facilitate graph generation -- not a sustainable approach.) But a day spent hacking with Graphviz dramatically improved my learning rate, and it was also useful in helping describe the code to others.

I have done the same and it totally saved my ass on legacy code that I was tasked with extending or fixing.

I just pumped the output of dot to a static web page. It was awesome.

Also, I rendered the entire graph as a single page, and started printing it tiled to multiple 8.5x11 sheets. One of the women I worked with that did all our document versioning and tracking saw me taping the sheets together, and asked me for a copy of the document. An hour later she walked into my office with a single page print from a 42" plotter. That hung like artwork on my office wall for about eight years.

She was a wonderful soul for that. And the print was beautiful.

granted, this was not fun, and also now 'modern' tex (not sure about graphviz) will use fontconfig on linux which may require different machinations.

so obviously your point on 'better integration' still stands unless I'm just out of date on how to do it..

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

Yup, I think these are the ones that mean I never actually end up using Graphviz for anything :)

If I'm generating graphs, I want them laid out in a hierarchical style.

To do that, I need a library which can do that layout.

Those libraries are often written in a higher level language like C#, Java, etc, which come with their own simple drawing layer.

And then I don't need Graphviz anymore! (not that I'm suggesting graphviz should change)

Also, in my own experience, I was able to get hierarchical layouts Graphviz by using directional graphs with subgraphs.

Thank you for the kind words.

I've tried to make it mobile-friendlier, after our marketing team told me that most people who come via Twitter use a phone. But we kinda ran out of time, so I only managed to fix the most egregious problems. By now I also have a few ideas how to get the edge paths to be much better (and built-in Bézier spline routing would have helped, but that was only released publicly ... two days ago). Admittedly, while that layout has been produced by yFiles' hierarchical layout it needed a bit massaging to do so properly (about 200 lines of custom layout code, if I remember correctly). However, a proper library that gives you that flexibility helps tremendously, of course. Sometimes, trying to get Graphviz to do the right thing can be pretty complicated and may involve hacks like invisible edges to force a certain layering (although that was way back and I didn't know about "rank=foo" back then; perhaps the invisible edges were really not needed).

In any case, yEd Live (https://www.yworks.com/yed-live/), built on yFiles for HTML, also has an undocumented, incomplete, and rudimentary Graphviz import. I've got a fairly exhaustive list of issues and missing features, but little time to tackle it, sadly. This is further complicated by the fact that the DOT language uses attributes to describe the graph structure, visual attributes of items, and to control layout settings. That makes mapping Graphviz to anything else a bit hard.

I've used it a few times for visualizing aspects of my research, usually by writing .dot files directly from Racket. It turned out to be quite useful.

What I want from graphviz is a rich library, based on D3, for building interactive web components for graphviz SVG output.

dot is an absolute dream for constructing automatic representations of graph and tree data, including great stuff like lexical scope and project maps. But simply building it into a raw SVG runs the risk of drowning in detail.

If this library were built in support of a graph generator SPA, something that lets a user tweak the huge state space of graphviz style parameters in real time, well, sky's the limit.

I work with parsers and abstract syntax trees professionally. I've been salivating over the kind of legibility we could introduce into this space with just such a library.

I know it's a huge undertaking! I think you'd find a lot of enthusiasm for actually doing it, if you organized the space to make it possible and put out a call to action.

This is a feature, not a bug.

The rest would be nice to have, though.

I will turn to Visio if I need to make something presentation-quality, so there's that.

I have similar feelings about the lack of ability to fine-tune the layout: I've started seeing it as a feature, because it gives me a great feedback mechanism: If the graph is too complicated for Graphviz to lay out nicely, I take that as a sign that the thing the graph represents needs to be simplified. I've even gone so far as to incorporate Graphviz into my definition of done for a refactoring project: I kept a dotfile representing the current state of the dependency graph, and stopped refactoring when the rendered graph stopped making my eyes water.

You mention a possible improvement of classes of nodes/edges. If I understood correctly, this is typically used for styling, and is most commonly achieved via a pre-processing step. We all use our own tools for that (I've personally used m4, cpp, sed, Tcl, and I'm sure others that I forget).

Graphviz is one of the tools that I use in a wide variety of circumstances. I'd say the most satisfying cases from all these years were (a) producing a genealogical graph of around 1000 people drawn with neato (very organic-looking!); and (b) producing orgcharts for an organization (that had to look acceptable to what people were used to seeing).

Many thanks for your work all this time!

EDIT: also, being able to create "venn diagrams" of sorts with subgraphs would be awesome, basically allowing a node to be in several clusters, and have the clusters borders cross each other so that the item is inside all of them.

Design is not something that should be tied to a particular decade. It's not fashion. Good design is timeless and only adopts to new technologies/media. Design is how well a particular solution works for the purpose of it. If it looks like 1985 and works well, there is absolutely no reason to change it. If it doesn't, then there is no need to look at "modern trends", instead we need to go back to the drawing board and find out what the problem is first.

Can you identify the problem with the design besides the superficial aesthetic (which can be easily themed)?

Design does not exist in a vacuum. Technological progress, for example, creates the need for design change. Microsoft's switch from a serif to a sans serif font as the default typeface for Word was a good move, because we rarely print documents anymore and a the best design for print is not the same as the best design for screens.

20th century physics books had a distinct design for illustrations. It was beautiful and functional. But it was also designed around the limitations of their eventual monochrome (not even greyscale) print. A 2020 textbook does not have the same limitations and should not be designed with the same set of constraints.

That's one half. The other one is how people feel while using it. 1985 aesthetic makes people feel bad. Thus design is half bad. Or, for you maybe, half good.

Many would argue good fashion is timeless as well. A good chunk of haute couture from decades past would be seen as modern and appealing today. (Which is why the houses like to repackage and ship them as such...)

> Fashion is a popular aesthetic expression at a particular time, place and in a specific context, especially in clothing, footwear, lifestyle, accessories, makeup, hairstyle, and body proportions.

Fashion is inexplicably linked to a particular time. Just like Art - Art evolves with time and it is part of the culture, current events, etc.

Design is not (unless you want to include say media as it changes through time. For e.g. print -> digital media).

But not at every given point in time. That fashion ebbs and flows is a given, but that's not the same thing as being timeless.

"It is essential that a font which has the glyphs for your specified characters is available at final rendering time."

It sounds to me like UTF-8 encoded characters won't show if the font isn't available on the machine, in which case we'd have to either somehow force a font install or ideally just package the font with the application. The latter would require rebuilding Graphviz without fontconfig enabled, I think?

Recently I started teaching Software Development, and once again reached for graphviz for a huge variety of classroom uses.

Thanks!

There are some who view the dot language as an "assembler" language, good as the output for graph generators. It would be desirable to have more expressive costructs, but barring that, a lot can be achieved by using gvpr, m4 or various scripting languages.