# TikZ 3.0.0 (release) produces strange shadings if used with XeLaTeX and standalone

I would like to use shadings in my TikZ graphics together with the standalone package and XeLaTeX, but for some reason it is broken if I try with the new 3.0.0 release (download here). Any other combination I tried works for me (use for example article class/pdflatex/lualatex/TikZ 2.10).

(I'm using a fully updated TeX Live 2013.)

## MWE

\documentclass{standalone}
%\documentclass{article} % would work

\usepackage{tikz}

\begin{document}
\tikz \draw[top color=red] (0,0) rectangle (2,1);
\end{document}


## Question

How can I avoid the problem and which package/class is causing it?

• It is XeLaTeX that is failing to support the shadings properly. I don't know the current situation but this is a known problem. – percusse Dec 28 '13 at 1:00
• @percusse for some reason I have no problem with 2.10. – someonr Dec 28 '13 at 1:01
• You are right, I should maybe say that XeLaTeX is not providing the correct PDF literals in some cases. I will try to find a similar question where 2.10 also fails. But also depends on he wiever. – percusse Dec 28 '13 at 1:03
• @percusse Thx for the info. Quite Evil bugs around. Looks like I can't use LuaLatex (tex.stackexchange.com/questions/28733/…) nor XeLaTex. Back to pdfLaTex ;( – someonr Dec 28 '13 at 1:11
• @JosephWright Is there any update on this? – cfr Jul 3 '15 at 20:29

I confirm that this is a regression and I can reproduce it.

PGF 3.0.0 comes with a lot of changes around shading and xelatex. These changes activate the full feature set of fadings, shadings, etc. just as pdflatex does. The fact that it works only for particular document classes is a bad surprise.

EDIT

I fixed the bug in the developer version of PGF; will become part of the next stable.

The following is probably better suited for a ticketing system, but since I started looking into the bug, I can document my steps here as well. Perhaps some expert on low-level drivers jumps onto it.

I found that it is caused by the code resulting from \pgfsys@vertshading, more specifically, the resulting PDF code segment

7 0 obj
<<
/Matrix [1 0 0 1 72 -72]
/Subtype /Form
/Length 15
/Resources 8 0 R
/FormType 1
/Type /XObject
/BBox [-72 72 28 172]
>>
stream
0 G 0 g /Sh sh
endstream


PGF 2.10 produced a further negative transformation (the part with 1 0 0 1.. cm).

<<
/Matrix [1 0 0 1 72 -72]
/Subtype /Form
/Length 37
/Resources 7 0 R
/FormType 1
/Type /XObject
/BBox [-72 72 28 172]
>>
stream
0 G 0 g q 1 0 0 1 -72 72 cm /Sh sh Q
endstream


I have patched the resulting pdf manually; if I introduce these negative shifts, the result is correct. Alternatively, If I patch /Matrix and /BBox to

7 0 obj
<<
/Matrix [1 0 0 1 0 0]
/Subtype /Form
/Length 15
/Resources 8 0 R
/FormType 1
/Type /XObject
/BBox [0 0 100 100]
>>
stream
0 G 0 g /Sh sh
endstream


it works as well. Interestingly, the value 100 100 is available as size in \pgfsys@vertshading; it is the bounding box in pgf's coordinates somewhere deep down in the system. I experimented a while but got no grip on the problem; I do not know how the "72" enters here.

Note that pdflatex generates the 0 0 100 100 as bounding box with identity matrix (the correct one). Using the article class and xelatex also produces this value.

Perhaps some guru on device driver development can shed some light on it; I bet it is related to something deep in the latex-specific pgfutil stuff (pgfutil-latex.def).