バウンディングボックスの編集

*バウンディングボックス [#headline]

バウンディングボックス（Bounding Box）とは，図形をちょうど囲うのに必要な大きさの，四角い箱 （矩形）のことです。
図形の大体の大きさを知るのに用いられます。
TeX においては，TeX が組版する際に必要となる「画像のサイズ」を表す数値の組として利用されます。
元来は，図形が実際に占める領域をちょうど囲む矩形なのですが，バウンディングボックスとして設定された領域から図形がはみ出していることもしばしばあります。

// 編集について一致していないようなので，
// この項目を作成した当人としての意見です．
// ここの目的は，TeX に特化して理解すべき「バウンディングボックス」の
// 意味についての事実をまとめることです．
// プログラムのどれかが仕様に合致するか違反しているかという議論は無用で
// あって，単に「…が使われます」という事実が集まればよいです．
// 「CropBox や ArtBox を参考にするのが適切かと予測されます」のような
// 個人的な意見も求めていません．
// PDF Reference に書かれている定義や規則，用法の例示がなんであれ，
// TeX や関連プログラムが何を使うかという理解には無用のものです．
// 「正解」「間違い」というカギカッコ用語を使うのであれば，
// その定義を明らかにしたうえで使えばよいと思います．
// 実際問題として「TeX とドライバが不整合を起こさないような値」を
// バウンディングボックスとして使わなければならないのは事実なのですから，
// 読者にその事実を認識してもらうことが第一の目的です．

// // とりあえず↑の方針に沿って書いてみました。いかがでしょう？

----
#contents
----

**TeX の画像とりこみとバウンディングボックス [#tex-and-bbox]

TeX の仕事は，文字や図形を版面（紙面）にきれいに配置することですが，図形の「中身」の処理，すなわち図形の表示や出力形式へのとりこみなど，は TeX 自身の機能ではなく，実際はプレビュアーや変換ソフトなどの「ドライバ」がそれを担います。
TeX が組版するうえで必要なのは，「その図形を版面に配置するために，どれくらいの幅と高さを確保するか」だけであり，その際に利用されるのがバウンディングボックスです。

-参考：[[TeX と「TeX 以外」]]，[[ドライバ依存>graphicx#driver-dependent]]

本来の意味でのバウンディングボックスは，それぞれの図形に対して一意的に定まるものです。
しかしながら，画像フォーマットなどによっては，これはあいまいさを伴います。
そのような状況では，バウンディングボックスを何らかのやり方で推量する必要が出てきます。
この場合，組版作業を行う TeX と，出力処理を行うドライバとの間で，推量のやり方に不整合が起きると，意図せぬ結果となってしまうという問題があります。
TeX が図形の幅が 3cm だと思って配置したのに，実際の出力では，ドライバが 5cm 幅で出力してしまったなどです。
このため，使用するドライバに合わせて，TeX が利用すべきバウンディングボックスの意図された値を決めてやる必要があります。

本項目では，「バウンディングボックスの推量において不整合が起きない値」のことを「正解の値」と呼ぶことにします。
組版を担う TeX と出力処理を行うドライバが不整合を起こさないためには，TeX が使うバウンディングボックスの値はドライバに合致した「正解の値」でなければなりません。
以降では，使用するドライバに応じて 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 にとってのバウンディングボックスの「正解の値」を知ることができるのです。

***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 ファイルにも明示されています。
他の Box については，アプリケーションによっては追加で明示することもあるという程度です。
プログラム，特にバッチ処理プログラムが，どのようにこれら複数の画像サイズに関連した値を使うかは不明瞭なところがあります。

extractbb (dvipdfmx) が取得するバウンディングボックスは，PDF に存在する CropBox → ArtBox → TrimBox → BleedBox → MediaBox を順に探し，''明示されている最初のもの''となります。
TeX Live 2016 以降では，extractbb 実行時に -B オプションで5つの Box のうちどれを使うか指定することも可能です。
どうしても思うようにいかない場合は使ってみましょう。
// ↑ こんなこと書いて参考になる''一般的な''ユーザなんているんでしょうか？
// ほとんどのひとはこれらBoxのことなんて知りたくもありません。
// ↑ ここは「バウンディングボックス」を網羅的に説明するために設けられた
// ページなのですよね？ だとすると，PDF にある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 に含まれる [[pdfcrop]] は，この機能を利用して PDF の余白をクロップしています。

**関連リンク [#links]

-[[日本人のための LaTeX タブー集 ～画像読込編～:http://qiita.com/zr_tex8r/items/5413a29d5276acac3771]]
--dvipdfm（ebb を起動して .bb ファイルを作成）と dvipdfmx （extractbb を起動して .xbb ファイルを作成）の違い
--\includegraphics の bb オプションは単位はビッグポイントであってピクセル単位ではない
-[[ナントカBoxの話(1):https://zrbabbler.hatenablog.com/entry/20140628/1403967372]]，[[(2):https://zrbabbler.hatenablog.com/entry/20140629/1404010741]]，[[(3):https://zrbabbler.hatenablog.com/entry/20140704/1404425429]]，[[(4):https://zrbabbler.hatenablog.com/entry/20140707/1404753998]]
--EPS における bbox，ビットマップにおける bbox
--PDF における 5 つの“ナントカBox”
-[[dvipdfmx で画像する時に色々とアレな話:https://zrbabbler.hatenablog.com/entry/20140814/1408040710]]
--標準の方法は「extractbb の自動起動を有効にする」
--代替案：事前に extractbb を手動で起動して .xbb ファイルを作成しておく
--bbox には“正解”がある
-[[bbox とか ﾅﾝﾄｶBox に関する補足:https://zrbabbler.hatenablog.com/entry/20140817/1408239981]]
--ImageMagick を用いてビットマップ画像の bbox を調べる
--pdfinfo を利用して PDF の ﾅﾝﾄｶBox の値を調べる

**コメント [#comment]

#comment

// ===== 以下，本文中から移転したコメント (before 2015-11-20) =====
// 不要だと判断されましたら，削除してください。

// 無意味な蘊蓄の披露はやめましょう。「正解」の値ってなんですか？「正解」なんてありません。
// ユーザが「意図する」値やプログラムがそうと推測する値があるだけです。
// ↑ 返信
// 「推量のやり方に不整合が起きると，意図せぬ結果となってしまう」
// この不整合が起きるような値を「間違い」という言い方で表現しているのです。
// 不整合が起きない値のことを，「正解」と呼んでいます。
// カギカッコつきで「正解」と言っている理由は，そういう意味です。

// MediaBox 以外は「必須」との文言はないですので無くても良いものです。
// - dvipdfmx も MediaBox だけ明示した PDF を作ります。
// - pdfTeX も通常は MediaBox だけを明示した PDF を作ります。
// - Office (MS, Apache, Libre) で図を描いて PDF を保存する場合も MediaBox だけです。
// - （横から追記：）Inkscape で図を描いて PDF を保存する場合も MediaBox だけですね．
// ArtBox なんて，Illustrator 以外のソフトウェアが明示するのを
// 見たことがありません。例があれば挙げてください。
// CropBox は PDF のトリミングという機能を持つツールがほとんどこれを
// 明示しています（Preview.app やオンラインの PDF トリマーなど）が，
// それ以外のツールで CropBox を明示するものを知りません。
// もしあれば例を挙げてください。
// そのように「MediaBox 以外の Box を明示するツール」が仮に
// 「MediaBox だけを明示するツール」を凌駕する数あれば，考えを改めます。
// で，そもそも「アプリケーションによっては追加で他の Box を明示することも
// あるという程度です」という記述はこうした経験に基づいたもので，
// 具体的に根拠を書かなければ根拠不明とまで非難されることは想定外です。
// Wiki の記述を書くには「これだけたくさんのツールが MediaBox しか
// 明示しません」という根拠まで付けないといけないとでもいうのですか？

// MediaBox は用紙サイズのような，出力媒体のサイズであり，クリップアートのような図形の大きさとはまた異なる概念です。
// このため他の文書に挿入される用途を前提とした図形のバウンディングボックスとしては本来，不適切です。
// ↑この記述はよくわかりません。
// 不適切なのに使っているのはなぜ？といわれてしまうでしょう。
// ほとんどのアプリケーションは MediaBox しか持たない PDF を出力
// することを考慮すると「不適切」という言い方は不適切です。
// ↑これこそ意味不明です。
// その「ほとんどのアプリケーション」が仕様違反かもしれないのでそっちに文句言いましょう。
// ↑ 上で書いたとおり，PDF Reference で MediaBox 以外について「必須」という
// 注意書きはないので，文句を言える筋合いはありません。
// MediaBox さえあれば，他は明示しなくても自由なのです。
// 「仕様違反かもしれない」そんなわけない。仕様書を読み直してください。

// 他にも出版用途の様々なボックスがあり，どれを選ぶのが適切なのかは混乱を招きます。
// 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.
//
// とあります。 
// クリップアートのようなものでは，CropBox や ArtBox を参考にするのが適切かと予測されます。
// ↑ これこそ，「使う人がどれをどう使いたいか自由」と書いているではないですか。
// 下に「ひとつの指針」とあなた自身が引用しているように，規則ではないのです。
// あなたは CropBox や ArtBox が適切だと考えるかもしれませんがそれ自体も
// 指針のレベルにすぎず，恣意的なものです。

// dvipdfmx は特定のルールに従い，PDF 画像のバウンディングボックスを決定します。
// // この「特定のルール」という書き方をするより，情報として実際の動作を説明する
// // ことに意義を感じませんか？ 隠してなんになるのでしょう？
// // 違反かどうかはおいておき，こういう順序で読むという事実を伝えるべきでは。
// このことをまるで、dvipdfmx が PDF の仕様に違反しているかのように吹聴する方々がいます。
// ↑
// わざわざ新しく追加された -B オプションは、意図的に pdfinfo 互換（=pdfTeX 互換）
// のクリッピングやフォールバックを実装してあります。
// わざわざ新機能で従来の extractbb の判定と一部異なる値を用いている理由は，
// 従来の判定が PDF の仕様と異なることがわかっているからです。
// ↑ 仕様書の記述を無視してあなたの独断を述べても意味はありません。
// 仕様違反だから変えた、それが仕様違反の証拠だなんて述べてどうしたいんでしょう？
// ↑ 逆に，違反でなければわざわざ変えた理由はなんだとお考えでしょう？
// 元々の仕様のまま突っ走ればよかったとは思いませんか？
// 「仕様書の記述を無視して」はむしろ逆にこちらからあなたに言いたいです。
// デフォルト値があるのに使わない・クリップすべきなのにしない」という
// dvipdfmx を擁護してどうしたいのでしょう？
// とはいえ今までの挙動がそうであったことは事実なので，従来の挙動は維持して
// 新しい -B オプションだけ仕様に揃えたという開発者の判断は妥当だと評価しております。
// dvipdfmx は仕様違反だから使うなとかダメだと批判するつもりは毛頭ありません。
// そういう風に動作するという事実を，情報としてここに書くことに意味があると
// 考えています。あくまで情報提供であって，本来はどうあるべきという個人的な
// 意見は書いていないつもりでした。だから「dvipdfmx は…をバウンディングボックスに
// 採用します」という事実だけ書いていました。それが違反かどうかは二の次。

// 決められているのはデフォルト値が何かというだけです。
// ↑ デフォルト値がある ＝ 明示されていないときはそのデフォルト値が採用される
// ことを定めているのでしょう？ そうでないとデフォルト値の存在意義がありません。
// ↑ デフォルト値があるということとそれによって与えられた値が何らかの目的に利用されるか
// ということは別問題です。論点理解してますか？
// ↑ 別問題ではないと思います。
// デフォルト値は利用されることを前提に定められたものであり，
// そのデフォルト値が利用されては都合が悪いとすれば，
// デフォルト値の定め方に文句を言わないといけないことになってしまいます。
// 私はデフォルト値の定め方に文句を言うつもりはありません。

// 恣意的な仕様解釈で自論を振りかざしてもなんにもなりません。
// 上記のルールで実質 CropBox // が明示されていればその通りになり，
// ArtBox をわざわざつかっているようなものがあればそれが優先され，
// MediaBox にしょうがなくフォールバックするという動作になります。
// 実装者とユーザが試行錯誤の上そのような結果に落ち着かせたのなら
// なんの問題があるのでしょう？ CropBox が明示されていないからと
// いって，すぐにデフォルトのMediaBoxを採用すれば，それでユーザが
// 期待した結果になりますか？
// ↑ CropBox が明示されていないときに即 MediaBox で「ユーザの期待はずれ」かどうか
// は，そのユーザに聞いてみないとわからないでしょう。
// そもそも ArtBox → CropBox → MediaBox の順に探すのが一番幸せなのだろう
// （かつ仕様とも齟齬をきたさない）とは個人的には思っていますが。
// 少なくとも「実装者とユーザが試行錯誤の上そのような結果に落ち着かせたのなら」
// という仮定が正しい根拠はどこにもありません。ユーザも意見を出して
// 試行錯誤したという事実があるのかどうかは私は知りません。