*バウンディングボックス [#headline] TeX におけるバウンディングボックスとは,TeX が組版する際に必要となる「画像のサイズ」を表す数値の組です。 元来は画像が実際に占める領域をちょうど囲む矩形ですが,画像データによっては,バウンディングボックスとして設定された領域からはみ出していることもしばしばあります。 ---- #contents ---- **TeX の画像とりこみとバウンディングボックス [#tex-and-bbox] 画像のとりこみは TeX 自身の機能ではなく,実際のとりこみは「ドライバ」がすべてを担います。 TeX が組版するうえで必要なのは「その画像を版面(紙面)に配置するためにどれくらいの幅と高さを確保するか」だけで,その際に必要となるのがバウンディングボックスです。 -参考:[[TeX と「TeX 以外」]],[[ドライバ依存>graphicx#driver-dependent]] 実際のとりこみをドライバが担っているため,バウンディングボックスの値もそのドライバに合致したものである必要があります。 逆にいえば,''使用するドライバが決まれば,TeX が利用すべきバウンディングボックスの値は一意に定まります''。 この唯一の「正解の値」以外が TeX に使われた場合,ドライバからの出力がどうなるかは''未定義''です。 「正解のバウンディングボックスの値」は,画像の形式によって以下のように扱われます。 ***EPS ファイルにおけるバウンディングボックス [#tex-and-bbox-eps] EPS ファイルの冒頭には,バウンディングボックスを指定する行を持つことが仕様で定められています。 以下の値は,[[エラー報告用の標準データセット]]の tiger.eps から抜き出したものです: %%BoundingBox: 17 171 567 739 EPS ファイルによっては,より桁数の多い高精度なバウンディングボックスをあわせもつこともあります。 %%HiResBoundingBox: 17.817252 171.021390 566.801823 738.921393 この値の組は,左下を原点とした座標系における,バウンディングボックスとして設定する矩形の左下頂点と右上頂点の各 x, y 座標を順に並べたものです(PostScript 言語には「座標系」の概念があることに注意)。 単位は bp(PostScript big point; 1bp = 1/72in)です。 TeX が EPS 画像を配置するときは,ファイルの中身を読んで冒頭の BoundingBox または HiResBoundingBox を見つけ,これを利用します。 EPS ファイルは基本的にはテキスト形式で,(時に大部分が圧縮されてバイナリになることはありますが)冒頭と末尾だけは常にテキストですので,TeX はこれを自分で読むことができます。 これが「TeX で使う画像はとにかく EPS に」と昔はよく言われていた所以です。 現在では EPS 形式以外の画像に対して -[[extractbb の自動実行>extractbb の自動実行許可の設定]]によってバウンディングボックスを取得する([[dvipdfmx]] を使う場合) -TeX エンジン自体が種々の画像のバウンディングボックスを自前で取得するライブラリを持っている([[pdfTeX]],[[LuaTeX]],[[XeTeX]] など) といった仕組みが整ったこともあり,いちいち [[Ghostscript]] を呼び出して PDF に変換しなければとりこめない不便な EPS 形式の画像は好まれなくなりました(参考:[[古い情報]])。 ***EPS ファイル以外の画像におけるバウンディングボックス [#tex-and-bbox-others] JPG や PNG,PDF といったファイルには BoundingBox や HiResBoundingBox といった記述がありませんので,なんらかの方法でバウンディングボックス情報を取得する必要があります。 そこで,pdfTeX / LuaTeX や XeTeX は TeX エンジン自体を拡張し,これらのバウンディングボックスを取得することができるようになっています。 しかし,日本でよく用いられている pTeX や upTeX はこうした拡張を経ていないいわば “素の TeX” で,画像のサイズを知る手段がありません。 そこで,TeX からの[[外部コマンドの実行]]の機構を利用して extractbb という「バウンディングボックスを抽出するプログラム」を実行し,バウンディングボックス情報を取得します。 TeX はバウンディングボックスの概念について PostScript を踏襲しているため,EPS 以外の画像形式でも単位は基本的に bp です。 JPG や PNG などのビットマップ画像には「ピクセル」(px) という概念がありますが,これとは必ずしも一致しませんので注意してください。 **dvipdfmx (extractbb) の場合のバウンディングボックス [#bbox-dvipdfmx] LaTeX + dvipdfmx の処理で [[graphicx]] パッケージを使う場合,EPS 形式以外の画像におけるバウンディングボックスの指定は +ソースに bb オプションがあればそれを最優先に採用 +bb がなければ .xbb ファイルを探しに行って読む +.xbb もなければ extractbbを実行 の順に優先されます(これは dvipdfmx.def の中で定義されています)。 extractbb というプログラムは実は dvipdfmx のシンボリックリンクで,dvipdfmx そのものです。 したがって,dvipdfmx を使う場合のバウンディングボックスの正解の値は「extractbb が返すもの」ということができます。 graphicx パッケージの dvipdfmx オプションは,TeX に続いて dvipdfmx を経由することが決まっている場合に自分自身である extractbb に「正解のバウンディングボックスの値」を返させるという役割を担っています。 ***JPG / PNG の場合 [#bbox-dvipdfmx-bitmap] ビットマップ画像の場合のバウンディングボックスは,左下隅を原点とみなし,解像度とピクセル数から算出できる物理的な寸法です。 たとえば解像度が 72 dpi の場合は 72 px が 1 in すなわち 72 bp に等しいことになり,解像度が 96 dpi の場合は 96 px が 1 in すなわち 72 bp に等しいことになります。 これに基づいて物理的な寸法を算出します。 ***PDF の場合 [#bbox-dvipdfmx-pdf] extractbb (dvipdfmx) が取得するバウンディングボックスは,PDF に存在する CropBox → ArtBox → TrimBox → BleedBox → MediaBox を順に探し,''明示されている最初のもの''を使います。 このことがまるで dvipdfmx のバグかのように吹聴する方々がいますが、そうではありません。例えば、PDF Reference sixth edition, p.964 の、 >How the various boundaries are used depends on the purpose to which the page is being put. The following are typical purposes: 以降をきちんと読みましょう。どのボックスをどういう風に使うかについて、仕様上の取り決めなどありません。決められているのはデフォルト値が何かというだけです。CropBox や ArtBox が明示されているときにのみそれらを使うというのは妥当な判断です。 W32TeX [2015/07/21] 以降および TeX Live 2016 以降では,extractbb 実行時に -B オプションで5つの Box のうちどれを使うか指定することも可能です。 **pdfinfo の場合のバウンディングボックス [#bbox-pdfinfo] [[Poppler]] や [[Xpdf]] に含まれるツールである pdfinfo は,PDF ファイルのバウンディングボックスを表示する機能を持ちます。 $ pdfinfo -box hoge.pdf によって,hoge.pdf の5つのバウンディングボックスの値を確認することができます。 **Ghostscript の場合のバウンディングボックス [#bbox-gs] [[Ghostscript]] の bbox デバイスは,PDF ファイルや PostScript ファイルのバウンディングボックスを表示する機能を持ちます。 ただし,extractbb (dvipdfmx) や pdfinfo と異なり「余白をクリップした,実際に文字や図形がある領域」の矩形を返します。 $ gs -sDEVICE=bbox -dBATCH -dNOPAUSE hoge.pdf によって,hoge.pdf の余白をクリップしたバウンディングボックスの値を確認することができます。 TeX Live や W32TeX に含まれる [[pdfcrop]] は,この機能を利用して PDF の余白をクロップしています。 **関連リンク [#links] -[[日本人のための LaTeX タブー集 ~画像読込編~:http://qiita.com/zr_tex8r/items/5413a29d5276acac3771]] --dvipdfm(ebb を起動して .bb ファイルを作成)と dvipdfmx (extractbb を起動して .xbb ファイルを作成)の違い --\includegraphics の bb オプションは単位はビッグポイントであってピクセル単位ではない -[[ナントカBoxの話(1):http://d.hatena.ne.jp/zrbabbler/20140628/1403967372]],[[(2):http://d.hatena.ne.jp/zrbabbler/20140629/1404010741]],[[(3):http://d.hatena.ne.jp/zrbabbler/20140704/1404425429]],[[(4):http://d.hatena.ne.jp/zrbabbler/20140707/1404753998]] --EPS における bbox,ビットマップにおける bbox --PDF における 5 つの“ナントカBox” -[[dvipdfmx で画像する時に色々とアレな話:http://d.hatena.ne.jp/zrbabbler/20140814/1408040710]] --標準の方法は「extractbb の自動起動を有効にする」 --代替案:事前に extractbb を手動で起動して .xbb ファイルを作成しておく --bbox には“正解”がある -[[bbox とか ナントカBox に関する補足:http://d.hatena.ne.jp/zrbabbler/20140817/1408239981]] --ImageMagick を用いてビットマップ画像の bbox を調べる --pdfinfo を利用して PDF の ナントカBox の値を調べる