僕は別に TeX / LaTeX 関連を専門としているわけでもないし、いわゆる TeXnician という存在でもない。この20年近くの間、文書を作成するのに比較的よく TeX / LaTeX を使ってきて、そのプロセスで必要なことを自力で（他者のコメントに助けられながら、であることは言うまでもない）行ってきて、その余力で、たとえば『TeX Live を使おう――Linux ユーザと Mac OS X ユーザのために――』を書いたり、 各種パッケージのバグを見つけたり……ということに至っているだけである。だから、殊この分野に関しては、先生とか呼んだり「教授」という言葉を向けられたりする（もっとも最近は「教授」と「教示」の区別がつかない人が多いのだけど）のは御勘弁願いたいところである。この点、まずは断り書きをしておくことにする。
さて、『TeX Live を使おう……』でも：
おそらく LuaTeX-ja が更に進展してきたら、また日本語処理環境のベストなかたちを模索するときがくるかもしれませんが、とりあえずは TeX Live で済ませられるかな、と思っています。あと1年か、2年か、あるいはもう少しか。LuaTeX-ja プロジェクトの成果が TeX Live に組込まれるかもしれませんし、まだ僕には何とも分かりません。とりあえず、今後も動向を見守りつつ、環境整備を行い続けることになりそうです。
と書いたけれど、どうやら、そろそろこの時期が来ているような気がするのだ。勿論、確実な処理を要求するならば、ここ何年かのデファクトスタンダードである platex + dvipdfmx が優れていることは間違いないのだが、この先に向けた助走に入ることを考えてもよさそうな状況が整いつつあるのだ。
まず、何と言っても大きいのが、先週末に LuaTeX-ja が CTAN に submit された、ということ。今現在、TeX Live 2011 をインストールして、tlmgr で最新のパッケージにアップデートするだけで、LuaTeX-ja は使えるようになるのだ！
実際、横書きに限定するならば、LuaTeX-ja は相当使える状態である。以下に、同じ文書を LuaLaTeX + LuaTeX-ja で組版して PDF としたもの (sauerbruch.pdf) と pLaTeX + dvipdfmx で組版して PDF としたもの (sauerbruch2.pdf) を示す。ほぼ同一の組版内容になっていることがお分かりかと思う。
ただし、現状では両者の間には様々な相違がある。まず、上の2文書は体裁としては同一であり、双方ともフォントを埋め込んでいるのだが、そのサイズは倍程違っている。これは dvipdfmx による埋め込みの場合、欧文フォントが CFF (Compact Font Format) と呼ばれるコンパクトな形式で埋め込まれるのに対して、LuaTeX での埋め込みの場合は type 0 フォントが埋め込まれているからである。
また、上2ファイルは各々 jarticle.cls と ltjarticle.cls を使用しているのだが、これを jsarticle.cls と ltjsarticle.cls で行った場合、組版結果には相応の相違が生ずる。これはおそらく http://oku.edu.mie-u.ac.jp/~okumura/jsclasses/ の「FAQ 長さがずれます」で書かれているような処理の相違によるものだと思うのだが……また、長さの単位に zw を使いたい場合は \zw とする必要があるし、XeLaTeX の場合と同様、en-dash や em-dash を出すためには、プリアンブルに：
\defaultfontfeatures{Ligatures=TeX}
と書いておく必要がある。
そして、今月に入ってからのことのようなのだけど、conTeXt で UTF-8 の日本語を扱ってみると、扱えないこともないようだ……という話が出ているのだ。おそらく、ここをお読みの方で conTeXt を御存じの方はそう多くないかもしれないけれど、TeX をエンジンとして使った新しいマークアップ型の組版システムである。欧米では既に結構広まっているようなのだけど、日本語を突っ込んだ場合、複数行に渡る文字列の扱いがうまくいかない、という問題があった。しかし、W32TeX で有名な近畿大の角藤氏が書いたコメントで、この問題が回避できるんじゃないの？ という話になったのであった。既に、Z. R. 氏のマクロツイーターの記事 (http://d.hatena.ne.jp/zrbabbler/20120416/1334595982) にある例で試して、これがうまくいくことを確認している。
ただし、これも問題がないというわけではない。まず、ヒラギノフォントでこれを行おうとすると、どうもうまくいかない。最新の ConTeXt Mk IV ではうまくいく、という話もあるのだけど、現時点で TeX Live に収録されているバイナリでは、この問題が不可避だった。
そして、LuaTeX-ja でも同様なのだけど、処理にかかる時間が非常に長い。ConTeXt の場合は、おそらく無駄な処理を何度も繰り返していると思われるのだが、LuaTeX-ja の場合は、初回にフォントのキャッシュを作成するのに非常に長い時間を要するものの、2回目以降はそう問題になることもなさそうな時間で処理できる。
このように、未だ pLaTeX + dvipdfmx と同様に、あるいはそれらを凌駕するような速度・質での処理ができる、というところには達していないのだけど、将来的には現状の pTeX / pLaTeX を凌駕するものになる可能性は非常に高い。ワールドワイドで見たら、今後は LuaTeX / LuaLaTeX や、それをエンジンとして用いている ConTeXt が defact standard になる可能性が大なので、日本人としても、これを無視するわけにはいくまい。eptex や uptex が登場する少し前までの日本語 TeX / LaTeX 環境がガラパゴス化寸前の状態だったことを考えると、現状の安定したシステムだけに依存するのは、やはり危ういと言わざるを得ないのだ。
Linux を使い始めてもう20年近くなるわけだが、kernel panic に出喰わすことは滅多になかった。ブートローダーやブートストラップ絡みで見ることはあっても、動作中に見る、ということは、まあまずなかった。
ところが、kernel を 3.4-rc3 に更新してから、もう3度も kernel panic に遭遇している。ファイルシステム等に高い負荷がかかったときに出るようなのだけど、どうもその周辺の挙動がログに残らないようで、未だ原因特定には至っていない。
最近は、普段使いには1種類の kernel だけを入れておくようにしていたのだけど、以前と同じように、安定版と開発版、各々の最新 kernel を入れておくようにしよう、ということで、現在 3.3.2 を build 中である。しかしなあ……こんなこと、まずこの何年かなかったのだけど、一体何が起きているのか。とりあえず状況のメモがてら、ここに書いておくことにしよう。
日頃からコンピュータを道具として使っているので、文書を電子化する必要が生ずることがしばしばあるのだけど、単語集のような本の巻末索引を電子化する必要が生じて、土曜日からちょこちょこと作業をしていた。
最近は「自炊」という言葉も定着して、本などを PDF 化する人も確実に増えている。そういう人だったら、そんなの OCR で楽勝じゃん、で終わりそうなのだけど、今回の索引はそうもいかなかったのだ。
そもそも、日本語と欧米系言語が混在している文書は、OCR で誤変換されることが少なくないのだけど、今回の文書の場合、まず欧米文字の部分に複数の書体が使用されていて、それに加えて発音記号まで（あ゛あ゛あ゛あ゛あ゛）書かれているのだ……土曜日に、試しに全てのページを 600 dpi の TIFF に変換して OCR をかけてみたけれど、いやーもう、何が何だか……というような状態であった。さあ、どうしよう。
まあ、こういうときには、手で入力できそうな量だったら、覚悟を決めて手で入力する方が速いのだろう。問題は、諦める閾値がどの辺りにあるのか、ということだけど……今回の文書は、エントリ数が千数百……うーむ、まあ、覚悟してやりますか。
ということで、がーっと入力する。こういうときには SKK は本当に便利で、英語と日本語の切り替えもスムースだし、誤変換に苛立たされることもない。しかし、まあ、数が数だから……昨日の午後の時間を一杯一杯使って、どうにかこうにか入力し仰せた。
さて、入力したこの文書を、どのような形式にしておこうか……手元では LibreOffice のフォーマットに変換してから、ソートをかけたりスペルチェックをかけたりする（まあ入力段階で既にチェックはかかっているのだが）。しかし、今回はこの文書を何人かの人に配布しなければならない。うーん……まあ、こういうときは Excel 2000 辺りの形式にしておいたら無難なのだろう、ということで、LibreOffice でエクスポートして、ファイルをメールで配布した。
しかしなあ……たとえば、最近は、子供の教科書を親がもう1冊づつ買って、自費で買った分を裁断して PDF 化する……なんてことがあるらしい。そういう人達は、どうやって記述の内容を電子化するのだろう？ 英語の教科書なんて、今回の僕が扱った文書どころではない程に、OCR で処理し難いのではないかと思うのだが……それとも iPad で見られればそれでいい、って話なの？ そういうのを電子化とは言わないように思えるのだけど……
最近ネット上で流行っているらしいのだけど、
8809=6
7111=0
2172=0
6666=4
1111=0
3213=0
7662=2
9313=1
0000=4
2222=0
3333=0
5555=0
8193=3
8096=5
7777=0
9999=4
7756=1
6855=3
9881=5
5531=0
2581=???
で、この問題のふれこみが「小学生以下は5〜10分、
高学歴ほど分からない問題」というのだそうな。となると、僕には分からないということになりそうなのだけど、おあいにくさま。ちゃんと10分未満の時間で解けましたよ。
この問題の回答方針は「『輪の数』がいくつか」ということになっているらしい。そういう直感力は子供が一番鋭いのだ、と、こういうつもりなのだろう。しかしそれはあまりに浅いというものだ。大人の解法というのを、以下に示しておくことにする。
僕がこの問題を見たときに注目したのは、「4つ全てが同じ数字から成る4桁の数は、全て0もしくは4の倍数と結びつけられている」ということである。これから、おそらくこの問題は、4桁を構成する各々の数字がある数と対応していて、4桁の数はその構成要素に対応する数の総和と結びつけられているのだろう、と推測することができるわけだ。
では、4つ全て同じ数字で構成される数を抜き出してみると、
0000=4
1111=0
2222=0
3333=0
5555=0
6666=4
7777=0
9999=4
となる。これらから、先の推測が成立すると仮定すると、
0→1
1→0
2→0
3→0
5→0
6→1
7→0
9→1
のように置き換えればよい、ということになる。先の数の組み合わせの中で、4だけは一度も登場することがなく（おそらく、上端を閉じる書き方とそうでない書き方があるので、「輪の数」を定め難いということなのだろうか……まあ、それに思い至らずとも、この問題を解く上での障害にはならない）、また、8888 に対応する数も提示されていない。しかし、8に関しては、先の結果と、たとえば、
8809=6
から、2
x + 2 = 6 →
x = 2 となることから、
8→2
とすればよいことが分かる。残りの4桁の数に対応する数も、この規則に則って加算を行うことで全て提示された通りの数に至るので、この推論は正しいと思われる。さて、問題になっている 2581 だが、これは、
2→0
5→0
8→2
1→0
より、0 + 0 + 2 + 0 →
2 、というのが答になる。
このような変換は、「換字法」と呼ばれる、暗号として最も古典的なもののことを知っていれば、何となく想像がつく。換字法の場合はいわゆる一対一対応としての変換だが、この場合は一対一でない変換で、それは文字列としてではなく総和として示されるので然程問題にならない、というだけのことである。
……というように、問題は数分で解けたわけだけど、この変換の意味が「『輪の数』がいくつか」ということだ、というのには気がつかなかった……というより、そんなことは瑣末事だとしか思えなかった。だって、そういう発想がなかったとしても、この問題はちゃんと解けるのだし、子供に解けて高学歴だと解けない、なんてのは、妙なヒガミなのか、学問の深みをご存知ないのか……まあ、実のない、下らん煽り文句だった、というだけのことだったのだから。
