Chris Luke

Hm, so I added width and height attributes so you could scale the SVG to the page; unfortunately it seems browsers don’t scale attached image maps with the image.

The only way I see to fix this is to include some JavaScript that will do it, which feels icky for what this plugin is doing. Any thoughts?

I missed this. I’ll merge it now.

https://blog.flirble.org/2015/11/15/adding-svg-support-tfo-graphviz/ if you want to see the SVG thing working ??

I have added the SVG format too. Once I’ve tested it a bit I’ll release version 1.13.

If you’re curious, this is what WordPress turned your DOT into:

1
    2 digraph hierarchy {
    3 size="5,5″
    4 node[shape=record,style=filled,fillcolor=gray95]
    5 edge[dir=back, arrowtail=empty]
    6 2[label = "{AbstractSuffixTree|+ text\n+ root|…}"]
    7 3[label = "{SimpleSuffixTree|…| + constructTree()\l…}"]
    8 4[label = "{CompactSuffixTree|…| + compactNodes()\l…}"]
    9 5[label = "{SuffixTreeNode|…|+ addSuffix(…)\l…}"]
   10 6[label = "{SuffixTreeEdge|…|+ compactLabel(…)\l…}"]
   11 2->3;
   12 2->4;
   13 5->5[constraint=false, arrowtail=odiamond]
   14 4->3[constraint=false, arrowtail=odiamond]
   15 2->5[constraint=false, arrowtail=odiamond]
   16 5->6[arrowtail=odiamond]
   17 }
   18

I’ve added mappings for the two characters it’s mangling there. I just wish there was a way to turn this off.

I may have worked it out. I think WordPress is converting the second ” mark into a special one.

size="5,5"

became

size="5,5″

Meh, this may need some work.

If I remove the “size” directive, your dot works for me, so I’ll investigate why that is.

I’ll add something to the error to show you the command line; the dot itself is fed into stdinof the dot process. Would it be useful to have it include the dot in the error message? I think it will help because there’s whitespace mangling going on. What wordpress gives us from between the [graphviz] markers has various HTML encoding going on – some of which is destructive to whitespace. I could even add line numbers.

As for svg, it wasn’t widely renderable when this was written and nobody else has asked for it. That can be added, too.

I pushed the change to the development version. I’ll release it once I’m happy it doesn’t break anything else.

Done, let me know if it resolves your issue, or if it breaks something else ??

Okay, minimum requirement for WP is PHP 5.6 now, so yes, it’s safe to remove this backwards-compatibility thingy.

I’ll push that out a bit later.

Okay, I guess you have PHP 5.4 or newer set to be super picky. It’s complaining about defining both a classic constructor “TFO_Graphviz_Graphviz()” and a new-style one “__construct()” even though PHP has a well-defined heuristic for how to deal with this. The code needs the classic definition to be backward compatible.

So really the question is: Have we arrived at a point where we can remove the old-style constructor? I’ll noodle that.

I didn’t think Graphviz supported using a URL to refer to an image – it probably wants a filename, which means you need to refer to a file on the system where Graphviz is running.

Note that because you can’t always guarantee the working directory it’ll launch with, you’ll need to give it the full path too.

Changing that would need the plugin to interpret the DOT to find URLs and paths and fix them up. Not impossible, but not a small task either.

This should be resolved in version 1.9.

And annoyingly this site didn’t tell me about your post again. Hmm.

Thanks for the patch; this is in version 1.7 and should be released today.