XeLaTeX/especiais gráficos

Question

Primeiramente, respondendo à questão geral, as pdf:especiais estão descritas nos manuais dvipdfme dvipdfmx. Para este último, você deseja dvipdfmx-special.pdf, que eu acesso usando texdoc -l dvipdfmxcomo entrada nº 2 na lista de arquivos.

As x:versões não são (que eu saiba) documentadas - lendoa fonte, estes se originam de xdvipdfmx, mas como dvipdfmxe xdvipdfmxagora foram mesclados, isso não é importante. A chave é que eles funcionam da mesma forma que pdf:...as versões documentadas para dvipdfm, e ainda mais importante, sabemos que eles têm sido usados dessa forma há muitos anos. Portanto, embora tenham começado como específicos do XeTeX, hoje podemos misturar pdf:e x:fazer especiais dvipdfmxcomo você viu. (Vale a pena notar que eles são implementados de forma independente, portanto as interações devem ser testadas em geral.) Há algumas informações na lista XeTeX sobre alguns dos especiais, mais obviamentehttps://tug.org/pipermail/xetex/2004-May/000220.html.

O par btrans/ etransforma um escopo para a matriz de transformação. (Na l3backendversão do mesmo código, usamos x:gsave/ x:grestore, que salva/restaura todo o estado gráfico - o que permite algum compartilhamento de código com outras operações.) O par btrans/ etransé útil quando se deseja um explícitoemparelhadoconjunto de promoções; contraste com x:rotateou similar, que é uma operação 'one shot' tão mais adequada para 'construir'dentro deum par externo x:gsave/ x:grestore. (No l3backendcódigo usamos ambos por esse motivo, pois correspondem às APIs de outros back-ends.)

Usar x:scale, etc., deveria ser equivalente a usar pdf:brans scale, já que ambos permitem que o back-end 'rastreie' as transformações. Isso aparece, por exemplo, quando você tem hiperlinks aninhados dentro de tal espaço: uma chamada bruta para uma cmoperação PDF significará que eles ficarão confusos. Conforme observado acima, a principal diferença entre os dois é que a x:versão pode ser 'autônoma' dentro de uma série de transformações, ao passo que pdf:btransrequer pdf:etransoperações de correspondência.

Na pergunta 'por que dimensionar duas vezes', é porque você tem uma imagem dentro de uma caixa dimensionada. No XeTeX, não dimensionamos as imagens 'diretamente' (no nível do especial para incluir a imagem), mas sim inserimos a imagem dentro de uma caixa que é então dimensionada (isso é compartilhado com o pdfTeX, veja abaixo). Dessa forma, quando você inclui a imagem, ela é definida em escala completa (sem escala como argumento opcional para \includegraphics) e isso aparece como escala não operacional. Você então escala umem torno dacaixa, que é feita em 'pontos grandes', daí os valores um pouco estranhos.

(Com o XeTeX, poderíamos escolher dimensionar a imagem no ponto de inclusão, mas isso não funciona, dvipdfmxportanto, para compartilhar o código, evitamos isso. Essencialmente, o código de back-end mais recente tende a seguir o pdfTeX e o primitivo que ele usa para imagem a inclusão não oferece dimensionamento para todos os tipos de imagem, portanto, a melhor rota de código compartilhado é dimensionar uma caixa contendo.)

Finalmente, voltamo-nos para a caixa delimitadora. Na dvipdfmxrota, temos que usar o programa auxiliar extractbbpara obter a caixa delimitadora. Porém, no XeTeX, temos uma primitiva de imagem \XeTeXpdffile, que pode ler o PDF diretamente. É necessário um argumento de palavra-chave para dizerqualcaixa para ler: isso é abordado em texdoc xetex. Você verá que esta primitiva pode dimensionar a imagem, em contraste com using \special{pdf:image ...}, mas como observado acima, esse recurso não é usado. Se alguém escolhesse dimensionar/girar a imagem no \XeTeXpdffilenível, isso apareceria no matrix: Não tenho certeza, neste caso, de quão bem isso interage com os hiperlinks.

A inserção de uma imagem PDF é cortada ao redor da caixa delimitadora desejada, o que significa que você não precisa se preocupar com as unidades. Se você quiser saber o tamanho da imagem resultante, meça a caixa TeX em que ela vai parar, por exemplo

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

pois a imagem é sempre inserida no ponto de referência da caixa sem profundidade. Você verá que xetex.defusamos isso para assumir que as coordenadas inferiores esquerdas são sempre (0,0)(cf. dvips, onde a vida é mais 'interessante').

Para gráficos bitmap, a primitiva \XeTeXpicfileestá disponível e pode inserir a imagem sem a necessidade de uma caixa delimitadora antecipadamente. Como acabamos de ver \XeTeXpdffile, como essas primitivas estão cientes da caixa delimitadora das imagens, elas as inserem no TeX com um tamanho 'real', para que possamos medir os resultados usando uma caixa TeX em todos os casos.

Answer 1