According to the doc , it can via the radius attributes, but when I try to render the provided example, the corner are not rounded, as if the attributes is doing nothing.
Here the example as is from the doc:
[dot]
digraph RoundedEdges {
splines = ortho;
nodesep = 1.0;
ranksep = 1.0;
// Default: square corners
A -> X [xlabel="radius=0 (default)"];
// Small rounded corners
B -> X [radius=8, xlabel="radius=8", color=blue];
// Medium rounded corners
C -> X [radius=12, xlabel="radius=12", color=green];
// Large rounded corners
D -> X [radius=20, xlabel="radius=20", color=red];
}
[/dot]
What gives?
I just started with graphviz, and I don’t know all the arcana.
(edit: I don’t undestard why the graph is not rendering)
Bad news: the documentation seems to be wrong (and has been forever?). I can not find any evidence that the ortho code recognizes, let alone uses, a radius attribute - or any similar-named attribute.
Better news: Here is a discussion of a post-processor (that I wrote) that will round-off ortho edges. It applies one radius to the entire graph (maybe that was the problem with the planned radius attribute)
[p.s. I had not noticed the radius in the documentation. Hidden in plain sight.]
Ah, I dint think to check the version, I just clicked on “edit on playground” to vizualize the graph. I can now see that playground uses 12.1.0, way behind to even stable version.
I’ll take into account this possible mismatch for future reference
If I may, I think hiding be good if the 14.1.0 release eventually not contain that functionality (for any reason), as then the page will need to be updated (or removed). Or, because it creates an otherwise unnecessary need for an occasional reader of the documentation to pay attention whether the latest release is newer or not. At least for me that’s unintuitive.
Though I like the impression it creates that Graphviz’s documentation is more up to date than Graphviz itself. I mean, I don’t observe that phenomenon frequently, if ever.
FWIW this is very unlikely. I intend to cut the 14.0.5 release, then move on to this one. The change to add radius is the very thing motivating a 14.1.0 bump.
What about just put more enphasys on the version targeted by the feature. Maybe a callout that alert user that current stable version is x.x.x and while feature y target this other version…
If feature is already in stable, green light
If feature is not in stable, red light
I’m imagining an automatic process for this labeling thing, but I not familiar enough with the project to know if it is possible at all.
I now know that this mismatch may exist, and also that the preview is using an even older version, so I will pay more attention, but another may not be aware, as I was
This is a very rare situation. I don’t think we’ve ever had a feature land in the docs before landing in the code prior to now.
Perhaps we should standardise how this stuff is called out though. I know I appreciate the Python docs’ consistency in styling call outs for which version features arrived in. We don’t really have any standard right now. E.g. the color page notes in the middle of paragraph text that there are some version differences.
To standardize version description for particular features is one thing, and I don’t know to what extent it be feasible. (Though I appreciate clarity in documentation, so if I could help here, please tell me how.) Anyway I think Graphviz could benefit from generic warnings for unknown attributes (and any unknown feature, for that matter), similar to e.g. the warning for an unknown color. Compare: when we do
echo 'graph { a -- b [ color = abc ] }' | dot -o /dev/null
we get
Warning: abc is not a known color.
but when we do
echo 'graph { splines = ortho ; a -- b [ radius = 1 ] }' | dot -o /dev/null
Perhaps this was already explained more clearly in some other posting or documentation, but, anyway, it’s a nice idea, but there are some things to consider.
Intentionally, graphviz tools pass through and otherwise ignore attributes they don’t recognize. It’s a schema less design. The goal was flexibility and convenience.
On the other hand, it’s reasonable to want the kind of checking that’s proposed here. (Also a checker could inspect values for correct type and range.) We might interpret this proposal as saying that the documentation provides the schema. One would expect the checking to be constructed automatically from one source of truth about the schema. The checker could be optional or simply emit warnings that could be ignored or enabled/disabled in some way. To me this seems like a medium-level effort, though perhaps AI can assist in writing the code? Graphviz is, in reality, maintained mostly by @smattr these days, with a little (not too much) assistance from others.
There’s a larger question about where the project goes from here. Maybe AI coding bots will improve enough to take over someday.
I think I should have come across such design in the past somewhere, but am not sure about its benefits. I don’t know the name “schema-less design”, and as I’m googling it up now, I see it mostly in the context of databases. OK, you say that “[w]e might interpret this proposal as saying that the documentation provides the schema”. But how exactly do you see it bring flexibility and convenience in comparison to such warnings I mentioned?
You mean like
[dot]
digraph {
“Source of truth (database?)” → “Documentation (graphviz.org/docs)”
“Source of truth (database?)” → “Warnings in code”
}
[/dot]
?
I’m looking around the code now… but such an assistance still isn’t close, I guess.
I don’t know what coding with AI could look like. Do you mean the maintainers won’t worry about particular lines of a piece of code, but only about the code’s general capability?