Graph with orthogonal edges

By default, the ortho rendering looks like :

digraph{
    splines=ortho
    a -> 1
    a -> 2
    a -> 3
}

[dot]
digraph{
splines=ortho
a → 1
a → 2
a → 3
}
[/dot]

I would like a straight vertical line from a, and then an horizontal line, and then three vertical lines going to 1,2,3

    a
    |
--------
|   |   |
1   2   3

I don’t see how I can tell dot to do this, so I added an invisible point p

digraph{
    splines=ortho
    p [label= "" width=0.01 height=0.01 shape=point fixedsize=true]
    a -> p [arrowhead=none]
    p -> 1
    p -> 2
    p -> 3
}

[dot]
digraph{
splines=ortho
p [label= “” width=0.01 height=0.01 shape=point fixedsize=true]
a → p [arrowhead=none]
p → 1
p → 2
p → 3
}
[/dot]

Which is almost perfect, but… if I add a fourth point :

digraph{
    splines=ortho
    p [label= "" width=0.01 height=0.01 shape=point fixedsize=true]
    a -> p [arrowhead=none]
    p -> 1
    p -> 2
    p -> 3
    p -> 4
}

[dot]
digraph{
splines=ortho
p [label= “” width=0.01 height=0.01 shape=point fixedsize=true]
a → p [arrowhead=none]
p → 1
p → 2
p → 3
p → 4
}
[/dot]

Horror !
Even with two points I have strange behaviour, the edge don’t go to the center of the node :

digraph{
    splines=ortho
    p [label= "" width=0.01 height=0.01 shape=point fixedsize=true]
    a -> p [arrowhead=none]
    p -> 1
    p -> 2
}

[dot]
digraph{
splines=ortho
p [label= “” width=0.01 height=0.01 shape=point fixedsize=true]
a → p [arrowhead=none]
p → 1
p → 2
}
[/dot]

I love Graphviz, please tell me it’s possible !

Don’t believe you can get the desired result using ortho. Both of the problems you encountered would probably require serious mucking with the ortho source.
But below is diy ortho. It creates more invisible nodes and uses the group attribute to to align them with the visible nodes. More work on your part, but gives you the control that ortho does not.

digraph{
    splines= polyline  //ortho
    {rank=same
    node [label= "" width=0.01 height=0.01 shape=point fixedsize=true]
    p1 [group=x1]
    p2 [group=x2]
    pX [group=xX]
    p3 [group=x3]
    p4 [group=x4]
    edge [arrowhead=none]
    p1->p2->pX->p3->p4
    }
    a -> pX [arrowhead=none]
    1 [group=x1]
    2 [group=x2]
    3 [group=x3]
    4 [group=x4]    
    p1 -> 1
    p2 -> 2
    p3 -> 3
    p4 -> 4
}

Giving:
pseudoOrtho

If there’s a free version of yWorks, that might be a better choice because of their work on orthogonal edge routing algorithms. Also, Tom Sawyer software has an academic version that is free for 1 year. Many years ago I talked with someone that released a commercial product with full orthogonal edge routing, and they said getting an implementation right was far more work than they expected. (That being said, there might be a lot of simplifying assumptions one could make for layered graphs.)

This is an example of an area where open source software struggles, because the problem is technically difficult (probably multiple years of graduate level hacking) and though ultimately many people could benefit, there is no reward system in place to encourage or support such work. All we have is 20 year old summer intern code. I think the intern is now a professor and recently promoted to a named chair at an institution in Southeast Asia. So hard to get hacking help from them now.

If ortho worked with ports, that solves the second issue. (Non-trivial) (it might be made to work even without ports if the code was changed to give priority to n/s/e/w).
Fixing the first mess could (maybe) be fixed if the user could provide a hint to go “clockwise” or “counter-clockwise” (my terminology) at least for the head & tail ends. (for the edge p->4,
ortho went counter-clockwise instead of clockwise from the tail).

Thank you, I will try this. It’s indeed more work on my part, I have a program that generates the dot (in an already messy way). I’ll let you know if it’s ok.