青空文庫というプロジェクトがある。著作権切れ（一部著作権の切れていないものも含む）の文学作品を電子化・蓄積・公開する、というものだけど、ここでは電子化した文書を plain text と XHTML document というかたちで公開している。僕等がこの手の文章を読んだり使ったりする際には、たとえば PDF であると都合がいいのだけど、いきなり PDF で公開する、というのは、たしかにいささか能率が悪いと思う。
僕の場合は TeX を使うので、たとえばこんな風（gon.pdf）に PDF 化が容易（でもないかな……でもまあ、この程度には）にできる。今度、『ごん狐』はちょっと使う用事があるのでこんなものを作成したけれど、自動的に TeX document に変換するような方法は、ちょっと頭が回ればできないこともない。実際、齋藤修三郎氏が公開されているコンテンツ『青空文庫を読もう！』のアーカイブを使えば、pLaTeX と ruby でこの変換を実現することができる。
ただし、元となる青空文庫の document 仕様には、実は致命的な問題がひとつある。ルビの分かち書き、という概念が入っていないのだ。
どういうことかを具体的に示そう。ルビ（いわゆる「振り仮名」）というのは、特に戦前の文章を読む場合には非常に重要なものなわけだけど、青空文庫では、このルビを表示するのに、《》でルビを囲んで表示している。青空文庫でルビを用いている文書に必ず添付される例で示すと、
（例）私《わたし》
のように表示しているわけだ。この例のような場合はこれでよろしい。しかし、今回の『ごん狐』の場合で一例を挙げるなら、
火縄銃《ひなわじゅう》
のような場合はどうするのか、ということである。
何が問題なのか？と問われそうだけど、「火縄銃」に「ひなわじゅう」とルビをふる場合は、実際には「火」に「ひ」、「縄」に「なわ」、「銃」に「じゅう」とルビをふるのが適切なわけだ。だから、このような場合には、
火《ひ》縄《なわ》銃《じゅう》
と、ルビを各々の漢字との対応関係が明示されるように「分かち書き」しなければならないのだ。誤解なきように強調しておくけれど、本来の書籍における組版では、このように分かち書きされた状態でルビが付いているものである。「いやーその二つって実際に差があるの？とか言われそうなので、以下に二者の相違を示す：
ではなぜ、青空文庫ではそのようにしていないのか。これは容易に想像がつくのだけど、テキストをそのまま人間が読むときに、このような表記が煩雑で読みづらくなるからこうしましょう、と「安易に」決めてしまったのだろう。しかし、文学作品を電子化する旨味というものを考えると、電子書籍としての利用や全文検索だけでなく、いわゆるタイプセッティングシステムの俎上に、このような文書を容易に載せることができる、ということは決して無視できない。
テキストを人が眺めることしか考えずに、本来の組版において込められていたルビの「分かち書き」に関する情報を、青空文庫ではそぎ落としてしまっている。これは、後で人がいちいちチェックするか、分かち書きを失敗することを覚悟した上で、辞書を用いたシステムで改めて分かち書きを行う、という作業を経なければ、本来の組版が持っていた情報を回復できないことを意味している。
これ以外にも、青空文庫に関しては、その運営が独善的である、等の批判がある。文書を資源化するということは、大きな恩恵が得られる行為なのだから、どうかその本道をちゃんと考えていただきたいものだ。そして、自分が見るもの、見ること、見る方法だけで、世界が成り立っているわけではない、という謙譲の意志を、どうかちゃんと持っていただきたいものなのだが。
先日 (1) を書いたザウアーブルッフ（ザウエルブルッフ）の件を書き続けるために、いくつか資料を用意していた。ほとんどは英語で書かれた医学史専攻の研究者による論文なのだけど、ザウアーブルッフの伝記として世に出ているもので数少ない日本語の文献がふたつあって、そのうちのひとつがこれである:
『危ない医者たち』: ロバート・ヤングソン，イアン・ショット 著，北村 美都穂 訳，青土社 ，1997．
しかし、この本の訳がもうひどいったらない。訳者の北村氏は既に鬼籍に入られているとのことだが、イギリス人の英語を日本語にし切れていないのが見え見えのひどい文章である。あまりにひどいので、ロンドンの Robinson 社から出ている原著 "Medical Blunders" のペーパーバックを取り寄せていたのだが、先日ようやく送られてきた。
ザウアーブルッフに関する記述はだいたい14ページ位の量なのだけど、僕は医学系の研究者ではないので、たとえば "oesophagus"（食道 esophagus）なんて単語が出てくると、さすがに首を捻ることになる。こういうときには、Emacs 上で英語の文章をテキストとして開いて書き換えるように訳して、不明な単語は sdic + 英辞郎で確認する、という作業をすると間違いが少なくていいのだけど、そうなると、このペーパーバックの文章を電子化する作業が必要になってくるわけだ。
14ページだから、本気でやっていれば手で打ち込めない量ではない。しかし、さすがにこれは楽をしたいところだ……しかし、これだけのために全ページをスキャンして OCR にかけるというのも面倒な話である。それに手元にはフラットヘッドスキャナ（後記：これは間違い。フラットベッドスキャナ Flatbed Scanner が正しい）があるだけなので……うーん、どうしようか、と考えたのだった。
実は、フリーの OCR ソフトがないわけでもない。日本語の場合は、もう公開されていないけれど、かつては SmartOCR Lite Edition というのがあって、これは結構皆さん重宝されていたようだ。まあ、スキャンの手間もあるし、日本語で OCR が必要になるなら、外部業者にスキャン依頼した方が楽かもしれない。
では英語の場合は、というと、これが Linux で動くフリーのものが複数種存在する。今回は GNU Ocrad で作業を行うことにする。
まず、14ページの文書をスキャナで読み込み、pbm，pgm，ppm，pnm のいずれかの形式でセーブしておいて、
ocrad -F utf8 foo.pgm > foo.txt
などとすれば良い。標準出力に出てくるので、シェルスクリプトなどで大量のファイルを処理することも容易である。
で、さっそく変換してみると……うーん。変換精度が今一つ、という感じである。ペーパーバックなので紙質が悪くて画像にノイズが多いというのもあるのだけど、辞書チェックをがっつりかけているわけでもないようなので、それが大きいかもしれない。まあ、とりあえず全て電子化する作業を終えたけれど、校正するのがこれから一苦労、ということになりそうなので、ABBYY FineReader Engine CLI for Linux の trial version をこれから試してみようか、と思案中である。
PDF を読むときには、Adobe Reader か xpdf かを使う。前者で表示できて後者で表示できないことはしばしばあるのだけど、逆はめったにない、はずだった。
ところが、日本語の文書を表示することが一切できなくなってしまった。これには少々焦ったのだけど、TrueType フォントで、MS 明朝と MS ゴシックの代替品を msmincho.ttc と msgothic.ttc に見えるように細工してあったのを思い出した。調べてみると……:
Ubuntu日本語フォーラム: インデックス » デスクトップ向けソフトウェア » Adobe Reader 9で日本語が点々になる件
あー……どうやら原因はこれらしい。
MS フォントの代替品を外すことはちょっとできないので、次善の策として、Adobe Reader に Microsoft のフォントを検出させないように、~/.bashrc に、
export ACRO_DISABLE_FONT_CONFIG=1
を追加して、問題は解決した。
先日の Linux の再セットアップのときに、Windows のシステムが入っているパーティション（当然だが NTFS でフォーマットしてある）を少し拡げた。隣接している Linux 用のパーティションを少し削って Windows 領域の拡大にあてたのだ。ああ、ちなみに書き添えておくけれど、こういうことは別に売り物のソフトがなくても比較的簡単にできる。僕は GNU Parted を使っているけれど、他にも、かつての Partition Magic の作者が公開しているというふれこみの Partition Logic なんてのもあるので。
で、Windows を起動したら、ディスクに問題があるというメッセージが……あー、しまった。これぁインデックスに不具合が出たな。まあ当然と言えば当然で、ボリューム（UNIX 系のファイルシステム等におけるパーティションに相当）の大きさを大きくした影響がこういうかたちで出たわけだ。
通常は、起動時にこういうメッセージが出たら、システムの本体を読み込む前の段階でディスクチェックがかかるようになっているわけだけど、どういうわけか僕のシステムでは、このブート時のチェックが問答無用で「チェック拒否」を選択した状態になる。そのために、放っておくといつまで経ってもこのままである。
さすがにこれは気持ちが悪いので、Windows の DVD ディスクを出してきて、DVD からブートしてコマンドプロンプトから CHKDSK をかけることにする。えーと、CHKDSK のオプションは、と……：
ディスクをチェックし、現在の状態を表示します。
CHKDSK [ボリューム[[パス]ファイル名]]] [/F] [/V] [/R] [/X] [/I] [/C] [/L[:サイズ]] [/B]
ボリューム ドライブ文字 (文字の後にはコロンを付ける)、マウントポイント、
ボリューム名を指定します。
ファイル名 FAT/FAT32 のみ: 断片化をチェックするファイルを指定します。
/F ディスクのエラーを修復します。
/V FAT/FAT32: ディスクの全ファイルの完全なパスと名前を表示
します。
NTFS: クリーンアップ メッセージがあればそれも表示します。
/R 不良セクタを見つけて、読み取り可能な情報を回復します (/F も
暗黙的に指定されます)。
/L:サイズ NTFS のみ: 指定されたキロバイト数にログ ファイル サイズを
変更します。サイズが指定されていないときは、現在のサイズを
表示します。
/X 必要であれば、最初にボリュームを強制的にマウント解除します。
ボリュームに対して開かれているすべてのハンドルは、無効になり
ます (/F も暗黙的に指定されます)。
/I NTFS のみ: インデックス エントリのチェックを抑制して実行しま
す。
/C NTFS のみ: フォルダ構造内の周期的なチェックをスキップします。
/B NTFS のみ: ボリューム上の不良クラスタを再評価します (/R も
暗黙的に指定されます)。
/I または /C スイッチは、ボリュームの特定のチェックをスキップして、Chkdsk の
実行時間を短縮します。
こういう時位しかチェックしないので、/R を選択することにする。大体1時間ちょっとでチェックは終了し、あの鬱陶しいメッセージは出てこなくなった。
それにしても、NTFS のファイルシステムチェックが Linux 上からで出来ないのが苦痛だ。方法が皆無というわけではないのだけど、Windows のシステム領域のバックアップが取れるだけの容量が必要だったりして、僕は使っていない。早いところ ntfsck が安定して使えるようになれば良いのだが。
