Luminescence

最近、pTeX で画像を貼る必要があって、久しぶりに dvipdfmx で graphicx を使って \includegraphics で画像を貼り込もうとしたら、どうもおかしい。画像の位置や大きさが無茶苦茶になるのである。最初のうちは（TeX をなまじ使い慣れている弊害だが）ad hoc に誤魔化していたのだが、どうにも我慢し切れなくなった。

graphicx の \includegraphics では、画像の大きさを検出するのに、バウンディングボックスの情報を要求する。EPS ファイルとかならばそのファイル自体にバウンディングボックスの記述があるからいいのだが、それ以外の画像ファイルの場合は、別途この情報を用意しておく必要がある。従来だったら、

ebb foo.jpg

しかし、どうもおかしい。foo.bb のバウンディングボックスを丸写しにしても、どうしても画像がとんでもない位置に行く。おっかしーなー、他にバウンディングボックスを生成するコマンドあったっけー、などと探しつつ、TeX document 内のバウンディングボックスの値をわざと消去してみたら、

! LaTeX Error: File `foo.xbb' not found. Use -shell-escape option to generate automatically.

うーん、このxbbという形式のファイルはどう出力されるんだろう、と思いつつ、man ebb としてみると、DESCRIPTION にちゃんと書いてあるではないか。

For each JPEG, PNG, or PDF file given on the command line, extractbb extracts the bounding box information and writes it into a file with extension .xbb, together with some header information. These files can then be used by dvipdfmx or other programs. For PDF files, the number of pages and the PDF version number are reported as well. The input filename extension may be in upper or lower case.

If called as ebb, the output is written in the ``bb'' format (and with extension .bb) as used by dvipdfm. Xbb may be defined as a synomym for extractbb on your system.

480×562ピクセルの JPEG ファイルに対して生成した bb ファイルと xbb ファイルの例を以下に示す：

foo.bb

%%Title: ./foo.jpg
%%Creator: extractbb 20090708
%%BoundingBox: 0 0 346 405
%%CreationDate: Thu Mar 10 18:46:22 2011

foo.xbb

%%Title: ./foo.jpg
%%Creator: extractbb 20090708
%%BoundingBox: 0 0 98 115
%%HiResBoundingBox: 0.000000 0.000000 98.181818 114.954545
%%CreationDate: Thu Mar 10 18:27:38 2011

今使っている shannon には、大分前にメモリを増設してある。現在のメモリは 4 G だ。購入後間もなくメモリを増設して、Microsoft Windows も 64 bit 版に変更した。勿論、Linux の方は最初っから AMD64 native である。

これだけメモリを載せていると、普段使用していてメモリが足りなくなることはまずないといっていい。ちょっと前まで、ちょっとケチってメモリと同じ大きさの swap partition を用意していたのだが、メモリの内容をこの swap partition に書き出す（swap out）ような事態に見舞われたことはなかった。僕が Linux を使い始めた頃……まだ Windows 95 が登場する前で、メモリが 8 M か 16 M か、とか言っていた頃だ……には、swap は実メモリの2倍を目安にして、というのが常識だったのだけど、今はそんなことを言う人はとんとお目にかからない。そりゃ、いくら Linux が昔より肥大化したとは言っても、メモリが昔の 1000 倍（妙なツッコミをされそうなので書いておくけれど、メモリや HDD の容量表示は 1000 が基準で、 1 G バイトは 1000 M バイトである）位に増大しているんだから、swap は確実にその重要性を失いつつあるのだ。

とは言え、いわゆる memory eater みたいなソフトがないわけでもない。今回問題になったのは Google Chrome なのだけど、この便利で速くて、でもメモリをかなり食うことのあるブラウザで、flash の表示がおかしくなった。たまたま調べものをしているところで、結構な数のタブが開いてあったのだけど、これが妙に重くなってきて、あれれ？と思ったら、一時的にキー入力を受けつけない状態になった。最近 SSD ユーザが言う「プチフリ」が発生したわけだけど、どうしたのかと思ってシステムモニタ（僕は XFCE4 上で CPU・メモリ・HDD のモニタを常駐させている）を見ると……おー、4 G 食いつぶして swap out してるじゃん！いやー、このシステム構成にしてから、初めての事態である。shell から Chrome のプロセスを手動で kill して事無きを得たが、まー Debian GNU/Linux sid 上で unstable な Chrome を使っていても、こんなことにお目にかかることになるとは思わなかった。

先日の HDD 換装に伴って、swap partition の大きさをメモリの倍に設定した（なにせ HDD が巨大になったしね）のだけど、これもこういうトラブル発生時には無駄ではないのかもしれない、などと思わされた事件であった。

pTeXLive をインストールして、ようやく書きものの環境が整ったわけだけど、このインストールに際して、ひとつ気になる問題が発生している。xindy の make ができなくなっているのだ。

もともと僕は xindy は使わないので、現時点では make するユーティリティのリストから外して対応しているのだけど、xindy の make に必要な clisp 等をちゃんと入れても、どうにも xindy のコンパイルで止まってしまう。

前回通らなかったときには ordrulei.c のコンパイルで引っかかっていて、これの対策用に patch を作成してある。しかし今回引っかかっているところはこれとは異なっていて、どうも clisp で解釈されている LISP ソースのエラーのようなのである。うーん、僕は Lisp は専門外なんだけどなあ。今日中にまたコンパイルしてみて、エラーメッセージを詳細にチェックする予定。

どうにかこうにか復活か、という感じである。

HDD が巨大（と言ってもこの時代では並かそれ以下なのだけど）になったので、手持ちの Windows Vista 64 bit も問題なく入るかなあ……と思っていたら、甘かった。sp2 のパッチが当てられないのだ。どうして？と思って調べたら、KB972036 を適用してあると、sp2 をインストールできない、というではないか！勝手に update で入れてきやがる癖して、どういうことよ？などと怒ってもどうしようもない。それは Microsoft だからです、で皆納得してしまうんだからなあ。

Linux の方もちょっと難儀だった。最新の NetInst image でインストールができないのだ。しかし「名刺サイズの CD image」だと何故かインストールできるんだから、もう何が何だか……という感じである。

で、細々したものを揃えていたら、skkinput のパッケージが消えてなくなっている。wheezy のを入れようとしたら、これもパッケージがない。仕方がないので squeeze のを入れたのだけど、これぁいずれは自家用のパッケージを作るしかないのだろうか。やれやれ。

で、この時間、疲れ果てて Emacs を build しようとしたら Emacs Lisp のエラーで make が中断する……あ゛あ゛あ゛あ゛あ゛！やっとれん！