twopi regression?

Dear All,

I've had occasion to return to the problem discussed here . I eventually got version 2.28 running on my linux shared host at webfaction. The twopi layouts on my mac running 2.29 were still better, but the layouts generated by 2.28 were acceptable. I've returned to this now and thought I could improve matters by installing GV 2.36 on my shared host. To my dismay, I have what looks like a regression.

here's my graph rendered by twopi as svg by GV 2.36 on my linux shared webhost (I tried rendering it as a png image and got the same sort of results):

gv 2.36

The same graph rendered by twopi with GV 2.29 on my mac:

gv 2.29


The program that generates these graphs is a python cgi script that delivers svg on request for display in a web page. The SVG output has the version clearly stated in the source, so I'm reasonably confident that my local installation of GV on my webhost is generating the graph rather than the host's version at /usr/local/bin where GV is still at 2.26.

I've attached the dot file from which both of these visualizations are drawn. Am I actually seeing some sort of regression, or am I doing something stupid that I've not figured out yet?



deeds-00880776.txt13.8 KB
deeds776GV2.36.txt37.73 KB
deeds776GV2.36-with-v_trace.txt36.43 KB

When I run 2.36 on your

When I run 2.36 on your graph, I get something like the preferred drawing. And I have to say the bad drawing is what you would get with 2.26. All I can suggest is for you to post the bad svg output and let me have a look at it, or file a bug report. 

2.36 svg

erg, thanks for having a look. I've attached the svg file to my original post. I'm baffled, and I can't shake the feeling that I'm doing something obvious, or stupid, or that there's something wonky about my install of 2.36; but this used to work.

I'm using pygraphviz to generate the dot by translating an RDF graph into an AGraph instance and then calling draw on it like this:
dgsvg = brat2dot(g).draw(format='svg', prog='twopi')

any insight you might have to offer would be gratefully received.

-- jon


I should have asked for this

I should have asked for this with the svg. Can you also run twopi with -v, capture the trace output and post that as well? Thanks.

svg output w/ -v trace

Of course, I should have thought of that myself. I've attached the svg output with the trace prepended. I don't really know what to look for. Anything suggestive there?


Well, you'll note the line  

Well, you'll note the line

  Adjusting %3 using Voronoi

This indicates that, indeed, the overlap removal is using the old voronoi technique, not the new prism technique. Prism has long been the default if you say overlap=false, unless it is not available. It is not available if you do not have the GTS library installed, or if you don't provide the triangle library.  You can check this by grepping config.h for GTS and TRIANGLE. If both are #undef'ed, prism won't work. The simple fix is to install the gts triangle library. Alternatively, you can find Shewchuk's triangle.c and triangle.h on the web, and put them in lib/sfdpgen. In either case, rerun configure, rebuild and you should be set.

twopi svg output fixed


Well, that went remarkably smoothly! The GTS Library installed in my shared webhost without a hitch, likewise the reconfigure and rebuild of GV, and I instantly had nice radial layouts. I can't thank you enough!

kudos, admiration, and thanks,


Recent comments