graphviz issueshttps://gitlab.com/graphviz/graphviz/-/issues2020-07-19T04:39:09Zhttps://gitlab.com/graphviz/graphviz/-/issues/1284Dot really slow on a relatively small graph.2020-07-19T04:39:09ZTeodor Alexandru StoenescuDot really slow on a relatively small graph.`/usr/local/bin/dot -v -Goverlap=scale -Tsvg -oout3.svg inputx.txt`
Produces a really ugly graph after about 5 minutes.
`dot - graphviz version 2.41.20171003.0012 (20171003.0012)
libdir = "/usr/local/lib/graphviz"
Activated plugin libr...`/usr/local/bin/dot -v -Goverlap=scale -Tsvg -oout3.svg inputx.txt`
Produces a really ugly graph after about 5 minutes.
`dot - graphviz version 2.41.20171003.0012 (20171003.0012)
libdir = "/usr/local/lib/graphviz"
Activated plugin library: libgvplugin_core.so.6
Using render: svg:core
Using device: svg:svg:core
Activated plugin library: libgvplugin_dot_layout.so.6
Using layout: dot:dot_layout
The plugin configuration file:
/usr/local/lib/graphviz/config6
was successfully loaded.
render : dot dot_json fig json json0 map mp pic pov ps svg tk visio vml xdot xdot_json
layout : circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
textlayout :
device : canon cmap cmapx cmapx_np dot dot_json eps fig gv imap imap_np ismap json json0 mp pic plain plain-ext pov ps ps2 svg svgz tk vdx vml vmlz xdot xdot1.2 xdot1.4 xdot_json
loadimage : (lib) eps gif jpe jpeg jpg png ps svg
pack info:
mode undefined
size 0
flags 0
margin 8
pack info:
mode node
size 0
flags 0
fontname: "courier" resolved to: [internal courier]
network simplex: 1307 nodes 1504 edges maxiter=2147483647 balance=1
network simplex: 1307 nodes 1504 edges 7 iter 0.01 sec
Maxrank = 524, minrank = 0
mincross: pass 0 iter 0 trying 0 cur_cross 980 best_cross 980
mincross: pass 0 iter 1 trying 1 cur_cross 1074 best_cross 980
mincross: pass 0 iter 2 trying 0 cur_cross 906 best_cross 906
mincross: pass 0 iter 3 trying 0 cur_cross 551 best_cross 551
mincross: pass 1 iter 0 trying 0 cur_cross 2064 best_cross 477
mincross: pass 1 iter 1 trying 1 cur_cross 875 best_cross 477
mincross: pass 1 iter 2 trying 2 cur_cross 780 best_cross 477
mincross: pass 1 iter 3 trying 3 cur_cross 508 best_cross 477
mincross: pass 2 iter 0 trying 0 cur_cross 477 best_cross 477
mincross: pass 2 iter 1 trying 1 cur_cross 736 best_cross 477
mincross: pass 2 iter 2 trying 2 cur_cross 925 best_cross 477
mincross: pass 2 iter 3 trying 3 cur_cross 517 best_cross 477
mincross: pass 2 iter 4 trying 4 cur_cross 536 best_cross 477
mincross: pass 2 iter 5 trying 5 cur_cross 769 best_cross 477
mincross: pass 2 iter 6 trying 6 cur_cross 1000 best_cross 477
mincross: pass 2 iter 7 trying 0 cur_cross 442 best_cross 442
mincross: pass 2 iter 8 trying 1 cur_cross 506 best_cross 442
mincross: pass 2 iter 9 trying 2 cur_cross 758 best_cross 442
mincross: pass 2 iter 10 trying 3 cur_cross 851 best_cross 442
mincross: pass 2 iter 11 trying 4 cur_cross 456 best_cross 442
mincross: pass 2 iter 12 trying 5 cur_cross 516 best_cross 442
mincross: pass 2 iter 13 trying 6 cur_cross 739 best_cross 442
mincross: pass 2 iter 14 trying 7 cur_cross 782 best_cross 442
mincross: pass 2 iter 15 trying 8 cur_cross 468 best_cross 442
mincross %3: 441 crossings, 1.12 secs.
network simplex: 38772 nodes 57735 edges maxiter=13 balance=2
network simplex: 38772 nodes 57735 edges 13 iter 0.89 sec
routesplines: 1523 edges, 39551 boxes 329.60 sec
Using render: svg:core
Using device: svg:svg:core
gvRenderJobs %3: 0.18 secs.`
![out3.svg](/uploads/07a7a069c63eee42704bfc3e66c822fd/out3.svg)https://gitlab.com/graphviz/graphviz/-/issues/1285Binary tcl modules should compile with -module2022-06-22T04:40:48ZDaniel MacksBinary tcl modules should compile with -moduleThey are runtime loadable (dlopen, or equivalent, from tcl program, via 'load') rather than shared libraries for dynamic linking by others. On OS X, these two concepts have different extensions (.so vs .dylib). It's confusing when a runt...They are runtime loadable (dlopen, or equivalent, from tcl program, via 'load') rather than shared libraries for dynamic linking by others. On OS X, these two concepts have different extensions (.so vs .dylib). It's confusing when a runtime-loadable module has a dynamic-linker extension. In commit 40123aedcd2761e98d8c9917be6040ea6187c97f, the -module flag was added to LDFLAGS in tclpkg/gv/Makefile.am, which fixes libgv_tcl. Could the same change be applied to the other tclpkg/*/Makefile.am LDFLAGS?https://gitlab.com/graphviz/graphviz/-/issues/1286Add links to cairo pdf output2018-11-25T19:35:41ZAdrian JohnsonAdd links to cairo pdf outputHere's a patch I used to test graphviz with cairo pdf links. PDF links feature is not yet in a stable release of cairo. Links are in the current cairo 1.15.8 snapshot. The patch is only a prototype I used for testing. It probably should ...Here's a patch I used to test graphviz with cairo pdf links. PDF links feature is not yet in a stable release of cairo. Links are in the current cairo 1.15.8 snapshot. The patch is only a prototype I used for testing. It probably should check the size of the url.
Also, the no white background option should be enabled for PDF. PDFs have a transparent background. The viewer will always render on top of a white background. The transparent background is useful in case you want to use a PDF file like an EPS file.
[link.diff](/uploads/054e9d1d4f5fdf0768da70538b61193c/link.diff)https://gitlab.com/graphviz/graphviz/-/issues/1287Cairo PS/PDF output is using hinted metrics2023-03-29T02:32:22ZAdrian JohnsonCairo PS/PDF output is using hinted metricsI noticed that the letter spacing is incorrect in cairo PDF and PS output. The problem can easily be seen in this line from the PS output (cairo uses PDF operators in PS output):
```
[(c)15(l)11(i)10(c)15(k)18( )-18(m)-25(e)]TJ
```
The n...I noticed that the letter spacing is incorrect in cairo PDF and PS output. The problem can easily be seen in this line from the PS output (cairo uses PDF operators in PS output):
```
[(c)15(l)11(i)10(c)15(k)18( )-18(m)-25(e)]TJ
```
The numbers are kerning adjustments. As Pango does not kern Type 1 fonts, using the default Nimbus Roman No9 L font, if the glyphs were at their natural glyph advances the line would be:
```
[(click me)]TJ
```
The problem is in pango_textlayout() where it is setting the font options. Instead of specifying the font options, you should call pango_cairo_update_context() with the cairo content. Pango will pickup the default font options for the surface which for PDF/PS is hint style and metrics off. Also, setting the subpixel order manually is wrong. If pango_cairo_update_context() is used it will detect the subpixel order for the display used.
I tried to create a patch for this but it appears the layout is done first before the surface is created.https://gitlab.com/graphviz/graphviz/-/issues/1274CGraph: Is there a way to convert a directed graph to an undirected graph?2017-10-11T22:07:05ZJohn EllsonCGraph: Is there a way to convert a directed graph to an undirected graph?*Created by: Chiel92*
Looking at the cgraph.h interface, it seems that only when creating a graph, properties such as directedness and strictness can be specified.
Once we have a directed `Agraph_t`, what is the easiest way to make ...*Created by: Chiel92*
Looking at the cgraph.h interface, it seems that only when creating a graph, properties such as directedness and strictness can be specified.
Once we have a directed `Agraph_t`, what is the easiest way to make it undirected?https://gitlab.com/graphviz/graphviz/-/issues/1283how to custom layout2022-06-17T03:42:40ZJohn Ellsonhow to custom layout*Created by: helloyi*
Hi!
1. I want to code a draw internal-DSL with Python.
2. And easy to draw graph(mem-struct, data-struct, flow-chat...), and used in org babel, my original intention.
3. How to custom layout module?
thx a lot!*Created by: helloyi*
Hi!
1. I want to code a draw internal-DSL with Python.
2. And easy to draw graph(mem-struct, data-struct, flow-chat...), and used in org babel, my original intention.
3. How to custom layout module?
thx a lot!https://gitlab.com/graphviz/graphviz/-/issues/1273Subgraph with rank = source or sink causes segfault2017-10-11T22:07:05ZJohn EllsonSubgraph with rank = source or sink causes segfault*Created by: camwebb*
This graph:
```
digraph {
a -> b
{ rank=source c}
}
```
causes a segfault with `dot`:
```
...
network simplex: 4 nodes 2 edges maxiter=2147483647 balance=2
Segmentation fault (core dumped)
```
Fai...*Created by: camwebb*
This graph:
```
digraph {
a -> b
{ rank=source c}
}
```
causes a segfault with `dot`:
```
...
network simplex: 4 nodes 2 edges maxiter=2147483647 balance=2
Segmentation fault (core dumped)
```
Fails also with `rank=sink`, but successful with `max`,`min`,`same`. Checked on fresh build of nightly release: `graphviz-2.41.20170103.1755`. This seems to be the same issues as bug [223](http://www.graphviz.org/mantisbt/view.php?id=223), fixed in version 1.9.
[Thanks for `graphviz`!]https://gitlab.com/graphviz/graphviz/-/issues/1282[CGraph] Is the library threadsafe for readonly access?2020-06-08T01:35:02ZJohn Ellson[CGraph] Is the library threadsafe for readonly access?*Created by: Chiel92*
It is stated in the CGraph manual that the library is not threadsafe. To what extent is this true?
Suppose a graph structure has been created. If then multiple threads are accessing this graph, but without maki...*Created by: Chiel92*
It is stated in the CGraph manual that the library is not threadsafe. To what extent is this true?
Suppose a graph structure has been created. If then multiple threads are accessing this graph, but without making any modifications to the graph, would this give any problems?https://gitlab.com/graphviz/graphviz/-/issues/1267testsuite: which of the ksh implementations is known to be able to run rtest.sh?2017-10-11T22:07:05ZJohn Ellsontestsuite: which of the ksh implementations is known to be able to run rtest.sh?*Created by: ng-0*
Hi,
one of our good usage policies is that we run test suites whenever possible, whereever possible with
applications.
mksh seemed like the shell which would be able to run this script, however it fails the check...*Created by: ng-0*
Hi,
one of our good usage policies is that we run test suites whenever possible, whereever possible with
applications.
mksh seemed like the shell which would be able to run this script, however it fails the check.
Could you tell me which exact shell (name, binary-name and version) you use to run this test?
I know it is "ksh93", but which available free software implementation, if any, is able to run it.
Thanks!
edit: is it really just the original ksh-93 as available from here https://github.com/att/ast ?https://gitlab.com/graphviz/graphviz/-/issues/1280[dot] Segfault when setting nodesep to 0.32020-07-03T22:14:21ZJohn Ellson[dot] Segfault when setting nodesep to 0.3*Created by: Chiel92*
The following graph gives a segfault when doing a dot layout. (tested with windows 7)
```dot
digraph "Graph 76b00d8f-11c3-463d-ad26-29f5d68c9008" {
graph [ nodesep=0.03 ];
node [ shape=point ];
subgraph "rank-t...*Created by: Chiel92*
The following graph gives a segfault when doing a dot layout. (tested with windows 7)
```dot
digraph "Graph 76b00d8f-11c3-463d-ad26-29f5d68c9008" {
graph [ nodesep=0.03 ];
node [ shape=point ];
subgraph "rank-target" {
graph [rank=same];
"A";
"B";
"X";
}
"A" -> "X";
"B" -> "X";
}
```
```
$ cat dump.dot | ./dot.exe -Tsvg -O
Segmentation fault
```
When increasing the `nodesep` to `0.4`, the following messages appear.
```
$ cat dump.dot | ./dot.exe -Tsvg -O
libpath/C:\Users\Chiel.tenBrinke\Projects\graphviz\lib\pathplan\shortest.c:324: triangulation failed
libpath/C:\Users\Chiel.tenBrinke\Projects\graphviz\lib\pathplan\shortest.c:207: cannot find triangle path
Warning: Unable to reclaim box space in spline routing for edge "A" -> "X". Something is probably seriously wrong.
```
According to http://www.graphviz.org/doc/info/attrs.html#a:nodesep, the minimum value is only `0.2`.https://gitlab.com/graphviz/graphviz/-/issues/1279What should I read/learn if I want to write a new output format for Graphviz?2017-11-29T20:12:48ZKoz RossWhat should I read/learn if I want to write a new output format for Graphviz?I'd like to contribute an output format that produces ASCII diagrams. However, I'm not really sure where to begin with the Graphviz codebase, or what to use as an example or starting point. Would someone be able to point me in the right ...I'd like to contribute an output format that produces ASCII diagrams. However, I'm not really sure where to begin with the Graphviz codebase, or what to use as an example or starting point. Would someone be able to point me in the right direction?https://gitlab.com/graphviz/graphviz/-/issues/1264Format svg not recognized2019-06-18T13:29:07ZJohn EllsonFormat svg not recognized*Created by: helperman*
I use dot.exe to create svg-output file using such a command:
"C:\Program Files (x86)\Graphviz 2.41.20170804.1243\bin\dot.exe" -Tsvg -O -Kdot "C:\graph\inputBeta.graphviz"
Here is what I get:
http://storage5...*Created by: helperman*
I use dot.exe to create svg-output file using such a command:
"C:\Program Files (x86)\Graphviz 2.41.20170804.1243\bin\dot.exe" -Tsvg -O -Kdot "C:\graph\inputBeta.graphviz"
Here is what I get:
http://storage5.static.itmages.ru/i/17/0807/h_1502124532_8321547_2103d2d1e8.png
Do you refuse svg-format forever?
Why?https://gitlab.com/graphviz/graphviz/-/issues/1277[Dot] When exactly do multiple splines occur?2021-03-20T02:07:43ZJohn Ellson[Dot] When exactly do multiple splines occur?*Created by: Chiel92*
A spline type can have multiple splines, according to http://www.graphviz.org/doc/info/attrs.html#k:splineType
However, I have not been able to find an answer in the documentation to the following question:
When ...*Created by: Chiel92*
A spline type can have multiple splines, according to http://www.graphviz.org/doc/info/attrs.html#k:splineType
However, I have not been able to find an answer in the documentation to the following question:
When and why will there be multiple splines?https://gitlab.com/graphviz/graphviz/-/issues/1262conflicting declaration ‘typedef long long int int64_t’ from includes in gv_o...2023-12-22T08:32:04ZJean-Christophe Manciotconflicting declaration ‘typedef long long int int64_t’ from includes in gv_ocaml.cpp prevents buildingUbuntu 17.04
git commit 9eee865
libc6-dev 2.24-9ubuntu2.2
libstdc++-6-dev 6.3.0-12ubuntu2
Building with:
```
./autogen.sh NOCONFIG
./configure --build=x86_64-pc-linux-gnu \
--prefix=/usr --sysconfdir=/...Ubuntu 17.04
git commit 9eee865
libc6-dev 2.24-9ubuntu2.2
libstdc++-6-dev 6.3.0-12ubuntu2
Building with:
```
./autogen.sh NOCONFIG
./configure --build=x86_64-pc-linux-gnu \
--prefix=/usr --sysconfdir=/etc --localstatedir=/var
make dist
```
leads to:
```
...
swig -c++ -ocaml -o gv_ocaml.cpp ./gv.i
mv gv_ocaml.cpp gv_ocaml.cpp.orig
sed '/int caml_array_length/d' gv_ocaml.cpp.orig > gv_ocaml.cpp
rm gv_ocaml.cpp.orig
CXX libgv_ocaml_la-gv_ocaml.lo
<command-line>:0:7: error: conflicting declaration ‘typedef long long int int64_t’
In file included from /usr/include/stdlib.h:275:0,
from /usr/include/c++/6/cstdlib:75,
from /usr/include/c++/6/stdlib.h:36,
from gv_ocaml.cpp:750:
/usr/include/x86_64-linux-gnu/sys/types.h:197:1: note: previous declaration as ‘typedef long int int64_t’
__intN_t (64, __DI__);
^
Makefile:2152: recipe for target 'libgv_ocaml_la-gv_ocaml.lo' failed
make[4]: *** [libgv_ocaml_la-gv_ocaml.lo] Error 1
make[4]: Leaving directory '/home/actionmystique/src/Topology/git-graphviz/tclpkg/gv'
Makefile:2683: recipe for target 'install-recursive' failed
...
```
https://gitlab.com/graphviz/graphviz/-/issues/1276Gv2gml Doesn't escape quotes in attributes.2021-10-01T15:50:11ZJohn EllsonGv2gml Doesn't escape quotes in attributes.*Created by: caber*
https://github.com/ellson/graphviz/blob/8f8c435c7c7ed3750816fa39c39b56ab0cc6a86f/cmd/tools/gv2gml.c#L232
Doesn't escape qoutes, emits malformed gml for proper dot file, without error.
PoC:
digraph test {
x [labe...*Created by: caber*
https://github.com/ellson/graphviz/blob/8f8c435c7c7ed3750816fa39c39b56ab0cc6a86f/cmd/tools/gv2gml.c#L232
Doesn't escape qoutes, emits malformed gml for proper dot file, without error.
PoC:
digraph test {
x [label=<"Label">]; // emits: label ""Label"" should emit: label "\\"Label\\""
}
https://gitlab.com/graphviz/graphviz/-/issues/1259I broke the Travis builds2017-10-11T22:07:05ZJohn EllsonI broke the Travis builds*Created by: ellson*
I managed to break the Travis build, which is done on a Ubuntu system.
The issue is likely that the python3-dev is not available, but I don't know how to configure the dpkg set.
It may be necessary to use:
...*Created by: ellson*
I managed to break the Travis build, which is done on a Ubuntu system.
The issue is likely that the python3-dev is not available, but I don't know how to configure the dpkg set.
It may be necessary to use:
--disable-python3 --disable-python2 --enable-python
to restore previous behaviour.
https://gitlab.com/graphviz/graphviz/-/issues/1275Graphviz in your browser through the new D3 plugin d3-graphviz2020-05-28T10:51:24ZJohn EllsonGraphviz in your browser through the new D3 plugin d3-graphviz*Created by: magjac*
I've developed a new plugin for D3, [d3-graphviz](https://github.com/magjac/d3-graphviz). I'd be honored if you would like to list it on your [Resources](http://www.graphviz.org/content/resources) page.
The plugi...*Created by: magjac*
I've developed a new plugin for D3, [d3-graphviz](https://github.com/magjac/d3-graphviz). I'd be honored if you would like to list it on your [Resources](http://www.graphviz.org/content/resources) page.
The plugin is based on [Viz.js](https://github.com/mdaines/viz.js) and adds:
* Animated transition of one graph into another
* Edge path tweening
* Node shape tweening
* Fade-in and fade-out of entering and exiting nodes and edges
* Panning & zooming of the generated graph
See this small [demo](http://bl.ocks.org/magjac/4acffdb3afbc4f71b448a210b5060bca).
Apologies for posting "advertisement" here. It's because of https://github.com/ellson/graphviz/issues/1270.
https://gitlab.com/graphviz/graphviz/-/issues/1271How to build static executable dot with all dependencies?2020-05-28T10:59:32ZAleh AtsmanHow to build static executable dot with all dependencies?Hi, i want to use graphviz in AWS lambda environment. I can't use package managers, because environment clean all things frequently. So i want to build static executable and place it in source files of my project.
Here is what i have...Hi, i want to use graphviz in AWS lambda environment. I can't use package managers, because environment clean all things frequently. So i want to build static executable and place it in source files of my project.
Here is what i have done already:
```
$ // Rent ec2 instance.
$ // Connect to it using ssh.
$ yum groupinstall "Development tools" // that will install C compiler and delepment tools.
$ sudo yum install cairo-devel pango-devel // that dependencies required for PDF format.
$ wget http://www.graphviz.org/pub/graphviz/stable/SOURCES/graphviz-2.40.1.tar.gz
$ tar -xvf graphviz-2.40.1.tar.gz
$ cd graphviz-2.40.1
$ ./configure
$ make
$ cd cmd/dot
$ make dot_static
```
After that i packed dot_static in my Clojure application and call it programmatically. I want to generate pdf files.
Now i receive next error - `"/tmp/dot_static: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or directory"`.
So my question is - is it possible to somehow build lib fully packed with all it dependencies? So that it can be passed as one executable file and can generate pdf files?
Thank you.https://gitlab.com/graphviz/graphviz/-/issues/1255In recent versions, some edges in dot are routed through nodes2017-10-11T22:07:05ZJohn EllsonIn recent versions, some edges in dot are routed through nodes*Created by: fedarko*
Hi,
I've noticed a bug in recent versions of Graphviz where certain edges are being routed through nodes, even in cases where a more optimal (without any edge-node-crossings) routing seems to be available.
Th...*Created by: fedarko*
Hi,
I've noticed a bug in recent versions of Graphviz where certain edges are being routed through nodes, even in cases where a more optimal (without any edge-node-crossings) routing seems to be available.
This error seems to have been introduced some time after version 2.38.0 of Graphviz, since that version produces desirable edge routings for me while more recent versions (the oldest version I've observed with this problem is version 2.39.20160727.0821, but I haven't done a lot of testing on versions) produce "undesirable" edge routings.
For reference, I've enclosed the DOT file for a graph which exhibits this problem at the end of this post.
Running `dot` (Graphviz version 2.39.20160727.0821) on the enclosed graph produces the following drawing, with edge crossings through nodes c_B20_142_198_17, -35, 206, and -4:
<img src="https://user-images.githubusercontent.com/4177727/27998807-e4a55950-64e2-11e7-94cc-3a8ff7ddaf72.png" width=200 />
Running `dot` (Graphviz version 2.38.0) on the enclosed graph, however, produces the following (with no edge-node crossings) drawing:
<img src="https://user-images.githubusercontent.com/4177727/27998808-f1121a2a-64e2-11e7-8eea-91d2ece8a2bd.png" width=200 />
Here's the graph used to generate these images.
```
digraph asm {
edge [headport=n,tailport=s];
c_B20_142_198_17 [height=9.73611,width=3.125,shape=rectangle];
c_Bc40_c156_c69_65 [height=9.63889,width=3.125,shape=rectangle];
-35 [height=1.43136,width=1.1964,shape=house];
-4 [height=4.74461,width=2.17821,shape=house];
-199 [height=1.36173,width=1.16693,shape=house];
-200 [height=1,width=1,shape=house];
-201 [height=1,width=1,shape=house];
206 [height=1.25527,width=1.12039,shape=invhouse];
-158 [height=1,width=1,shape=house];
-159 [height=2.03743,width=1.42738,shape=house];
41 [height=2.5302,width=1.59066,shape=invhouse];
259 [height=1,width=1,shape=invhouse];
-127 [height=2.03342,width=1.42598,shape=house];
-61 [height=1.77085,width=1.33073,shape=house];
-62 [height=2.04532,width=1.43015,shape=house];
207 [height=1.11394,width=1.05544,shape=invhouse];
-279 [height=1.54407,width=1.24261,shape=house];
-63 [height=3.24527,width=1.80146,shape=house];
-35 -> c_B20_142_198_17
-35 -> -63
c_B20_142_198_17 -> -35
-4 -> -35
-199 -> -4
-199 -> -279
-200 -> -199
-200 -> 207
-201 -> -62
-201 -> -200
206 -> -201
c_Bc40_c156_c69_65 -> 206
-158 -> c_Bc40_c156_c69_65
-159 -> -158
41 -> -158
259 -> 41
259 -> -127
-127 -> c_Bc40_c156_c69_65
-61 -> -201
-62 -> -61
207 -> 206
-279 -> -61
-63 -> -159
-63 -> 259
}
```
Thanks!https://gitlab.com/graphviz/graphviz/-/issues/1270User registration and contact form broken on graphviz.org2020-06-08T01:28:39ZJohn EllsonUser registration and contact form broken on graphviz.org*Created by: Liam-Ryan*
Apologies for posting in the repo but I'm unable to register as a new user or contact the site admin using contact us on graphviz.org as the back-end seems to be down ( www.graphviz.org:8080)
I'm hoping someo...*Created by: Liam-Ryan*
Apologies for posting in the repo but I'm unable to register as a new user or contact the site admin using contact us on graphviz.org as the back-end seems to be down ( www.graphviz.org:8080)
I'm hoping someone who manages the repo has contact details for the site admin. https://gitlab.com/graphviz/graphviz/-/issues/1248[Dot] Output format plain edges wrong2017-10-11T22:07:06ZJohn Ellson[Dot] Output format plain edges wrong*Created by: yss14*
My input dot file
```
digraph{rankdir="LR";node[shape=box;width=3.5;height=3.5];101 -> {105};105 -> {106};106 -> {105};299011936 -> {101}}
```
If I choose svg or jpg as output format, the graph looks fine.
If I ...*Created by: yss14*
My input dot file
```
digraph{rankdir="LR";node[shape=box;width=3.5;height=3.5];101 -> {105};105 -> {106};106 -> {105};299011936 -> {101}}
```
If I choose svg or jpg as output format, the graph looks fine.
If I choose plain as output format, the edge's positions seems wrong.
```
graph 1 15.5 3.5
node 101 5.75 1.75 3.5 3.5 101 solid box black lightgrey
node 105 9.75 1.75 3.5 3.5 105 solid box black lightgrey
node 106 13.75 1.75 3.5 3.5 106 solid box black lightgrey
node 299011936 1.75 1.75 3.5 3.5 299011936 solid box black lightgrey
edge 101 105 4 7.5004 1.75 7.6189 1.75 7.7387 1.75 7.8579 1.75 solid black
edge 105 106 4 11.5 1.6569 11.619 1.6563 11.739 1.6561 11.858 1.6564 solid black
edge 106 105 4 11.998 1.8431 11.879 1.8437 11.759 1.8439 11.64 1.8436 solid black
edge 299011936 101 4 3.5004 1.75 3.6189 1.75 3.7387 1.75 3.8579 1.75 solid black
stop
```
Example:
```
node 299011936 1.75 1.75 3.5 3.5 299011936 solid box black lightgrey
```
It says that `x` starts at 1.75 and the rect is 3.5 inches long. So there should be an edge starting at x=5.25, right? But there isn't... Or is my interpretation of the output format wrong?
This is the output as jpg:
![test](https://user-images.githubusercontent.com/4346842/27262664-e24683d8-545b-11e7-85bc-adc2fd47ca59.jpg)
https://gitlab.com/graphviz/graphviz/-/issues/1269Error: remove_overlap: Graphviz not built with triangulation library in sfdp2023-09-16T11:59:51ZJohn EllsonError: remove_overlap: Graphviz not built with triangulation library in sfdp*Created by: trycmail*
Hi,
I got a error message in using sfdp command of graphviz, "Error: remove_overlap: Graphviz not built with triangulation library", but the dot,fdp ,etc are ok.
version: 2.41.338
platform: win7
download from: A...*Created by: trycmail*
Hi,
I got a error message in using sfdp command of graphviz, "Error: remove_overlap: Graphviz not built with triangulation library", but the dot,fdp ,etc are ok.
version: 2.41.338
platform: win7
download from: Appveyor( binary files.)
would you please help me.
Thanks a lot!https://gitlab.com/graphviz/graphviz/-/issues/1245graph_not_found error for DOT file2017-10-11T22:07:06ZJohn Ellsongraph_not_found error for DOT file*Created by: MBetters*
Hello,
I'm trying to use graphviz in the README markdown of a git repo at https://github.com/MBetters/avatar101. It is giving me a graph_not_found error. I tried to follow the example on https://bitbucket.org/TL...*Created by: MBetters*
Hello,
I'm trying to use graphviz in the README markdown of a git repo at https://github.com/MBetters/avatar101. It is giving me a graph_not_found error. I tried to follow the example on https://bitbucket.org/TLmaK0/gravizo-example/overview, except mine is slightly different since I'm using a DOT file instead of a UML file. I've been banging my head on this for a while. Any help is appreciated. Thanks!https://gitlab.com/graphviz/graphviz/-/issues/1266Suggestion: Add Crow's foot notation cardinality arrow types for Entity Relat...2023-01-03T04:52:38ZJohn EllsonSuggestion: Add Crow's foot notation cardinality arrow types for Entity Relationship diagrams*Created by: Sarke*
https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Cardinalities
![image](https://user-images.githubusercontent.com/2719310/29148000-7c8d3dd8-7d1f-11e7-9e91-2caf5074f6af.png)*Created by: Sarke*
https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Cardinalities
![image](https://user-images.githubusercontent.com/2719310/29148000-7c8d3dd8-7d1f-11e7-9e91-2caf5074f6af.png)https://gitlab.com/graphviz/graphviz/-/issues/1240How to get label2017-10-11T22:07:06ZJohn EllsonHow to get label*Created by: cqf00*
I want to get the label of a edge.
When I use agnameof , it return null.
What should I do?
Example:
test.gv
`digraph g{
"node a" -> "node b" [label="edge label"]
}`
c code:
fp = fopen("test.gv", "r");
...*Created by: cqf00*
I want to get the label of a edge.
When I use agnameof , it return null.
What should I do?
Example:
test.gv
`digraph g{
"node a" -> "node b" [label="edge label"]
}`
c code:
fp = fopen("test.gv", "r");
if (g = agread(fp, 0))
{
for (v = agfstnode(g); v; v = agnxtnode(g,v))
{
for (e = agfstout(g,v); e; e = agnxtout(g,e))
{
printf("agtail: %s\n", agnameof(agtail(e)));
printf("aghead: %s\n", agnameof(aghead(e)));
printf("edge: %s\n", agnameof(e));
}
}
}
Then, the result:
agtail: node a
aghead: node b
edge: (null)
https://gitlab.com/graphviz/graphviz/-/issues/1265dot.exe doesn't finish2021-03-20T02:05:13ZJohn Ellsondot.exe doesn't finish*Created by: helperman*
I use such a command to create a graph:
"C:\Program Files (x86)\Graphviz 2.41.20170804.1243\bin\dot.exe" -Tsvg -O -Kdot "C:\graph\inputBeta.graphviz"
Here is the input file:
https://drive.google.com/open?id=0B0q...*Created by: helperman*
I use such a command to create a graph:
"C:\Program Files (x86)\Graphviz 2.41.20170804.1243\bin\dot.exe" -Tsvg -O -Kdot "C:\graph\inputBeta.graphviz"
Here is the input file:
https://drive.google.com/open?id=0B0qHye1mDIyyZnFhcGVmYURDeG8
The issue is that dot.exe runs many hours and never ends...
Here is what I'm watching now during 1-2 hours:
http://storage3.static.itmages.ru/i/17/0807/h_1502127267_1893755_8b4f31d086.png
CPU utilization is full core:
http://storage8.static.itmages.ru/i/17/0807/h_1502127459_4232473_7fb3ae81fa.png
I try fdp.exe (sfdp.exe) and it gives the same issue.
Input file is not so heavy (~5500 lines).
The result is the same with 2.38 stable version and new beta versions (2.41.20170804.1243).https://gitlab.com/graphviz/graphviz/-/issues/1239labelangle, labeldistance are ignored (or user error)2017-10-11T22:07:06ZDavid Loyalllabelangle, labeldistance are ignored (or user error)They say a picture is worth 1000 words.
This graph...
digraph g {
a -> b [label="test",
labeldistance=20,
labelangle=10];
}
...compiled like this...
$ dot -Tpng -o TMP.p...They say a picture is worth 1000 words.
This graph...
digraph g {
a -> b [label="test",
labeldistance=20,
labelangle=10];
}
...compiled like this...
$ dot -Tpng -o TMP.png TMP.dot
...produces this output.
![image](https://cloud.githubusercontent.com/assets/1524866/25868017/13757ed8-34c1-11e7-8a4d-cfddbbe3aed4.png)
This OTHER graph, compile the same way, produces the SAME image.
digraph g {
a -> b [label="test",
labeldistance=-20,
labelangle=30];
}
I am using this dot:
$ dot -V
dot - graphviz version 2.41.20170503.1600 (20170503.1600)
Which I built myself on a 64bit debian machine using https://github.com/ellson/graphviz/commit/1bf033d2979b07416c4f42e09b90db133d88b877.
For what it is worth, I might be using the DOT language incorrectly, as I have done in another Issue recently...https://gitlab.com/graphviz/graphviz/-/issues/1263Avoidable Crossing, while respecting the tailport and headport2023-03-19T14:48:02ZJohn EllsonAvoidable Crossing, while respecting the tailport and headport*Created by: EnisOlgac*
This seems to be a bug. The edge from (6,2) to (2,3) should be drawn left to (3,6). This would avoid the crossings.
Here is the drawing:
![proc](https://user-images.githubusercontent.com/30180062/28940169-12ffab6...*Created by: EnisOlgac*
This seems to be a bug. The edge from (6,2) to (2,3) should be drawn left to (3,6). This would avoid the crossings.
Here is the drawing:
![proc](https://user-images.githubusercontent.com/30180062/28940169-12ffab6a-7894-11e7-9396-b8d2e6eb7d7a.png)
Here is the ".dot" file:
[Proc.dot.txt](https://github.com/ellson/graphviz/files/1198372/Proc.dot.txt)
Thanks, Enishttps://gitlab.com/graphviz/graphviz/-/issues/1238labelfontsize is ignored2017-10-11T22:07:06ZDavid Loyalllabelfontsize is ignoredThey say a picture is worth 1000 words.
This graph...
digraph g {
a -> b [label="test",labelfontsize="40"];
b [fontsize="40"];
}
...compiled like this...
$ dot -Tpng -o DONUTS-TMP.png DONUTS-TMP...They say a picture is worth 1000 words.
This graph...
digraph g {
a -> b [label="test",labelfontsize="40"];
b [fontsize="40"];
}
...compiled like this...
$ dot -Tpng -o DONUTS-TMP.png DONUTS-TMP.dot
...produces this output.
![image](https://cloud.githubusercontent.com/assets/1524866/25829829/81a64566-341e-11e7-8849-65978cbdb505.png)
I am using this dot:
$ dot -V
dot - graphviz version 2.41.20170503.1600 (20170503.1600)
Which I built myself on a 64bit debian machine using https://github.com/ellson/graphviz/commit/1bf033d2979b07416c4f42e09b90db133d88b877.
For what it is worth, `labelangle` and `labeldistance` don't seem to work either.https://gitlab.com/graphviz/graphviz/-/issues/1261missing endquote? longer than 163482021-03-17T03:48:35ZRichmond missing endquote? longer than 16348Is there away to increase this buffer or specify in somewhere?Is there away to increase this buffer or specify in somewhere?https://gitlab.com/graphviz/graphviz/-/issues/1237Building graphviz from source on Ubuntu (to add gts triangulation library)2017-10-11T22:07:06ZJohn EllsonBuilding graphviz from source on Ubuntu (to add gts triangulation library)*Created by: josephrocca*
When installing on ubuntu (16.04.2) with `sudo apt install graphviz`, I get the following error when trying to use `sfdp`:
```
Error: remove_overlap: Graphviz not built with triangulation library
```
Afte...*Created by: josephrocca*
When installing on ubuntu (16.04.2) with `sudo apt install graphviz`, I get the following error when trying to use `sfdp`:
```
Error: remove_overlap: Graphviz not built with triangulation library
```
After some searching I found out that it's because graphviz was built with `--without-gts` ([launchpad bug report](https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/1409280)). So I set about trying to build it myself (I'm new to this).
I followed the following procedure (from [this SO answer](http://stackoverflow.com/questions/34228395/ubuntu-graphviz-sfdp-not-working/42579735)):
1. run `sudo apt install libgts-dev`
2. run `sudo pkg-config --libs gts`
3. run `sudo pkg-config --cflags gts`
4. Download `graphviz-2.40.1.tar.gz` from [here](http://www.graphviz.org/Download_source.php)
5. Extract and run `sudo ./configure --with-gts --prefix ~` in the folder
6. Run `sudo make` in the folder
7. Run `sudo make install` in the folder
After doing that I can successfully use some commands (dot, fdp), but not others (sfdp, neato). I get `/usr/bin/sfdp: No such file or directory` when trying to use `sfdp`, for example. Can anyone see anything wrong with my procedure? Thanks!https://gitlab.com/graphviz/graphviz/-/issues/1260Crash of neato.exe -Tdot -n -Gsplines=ortho, and crash of dot.exe -Tdot -n -G...2023-02-07T12:40:09ZJohn EllsonCrash of neato.exe -Tdot -n -Gsplines=ortho, and crash of dot.exe -Tdot -n -Gsplines=ortho -Kneato*Created by: visubesy*
When executing neato.exe with certain input data, neato.exe crashes. I tried it on two systems, one being Windows 7 x64 and one being Windows 10 x64. On the Windows 7 system, the crashes seem to always occur. On ...*Created by: visubesy*
When executing neato.exe with certain input data, neato.exe crashes. I tried it on two systems, one being Windows 7 x64 and one being Windows 10 x64. On the Windows 7 system, the crashes seem to always occur. On the Windows 10 system, the crashes seem to occur in about 50% of the program calls (with identical input data).
I can reproduce the crashes with the following versions of neato.exe:
- neato - graphviz version 2.36.0 (20140111.2315)
- neato - graphviz version 2.38.0 (20140413.2041)
Unfortunately, there are no newer builds of graphviz / neato available for Windows.
Program arguments:
> neato.exe -Tdot -n -Gsplines=ortho
Program exit code (ERRORLEVEL):
> -1073741819
Error messages which are output by neato.exe:
> newtrap: Trapezoid-table overflow 1901
> newnode: Query-table overflow
> newnode: Query-table overflow
> newtrap: Trapezoid-table overflow 1901
Input data:
[graphviz-neato-crash.txt](https://github.com/ellson/graphviz/files/1162598/graphviz-neato-crash.txt)https://gitlab.com/graphviz/graphviz/-/issues/1258Digraph: separate loops in graph2023-03-19T14:50:13ZJohn EllsonDigraph: separate loops in graph*Created by: JohnCC330*
I have a state where two stimuli cause a 'local' loop. It seems that these are all generated in the same direction, but this creates a rather unclear graph. Is there any way to change the direction of one of the ...*Created by: JohnCC330*
I have a state where two stimuli cause a 'local' loop. It seems that these are all generated in the same direction, but this creates a rather unclear graph. Is there any way to change the direction of one of the loops? (looked at orientation, rotate, rotation, but they don't seem to have any effect)
![screenshot_2017-07-17_16-53-56](https://user-images.githubusercontent.com/3728987/28287366-c7fb4a78-6b11-11e7-8c9e-7a1e8023055d.png)https://gitlab.com/graphviz/graphviz/-/issues/1235Regression: some cgraph functions are not exported anymore2023-07-24T12:06:07ZJohn EllsonRegression: some cgraph functions are not exported anymore*Created by: Chiel92*
It seems that commit 003fd90cbc56f14a959e4fbf237ac325233f3ed9 fails to export several cgraph functions which were exported before, such as ageqedge, agtail, aghead.*Created by: Chiel92*
It seems that commit 003fd90cbc56f14a959e4fbf237ac325233f3ed9 fails to export several cgraph functions which were exported before, such as ageqedge, agtail, aghead.https://gitlab.com/graphviz/graphviz/-/issues/1234File not found while compiling from source (tag graphviz-stable_release_2.40.1)2017-10-11T22:07:06ZJohn EllsonFile not found while compiling from source (tag graphviz-stable_release_2.40.1)*Created by: araruna*
I downloaded the github commit tagged as I `graphviz-stable_release_2.40.1` and installed most of the optional libraries prior to the compilation of the software.
After having to install yacc and flex to continu...*Created by: araruna*
I downloaded the github commit tagged as I `graphviz-stable_release_2.40.1` and installed most of the optional libraries prior to the compilation of the software.
After having to install yacc and flex to continue building, make stopped with an error:
```
/bin/bash /home/araruna/Downloads/graphviz-stable_release_2.40.1/config/missing flex -i ../../lib/cgraph/scan.l
/bin/sed "s/yy/aag/g" < .c | /bin/sed '/extern.*isatty/d' > scan.c
/bin/bash: .c: Arquivo ou diretório não encontrado
rm .c
rm: não foi possível remover '.c': Arquivo ou diretório não encontrado
Makefile:1103: recipe for target 'scan.c' failed
make[3]: *** [scan.c] Error 1
```
I suppose there is a reference to an undefined bash variable in this line (to account for why there is a lonely `.c` there), but I cannot track where nor what is the correct variable name.
Because of this, I cannot finish the compilation.https://gitlab.com/graphviz/graphviz/-/issues/1232Nodes wandering into subgraphs2017-10-11T22:07:06ZJohn EllsonNodes wandering into subgraphs*Created by: conal*
Is there a way to get dot to leave nodes in the graph in which they're declared rather than in some subgraph? In particular, I'm seeing that if the only outgoing edges for a given "source node" land in a subgraph, th...*Created by: conal*
Is there a way to get dot to leave nodes in the graph in which they're declared rather than in some subgraph? In particular, I'm seeing that if the only outgoing edges for a given "source node" land in a subgraph, then the source node itself gets placed in that subgraph rather than the parent graph that declares the source node.
I stumbled onto a workaround: wrap *every* node in its own cluster subgraph. This practice somehow avoids the wandering node problem, but the resulting layouts are not as nice looking.
https://gitlab.com/graphviz/graphviz/-/issues/1231Edge ports can cause dot to crash2017-10-11T22:07:06ZJohn EllsonEdge ports can cause dot to crash*Created by: thomasdullien*
Hey there,
(Source line numbers refer to GV 2.36.0)
The attached example .dot file crashes dot in dotsplines.c, line 1301 - ED_label(auxe)
ends up being 0, and ED_label(auxe)->pos predictably segfaults...*Created by: thomasdullien*
Hey there,
(Source line numbers refer to GV 2.36.0)
The attached example .dot file crashes dot in dotsplines.c, line 1301 - ED_label(auxe)
ends up being 0, and ED_label(auxe)->pos predictably segfaults.
According to valgrind, an invalid write8 happens previously, in line 1231. I am unfortunately
too unfamiliar with all the macros in the codebase to judge exactly what is going on, but it
appears that cloneEdge does not work as expected. There are a few lines of code commented
out w/o further details - perhaps they are the culprit?
Cheers,
Thomas
[corrupt_tree_part.dot.txt](https://github.com/ellson/graphviz/files/943546/corrupt_tree_part.dot.txt)
https://gitlab.com/graphviz/graphviz/-/issues/1230Undefined symbols in build, cannot compile2017-10-11T22:07:06ZJohn EllsonUndefined symbols in build, cannot compile*Created by: emprice*
I am having trouble compiling `dot` on a Linux system. I get undefined symbols like `__log10_finite` and other similar math "_finite" variants. I am not sure where the problem originates. Google has been no help in...*Created by: emprice*
I am having trouble compiling `dot` on a Linux system. I get undefined symbols like `__log10_finite` and other similar math "_finite" variants. I am not sure where the problem originates. Google has been no help in isolating the issue. System details are below.
```
$ uname -a
Linux sabriel 2.6.32-642.15.1.el6.x86_64 #1 SMP Fri Feb 24 14:31:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
```https://gitlab.com/graphviz/graphviz/-/issues/1228OSError: [Errno 20] Not a directory2017-10-11T22:07:06ZJohn EllsonOSError: [Errno 20] Not a directory*Created by: mandarup*
System: MacOS
Python: 2.7.13 (brew)
graphviz (0.6)
code to reproduce error:
$python
>>>import graphviz as gv
>>>g = gv.Digraph(format='svg')
>>>g.node('A')
>>>g.node('B')
...*Created by: mandarup*
System: MacOS
Python: 2.7.13 (brew)
graphviz (0.6)
code to reproduce error:
$python
>>>import graphviz as gv
>>>g = gv.Digraph(format='svg')
>>>g.node('A')
>>>g.node('B')
>>>g.edge('A', 'B')
>>>print(g.source)
digraph {
A
B
A -> B
}
>>>g.render('g')
gives error:
---------------------------------------------------------------------------
OSError Traceback (most recent call last)
<ipython-input-21-252ffd7f8453> in <module>()
----> 1 g.render('g')
.../lib/python2.7/site-packages/graphviz/files.pyc in render(self, filename, directory, view, cleanup)
144 filepath = self.save(filename, directory)
145
--> 146 rendered = backend.render(self._engine, self._format, filepath)
147
148 if cleanup:
.../lib/python2.7/site-packages/graphviz/backend.pyc in render(engine, format, filepath)
93
94 try:
---> 95 subprocess.call(args, startupinfo=STARTUPINFO)
96 except OSError as e:
97 if e.errno == errno.ENOENT:
/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.pyc in call(*popenargs, **kwargs)
166 retcode = call(["ls", "-l"])
167 """
--> 168 return Popen(*popenargs, **kwargs).wait()
169
170
/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.pyc in __init__(self, args, bufsize, executable, stdin, stdout, stderr, preexec_fn, close_fds, shell, cwd, env, universal_newlines, startupinfo, creationflags)
388 p2cread, p2cwrite,
389 c2pread, c2pwrite,
--> 390 errread, errwrite)
391 except Exception:
392 # Preserve original exception in case os.close raises.
/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.pyc in _execute_child(self, args, executable, preexec_fn, close_fds, cwd, env, universal_newlines, startupinfo, creationflags, shell, to_close, p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite)
1022 raise
1023 child_exception = pickle.loads(data)
-> 1024 raise child_exception
1025
1026
OSError: [Errno 20] Not a directory
This behavior was originally observed and reported at https://github.com/dmlc/xgboost/issues/2174https://gitlab.com/graphviz/graphviz/-/issues/1225Memory fault on simple graphj2020-11-15T01:52:02ZJohn EllsonMemory fault on simple graphj*Created by: emden*
2.40.1 dot crashes on
```c
digraph G {
a -> b
{rank = sink c }
}
```
This works in 2.38. It also works if newrank=true.
The fault occurs during positioning, not ranking. The graph given to rank2 is ...*Created by: emden*
2.40.1 dot crashes on
```c
digraph G {
a -> b
{rank = sink c }
}
```
This works in 2.38. It also works if newrank=true.
The fault occurs during positioning, not ranking. The graph given to rank2 is not connected, though the new feasible_tree() routine explicitly requires this.
Interesting that the old network simplex worked with disconnected graphs. https://gitlab.com/graphviz/graphviz/-/issues/1257'Official' website does not accept registrations?2020-06-08T01:11:25ZJohn Ellson'Official' website does not accept registrations?*Created by: JohnCC330*
Sorry for posting this here, but I could not find any other way to contact anyone on Graphviz.
I've been trying for the last two days to register at the official webpage, but I never received the registration ...*Created by: JohnCC330*
Sorry for posting this here, but I could not find any other way to contact anyone on Graphviz.
I've been trying for the last two days to register at the official webpage, but I never received the registration information. On the Contact Us page, two status lines inform me that messages were sent to me, but they're not in my inbox or spam folder. Each try took about 1 minute to get a reply, as if there was a timeout.
I gather that research.att.com has something to do with the registering process, and that site does not respond. I have a graphviz question, but I'll post that as a separate issue.https://gitlab.com/graphviz/graphviz/-/issues/1252agedge() not using name?2021-05-31T17:48:06ZCasey Deccioagedge() not using name?pygraphviz's get_edge() calls libgraphviz's agedge() under the hood. Some behavior seemed to change with get_edge(), between version 2.38 and 2.39. Specifically, if I pass a key to get_edge() (which also gets passed as the "name" argum...pygraphviz's get_edge() calls libgraphviz's agedge() under the hood. Some behavior seemed to change with get_edge(), between version 2.38 and 2.39. Specifically, if I pass a key to get_edge() (which also gets passed as the "name" argument to agedge()) with version 2.39, it returns an edge, even if the key/name doesn't match. In 2.38 the same call would return KeyError. Of course, the latter is the expected/desired behavior.
Here is the pygraphviz code to reproduce it:
Version 2.38:
>>> from pygraphviz import AGraph
>>> g = AGraph(directed=True)
>>> g.add_edge('a','b','123')
>>> g.get_edge('a','b','456')
Traceback (most recent call last):
...
KeyError: 'Edge a-b not in graph.'
Version 2.39:
>>> from pygraphviz import AGraph
>>> g = AGraph(directed=True)
>>> g.add_edge('a','b','123')
>>> g.get_edge('a','b','456')
(u'a', u'b')
Was this an intended API change or a regression?https://gitlab.com/graphviz/graphviz/-/issues/1250How to change the orientation of a node or a edge's label?2022-06-17T03:54:52ZJohn EllsonHow to change the orientation of a node or a edge's label?*Created by: trycmail*
Dear sir,
I'm a new user of graphviz, and find its powerful functions in drawing. In neato layout, some times I want to change the orientation of a node or edge's label(some time it's very important. ),...*Created by: trycmail*
Dear sir,
I'm a new user of graphviz, and find its powerful functions in drawing. In neato layout, some times I want to change the orientation of a node or edge's label(some time it's very important. ), just like the attach file as below:
![we](https://user-images.githubusercontent.com/29050991/27381463-87f502ea-56b5-11e7-840b-fd5d92f3b12d.png)
But I don't know how to achieve it even looking through all documents at [Graphviz Website](http://www.graphviz.org/Documentation.php). Would you please help me or give me some advice?
Tanks very much!https://gitlab.com/graphviz/graphviz/-/issues/1249dot.exe crash2020-07-03T22:12:18ZJohn Ellsondot.exe crash*Created by: helperman*
I run such a command:
"C:\Program Files (x86)\Graphviz2.38\bin\dot.exe" -Tsvg -O -Kdot "C:\input.graphviz"
Here is contents of a graphviz-file:
https://drive.google.com/open?id=0B_05wItrOvX_bFJkcHl0bTdqWGs
Resu...*Created by: helperman*
I run such a command:
"C:\Program Files (x86)\Graphviz2.38\bin\dot.exe" -Tsvg -O -Kdot "C:\input.graphviz"
Here is contents of a graphviz-file:
https://drive.google.com/open?id=0B_05wItrOvX_bFJkcHl0bTdqWGs
Result is crash:
http://storage5.static.itmages.ru/i/17/0619/h_1497880059_1190823_4cfe7b5fb0.png
Yes, it is a very big and it contains lots of lines.
But I can't do anything. I need it.
I need to use svg-format as the most powerfull output.
It crashes.
Why?
What can I do to fix it?https://gitlab.com/graphviz/graphviz/-/issues/1246long edges in 2.402024-02-26T06:08:08ZJohn Ellsonlong edges in 2.40*Created by: emden*
With the attached file, the lengths of some edges are too long. This occurs in 2.40 but not 2.38. It appears the rank distances are not being set correctly in the cluster. The extra ranks are added to handle the edge...*Created by: emden*
With the attached file, the lengths of some edges are too long. This occurs in 2.40 but not 2.38. It appears the rank distances are not being set correctly in the cluster. The extra ranks are added to handle the edge labels, but the rank distance is not cut in half. Removing the edge labels, or making them xlabels, or using newrank=true act as workarounds.
[lng.gv.txt](https://github.com/ellson/graphviz/files/1066628/lng.gv.txt)
https://gitlab.com/graphviz/graphviz/-/issues/1244Please help for graphviz building !2020-06-27T02:18:01ZJohn EllsonPlease help for graphviz building !*Created by: trycmail*
Dear sir, I'm a new user of graphviz, and can't buid it with the guidance on windows platform for many times. The old version of graphviz 2.38 is three years before and has some bugs in using.Would you please...*Created by: trycmail*
Dear sir, I'm a new user of graphviz, and can't buid it with the guidance on windows platform for many times. The old version of graphviz 2.38 is three years before and has some bugs in using.Would you please update the binary installer quickly as the sourcecode? Or make a detailed steps of graphviz building (on window platform) with text or video? There would be more dummy persons(just like me) can use the latest graphviz, even if little knowledge about programming.
Tanks a lot.
https://gitlab.com/graphviz/graphviz/-/issues/1242Graphviz aliases memory.h and malloc.h2020-10-05T15:01:11ZJohn EllsonGraphviz aliases memory.h and malloc.h*Created by: AstralStorm*
Graphviz is aliasing system headers memory.h and malloc.h.
This causes build failures against libc different than glibc, for example with bionic.
Additionally quite a few source files include <memory.h> w...*Created by: AstralStorm*
Graphviz is aliasing system headers memory.h and malloc.h.
This causes build failures against libc different than glibc, for example with bionic.
Additionally quite a few source files include <memory.h> while they should be using the graphviz version.https://gitlab.com/graphviz/graphviz/-/issues/1226newrank=true does not handle source/min/max/sink correctly.2023-02-11T16:46:35ZJohn Ellsonnewrank=true does not handle source/min/max/sink correctly.*Created by: emden*
If the graph
```c
digraph {
a -> b
{ rank=source c]
{ rank=sink d}
}
```
is processed with dot -Gnewrank, c and d are placed on the same rank as a.
![out](https://cloud.githubusercontent.com/assets/1530174/2...*Created by: emden*
If the graph
```c
digraph {
a -> b
{ rank=source c]
{ rank=sink d}
}
```
is processed with dot -Gnewrank, c and d are placed on the same rank as a.
![out](https://cloud.githubusercontent.com/assets/1530174/24715848/f8225f24-19fa-11e7-9a0f-1ef34906fc65.png)
The expected output is
![out0](https://cloud.githubusercontent.com/assets/1530174/24715906/2eafacc2-19fb-11e7-9899-76b44e09f7f2.png)
The same happens if source and sink are replaced by min and max.https://gitlab.com/graphviz/graphviz/-/issues/1223Two edges are rendered though the input contains only one2021-03-20T02:07:43ZJohn EllsonTwo edges are rendered though the input contains only one*Created by: sinopalnikov*
For the following graph the output is incorrect in both 2.38 and 2.40:
```digraph graph3 {
subgraph cluster_0 {
"Naming"
"lily"
}
subgraph cluster_1 {
"daughter"
"speaker"
}
"daughter" -> "speaker" [...*Created by: sinopalnikov*
For the following graph the output is incorrect in both 2.38 and 2.40:
```digraph graph3 {
subgraph cluster_0 {
"Naming"
"lily"
}
subgraph cluster_1 {
"daughter"
"speaker"
}
"daughter" -> "speaker" [constraint="false"]
"Naming" -> "daughter" [constraint="false" ]
"Naming" -> "lily" [constraint="false" ]
}
```
Output:
<img width="500" alt="output" src="https://cloud.githubusercontent.com/assets/5305828/24640043/2a4f24b2-18f4-11e7-9353-b7db864f9cef.png">
There are two edges from "Naming" to "daughter" in the output. while there is only one in the input.
In SVG output there are 2 paths for a single edge:
```
<g xmlns="http://www.w3.org/2000/svg" id="edge2" class="edge" style="cursor: pointer;">
<title>Naming->daughter</title>
<path fill="none" stroke="black" d="M146.435,-50.0898C157.188,-58.3894 171.465,-67.6626 186,-72 222.2,-82.8027 234.888,-83.0955 271,-72 281.554,-68.7573 291.905,-62.7752 300.78,-56.5016"/>
<polygon fill="black" stroke="black" points="302.905,-59.2833 308.796,-50.4774 298.699,-53.6875 302.905,-59.2833"/>
<path fill="none" stroke="black" d="M143.257,-50.7887C155.2,-62.6037 172.935,-77.4358 192,-84 222.677,-94.5625 234.406,-94.7993 265,-84 279.9,-78.7407 293.851,-68.2149 304.731,-58.1719"/>
<polygon fill="black" stroke="black" points="307.351,-60.5067 312.081,-51.0265 302.471,-55.4876 307.351,-60.5067"/>
</g>
```
https://gitlab.com/graphviz/graphviz/-/issues/1222Combination of newrank and packmode=graph loses clusters2022-05-27T02:10:53ZJohn EllsonCombination of newrank and packmode=graph loses clusters*Created by: emden*
Running dot -Gnewrank -Grankmode=graph on the following graph loses the clusters on output:
```C
digraph {
subgraph "cluster_1" {
1;
}
subgraph "cluster_2" {
...*Created by: emden*
Running dot -Gnewrank -Grankmode=graph on the following graph loses the clusters on output:
```C
digraph {
subgraph "cluster_1" {
1;
}
subgraph "cluster_2" {
2
}
}
```
Related issue [#1221 ](https://github.com/ellson/graphviz/issues/1221)https://gitlab.com/graphviz/graphviz/-/issues/1221Segmentation fault when newrank=true2020-11-07T02:10:12ZJohn EllsonSegmentation fault when newrank=true*Created by: Chiel92*
Consider the following dot code:
```
digraph "Graph d718cbc6-5e20-4417-a41a-e1e380469dd2" {
graph [
newrank=true
];
subgraph "cluster_1" {
1;
}
subgraph "cluster_2" {
1
}
}
```
Then ru...*Created by: Chiel92*
Consider the following dot code:
```
digraph "Graph d718cbc6-5e20-4417-a41a-e1e380469dd2" {
graph [
newrank=true
];
subgraph "cluster_1" {
1;
}
subgraph "cluster_2" {
1
}
}
```
Then running dot on this will segfault.
```
$ cat ~/Desktop/repro.txt | ./dot.exe -Tpng > after.png
Segmentation fault
````
However, the old ranking algorithm will not segfault on this. Is this a bug in the new ranking algorithm?https://gitlab.com/graphviz/graphviz/-/issues/1219New Windows Release2020-06-01T00:25:24ZJohn EllsonNew Windows Release*Created by: cdrnet*
Is there any chance to get a more up to date release for windows? I'm affected by quite a few issues and crashes of dot.exe which are supposedly fixed or at least improved since 2.38 (which is the latest Windows re...*Created by: cdrnet*
Is there any chance to get a more up to date release for windows? I'm affected by quite a few issues and crashes of dot.exe which are supposedly fixed or at least improved since 2.38 (which is the latest Windows release, from early 2014)
Building myself on Windows is not trivial, and even if I would manage to compile myself, the users of my software still need a stable version. Thanks!https://gitlab.com/graphviz/graphviz/-/issues/1214Non-determinancy in fdp2024-02-27T07:34:07ZJohn EllsonNon-determinancy in fdp*Created by: emden*
The output from running fdp on the regression test file rtests/graph/fdp.gv can change between runs. This appears unrelated to the use of drand, as the seed is always set the same in every run. There appear to be jus...*Created by: emden*
The output from running fdp on the regression test file rtests/graph/fdp.gv can change between runs. This appears unrelated to the use of drand, as the seed is always set the same in every run. There appear to be just two possible outcomes, related to order of two edges in a derived subgraph. So the question is, why does the ordering change?https://gitlab.com/graphviz/graphviz/-/issues/1213Error: trouble in init_rank2024-02-26T12:51:18ZJohn EllsonError: trouble in init_rank*Created by: johnwickerson*
If I compile the following .dot file (which I've minimised as much as I can):
```
digraph G {
V4
V0
V2
subgraph cluster_0 {
V3
V1
}
subgraph cluster_1 {
V10
V5
V11
}
subgraph cluster_2 {
V9
V8
V6
}
V7
V0...*Created by: johnwickerson*
If I compile the following .dot file (which I've minimised as much as I can):
```
digraph G {
V4
V0
V2
subgraph cluster_0 {
V3
V1
}
subgraph cluster_1 {
V10
V5
V11
}
subgraph cluster_2 {
V9
V8
V6
}
V7
V0 -> V3 [constraint=false]
V4 -> V0
V3 -> V1
V0 -> V2 [constraint=false]
V10 -> V6 [label=a,constraint=false]
V11 -> V10
V9 -> V8
V6 -> V9
V5 -> V11
V10 -> V7 [constraint=false]
V4 -> V5 [constraint=false]
V3 -> V6 [constraint=false]
V2 -> V7 [constraint=false]
V1 -> V9 [label=b,constraint=false]
V1 -> V8
V0 -> V11 [constraint=false]
V0 -> V10
}
```
using the `dot -Tpng` command, with graphviz version 2.38.0 (20140413.2041) on Mac OS, then I get the following error message:
```
Error: trouble in init_rank
%0 1
%0 1
%0 1
V1 1
%0 2
%0 1
V7 1
V2 1
%0 1
libpath/shortest.c:324: triangulation failed
libpath/shortest.c:192: source point not in any triangle
Error: in routesplines, Pshortestpath failed
Error: lost V1 V9 edge
```https://gitlab.com/graphviz/graphviz/-/issues/1211[cgraph, dot] How to turn a subgraph into a cluster?2023-03-29T02:36:55ZJohn Ellson[cgraph, dot] How to turn a subgraph into a cluster?*Created by: Chiel92*
In C code, how can I turn an existing subgraph into a cluster? I haven't found a function in `cgraph.h` that renames subgraphs. The latter would allow you to prepend a subgraph with 'cluster', effectively turning i...*Created by: Chiel92*
In C code, how can I turn an existing subgraph into a cluster? I haven't found a function in `cgraph.h` that renames subgraphs. The latter would allow you to prepend a subgraph with 'cluster', effectively turning it into a cluster. Are there other ways to accomplish this?https://gitlab.com/graphviz/graphviz/-/issues/1209[Dot] segfault when cluster and rank subgraph have the same node2021-03-20T02:22:07ZJohn Ellson[Dot] segfault when cluster and rank subgraph have the same node*Created by: Chiel92*
Example dot input:
```dot
digraph "Name" {
subgraph "cluster_foo" {
"n1";
}
subgraph "rank-1" {
graph [rank=same];
"n1";
}
}
```
```
$ cat ~/Desktop/dump1.dot | ./dot.exe -...*Created by: Chiel92*
Example dot input:
```dot
digraph "Name" {
subgraph "cluster_foo" {
"n1";
}
subgraph "rank-1" {
graph [rank=same];
"n1";
}
}
```
```
$ cat ~/Desktop/dump1.dot | ./dot.exe -Tpng > ~/Desktop/dump1.png
Segmentation fault
```
I'd say that is a bug, correct?https://gitlab.com/graphviz/graphviz/-/issues/1206cgraph: how to add an existing subgraph to another subgraph?2023-01-23T18:17:10ZJohn Ellsoncgraph: how to add an existing subgraph to another subgraph?*Created by: Chiel92*
From the cgraph tutorial Chapter 9 "Subgraphs":
> It is not uncommon to want to populate a subgraph with nodes and edges that
have already been created. This can be done using the functions agsubnode and
agsubedge...*Created by: Chiel92*
From the cgraph tutorial Chapter 9 "Subgraphs":
> It is not uncommon to want to populate a subgraph with nodes and edges that
have already been created. This can be done using the functions agsubnode and
agsubedge,
How can we add an already existing subgraph to another subgraph? For nodes and edges there are functions available, but for subgraphs that doesn't seem to be case.https://gitlab.com/graphviz/graphviz/-/issues/1199Unexpected artifacts in png output after deleting node2020-06-25T14:11:09ZJohn EllsonUnexpected artifacts in png output after deleting node*Created by: Chiel92*
Consider the following bit of test code.
```c++
void dump(Agraph_t* root, string filename)
{
GVC_t* gvc = gvContext();
imagwrite(root, (filename + ".dot").c_str());
gvLayout(gvc, root, "dot");
...*Created by: Chiel92*
Consider the following bit of test code.
```c++
void dump(Agraph_t* root, string filename)
{
GVC_t* gvc = gvContext();
imagwrite(root, (filename + ".dot").c_str());
gvLayout(gvc, root, "dot");
gvRenderFilename(gvc, root, "png", (filename + ".png").c_str());
}
void imdebug()
{
Agraph_t* root = agopen("test root graph", Agdirected, &memDisc);
Agnode_t* n1 = agnode(root, "x", 1);
Agnode_t* n2 = agnode(root, "xx", 1);
Agnode_t* n3 = agnode(root, "xxx", 1);
Agnode_t* n4 = agnode(root, "xxxx", 1);
agedge(root, n2, n4, "1", 1);
agedge(root, n3, n4, "1", 1);
agedge(root, n1, n2, "1", 1);
agedge(root, n2, n1, "2", 1);
agedge(root, n1, n3, "1", 1);
agedge(root, n3, n1, "2", 1);
agedge(root, n2, n3, "1", 1);
agedge(root, n3, n2, "2", 1);
dump(root, "C:\\Users\\chiel.tenbrinke\\Desktop\\dump1");
agdelete(root, n1);
dump(root, "C:\\Users\\chiel.tenbrinke\\Desktop\\dump2");
}
```
dump1.png:
![dump1](https://cloud.githubusercontent.com/assets/1030961/22247434/17b9415c-e23a-11e6-8ee6-bfc04f87b547.png)
dump2.png:
![dump2](https://cloud.githubusercontent.com/assets/1030961/22247435/17bafc90-e23a-11e6-9c1d-642077b66569.png)
As you see, there are two seemingly stale edges partially visible in dump2.png that I wouldn't expect there. The contents of the dot dumps is as follows.
dump1.dot:
```dot
digraph "test root graph" {
graph [bb="0 0 109 252"];
node [label="\N"];
xx -> xxx [key=1];
xx -> xxxx [key=1];
xxx -> xx [key=2];
xxx -> xxxx [key=1];
}
```
dump2.dot:
```dot
digraph "test root graph" {
x -> xx [key=1];
x -> xxx [key=1];
xx -> x [key=2];
xx -> xxx [key=1];
xx -> xxxx [key=1];
xxx -> x [key=2];
xxx -> xx [key=2];
xxx -> xxxx [key=1];
}
```
As you see there is no trace of these stale edges in the dot representation. This seems like a bug to me, or am I doing something wrong?
---
The identifiers `imagwrite` and `memDisc` have to do with the custom IO discipline I'm using. If needed I can upload the discipline code as well.
https://gitlab.com/graphviz/graphviz/-/issues/1182linking against lua5.12021-11-20T04:46:43ZJohn Ellsonlinking against lua5.1*Created by: gborghesan*
Hi,
I am trying to specify to link against liblua5.1 in a ubuntu 14.04 where both 5.1 and 5.2 are installed
i tried to configure with
```
> ./configure --disable-perl LUA_VERSION=5.1
```
after making
i get:
`...*Created by: gborghesan*
Hi,
I am trying to specify to link against liblua5.1 in a ubuntu 14.04 where both 5.1 and 5.2 are installed
i tried to configure with
```
> ./configure --disable-perl LUA_VERSION=5.1
```
after making
i get:
```
> ldd /home/gb/temp/graphviz/tclpkg/gv/.libs/libgv_lua.so
...
liblua5.2.so.0 => /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
...
```
any help is welcome!https://gitlab.com/graphviz/graphviz/-/issues/1180Format: "pdf" not recognized.2020-06-17T14:00:19ZBalaFormat: "pdf" not recognized.Hi,
I have built graphviz 2.38.0 from source. I am using ubuntu 1404.
Installation is missing "pdf" plugins. I tired all options in documentation.
Kindly help to resolve this issue.
ubuntu1404@balraj01> dot -v
dot - graphviz...Hi,
I have built graphviz 2.38.0 from source. I am using ubuntu 1404.
Installation is missing "pdf" plugins. I tired all options in documentation.
Kindly help to resolve this issue.
ubuntu1404@balraj01> dot -v
dot - graphviz version 2.38.0 (20140413.2041)
libdir = “/opt/graphviz-2.38.0/lib/graphviz"
Activated plugin library: libgvplugin_dot_layout.so.6
Using layout: dot:dot_layout
Activated plugin library: libgvplugin_core.so.6
Using render: dot:core
Using device: dot:dot:core
The plugin configuration file:
/opt/graphviz-2.38.0/lib/graphviz/config6
was successfully loaded.
render : dot fig gd map pic pov ps svg tk vml vrml xdot
layout : circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi
textlayout : textlayout
device : canon cmap cmapx cmapx_np dot eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg pic plain plain-ext png pov ps ps2 svg svgz tk vml vmlz vrml wbmp xdot xdot1.2 xdot1.4
loadimage : (lib) eps gd gd2 gif jpe jpeg jpg png ps svg xbm
**ERROR:**
**ubuntu1404@balraj01> echo "graph test {}" | dot -Tpdf -o test.pdf
Format: "pdf" not recognized. Use one of: canon cmap cmapx cmapx_np dot eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg pic plain plain-ext png pov ps ps2 svg svgz tk vml vmlz vrml wbmp xdot xdot1.2 xdot1.4
ubuntu1404@balraj01>ubuntu1404@balraj01>**https://gitlab.com/graphviz/graphviz/-/issues/1288Label on edge causes issue with GraphViz 2.40.12024-02-26T06:08:09ZPlantUMLLabel on edge causes issue with GraphViz 2.40.1Putting a label on edge sometimes creates strange results with GraphViz 2.40.1: the generated edge is very long.
The same DOT source works fine with GrappViz 2.38
Removing the label on the edge also solves the issue.
You can try with ...Putting a label on edge sometimes creates strange results with GraphViz 2.40.1: the generated edge is very long.
The same DOT source works fine with GrappViz 2.38
Removing the label on the edge also solves the issue.
You can try with this snippet:
```
digraph unix {
nodesep=0.486111;
ranksep=0.833333;
remincross=true;
searchsize=500;
subgraph cluster4p0 {label="";subgraph cluster4 {style=solid;color="0000004";label=<<TABLE BGCOLOR="0000005" FIXEDSIZE="TRUE" WIDTH="60" HEIGHT="12"><TR><TD></TD></TR></TABLE>>;
subgraph cluster4p1 {label="";
sh0006 [shape=rect,label="",width=0.944444,height=0.666667,color="0000006"];
sh0007 [shape=rect,label="",width=0.722222,height=0.666667,color="0000007"];
}}}
sh0006->sh0007[arrowtail=none,arrowhead=empty,arrowsize=2.0,minlen=1,color="0000008",label=<<TABLE BGCOLOR="0000009" FIXEDSIZE="TRUE" WIDTH="69" HEIGHT="18"><TR><TD></TD></TR></TABLE>>];
}
```
Thankshttps://gitlab.com/graphviz/graphviz/-/issues/1289Having several clusters causes too long edge display with Graphviz/Dot 2.392024-02-26T06:08:09ZPlantUMLHaving several clusters causes too long edge display with Graphviz/Dot 2.39If you try the following graph, you will get a very long edge.
This is working fine with Graphviz/Dot 2.38
```
digraph unix {
subgraph cluster1 {
subgraph cluster2 {
subgraph cluster3 {
sh0006;
sh0007;
}
}
}
sh0006->sh0007[label=<<TABLE...If you try the following graph, you will get a very long edge.
This is working fine with Graphviz/Dot 2.38
```
digraph unix {
subgraph cluster1 {
subgraph cluster2 {
subgraph cluster3 {
sh0006;
sh0007;
}
}
}
sh0006->sh0007[label=<<TABLE FIXEDSIZE="TRUE" WIDTH="44" HEIGHT="18"><TR><TD></TD></TR></TABLE>>];
}
```
Is it possible to fix this ?
Thankshttps://gitlab.com/graphviz/graphviz/-/issues/1176Graphviz for euler diagrams.2020-07-03T22:10:38ZJohn EllsonGraphviz for euler diagrams.*Created by: fminkin*
Hello!
My problem is to draw euler's diagram from data.
I found an info on the Internet, that gvmap can generate euler's diagrams, how can it be established? There's no documentation whatsoever. So, can it help me?...*Created by: fminkin*
Hello!
My problem is to draw euler's diagram from data.
I found an info on the Internet, that gvmap can generate euler's diagrams, how can it be established? There's no documentation whatsoever. So, can it help me?
I will really appreciate the answer.https://gitlab.com/graphviz/graphviz/-/issues/1174Can't download grappa package2020-07-03T22:10:20ZJohn EllsonCan't download grappa package*Created by: lingvisa*
I always got a message after clicking the link http://www.research.att.com/~john/Grappa/grappa.tgz:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this ad...*Created by: lingvisa*
I always got a message after clicking the link http://www.research.att.com/~john/Grappa/grappa.tgz:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.
I disabled the cookie in Firefox and does't solve the problem.https://gitlab.com/graphviz/graphviz/-/issues/1173[Dot] "Error: trouble in init_rank" puzzle finally solved!2024-01-15T07:55:47ZJohn Ellson[Dot] "Error: trouble in init_rank" puzzle finally solved!*Created by: ens-lg4*
Dear GraphViz developers,
We were migrating our software that uses "dot" for graph generation to another RedHat Linux machine. I was puzzled by the fact that the same code behaved differently on two computers, alt...*Created by: ens-lg4*
Dear GraphViz developers,
We were migrating our software that uses "dot" for graph generation to another RedHat Linux machine. I was puzzled by the fact that the same code behaved differently on two computers, although we made sure all the installed packages/libraries were the same. The same version of "dot" (actually the same binary living on a shared mounted filesystem) with the same input file was working fine on one computer and throwing the infamous "trouble in init_rank" error on another.
Today we finally tracked it down to a single culprit: the availability of Type1 fonts in /usr/share/fonts/ !
There is a clear 100% correlation: adding the files solves the problem, removing the files causes the "trouble in init_rank" kind of crash.
Apparently, before laying out the graph "dot" uses (possibly indirectly, via png/svg libraries?) system's font files to estimate sizes of text-containing elements. For some reason, the failure to find those files is not properly caught/reported, but the missing data somehow causes that "trouble in init_rank".
It was very confusing that for smaller graphs there was no crash. Probably, this dependence on font files is masked by some other, stronger conditions.
The same behaviour has been seen in "dot" versions from 2.28.0 through 2.38.0 (under Ubuntu and RedHat). The test file has been attached. To replicate you can either move files out of and back into /usr/share/fonts or simply change font paths in /etc/fonts/fonts.conf to temporarily mask the actual font files.
Thank you in advance for looking into this!
[trouble_in_init_rank.zip](https://github.com/ellson/graphviz/files/606634/trouble_in_init_rank.zip)https://gitlab.com/graphviz/graphviz/-/issues/1169[Dot] segfault: clusters + records + constraint=false2020-10-30T03:04:41ZAleks-Daniel Jakimenko-Aleksejev[Dot] segfault: clusters + records + constraint=falseHere is the shortest example that crashes:
Code:
```dot
digraph segfault {
rankdir = LR;
subgraph cluster_module {
one [shape=record, label="{<foo>foo|<bar>bar}"];
two [shape=record, label="<foo>foo|<bar>bar"];
...Here is the shortest example that crashes:
Code:
```dot
digraph segfault {
rankdir = LR;
subgraph cluster_module {
one [shape=record, label="{<foo>foo|<bar>bar}"];
two [shape=record, label="<foo>foo|<bar>bar"];
}
one:bar -> baz;
edge [constraint=false];
one:foo -> two:foo;
one:bar -> two:bar;
}
```
Result:
```
Warning: Unable to reclaim box space in spline routing for edge "one" -> "two". Something is probably seriously wrong.
Warning: Unable to reclaim box space in spline routing for edge "one" -> "two". Something is probably seriously wrong.
*** Error in `dot': double free or corruption (fasttop): 0x0000563ec4d8d4d0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f91b8997bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7f91b899dfa6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7f91b899e79e]
/usr/lib/libgvc.so.6(gv_free_splines+0x33)[0x7f91b8f37ea3]
/usr/lib/libgvc.so.6(gv_cleanup_edge+0x1c)[0x7f91b8f37f0c]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(dot_cleanup+0x138)[0x7f91b33c2108]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(+0x1db30)[0x7f91b33d3b30]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(+0x1a7a4)[0x7f91b33d07a4]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(+0xbe5d)[0x7f91b33c1e5d]
/usr/lib/graphviz/libgvplugin_dot_layout.so.6(dot_layout+0x338)[0x7f91b33c24c8]
/usr/lib/libgvc.so.6(gvLayoutJobs+0xd2)[0x7f91b8efdd12]
dot(+0xfa0)[0x563ec4866fa0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f91b89472b1]
dot(+0x103a)[0x563ec486703a]
======= Memory map: ========
563ec4866000-563ec4868000 r-xp 00000000 00:13 5516953 /usr/bin/dot
563ec4a67000-563ec4a68000 r--p 00001000 00:13 5516953 /usr/bin/dot
563ec4a68000-563ec4a69000 rw-p 00002000 00:13 5516953 /usr/bin/dot
563ec4d22000-563ec4ddd000 rw-p 00000000 00:00 0 [heap]
7f91ac000000-7f91ac021000 rw-p 00000000 00:00 0
7f91ac021000-7f91b0000000 ---p 00000000 00:00 0
7f91b319f000-7f91b31b5000 r-xp 00000000 00:13 5451529 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f91b31b5000-7f91b33b4000 ---p 00016000 00:13 5451529 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f91b33b4000-7f91b33b5000 r--p 00015000 00:13 5451529 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f91b33b5000-7f91b33b6000 rw-p 00016000 00:13 5451529 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f91b33b6000-7f91b33da000 r-xp 00000000 00:13 5516882 /usr/lib/graphviz/libgvplugin_dot_layout.so.6.0.0
7f91b33da000-7f91b35d9000 ---p 00024000 00:13 5516882 /usr/lib/graphviz/libgvplugin_dot_layout.so.6.0.0
7f91b35d9000-7f91b35da000 r--p 00023000 00:13 5516882 /usr/lib/graphviz/libgvplugin_dot_layout.so.6.0.0
7f91b35da000-7f91b35db000 rw-p 00024000 00:13 5516882 /usr/lib/graphviz/libgvplugin_dot_layout.so.6.0.0
7f91b35db000-7f91b35e3000 rw-p 00000000 00:00 0
7f91b35e3000-7f91b35fd000 r-xp 00000000 00:13 5516881 /usr/lib/graphviz/libgvplugin_core.so.6.0.0
7f91b35fd000-7f91b37fc000 ---p 0001a000 00:13 5516881 /usr/lib/graphviz/libgvplugin_core.so.6.0.0
7f91b37fc000-7f91b37fd000 r--p 00019000 00:13 5516881 /usr/lib/graphviz/libgvplugin_core.so.6.0.0
7f91b37fd000-7f91b3801000 rw-p 0001a000 00:13 5516881 /usr/lib/graphviz/libgvplugin_core.so.6.0.0
7f91b3801000-7f91b3807000 r-xp 00000000 00:13 5528181 /usr/lib/x86_64-linux-gnu/libdatrie.so.1.3.3
7f91b3807000-7f91b3a07000 ---p 00006000 00:13 5528181 /usr/lib/x86_64-linux-gnu/libdatrie.so.1.3.3
7f91b3a07000-7f91b3a08000 r--p 00006000 00:13 5528181 /usr/lib/x86_64-linux-gnu/libdatrie.so.1.3.3
7f91b3a08000-7f91b3a09000 rw-p 00007000 00:13 5528181 /usr/lib/x86_64-linux-gnu/libdatrie.so.1.3.3
7f91b3a09000-7f91b3a2c000 r-xp 00000000 00:13 135663 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1
7f91b3a2c000-7f91b3c2c000 ---p 00023000 00:13 135663 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1
7f91b3c2c000-7f91b3c2e000 r--p 00023000 00:13 135663 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1
7f91b3c2e000-7f91b3c2f000 rw-p 00025000 00:13 135663 /usr/lib/x86_64-linux-gnu/libgraphite2.so.3.0.1
7f91b3c2f000-7f91b3c34000 r-xp 00000000 00:13 123334 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f91b3c34000-7f91b3e33000 ---p 00005000 00:13 123334 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f91b3e33000-7f91b3e34000 r--p 00004000 00:13 123334 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f91b3e34000-7f91b3e35000 rw-p 00005000 00:13 123334 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f91b3e35000-7f91b3e38000 r-xp 00000000 00:13 36116 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f91b3e38000-7f91b4037000 ---p 00003000 00:13 36116 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f91b4037000-7f91b4038000 r--p 00002000 00:13 36116 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f91b4038000-7f91b4039000 rw-p 00003000 00:13 36116 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f91b4039000-7f91b40ab000 r-xp 00000000 00:13 3105192 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
7f91b40ab000-7f91b42aa000 ---p 00072000 00:13 3105192 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
7f91b42aa000-7f91b42ab000 r--p 00071000 00:13 3105192 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
7f91b42ab000-7f91b42ac000 rw-p 00072000 00:13 3105192 /lib/x86_64-linux-gnu/libpcre.so.3.13.3
7f91b42ac000-7f91b42b3000 r-xp 00000000 00:13 3405072 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f91b42b3000-7f91b44b3000 ---p 00007000 00:13 3405072 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f91b44b3000-7f91b44b4000 r--p 00007000 00:13 3405072 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f91b44b4000-7f91b44b5000 rw-p 00008000 00:13 3405072 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f91b44b5000-7f91b44bd000 r-xp 00000000 00:13 5534518 /usr/lib/x86_64-linux-gnu/libthai.so.0.3.0
7f91b44bd000-7f91b46bd000 ---p 00008000 00:13 5534518 /usr/lib/x86_64-linux-gnu/libthai.so.0.3.0
7f91b46bd000-7f91b46be000 r--p 00008000 00:13 5534518 /usr/lib/x86_64-linux-gnu/libthai.so.0.3.0
7f91b46be000-7f91b46bf000 rw-p 00009000 00:13 5534518 /usr/lib/x86_64-linux-gnu/libthai.so.0.3.0
7f91b46bf000-7f91b473d000 r-xp 00000000 00:13 1804006 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10200.7
7f91b473d000-7f91b493d000 ---p 0007e000 00:13 1804006 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10200.7
7f91b493d000-7f91b493e000 r--p 0007e000 00:13 1804006 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10200.7
7f91b493e000-7f91b493f000 rw-p 0007f000 00:13 1804006 /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0.10200.7
7f91b493f000-7f91b4946000 r-xp 00000000 00:13 5454980 /lib/x86_64-linux-gnu/librt-2.24.so
7f91b4946000-7f91b4b45000 ---p 00007000 00:13 5454980 /lib/x86_64-linux-gnu/librt-2.24.so
7f91b4b45000-7f91b4b46000 r--p 00006000 00:13 5454980 /lib/x86_64-linux-gnu/librt-2.24.so
7f91b4b46000-7f91b4b47000 rw-p 00007000 00:13 5454980 /lib/x86_64-linux-gnu/librt-2.24.so
7f91b4b47000-7f91b4b58000 r-xp 00000000 00:13 36479 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f91b4b58000-7f91b4d57000 ---p 00011000 00:13 36479 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f91b4d57000-7f91b4d58000 r--p 00010000 00:13 36479 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f91b4d58000-7f91b4d59000 rw-p 00011000 00:13 36479 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f91b4d59000-7f91b4e95000 r-xp 00000000 00:13 123369 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f91b4e95000-7f91b5094000 ---p 0013c000 00:13 123369 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f91b5094000-7f91b5096000 r--p 0013b000 00:13 123369 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f91b5096000-7f91b509b000 rw-p 0013d000 00:13 123369 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f91b509b000-7f91b509c000 rw-p 00000000 00:00 0
7f91b509c000-7f91b50a5000 r-xp 00000000 00:13 126619 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f91b50a5000-7f91b52a4000 ---p 00009000 00:13 126619 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f91b52a4000-7f91b52a5000 r--p 00008000 00:13 126619 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f91b52a5000-7f91b52a6000 rw-p 00009000 00:13 126619 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7f91b52a6000-7f91b52cd000 r-xp 00000000 00:13 5456814 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f91b52cd000-7f91b54cc000 ---p 00027000 00:13 5456814 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f91b54cc000-7f91b54cd000 r--p 00026000 00:13 5456814 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f91b54cd000-7f91b54ce000 rw-p 00027000 00:13 5456814 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f91b54ce000-7f91b54da000 r-xp 00000000 00:13 5457087 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f91b54da000-7f91b56da000 ---p 0000c000 00:13 5457087 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f91b56da000-7f91b56db000 r--p 0000c000 00:13 5457087 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f91b56db000-7f91b56dc000 rw-p 0000d000 00:13 5457087 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f91b56dc000-7f91b56de000 r-xp 00000000 00:13 5504882 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f91b56de000-7f91b58de000 ---p 00002000 00:13 5504882 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f91b58de000-7f91b58df000 r--p 00002000 00:13 5504882 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f91b58df000-7f91b58e0000 rw-p 00003000 00:13 5504882 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f91b58e0000-7f91b5911000 r-xp 00000000 00:13 5474347 /usr/lib/x86_64-linux-gnu/libpng16.so.16.25.0
7f91b5911000-7f91b5b11000 ---p 00031000 00:13 5474347 /usr/lib/x86_64-linux-gnu/libpng16.so.16.25.0
7f91b5b11000-7f91b5b12000 r--p 00031000 00:13 5474347 /usr/lib/x86_64-linux-gnu/libpng16.so.16.25.0
7f91b5b12000-7f91b5b13000 rw-p 00032000 00:13 5474347 /usr/lib/x86_64-linux-gnu/libpng16.so.16.25.0
7f91b5b13000-7f91b5bb1000 r-xp 00000000 00:13 3641814 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0
7f91b5bb1000-7f91b5db1000 ---p 0009e000 00:13 3641814 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0
7f91b5db1000-7f91b5db9000 r--p 0009e000 00:13 3641814 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0
7f91b5db9000-7f91b5dba000 rw-p 000a6000 00:13 3641814 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.34.0
7f91b5dba000-7f91b5dd2000 r-xp 00000000 00:13 5454978 /lib/x86_64-linux-gnu/libpthread-2.24.so
7f91b5dd2000-7f91b5fd1000 ---p 00018000 00:13 5454978 /lib/x86_64-linux-gnu/libpthread-2.24.so
7f91b5fd1000-7f91b5fd2000 r--p 00017000 00:13 5454978 /lib/x86_64-linux-gnu/libpthread-2.24.so
7f91b5fd2000-7f91b5fd3000 rw-p 00018000 00:13 5454978 /lib/x86_64-linux-gnu/libpthread-2.24.so
7f91b5fd3000-7f91b5fd7000 rw-p 00000000 00:00 0
7f91b5fd7000-7f91b5fd8000 r-xp 00000000 00:13 5474214 /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.1
7f91b5fd8000-7f91b61d7000 ---p 00001000 00:13 5474214 /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.1
7f91b61d7000-7f91b61d8000 r--p 00000000 00:13 5474214 /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.1
7f91b61d8000-7f91b61d9000 rw-p 00001000 00:13 5474214 /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0.5000.1
7f91b61d9000-7f91b6281000 r-xp 00000000 00:13 122186 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.3
7f91b6281000-7f91b6481000 ---p 000a8000 00:13 122186 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.3
7f91b6481000-7f91b6487000 r--p 000a8000 00:13 122186 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.3
7f91b6487000-7f91b6488000 rw-p 000ae000 00:13 122186 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.12.3
7f91b6488000-7f91b64c4000 r-xp 00000000 00:13 3109737 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f91b64c4000-7f91b66c3000 ---p 0003c000 00:13 3109737 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f91b66c3000-7f91b66c5000 r--p 0003b000 00:13 3109737 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f91b66c5000-7f91b66c6000 rw-p 0003d000 00:13 3109737 /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f91b66c6000-7f91b67d8000 r-xp 00000000 00:13 5474207 /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.1
7f91b67d8000-7f91b69d7000 ---p 00112000 00:13 5474207 /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.1
7f91b69d7000-7f91b69d8000 r--p 00111000 00:13 5474207 /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.1
7f91b69d8000-7f91b69d9000 rw-p 00112000 00:13 5474207 /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.1
7f91b69d9000-7f91b69da000 rw-p 00000000 00:00 0
7f91b69da000-7f91b6a2c000 r-xp 00000000 00:13 5474213 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.1
7f91b6a2c000-7f91b6c2b000 ---p 00052000 00:13 5474213 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.1
7f91b6c2b000-7f91b6c2c000 r--p 00051000 00:13 5474213 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.1
7f91b6c2c000-7f91b6c2d000 rw-p 00052000 00:13 5474213 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5000.1
7f91b6c2d000-7f91b6c76000 r-xp 00000000 00:13 3602058 /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4000.3
7f91b6c76000-7f91b6e75000 ---p 00049000 00:13 3602058 /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4000.3
7f91b6e75000-7f91b6e78000 r--p 00048000 00:13 3602058 /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4000.3
7f91b6e78000-7f91b6e79000 rw-p 0004b000 00:13 3602058 /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0.4000.3
7f91b6e79000-7f91b6e8d000 r-xp 00000000 00:13 3602082 /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.4000.3
7f91b6e8d000-7f91b708d000 ---p 00014000 00:13 3602082 /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.4000.3
7f91b708d000-7f91b708e000 r--p 00014000 00:13 3602082 /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.4000.3
7f91b708e000-7f91b708f000 rw-p 00015000 00:13 3602082 /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0.4000.3
7f91b708f000-7f91b719d000 r-xp 00000000 00:13 126642 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6
7f91b719d000-7f91b739d000 ---p 0010e000 00:13 126642 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6
7f91b739d000-7f91b73a0000 r--p 0010e000 00:13 126642 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6
7f91b73a0000-7f91b73a1000 rw-p 00111000 00:13 126642 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6
7f91b73a1000-7f91b73a3000 rw-p 00000000 00:00 0
7f91b73a3000-7f91b73ae000 r-xp 00000000 00:13 3602101 /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.4000.3
7f91b73ae000-7f91b75ae000 ---p 0000b000 00:13 3602101 /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.4000.3
7f91b75ae000-7f91b75af000 r--p 0000b000 00:13 3602101 /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.4000.3
7f91b75af000-7f91b75b0000 rw-p 0000c000 00:13 3602101 /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0.4000.3
7f91b75b0000-7f91b75b9000 r-xp 00000000 00:13 5516886 /usr/lib/graphviz/libgvplugin_pango.so.6.0.0
7f91b75b9000-7f91b77b8000 ---p 00009000 00:13 5516886 /usr/lib/graphviz/libgvplugin_pango.so.6.0.0
7f91b77b8000-7f91b77b9000 r--p 00008000 00:13 5516886 /usr/lib/graphviz/libgvplugin_pango.so.6.0.0
7f91b77b9000-7f91b77bb000 rw-p 00009000 00:13 5516886 /usr/lib/graphviz/libgvplugin_pango.so.6.0.0
7f91b77bb000-7f91b77bd000 r-xp 00000000 00:13 5454966 /lib/x86_64-linux-gnu/libdl-2.24.so
7f91b77bd000-7f91b79bd000 ---p 00002000 00:13 5454966 /lib/x86_64-linux-gnu/libdl-2.24.so
7f91b79bd000-7f91b79be000 r--p 00002000 00:13 5454966 /lib/x86_64-linux-gnu/libdl-2.24.so
7f91b79be000-7f91b79bf000 rw-p 00003000 00:13 5454966 /lib/x86_64-linux-gnu/libdl-2.24.so
7f91b79bf000-7f91b7ac2000 r-xp 00000000 00:13 5454967 /lib/x86_64-linux-gnu/libm-2.24.so
7f91b7ac2000-7f91b7cc1000 ---p 00103000 00:13 5454967 /lib/x86_64-linux-gnu/libm-2.24.so
7f91b7cc1000-7f91b7cc2000 r--p 00102000 00:13 5454967 /lib/x86_64-linux-gnu/libm-2.24.so
7f91b7cc2000-7f91b7cc3000 rw-p 00103000 00:13 5454967 /lib/x86_64-linux-gnu/libm-2.24.so
7f91b7cc3000-7f91b7cdd000 r-xp 00000000 00:13 11788 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f91b7cdd000-7f91b7edc000 ---p 0001a000 00:13 11788 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f91b7edc000-7f91b7edd000 r--p 00019000 00:13 11788 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f91b7edd000-7f91b7ede000 rw-p 0001a000 00:13 11788 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f91b7ede000-7f91b7f05000 r-xp 00000000 00:13 652836 /lib/x86_64-linux-gnu/libexpat.so.1.6.2
7f91b7f05000-7f91b8105000 ---p 00027000 00:13 652836 /lib/x86_64-linux-gnu/libexpat.so.1.6.2
7f91b8105000-7f91b8107000 r--p 00027000 00:13 652836 /lib/x86_64-linux-gnu/libexpat.so.1.6.2
7f91b8107000-7f91b8108000 rw-p 00029000 00:13 652836 /lib/x86_64-linux-gnu/libexpat.so.1.6.2
7f91b8108000-7f91b810f000 r-xp 00000000 00:13 5516823 /usr/lib/libpathplan.so.4.0.0
7f91b810f000-7f91b830e000 ---p 00007000 00:13 5516823 /usr/lib/libpathplan.so.4.0.0
7f91b830e000-7f91b830f000 r--p 00006000 00:13 5516823 /usr/lib/libpathplan.so.4.0.0
7f91b830f000-7f91b8310000 rw-p 00007000 00:13 5516823 /usr/lib/libpathplan.so.4.0.0
7f91b8310000-7f91b8316000 r-xp 00000000 00:13 5516786 /usr/lib/libcdt.so.5.0.0
7f91b8316000-7f91b8515000 ---p 00006000 00:13 5516786 /usr/lib/libcdt.so.5.0.0
7f91b8515000-7f91b8516000 r--p 00005000 00:13 5516786 /usr/lib/libcdt.so.5.0.0
7f91b8516000-7f91b8517000 rw-p 00006000 00:13 5516786 /usr/lib/libcdt.so.5.0.0
7f91b8517000-7f91b851c000 r-xp 00000000 00:13 5516850 /usr/lib/libxdot.so.4.0.0
7f91b851c000-7f91b871b000 ---p 00005000 00:13 5516850 /usr/lib/libxdot.so.4.0.0
7f91b871b000-7f91b871c000 r--p 00004000 00:13 5516850 /usr/lib/libxdot.so.4.0.0
7f91b871c000-7f91b871d000 rw-p 00005000 00:13 5516850 /usr/lib/libxdot.so.4.0.0
7f91b871d000-7f91b8726000 r-xp 00000000 00:13 2559550 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f91b8726000-7f91b8925000 ---p 00009000 00:13 2559550 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f91b8925000-7f91b8926000 r--p 00008000 00:13 2559550 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f91b8926000-7f91b8927000 rw-p 00009000 00:13 2559550 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f91b8927000-7f91b8abc000 r-xp 00000000 00:13 5454963 /lib/x86_64-linux-gnu/libc-2.24.so
7f91b8abc000-7f91b8cbb000 ---p 00195000 00:13 5454963 /lib/x86_64-linux-gnu/libc-2.24.so
7f91b8cbb000-7f91b8cbf000 r--p 00194000 00:13 5454963 /lib/x86_64-linux-gnu/libc-2.24.so
7f91b8cbf000-7f91b8cc1000 rw-p 00198000 00:13 5454963 /lib/x86_64-linux-gnu/libc-2.24.so
7f91b8cc1000-7f91b8cc5000 rw-p 00000000 00:00 0
7f91b8cc5000-7f91b8cda000 r-xp 00000000 00:13 5516805 /usr/lib/libcgraph.so.6.0.0
7f91b8cda000-7f91b8ed9000 ---p 00015000 00:13 5516805 /usr/lib/libcgraph.so.6.0.0
7f91b8ed9000-7f91b8eda000 r--p 00014000 00:13 5516805 /usr/lib/libcgraph.so.6.0.0
7f91b8eda000-7f91b8edb000 rw-p 00015000 00:13 5516805 /usr/lib/libcgraph.so.6.0.0
7f91b8edb000-7f91b8f67000 r-xp 00000000 00:13 5516888 /usr/lib/libgvc.so.6.0.0
7f91b8f67000-7f91b9166000 ---p 0008c000 00:13 5516888 /usr/lib/libgvc.so.6.0.0
7f91b9166000-7f91b9167000 r--p 0008b000 00:13 5516888 /usr/lib/libgvc.so.6.0.0
7f91b9167000-7f91b9178000 rw-p 0008c000 00:13 5516888 /usr/lib/libgvc.so.6.0.0
7f91b9178000-7f91b9179000 rw-p 00000000 00:00 0
7f91b9179000-7f91b919c000 r-xp 00000000 00:13 5454959 /lib/x86_64-linux-gnu/ld-2.24.so
7f91b92db000-7f91b92dc000 rw-p 00000000 00:00 0
7f91b92dc000-7f91b92f5000 r--p 00000000 00:13 3143918 /usr/share/fonts/type1/gsfonts/n021003l.pfb
7f91b92f5000-7f91b92f6000 r--s 00000000 00:13 3165796 /var/cache/fontconfig/087e1975ba9a574b140bb1df193bf770-le64.cache-4
7f91b92f6000-7f91b9301000 r--s 00000000 00:13 3165792 /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-4
7f91b9301000-7f91b9304000 r--s 00000000 00:13 3165788 /var/cache/fontconfig/f24b2111ab8703b4e963115a8cf14259-le64.cache-4
7f91b9304000-7f91b9308000 r--s 00000000 00:13 5557401 /var/cache/fontconfig/0fafd173547752dce4dee1a69e0b3c95-le64.cache-4
7f91b9308000-7f91b930e000 r--s 00000000 00:13 4556612 /var/cache/fontconfig/6eb3985aa4124903f6ff08ba781cd364-le64.cache-4
7f91b930e000-7f91b9312000 r--s 00000000 00:13 4167766 /var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-le64.cache-4
7f91b9312000-7f91b9316000 r--s 00000000 00:13 3165784 /var/cache/fontconfig/de156ccd2eddbdc19d37a45b8b2aac9c-le64.cache-4
7f91b9316000-7f91b9317000 r--s 00000000 00:13 5557398 /var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-le64.cache-4
7f91b9317000-7f91b931b000 r--s 00000000 00:13 3165778 /var/cache/fontconfig/c57959a16110560c8d0fcea73374aeeb-le64.cache-4
7f91b931b000-7f91b9321000 r--s 00000000 00:13 3165776 /var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le64.cache-4
7f91b9321000-7f91b9329000 r--s 00000000 00:13 3165774 /var/cache/fontconfig/bf3b770c553c462765856025a94f1ce6-le64.cache-4
7f91b9329000-7f91b932c000 r--s 00000000 00:13 3165770 /var/cache/fontconfig/e49e89034d371f0f9de17aab02136486-le64.cache-4
7f91b932c000-7f91b933f000 r--s 00000000 00:13 3165766 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le64.cache-4
7f91b933f000-7f91b934b000 r--s 00000000 00:13 3165760 /var/cache/fontconfig/d589a48862398ed80a3d6066f4f56f4c-le64.cache-4
7f91b934b000-7f91b9351000 rw-p 00000000 00:00 0
7f91b9351000-7f91b9352000 r--s 00000000 00:13 3653417 /var/cache/fontconfig/0bd3dc0958fa2205aaaa8ebb13e2872b-le64.cache-4
7f91b9352000-7f91b9353000 r--s 00000000 00:13 3165772 /var/cache/fontconfig/95ec50e26f92b78a11e12952ce86c0c8-le64.cache-4
7f91b9353000-7f91b9355000 r--s 00000000 00:13 3165768 /var/cache/fontconfig/4b14b093aebc79c320de5e86ae1d3314-le64.cache-4
7f91b9355000-7f91b9356000 r--s 00000000 00:13 3165764 /var/cache/fontconfig/8a687c406b77f27d99abfeeba937fcce-le64.cache-4
7f91b9356000-7f91b9357000 r--s 00000000 00:13 3165762 /var/cache/fontconfig/3f7329c5293ffd510edef78f73874cfd-le64.cache-4
7f91b9357000-7f91b935b000 r--s 00000000 00:13 3165758 /var/cache/fontconfig/246184dc75a16901ca37d96895904249-le64.cache-4
7f91b935b000-7f91b9362000 r--s 00000000 00:13 3165750 /var/cache/fontconfig/53d14c92082a93e67d5078324eb314ca-le64.cache-4
7f91b9362000-7f91b9363000 r--s 00000000 00:13 3165748 /var/cache/fontconfig/c277e94e32b20404286a1ddafa5a80f0-le64.cache-4
7f91b9363000-7f91b9391000 r--s 00000000 00:13 3165726 /var/cache/fontconfig/cabbd14511b9e8a55e92af97fb3a0461-le64.cache-4
7f91b9391000-7f91b9394000 r--s 00000000 00:13 3165720 /var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-le64.cache-4
7f91b9394000-7f91b9398000 r--s 00000000 00:13 4556610 /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-le64.cache-4
7f91b9398000-7f91b939b000 rw-p 00000000 00:00 0
7f91b939b000-7f91b939c000 r--p 00022000 00:13 5454959 /lib/x86_64-linux-gnu/ld-2.24.so
7f91b939c000-7f91b939d000 rw-p 00023000 00:13 5454959 /lib/x86_64-linux-gnu/ld-2.24.so
7f91b939d000-7f91b939e000 rw-p 00000000 00:00 0
7fff4b90a000-7fff4b92b000 rw-p 00000000 00:00 0 [stack]
7fff4b9ae000-7fff4b9b0000 r--p 00000000 00:00 0 [vvar]
7fff4b9b0000-7fff4b9b2000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted
```
Graphviz version (debian unstable package):
``dot - graphviz version 2.38.0 (20140413.2041)``https://gitlab.com/graphviz/graphviz/-/issues/1168[Dot] Subscriptions not works with SVG2022-04-26T00:02:53ZJohn Ellson[Dot] Subscriptions not works with SVG*Created by: borneq*
I have in dot
`PS [label = <p<SUB>S</SUB>>]`
or
`PS [label = <p<sub>S</sub>>]`.
If I generate png is ok but on svg is big "S" letter
this error is for 2.38 version and still in graphviz-2.39.20150331.msi*Created by: borneq*
I have in dot
`PS [label = <p<SUB>S</SUB>>]`
or
`PS [label = <p<sub>S</sub>>]`.
If I generate png is ok but on svg is big "S" letter
this error is for 2.38 version and still in graphviz-2.39.20150331.msihttps://gitlab.com/graphviz/graphviz/-/issues/1153concentrate is inconsistent2021-03-20T02:12:44ZJohn Ellsonconcentrate is inconsistent*Created by: ellson*
Edge concentration is inconsistent in behavior in dot. in the following graph, why is "{a b} -> d" concentrated, but "{A B} -> D" not?
digraph G {
concentrate=true
a -> b -> c -> d
{ a b } -> d
{ A ...*Created by: ellson*
Edge concentration is inconsistent in behavior in dot. in the following graph, why is "{a b} -> d" concentrated, but "{A B} -> D" not?
digraph G {
concentrate=true
a -> b -> c -> d
{ a b } -> d
{ A B } -> D
}
What I'm really looking for is a way to represent netlists in dot. Concentrate almost handles 1-to-many netlists, but not quite.
It looks like concentrate might use a zero-sized floating node for the branch point? Can this type of node be exposed in the dot language? And can it be allowed to position half-way between ranks so that "{A B} -> D" will concentrate?https://gitlab.com/graphviz/graphviz/-/issues/1152ordering=out is not being obeyed2022-02-08T10:30:12ZJohn Ellsonordering=out is not being obeyed*Created by: ellson*
dot - graphviz version 2.39.20160809.1552 (20160809.1552)
ordering=out is not being obeyed in this graph:
strict digraph { ordering=out
"CONTENTS" -> "PROPERTIES" [label="?"]
"CONTENTS" -> "ACT" [label="_+...*Created by: ellson*
dot - graphviz version 2.39.20160809.1552 (20160809.1552)
ordering=out is not being obeyed in this graph:
strict digraph { ordering=out
"CONTENTS" -> "PROPERTIES" [label="?"]
"CONTENTS" -> "ACT" [label="_+"]
"ACT" -> "VERB" [label="?"]
"ACT" -> "SUBJECT" [label=""]
"ACT" -> "ATTRIBUTES" [label="?"]
"ACT" -> "CONTAINER" [label="?"]
"ACT" -> "TERM" [label="?"]
"VERB" -> "TLD" [label=""]
"VERB" -> "QRY" [label=""]
"SUBJECT" -> "OBJECT" [label=""]
"SUBJECT" -> "OBJECT_LIST" [label=""]
"OBJECT_LIST" -> "LPN" [label=""]
"OBJECT_LIST" -> "OBJECT" [label="_+"]
"OBJECT_LIST" -> "RPN" [label=""]
"PROPERTIES" -> "LBR" [label=""]
"PROPERTIES" -> "ATTR" [label="_*"]
"PROPERTIES" -> "RBR" [label=""]
"ATTRIBUTES" -> "LBR" [label=""]
"ATTRIBUTES" -> "ATTR" [label="_*"]
"ATTRIBUTES" -> "RBR" [label=""]
"CONTAINER" -> "LBE" [label=""]
"CONTAINER" -> "CONTENTS" [label="?"]
"CONTAINER" -> "RBE" [label=""]
"TERM" -> "SCN" [label=""]
"TERM" -> "HAT" [label=""]
}https://gitlab.com/graphviz/graphviz/-/issues/1146edgepaint failure with record ports2021-03-20T02:11:28ZJohn Ellsonedgepaint failure with record ports*Created by: wavexx*
When a node with multiple ports has > 1 edge going out of it, edgepaint crashes with a segmentation fault (no error is emitted).
Minimal test case:
```
digraph G { ...*Created by: wavexx*
When a node with multiple ports has > 1 edge going out of it, edgepaint crashes with a segmentation fault (no error is emitted).
Minimal test case:
```
digraph G {
a [shape=record; label="<a> a|<b> b"];
b;
a:a -> b;
a:b -> b;
}
```
Creating a single edge (starting from any port) works as intended.https://gitlab.com/graphviz/graphviz/-/issues/1140NaN position with splines=curved using neato2021-03-20T02:10:13ZSpencer BlivenNaN position with splines=curved using neatoI am having a problem with edges not showing up when using curved splines. This only seems to be a problem with neato, but I can't use the default filter because I need to set the node positions explicitly.
Input:
```
digraph "Assembly...I am having a problem with edges not showing up when using curved splines. This only seems to be a problem with neato, but I can't use the default filter because I need to set the node positions explicitly.
Input:
```
digraph "Assembly 2" {
graph [
splines="curved"
size="1,1"
dpi="300"
ratio="fill"
bgcolor="transparent"
]
node [
style="filled"
fillcolor="#a6cee3"
color="#a6cee3"
width="1.5"
regular="true"
label=""
]
edge [
dir="none"
penwidth="10"
]
"A_0" [ pos="143.0,50.0" color="#1b9e77" fillcolor="#1b9e77"]
"A_1" [ pos="50.0,550.0" color="#1b9e77" fillcolor="#1b9e77"]
"A_0" ->"A_1" [ color="#000066" ]
}
```
When run with `dot -Tdot -Kneato -O -n2 test.dot`, I get the following output:
```
digraph "Assembly 2" {
graph [bb="0,0,608,608",
bgcolor=transparent,
dpi=300,
ratio=fill,
size="1,1",
splines=curved
];
node [color="#a6cee3",
fillcolor="#a6cee3",
label="",
regular=true,
style=filled,
width=1.5
];
edge [dir=none,
penwidth=10
];
A_0 [color="#1b9e77",
fillcolor="#1b9e77",
height=1.5,
pos="444.66,54"];
A_1 [color="#1b9e77",
fillcolor="#1b9e77",
height=1.5,
pos="163.34,554"];
A_0 -> A_1 [color="#000066",
pos="nan,nan nan,nan nan,nan nan,nan"];
}
```
The NaN edge position causes the edge to be dropped completely when rendered.
This is using graphviz version 2.38.0 (20140413.2041) on OS 10.11.4.https://gitlab.com/graphviz/graphviz/-/issues/1138Licence and copyright information2021-03-25T05:01:05ZErwin JanssenLicence and copyright informationThere are multiple licence files
- LICENCE
- ep-v10.html
- ep-v10.txt
- COPYING
This clutters the repository, so I wondered if they should all be kept, or if some could be removed.
Most code files contain the following licence / copyri...There are multiple licence files
- LICENCE
- ep-v10.html
- ep-v10.txt
- COPYING
This clutters the repository, so I wondered if they should all be kept, or if some could be removed.
Most code files contain the following licence / copyright information
```
/*************************************************************************
* Copyright (c) 2011 AT&T Intellectual Property
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
*
* Contributors: See CVS logs. Details at http://www.graphviz.org/
*************************************************************************/
```
This message is outdated. The year is long past, AT&T doesn't support this software any more and instead of CVS, Git is being used. What should be done with this message?
Also, what message, if any, should new code files contain. I plan to do some refactoring and add some files.https://gitlab.com/graphviz/graphviz/-/issues/1136copy to clipboard feature wanted2020-06-17T13:57:12ZJohn Ellsoncopy to clipboard feature wanted*Created by: highwall*
Copy is sometimes much more convenient than export. The feature may default copy the exported png to clipboard.
*Created by: highwall*
Copy is sometimes much more convenient than export. The feature may default copy the exported png to clipboard.
https://gitlab.com/graphviz/graphviz/-/issues/1132[Neato] Incorrect node shapes during neato overlap removal2022-06-17T03:45:09ZSteve (Gadget) Barnes[Neato] Incorrect node shapes during neato overlap removalPorted Issue from Mantis
Original ID: 9
Reported By: user442
SEVERITY: MINOR
Submitted: 2002-03-09 04:34:22
OS: _-_-*
VERSION: 1.8.2
## DESCRIPTION
<br>
To remove overlap, nodes are approximated by polygons. The
code to create the p...Ported Issue from Mantis
Original ID: 9
Reported By: user442
SEVERITY: MINOR
Submitted: 2002-03-09 04:34:22
OS: _-_-*
VERSION: 1.8.2
## DESCRIPTION
<br>
To remove overlap, nodes are approximated by polygons. The
code to create the polygons currently does not apply the orientation,
skew or distortion factors.https://gitlab.com/graphviz/graphviz/-/issues/1131[Webdot] webdot in perl doesn't handle generalized URL syntax2023-01-05T02:50:39ZSteve (Gadget) Barnes[Webdot] webdot in perl doesn't handle generalized URL syntaxPorted Issue from Mantis
Original ID: 30
Reported By: Stephen C. North2
SEVERITY: MAJOR
Submitted: 2002-04-11 18:41:36
OS: _-_-
## DESCRIPTION
<br>
URLS like: <a href=/~north/cgi-bin/webdot1.7.11/webdot.cgi//~north/webdot1.7.11/tut2....Ported Issue from Mantis
Original ID: 30
Reported By: Stephen C. North2
SEVERITY: MAJOR
Submitted: 2002-04-11 18:41:36
OS: _-_-
## DESCRIPTION
<br>
URLS like: <a href=/~north/cgi-bin/webdot1.7.11/webdot.cgi//~north/webdot1.7.11/tut2.dot.dot.map>
<br>
are handled by the tcl webdot, but perl wants to see http:// before
the graph file to be pulled (at least I think so).
https://gitlab.com/graphviz/graphviz/-/issues/1130[Dot] Loop in calculation?2020-06-25T14:12:28ZSteve (Gadget) Barnes[Dot] Loop in calculation?Ported Issue from Mantis
Original ID: 41
Reported By: Wouter Slegers
SEVERITY: MAJOR
Submitted: 2002-04-25 08:04:07
OS: X86-UNIX-OPENBSD 3.0-STABLE
VERSION: 1.8.4
## DESCRIPTION
<br>
Calculation of a graph of approx 175 nodes and 25...Ported Issue from Mantis
Original ID: 41
Reported By: Wouter Slegers
SEVERITY: MAJOR
Submitted: 2002-04-25 08:04:07
OS: X86-UNIX-OPENBSD 3.0-STABLE
VERSION: 1.8.4
## DESCRIPTION
<br>
Calculation of a graph of approx 175 nodes and 2500 edges takes 150+ MB of memory and was manually aborted after 600+ CPUseconds (realworldtime due to thrashing: more then a week).
Input is a graph generated from spidering a website.
Reducing the amount of edges by removing all duplicate edges between two nodes, did not help.
I haven't yet been able to find what exactly triggers this, so I'm afraid I'm unable to reduce the input file further.
https://gitlab.com/graphviz/graphviz/-/issues/1129[Output Generation] Viewing PS output of large graphs fails2021-05-29T04:13:15ZSteve (Gadget) Barnes[Output Generation] Viewing PS output of large graphs failsPorted Issue from Mantis
Original ID: 57
Reported By: Art Morales
SEVERITY: MAJOR
Submitted: 2002-05-21 02:52:06
OS: *-OTHER-ALPHA/LINUX
VERSION: 1.7.3B
## DESCRIPTION
<br>
Viewers crash on PostScript output of large graphs which
ar...Ported Issue from Mantis
Original ID: 57
Reported By: Art Morales
SEVERITY: MAJOR
Submitted: 2002-05-21 02:52:06
OS: *-OTHER-ALPHA/LINUX
VERSION: 1.7.3B
## DESCRIPTION
<br>
Viewers crash on PostScript output of large graphs which
are scaled down.
<br>
[erg] When a large graph is scaled down, the scale factor is very small.
Unfortunately, psgen uses %.4f to output the scale factor. This is not
enough precision, so the number becomes 0. This, in turn, upsets
PostScript intrpreters (e.g., dividing by 0).https://gitlab.com/graphviz/graphviz/-/issues/1128[Dot] arrowhead/tail scaling (add arrowheadsize, arrowtailsize attrs)2023-04-19T03:57:44ZSteve (Gadget) Barnes[Dot] arrowhead/tail scaling (add arrowheadsize, arrowtailsize attrs)Ported Issue from Mantis
Original ID: 59
Reported By: David O'Shea2
SEVERITY: COSMETIC
Submitted: 2002-05-27 08:18:28
OS: SPARC-SUNOS-SOLARIS 8
VERSION: NIGHTLY 27-MAY-02
## DESCRIPTION
<br>
Compared to older versions (e.g. 1.7.6), ...Ported Issue from Mantis
Original ID: 59
Reported By: David O'Shea2
SEVERITY: COSMETIC
Submitted: 2002-05-27 08:18:28
OS: SPARC-SUNOS-SOLARIS 8
VERSION: NIGHTLY 27-MAY-02
## DESCRIPTION
<br>
Compared to older versions (e.g. 1.7.6), when I use 'arrowtail = dot', the dot is much larger, and when I'm using a port within a record as the tail of the edge, it ends up covering up some of the text. However, if I use 'arrowsize' to decrease the size of the dot, it will decrease the size of the arrowhead, too. It would be good if there were independent scaling options for arrowhead and arrowtail.
<br>
## STEPS TO REPRODUCE
```
digraph test {
node [
fontname = "Arial"
fontsize = 8
]
node1 [
shape = record
label = "{{blah|blah}|{blah|<xxx>blah}|{blah|blah}}"
]
node2 -> node1:xxx [
arrowhead = dot
]
}
```https://gitlab.com/graphviz/graphviz/-/issues/1127[Dot] Crash in dot.exe2020-09-08T02:21:36ZSteve (Gadget) Barnes[Dot] Crash in dot.exePorted Issue from Mantis
Original ID: 60
Reported By: Uli
SEVERITY: MINOR
Submitted: 2002-05-28 10:06:08
OS: X86-OTHER-NT 4.0
VERSION: 1.8.2
## DESCRIPTION
Crash during genartion of graph. Dot-file comes from doxygen!
## ADDITIONAL I...Ported Issue from Mantis
Original ID: 60
Reported By: Uli
SEVERITY: MINOR
Submitted: 2002-05-28 10:06:08
OS: X86-OTHER-NT 4.0
VERSION: 1.8.2
## DESCRIPTION
Crash during genartion of graph. Dot-file comes from doxygen!
## ADDITIONAL INFORMATION
[erg] The graph has 2409 nodes and 17047 edges. Crash could well be
from lack of memory.https://gitlab.com/graphviz/graphviz/-/issues/1126[Dot] cant draw a large graph2021-03-17T03:45:08ZSteve (Gadget) Barnes[Dot] cant draw a large graphPorted Issue from Mantis
Original ID: 65
Reported By: Miroslav Makstenek2
SEVERITY: MINOR
Submitted: 2002-06-20 11:07:57
OS: X86-OTHER-WIN 2000 AS
VERSION: 1.8.6
## DESCRIPTION
<br>
Dotty hangs. On the 500-700 nodes works normally. ...Ported Issue from Mantis
Original ID: 65
Reported By: Miroslav Makstenek2
SEVERITY: MINOR
Submitted: 2002-06-20 11:07:57
OS: X86-OTHER-WIN 2000 AS
VERSION: 1.8.6
## DESCRIPTION
<br>
Dotty hangs. On the 500-700 nodes works normally. More - hangs. Gives out
msgbox "Lefty error", then - "dot fail" and advises to send bug report.
The picture and does not appear.
Thus in task manager it is visible, that the task loses management, and it
should be removed manually.
## ADDITIONAL INFORMATION
[erg] Since dot is dying and the file is large, it is probable that
the user is running out of memory.
With enough memory, the position phase network simplex takes forever.
One wonders if the tools shouldn't defend against big graphs. For example,
dotty might set the nslimit parameter.https://gitlab.com/graphviz/graphviz/-/issues/1125[Dot] planar graph drawn with overlapping edges2021-05-29T04:10:14ZSteve (Gadget) Barnes[Dot] planar graph drawn with overlapping edgesPorted Issue from Mantis
Original ID: 67
Reported By: Lilian
SEVERITY: COSMETIC
Submitted: 2002-06-20 15:18:05
OS: X86-LINUX-
VERSION: 1.8.5
## DESCRIPTION
<br>
Hello,
<br>
The following graph is obviously planar, but dot insists o...Ported Issue from Mantis
Original ID: 67
Reported By: Lilian
SEVERITY: COSMETIC
Submitted: 2002-06-20 15:18:05
OS: X86-LINUX-
VERSION: 1.8.5
## DESCRIPTION
<br>
Hello,
<br>
The following graph is obviously planar, but dot insists on placing the input and the output on the same side of the channel, which makes some edges overlap.
Is there any way to avoid this behavior ?
<br>
Thanks,
Lilian.
## STEPS TO REPRODUCE
digraph anything {
size="7,10"
edge [ decorate=1 fontsize=8 fontname=Helvetica labelfontname=Helvetica labelfontsize=8 ]
node [ fontsize=12 fontname="Helvetica-Bold" shape=ellipse ]
subgraph ports {
port0 [label="activate" style=bold shape=box ]
port1 [label="i" style=bold shape=box ]
port2 [label="o" style=bold shape=box ]
}
subgraph cluster_components {
label="buffer_n"
comp0 [label="."]
comp1 [label="."]
comp2 [label="W."]
comp3 [label="buffer"]
comp4 [label="buffer"]
comp5 [label="."]
comp6 [label="buffer"]
comp7 [label="buffer"]
}
port0 -> comp2 [ label="C1: @14:20" arrowhead=odot arrowtail=dot dir=forward headlabel="0" taillabel="" ]
port1 -> comp3 [ label="C2: i" arrowhead=normal arrowtail=odot dir=forward headlabel="" taillabel="1" ]
comp4 -> port2 [ label="C3: o" arrowhead=normal arrowtail=dot dir=forward headlabel="" taillabel="2" ]
comp7 -> comp0 [ label="C4: c[3]" arrowhead=normal arrowtail=dot dir=forward headlabel="1" taillabel="2" ]
comp7 -> comp5 [ label="C5: c[2]" arrowhead=odot arrowtail=normal dir=back headlabel="0" taillabel="1" ]
comp2 -> comp7 [ label="C6: @17:12" arrowhead=odot arrowtail=dot dir=forward headlabel="0" taillabel="4" ]
comp6 -> comp5 [ label="C7: c[2]" arrowhead=normal arrowtail=dot dir=forward headlabel="1" taillabel="2" ]
comp6 -> comp1 [ label="C8: c[1]" arrowhead=odot arrowtail=normal dir=back headlabel="0" taillabel="1" ]
comp2 -> comp6 [ label="C9: @17:12" arrowhead=odot arrowtail=dot dir=forward headlabel="0" taillabel="3" ]
comp4 -> comp0 [ label="C10: c[3]" arrowhead=odot arrowtail=normal dir=back headlabel="0" taillabel="1" ]
comp2 -> comp4 [ label="C11: @15:10" arrowhead=odot arrowtail=dot dir=forward headlabel="0" taillabel="2" ]
comp3 -> comp1 [ label="C12: c[1]" arrowhead=normal arrowtail=dot dir=forward headlabel="1" taillabel="2" ]
comp2 -> comp3 [ label="C13: @14:10" arrowhead=odot arrowtail=dot dir=forward headlabel="0" taillabel="1" ]
}
## ADDITIONAL INFORMATION
[erg] dot does not guarantee planarity. In fact, as with this graph,
the aesthetics work against it. The user can make the graph planar by
putting node o into the cluster and forcing the bottom nodes down a rank.https://gitlab.com/graphviz/graphviz/-/issues/1124[Dot] more cluster wrongness2021-03-20T02:09:02ZSteve (Gadget) Barnes[Dot] more cluster wrongnessPorted Issue from Mantis
Original ID: 79
Reported By: Stephen C. North
SEVERITY: MAJOR
Submitted: 2002-07-10 03:33:18
OS: X86-LINUX-REDHAT 7.2
VERSION: 1.8.5 OR SO
## DESCRIPTION
<br>
Cluster minrank and maxrank and the rankleader a...Ported Issue from Mantis
Original ID: 79
Reported By: Stephen C. North
SEVERITY: MAJOR
Submitted: 2002-07-10 03:33:18
OS: X86-LINUX-REDHAT 7.2
VERSION: 1.8.5 OR SO
## DESCRIPTION
<br>
Cluster minrank and maxrank and the rankleader array's
indexing aren't handled consistently, causing much
potential woe.
## STEPS TO REPRODUCE
digraph G {
graph [style=invis];
bla;
subgraph cluster_X {
ratio=compress;
subgraph cluster0 {
graph [style=invis];
a -> b -> {c0 c1};
{rank=sink max_of_cluster0 [color=transparent,shape=point]};
}
```
subgraph cluster1 {
graph [style=invis];
x -> y -> {z0 z1};
{rank=source min_of_cluster1 [color=transparent,shape=point]};
}
graph [compound=true];
max_of_cluster0 -> min_of_cluster1
[ltail=cluster0, lhead=cluster1, style=invis, weight=0];
}
```
}
## ADDITIONAL INFORMATION
cluster_leader() shouldn't assume that minrank=0.
But eveb if you fix that in the obvious way
there are other problems.https://gitlab.com/graphviz/graphviz/-/issues/1123[Dot] Missing error message when node is in two subgraphs2023-01-03T05:06:33ZSteve (Gadget) Barnes[Dot] Missing error message when node is in two subgraphsPorted Issue from Mantis
Original ID: 85
Reported By: user442
SEVERITY: MINOR
Submitted: 2002-07-25 14:12:08
OS: _-_-*
VERSION: 1.8.8
## DESCRIPTION
<br>
The input graph has illegal constraints: node a is in two constraining
subgrap...Ported Issue from Mantis
Original ID: 85
Reported By: user442
SEVERITY: MINOR
Submitted: 2002-07-25 14:12:08
OS: _-_-*
VERSION: 1.8.8
## DESCRIPTION
<br>
The input graph has illegal constraints: node a is in two constraining
subgraphs. However, dot does not complain despite the fact that node a
is not put into cluster3 in the output.
<br>
If the subgraphs are reversed, dot gives the expected complaint.
## STEPS TO REPRODUCE
```
digraph G {
subgraph H2 {
rank=same;
a;
c;
}
subgraph cluster3 {
a -> d;
}
}
```https://gitlab.com/graphviz/graphviz/-/issues/1122[Dot] Assertion failed2020-06-17T14:05:51ZSteve (Gadget) Barnes[Dot] Assertion failedPorted Issue from Mantis
Original ID: 89
Reported By: Christof
SEVERITY: MAJOR
Submitted: 2002-07-29 01:54:35
OS: X86-LINUX-2.4
VERSION: DOT VERSION 1.8.8
## DESCRIPTION
<br>
<CD>
dot: mincross.c:959: transpose_step: Assertion `v->u...Ported Issue from Mantis
Original ID: 89
Reported By: Christof
SEVERITY: MAJOR
Submitted: 2002-07-29 01:54:35
OS: X86-LINUX-2.4
VERSION: DOT VERSION 1.8.8
## DESCRIPTION
<br>
<CD>
dot: mincross.c:959: transpose_step: Assertion `v->u.order < w->u.order' failed.
graph parser: parse error near line 2928
context: >>> Abort <<<
dot: mincross.c:959: transpose_step: Assertion`v->u.order < w->u.order' failed.
</CD>
https://gitlab.com/graphviz/graphviz/-/issues/1121[Dotty/Lneato/Lefty] garbled dotty output2021-05-29T04:21:26ZSteve (Gadget) Barnes[Dotty/Lneato/Lefty] garbled dotty outputPorted Issue from Mantis
Original ID: 103
Reported By: Tomas Pospise
SEVERITY: MINOR
Submitted: 2002-09-02 11:36:20
OS: X86-LINUX-DEBIAN WOODY RELEASE
VERSION: 2.3
## DESCRIPTION
<br>
Output is garbled, see attached dotfile and resp...Ported Issue from Mantis
Original ID: 103
Reported By: Tomas Pospise
SEVERITY: MINOR
Submitted: 2002-09-02 11:36:20
OS: X86-LINUX-DEBIAN WOODY RELEASE
VERSION: 2.3
## DESCRIPTION
<br>
Output is garbled, see attached dotfile and respective window snapshot.
<br>
And check the dotty scrollbars too - even if I wanted I
wouldn't be able to modify the graph as I wanted because I can not
scroll that far.
<br>
Maybe this is interesting too:
<CD>
tpo@tpo2:tmp$ ldd `which lefty`
libXaw.so.7 => /usr/X11R6/lib/libXaw.so.7 (0x40025000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40077000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4007f000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40095000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x400a9000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400f3000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40100000)
libm.so.6 => /lib/libm.so.6 (0x401db000)
libc.so.6 => /lib/libc.so.6 (0x401fc000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40317000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
</CD>
## ADDITIONAL INFORMATION
resubmitting bug here as requested by Eleftherios Koutsofios
[erg] The font does not appear to be scaled as needed, so labels overlap.https://gitlab.com/graphviz/graphviz/-/issues/1120[Dot] Assertion `v->u.order < w->u.order' failed2020-06-17T14:05:50ZSteve (Gadget) Barnes[Dot] Assertion `v->u.order < w->u.order' failedPorted Issue from Mantis
Original ID: 106
Reported By: Karin Hogstedt
SEVERITY: CRITICAL
Submitted: 2002-09-12 05:05:33
OS: X86-LINUX-2.4.9-31
## DESCRIPTION
<br>
This is the error I get when I run dotty on the input graph given belo...Ported Issue from Mantis
Original ID: 106
Reported By: Karin Hogstedt
SEVERITY: CRITICAL
Submitted: 2002-09-12 05:05:33
OS: X86-LINUX-2.4.9-31
## DESCRIPTION
<br>
This is the error I get when I run dotty on the input graph given below.
I also attach the dottybug.dot file that dotty generates as the output file.
<CD>
dot: mincross.c:950: transpose_step: Assertion `v->u.order < w->u.order' failed.
graph parser: parse error near line 9279
context: >>> Abort <<< (core dumped)
dot: mincross.c:950: transpose_step: Assertion`v->u.order < w->u.order' failed.
dotty.lefty: giving up on dot
dotty.lefty: graph that causes dot
dotty.lefty: to fail has been saved in file dottybug.dot
dotty.lefty: please fill out a bug report at http://www.research.att.com/~erg/gr
aphviz/bugform.html
</CD>
## ADDITIONAL INFORMATION
See bug 180.
https://gitlab.com/graphviz/graphviz/-/issues/1119[Dot] Concentrate drops edges from two vertex cycles2022-12-30T18:52:15ZSteve (Gadget) Barnes[Dot] Concentrate drops edges from two vertex cyclesPorted Issue from Mantis
Original ID: 115
Reported By: Alex Harper
SEVERITY: MAJOR
Submitted: 2002-09-20 20:58:21
OS: X86-LINUX-2.4.9 REDHAT
VERSION: 1.8.9
## DESCRIPTION
<br>
With edge concentration on dot drops a cyclic edge betwe...Ported Issue from Mantis
Original ID: 115
Reported By: Alex Harper
SEVERITY: MAJOR
Submitted: 2002-09-20 20:58:21
OS: X86-LINUX-2.4.9 REDHAT
VERSION: 1.8.9
## DESCRIPTION
<br>
With edge concentration on dot drops a cyclic edge between two vertices
in a cycle.
<br>
In previous versions (1.7.x releases) this was rendered correctly as a
bidirectional edge between the vertices. In 1.8 (1.8.5 and
1.8.9 were tested) the edge is rendered as a one-way arrow. Turning off
concentration eliminates the issue.
<br>
As for severity... since I saw no mention of changes to concentrate
behavior in the changelog I'm assuming this is a bug.
## STEPS TO REPRODUCE
digraph G {
/\* Use edge concentration */
concentrate=true;
1 [ label = "node1" ];
2 [ label = "node2" ];
1 -> 2;
2 -> 1;
} /\* graph close */https://gitlab.com/graphviz/graphviz/-/issues/1118[Dot] dot chrash on Win322020-06-17T14:02:50ZSteve (Gadget) Barnes[Dot] dot chrash on Win32Ported Issue from Mantis
Original ID: 118
Reported By: Jari Siikarla
SEVERITY: MAJOR
Submitted: 2002-10-04 12:33:43
OS: X86-OTHER-4.0 SP6
VERSION: WINDOWS (1.8.9)
## DESCRIPTION
<br>
OS=Windows Nt
<br>
Using Dotty on large function...Ported Issue from Mantis
Original ID: 118
Reported By: Jari Siikarla
SEVERITY: MAJOR
Submitted: 2002-10-04 12:33:43
OS: X86-OTHER-4.0 SP6
VERSION: WINDOWS (1.8.9)
## DESCRIPTION
<br>
OS=Windows Nt
<br>
Using Dotty on large function call graph (~20 000 nodes)
Gives "size too big"
<br>
Reducing the file to have only 5 000 lines of edges (ie. 5 -> {1;2;3;4;})
causes dot to crash. Dotty still tries to continue, but eventually gives up after the second crash of dot.
<br>
Produced crash report "dottybug.dot" is 7,3 MB
## ADDITIONAL INFORMATION
vcg or aisee crashed with less dignity than dot/dotty ;)
Do you have rule of thump on how big a graph dot/dotty can handle ?
[erg] At first blush, this appears to be a stack overflow
in search_component during mincross.
https://gitlab.com/graphviz/graphviz/-/issues/1117[Dot] Spline router problems2021-05-29T11:46:15ZSteve (Gadget) Barnes[Dot] Spline router problemsPorted Issue from Mantis
Original ID: 146
Reported By: Stephen C. North2
SEVERITY: MAJOR
Submitted: 2002-10-14 05:00:00
OS: _-_-*
VERSION: 1.8.10
## DESCRIPTION
<br>
There really does seem to be something wrong with the spline route...Ported Issue from Mantis
Original ID: 146
Reported By: Stephen C. North2
SEVERITY: MAJOR
Submitted: 2002-10-14 05:00:00
OS: _-_-*
VERSION: 1.8.10
## DESCRIPTION
<br>
There really does seem to be something wrong with the spline router.
See the attached Postscript debug output. It looks to me as if the
router has sign error somewhere and attempts to zig when it ought
to zag. Unfortunately I didn't write the code, and worse, I thought
I had fixed this already a while ago.https://gitlab.com/graphviz/graphviz/-/issues/1116[Dotty/Lneato/Lefty] incorrect visualization of russian words2021-05-29T04:19:28ZSteve (Gadget) Barnes[Dotty/Lneato/Lefty] incorrect visualization of russian wordsPorted Issue from Mantis
Original ID: 124
Reported By: Maxim
SEVERITY: CRITICAL
Submitted: 2002-10-22 12:44:33
OS: _-_-
VERSION: ALL
## DESCRIPTION
<br>
I can't use russian words for nodes in DOTTY.
I do UTF-8 conversion, but see st...Ported Issue from Mantis
Original ID: 124
Reported By: Maxim
SEVERITY: CRITICAL
Submitted: 2002-10-22 12:44:33
OS: _-_-
VERSION: ALL
## DESCRIPTION
<br>
I can't use russian words for nodes in DOTTY.
I do UTF-8 conversion, but see strange symbols.https://gitlab.com/graphviz/graphviz/-/issues/1115[Output Generation] HPGL output text labels are out of alignment2021-05-07T15:04:52ZSteve (Gadget) Barnes[Output Generation] HPGL output text labels are out of alignmentPorted Issue from Mantis
Original ID: 126
Reported By: Al Tobey
SEVERITY: MINOR
Submitted: 2002-11-01 22:03:40
OS: X86-LINUX-REDHAT 8.0 & 7.3
VERSION: 1.8.10
## DESCRIPTION
<br>
I have no idea what flags I used as I generated the gr...Ported Issue from Mantis
Original ID: 126
Reported By: Al Tobey
SEVERITY: MINOR
Submitted: 2002-11-01 22:03:40
OS: X86-LINUX-REDHAT 8.0 & 7.3
VERSION: 1.8.10
## DESCRIPTION
<br>
I have no idea what flags I used as I generated the graph from perl. The graphs all look fine when output as png, jpeg, postscript, etc., but the HPGL comes out with bad text alignment.
I printed to an HP DesignJet 250C, and it looks like the left side of the text starts at the center of the box.
## <CD>
| |
| This is a descriptio| of a node
## | (234) |
</CD>
It looks correct in bitmap formats - here's what it should look like:
## <CD>
| |
| This is a description of a node |
## | (234) |
</CD>
<br>
Email me for more info.
I have verified the problem using an HPGL viewer (CERN HPGLVIEW).https://gitlab.com/graphviz/graphviz/-/issues/1114[Dot] line numbers in warnings?2021-03-17T03:53:00ZSteve (Gadget) Barnes[Dot] line numbers in warnings?Ported Issue from Mantis
Original ID: 131
Reported By: Joachim Nadler
SEVERITY: COSMETIC
Submitted: 2002-11-15 16:03:01
OS: X86-WINDOWS-XP
VERSION: 1.8.10
## DESCRIPTION
<br>
It is very nice, that dot issues warnings
(eg. for meanin...Ported Issue from Mantis
Original ID: 131
Reported By: Joachim Nadler
SEVERITY: COSMETIC
Submitted: 2002-11-15 16:03:01
OS: X86-WINDOWS-XP
VERSION: 1.8.10
## DESCRIPTION
<br>
It is very nice, that dot issues warnings
(eg. for meaningless lhead/ltail references).
But it might be even more helpful if they
were accompanied by a line number.
<br>
By the way: it is in general a good thing that dot automatically
inserts a node "x" by default if it is referenced
in an edge "x -> y" and "x" has not been declared before.
But sometimes a typo might be involved so that an unintended
edge is created! This case might be difficult to spot
in a large graph.
The "declare before use" paradigm served a purpose
in programming languages, so maybe it is useful in
this case too.
So I suggest to introduce a command line option that
warns if an edge references an (previously?) unseen node.
What do you think?
## ADDITIONAL INFORMATION
Thank you very much in advance.
This is really a great tool to work with.
[erg] Line numbers on warnings will involve code change. We could
decide to maintain line numbers in the graph, but because nodes
and edges can be used multiple times, line numbers would also have
to be attached to attributes. Alternatively, moving the check to
the parser wouldn't work in general, because the use of ltail
or lhead in an edge may precede the definition of the cluster.
As for providing stricter checking, this could be helpful. Other
possible checks would be for multiple edge expressions for the same
edge, and reporting attributes or values unrecognized by graphviz.
This last would probably be most helpful if it checked specifically
for attributes close to a known attribute or value, to pick up
potential misspellings.https://gitlab.com/graphviz/graphviz/-/issues/1113[Dot] Re: [graphviz] strange warning + bad output from dot2021-05-29T04:22:20ZSteve (Gadget) Barnes[Dot] Re: [graphviz] strange warning + bad output from dotPorted Issue from Mantis
Original ID: 140
Reported By: John Lenton
SEVERITY: MINOR
Submitted: 2002-11-29 17:29:17
OS: X86-LINUX-2.4.18
VERSION: CVS
## DESCRIPTION
<br>
When running a graph through dot I repeatedly get a 'trouble in
...Ported Issue from Mantis
Original ID: 140
Reported By: John Lenton
SEVERITY: MINOR
Submitted: 2002-11-29 17:29:17
OS: X86-LINUX-2.4.18
VERSION: CVS
## DESCRIPTION
<br>
When running a graph through dot I repeatedly get a 'trouble in
init_rank' warning, a flood of ranks,
<CD>
virtual 60
virtual 3
virtual 3
virtual 3
virtual 3
virtual 7
.
.
.
</CD>
<br>
(a _lot_ of these), and the resulting graph isn't layed out correctly
(the nodes overlap).
<br>
Just 'dot', no arguments, triggers this. I haven't found any
combination of arguments that _doesn't_ trigger it, in fact.
I'm unable to find a smaller graph that does the same thing.
<br>
Sorry about the butt-uglyness of the graph -- I haven't had time
to clean up the output of the program that generates it.
<br>
I'll attach the output, in case it gives you any further clues.
<br>
Having been able to reduce a previously huge graph down to a measly
size (attached graph) while still seeing dot balk, I'm wanting to post
a followup to the bugreport. I'm probably blind, or had too much beer
at the LUG meet, but I can't seem to find that option.
<br>
Anyhoo, here she is. If you want to see what the graph _should_ look
like, remove the second and beforelast lines.
<br>https://gitlab.com/graphviz/graphviz/-/issues/1112[Dotty/Lneato/Lefty] dotty do not show changes in node attrs2023-01-03T05:05:14ZSteve (Gadget) Barnes[Dotty/Lneato/Lefty] dotty do not show changes in node attrsPorted Issue from Mantis
Original ID: 142
Reported By: Salvador Cavadini
SEVERITY: MINOR
Submitted: 2002-11-30 05:00:00
OS: WINDOWS 9X
VERSION: 1.8.10
## DESCRIPTION
when some nodes' properties are changes using "set attr" popup
men...Ported Issue from Mantis
Original ID: 142
Reported By: Salvador Cavadini
SEVERITY: MINOR
Submitted: 2002-11-30 05:00:00
OS: WINDOWS 9X
VERSION: 1.8.10
## DESCRIPTION
when some nodes' properties are changes using "set attr" popup
menu option, the changes are not visible until a "do layout" option
execution. For example, if we set "shape=circle" for a ellipse shaped node,
the node becomes a circle only after a "do layout".
## ADDITIONAL INFORMATION
[erg] To do a circle correctly, the graph needs to be laid out again,
to get the correct node size and allow for adjacent ranks to move.
Since dotty relies on the batch program dot for layout, it only does a
layout when the user asks for it. Presumably, the dotty scripts could
be changed to do a layout whenever an attribute change occurs.
Alternatively, the file dotty_draw.lefty in lib/lefty can be changed
as shown. This may produce, however, a circle too large (or if '>' is
changed to ',', a circle too small).
<CD>
---
**\* 295,300 ****
--- 295,304 ----
pos = node.pos;
size.x = node.size.x / 2;
size.y = node.size.y / 2;
- if ((node.attr.shape == 'circle') | (node.attr.shape == 'doublecircle')) {
- if (size.x > size.y) size.y = size.x;
- else size.x = size.y;
- }
if (~(label = node.attr.label) | label == '\N')
label = node.name;
if (node.attr.style == 'filled') {
</CD>https://gitlab.com/graphviz/graphviz/-/issues/1111[Dotty/Lneato/Lefty] lefty readline from pipe hangs on Solaris2021-05-29T04:18:43ZSteve (Gadget) Barnes[Dotty/Lneato/Lefty] lefty readline from pipe hangs on SolarisPorted Issue from Mantis
Original ID: 150
Reported By: Marko Makela
SEVERITY: MAJOR
Submitted: 2002-12-11 05:00:00
OS: SPARC-SUN-SOLARIS2.8
VERSION: 1.8.10
## DESCRIPTION
<br>
The visualization interface of my program "maria"
...Ported Issue from Mantis
Original ID: 150
Reported By: Marko Makela
SEVERITY: MAJOR
Submitted: 2002-12-11 05:00:00
OS: SPARC-SUN-SOLARIS2.8
VERSION: 1.8.10
## DESCRIPTION
<br>
The visualization interface of my program "maria"
(http://www.tcs.hut.fi/Software/maria/) fails on Solaris.
When I try to use any functions that would communicate to
the dotty-based "maria-vis" script via pipes, the dotty
window opens, but the mouse pointer inside the window
remains as a wristwatch and nothing happens.
## ADDITIONAL INFORMATION
I think I reported this bug about one year ago,
but my fix has not been applied.https://gitlab.com/graphviz/graphviz/-/issues/1110[Dot] Recursive line on cluster doesn't work2023-01-31T00:04:24ZSteve (Gadget) Barnes[Dot] Recursive line on cluster doesn't workPorted Issue from Mantis
Original ID: 153
Reported By: Johnny Willemsen
SEVERITY: COSMETIC
Submitted: 2002-12-20 09:14:06
OS: X86-WINDOWS-XP SP1
VERSION: 1.8.10
## DESCRIPTION
<br>
I want to create a recursive transition on a cluste...Ported Issue from Mantis
Original ID: 153
Reported By: Johnny Willemsen
SEVERITY: COSMETIC
Submitted: 2002-12-20 09:14:06
OS: X86-WINDOWS-XP SP1
VERSION: 1.8.10
## DESCRIPTION
<br>
I want to create a recursive transition on a cluster to generate
a recursive transition on a UML state diagram. To do this I use
a child state as tail and head but this doesn't work, the transition
is created from the child state and not on the cluster
## ADDITIONAL INFORMATION
[erg] This is not a bug but a request for real compound graphs. The
documentation indicates that, at present, we don't support edges between
nested clusters.https://gitlab.com/graphviz/graphviz/-/issues/1109[Dot] dot gives poor results on graph2021-03-20T02:23:55ZSteve (Gadget) Barnes[Dot] dot gives poor results on graphPorted Issue from Mantis
Original ID: 158
Reported By: Chris Bartels
SEVERITY: MINOR
Submitted: 2003-01-11 01:22:47
OS: X86-LINUX-REDHAT 7.2
VERSION: 1.8.9
## DESCRIPTION
<br>
I am trying to use dot to graph dynamic bayesian network...Ported Issue from Mantis
Original ID: 158
Reported By: Chris Bartels
SEVERITY: MINOR
Submitted: 2003-01-11 01:22:47
OS: X86-LINUX-REDHAT 7.2
VERSION: 1.8.9
## DESCRIPTION
<br>
I am trying to use dot to graph dynamic bayesian network templates.
It works great for simple examples, but on more complex graphs it often
wraps the edges which go between clusters completely around the graph.
Thank you for your help.
<br>https://gitlab.com/graphviz/graphviz/-/issues/1108[Dot] Too Much Memory needed2020-06-05T03:31:49ZSteve (Gadget) Barnes[Dot] Too Much Memory neededPorted Issue from Mantis
Original ID: 161
Reported By: Fred Fillon
SEVERITY: MAJOR
Submitted: 2003-01-20 14:30:37
OS: X86-LINUX-SLACKWARE 8.1
VERSION: 1.8.10
## DESCRIPTION
<br>
Good morning,
<br>
First, your softwares are very use...Ported Issue from Mantis
Original ID: 161
Reported By: Fred Fillon
SEVERITY: MAJOR
Submitted: 2003-01-20 14:30:37
OS: X86-LINUX-SLACKWARE 8.1
VERSION: 1.8.10
## DESCRIPTION
<br>
Good morning,
<br>
First, your softwares are very usefull ! Thank you !
<br>
I am trying to make the "path analyse" from one of my web site,
I used apache2dot.pl and pathanalyzer for creating dot file.
<br>
Everything works fine, but if I do this on a large file, dot or neato
seems to need a lot of mmemory more than 1,5 Gb for a 77Mo dot file.
I tried with a lesser file about 14Mo dot file, same problem.
<br>
Do you have a special parameter for hudge file ? Do you know the relation
between dot file size and memory needed ?
<br>
Best Regards.
https://gitlab.com/graphviz/graphviz/-/issues/1107[Neato] Pinning nodes in neato gives weird results2021-03-20T02:25:20ZSteve (Gadget) Barnes[Neato] Pinning nodes in neato gives weird resultsPorted Issue from Mantis
Original ID: 165
Reported By: Lev Pevzner
SEVERITY: MAJOR
Submitted: 2003-01-23 05:00:00
OS: _-_-*
VERSION: 1.8.10
## DESCRIPTION
<br>
I'm trying to use neato to lay out the graph in the dot input below. Thi...Ported Issue from Mantis
Original ID: 165
Reported By: Lev Pevzner
SEVERITY: MAJOR
Submitted: 2003-01-23 05:00:00
OS: _-_-*
VERSION: 1.8.10
## DESCRIPTION
<br>
I'm trying to use neato to lay out the graph in the dot input below. This
graph has two pinned nodes and lots of unpinned ones. When I run neato on
this dot file, the unpinned nodes get laid out in a small corner of the
screen, even though I have the "ratio" attribute set to "fill" -- the
output file is attached as layout_output1.dot. When I perform the same
layout without pinning the two nodes, I get a perfectly good layout that
fills the screen as intended.https://gitlab.com/graphviz/graphviz/-/issues/1106[Dot] Aborted (core dumped) using clusters2020-07-03T22:08:44ZSteve (Gadget) Barnes[Dot] Aborted (core dumped) using clustersPorted Issue from Mantis
Original ID: 168
Reported By: Alena Laskavaia
SEVERITY: CRITICAL
Submitted: 2003-01-29 15:32:21
OS: X86-LINUX-2.4.2-2 RED HAT
VERSION: 1.8.10
## DESCRIPTION
<br>
Dot crashing on certain file
<CD>
> dot -Ver...Ported Issue from Mantis
Original ID: 168
Reported By: Alena Laskavaia
SEVERITY: CRITICAL
Submitted: 2003-01-29 15:32:21
OS: X86-LINUX-2.4.2-2 RED HAT
VERSION: 1.8.10
## DESCRIPTION
<br>
Dot crashing on certain file
<CD>
> dot -Verbose -Tps qq.dot
> dot version 1.8.10 (Tue Jan 28 15:51:28 EST 2003)
> dot -Tps qq.dot
> Aborted (core dumped)
> uname -a
> Linux pmerd200 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
> </CD>
## STEPS TO REPRODUCE
digraph G {
rankdir=LR;
size="10,8";
orientation=landscape;
subgraph cluster_13 {
label="FILE source.c"
source13 [label="#include ''header.h''\nmain(){ return 1;}\n",shape=box]
53 [label="main"];
source13 -> 53 [label="contains",weight=100,color=orange,constraint=false ]
}
subgraph cluster_14 {
label="FILE header.h"
source14 [label="#ifndef **HEADER \n#define __HEADER \ntypedef int type; \n#include ''header1.h'' \ntypedef type_x \* p_type_x;\n#endif \n",shape=box]
44 [label="__HEADER"];
source14 -> 44 [label="contains",weight=100,color=orange,constraint=false ]
47 [label="type"];
source14 -> 47 [label="contains",weight=100,color=orange,constraint=false ]
52 [label="p_type_x"];
source14 -> 52 [label="contains",weight=100,color=orange,constraint=false ]
}
subgraph cluster_15 {
label="FILE header1.h"
source15 [label="#ifndef __HEADER1 \n#define __HEADER1 \n#include ''header2.h''\n#endif \n",shape=box]
45 [label="__HEADER1"];
source15 -> 45 [label="contains",weight=100,color=orange,constraint=false ]
}
subgraph cluster_16 {
label="FILE header2.h"
source16 [label="#ifndef __HEADER2 \n#define __HEADER2 \n#include ''header.h''\ntypedef struct x {\n type a; \n int b; \n} type_x; \n#endif \n",shape=box]
46 [label="__HEADER2"];
source16 -> 46 [label="contains",weight=100,color=orange,constraint=false ]
48 [label="type_x"];
source16 -> 48 [label="contains",weight=100,color=orange,constraint=false ]
50 [label="a"];
49 -> 50 [label="contains",weight=100,color=orange,constraint=false ]
51 [label="b"];
49 -> 51 [label="contains",weight=100,color=orange,constraint=false ]
49 [label="x"];
source16 -> 49 [label="contains",weight=100,color=orange,constraint=false ]
}
3 [label="@__UNDEFINED**@"];
source13 -> source14 [label="includes" ]
source14 -> source15 [label="includes" ]
source15 -> source16 [label="includes" ]
source16 -> source14 [label="includes" ]
source14 -> 44 [label="reads" ]
50 -> 47 [label="uses" ]
48 -> 49 [label="uses" ]
52 -> 48 [label="uses" ]
}