XeLaTeX / spéciaux graphiques

Question

Lorsque j'utilise le code suivant sous XeLaTeX

\resizebox{\textwidth}{!}{\includegraphics{foo.pdf}}

le fichier XDV contient les opcodes suivants:

PUSH
XXX "pdf:btrans"
XXX "x:scale 0.99667 0.99667"
PUSH
PUSH
PUSH
PUSH
PUSH
PUSH
XXX "pdf:btrans"
XXX "x:scale 1 1"
PUSH
PUSH
XXX "pdf:image matrix 1.0 0.0 0.0 1.0 0.0 0.0 page 0 pagebox cropbox (foo.pdf)"
POP
POP
XXX "pdf:etrans"
POP
POP
POP
POP
POP
POP
XXX "pdf:etrans"
POP

Où puis-je trouver une description des offres spéciales avec namespace xet pdf?

Je suppose que cela pdf:btransgarde l'état graphique actuel en mémoire et en démarre un nouveau, est-ce x:scaleque le spécial est spécifique à XeLaTeX?

Pourquoi y a-t-il d'abord une échelle de 0,99667 (obtenue à partir de \resizebox), puis une autre avec une échelle de 1,0?

Dans le pdf:imagespécial, je vois un matrixmot clé qui me rappelle la matrice d'état graphique PostScript, pourquoi cette matrice n'est-elle pas utilisée pour la mise à l'échelle? J'ai regardé dans mon document et toutes les figures avaient la même matrice «unitaire», dans quelles circonstances cette matrice serait-elle différente?

Et dernière question: je vois ça, contrairement aux spéciaux PostScript comme

PSfile=%0022fig1.eps%0022 llx=0 lly=0 urx=104 ury=131 rwi=1040

où le cadre de délimitation est explicite, dans le pdf:imageil n'y a pas de cadre de délimitation, et le cropbox doit être extrait du fichier PDF. Connaissez-vous un outil qui extrait le cropbox en toute sécurité? J'ai testé pdfinfoet il a produit le code suivant:

Creator:        TeX
Producer:       pdfTeX-1.40.20
CreationDate:   Mon Aug 31 13:24:48 2020 CEST
ModDate:        Mon Aug 31 13:24:48 2020 CEST
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      347 x 426 pts
Page rot:       0
File size:      11745 bytes
Optimized:      no
PDF version:    1.5

La "Taille de la page" est-elle réellement la zone de recadrage? Et sont des points PostScript "pts" (= bp) ou des points TeX (= pt)?

Answer 1

Tout d'abord, en prenant la question générale, les pdf:offres spéciales sont décrites dans les manuels dvipdfmet dvipdfmx. Pour ce dernier, vous voulez dvipdfmx-special.pdf, auquel j'accède en utilisant texdoc -l dvipdfmxcomme c'est l'entrée n ° 2 dans la liste des fichiers.

Les x:versions ne sont pas (à ma connaissance) documentées - la lecture de la source , elles proviennent de xdvipdfmx, mais depuis dvipdfmxet xdvipdfmxsont maintenant fusionnées, cela n'a pas d'importance. La clé est qu'elles fonctionnent de la même manière que les pdf:...versions documentées pour dvipdfm, et plus important encore, nous savons qu'elles sont utilisées de cette manière depuis de nombreuses années. Ainsi , bien que ceux - ci a commencé comme XeTeX spécifique, nous pouvons aujourd'hui entremêler pdf:et de x:promotion avec dvipdfmxcomme vous l' avez vu. (Il est à noter qu'ils sont implémentés indépendamment, donc les interactions doivent en général être testées.) Il y a des informations sur la liste XeTeX sur certaines des promotions, le plus évidemmenthttps://tug.org/pipermail/xetex/2004-May/000220.html.

La paire btrans/ etransforme une portée pour la matrice de transformation. (Dans la l3backendversion du même code, nous utilisons x:gsave/ x:grestore, qui enregistre / restaure l'intégralité de l'état graphique - qui permet un partage de code avec d'autres opérations.) La paire btrans/ etransest utile quand on veut un ensemble apparié explicite de spéciaux; contraste avec x:rotateou similaire, qui est une opération « one shot » donc mieux adapté à « construire » à l' intérieur d' un extérieur x:gsave/ x:grestorepaire. (Dans le l3backendcode, nous utilisons les deux pour cette raison, car ils correspondent aux API d'autres backends.)

Utiliser x:scale, etc., devrait je pense être équivalent à utiliser pdf:brans scale, car les deux laissent les transformations backend «suivre». Cela apparaît par exemple lorsque vous avez des liens hypertexte imbriqués dans un tel espace: un appel brut à une cmopération PDF signifiera que ceux-ci seront foirés. Comme indiqué ci-dessus, la principale différence entre les deux est que la x:version peut être «autonome» à l'intérieur d'une série de transformations, alors qu'elle pdf:btransnécessite des pdf:etransopérations de mise en correspondance .

Sur la question «pourquoi redimensionner deux fois», c'est parce que vous avez une image dans une boîte mise à l'échelle. Dans XeTeX, nous ne redimensionnons pas les images `` directement '' (au niveau du spécial pour inclure l'image), mais nous insérons plutôt l'image dans une boîte qui est ensuite mise à l'échelle (cela est partagé avec pdfTeX, voir ci-dessous). En tant que tel, lorsque vous incluez l'image, elle est définie à pleine échelle (pas de mise à l'échelle en tant qu'argument facultatif à \includegraphics), et cela apparaît comme la mise à l'échelle sans opération. Vous mettez ensuite à l'échelle une boîte environnante , ce qui est fait en «gros points», d'où les valeurs un peu étranges.

(Avec XeTeX, nous pourrions choisir de redimensionner l'image au point d'inclusion, mais cela ne fonctionne pas, dvipdfmxdonc pour partager du code, nous l'évitons. Essentiellement, le nouveau code backend a tendance à suivre pdfTeX, et la primitive qu'il utilise pour l'image l'inclusion n'offre pas de mise à l'échelle pour tous les types d'images, donc la meilleure route de code partagée est de mettre à l'échelle une boîte contenant.)

Enfin, nous passons à la boîte englobante. Dans l' dvipdfmxitinéraire, nous devons utiliser le programme auxiliaire extractbbpour obtenir la boîte englobante. Cependant, dans XeTeX, nous avons une primitive d'image \XeTeXpdffile, qui peut lire le PDF directement. Il faut un argument mot-clé pour dire quelle case lire: ceci est couvert dans texdoc xetex. Vous y verrez que cette primitive peut faire la mise à l'échelle de l'image, contrairement à l'utilisation \special{pdf:image ...}, mais comme indiqué ci-dessus, cette fonctionnalité n'est pas utilisée. Si l'on choisissait de redimensionner / faire pivoter l'image au \XeTeXpdffileniveau, cela apparaîtrait dans le matrix: Je ne suis pas sûr dans ce cas de savoir si cela interagit avec les hyperliens.

L'insertion d'une image PDF rogne autour du cadre de sélection souhaité, ce qui signifie que vous n'avez pas à vous soucier des unités. Si vous voulez connaître la taille de l'image résultante, vous mesurez la boîte TeX dans laquelle elle se termine, par exemple

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

car l'image est toujours insérée au point de référence de la boîte sans profondeur. Vous verrez dans xetex.defnous utilisons cela pour supposer que les coordonnées en bas à gauche sont toujours (0,0)(cf. dvips, là où la vie est plus «intéressante»).

Pour les graphiques bitmap, la primitive \XeTeXpicfileest disponible et peut insérer l'image sans avoir besoin d'un cadre de délimitation à l'avance. Comme nous venons de le voir \XeTeXpdffile, comme ces primitives sont conscientes de la boîte englobante des images, elles les insèrent dans TeX avec une taille `` réelle '', afin que nous puissions mesurer les résultats en utilisant une boîte TeX dans tous les cas.