*バウンディングボックス [#headline] バウンディングボックス(Bounding Box)とは,図形をちょうど囲うのに必要な大きさの,四角い箱 (矩形)のことです。 図形の大体の大きさを知るのに用いられます。 TeX においては,TeX が組版する際に必要となる「画像のサイズ」を表す数値の組として利用されます。 元来は,図形が実際に占める領域をちょうど囲む矩形なのですが,バウンディングボックスとして設定された領域から図形がはみ出していることもしばしばあります。 ---- #contents ---- **TeX の画像とりこみとバウンディングボックス [#tex-and-bbox] TeX の仕事は,文字や図形を版面(紙面)にきれいに配置することですが,図形の「中身」の処理,すなわち図形の表示や出力形式へのとりこみなど,は TeX 自身の機能ではなく,実際はプレビュアーや変換ソフトなどの「ドライバ」がそれを担います。 TeX が組版するうえで必要なのは,「その図形を版面に配置するために,どれくらいの幅と高さを確保するか」だけであり,その際に利用されるのがバウンディングボックスです。 -参考:[[TeX と「TeX 以外」]],[[ドライバ依存>graphicx#driver-dependent]] 本来の意味でのバウンディングボックスは,それぞれの図形に対して一意的に定まるものです。 しかしながら,画像フォーマットなどによっては,これはあいまいさを伴います。 そのような状況では,バウンディングボックスを何らかのやり方で推量する必要が出てきます。 この場合,組版作業を行う TeX と,出力処理を行うドライバとの間で,推量のやり方に不整合が起きると,意図せぬ結果となってしまうという問題があります。 TeX が図形の幅が 3cm だと思って配置したのに,実際の出力では,ドライバが 5cm 幅で出力してしまったなどです。 このため,使用するドライバに合わせて,TeX が利用すべきバウンディングボックスの意図された値を決めてやる必要があります。 ***EPS ファイルにおけるバウンディングボックス [#tex-and-bbox-eps] EPS (Encapsulated PostScript) は,PostScript 形式の図を様々なメディアに挿入し,配置するための画像フォーマットで,バウンディングボックス情報を持ちます。 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] ビットマップ画像が実際にどのくらいの大きさを占めるかを知るには,想定された出力機器の解像度の情報が必要です。 100 ピクセル幅の画像を,1cm 幅あたり 100 以上のピクセルを表示できる高精細の出力デバイスで表示させると,1cm の幅になりますが,1cm あたりせいぜい 30 程度のピクセルしか表示できないものでは,3cm 程にもなります。 ビットマップ画像の場合のバウンディングボックスは,左下隅を原点とみなし,解像度とピクセル数から算出できる物理的な寸法です。 JPG では,Exif データなどに解像度情報を含めることができ,そこから画像の意図された大きさを算出することができます。また,PNG などの画像形式でも,オプションとして想定される解像度情報を含めることもできます。とりこんだ画像のサイズが異常に大きかったり,小さかったりする場合は,このデータが原因です。 ***PDF の場合 [#bbox-dvipdfmx-pdf] // これを書かれた方は相当特殊な自論を持たれているようですが、文脈を読まずに気に入らない // 箇所を削除しても意味の通らない支離滅裂な文章になるだけです。 // 修正するんだったら意味の通る文に書き直しましょう。 PDF では,印刷媒体や描画領域などに関する情報として,いくつかの異なる矩形領域を宣言することができます: -MediaBox -- ページが最終的に印刷される物理媒体の領域を表します。用紙サイズです。 -CropBox -- 表示・印字されるときクリップされるべき領域 -ArtBox -- ページ内容として意味のあるとされる部分を表す領域 -TrimBox -- 出版用 -BleedBox -- 出版用 このうち必須なのは MediaBox だけです。 // このうち,いかなる PDF ファイルにも明示されているのは MediaBox だけで,アプリケーションによっては追加で他の Box を明示することもあるという程度です。 // ↑根拠不明 MediaBox は用紙サイズのような,出力媒体のサイズであり,クリップアートのような図形の大きさとはまた異なる概念です。 // このため他の文書に挿入される用途を前提とした図形のバウンディングボックスとしては本来,不適切です。 // ↑この記述はよくわかりません。 // 不適切なのに使っているのはなぜ?といわれてしまうでしょう。 // ほとんどのアプリケーションは MediaBox しか持たない PDF を出力 // することを考慮すると「不適切」という言い方は不適切です。 // ↑これこそ意味不明です。 // その「ほとんどのアプリケーション」が仕様違反かもしれないのでそっちに文句言いましょう。 他にも出版用途の様々なボックスがあり,どれを選ぶのが適切なのかは混乱を招きます。 クリップアートのようなものでは,CropBox や ArtBox を参考にするのが適切かと予測されます。 //PDF Reference sixth edition, p.964 には,ひとつの指針として // //>Placing the content of a page in another application. The art box determines //the boundary of the content that is to be placed in the application. ... //(略)...The media box and trim box are ignored. // //とあります。 //extractbb (dvipdfmx) が取得するバウンディングボックスは,PDF に存在する CropBox → //ArtBox → TrimBox → BleedBox → MediaBox を順に探し,''明示されている最初のもの''を使います。 // ↑こんなこと書いて参考になる''一般的な''ユーザなんているんでしょうか? // ほとんどのひとはこれらBoxのことなんて知りたくもありません。 // // 恣意的な仕様解釈で自論を振りかざしてもなんにもなりません。上記のルールで実質 CropBox // が明示されていればその通りになり,ArtBox をわざわざつかっているようなものがあればそれが // 優先され,MediaBox にしょうがなくフォールバックするという動作になります。実装者とユーザが // 試行錯誤の上そのような結果に落ち着かせたのならなんの問題があるのでしょう? // CropBox が明示されていないからといって,すぐにデフォルトのMediaBoxを採用すれば,それで // ユーザが期待した結果になりますか? //このことをまるで、dvipdfmx が PDF の仕様に違反しているかのように吹聴する方々がいます。 // ↑ // わざわざ新しく追加された -B オプションは、意図的に pdfinfo 互換(=pdfTeX 互換) // のクリッピングやフォールバックを実装してあります。 // わざわざ新機能で従来の extractbb の判定と一部異なる値を用いている理由は, // 従来の判定が PDF の仕様と異なることがわかっているからです。 // // ↑ 仕様書の記述を無視してあなたの独断を述べても意味はありません。 // 仕様違反だから変えた、それが仕様違反の証拠だなんて述べてどうしたいんでしょう? //しかしながら、 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: 以下には,画像を他のファイルに取り込むといった状況で,どのボックスをどういう風に使うかについて,いくつかの例示があります。プログラム,特にバッチ処理プログラムが,どのようにこれら複数の画像 サイズに関連した値を使うかは不明瞭なところがあります。 // 決められているのはデフォルト値が何かというだけです。 // ↑ デフォルト値がある = 明示されていないときはそのデフォルト値が採用される // ことを定めているのでしょう? そうでないとデフォルト値の存在意義がありません。 // // ↑ デフォルト値があるということとそれによって与えられた値が何らかの目的に利用されるか // ということは別問題です。論点理解してますか? dvipdfmx は特定のルールに従い,PDF画像のバウンディングボックスを決定します。 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 の値を調べる