
XeLaTeXで次のコードを使用すると
\resizebox{\textwidth}{!}{\includegraphics{foo.pdf}}
XDV ファイルには次のオペコードが含まれています。
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
x
名前空間とを使用したスペシャルの説明はどこにありますかpdf
?
pdf:btrans
現在のグラフィック状態をメモリに保持して新しい状態を開始すると思いますが、これはx:scale
XeLaTeX に固有の特別な機能ですか?
なぜ最初に0.99667スケール( から得られる\resizebox
)があり、次にもう一つ1.0スケールですか?
スペシャルで、 PostScript グラフィック状態マトリックスを思い出させるキーワードがpdf:image
表示されましたがmatrix
、このマトリックスがスケーリングに使用されないのはなぜですか? ドキュメントを確認したところ、すべての図に同じ「ユニタリ」マトリックスがありましたが、どのような状況でこのマトリックスが異なるのでしょうか?
そして最後の質問です。PostScriptの特殊文字とは対照的に、
PSfile=%0022fig1.eps%0022 llx=0 lly=0 urx=104 ury=131 rwi=1040
境界ボックスが明示されているが、 にはpdf:image
境界ボックスがないため、クロップボックスを PDF ファイルから抽出する必要があります。クロップボックスを安全に抽出するツールをご存知ですか? テストしたpdfinfo
ところ、次のコードが生成されました。
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
「ページ サイズ」は実際にはクロップ ボックスですか? また、「pts」は PostScript ポイント (= bp) ですか、それとも TeX ポイント (= pt) ですか?
答え1
まず、一般的な質問ですが、特別な機能はおよび のマニュアルpdf:
に記載されています。後者の場合、 が必要ですが、これはファイル リストのエントリ #2 を使用してアクセスします。dvipdfm
dvipdfmx
dvipdfmx-special.pdf
texdoc -l dvipdfmx
バージョンx:
は(私の知る限り)文書化されていない - 読む起源これらは に由来しますxdvipdfmx
が、dvipdfmx
と はxdvipdfmx
現在統合されているため、これは重要ではありません。重要なのは、pdf:...
で文書化されたバージョンと同じように動作することdvipdfm
であり、さらに重要なことは、これらが長年にわたってそのように使用されてきたことがわかっていることです。したがって、これらは XeTeX 固有のものとして始まりましたが、今日では、ご覧のとおり、 と の特殊関数をpdf:
と混在させることができます。(これらは独立して実装されているため、相互作用は一般にテストする必要があることに注意してください。) XeTeX リストには、最も明らかな特殊関数のいくつかに関する情報があります。x:
dvipdfmx
https://tug.org/pipermail/xetex/2004-May/000220.html。
/ペアは変換行列のスコープを形成します。(同じコードのバージョンでは、グラフィックス状態全体を保存/復元する/btrans
を使用します。これにより、他の操作とのコード共有が可能になります。) /ペアは、明示的なetrans
l3backend
x:gsave
x:grestore
btrans
etrans
ペアスペシャルのセット。x:rotate
または類似のものとは対照的で、これは「ワンショット」操作であるため、「構築」に最適です。内で外側のx:gsave
/x:grestore
ペア。(l3backend
コードでは、他のバックエンドの API と一致するため、両方を使用しています。)
などを使用することx:scale
は、 を使用することと同等であると考えるべきだと思いますpdf:brans scale
。どちらもバックエンドで変換を「追跡」できるようにするためcm
です。これは、たとえば、そのようなスペース内にハイパーリンクがネストされている場合に発生します。PDF 操作をそのまま呼び出すと、これらが混乱することになります。上で述べたように、2 つの主な違いは、バージョンはx:
一連の変換内で「スタンドアロン」になることができるのに対し、 ではpdf:btrans
一致するpdf:etrans
操作が必要になることです。
「なぜ2倍に拡大縮小するのか」という質問については、拡大縮小されたボックス内に画像があるためです。XeTeXでは、画像を「直接」(画像を含めるための特別なレベルで)拡大縮小するのではなく、画像をボックス内に挿入してから拡大縮小します(これはpdfTeXと共有されています。以下を参照してください)。そのため、画像を含めると、フルスケールに設定され( のオプション引数としてスケーリングなし\includegraphics
)、それがno-opスケーリングとして表示されます。次に、周囲のボックスは「大きなポイント」で実行されるため、値が少し奇妙になります。
(XeTeX では、画像の取り込み時点で拡大縮小を選択できますが、これは機能しないため、dvipdfmx
コードを共有するためにこれを回避しています。基本的に、新しいバックエンド コードは pdfTeX に従う傾向があり、画像の取り込みに使用するプリミティブはすべての画像タイプに対して拡大縮小を提供しないため、共有コードとして最適な方法は、包含ボックスを拡大縮小することです。)
最後に、バウンディングボックスについて考えます。ルートでは、バウンディングボックスを取得するためにdvipdfmx
補助プログラムを使用する必要があります。しかし、XeTeXには、 PDFを直接読み取ることができる画像プリミティブがあります。キーワード引数を使用して、次のように指定します。extractbb
\XeTeXpdffile
どれのボックスに次のように表示されますtexdoc xetex
。これは で説明されています。 を使用する場合とは対照的に、このプリミティブはイメージの拡大縮小を実行できることがわかります\special{pdf:image ...}
が、上で述べたように、その機能は使用されません。 レベルでイメージを拡大縮小/回転することを選択した場合\XeTeXpdffile
、これは に表示されますmatrix
。この場合、ハイパーリンクとどの程度相互作用するかはわかりません。
PDF画像を挿入すると、希望する境界ボックスの周囲が切り取られるので、単位を気にする必要はありません。結果の画像のサイズを知りたい場合は、たとえば、画像が配置されるTeXボックスを測定します。
\setbox0=\hbox{\XeTeXpdffile "foo.pdf" media }%
\edef\pictureheight{\the\ht0 }%
\edef\picturewidth{\the\wd0 }%
画像は、常に奥行きのないボックスの参照点に挿入されるためです。 では、xetex.def
これを使用して、左下の座標が常に であると想定していることがわかります(0,0)
(cf. dvips
、ここでは人生がより「興味深い」)。
ビットマップ グラフィックスの場合、プリミティブ\XeTeXpicfile
が使用可能であり、事前に境界ボックスを必要とせずに画像を挿入できます。 で見たように\XeTeXpdffile
、これらのプリミティブは画像の境界ボックスを認識しているため、それらを「実際の」サイズで TeX に挿入します。そのため、すべてのケースで TeX ボックスを使用して結果を測定できます。