# TikZ (and LaTeX) driver for Graphviz?

[Note: I’ve never written a single document using TeX, LaTeX, or TikZ, so bear with my mistakes]

In the last year or so I’ve noted several comments that it would be nice if Graphviz produced TikZ output. TikZ (PGF/TikZ - Wikipedia) is a vector graphics add-on for TeX/LaTeX. A while back I looked at the TikZ language and decided that writing a driver for TikZ itself (the vector graphics stuff) would be pretty straight-forward. But the text (LaTeX) part of the effort stopped me cold. So:

• Does anybody care about TikZ/LaTeX? Is this worth the effort?
• There is a graphviz-to-TikZ post-processor dot2tex (dot2tex - A Graphviz to LaTeX converter — dot2tex 2.11.3 documentation). It seems to do its own text processing after the nodes have beed sized and the edges positioned. Is it good enough?
• The problems I foresee:
• allowing LaTex text input
• converting “regular” Graphviz text to LaTex
• sizing the LaTex text for the Graphviz layout process

1 Like

I’m familiar with TikZ and LaTeX, though haven’t used either for a while. My initial question is who is asking about this and why? The reason I ask is that converting dot to TikZ doesn’t immediately make sense as a goal to me.

Dot and TikZ are both graph representations designed to be easy for humans to input. If you want your final graph in TikZ, why not just write it in TikZ in the first place?

Coming from the other direction… LaTeX is used as a means to producing something else, usually PDF. If you have a dot graph and want it in your final output, why not use Graphviz to convert it to e.g. PS and use LaTeX’s built-in support for including a PS file?

+1, I’d like to know more about the use case. How do people solve this problem today? Presumably they include dot graphs generated in other formats into their papers somehow?

i have used dot2tex as well as the LaTeX package that enables us to embed graphviz code directly in the LaTeX document source (dot2texi). Both have given me problems. I walked away from the project about 6 months ago so it’s not all fresh in my head ATM, but IIRC I reached a point where I concluded that I’ll have to generate PNG images which would then be imported. That’s essentially conceding defeat because in principle there is no reasen the document should have a pre-rendered raster blob in it. I also briefly considered producing PostScript with graphviz, but the problem is LaTeX has special PDF features which are indispensible (such as hyperref, I think), so to import PS forces compiling with latex (not pdflatex) & producing PostScript ultimately. The PostScript final doc can of course be converted to PDF but PDF special features are lost. So I might have to cut my losses and embed PNGs.

Another problem: I would like the nodes in a graph to be clickable. I’ve been able to produce an SVG from dot, and then manually hack the SVG file so that the nodes can be clicked to visit an URL. But there’s no way to import the SVG into LaTeX AFAIK.

I have to say I would much welcome more options because everything i’ve tested has show-stopping limitations. Perhaps I should go back to working on the project I stopped 6 months ago so I can recall the things that failed and better document the limitations.

BTW, TikZ also has some limitation that I found annoying. It’s been a while since I used it, but I seem to recall that it was impossible to nest a TikZ image inside another TikZ image. So it it means that if someone wanted to add some extra TikZ code that would draw things around what is generated, then I think they might have to edit the generated code.

[All these answers are my best guess]

• Graphviz does the layout (its strength)
• Graphviz is a high-level language (its strength)
• Allow TikZ/LaTeX text inclusion for label sizing (somehow)
• TikZ/LaTeX output output allows end-user placement modification (X/Y tweaking)
• TikZ/LaTeX output is editable (like SVG), it can be post-processed to add/modify features
• TikZ/LaTeX has the advantages of being a vector language

There seem to be 2 or 3 Graphviz-to-TikZ post-processors, but I don’t think that any of them support correct label sizing based on TikZ/LaTeX text formatting (https://ctan.math.illinois.edu/macros/latex/contrib/graphviz/graphviz.pdf, dot2tex - A Graphviz to LaTeX converter — dot2tex 2.11.3 documentation, https://mirrors.concertpass.com/tex-archive/macros/latex/contrib/dot2texi/dot2texi.pdf)

Maybe the question should go to a TikZ user forum.

Agree.

I don’t quite follow this point. latex vs pdflatex is what I’m confused by. LaTeX is the language (TeX plus some macros), right? And `pdflatex` is a tool for converting LaTeX source to PDF output. Are you talking about a difference between `pdflatex` and `xelatex`? Or vs `pandoc`? Maybe my taxonomy is wrong here.

I don’t follow this point either. Clickable in what? Surely this depends on what output format you’re producing? AFAIK there is no LaTeX primitive for describing something “clickable.” There’s URLs and hyperref but this is all assuming an HTML-fluent backend, I think.

Maybe there is a meta problem to be solved here, and Graphviz could produce “LaTeX” output… Maybe there is an output format that is neither TikZ nor PS but rather something more friendly to ingestion by a TeX tool.

I don’t quite follow this point. latex vs pdflatex is what I’m confused by. LaTeX is the language (TeX plus some macros), right? And pdflatex is a tool for converting LaTeX source to PDF output.

latex and pdflatex are both tools that compile LaTeX code. The pdflatex tool produces a PDF. The latex tool produces a DVI (device independent) file. The DVI file is an intermediate format. You can use xdvi to view it. DVI files are then converted to PostScript or PDF, or other formats (fax, gif, png, hp, laserjet, etc).

If you go straight from *.tex source to PDF using pdflatex, all the special PDF features are honored (which has lots of capabilities like embedding other (MIME specified) files in the PDF, and having hyperlinks to URLs that will launch when clicked).

You can also get a PDF the old way: *.tex => DVI => PDF using the dvipdf tool for the last step. But the special PDF features are lost. IIRC there is a way to embed hyperlinks in the DVI and make them appear in a PDF (possibly with an extra PostScript middlestep), but I guess that’s only useful if hyperlinks is the only special PDF feature the doc uses.

You might be wondering why even consider the *.tex => DVI => PS => PDF route, as opposed to *.tex => PDF. The problem is that pdflatex does not support importing PostScript, so if you have \includegraphics{some_graphviz_output.eps} in the tex doc, the pdflatex tool will reject it. So if we must import a PosScript file from graphviz, then we must use the plain latex /tool/ to create a PostScript doc, convert to PDF, and give up some PDF features.

There is also XeLaTeX and LuaLaTeX tools, but I’m not real clear on what they offer. I just know one or two times I ran into a bizarre problem with my LaTeX code not being compiled correctly, and someone said use XeLaTeX and LuaLaTeX instead, and it fixed my problem.

I don’t follow this point either. Clickable in what? Surely this depends on what output format you’re producing?

The hyperref LaTeX package enables you to put hyperlinks to URLs in your document, thus making the document interactive. Clicking a link launches a browser from the PDF doc.

Thanks for the explanation. This makes a lot of things clearer to me.

I guess this is sort of an impedance mismatch. Graphviz has a notion of things like “URLs” and “tooltips,” but what actual UX these translate to is entirely up to downstream tools. AFAIK there is no Graphviz mechanism for specifying something as “clickable” or “hyperlinked.”

If Graphviz was outputting LaTeX it would probably make sense for it to emit any URL as a `hyrperref`.

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?

Here is my poor diagram of things available today. What arrow is missing from this?

``````digraph {
DOT -> PS [label="dot -Tps"];
DOT -> PDF [label="dot -Tpdf"];
TeX -> DVI [label="latex"];
DVI -> PDF [label="dvipdf"];
PS -> PDF [label="eps2pdf"];
PS -> DVI [label="includegraphics;latex"];
TeX -> PDF [label="pdflatex"];
PDF -> PDF [label="includegraphics;pdflatex"];
}
``````

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:

https://contact.gombos.info/

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:

``````digraph {
pdflimitation [shape=note, style="filled", fillcolor=yellow2, tooltip="would be a useful enhancement",
URL=<https://forum.graphviz.org/t/tikz-and-latex-driver-for-graphviz/577/8>,
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,
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];

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"];

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.

(edit)
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.

So far:

• better text formatting
• easier post-processing (for folks who want to edit the TikZ/LaTex output)
• easier to use (no extra steps/tools)

Did I miss anything?

This still seems like a rather roundabout solution. Having said that, I think I understand the motivation a bit more now. Now it just needs someone to work on it

I still get lost with comments like this. What is a “clickable” node? I don’t think Graphviz generates anything like `onclick` attributes in SVGs, so surely any “clickable” behavior is related to how your viewer (your browser) chooses to interpret the SVG.

You have blogs/forums that don’t support embedding SVG but support embedding PDFs? I did not know such creatures existed. If you can point me to such a platform, I would be interested to take a look.

I guess the accumulated list is more like a set of feature requests than a single feature request.

Have a look at https://contact.gombos.info/ . If you hover over some of the nodes, the arrow becomes a hand. If you click, the browser will visit an URL.

The SVGs are not a problem because GV codes the hyperlinks correctly, unlike PDF. If GV just arbitrarily prints URL parameters somewhere, how will the viewer know what to do with them? The objects in the PDF container must be coded in a way that a viewer can recognize and render the URLs as hyperlinks.

Evince is a viewer that will render links to be interactive. If you view a pdflatex-generated PDF from a TeX doc that made use of hyperref, the links are made active (so clicking on them triggers a response) when viewed with evince. So Evince has the capability, but when evince opens a GV-generated PDF where objects were defined using the URL parameter, it reveals than information was lost. The URLs do not visibly appear, and the objects are not hyperlinks.

As a hack, one could possibly import a GV-generated pdf into a tex doc, recreate invisible objects that layer above a GV node, which are wrapped by an \href command from the hyperref package. But they shouldn’t have to.

GV’s current behavior fails the rule of least astonishment. That is, when a user populates the URL parameter they have an expectation that the parameter has a purpose when the output format supports it. SVG nodes are hyperlinks and PDF nodes are not. Why the inconsistency?

Yes. For security, SVGs are almost universally refused, likely because SVG can hold embedded javascript. Javascript is risky. Consider eBay, who pushes javascript to all their users that port scans their LAN and reports the results to ebay. That same code could be put in an SVG file. The only service I’ve found to accept it is a site for sharing creative commons clip art, because SVG is essential in that context. Github will allow SVG in repos, but they disarm them by forceably imposing an “octet-stream” MIME type, which breaks the UX. Users can only download them manually then open them manually. If you wrote a blog that said “sorry, I can’t let you see the text right here just now, please download this file and view it manually”, your post wouldn’t get much notice.

It’s a pity SVG was designed to accept javascript. That perverse design decision wrecked its potential.

PDFs can also be very dangerous, but they are tolerated and risks are taken because docs are essential in more contexts and PDF is king despite its major shortcomings. So acceptance is high (justified or not). Whether it’s “embedded” doesn’t matter from a UX point of view because all modern browsers have a built-in pdf.js, thus simulating the embedded UX no matter how the MIME is specified.

We keep jumping around here and I lose track of what’s being discussed. I just tried an experiment with `-Tsvg` and `-Tpdf` and both produce files where nodes with a `URL` attribute are clickable and go to that URL (at least in Firefox). So what is inconsistent here? I’m guessing this is not the SVG and PDF you’re referring to this time…?

I agree it’s a pity, but this apparently did not wreck its potential: https://www.xul.fr/svgtetris.svg

Graphviz does support PDF hyperlinks - even though the documentation doesn’t say so. My environment is messed up, so I cant’ tell if the hyperlinks are correct, but they are generated.
Give them a try.

A lot of it is one problem that is very multi-faceted, which gives the appearance of unrelated issues. There are several bugs:

• Inkscape’s SVG => PDF conversion is lossy (hyperlinks lost)-- but this is moot since GV can directly produce interactive PDFs (which I didn’t know earlier)
• When pdflatex imports a PDF, all hyperlink info is lost. So even when GV does the PDF generation correctly, it doesn’t solve the problem of getting active hyperlinks in a LaTeX doc
• \includesvg conflicts with \includepdf, thus reducing the value of importing SVGs
• (limitation) Doing everything in PostScript & converting to PDF as a final step may workaround the hyperlinking problem, but it would be impossible to use the attachfile package to embed files in the PDF.

All of those bugs are outside of GV. But GV can still be a possible solution. E.g.

• LaTeX proves that it is possible to include hyperlinks in PostScript. They are disregarded by PS viewers, but ps2pdf makes use of them & produces a PDF with active hyperlinks. I don’t know how it works, but I believe GV could produce PostScript that’s enhanced in that way. This would ultimately enable LaTeX docs to have interactive graphs that are GV-generated. It’s potentially a trivial fix, but OTOH the document could not at the same time embed files using the attachfile pkg (but pdftk could be used as a hack to embed files as a separate step).

• GV could produce TikZ code with hyperref constructs. I’ve not tested it, but if it doesn’t work that would be a bug in the TikZ package.

When I do the same with the GV code I posted, Firefox renders the top left note as an active hyperlink in the SVG, but the same node is dead in the PDF (no hyperlink, no tooltip when hovered). Perhaps this bug was fixed after dot version 2.38.0.

BTW, I tried grepping the binary PDF for part of the URL and also grepping the pdftotex output of the PDF and both came up dry as well.

OK, I’ve create an issue for the first one: translate URLs into something in PS files that is recognized by LaTeX as a hyperref (#1991) · Issues · graphviz / graphviz · GitLab

It’s possible. There have been a lot of changes between 2.38.0 and the current version. Unfortunately the various downstream volunteers we rely on to package Graphviz for Linux distros appear to have dropped off or been otherwise occupied since ~2.38.

In Postscript there must be special comments that indicate anchors for clickable content. Is that how it works? We could “easily” generate such comments, even without breaking anything that works today.

Note that PDF today is generated through cairographics and/or the OSX quartz library. In years of old, slightly to my amazement, cairo did not support clickable objects and my inquiries to their project were politely ignored. At some point, they added an API for this feature, and we attempt to invoke it, which you can see here: plugin/pango/gvrender_pango.c · main · graphviz / graphviz · GitLab

If it doesn’t work, either we did it wrong, or that feature isn’t actually supported in cairo.

Given the importance of this feature and the difficulties people have it would be good to fix this even if it’s not 100% backward compatible, or we could introduce a new way of doing this then phase out the old way.

I tested the driver based on pdfmarks in this approach (1st answer):

I had hyperlinks in the text of the LaTeX doc, and I also imported GV-generated PostScript where a node had an URL specified. The text in the body was correctly hyperlinked, and of course the GV node with the URL was not active.

Then I compiled with \usepackage{hyperref} instead of \usepackage[dvips]{hyperref}, expecting the link to no longer be a hyperlink, but it was still a hyperlink. I was hoping to be able to do a diff on the two PS files to see the difference, but I guess it won’t be quite that easy.

This is increasingly sounding like a LaTeX bug and not a Graphviz bug…

Just came across a related 10-year old discussion of this: [Output Generation] Support URL in PDF output (#531) · Issues · graphviz / graphviz · GitLab