Keep the position

1

hello people,

I wrote this

digraph {  
    vim    [shape=record,label="{<cmd>vim}|{<0>0|<1>1|<2>2}" ]
    xterm  [shape=record,label="{<0>0|<1>1|<2>2}|{<cmd>xterm}|{3|4|5}"]
    xterm2 [shape=record,label="{<0>0|<1>1|<2>2}|{<cmd>xterm}"];
}

and it rendered the way i expected (maybe more space but it’s ok).
then i add some edges:

digraph {  
    vim    [shape=record,label="{<cmd>vim}|{<0>0|<1>1|<2>2}" ]
    xterm  [shape=record,label="{<0>0|<1>1|<2>2}|{<cmd>xterm}|{3|4|5}"]
    xterm2 [shape=record,label="{<0>0|<1>1|<2>2}|{<cmd>xterm}"];
    vim:0 -> xterm:1
}

then dot lost his mind and render the boxes totally differently. is there a way to tell it to keep its positions ?

regards

2

Dot can indeed be mysterious, but in this case it is not. “Normally”, defining an edge tells dot to put the head and tail on different ranks (different rows).
The standard way to keep head and tail on the same rank (I assume that is what you want), is to insert both head and tail in a subgraph with rank=same attribute (see Section 2.6 of https://www.graphviz.org/pdf/dotguide.pdf). Like so:

digraph {
  {rank=same  
    vim    [shape=record,label="{<cmd>vim}|{<0>0|<1>1|<2>2}" ]
    xterm  [shape=record,label="{<0>0|<1>1|<2>2}|{<cmd>xterm}|{3|4|5}"]
    xterm2 [shape=record,label="{<0>0|<1>1|<2>2}|{<cmd>xterm}"];
    vim:0 -> xterm:1
  }
}

Unfortunately, dot has a bug/feature/problem with edges connecting record-style nodes that are on the same rank. The above input will produce this warning message:

Warning: flat edge between adjacent nodes one of which has a record shape - replace records with HTML-like labels
  Edge vim -> xterm

So, unfortunately you may have to rewrite your record-style nodes as html-style.

3

hello and thanks for your reply,

Unfortunately, dot has a bug/feature/problem with edges connecting
record-style nodes that are on the same rank. The above input will
produce this warning message

I tried to use rank=same without the inside block and this had no
effect. I just copy/pasted your example and confirm I have the same
error. Aside: I realized that the debian package for graphviz is
outdated.

So, unfortunately you may have to rewrite your record-style nodes as html-style.

Which at this point leads me to fall back to pic which seems to be
easier to use when

  • the graph isn’t large
  • you need to control what happens

Thanks again for helping!

marc

marc

4

You might like pikchr Pikchr: Documentation - a pic rewrite, which can be included in Markdown - but does not have to be.

5

hello,

You might like pikchr Pikchr: Documentation -
a pic rewrite, which can be included in Markdown - but does not have
to be.

thanks for the link it seems the only possible output is svg wich is
none of my usecase (i don’t do web). i write my papers in roff to get
pdf files so when graphviz can’t help, pic is probably the best choice
(i have asymptote in my bookmarks i case but i had no need for the moment).

i’ll bookmark pikchr just in case i need an epub output.

regards.

6

Wow, {tgn}roff, cool! I didn’t know it was still a thing. I have ancient memories of creating troff docs on the single(?) typesetter in the building before Postscript and before bitmapped terminals. Ouch!
For completeness, let me note that there are ways to explicitly and/or implicitly better manage node positioning in Graphviz. If (g)pic becomes a hassle, come on back here and we’ll try to help.
You might also look at dpic (GitHub - tim-tx/dpic: A fork of Dwight Aplevich's dpic https://gitlab.com/aplevich/dpic). I believe it is a slightly improved over (g)pic.

7

hello,

Wow, {tgn}roff, cool! I didn’t know it was still a thing.

I used to use sdoc to write my manpages and someone poked me about the
very bad quality of the result. He pointed out mandoc as replacement.

At first I was really skeptical because of a first experience in late
90s but i wanted my doc to be great so I tried and was pleased how easy
it was to write the manpage this way. It’s clean and use semantic tags
so you can easily parse it. I reported this experience to my local unix
group and someone told me I have to give groff a try.

I did and once again, after years and years of latex an html, it was a
really pleasant experience:

  • it’s simple and productive
  • it’s easy adapt
  • it’s blazing fast

There are many available roff distro outthere, all of them has pro and
cons but I was advised to use groff and have no reason to test for
something else for the moment. Also: the mailing list is active and
welcoming so I sticked on it.

Opening the discussion into our local group really interested people:
when you just want to write a simple paper, a letter or something,
latex is way too much effort. so the trend here is to move from latex
to roff.

I have ancient memories of creating troff docs on the single(?)
typesetter in the building before Postscript and before bitmapped terminals.

The bad memories from roff were the fact that:

  • you can’t indent the way you can in html (I didn’t know how to use vim)
  • in the examples, it was boring just to get an accent or an insecable
    space. Nowadays
    • groff comes with some flags to use preconv
      (I don’t know if it doesn’t exists or if I just missed it back in
      the '90s)
    • AFAIK, 9front roff and neatroff comes with a direct utf-8 support

I still use postscript when I don’t need PDF features.

becomes a hassle, come on back here and we’ll try to help. You might
also look at dpic (GitHub - tim-tx/dpic: A fork of Dwight Aplevich's dpic https://gitlab.com/aplevich/dpic). I believe it is a
slightly improved over (g)pic.

Again: thanks! our local group try to collect a collection of useful
links about roff (for example: we started to take care of dformat
so it can be easily shipped. nothing public but we started over
GitHub - eiro/dformat: A Program for Typesetting Data Formats.).

So if you have other interesting pointers to share: please tell me :slight_smile:

regards,
marc