Estou lutando para fazer o seguinte código funcionar:
\documentclass{minimal}
\usepackage{tikz}
\usetikzlibrary{calc}
\begin{document}
\begin{tikzpicture}
\foreach \point in {(0,0),(0,2),(2,0),(2,2)} {
\begin{scope}[shift={\point}]
\fill (0,0) circle (0.1) ;
\end{scope}
}
\end{tikzpicture}
\end{document}
O registro contém
Erro do pacote tikz: não é possível analisar esta coordenada.
Veja a documentação do pacote tikz para explicação. Digite H para ajuda imediata. ...
l.11 } Esta mensagem de erro foi gerada por um comando \errmessage, portanto não posso dar nenhuma ajuda explícita. Finja que você é Hercule Poirot: examine todas as pistas e deduza a verdade por ordem e método.Caractere ausente: não há (na fonte nullfont!
Caractere ausente: não há 0 na fonte nullfont!
Caractere ausente: não há , na fonte nullfont!
Caractere ausente: não há 0 na fonte nullfont!
Caractere ausente: não há ) na fonte nullfont!
Existe uma maneira de usar essas coordenadas diretamente ou devo recorrer ao estilo X/Y?
Atualização: (para abordar a afirmação de que () resolve o problema). Atualizei totalmente a instalação do Miktex através do console. Porém, as seguintes linhas (diretamente ligadas ao uso de shift + ()) ainda aparecem:
Arquivo: epstopdf-sys.cfg 2021/03/18 v2.0 Configuração do epstopdf para MiKTeX))
Caractere ausente: não há ) na fonte nullfont!
Caractere ausente: não há ) na fonte nullfont!
Caractere ausente: não há ) na fonte nullfont!
Caractere ausente: não há ) na fonte nullfont!
[1]
Exatamente uma chave para cada coordenada da lista (verificada com um número diferente de pontos).
Responder1
Quando o analisador TikZ (que também é usado para analisar as shiftcoordenadas) encontra algo que não entende, geralmente tenta expandir o que está à sua frente.
Isso é por que
\fill \point circle (0.1);
funciona sem problemas.
Caso o usuário escreva a sintaxe errada, o TikZ possui um fail-safe, pois decrementa um contador interno e só tenta a tática de expansão até que esse contador chegue a 0. Esse contador geralmente começa em 100 e é decrementado em 1 ou 10 dependendo do caso.
Em certos locais, este contador é reiniciado para 100, por exemplo, no início de um caminho (é por isso que
\fill[shift=\point] (0,0) circle (0.1) ;
funciona) ou quando o analisador encontra com sucesso uma especificação de caminho válida. Istonão é redefinidono início da imagem ou no início de um escopo. E como ainda é o padrão e inicializado com 0 nesse ponto, a análise gera um erro.
Usar shift=(\point)funciona porque há outra expansão de tudo acontecendo, mas isso levará a avisos de
Missing character: There is no ) in font nullfont!
Isso ocorre porque agora ele tenta analisar
((0,0))e o que acontece é que o analisador reconhece
(0comoxvalor para a coordenada e o segundo 0como osimvalor. Mas deixa o último )no fluxo de entrada do TeX, semelhante como se você tivesse feito:
\path;
Foo
\path;
Agora, por que não (0gera nenhum erro? Tal como acontece com muitas coisas no PGF/TikZ, isso será enviado ao PGFmath e avaliado… e o PGFmath não tem problemas com isso. Tentar
\pgfmathparse{(((((1}\pgfmathresult
ou mesmo
\pgfmathparse{1))))}\pgfmathresult
Em vez de usar \expandede \noexpandconforme sugerido nos comentários, recomendo usar o.expandedmanipulador de chavesque instruirá o PGFkeys a expandir o valor antes de fornecê-lo à chave.
(Ou corrigimos o scopeambiente ou a shiftchave ou apenas redefinimos manualmente o contador, mas usar o manipulador de chave sempre funciona muito bem em outros lugares quando o TikZ não faz nenhuma expansão por conta própria.)
Código
\documentclass[tikz]{standalone}
\begin{document}
\begin{tikzpicture}
\foreach \point in {(0,0),(0,2),(2,0),(2,2)} {
\begin{scope}[shift/.expanded=\point]
\fill (0,0) circle[radius=.1];
\end{scope}
}
\end{tikzpicture}
\end{document}