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

Question

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}
\usetikzlibrary{shadings}
\begin{document}
\tikz \draw[top color=red] (0,0) rectangle (2,1);
\end{document}

Output

Expected Output

Question

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

Answer 1

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 candidate can be downloaded at http://pgf.sourceforge.net/

---

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