JAGAT（日本印刷技術協会）が主催する「紙面制作の自動化とページデザイン」のセミナーに参加してきた。PCJapan用語辞典のワークフロー作りをお手伝いしたということで、無理を言ってタダで（←ここ重要（笑））聴講させてもらったのだ。
このワークフローについて簡単に述べておこう。ハッカー用語辞典2004まではMac OS 9＋QuarkXPressの環境だったが、PCJapan用語辞典2005からはDTPプロダクションのビーワークスと話し合ってInDesignを使ってもらうことにした。私の立場からの理由は2つ。XMLとUnicodeである。
PCJapan用語辞典の制作ではデジタル版（WindowsのHTML Help形式）を作るためにDTPデータを再利用したい。そのために、XMLでデータをやり取りできれば作業がスムーズに行くと考えた。
PC雑誌『PCJapan』の毎年恒例付録がPCJapan用語辞典。2005年版は432ページの大ボリュームなのである。
これをパソコン上で使えるようにしたのが「PCJapan用語辞典2005デジタル版」で、このソフトを含む「PCJapan Special CD-ROM2005」がPCJapanの年間定期購読者にはもれなくプレゼントされる（市販もあり（価格は税込み2,000円））。
私は紙版の編集と、デジタル版の制作作業を担当している。自分で作っておいていうのも何だが、このPCJapan用語辞典2005デジタル版はなかなか重宝する。ローカルのパソコン上で使うものだから動作も軽快だし、Windows標準のHTML Help形式なので余計なソフトもインストールされない。さらに、説明文内の用語にはリンクが貼ってあるため、用語間を1クリックでジャンプできてこれがとても快適なのだ。
PCJapan Special CD-ROM2005には、PCJapan全目次データもHTML Help形式で収録されている。PC関連のマニアックな情報に興味がある人はぜひ使っていただきたい。
書籍や雑誌などでWebページを紹介する時、URLが正しいかチェックするのが実に実に面倒くさい。
しかし、Acrobat7.0（およびAdobe Reader）でPDFを開くと、URLの部分をクリックするだけでそのページにジャンプする！（Webページのように最初からリンクが埋め込まれているものでなくても） 今、はじめて気付いた。これって、今までのバージョンにもあったのだろうか？ だったらこれに気付かなかった私は大馬鹿野郎だ。
画面上だけで校正するのは現実的に不可能だから、結局は校正紙に赤を入れることになるのだけど、URLのチェックだけでもスムーズにできるようになったのはものすごくうれしい。アドビ、グッジョブ。
ここ最近のジャストシステム関連の話題といえば、松下電器産業がジャストシステムを自社の特許を侵害しているとして提訴していた裁判。これに関しては、完全にジャストシステムの肩を持ちたいな。マイクロソフトの「TABキーでリンクを見付ける手法」とか、もういい加減にしろと思うような特許ばかりで頭痛がしてくる。こんなことをいっていたら、どんなソフトウェアも作れなくなってしまう。Rubyの開発者まつもとさんも強く非難しているけど、こういう特許は無効にしないとソフトウェア産業全体のクビを締めるんじゃないかなあ。
話は変わり、ジャストシステムから校正支援ツールの「Just Right! /R.2」が3月11日に発売される。
ここのところ、Excelを使った作業がやたら多い。その中で、けっこう面倒くさい作業が表の比較だ。例えば、以前に作った表データを元に、新しい表データを作った場合。新しい表データに含まれる項目の一部を古い表に書き戻したくなったとする。
この時、新旧の表で行の順番が入れ替わっていなければ問題はない。ところが、住所録のようなデータであれば新しく連絡先を追加しているかもしれないし、データを並べ替えているかもしれない。新しい表と古い表で、データの順番が同じになっているかチェックする必要があるわけだ。
Excel 2003では、「ウィンドウ」メニュー→「?と並べて比較」という機能が付いたが、これは2つの表データのスクロールを同期してくれるだけ。チェックは自分が見てやらなければならないのだ。
せっかくコンピュータを使っているのに、これではあまりにも馬鹿馬鹿しい。そこで、比較をExcelにやらせることにする。
仕事によっては、Unicodeのテキストファイルを積極的に利用していこうといろいろ試している。JISコード（正確にはJIS X 0208）にない文字も、OSやアプリケーションを問わずにやり取りできて便利だろうと思うからだ。
例えば、私は用語辞典の仕事をしており、紙とデジタルで同じデータを活用できると仕事が楽になる。ところが、丸数字（「?」など。カギ括弧内は環境によっては見えないかも）1つ取っても厄介だ。今までDTPオペレータにシフトJISで原稿データを渡していたが、Windowsの文字コード（シフトJISを拡張したCP932）とMacでは丸数字のコードも異なる。気の利いたDTPオペレータなら、Windows機種（プラットフォーム）依存文字の自動変換処理くらいはしてくれるから、紙に印刷する分には問題にはならない。ところが、一度DTPソフトに流し込んだテキストを抜き出して、再利用しようとするとこうした文字コードの違いが問題になってくる。そこで、Unicodeで文字コードを統一できれば、データの再利用がしやすくなるはずだ。
最近、一部の仕事では、テキストの文字コードをUnicodeにしていこうかと考えている。DTP作業と密接に連携する必要のある仕事では、Unicodeをベースにすれば、扱える文字種が増え、なおかつ特殊な記号を別途DTPオペレーターに指示する必要がない。例えば、改行マークを入れたい場合、今までの（シフトJISベースの）ワークフローではテキストデータ中にオペレーターがわかるように指示を入れたり、打ち出した紙に指示を書き込んでおくといった手間がかかった。Unicodeが扱える環境なら、「?」（U+21B5）をそのままテキストデータに書き込んでおけばいい（カギ括弧内は改行マーク。フォント環境によっては画面上で見えないかも）。マークの書体に凝りたいといった場合にはやはり別途指示する必要はあるだろうが。
DTPソフトではInDesignのUnicode対応が進んでおり、Mac／Winが混在したワークフローでも何とかなりそうな気がする。
現在試行錯誤中なのだが、1つ気になったのは既存のテキストデータを利用する場合だ。シフトJIS形式で書かれたテキストデータをUnicode（のUTF-8形式）に変換する場合、OSやアプリケーションによって変換結果が異なることがあるようだ。例えば、丸数字（「?」など）。WindowsではJISコード（JIS X 0208）を独自に拡張して丸数字等を割り当てている。こうした文字を使ったシフトJISのテキストを、Windowsのメモ帳でUTF-8形式で保存すると、該当するUnicodeのコードに変換される。しかし、Mac OS Xのテキストエディットで元のシフトJISテキストを読み込み（Mac用フォントの該当コードは丸数字でないため表示されない）、UTF-8形式で保存してもWindowsのメモ帳とは同じ結果にならないのだ（文字化けしてしまう）。Mac OS X（というよりWindows以外のOS）では、Windows独自拡張文字に対応していないから、ある意味当然といえば当然なのかもしれないが……。機種依存文字を使った文書をUnicodeに変換する際には、注意する必要がありそうだ。
（補足）
このbinWord/blogは、UTF-8形式になっている。上記の文章中、改行マークや丸数字を使っているが、これはUnicodeで定義されているもの。WindowsXP等のMSゴシック・MS明朝、Mac OS Xのヒラギノフォントであれば問題なく閲覧できるはず。
（追記）
変換の相違についてまとめたページを発見。
・シフトJISからUnicodeへの変換テーブルの相違
前回述べた、ExcelファイルからPukiWikiのページを生成するRubyスクリプトを作成してみた。
まず、以下のようなExcelファイルを用意する（1行目が項目名、2行目以降がデータ）。
| 製品名 | メーカー | 価格 | 備考 |
|---|---|---|---|
| 製品A | アルファ | 5000円 | 品切れ |
| 製品B | ベータ | 10000円 | 取り寄せ |
| 製品C | ガンマ | 8000円 | 絶版 |
（※セル内で改行があってもかまわない。）
次にスクリプト末尾にあるテンプレート部分を自由に書き換える。Excelデータで置き換えたい部分は、「%項目名%」のように、前後を”%”で囲む。
コマンドプロンプトから、「ruby xls2wiki.rb Excelファイル名 出力先ディレクトリ名」と入力。
指定したディレクトリにWiki用のテキストファイルが生成されるので、これをPukiWiki用のWikiディレクトリにFTPでアップする。PukiWikiにアクセスすれば、「製品A」「製品B」「製品C」というページができているのがわかるはずだ。
適当に作ったもので、エラー処理などもろくに行っていないし、使い勝手もよくない。興味がある方は、自己責任でどうぞ。
現在、いくつかの仕事でWikiを使っている。アイデアを出し合ったり、議論をするには非常に便利なツールだ。
ただ、新しいコンテンツを作っていくには適しているが、既存コンテンツの再利用という点が弱いように思う。Excelなどのデータから、各レコードごとのページを新規に作成できるといろいろと役に立つのではないか。
ざっと探したところ、こういうプラグインが見あたらなかったので、自分で作ることにした。たいていのWikiでは、ページの実体はプレーンテキストとしてデータフォルダに置かれている。データフォルダに適切なテキストファイルを放り込めば、それだけで新しいページになる（こういう使い方が正しいのかよくわからない）。
ということは、編集作業で利用しているRubyスクリプトをちょっと書き換えれば、そのまま使えそうだ。ふむ。暇を見て作ってみよう。
