Luminescence

僕は Debian GNU/Linux というディストリビューションを使っているのだが、いくつかのツールはディストロの管理に依存せず、自分でソースを管理してビルドしている。これは昔からそうしていたから、というのと、やはりディストロのパッケージはカタくできているものなので、最新版を使っている場合にはこの方が都合がいいから、というのもある。

じゃあ具体的に何をそうしているのか、というと、まずは Kernel である。言うまでもなく、Kernel は Linux の中核を成すものなわけだけど、僕は定期的に kernel.org の finger server を覗くようにしていて、Kernel のアップデートがあったときにはアーカイブを落として、自分で debian package を作成している。

そして、GNU Emacs も自力でビルドしている。XEmacs が流行った頃に、GNU Emacs の cvs 版の方がいいなあ、という話をあちこちで聞き、当時はまだ電総研（現在の産総研）で公開されていたソースを落として build するようになって（それ以前も GNU からソースを取ってきてビルドしていたのだが）、それ以来自分で管理する習慣がついてしまった。一時期は Debian のパッケージを使ってみたこともあるのだが、現在は Bazaar で公開されているソースを落としてビルドしている。

Emacs 周辺のパッケージ、具体的には Mew, APEL, Emacs-w3n, FLIM, navi2ch, SKK, twittering-mode 等だが、これらも自分で管理している。具体的には anoncvs や Git でソースツリーを更新しつつ、定期的に自分でビルドしているわけだが、最近は Debian のパッケージを入れると、依存関係の解消のために不要なパッケージが入ってくるのが厭になってGit も自分でビルドするようになってしまった。こうなってくると、いちいち自力でやるのに一日何分かを費すことになるわけだ。

まあ、こう書くと、何をそんな面倒なことをやっているのか、と言われそうだけど、bash の強力なヒストリを使えば、そう入力に困ることはなかった。だから完全手動でやっていたのだけど、さすがにこれも面倒だし、暇があるときに一日に2度 Emacs のビルドをしていたりすると、ああこういうのがいかんのだよな、とか考えて自己嫌悪に陥る。そこで、shell script を書いて cron で自動実行するように整えた。これで一日に1度だけ、ネットワークも端末の負荷も軽い時間に、端末が自動的にその作業をしてくれるようになったわけだ。

本当は、こういうことをまず自動化できることこそが、Linux を使っていて便利なところのはずなんだけど……どうも、いかんな。

昨日のこと。ふと見た某オークションで、英語版の Windows 7 Ultimate が安価に出ていたのに、冗談半分でビッドしたところが、落札できてしまった。あれれ。こんなん買っていいのかなー、と、何やら後ろめたい思いを感じつつ、手続きを済ませた。

まあでも、必要と言えば必要なものなのだ。なにせ、Windows Vista は、7 が出たために以後のサービスパックを出していない（誤解なきよう書いておくけれど、サポートやパッチの配布は継続している）。一説には 7 は Vista SP3 相当だ、なんて話もある位である。

それに、7 のリリース直前に Microsoft 方面から聞いた話によると、たとえばエクスプローラのような頻繁に複数立ち上げるソフトのジョブを束ねることで、無用なリソースの食い潰しを防ぐ、というような配慮が 7 にはなされているという。まあ、話半分としても、試す価値がないわけではない。

それに、今使っている Vista 64bit は Home Basic で、いくつかのプログラムを使用できない。特に僕の場合に問題なのが、SUA が使用できないことだ。Windows 7 Ultimate ならば、これらの問題は皆解消される（はずだ）。

ただなあ……今回入手したのは英語版である。Windows 7 Ultimate は完全国際化されているので、インストール時に言語選択で日本語を選び、インストール後に拡張パックをインストールすれば日本語化できる（はずだ）。一応、関連情報の載っているサイトにリンクしておく：http://lowend.at.webry.info/200908/article_3.html

ちょっと環境の大掃除をする必要があって、Linux のシステムをクリーンインストールした。丁度今の時期は Debian GNU/Linux sid が不安定で、依存性が完全に解決していないライブラリがある状態で、正直こんな時期にこんな作業はしたくなかったのだが仕方ない。今は何とか以前の状態に戻せている。

で、折角なので、LaTeX を TeX Live 2010 ベースにしようと思って、ちょこちょこと作業をしていたのだけど……うーん。煮詰まった。OTF を入れて、dvipdfmx で日本語フォントを参照できるようにすると、盛大に文字化けする。何が問題なんだろうか。

さすがに TeX をハックする時間もないので、TeX Live 2009 + pTeXLive で環境を再構築する。まあこちらは方法を確立しているのでさくっと完了したわけだけど、この調子で LaTeX を使い続けていて大丈夫なのだろうか。pTeXLive も更新が止まっている→もう更新の必要なしと判断、のようだし。ううむ。

最近、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