2004/11/29
ScanSnapを使う

富士通のScanSnap fi-5110EOX2は、自動給紙装置の付いたUSB 2.0接続のA4小型スキャナーである。前々から注目していたところにPC Watchの紹介記事を読んで、購入意欲に火がついてしまった。

ScanSnapで紙の書類をPDFにしたところで書類の利用価値が高まるわけではないと考える人は、まったく正しい。ScanSnapのありがたみは紙書類を気兼ねなく捨てられることにある。いつか使うかもしれないと考えると書類が捨てられなくなる人には打って付けだ。逆に、気兼ねなくどんどんモノを捨てられる人には役に立たない品物だろう。

ドライバーソフトウェアに気になる点がある。まず、ボタン一発でスキャンできるようにドライバーを起動時に常駐させる設定にしていると、Windowsの起動時間が10秒ほど延びる。(Celeron 1.0AGHzでWindows 2000 SP4。5400rpmのHDD。)また、スキャンしてからデータ転送が終了するまでCPU負荷が100%に張り付いたままだ。白黒600dpiで取り込んでいるときには、最大で80MB強のメモリー割り当てになる。

2004/11/22
英文タイポグラフィの基本的な書籍

Sさんから聞いてはじめて知ったことに、英米で標準的に使用される引用符(“”の半角のもの)が一太郎ではうまく扱えないのだという。Microsoft Wordだと入力オートフォーマット機能によって引用符を適切なかたちに(non-orientedからorientedに)変更してくれるのだが、一太郎はその機能を備えていない。検索・置換で変えようにも、その部分は半角カナの領域のため日本語フォントになってしまうのだそうだ。まさかと思って一太郎2004で試してみたら本当だった。これでは欧文は組めない。

つい最近Robert Bringhurstの『The Elements of Typographic Style』に第3版(Version 3.0)が出たので購入した。同書のめざすところはThe Elements of Styleのタイポグラフィ版で、タイポグラフィに関わる原則をコンパクトにまとめようとしたものだ。もっとも、382ページがコンパクトかどうかは意見の分かれるところだろう。

章立てを紹介しておくと、次のようになっている。章の名前が詩的で内容が把握しにくい箇所は括弧内に補足説明をしておいた。

1. 基本設計(前講釈)
2. リズムとプロポーション(アキのとりかた)
3. 調和と対位の方法(書体の寸法・修飾)
4. 構造と意匠(章・段落起こし、脚注、表などの構成要素)
5. 約物
6. 書体選びと組み合わせ
7. 歴史の幕間(書体と活版の歴史)
8. ページ成形(判型と版面の設計)
9. 技術の趨勢(電子活字や組版ソフト)
10. 書体の調整
11. 活字の森へ(活字見本帳の見かたと書体紹介)

同書の特色は、筆者の性質かカナダ多文化主義の表われか、米英や西欧以外の文化に対しても配慮を払っている点だ。グーテンベルクとともに畢昇の名前がある(しかも漢字で)のには驚いたし、ギリシャ語書体についてのまとまった解説は役に立った。同じラテン文字を使っているということでベトナム語まで遡上に載せているのは珍しい。

第8章はおもしろい。用紙の縦横比を音階に見立てて表現しているのは初めて見た。たとえば1:sqrt(2)ならaug.4thという具合である。洋書はほんとうにさまざまな判型があって書棚の整理がつかなくて困るのだが、判型の自由度の高い地域ならではの章だ。

思うところがあるのは第5章の原則5.2.2「ダッシュを使って数字の範囲を示すときには、2分ダッシュか3分ダッシュを空けずに使う」(p.80)というもの。組版例を見て思うに、この原則が生きるのはnon-liningな数字のときだ。

300dpiのスキャン結果ではわかりにくいかもしれないが、上の絶妙なアキは素敵だ。(EUのルールには2分ダッシュはないそうで、この場合もハイフンで組まれる。)日本語の文脈で使うときにnon-liningにはしづらいが、前にも書いたようにliningな数字の多くは字間が詰まっているため、このまま空けずに組むと窮屈になるだろう。この場合は広げる方向でのkernが必要ではないか。

本書の本文書体はAdobe Minion(1991)である。MinionはOpenType時代の標準セリフ書体とでもいうべき地位を占めている。作者はAdobe Garamond(1989)と同じくRobert Slimbachで、Times Romanよりは読みやすいし文字種も多い。(Minionのギリシャ文字は美しい。)Optical版もある。私の好みから若干はずれるところもあるが、多くの場面で使用されてほしいと思う。

残念なのは、かすれたページがあるなど印字品質があまり高くない点だ。出たばかりなのに――と奥付を見たら、なんと中国で印刷したとある。メキシコで印刷するよりもさらに低コストなのだろうか。

さて、本書の最大の謎に触れていなかった。それは冒頭の引用文である。困難だが日本語訳しよう。

――書いたものはすべて過ぎ去ったものだと言える。動物が残した足跡みたいなものだ。それゆえ、瞑想の達人は文字を究極のものとしない。足跡や文字や合図を用いて真理に到達するのが目的なのだが、真理そのものは合図ではないから足跡など残さぬ。言葉でわかるものではないのだ。前に進むには、前に戻って言葉の源を追えばよい。もっとも、合図や理屈や世間の評価に目が行くあいだは悟りは開けまい。
――ですが、合図や評価を諦観すれば、まったくの無になってしまうのではないですか。
――そうだ。

なんだか禅のような話だ。真理が月で言葉が指で、月を指させば月の方向はわかるが指は真理ではない、という比喩をむかし読んだ記憶がある。だが、引用元には「Kimura Kyuho, Kenjutsu Fushigi Hen. 1768」とある。この「木村きゅうほう」なる人物にはまったく心覚えがない。

おもしろいことに、日本語のGoogle検索では「剣術不思議篇(?)」も木村氏もまったく出てこないのだが、世界各国で数件のヒットがある。英語だけでなくポルトガル語やドイツ語やオランダ語になっているところを見ると、シーボルトが持ち帰ったのだろうか。この件についてご存じの方があれば、教えていただければ嬉しい。

追記。2人の方から、木村久甫「剣術不識篇」であることを教えていただいた。「Kyuho」を「きゅうほう」と読むあたり、「Ryokan」と同じ失敗を繰り返しているのが情けない。


2004/11/15
Windows版茶筌(WinCha)の現在

むかし、日本語文献の分かち書きの作業をしていたことがあった。通常の分かち書きよりも区切りが弱く(粒度が荒く)、分かち書きの文字も2種類ある。また、表層語は同じでも品詞が異なる語(たとえば「と」には数種類ある)の一部には@記号をつけるなど、なかなか手間のかかるものだった。当時は富士通の形態素解析システムbreakfastを使い、それをPerlスクリプトで後処理していた。「@」の付加は文法的な判断が必要となるので手作業で行なっていた。

その後、形態素解析にWindows版のChasenを用い、統計処理と出力にはAccessを使うという話が出ていたのだが、私がさぼっていたために立ち消えになってしまった。それが先月ごろから再び話題に上るようになり、この前から作業を再開させつつある。作業内容を思い出すために茶筌のページやIPADIC 2.7.0の説明書などを読み、いくつかの実験をした。そこでわかったことを以下に書いておく。

IPADIC 2.7.0の説明書によれば、辞書の中に「付加情報」という項目が追加できるようになっている。これはChasenから%iで出せるので、必要な語にだけ「@」を付加情報として持たせておけば、手作業の手間がだいぶ軽減できるだろう。

ところが問題があって、付加情報の出力が可能になっているのはChasen 2.3系列である。茶筌がWindowsでも使えるとなって世間の注目を集め、WinChaとしてGUI版が付属するのは2.1系で、こちらは付加情報の出力に対応しない。

実はWindows版にはMinGW環境でコンパイルされた2.3系列のものが存在している。しかしDLLが2.1系のChasen.dllからlibchasen.dllに変わっていて、Google検索してみてもlibchasen.dllはあまり知られていないことがわかる。最も痛いのは、先方がVisual BasicでChasenを呼び出す際に使っているComChaが使えないことだ。

2.1系列では読みや発音の出力は行なえるので、辞書の発音フィールドを基本的に空白にしておき、必要な部分にだけ「@」を使用してはどうかと考えた。実際にやってみると、空白にすると自動的にカナで埋められるようになっていて、失敗に帰した。次に、発音部分に分かち書きの区切り記号「/」を入れて、必要な部分を「@/」とすると、これは当然ながらうまくいった。しかしこの場合には連結品詞の処理ができなくなってしまう。さて、どうしたものだろうか。

2004/11/11
Acrobatを別プロセスで起動してSDIっぽくする

前にも述べたMDI(Multiple-Document Interface)とSDI(Single-Document Interface)の話。私は根っからのSDI派で、SDIを推奨するマイクロソフトに同意する。もっともMDIのほうが好きという人もいるようで、Microsoft Word 2000からSDIが採用されたものの、2002からは両者が選択できるようになっている。

AdobeのWindows製品は、文書のインターフェイスとして基本的にMDIを採用している。PhotoshopやIllustratorあたりでは許せるのだが、AcrobatをPDFビューアーと使うときにはSDIにしたい。こちらがPDFファイルを閲覧するときには、ほとんどブラウザー同様に使っているからだ。これは私の夢想だけれども、IEコンポーネントを使用したタブブラウザーのように、Acrobatのブラウザー用プラグインを使用したSDIのPDFビューアーは作成できないものだろうか。

夢はさておき現状できることと言えば、Acrobatを別プロセスで起動させるようにすることだろう。最近見つけたAcrobat Developers FAQ(PDF)を読むと、そのためのコマンドラインオプションは「/n」であるという。ExplorerでPDFファイルをダブルクリックしたときに「/n」を自動的に反映させるには、下のように変更を加えればよい。(Windows 2000、Acrobat 4.0の場合。)

(1)Explorerのメニューから〈ツール〉-〈フォルダ オプション...〉を選択。
(2)〈ファイルタイプ〉タブを選び、登録されている拡張子PDFを出し(PDFとタイプすればよい)、〈詳細設定〉ボタンを押す。
(3)「アクション」の中の「open」を選び、〈編集...〉ボタンを押す。
(4)「DDEを使う」のチェックを外し、「アクションを実行するアプリケーション」のアプリケーション名のあとに「/n」と入力する。(画面写真参照。)

注意。(4)で、デスクトップ機に入れているAcrobat 5.05は、「DDEを使う」のチェックは最初から入っていなかった。6.0はインストールしていないのでわからない。また、私が使用しているWZ Editor用マクロpHackTeXはMDIを前提としているから、DDEメッセージのCloseAllDocs()をAppExit()に変更する必要がある。


2004/11/8
長寿と繁栄の関係

長寿と繁栄を(Live Long and Prosper)――とはスタートレックでのバルカン人の挨拶である。ところが個人ではなく種族として考えた場合、長寿する種族が必ずしも繁栄するわけではない。鈴木英治『植物はなぜ5000年も生きるのか』(講談社ブルーバックス、2002年)は、そのあたりの事情を説明してくれる書籍だ。

副題に「寿命からみた動物と植物のちがい」とあるように、同書では動物の寿命についても触れられている。しかし著者の本職は植物生態学であり、話も植物――特に樹木(草本ではなく)についてのほうがずっと専門的でおもしろい。以下では植物に的を絞って話を進めることにしよう。

植物進化の系統樹を思い出すと、ラン藻類からはじまってコケ植物・シダ植物・種子植物とつづき、種子植物は裸子植物と被子植物とに分かれ、さらに被子植物が単子葉類と双子葉類とに分かれている。その双子葉類は離弁花類と合弁花類に分かれる。基本的に、被子植物は裸子植物よりも「進化している」と教わる。

ところが個体の寿命について見てみると、被子植物である広葉樹は長くて数百年というところで、1000年を超えるものはない。その一方で裸子植物である針葉樹の中には、スギやヒノキ・マツなど数千年生きつづける種がある。被子植物の中で見ると、進化した合弁花類の樹木はツツジやモクセイといったところで、これらは巨木にならない。それに被子植物はほとんどが草本である。つまり基本的に、植物は寿命が短くなる方向で進化しているのだ。

被子植物が生まれたのは白亜紀以前と見られるが、爆発的な増加を見たのは新生代以降である。これには大規模な気候変動――寒冷化が関わっている。寒冷化は、「中生代には存在していなかったヒマラヤ、ヨーロッパやアルプス、南極などの造山活動」が一因であるという。山の出現によって赤道から北極への熱の移動が妨げられ、また降り積もった雪は太陽光線を反射するため熱エネルギーに変換されにくくなる。そうした厳しい環境で個体が越冬するよりも、短命のかわりに成長を早めて子孫をたくさん残す道が選ばれたのだろう。

上では寿命と書いたが、植物は老衰で死ぬわけではない。植物はたとえ数千年生きていても生殖能力が衰えることはないし、生きているかぎり成長をつづける。「成長に限りがあるものは、寿命にも限りがある」のだ。また植物は挿し木によって殖えることからわかるとおり、組織分化が動物よりもかなり遅い。また動物とちがって、同じ場所の細胞が入れ替わるということはない。植物組織の中で有限の寿命をもつのは葉だが、これもすべて違う場所から生えるようになっている。キツツキに穴を空けられたからといって、穴が修復されるわけでもない。いうなれば植物は、いったん分裂して成長した細胞は放ったらかしにしておき、根と茎との先端だけを際限なく分裂させている。

その植物にとっての大敵は、菌類・細菌類である。もともと細胞壁の主成分であるセルロースやリグニンは分解されにくい。さらに木材では、放射組織と呼ばれる組織から防御物質が出され、中心部が堅い心材へと変化するようになっている。また、現在でも原因不明だが針葉樹のリグニンは腐りにくく、かつ含有量が広葉樹よりも多いという。もうひとつ、針葉樹と広葉樹との違いで仮道管・道管の効率性・安定性の話題(pp.183--185)がおもしろいのだが、図がないと説明しづらいので割愛する。

ところで、この本を読んで積年の疑問が解けた。それは師管という名前だ。維管束は水を運ぶ道管と糖類を運ぶ師管とで構成されている。このうち道管の由来はすぐにわかるのだが、師管をなぜそういうのかは謎だった。同書によれば、「隣同士の篩管細胞の原形質がじかに接するように、細胞壁に小さな穴がたくさん開いており、それが篩(ふるい)のようだというので命名され」たそうである。それが漢字制限の影響で師管になったのだという。

2004/11/4
Acrobatで自動生成されるフォームで日本語フォントを使う

Acrobatは5.0からJavaScriptが強化されており、なかなかおもしろい。フォームの自動生成といった機能はAcrobat 4.0では使えないが、その機能を使って作られたフォームを表示することは4.0でも可能だ。

ところで先日から探しつづけていたのは、フォームに日本語フォントを指定する方法である。『Acrobat JavaScriptガイド』によれば事前登録されているフォントは基本17書体で、日本語フォントはない。PostScript名で指定すれば任意のフォントが利用できるとあるのだが、はたして日本語フォントに対応しているのか、エンコーディングはどう指定するのか判然としない。もしやと思ってアドビのサイトに情報がないか探してみた。JavaScriptガイドの日本語訳(PDF)があったのは思わぬ収穫だが、肝心の情報は見つからなかった。

Acrobat 6.0はインストールしていないのでわからないが、5.0の段階では日本語フォント関係の設定にチグハグな部分がある。たとえばWebキャプチャーでPDFファイルを生成すると、本文書体には平成明朝が指定されている。しかし、Acrobat 5.0からはOpenTypeフォントの小塚書体が付属するようになったので、平成書体は存在しない。フォームも同様で、メニューからフォントを指定するときにはPostScript系の書体としては平成書体しか選べないのに、平成書体のPostScript名を入力しても自動生成が行なえない。

きょうになってようやく閃いて、フォント指定に「KozMinPro-Regular-Acro」としてみた。これが正解で、日本語フォントを指定したフォームが生成できた。その後の実験で、Resource/CIDFont/AdobeFnt.lstに登録されているフォントならば指定できることがわかった。平成書体もリュウミン・中ゴも登録されていないから、生成に失敗していた次第だ。

ところがまた問題が発生した。いましがた指定した小塚明朝は、エンコーディングが「90msp」、つまりプロポーショナル書体になっている。このファイルをAcrobat 4.0環境で開くとMS P明朝で代替されてしまう。これはまずい。小塚明朝が埋め込めればいいのだが、その方法はなさそうである。せめてエンコーディングを変更できないものか。

私は、少しトリッキーな方法を使って凌いでいる。(1)エンコーディングが「90ms」となるPSフォントを探す。私が確認したのはAcrobat 4.0付属の「HeiseiMin-W3-AcroSub」である。(3.0付属の「HeiseiMin-W3-Acro」はダメ。)(2)これをResource/CIDFont/に入れてAcrobat 5.0を起動し、AdobeFnt.lstを更新させる。次にAdobeFnt.lstを開いて、「HeiseiMin-W3-AcroSub」の項目を複製し、名前を「Ryumin-Light」「GothicBBB-Medium」に変更する。AdobeFnt.lstは「読み取り専用」としたほうが安全だろう。(3)フォント名をRyumin-Lightとしてフォームを自動生成する。

注意すべきは、この段階では日本語フォントが空白になっているように見えることだ。というのはAcroSubというフォントは名前のとおり差分フォントで外字データしかもっていないからである。そこで、(4)先のAdobeFnt.lstを消すなりリネームする。これで確認すると、フォームにRyumin-Lightが使われているのが確認できるだろう。エンコーディングも90msとなっているので、PSプリンターでも(90msをもっているかぎりは)正しく出力される。

この方法はまったくスマートでないので、そのうちAcrobatでエンコーディングが指定できるようになることを期待したい。