Include graphviz source code in SVG output

Dev
1

Graphviz should be able to output its dot language source code as part of SVG documentation. Although simply commenting it with XML comments “< ! - -” and “- - >” would run into trouble with “- -” content, you could use a combination of CDATA and defs instead at the end of the SVG file like this:

<!-- Graphviz source code: -->
<defs>
<![CDATA[

graph example { 
  Hello -- world
}

]]>
</defs>
</svg>

This should be trivial to implement and very helpful for recovering the dot source from generated SVG files.

1 Like
2

Do you have a use case for this?

3

Just today I was providing a SVG image of a PV power diagram to someone and I wanted to include the source with the SVG so he could modify it if he wanted to without having to keep track of the source file for which SVG he’s looking at. Actually it would be cool if it could recognize its own source within a SVG as input… You wound’t need to keep around separate source files.

1 Like
4

It would also be nice to be able to find the source to old SVG files when they get separated.

5

Seemingly you can do this now, using the comment attribute:

f=ranksep00.gv;T=svg;F=$(basename $f .gv); /usr/bin/dot -G"comment=$(cat $f)" -T$T $f >$F.$T

But if you want it as a default, create an issue here: Issues · graphviz / graphviz · GitLab

1 Like
6

well sort of - but it tries to put it into a regular XML comment, and to avoid the double dash problem, all dashes are replaced with entity - which doesn’t lend itself to easily copying the source code back from a comment. That’s why CDATA was suggested. Thanks for the link to the issues database.

7
8

Maybe this is a silly question, but if your recipient is modifying the source then they also have Graphviz installed, so why not just email around DOT files instead of SVGs? You can both view them as SVGs (or anything else) on your respective sides.

9

I don’t know for a fact when I send it whether he has graphviz installed or not. I do know he’s an engineer who can install it.
Also for archival, I’ll see the thumbnails of SVGs and be able to find them, not dot files.

10

If this isn’t approved, then perhaps using an image database will help you on managing source and output files easier

11

related idea: