TikZ 3.0.0 (lanzamiento) produce sombras extrañas si se usa con XeLaTeX y de forma independiente

TikZ 3.0.0 (lanzamiento) produce sombras extrañas si se usa con XeLaTeX y de forma independiente

Me gustaría usar sombreados en mis gráficos TikZ junto con el standalonepaquete y XeLaTeX, pero por alguna razón no funciona si lo intento con la nueva versión 3.0.0 (descarga aquí). Cualquier otra combinación que probé funciona para mí (use, por ejemplo, articleclase/ pdflatex/ lualatex/ TikZ2.10).

(Estoy usando un TeX Live 2013 completamente actualizado).

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}

Producción

Producción

Rendimiento esperado

Rendimiento esperado

Pregunta

¿Cómo puedo evitar el problema y qué paquete/clase lo está causando?

Respuesta1

Confirmo que esto es una regresión y puedo reproducirla.

PGF 3.0.0 viene con muchos cambios en torno al sombreado y xelatex. Estos cambios activan el conjunto completo de funciones de desvanecimientos, sombras, etc. tal como lo hace pdflatex. El hecho de que funcione sólo para determinadas clases de documentos es una mala sorpresa.


EDITAR

Solucioné el error en la versión para desarrolladores de PGF; pasará a formar parte del próximo establo.

El candidato se puede descargar enhttp://pgf.sourceforge.net/


Lo siguiente probablemente sea más adecuado para un sistema de emisión de tickets, pero desde que comencé a investigar el error, también puedo documentar mis pasos aquí. Quizás algún experto en conductores de bajo nivel se dé cuenta.

Descubrí que es causado por el código resultante \pgfsys@vertshading, más específicamente, el segmento de código PDF resultante.

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 produjo una transformación negativa adicional (la parte con 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 

He parcheado el pdf resultante manualmente; si introduzco estos cambios negativos, el resultado es correcto. Alternativamente, si parcheo /Matrixy/BBox

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 

también funciona. Curiosamente, el valor 100 100está disponible como tamaño en \pgfsys@vertshading; es el cuadro delimitador en las coordenadas de pgf en algún lugar profundo del sistema. Experimenté por un tiempo pero no pude resolver el problema; No sé como entra aquí el "72".

Tenga en cuenta que pdflatex genera el 0 0 100 100cuadro delimitador con matriz de identidad (la correcta). Usando la articleclase y xelatextambién produce este valor.

Quizás algún gurú del desarrollo de controladores de dispositivos pueda arrojar algo de luz al respecto; Apuesto a que está relacionado con algo profundo en el tema pgfutil específico del látex ( pgfutil-latex.def).

información relacionada