☰

TikZ 3.0.0 (lançamento) produz sombras estranhas se usado com XeLaTeX e autônomo

tag-icon • tag-icon tikz-pgf xetex standalone
TikZ 3.0.0 (lançamento) produz sombras estranhas se usado com XeLaTeX e autônomo

Eu gostaria de usar sombreamentos em meus gráficos TikZ junto com o standalonepacote e o XeLaTeX, mas por algum motivo ele quebra se eu tentar com a nova versão 3.0.0 (baixe aqui). Qualquer outra combinação que tentei funciona para mim (use por exemplo articleclass/ pdflatex/ lualatex/ TikZ2.10).

(Estou usando um TeX Live 2013 totalmente atualizado.)

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}

Saída

Saída

Resultado Esperado

resultado esperado

Pergunta

Como posso evitar o problema e qual pacote/classe está causando isso?

Responder1

Confirmo que se trata de uma regressão e posso reproduzi-la.

O PGF 3.0.0 vem com muitas mudanças em relação ao sombreamento e ao xelatex. Essas alterações ativam o conjunto completo de recursos de desvanecimentos, sombreamentos, etc., assim como o pdflatex faz. O fato de funcionar apenas para classes específicas de documentos é uma surpresa ruim.

EDITAR

Corrigi o bug na versão de desenvolvedor do PGF; fará parte do próximo estábulo.

O candidato pode ser baixado emhttp://pgf.sourceforge.net/

O seguinte provavelmente é mais adequado para um sistema de tickets, mas desde que comecei a investigar o bug, posso documentar minhas etapas aqui também. Talvez algum especialista em drivers de baixo nível se interesse por isso.

Descobri que isso é causado pelo código resultante \pgfsys@vertshading, mais especificamente, do 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

O PGF 2.10 produziu mais uma transformação negativa (a parte com 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

Corrigi o PDF resultante manualmente; se eu introduzir essas mudanças negativas, o resultado estará correto. Alternativamente, se eu corrigir /Matrixe/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

funciona também. Curiosamente, o valor 100 100está disponível em tamanho \pgfsys@vertshading; é a caixa delimitadora nas coordenadas do pgf em algum lugar no fundo do sistema. Experimentei um pouco, mas não consegui entender o problema; Não sei como entra o “72” aqui.

Observe que o pdflatex gera a 0 0 100 100caixa delimitadora com matriz identidade (a correta). Usar a articleclasse e xelatextambém produz esse valor.

Talvez algum guru no desenvolvimento de drivers de dispositivos possa esclarecer isso; Aposto que está relacionado a algo profundo no material pgfutil específico do látex ( pgfutil-latex.def).

informação relacionada