まずIllustratorのオブジェクト構造がどうなっているのかさっぱりわけがわからないし、テキスト枠を作成するだけでも手順がやたら面倒。さらに、枠内にテキストが収まらない状態（文字あふれ）になった時、自動的に枠のサイズを変えることが、これまた難しい。手作業で行う時は、テキストフレームをドラッグ＆ドロップするだけなのだが、AppleScriptからテキストフレームの高さを変えると、文字まで引き延ばされてしまう！
文字あふれの判定を行って、テキストフレームを作り直すという手も考えたが、私の手には負えない感じになってきたので断念。

で、代わりに「OmniGraffle」（日本語名は「オムニグラフ」だけど、それだと棒グラフなんかを描くソフトだと誤解されないのかね？）を使ってみたら、問題があっという間に解決した。オブジェクトの階層構造がすっきりしていて、AppleScriptに詳しくない私にもわかりやすい。これなら何とかなりそうだと思って、作業を進めている時、すごい機能を発見。
カンバスに描いた図形を右クリックして、「別形式でコピー」→「AppleScript」を選ぶと、その図形を描くためのAppleScriptのコードがクリップボードに出力されるのだ！　例に示した図だと、以下のようなコードになる。

tell application "OmniGraffle Professional"
tell canvas of front window
make new shape at end of graphics¬
with properties {stroke color: {1.000000, 0.000000, 0.000000},¬
thickness: 3, fill: no fill, origin: {112.000000, 105.000000},¬
size: {130.000000, 77.000000},¬
text: {text: "テスト図形", font: "HiraKakuProN-W3",¬
text: "テスト図形", alignment: center}}
end tell
end tell

これはすごい。どのプロパティをいじったらどうなるか、実際の図形を描きながら確かめていけるのだ。さすが、NeXTSTEPの時代からアプリを開発しているOmni Groupだけのことはありますな。

・さらに仕事に使うRuby（後藤 謙太郎氏（ごとけん））
プロジェクト管理ツールのRedmineが便利そう。

・日本Rubyのリファレンスマニュアル2008・初夏（青木峰郎氏）
執筆支援システム「ReVIEW」。ReVIEWフォーマットでドキュメントを書くと、HTMLやLaTeXの形式で出力できる。InDesignのXMLで出力することも可能。単純なレイアウトの書籍なら、制作効率を大幅に上げられそう。ぜひ試してみたい。

・The future of Ruby in Mac OS X（Laurent Sansonetti氏）
現在のMac OS X v10.5 Leopardには、RubyCocoaが搭載されていて、Cocoaフレームワークを活用してMac OS Xを開発できる。ブログエディタのblogoやIRCクライアントのLimeChatは、RubyCocoaで開発されているそうだ。しかし、RubyCocoaでは、プロキシオブジェクトを作成してCocoaフレームワークを呼び出しているので、メモリの利用効率が悪く、速度が遅いという欠点がある（らしいですがよくわかりません。詳しくはこちら）。
Laurent Sansonetti氏（Apple社員！）が開発しているMacRubyは、Objective-Cで実装したRuby（1.9準拠）。プロキシクラスを作成しないため、パフォーマンスが圧倒的によくなる（アプリケーションによっては10倍速くなるとか）。
現在のバージョンは0.2。今年の終わりには0.3が出て、RubyCocoa互換のモードも搭載。MacRubyでアプリケーションを書くためには、結局CocoaフレームワークとObjective-Cに通じている必要がある（RubyCocoaも）。しかし、Sansonetti氏らが一晩で作ったという「hotcocoa.rb」というモジュールを使うと、ものすごく簡単にCocoaアプリケーションが作れるみたいだ。デモを見ていて「もしかして、これなら私にもCocoaアプリケーションが作れるかも！」と思ってしまったくらい。0.3以降では、AppleScriptと同等のアプリケーション制御もできるようになるそうな。Mac OS Xにはいつかわからないが、MacRubyが搭載される予定という。iPhoneへの搭載は難しいとのこと。

「章」「節」という単位で企画内容を書き出していくのは、どのアウトラインプロセッサでも同じ。しかし、OmniOutlinerの場合はそれぞれの項目にページ数を割り振り、その合計をリアルタイムに表示できるのだ。しかも、全体、章、節といったレベルごとに。もちろんExcelなどの表計算ソフトを使えばページ数の合計を計算できるが、階層構造を扱うのが面倒になる。OmniOutlinerなら「この企画はもうちょっとボリュームを増やそう」といった判断がスムーズにできるのだ。
操作は簡単で、「列を追加」ボタンをクリックして、新しい列を追加する。そしてインスペクタの「列の種類」で、「種類」を「数値」、「要約」を「合計」、「書式」を「10000」にする。
書籍の企画だけでなく、ボリュームのあるプレゼン資料を作る時にも重宝するはず。

あらためてInDesignのフォルダを調べてみると「LabelGraphicMenu」というスクリプトが入っている！

InDesign CS3のスクリプトパネルから「LabelGraphicMenu」を実行すると、このスクリプトがコンテキストメニューに組み込まれる。画像（複数でもOK）を選択して右クリック、コンテキストメニューから「Label Graphic」を選ぶと、ダイアログが現れるので段落スタイルなどを指定して「OK」をクリック。これで画像ファイルの下（オフセットを指定すると画像の上でも可）にテキストボックスが作られてファイル名が表示される。

アプリケーションのおまけはちゃんとチェックしておかないと損をするなあ。

そこで、正規表現とExcelを使うことにする。

例えば、索引のテキストデータが、次のような形式になっているとする。この場合は上下巻で、項目名とノンブルの間はタブで区切られている。

項目名1　上○○○,○○○,下○○○
項目名2　下○○○,○○○
・
・
・

まず、Excelで処理できるよう、ノンブルの区切りをすべてタブに置換する（本当は最初から索引がExcelで作ってあるとよいのだけど）。テキストエディタ上で正規表現の使える置換機能を呼び出し、「\t.+([0-9]),([0-9])」→「\1\t\2」と指定する（正規表現はエディタによって微妙に違うので注意）。これによって、（タブのあとにある）数字ではさまれたカンマがタブに置き換わった。例では「上」や「下」といった文字が付く数字もあるので、それらも「上　タブ　数字」などとなるよう処理しておく。
こうやって処理したテキストデータをExcelに読み込む。そうしたら、新しいシートを作り、そこに項目名の行をコピーする。
ノンブルについては、すべて「2」を足したい。そのため、新しいシートの対応セル（例えばA3セル）には「=IF(Sheet1!A3=”",”",Sheet1!A3+2)」と入力する。これは、Sheet1のA3セルが空なら、このシートのA3セルも空、空でないなら2を足した値を入れる」という意味だ。入力したセルの右隅をドラッグして範囲を広げれば、すべてのセルに同じ式を簡単に入力できる（参照するセルもきちんと対応したものになる）。
「上」「下」と入っている部分は数値でないためエラーになるが、これについてはExcelの検索・置換機能で修正してしまえばいい。いろいろテクニックを使えばこの辺りもスマートに解決できるのだが、とりあえずはスピード優先だ。
こうして出来上がった表をコピーして、再度テキストエディタに貼り付ける。そして最初に行った処理の逆、つまり数字と数字の間をカンマにするといった処理を行えばいい。なお、例は上下巻とも2ページ足しているが、増やすページが上下で違うとちょっとややこしいことにはなる（上下巻それぞれの索引を作って、あとでマージすることになるだろう）。
あとは、できた索引のテキストデータを入稿すると……。いや、以上はあくまでも仮の話だけど。

このワークフローについて簡単に述べておこう。ハッカー用語辞典2004まではMac OS 9＋QuarkXPressの環境だったが、PCJapan用語辞典2005からはDTPプロダクションのビーワークスと話し合ってInDesignを使ってもらうことにした。私の立場からの理由は2つ。XMLとUnicodeである。
PCJapan用語辞典の制作ではデジタル版（WindowsのHTML Help形式）を作るためにDTPデータを再利用したい。そのために、XMLでデータをやり取りできれば作業がスムーズに行くと考えた。

ライターから集まってきた原稿は私が編集して、Excelデータとしてビーワークスに渡す。ビーワークスはExcelからXMLデータを書き出し、それを同社独自開発のスクリプトを使ってInDesign用XMLに変換、InDesignに読み込む。この時点で見出しには見出しの、本文には本文のスタイルが適用されている。テキストを選択してスタイルを手動で適用する必要がないため、ビーワークスでの組版作業の手間は半分以下になったという。
用語辞典のデジタル版を作る際は、ビーワークスがInDesignからXMLを書き出し、私がExcelに読み込む。見出しや本文、関連用語など項目別にきちんと分かれて読み込まれるから、実に再利用しやすい。文字コードをUnicodeに統一することで、WindowsやMacの機種依存文字に悩まされることもない。

データの再利用を考えて、いくつか注意している点もある。例えば、上付文字、下付文字はDTPソフト側の機能を使うのではなく、（テキストデータの段階から）Unicodeに用意されている文字で表現するようにする。特殊なフォントを使う記号はできる限り避ける。（DTPソフト上で）字詰めを調整するためにスペースや改行を入れるのは避ける、等々。こうしておくことで、紙の用語辞典と同じテキストデータを可能な限り再利用できる。
まあ、現時点でHTML Helpを作るためのオーサリングツールがUTF-8に対応していないため、結局Unicodeにしかない記号は手作業で置き換えているのだけど。

DTPの話からちょっと外れるが、編集でのExcel利用について。テキストデータをExcelデータで渡すということに、抵抗を感じる人もいるかもしれない。テキストの編集作業にExcelなんか使えないだろうと。
もちろん、文章をガリガリ入力・編集するのにExcelではまったく力不足だ。テキスト編集にはテキストエディタ（ワープロでもいいが）を使う。この時、見出しは行頭に「■」を付けるとか、自分なりのルールを作ってそれをきっちり守るのがミソ。このように規則性のあるテキストデータは、PerlやRubyなどのスクリプト言語を使って簡単に処理できる（HTMLなどのマークアップ言語を使う手もあるが、テキスト編集作業が面倒になるために自分ルールでやっている）。私の場合は、RubyからActiveXオートメーションでExcelをコントロールし、テキストファイルからExcelシートを生成するようにしている。Excelデータになると、読み順に並べ替えたりといった処理もすばやく行える。また、独自スクリプトを使って、この時点で関連用語の飛び先チェックも行うようにしている。いったんExcelデータになったデータを再度テキストエディタで編集したくなったら、先ほどと逆の処理を行うスクリプトでテキストデータを吐き出せばいい。同一データを相互変換できるわけではないが、テキストエディタとExcelの間でコピー＆ペーストするのに比べたら雲泥の差だ。そうそう、ExcelはUnicodeにもきっちり対応している。

自動組版というと、大がかりなデータベースを構築するようなイメージがある。カタログなどを作る場合は確かにそういうソリューションも必要だが（ビーワークスや他社もそういう事例を数多く発表している）、テキストを流し込むタイプの自動組版なら、InDesignとExcelを組み合わせるだけでもかなり効率化できる。ビーワークスでは、ハシラ（欄外に入れる章タイトルや見出しなど）を入れるプラグインも開発してさらにDTP作業の効率を上げているそうだ。

その他の自動組版ソリューションで興味を引かれたのが、フレイマーグループの事例。同社の組版システム「WAVE」は何とCADソフトのAutoCAD上に構築されている。自動組版を行う際も、CADソフトならではの細かい指定が行えるのだそうだ。
当然のことながら、素のAutoCADできっちりとした組版ができるわけではなく、あくまで同社が開発したWAVEがあってのソリューション。それにしても意外なソフトがDTPで活躍しているものだ。

デジタル版の制作では、Ruby用の自作スクリプトでリンクの作成やチェックをしている。さすがに完全自動とはいかないが、これで大幅に作業が効率化できた。
また、2005年版の紙バージョンからは、DTPプロダクションに頼んでInDesignを組版に使うようにしてもらった。InDesignはXMLの取り扱いが手軽なので、紙版→デジタル版の制作ワークフローを効率化できるのではないかと思ったのだ。まあ、今回に関しては完璧とはいかなかったけど、かなり「イケル！」という感触はつかめた。ワンソース・マルチユースということで、いろいろなジャンルで応用が利きそうだ。

民明書房大全には、見たこともない漢字がバンバン出てくる。例えば、私の大好きなネタ、李筴振（りばしぶる）が創始した凶獬面閶殺（きょうかいめんしょうさつ）。ネタの内容については同書を見てもらうとして、「獬」（かい）も「閶」（しょう）もJISコード（JIS X 0208）の第一水準、第二水準に含まれていない。ただし、Unicodeには収録されているので、Windows XPやMac OS Xなら問題なく扱えるし、このブログのようにUTF-8で書かれたWebページでも使える。男塾のファンサイトを運営するなら、UTF-8ベースじゃないときついかもしれない。
それにしても、民明書房大全の校正は大変だったんじゃないかな。やっぱり、DTPにはInDesignを使ったんだろうか。