Estoy luchando para que el siguiente código funcione:
\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}
El registro contiene
Error del paquete tikz: no se puede analizar esta coordenada.
Consulte la documentación del paquete tikz para obtener una explicación. Escriba H para obtener ayuda inmediata. ...
l.11 } Este mensaje de error fue generado por un comando \errmessage, por lo que no puedo brindar ninguna ayuda explícita. Imagina que eres Hércules Poirot: examina todas las pistas y deduce la verdad por orden y método.Carácter faltante: no hay (en fuente nullfont!
Carácter faltante: ¡No hay 0 en la fuente nullfont!
Carácter faltante: ¡No hay ningún , en fuente nullfont!
Carácter faltante: ¡No hay 0 en la fuente nullfont!
Carácter faltante: ¡No hay ) en la fuente nullfont!
¿Hay alguna forma de utilizar estas coordenadas directamente o debería recurrir al estilo X/Y?
Actualización: (para abordar la afirmación de que () resuelve el problema). He actualizado completamente la instalación de Miktex a través de consola. Sin embargo, las siguientes líneas (directamente relacionadas con el uso de shift + ()) todavía aparecen:
Archivo: epstopdf-sys.cfg 2021/03/18 v2.0 Configuración de epstopdf para MiKTeX))
Carácter faltante: ¡No hay ) en la fuente nullfont!
Carácter faltante: ¡No hay ) en la fuente nullfont!
Carácter faltante: ¡No hay ) en la fuente nullfont!
Carácter faltante: ¡No hay ) en la fuente nullfont!
[1]
Exactamente una llave para cada coordenada de la lista (comprobada con un número diferente de puntos).
Respuesta1
Cuando el analizador TikZ (que también se utiliza para analizar shiftcoordenadas) encuentra algo que no comprende, normalmente intenta expandir lo que tiene delante.
Esta es la razón por
\fill \point circle (0.1);
funciona sin problemas.
En caso de que el usuario escriba una sintaxis incorrecta, TikZ tiene un mecanismo de seguridad, ya que disminuye un contador interno y solo intenta la táctica de expansión hasta que este contador llega a 0. Este contador generalmente comienza en 100 y se reduce en 1 o 10 según el caso.
En ciertos lugares, este contador se pone a 100, por ejemplo al inicio de un camino (razón por la cual
\fill[shift=\point] (0,0) circle (0.1) ;
funciona) o cuando el analizador encuentra exitosamente una especificación de ruta válida. Élno se reiniciaal comienzo de la imagen o al comienzo de un alcance. Y dado que sigue siendo el valor predeterminado y está inicializado, con 0 en ese punto, el análisis arroja un error.
El uso shift=(\point)funciona porque hay otra expansión de todo lo que sucede, pero generará advertencias de
Missing character: There is no ) in font nullfont!
Esto se debe a que ahora intenta analizar
((0,0))y lo que sucede es que el analizador reconoce
(0como elXvalor para la coordenada y el segundo 0comoyvalor. Pero deja lo último )en el flujo de entrada de TeX, similar a como lo hubiera hecho:
\path;
Foo
\path;
Ahora bien, ¿por qué no (0genera ningún error? Como ocurre con muchas cosas en PGF/TikZ, esto se enviará a PGFmath y se evaluará... y PGFmath no tiene ningún problema con ello. Intentar
\pgfmathparse{(((((1}\pgfmathresult
o incluso
\pgfmathparse{1))))}\pgfmathresult
En lugar de usar \expandedy \noexpandcomo se sugiere en los comentarios, recomendaría usar el.expandedmanejador de claveslo que indicará a PGFkeys que expanda el valor antes de asignarlo a la clave.
(O parcheamos el scopeentorno o la shiftclave o simplemente reiniciamos manualmente el contador, pero usar el controlador de claves siempre funciona muy bien en otros lugares cuando TikZ no se expande por sí solo).
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}