XeLaTeX / Grafik-Specials

Question

Wenn ich den folgenden Code unter XeLaTeX verwende

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

Die XDV-Datei enthält die folgenden Opcodes:

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

Wo finde ich eine Beschreibung der Specials mit Namespace xund pdf?

Ich denke, das pdf:btransbehält den aktuellen Grafikstatus im Speicher und startet einen neuen. x:scaleIst das eine Besonderheit für XeLaTeX?

Warum gibt es zuerst eine Skala von 0,99667 (erhalten von der \resizebox) und dann eine andere mit einer Skala von 1,0?

In dem pdf:imageSpecial sehe ich ein matrixSchlüsselwort, das mich an die PostScript-Grafikstatusmatrix erinnert. Warum wird diese Matrix nicht für die Skalierung verwendet? Ich habe in meinem Dokument nachgesehen und alle Zahlen hatten dieselbe "einheitliche" Matrix. Unter welchen Umständen würde diese Matrix anders sein?

Und letzte Frage: Ich sehe das im Gegensatz zu PostScript-Specials wie

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

pdf:imageWenn der Begrenzungsrahmen explizit ist, gibt es keinen Begrenzungsrahmen, und die Zuschneidebox muss aus der PDF-Datei extrahiert werden. Kennen Sie ein Werkzeug, mit dem Sie die Cropbox sicher extrahieren können? Ich habe getestet pdfinfound es wurde der folgende Code erzeugt:

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

Ist die "Seitengröße" tatsächlich die Cropbox? Und sind "pts" PostScript-Punkte (= bp) oder TeX-Punkte (= pt)?

Answer 1

Zunächst werden unter Berücksichtigung der allgemeinen Frage die pdf:Besonderheiten in den Handbüchern dvipdfmund beschrieben dvipdfmx. Für letzteres möchten Sie dvipdfmx-special.pdf, auf das ich texdoc -l dvipdfmxals Eintrag Nr. 2 in der Liste der Dateien zugreife .

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

Das btrans/ etransPaar bildet einen Bereich für die Transformationsmatrix. (In der l3backendVersion desselben Codes verwenden wir x:gsave/ x:grestore, wodurch der gesamte Grafikstatus gespeichert / wiederhergestellt wird. Dies ermöglicht die gemeinsame Nutzung von Code mit anderen Vorgängen.) Das btrans/ etranspair ist nützlich, wenn ein explizit gepaarter Satz von Specials gewünscht wird. Kontrast zu x:rotateoder ähnlich, was eine "One-Shot" -Operation ist, die sich am besten zum "Aufbauen" innerhalb eines Äußeren x:gsave/ x:grestorePaares eignet . (Im l3backendCode verwenden wir beide aus diesem Grund, da sie mit den APIs anderer Backends übereinstimmen.)

Verwenden x:scaleusw. sollte meiner Meinung nach gleichbedeutend mit Verwenden sein pdf:brans scale, da beide die Backend-Transformationen "verfolgen" lassen. Dies wird beispielsweise angezeigt, wenn in einem solchen Bereich Hyperlinks verschachtelt sind: Ein roher Aufruf eines PDF- cmVorgangs bedeutet, dass diese durcheinander gebracht werden. 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:btransÜbereinstimmungsoperationen pdf:etranserforderlich sind.

Bei der Frage "Warum zweimal skalieren" haben Sie ein Bild in einem skalierten Feld. In XeTeX skalieren wir Bilder nicht "direkt" (auf der Ebene des Specials, um das Bild einzuschließen), sondern fügen das Bild in ein Feld ein, das dann skaliert wird (dies wird mit pdfTeX geteilt, siehe unten). Wenn Sie das Bild einschließen, wird es auf den vollen Maßstab eingestellt (keine Skalierung als optionales Argument \includegraphics), und dies wird als No-Op-Skalierung angezeigt. Sie skalieren dann eine umgebende Box, was in "großen Punkten" erfolgt, daher die etwas seltsamen Werte.

(Mit XeTeX können wir das Bild am Einschlusspunkt skalieren, aber das funktioniert nicht dvipdfmx, um Code freizugeben, den wir vermeiden. Im Wesentlichen folgt neuerer Backend-Code in der Regel pdfTeX und dem für das Bild verwendeten Grundelement Die Aufnahme bietet nicht für alle Bildtypen eine Skalierung. Die beste Route für gemeinsam genutzten Code ist daher die Skalierung eines enthaltenen Felds.)

Schließlich wenden wir uns dem Begrenzungsrahmen zu. In der dvipdfmxRoute müssen wir das Hilfsprogramm verwenden extractbb, um den Begrenzungsrahmen zu erhalten. In XeTeX haben wir jedoch ein Bildprimitiv \XeTeXpdffile, das das PDF direkt lesen kann. Es ist ein Schlüsselwortargument erforderlich, um anzugeben, welches Feld gelesen werden soll: Dies wird behandelt texdoc xetex. Sie werden dort sehen, dass dieses Grundelement im Gegensatz zur Verwendung eine Bildskalierung durchführen kann \special{pdf:image ...}, aber wie oben erwähnt, wird diese Funktion nicht verwendet. Wenn man das Bild auf der \XeTeXpdffileEbene skalieren / drehen möchte, wird dies in matrixfolgendem angezeigt: Ich bin mir in diesem Fall nicht sicher, wie gut das mit Hyperlinks interagiert.

Durch das Einfügen eines PDF-Bildes wird der gewünschte Begrenzungsrahmen 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 die TeX-Box, in der es endet

\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 sehen xetex.def, dass wir dies verwenden, um anzunehmen, dass die Koordinaten unten links immer sind (0,0)(vgl dvips. Wo das Leben „interessanter“ ist).

Für Bitmap-Grafiken ist das Grundelement \XeTeXpicfileverfügbar und kann das Bild einfügen, ohne dass zuvor ein Begrenzungsrahmen erforderlich ist. Wie wir gerade gesehen haben \XeTeXpdffile, fügen diese Grundelemente, da sie den Begrenzungsrahmen der Bilder kennen, diese mit einer "echten" Größe in TeX ein, sodass wir die Ergebnisse in allen Fällen mit einem TeX-Kästchen messen können.