Hatena::ブログ(Diary)

アセトアミノフェンの気ままな日常

2015-07-13

Emacs の YaTeX(野鳥)の BoundingBox 補完機能

Twitter 上の BoundingBox の話題(始まりはこちら)が気になったので横から入り込んでツイート。確かに用語の混同もあって紛らわしい部分ではある。しかし、昨年の ZR さんの TeX ユーザの集いの発表資料その補足を前提に考えると、YaTeX の実装に2箇所の問題がありそうな気がしたのである。

1. PDF のバウンディングボックス指定

  • extractbb が返すのは、PDF の CropBox → ArtBox → TrimBox → BleedBox → MediaBox のうち、この順で明示されている最初のもの。
  • Ghostscript の bbox デバイスが返す値は「図やテキストが存在する領域」。
    • したがって、何も描かれていない余白は含まれない
    • pdfcrop という Perl スクリプト(TeX Live や W32TeX に含まれる)は、まさに gs の bbox デバイスに描画範囲を算出させている。
    • pdfcrop は Perl 依存だが、類似処理は Windows バッチで再実装可能。

現状 (1.78.4) では EmacsYaTeX モードでは \includegraphics の入力補完で bb= に gs の bbox の値をそのまま入れる実装になっているらしい(これは僕はやりかたが分からず未確認…→追記:YaTeXコマンド名を gs 決め打ちなので Windows では働かないことを確認)。これは、例のスライド2番目のような明らかな「バウンディングボックス詐称」で、この値は本来 viewport= に与えるべきもののはずだというのが僕の主張。だけれど、昔の環境ではこの未定義動作のほうが正しく動くという実験結果があるので厄介。結局、僕は事前に pdfcrop(または tcpdfcrop)で余白をクロップしてから取り込むのが無難だと思っている(理由は後日)。まあここは賛否両論あるだろうし、一回実装してしまったものの仕様を変えるのは困難だな…*1

2. JPG/PNG のバウンディングボックス指定

  • extractbb が返すのは dvipdfmx にとっての正しい BoundingBox 値(bp 単位)。TeX は bp 単位を元に画像の領域を決定して確保する。
  • ピクセル値 (px) は(今も昔も)本来正しくない;解像度が 72 dpi のときだけ、bp 単位の数値は px 単位のものに(偶然)一致する。

もう一つ、JPG/PNG の場合にも YaTeX モードが \includegraphics の入力補完で bb= を入れるのだが、こちらはなんと bp ではなく px 単位の値が補完されていた。これまた例のスライドの3番目のような「面倒くさいのでピクセル単位」というものである。TL のバージョンによって結果が異なるという未定義動作であり、これもまた好ましくない*2

そもそも2つとも必須ではない機能だと思う。というのも、TeX Live 2015 以降は extractbb の自動実行が許可されているし、TeX Wiki に従ってインストールした場合(美文書を含む)などではそれ以前でも extractbb の自動実行設定をしているはずなので、わざわざ YaTeX で補完する必要がないと思うのだが… ちなみに一番はっきりこの辺りの誤解を解いてくれる記事は ZR さんによる Qiita の記事だ。少なくとも上に挙げた2点は「バッドノウハウ」そのもの*3であり、改善されたらいいなあというのが今の僕の考えである。

*1:補完の時点で bb を取得してしまえば、あとはもう gs なり extractbb なりが起動されずに済んで早いという論理であろうが、これは画像を変更した場合に「正解の値」をソース中で変更しなければならず、忘れがちではなかろうか? となると、最も確実なのは「extractbb 自動実行で毎回 LaTeX タイプセットの度に値を取得」であろう。extractbb は gs に比べると高速なので、それほどストレスは感じないと思う。

*2:実際、いま W32TeX [2012/11/07] で試してみると、dvipdfmx (20120420) で不正な表示となって ZR さんの例のスライドと結果が一致した。W32TeX [2015/07/10] ではなぜか正常になるが、未定義なので今これが期待通りだからといって喜んではいけない。

*3:僕がいう「バッドノウハウ」という用語の定義は次回