Re: [graphviz-interest] Intended behaviour of "canon" output

John Ellson <[email protected]> Tue, 13 May 2014 09:21:52 -0400
Newsgroups gmane.comp.video.graphviz
Message-ID <[email protected]>
The language definition in
     http://www.graphviz.org/content/dot-language
hasn't changed, but the graph library that implements the core
graph parsing and data structures has changed from libgraph to libcgraph
in the three years or so.   So I suspect what you are seeing is some
syntactically-inconsequential difference in output ordering.

Your ordering assumptions are too strict, I believe.

John


On 05/13/2014 05:50 AM, Ivan Lazar Miljenovic wrote:
> What is the intended pretty-printing performed by "dot -Tcanon"?  My
> understanding from how it seemed to work was that for each
> graph/subgraph it would produce something like:
>
> <graph/subgraph specification> {
>      [possibly empty list of global attributes]
>      [possibly empty list of sub-graphs]
>      [possibly empty list of nodes]
>      [possibly empty list of edges]
> }
>
> However, at least in 2.38.0 (the last time I checked this behaviour
> was with 2.30 I think; I skipped a few versions when I realised my
> installation of Graphviz was old) this is not the case for some
> graphs: e.g. when applied to the undirected/ER.gv sample graph, whilst
> each node seems to be specified before any edges its used in, the
> nodes and edges are now mixed together.
>
> Is this the correct/expected behaviour?  I have some code that assumes
> it's in the old behaviour, so if this isn't the case I'll need to
> change how I'm parsing the Dot code.
>

_______________________________________________
[email protected]
http://lists.research.att.com/mailman/listinfo/graphviz-interest