JoachimDurchholz

1.14 works now, including for French and German.
Thanks!

(I haven’t tested the resizing stuff. I’m not seeing any Javascript, so I’m happy with that.)

Telling the browser to use a different scaling factor via Ctrl-Plus and Ctrl-Minus actually works, so that rules out the easy “it’s a browser bug” explanation.

I read up on coordinates in the HTML specs, and found that coordinates are to be given in pixels, not imagemap percentages. No hints of scaling for an <img width=…> setting either, so browser behaviour seems to be conformant with the spec.
So there’s nothing that Graphviz can do, since it doesn’t see HTML tags and attributes, just .dot files and command-line parameters.

I don’t see a way to tell Graphviz that it should anticipate a different image width for generating the image map. The way to go seems to specify a different size= attribute in the dot source, see also dpi=, page=, and ratio= in https://www.graphviz.org/doc/info/attrs.html .

This all amounts to saying that saying [graphviz width=…] cannot ever work properly, the image needs to be included at its default size.
Maybe you want to deprecate width= on [graphviz] – I didn’t find that parameter documente on the plugin page so maybe it’s easy to remove.

Take this all with a grain of salt, time’s running out for today so I couldn’t do any experimentation and verification with these findings. Maybe I’ll find more time tomorrow in the evening.
Hope this all helps.

no_texturize_shortcodes looks good, yes.

Avoid JS if you can. My offer to take a look at a non-working URL stands.

MUCH better!

Now I get this:

Error generating Graphviz image

Graphviz cannot generate graph
Command: /usr/bin/dot ‘-Kdot’ ‘-Tpng’ ‘-o/var/www/webs/jo/html/durchholz.org/wp-content/tfo-graphviz/872702058610b9e66b4cdd7930c3ed7f.png’
Output:
Warning: : syntax error in line 7 near ‘&’

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

Which is still a failure but at least I’m seeing it’s leaving in the opening quotes. These are opening quotes, not HTML entities.
I found that this is caused by language preferences; the opening quotes in German are different than the closing ones.

Language differences do more. This is what I get for French:

1
2 digraph hierarchy {
3 size= ?5,5″
4 node[shape=record,style=filled,fillcolor=gray95]
5 edge[dir=back, arrowtail=empty]
6
7 2[label = ? {AbstractSuffixTree|+ text\n+ root|…} ?]
8 3[label = ? {SimpleSuffixTree|…| + constructTree()\l…} ?]
9 4[label = ? {CompactSuffixTree|…| + compactNodes()\l…} ?]
10 5[label = ? {SuffixTreeNode|…|+ addSuffix(…)\l…} ?]
11 6[label = ? {SuffixTreeEdge|…|+ compactLabel(…)\l…} ?]

… but I LOVE how I can see what’s actually happening!

Many thanks – looking forward to trying out 1.13!

The imagemap problem isn’t going to affect me, but if you can refer me to a URL with a failing imagemap, I may be able to spot something off.

Urk. That quote mark conversion really stinks.
That might explain why all the other lines fail, too. There are many strings in the example dot. The size setting isn’t that important (it’s just what happened to be in the example I was working off, and scheduled for removal-if-possible), but somehow I doubt I can work entirely without quote marks, I need to do a lot of labelling with all kinds of punctuation for UML diagrams.
It would be nice if the WP API offered a way to say “please don’t transform the stuff between [graphviz] and [/graphviz]”, but given that you say “needs some work” I guess that’s not available.

The example dot renders as 17k in png and 6k in svg; not a big deal but might become a factor for larger graphs. Plus, maybe future browsers allow copying labels from SVGs so people can paste them to their texts (never give up hope ?? ).
SVG is widely accepted enough for Wikipedia to use it, so I guess it’s ready for the unwashed masses ??

Yes, a dotfile dump with line numbers would be really, really, really pretty please nice!
Graphviz error messages are vague enough to be almost useless, the line number is almost the only thing to go by. I don’t know whether whitespace mangling can fold lines, but if it does, then line numbers will be indispensable to diagnose problems.
If whitespace mangling can create syntax errors, then printing the dot source will also be essential to even start diagnosing things.

The command line would be heplful, too, to find out whether the options given in the [graphviz] tag are getting transformed to the options I expect.
It’s not as important as the dot source dump, but it would be very nice to have.