|Anonymous | Login||2017-11-20 03:03 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002269||graphviz||Output Generation||public||2013-03-11 06:23||2013-08-22 22:34|
|Status||inactive||Resolution||no change required|
|Summary||0002269: Node is drawn twice in digraph|
|Description||One 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 Reproduce||The 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 Information||I 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.|
|Tags||No tags attached.|
|Attached Files|| anon.gv [^] (1,010 bytes) 2013-03-11 06:23|
anon2.gv [^] (762 bytes) 2013-03-11 09:34
anon3.gv [^] (761 bytes) 2013-03-11 09:43
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!
|anon3.gv fixes it. There was some non-printing character in the line "urt -> mu;" just before the 'm'.|
hexdump shows there was a 302 240 sequence in place of the space.
Is that UTF-8 ?
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.
|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.|
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.
"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
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.
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.
|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.|
|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|