XeLaTeX/especiales de gráficos

Question

Primero, tomando la pregunta general, las pdf:especiales se describen en los manuales dvipdfmy dvipdfmx. Para este último, desea dvipdfmx-special.pdf, al que accedo usando texdoc -l dvipdfmxla entrada número 2 en la lista de archivos.

Las x:versiones no están (que yo sepa) documentadas - lecturala fuente, estos se originan en xdvipdfmx, pero como dvipdfmxy xdvipdfmxahora están fusionados, esto no es importante. La clave es que funcionan igual que pdf:...las versiones documentadas para dvipdfm, y lo que es más importante, sabemos que se han utilizado de esa manera durante muchos años. Entonces, aunque comenzaron como específicos de XeTeX, hoy podemos mezclarlos pdf:con x:especiales dvipdfmxcomo has visto. (Vale la pena señalar que se implementan de forma independiente, por lo que, en general, se deben probar las interacciones). Hay información en la lista de XeTeX sobre algunas de las ofertas especiales, la más obvia.https://tug.org/pipermail/xetex/2004-May/000220.html.

El par btrans/ etransforma un ámbito para la matriz de transformación. (En la l3backendversión del mismo código, usamos x:gsave/ x:grestore, que guarda/restaura todo el estado de los gráficos, lo que permite compartir código con otras operaciones). El par btrans/ etranses útil cuando se desea una conexión explícitaemparejadoconjunto de especiales; contraste con x:rotateo similar, que es una operación de "una sola vez", por lo que es más adecuada para "construir"dentroun exterior x:gsave/ x:grestorepar. (En el l3backendcódigo utilizamos ambos por este motivo, ya que coinciden con las API de otros backends).

Usar x:scale, etc., debería ser equivalente a usar pdf:brans scale, ya que ambos permiten que el backend "rastree" las transformaciones. Esto aparece, por ejemplo, cuando tiene hipervínculos anidados dentro de dicho espacio: una llamada sin formato a una cmoperación PDF significará que estos se estropearán. Como se señaló anteriormente, la principal diferencia entre los dos es que la x:versión puede ser "independiente" dentro de una serie de transformaciones, mientras que pdf:btransrequiere pdf:etransoperaciones de coincidencia.

En la pregunta "¿por qué escalar dos veces?", es porque tienes una imagen dentro de un cuadro escalado. En XeTeX, no escalamos las imágenes 'directamente' (en el nivel especial para incluir la imagen), sino que insertamos la imagen dentro de un cuadro que luego se escala (esto se comparte con pdfTeX, ver más abajo). Como tal, cuando incluye la imagen, se establece a escala completa (sin escala como argumento opcional para \includegraphics), y eso se muestra como la escala no operativa. Luego escalas uncircundantecuadro, que se hace en 'puntos grandes', de ahí los valores ligeramente extraños.

(Con XeTeX, podríamos optar por escalar la imagen en el punto de inclusión, pero eso no funciona, por dvipdfmxlo que lo evitamos para compartir código. Esencialmente, el código backend más nuevo tiende a seguir a pdfTeX y la primitiva que usa para la imagen). La inclusión no ofrece escala para todos los tipos de imágenes, por lo que la mejor ruta de código compartido es escalar un cuadro contenedor).

Finalmente, pasamos al cuadro delimitador. En la dvipdfmxruta, tenemos que usar el programa auxiliar extractbbpara obtener el cuadro delimitador. Sin embargo, en XeTeX tenemos una primitiva de imagen \XeTeXpdffileque puede leer el PDF directamente. Se necesita un argumento de palabra clave para decircualcuadro para leer: esto está cubierto en texdoc xetex. Verá allí que esta primitiva puede escalar la imagen, a diferencia de usar \special{pdf:image ...}, pero como se señaló anteriormente, esa característica no se usa. Si uno elige escalar/rotar la imagen en el \XeTeXpdffilenivel, esto aparecería en matrix: En este caso, no estoy seguro de qué tan bien interactúa con los hipervínculos.

Al insertar una imagen PDF, se recorta alrededor del cuadro delimitador deseado, lo que significa que no necesita preocuparse por las unidades. Si quieres saber el tamaño de la imagen resultante, mides el cuadro TeX en el que termina, por ejemplo

\setbox0=\hbox{\XeTeXpdffile "foo.pdf" media }%
\edef\pictureheight{\the\ht0 }%
\edef\picturewidth{\the\wd0 }%

ya que la imagen siempre se inserta en el punto de referencia del cuadro sin profundidad. Verás que xetex.defusamos eso para asumir que las coordenadas inferiores izquierdas son siempre (0,0)(cf. dvips, donde la vida es más "interesante").

Para gráficos de mapa de bits, la primitiva \XeTeXpicfileestá disponible y puede insertar la imagen sin necesidad de un cuadro delimitador por adelantado. Como acabamos de ver con \XeTeXpdffile, como estas primitivas conocen el cuadro delimitador de las imágenes, las insertan en TeX con un tamaño "real", por lo que podemos medir los resultados usando un cuadro TeX en todos los casos.

Answer 1