Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002269graphvizOutput Generationpublic2013-03-11 06:232013-08-22 22:34
Assigned Toellson 
StatusinactiveResolutionno change required 
PlatformMacOSOSXOS Version10.8.2
Summary0002269: Node is drawn twice in digraph
DescriptionOne of the nodes in a graph seems to be "split" and is drawn twice. It seems to affect all of the tools, but the problem is particularly dramatic in the case of circo, where the duplicate node is drawn outside the circle.
Steps To ReproduceThe attached graph file contains 13 nodes. If drawn with neato, circo, etc. using

/usr/local/bin/neato -Tpng anon.gv -o anon.png

14 nodes are drawn, two of which with the same label - "rt". One of the edges goes to one version of the node, the remaining edges go to the other. If you change the order the nodes appear in the file, a different node is affected by the duplication.
Additional InformationI tried this on graphviz versions 2.28, 2.30 and the development version 2.31. All are affected, with 2.28 even crashing for certain permutations of the nodes.
TagsNo tags attached.
VERSION2.31.20130311.0445 (20130311.0445)
Attached Files? file icon anon.gv [^] (1,010 bytes) 2013-03-11 06:23
? file icon anon2.gv [^] (762 bytes) 2013-03-11 09:34
? file icon anon3.gv [^] (761 bytes) 2013-03-11 09:43

- Relationships

-  Notes
User avatar (0000313)
ellson (administrator)
2013-03-11 09:36
edited on: 2013-03-11 09:36

anon.gv doesn't use "node" correctly. I've updated anon2.gv, but this doesn't fix the primary problem of a repeated node , now "mu". Weird one!

User avatar (0000314)
ellson (administrator)
2013-03-11 09:44

anon3.gv fixes it. There was some non-printing character in the line "urt -> mu;" just before the 'm'.
User avatar (0000315)
ellson (administrator)
2013-03-11 09:51

hexdump shows there was a 302 240 sequence in place of the space.

Is that UTF-8 ?
User avatar (0000317)
erg (administrator)
2013-03-11 11:02
edited on: 2013-03-11 11:03

Actually, it is. It corresponds to 0xA0,  non-breaking space, so you don't see it in the label. So the output is exactly what the user specified. And since it is legal utf-8, there is no reason for a warning.

User avatar (0000318)
ellson (administrator)
2013-03-11 11:36

Yes, but, it is being treated as part of the token string and not as a token separator. So now you have nodes "mu" and "<0xA0>mu" which is probably not what is wanted.
User avatar (0000319)
pmjordan (reporter)
2013-03-11 11:44

So a couple of observations:

1. The non-breaking space was not intentional and must have slipped in during a copy & paste. Definitely user error there.

2. Re the comment 'anon.gv doesn't use "node" correctly' - there aren't any syntax errors or warnings, so I'd be keen to know what is "incorrect" about it? If you mean that the label matches the node name: in the original, the labels are actually something else. This also leads me to think there is some kind of bug in there because the duplicated node had the "correct" human-readable label, not "mu" with the non-breaking space. Not knowing any of the graphviz internals, my guess would be that there are two tokenisation steps here, one of which treats the unicode character as a token delimiter (so that they both end up as "mu" for the purposes of the label lookup) and the other treats the character as part of the token, which causes it to treat the nodes as distinct for the purposes of the graph.
User avatar (0000320)
erg (administrator)
2013-03-11 12:26

"Not correctly" was probably too strong. Your original syntax was correct and specified what you were after, just non-standard and more verbose than necessary. Typically, the node and edge keywords are used to specify global defaults in the context of a subgraph, so the attribute doesn't have to be repeated. Specific attributes are usually attached directly. So, instead of

    node [label="uuv"] uuv;
    node [label="ut"] ut;
on tends to use

    uuv [label="uuv"];
    ut [label="ut"];

As for tokenization, the scanner is ascii-based, so we rely on a few ascii punctuations, separators and syntactic sugar, and all of the remaining ascii and all non-ascii are considered uninterpreted bytes. Interpretation only occurs if a string is being used as a label.

So in the given graph, there are two separate nodes, one named mu and one named
0xA0mu. The labels will probably look almost the same, except the mu in the second case will be shifted a tad to the right.

We could probably do a one-off and catch 0xA0 (not in quoted string) in the scanner, treat is as an ordinary space and give a warning.
User avatar (0000321)
pmjordan (reporter)
2013-03-11 12:31

To be clear, I had:

node [label="Something something"] mu;

And there were two nodes labeled "Something something" in the graph, and none labeled mu. I guess the last label ended up being the default label for all the nodes following it, including implicitly generated nodes? Otherwise I can't explain that behaviour.
User avatar (0000322)
erg (administrator)
2013-03-11 12:35

Yes, every node after that statement will have the label "Something something", until you do another node[label="Something else"] or unless a node gets its own label attribute.

- Issue History
Date Modified Username Field Change
2013-03-11 06:23 pmjordan New Issue
2013-03-11 06:23 pmjordan File Added: anon.gv
2013-03-11 09:34 ellson File Added: anon2.gv
2013-03-11 09:36 ellson Note Added: 0000313
2013-03-11 09:36 ellson Note Edited: 0000313 View Revisions
2013-03-11 09:43 ellson File Added: anon3.gv
2013-03-11 09:44 ellson Note Added: 0000314
2013-03-11 09:51 ellson Note Added: 0000315
2013-03-11 11:02 erg Note Added: 0000317
2013-03-11 11:03 erg Note Edited: 0000317 View Revisions
2013-03-11 11:04 erg Assigned To => ellson
2013-03-11 11:04 erg Status new => assigned
2013-03-11 11:04 erg Resolution open => no change required
2013-03-11 11:36 ellson Note Added: 0000318
2013-03-11 11:44 pmjordan Note Added: 0000319
2013-03-11 12:26 erg Note Added: 0000320
2013-03-11 12:31 pmjordan Note Added: 0000321
2013-03-11 12:35 erg Note Added: 0000322
2013-08-22 22:34 erg Status assigned => inactive

MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker