Graphviz has a notion of things like “URLs” and “tooltips,” but what actual UX these translate to is entirely up to downstream tools.
Graphviz does not seem to express URLs in PDFs in a way that PDF tools can leverage that info. When I load a GV-generated PDF into Evince, nodes that had an URL are not hyperlinks. Contrast that with SVG images, which can be loaded with Firefox and the nodes with URLs can be clicked on.
If Graphviz was outputting LaTeX it would probably make sense for it to emit any URL as a hyrperref.
Indeed it would, which I believe is the proposal of this steveroush. It might overcome current limitations, assuming hyperref works in TikZ code.
I’m still a little unclear on the use case. What do you want to achieve that is today not possible with the Graphviz PS back end?
Consider this demo of a GV SVG where someone took advantage of hyperlink nodes in some places:
The problem is, with today’s implementation that’s only possible in an SVG. It would be useful to be able to produce a PDF that has hyperlink nodes too. It would be quite useful for an ebook to have interactive diagrams. Note that while it would be cool if GV were to produce hyperlink nodes in PDFs, those hyperlinks would likely be destroyed when latex imports the PDF. So directly generating TikZ code may be the solution.
BTW, I was wrong about SVG being incompatible with LaTeX. This elaborates:
pdflimitation [shape=note, style="filled", fillcolor=yellow2, tooltip="would be a useful enhancement",
label="URLs are not hyperlinks and\lhacking them in expost-facto\lis likely impractical\l"];
pslimitation [shape=note, style="filled", fillcolor=yellow2,
label="URLs are not hyperlinks,\lbut that's expected in PS docs\l"];
svglimitation [shape=note, style="filled", fillcolor=yellow2,
label="URLs are hyperlinks"];
pdfanchor [shape=point, width=.01, height=.01, label="", invisible=true];
psanchor [shape=point, width=.01, height=.01, label="", invisible=true];
svganchor [shape=point, width=.01, height=.01, label="", invisible=true];
pdflimitation -> pdfanchor [arrowhead=none, style=dotted];
pslimitation -> psanchor [arrowhead=none, style=dotted];
svglimitation -> svganchor [arrowhead=none, style=dotted];
TeX -> DVI [label="latex\l(PDF features\lmostly unsupported)\l"];
DVI -> PDF [label="dvipdf"];
PS -> PDF [label="eps2pdf"];
PS -> DVI [label="includegraphics;latex"];
TeX -> PDF [label="pdflatex"];
PDF -> PDF [label="includegraphics;pdflatex\l(hyperlinks lost)\l"];
DOT -> pdfanchor [label="dot -Tpdf", arrowhead=none];
pdfanchor -> PDF [label="vector PDF\l(good)\n"];
DOT -> psanchor [label="dot -Tps", arrowhead=none];
psanchor -> PS;
DOT -> svganchor [label="dot -Tsvg", arrowhead=none];
svganchor -> SVG [label="vector format that\lLaTeX can't import natively\l"];
SVG -> PDF [label="includesvg;pdflatex\l(Inkscape conversion)\l"];
Notice that the “pdflimitation” (top left) note is missing from the SVG that’s embedded above. That’s also the only node that has an URL. So is this forum stripping out clickable nodes?
It’s also worth noting that the “svg” package for LaTeX is buggy and can’t be used in the same docment that \includepdf (from pdfpages pkg) is used. Even if Inkscape were to improve to preserve hyperlinks, it would be of no use to LaTeX because the PDF imports lose the hyperlinks.
I just thought of another use case. I often want to post graphs with clickable nodes in blogs and forums, but they all refuse to accept SVG images. Being able to produce a PDF with clickable nodes would serve in those cases.