Luminescence

最近、どうもちょいと難しいと思われる言葉をすぐに平仮名で書くのが目に障って仕方がない。

昼食のとき、テレビを観ていた U に、

「とうてき、って何？」

と聞かれた。ん？ と聞き返すと、投げるに平仮名で「てき」だ、と言う。少し考えて、

「それは投擲のことじゃないの？何の話で出てきたんだ？」
「早稲田の槍投げの選手が何とか、って」
「ああ、じゃあ投擲競技のことだろうから投擲だ」

最近は「投てき」と書くらしい、ということを、今日初めて知ったのだった。

この手のもので一番よく知られているのは「障碍」「障礙」の意味で「障がい」と書く、というものだろう。たしかに、この意味で「障害」と書くのは、これは一種の当て字だから、「障害」と書かない、ということに異論を唱えるつもりはない。しかし、だ。「障がい」では、言葉の意味が正直言って分かりかねる。せっかくこの国には、表音文字と表意文字、そして両者の仲をとりもつ「ルビ」というものがあるのだから、何も平仮名で書かなくてもいいだろうに、と思うわけだが、一向にこれが変わる気配はない。むしろ、どんどんこの手の「無難な平仮名表記」が浸透しているようで、正直嫌になってくる。

先程、某ポータルサイトのテレビ番組表を何気なく見ていたところが、目に入ってきたのがこれだ：

……けつ？ と一瞬当惑した僕は、果たして下劣な人間なのだろうか。そうは思えないのだけど。いいじゃん「秘訣」で。いくら何でも、これが読めない人ってそうそういないと思うんだけど、何故そんなに平仮名に頼るの？

ここ何日か、tlmgr を動かしても TeX Live のパッケージがアップデートされることがほとんどなくなった。いよいよ、この時期が来たのである。

TUG の TeX Live のページを見ると、TeX Live 2012 への工程表が掲載されている。コメントアウトされている箇所も含めて引用すると、

Plan for TeX Live 2012:

• 2apr: sources committed, builds begin.
• 15apr: sources stable except for major bugs.
• 10may: tlnet frozen, tlpretest starts, CTAN updates only on request.
• 1jun: complete freeze for final build, no more updates, final doc tweaks, always more testing.
• 15jun: make final images for the TeX Collection DVD.
• 1jul: public release made (also of MacTeX).
• August?: delivery of DVDs to members.

僕は TeX Live の開発や配布に関して何も関わっていない (?) し、実際の運営状況もよく知らないのだが、こうなってくると気になるのが tlptexlive の行方である。既に subversion 等で公開されているソースツリーにはマージされているようなので、おそらく tlptexlive の成果は TeX Live 2012 に入ることになるのだろうと思うけれど、つい昨日に公開された uptex 1.10 はどうなるのか、とか、分からないことは多い。とりあえず、手元の環境をいつでも TeX Live 2012 に差し替えられるようにして、待つことしか術はないのだけど。

次世代の TeX / LaTeX 環境をどうしようか、あれこれ document を読みながら考えているのだが、これが実は結構悩ましい。

次世代の TeX / LaTeX 環境としてぱっと頭に浮かぶのは、

• XeTeX / XeLaTeX
• LuaTeX / LuaLaTeX
• ConTeXt (w LuaTeX)

日本語環境ということで考えると、LuaTeX-ja プロジェクトが存在する以上、LuaTeX を選択するのが現実的なのは言うまでもない。しかし、LuaTeX と XeTeX を比較した場合、ひとつだけ僕が問題に感ずることがあって、それは polyglossia のことである。

polyglossia は、多言語を XeTeX 上で扱うためのパッケージである。従来の TeX / LaTeX 業界では、この目的にはもっぱら babel が用いられていたが、polyglossia はこの後継とでも言うべき存在である。有用なパッケージで、日本語に関しては九州大学の岩瀬則夫氏が、babel の japanese パッケージに相当する gloss-japanese.ldf と gloss-nihongo.ldf を『XeTeX を使ってみよう（事故で全部消してしまったのでサービス停止中）』で公開されている。

僕は polyglossia の存在を知った当初、これが LuaLaTeX でも使えるだろうと思い込んで喜んだ。しかし……残念ながら、少なくとも現状では polyglossia は XeLaTeX でしか使えないようなのだ。ググってみると、海外でも polyglossia を LuaLaTeX で使いたい、というニーズはあるようなのだが……

じゃあ素直に babel を使えばいいじゃないか、という話になるかもしれない。たしかに babel は LuaLaTeX 上で使えるのだが、japanese パッケージは LaTeX2ε での使用しか考慮されていない。どうやら、LuaLaTeX で多言語環境（日本語を含めて）を享受したいなら、polyglossia を LuaTeX でも動作するようにするか、japanese パッケージを LuaLaTeX + LuaTeX-ja の環境下で使えるように書き換えるかするしかない、ということのようだ。むう。まあ、自力で細々と始めてみましょうか……

まず、babel で japanese.ldf を使った場合に出るエラーをチェックすると、

(/usr/local/texlive/2011/texmf-dist/tex/platex/japanese/japanese.ldf

Package babel Warning: No hyphenation patterns were loaded for
(babel)                the language `Japanese'
(babel)                I will use the patterns loaded for \language=0 instead.


! LaTeX Error: Missing \begin{document}.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...                                              
                                                  
l.53 \newif\if西
                 暦 \西暦true%
? 

ということで、japanese.ldf を見てみると……

\newif\if西暦 \西暦true%
\def\西暦{\西暦true}%
\def\和暦{\西暦false}%

• \if西暦
• \西暦
• \和暦

• \if西暦 → \ifSeireki
• \西暦 → \Seireki
• \和暦 → \Wareki

まさかこれだけで……いや、これだけでいいのである。これを行った後、LuaLaTeX + babel で japanese が（japanesedash という名前に変わっているわけだが）使えるようになったことを確認している。ということで、当面はこれでしのぐことにしようと思う。

txfonts や Mathptmx を使っていた僕も、最近は（ようやく？） TeX Gyre Termes をメインの欧文フォントとして使っているのだけど、最近、どうも何かおかしい、と気付いたのだ。TeX Gyre Termes を使うと、日本語フォントに影響が出ていないだろうか？ と。

今迄安易に：

\usepackage{tgtermes}

\renewcommand{\rmdefault}{qtm}

意外な盲点だったのだが、でも TeX Gyre Termes が高品質で、こうやってでも使いたいフォントであることは変わらない。他によりよいものが出てくるまでは、こうやって使い続けるであろう。

僕は別に TeX / LaTeX 関連を専門としているわけでもないし、いわゆる TeXnician という存在でもない。この20年近くの間、文書を作成するのに比較的よく TeX / LaTeX を使ってきて、そのプロセスで必要なことを自力で（他者のコメントに助けられながら、であることは言うまでもない）行ってきて、その余力で、たとえば『TeX Live を使おう――Linux ユーザと Mac OS X ユーザのために――』を書いたり、 各種パッケージのバグを見つけたり……ということに至っているだけである。だから、殊この分野に関しては、先生とか呼んだり「教授」という言葉を向けられたりする（もっとも最近は「教授」と「教示」の区別がつかない人が多いのだけど）のは御勘弁願いたいところである。この点、まずは断り書きをしておくことにする。

さて、『TeX Live を使おう……』でも：

おそらく LuaTeX-ja が更に進展してきたら、また日本語処理環境のベストなかたちを模索するときがくるかもしれませんが、とりあえずは TeX Live で済ませられるかな、と思っています。あと1年か、2年か、あるいはもう少しか。LuaTeX-ja プロジェクトの成果が TeX Live に組込まれるかもしれませんし、まだ僕には何とも分かりません。とりあえず、今後も動向を見守りつつ、環境整備を行い続けることになりそうです。

まず、何と言っても大きいのが、先週末に 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=???

この問題の回答方針は「『輪の数』がいくつか」ということになっているらしい。そういう直感力は子供が一番鋭いのだ、と、こういうつもりなのだろう。しかしそれはあまりに浅いというものだ。大人の解法というのを、以下に示しておくことにする。

僕がこの問題を見たときに注目したのは、「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

8809=6

8→2

2→0
5→0
8→2
1→0

このような変換は、「換字法」と呼ばれる、暗号として最も古典的なもののことを知っていれば、何となく想像がつく。換字法の場合はいわゆる一対一対応としての変換だが、この場合は一対一でない変換で、それは文字列としてではなく総和として示されるので然程問題にならない、というだけのことである。

……というように、問題は数分で解けたわけだけど、この変換の意味が「『輪の数』がいくつか」ということだ、というのには気がつかなかった……というより、そんなことは瑣末事だとしか思えなかった。だって、そういう発想がなかったとしても、この問題はちゃんと解けるのだし、子供に解けて高学歴だと解けない、なんてのは、妙なヒガミなのか、学問の深みをご存知ないのか……まあ、実のない、下らん煽り文句だった、というだけのことだったのだから。

原稿用紙マクロが使えるようになった、ということで、一例として、原民喜の『夏の花』の一節を版組みしてみることにした……のだが、冒頭に出てくる：

　　　　　　　　　わが愛する者よ請う急ぎはしれ
　　　　　　　　　香わしき山々の上にありて、獐の
　　　　　　　　　ごとく小鹿のごとくあれ

原稿用紙マクロは、桝目に文字を合わせるために独自のフォントメトリックを使っている。OTF パッケージも独自のフォントメトリックを使っているので、そのまま OTF パッケージを使用しようとすると、文字の配列が無茶苦茶になってしまうのだが、otf.sty を読み込むときのオプションに noreplace というのがあって、これを指定しておくと、フォントメトリックはそのままにして、文字を \UTF{} や \CID{} で読み込むことができる。

(/usr/local/texlive/2011/texmf-dist/tex/platex/japanese-otf-uptex/otf.sty
! Too many }'s.
l.139 ^^I}

otf.sty で、フォントメトリックの置換を行っているルーチンを見たが、ちょっと見ただけではよく分からない。では、原稿用紙マクロ以外でこのような現象が発生することがないのか、ちょっと試してみたところ……

\documentclass{article}

\usepackage[noreplace]{otf}

\begin{document}

これは OTF パッケージのテストです。

\end{document}

ということで、思い切って TeX wiki で聞いてみたのがこれだ。原因はやはり、replace に関わるネストにあるようで、皆さんコーディングを検討して下さった。まずは感謝の意をここに表したい。

いくつかの改善案のひとつを基に otf.sty を書き換えると、article の場合も原稿用紙マクロの場合もうまくいくことが分かった。勿論、jarticle や jsarticle でもうまくいく。やはり、三人寄れば文殊の智恵とはよくも言ったもので、 TeX マクロに慣れている人の助けを借りるべきときは、こうやってお願いしてみるのが早道なのかもしれない。

（後記）ここで書かれている問題に関して改善された OTF パッケージ ver. 1.7b5 がリリースされた。齋藤修三郎氏の迅速な対応に対し、ここに深く感謝の意を表するものである。TeX Live 収録のパッケージも修正されたとのこと（CTAN の announcement）だが、現時点では CTAN や TUG のサーバでも反映されていない模様。少し気長に待つべきなのか？ 余談だけれど、英語で Mr. Ueda と書かれたのは久しぶりのような気がする……知ってれば当然 Dr. Ueda とか Prof. Ueda とか書くだろうけれど、まあご存知なくて当然か。

とある事情により、原稿用紙に LaTeX で文章を組版することになった。こういうのは本当に勘弁してもらいたい……何故って、TeX / LaTeX が一番苦手としている処理だからだ。

でも、まあブツクサ言っていても何も進まないので、昔の記憶を掘り返しながら、まずは NIFTY の FTEX 辺りで流れていたマクロを探してみる……なかなか発見できなかったが、 Google The Big Brother によって以下の URL を発見：

ftp://masui.med.osaka-u.ac.jp/pub/public/latex/style/

こういうヤクザな代物をシステムに入れるのは躊躇われるので、今回は ~/texmf 以下に入れることにする。まず

~ / texmf / tex / latex / fgenko
             |
             / fonts / map / fgenko
                       / pk
                       / sources / fgenko
                       / tfm / fgenko
                       / vf / fgenko

~/texmf/tex/latex/fgenko には、

• binsen.clo
• genkin.tex
• genkomac.sty
• genkou.cls
• genkouid.tex
• ribon.clo
• tgenkou.clo
• ygenkou.clo

~/texmf/fonts/tfm/fgenko には *.tfm をコピー。このディレクトリ内で、

$ makejvf gmin10 rml
$ makejvf gtmin10 rmlv

~/texmf/fonts/sources/fgenko 内で、

$ mktexpk --mfmode / --bdpi 600 --mag 2+90/600 --dpi 1290 gerib10

$ cd ~
$ mktexlsr ./texmf

さて、これで、

\documentclass[縦,A4]{genkou}
\begin{document}

　　　原稿用紙テスト

　　　　　　　　　　　　　　　何之　某

　これから、原稿用紙でのＴｅＸによる組版の問題についてみていこうと思います。そもそも、ＴｅＸで均等割りの版組みを行うというのは、その思想に反した行為だと思うのですが、日本の場合はそれに反することを強制されることがままあり、それに対応する必要がある、というわけです。

　現在の状況に関して書いておくと、ホームディレクトリ以下に「原稿用紙パッケージ」をセットアップしてあります。フォントは小塚フォントを用いるようにしてみたのですが、ずれるので埋め込まずに使っています。

\end{document}

$ platex genkoutest.tex
$ dvipdfmx -l genkoutest.dvi

1. フォントを埋め込むとずれる。（後述：埋め込みは問題なく可能）
2. ルビをふったときもずれる。（後述：これも問題なく可能）
3. リボン（原稿用紙中央にある飾り）を付けるオプションを付与すると割付けが無茶苦茶になる。（後述：これはどうやら B4 サイズ決め打ちらしい…… dvipdfmx で "-p b4 -l " を明示的に指定することで版組が可能である）

【後記】この原稿用紙モードのアーカイブが阪大から落とせなくなっている（というよりも、よくもまあこの時代まで ftp server を生かしておいていただいたと、逆に感謝の念しきりなのであるが）。再配布自由らしいのでこちらから取れるようにしておくことにする。

• fgenko10.lzh
• fgenko10.tar.xz

あと余談ながら書き添えておくけれど、オリジナルのアーカイブを使用される場合、アーカイブ中のテキストのコード変換の際に tfm ファイルまで変換に通さないように（tfm ファイルはバイナリです）。これが原因で「動かない」と言われることがしばしばありましたよ。