# How does PGF/TikZ work?

How has it been possible to develop a huge vector graphics package, PGF/TikZ, entirely within the TeX language? Exactly how is it working under the hood? Which techniques and TeX primitives does it rely on to produce its graphical output in my TeX document?

• PGF relies on \special, with drivers for each engine used for producing the final output, so dvips, (x)dvipdfmx, pdftex and luatex. The higher level graphic commands are translated into lower level \special commands tailored for the used engine. – egreg Jun 11 '16 at 10:43
• You can find the implementation of the drivers in the files pgfsys-<driver>.def. – Henri Menke Jun 11 '16 at 10:58

Let's look at a simple example

\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\tracingmacros=1
\draw (0,0)--(1,1);
\end{tikzpicture}
\end{document}


The \tracingmacros=1 instruction will show all macro expansions in the log file.

Compiling with latex we find

\pgfsys@invoke #1->\special {ps:: #1}
#1<-0.0 0.0 moveto

\pgfsys@invoke #1->\special {ps:: #1}
#1<-28.3468 28.3468 lineto

\pgfsys@invoke #1->\special {ps:: #1}
#1<-pgfstr


With pdflatex we find

\pgfsys@invoke #1->\pdfliteral {#1}
#1<-0.0 0.0 m

\pgfsys@invoke #1->\pdfliteral {#1}
#1<-28.3468 28.3468 l

\pgfsys@invoke #1->\pdfliteral {#1}
#1<-S


With xelatex, we see

\pgfsys@invoke #1->\special {pdf:code #1}
#1<-0.0 0.0 m

\pgfsys@invoke #1->\special {pdf:code #1}
#1<-28.3468 28.3468 l

\pgfsys@invoke #1->\special {pdf:code #1}
#1<-S


Finally, lualatex (with LuaTeX v. 0.90), produces

\pgfsys@invoke #1->\pdfextension literal{#1}
#1<-0.0 0.0 m

\pgfsys@invoke #1->\pdfextension literal{#1}
#1<-28.3468 28.3468 l

\pgfsys@invoke #1->\pdfextension literal{#1}
#1<-S


Higher level graphic commands are translated into lower level ones, but different for each engine used. PGF has various drivers and loads the relevant one, which provides the translations specially tailored for the used engine.

The primitive \special simply writes its argument to the DVI (or XDV) file and it's a duty of dvips or xdvipdfmx to use this code for providing a graphic rendering. With pdftex there is \pdfliteral that writes PDF code to the PDF file and the same for luatex, just with a different name.

Dealing with each possible graphic command would require a book. Look at the files

/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-pdf-via-dvi.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-pdf.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-postscript.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-svg.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvi.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvipdfm.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvipdfmx.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvips.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvisvgm.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-pdftex.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-tex4ht.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-textures.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-vtex.def
/usr/local/texlive/2016/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-xetex.def


• Also, with the mplib library in LuaTeX, I think it is not entirely unlikely that PGF might slowly develop into a partial front-end to metapost, at least when compiled using LuaTeX. – Gaussler Jun 11 '16 at 13:34
• You wrote: "it's a duty of dvips or xdvipdfmx to use this code for providing a graphic rendering." How are divps and xdvipdfmx supposed to know what to do with the literal pgfstr which, according to your example, is output when compiled with latex? pgfstr is not a PostScript command. – Evan Aad Aug 6 '17 at 13:03