Guidelines for Node label formatting

[GoogleCodeExporter]

It seems that formatting of the label string supplied to Node constructor
is very sensitive. I had working code that was producing svg with this kind of
string for node labels: $GUID__/ffb73e1c-7495-40b3-9618-9e5462fc89c7. Now I
think I have new pydot version and the code does not work:

Warning: /tmp/tmpxa46du:5: ambiguous "-40b" splits into two names: "-40" and  "b".

If I remove this string, the problems continue, something about newline at
the end of the remaining string (as I read on the forum somewhere).

What are the rules for the label string?
Thank you.

Original issue reported on code.google.com by [email protected] on 12 Dec 2013 at 10:06

[peternowee]

Some remarks before I close this 7 year old issue:

• The error message originates from Graphviz. It is from the old Graphviz lib/graph/lexer.c, which was replaced by lib/cgraph around 2013 (Graphviz 2.30.0 according to their changelog). Recently, the lib/graph directory was deleted from the Graphviz master branch.
• With a part of the string mentioned in the original question, left unquoted in a DOT-file, I was able to reproduce a similar error from the new lib/cgraph/scan.l using Graphviz 2.40.1 (without pydot):

  $ cat /tmp/tmp0wfhwgil
  digraph G {
  "N" [label=ffb73e1c-7495-40b3-9618-9e5462fc89c7];
  }
  $ dot -Tdot /tmp/tmp0wfhwgil
  Warning: syntax ambiguity - badly delimited number '-40b' in line 2 of /tmp/tmp0wfhwgil splits into two tokens
  Error: /tmp/tmp0wfhwgil: syntax error in line 2 near '-40'
  

• I found a random 2006 forum thread that also generated the old lib/graph error and found that with the example DOT-file given there I got the new lib/cgraph error now with Graphviz 2.40.1. This suggests that code that triggers the new error (like my example above) will likely to have triggered the old error in Graphviz versions of 2013 or before.
• Back to this issue here at pydot, because reproducible in Graphviz does not mean reproducing in pydot yet: The reason my example DOT above triggers the error in Graphviz is obviously the lack of quoting of the label value. So, did the OP run into some kind of regression in pydot's quoting behavior? The OP says on 2013-12-12 that he recently upgraded to the latest version of pydot. The most recent pydot release before that was pydot-1.0.28 of 2012-01-03, which contained commit ebfd155. That commit contained many changes with regard to quoting. I did not immediately see which of those could have prevented quoting of a string as mentioned by the OP, but I also did not spend much time on that. Perhaps one of the changed regular expressions.
• I tested the string mentioned by the OP with pydot 1.0.2, 1.0.25, 1.0.28 and current 1.4.1 using the following code, which has a loop to shorten the string by dropping one character from the left each time:

  import pydot
  G = pydot.Dot()
  LABEL = "\$GUID__/ffb73e1c-7495-40b3-9618-9e5462fc89c7"
  for i in range(1, len(LABEL)):
      N = pydot.Node(LABEL[i:], label=LABEL[i:])
      G.add_node(N)
  print(G)
  G.write_dot('pydot-pydot-88-out.dot')

  The result was the same every time: All node node names and labels were correctly quoted or not quoted, and Graphviz accepted the pydot output. One example line of the output that shows correct quoting:

   "ffb73e1c-7495-40b3-9618-9e5462fc89c7" [label="ffb73e1c-7495-40b3-9618-9e5462fc89c7"];

  So, I cannot reproduce that pydot wrongly omitted quotes in any of the mentioned versions.
• Perhaps the example string supplied by the OP was changed in the export of this issue from Google Code to Github.
• Perhaps quoting was not the problem? The OP also mentions possible issues with newlines. There was a change related to that between pydot 1.0.2 and 1.0.4 in commit 1f01e2d of 2010-12-31. But that would mean the OP upgraded from a 3 year old version. Unfortunately, the report is short on details.

Given the age of this issue, I assume we will not be getting more information, so I will close it now. If anyone still runs into one of the mentioned errors, feel free to reopen or open a new issue. Please provide a Minimal Reproducible Example (aka Minimal Working Example) then.

[peternowee]

With regard to the question:

What are the rules for the label string?

See The DOT Language, which pydot should normally follow. Where it does not can be reported as a possible bug here in this issue tracker.

[peternowee]

Reopening, because this issue was also discussed in the earlier pydot-fork pydot/pydot-ng#24. There are fixes mentioned there, although it is not clear to me how exactly they addressed the issue reported here. I will have a look at them later, together with all the other open issues related to quoting.