XeLaTeX/Grafik-Spezialitäten

Question

Zunächst zur allgemeinen Frage: Die Besonderheiten sind in den Handbüchern und pdf:beschrieben . Für Letzteres benötigen Sie , auf das ich über Eintrag Nr. 2 in der Dateiliste zugreife .dvipdfmdvipdfmxdvipdfmx-special.pdftexdoc -l dvipdfmx

Die x:Versionen sind (soweit ich weiß) nicht dokumentiert - Lesendie Quelle, diese stammen aus xdvipdfmx, aber da dvipdfmxund xdvipdfmxjetzt zusammengeführt wurden, ist dies unwichtig. Der Schlüssel ist, dass sie genauso funktionieren wie pdf:...die für dokumentierten Versionen dvipdfm, und was noch wichtiger ist: Wir wissen, dass sie seit vielen Jahren auf diese Weise verwendet werden. Obwohl diese also als XeTeX-spezifisch begannen, können wir heute pdf:und x:Specials mit mischen dvipdfmx, wie Sie gesehen haben. (Es ist erwähnenswert, dass sie unabhängig implementiert werden, daher sollten Interaktionen im Allgemeinen getestet werden.) Es gibt einige Informationen auf der XeTeX-Liste zu einigen der Specials, am offensichtlichstenhttps://tug.org/pipermail/xetex/2004-May/000220.html.

Das btrans/ etrans-Paar bildet einen Bereich für die Transformationsmatrix. (In der l3backendVersion desselben Codes verwenden wir x:gsave/ x:grestore, das den gesamten Grafikzustand speichert/wiederherstellt - das ermöglicht eine gewisse Code-Freigabe mit anderen Operationen.) Das btrans/ etrans-Paar ist nützlich, wenn man eine explizitegepaartReihe von Specials; im Gegensatz zu x:rotateoder ähnlich, was eine „One-Shot“-Operation ist und sich daher am besten zum „Aufbauen“ eignet.innerhalbein äußeres x:gsave/ x:grestore-Paar. (Im l3backendCode verwenden wir aus diesem Grund beide, da sie mit den APIs anderer Backends übereinstimmen.)

Die Verwendung von x:scaleusw. sollte meiner Meinung nach der Verwendung von entsprechen pdf:brans scale, da beide das Backend Transformationen „verfolgen“ lassen. Dies zeigt sich beispielsweise, wenn Sie Hyperlinks in einem solchen Bereich verschachtelt haben: Ein einfacher Aufruf einer PDF- cmOperation führt dazu, dass diese durcheinander geraten. Wie oben erwähnt, besteht der Hauptunterschied zwischen den beiden darin, dass die x:Version innerhalb einer Reihe von Transformationen „eigenständig“ sein kann, während pdf:btranspassende pdf:etransOperationen erforderlich sind.

Zur Frage „Warum zweimal skalieren?“: Das liegt daran, dass Sie ein Bild in einer skalierten Box haben. In XeTeX skalieren wir Bilder nicht „direkt“ (auf der Ebene des speziellen Befehls zum Einbinden des Bilds), sondern wir fügen das Bild in eine Box ein, die dann skaliert wird (dies wird mit pdfTeX geteilt, siehe unten). Wenn Sie das Bild also einbinden, wird es auf den vollen Maßstab eingestellt (keine Skalierung als optionales Argument für \includegraphics), und das wird als No-Op-Skalierung angezeigt. Sie skalieren dann einUmgebungBox, die in „Big Points“ erfolgt, daher die etwas seltsamen Werte.

(Bei XeTeX könnten wir das Bild am Einbindungspunkt skalieren, aber das funktioniert nicht, also dvipdfmxvermeiden wir es, um Code gemeinsam zu nutzen. Neuerer Backend-Code tendiert im Wesentlichen dazu, pdfTeX zu folgen, und das Primitiv, das es für die Bildeinbindung verwendet, bietet keine Skalierung für alle Bildtypen, also ist die beste Methode für gemeinsam genutzten Code die Skalierung einer enthaltenden Box.)

Zum Schluss wenden wir uns dem Begrenzungsrahmen zu. Im dvipdfmxPfad müssen wir das Hilfsprogramm verwenden, extractbbum den Begrenzungsrahmen zu erhalten. In XeTeX haben wir jedoch ein Bildprimitiv \XeTeXpdffile, das das PDF direkt lesen kann. Es benötigt ein Schlüsselwortargument, um zu sagenwelcheFeld mit folgendem Inhalt: Dies wird in behandelt texdoc xetex. Sie werden dort sehen, dass dieses Primitiv im Gegensatz zur Verwendung von Bilder skalieren kann \special{pdf:image ...}, aber wie oben erwähnt, wird diese Funktion nicht verwendet. Wenn man sich dafür entscheidet, das Bild auf der Ebene zu skalieren/drehen \XeTeXpdffile, würde dies in angezeigt matrix: Ich bin mir in diesem Fall nicht sicher, wie gut das mit Hyperlinks interagiert.

Beim Einfügen eines PDF-Bildes wird es um den gewünschten Begrenzungsrahmen herum zugeschnitten, sodass Sie sich keine Gedanken über die Einheiten machen müssen. Wenn Sie die Größe des resultierenden Bildes wissen möchten, messen Sie beispielsweise den TeX-Rahmen, in dem es landet

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

da das Bild immer am Referenzpunkt der Box ohne Tiefe eingefügt wird. Sie werden in sehen, dass xetex.defwir dies verwenden, um anzunehmen, dass die unteren linken Koordinaten immer sind (0,0)(vgl. dvips, wo das Leben „interessanter“ ist).

Für Bitmap-Grafiken ist das Primitiv \XeTeXpicfileverfügbar und kann das Bild einfügen, ohne dass vorher ein Begrenzungsrahmen erforderlich ist. Wie wir gerade bei gesehen haben \XeTeXpdffile, fügen diese Primitiven die Bilder in TeX mit einer „echten“ Größe ein, da sie den Begrenzungsrahmen der Bilder kennen. Daher können wir die Ergebnisse in allen Fällen mithilfe eines TeX-Rahmens messen.

Answer 1