# \`radius\` attribute for ortho splines not working in the doc **URL:** \ **Category:** Help\ **Created:** [November 20, 2025, 9:38am UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244 "2025-11-20T09:38:44Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![kompre](https://avatars.discourse-cdn.com/v4/letter/k/a9adbd/32.png) [@kompre](https://forum.graphviz.org/u/kompre)\ **Post date:** [November 20, 2025, 9:38am UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/1 "2025-11-20T09:38:44Z")
Can the edge of spline in `ortho` mode be rounded? According to the doc , it can via the [`radius`](https://graphviz.org/docs/attrs/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] ```auto 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) ---
**Author:** ![steveroush](https://avatars.discourse-cdn.com/v4/letter/s/a9adbd/32.png) [@steveroush](https://forum.graphviz.org/u/steveroush)\ **Post date:** [November 20, 2025, 4:48pm UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/3 "2025-11-20T16:48:34Z")
- 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](https://forum.graphviz.org/t/round-off-ortho-edges/2414) 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.] ---
**Author:** ![magjac](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/magjac/32/16_2.png) [@magjac](https://forum.graphviz.org/u/magjac)\ **Post date:** [November 20, 2025, 6:03pm UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/4 "2025-11-20T18:03:41Z")
There is an open MR that implements it: > **[Add radius attribute for rounded corners on orthogonal edges (!4612) · Merge...](https://gitlab.com/graphviz/graphviz/-/merge_requests/4612)** > > Implements rounded corner support for orthogonal edge routing with opt-in behavior to maintain backward compatibility. Features: Supports radius=N attribute for explicit radius... ---
**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\ **Post date:** [November 21, 2025, 2:10am UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/5 "2025-11-21T02:10:57Z")
As the documentation you referenced says: > Available from Graphviz version ≥ 14.1.0. This version has not yet been released. ---
**Author:** ![kompre](https://avatars.discourse-cdn.com/v4/letter/k/a9adbd/32.png) [@kompre](https://forum.graphviz.org/u/kompre)\ **Post date:** [November 21, 2025, 6:24am UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/6 "2025-11-21T06:24:22Z")
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 ---
**Author:** ![mark](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/mark/32/84_2.png) [@mark](https://forum.graphviz.org/u/mark)\ **Post date:** [November 21, 2025, 6:52am UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/7 "2025-11-21T06:52:36Z")
I was wondering if I should hide the page until release. Idk, it’s a bit more work! ---
**Author:** ![decision-making-mike](https://avatars.discourse-cdn.com/v4/letter/d/9dc877/32.png) [@decision-making-mike](https://forum.graphviz.org/u/decision-making-mike)\ **Post date:** [November 21, 2025, 4:37pm UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/8 "2025-11-21T16:37:48Z")
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. ---
**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\ **Post date:** [November 22, 2025, 1:02am UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/9 "2025-11-22T01:02:18Z")
> [@decision-making-mike](#): > > if the 14.1.0 release eventually not contain that functionality (for any reason) 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. ---
**Author:** ![kompre](https://avatars.discourse-cdn.com/v4/letter/k/a9adbd/32.png) [@kompre](https://forum.graphviz.org/u/kompre)\ **Post date:** [November 22, 2025, 4:33pm UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/10 "2025-11-22T16:33:50Z")
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 ---
**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\ **Post date:** [November 22, 2025, 4:48pm UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/11 "2025-11-22T16:48:04Z")
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](https://graphviz.org/docs/attr-types/color/) notes in the middle of paragraph text that there are some version differences. ---
**Author:** ![decision-making-mike](https://avatars.discourse-cdn.com/v4/letter/d/9dc877/32.png) [@decision-making-mike](https://forum.graphviz.org/u/decision-making-mike)\ **Post date:** [November 23, 2025, 11:21am UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/12 "2025-11-23T11:21:02Z")
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 ```bash echo 'graph { a -- b [color = abc] }' | dot -o /dev/null ``` we get ```auto Warning: abc is not a known color. ``` but when we do ```bash echo 'graph { splines = ortho ; a -- b [radius = 1] }' | dot -o /dev/null ``` we get nothing, at least in ~~14.0.4~~ 14.0.1. ---
**Author:** ![scnorth](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/scnorth/32/89_2.png) [@scnorth](https://forum.graphviz.org/u/scnorth)\ **Post date:** [November 23, 2025, 1:23pm UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/13 "2025-11-23T13:23:23Z")
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. ---
**Author:** ![decision-making-mike](https://avatars.discourse-cdn.com/v4/letter/d/9dc877/32.png) [@decision-making-mike](https://forum.graphviz.org/u/decision-making-mike)\ **Post date:** [November 23, 2025, 2:40pm UTC](https://forum.graphviz.org/t/radius-attribute-for-ortho-splines-not-working-in-the-doc/3244/14 "2025-11-23T14:40:55Z")
> [@scnorth](#): > > - 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. 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? > [@scnorth](#): > > One would expect the checking to be constructed automatically from one source of truth about the schema You mean like [dot] digraph { “Source of truth (database?)” → “Documentation ([graphviz.org/docs](http://graphviz.org/docs))” “Source of truth (database?)” → “Warnings in code” } [/dot] ? > [@scnorth](#): > > Graphviz is, in reality, maintained mostly by @smattr these days, with a little (not too much) assistance from others. I’m looking around the code now… but such an assistance still isn’t close, I guess. > [@scnorth](#): > > There’s a larger question about where the project goes from here. Maybe AI coding bots will improve enough to take over someday. 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?