binWord/blog » XML

Leopardの「辞書」アプリで「ランダムハウス英語辞典」を使う

Tats_y — Sun, 11 May 2008 12:34:24 +0000

Leopardの辞書アプリ（Dictionary.app）で英辞郎を使えるようにしたおかげで、海外のサイトを読むのもずいぶん楽になった。しかし、単語の意味などをもう少し詳しく知りたいという時は、英辞郎だとちと物足りない。そこで、だいぶ前に買ったまま、ほとんど活用していなかったランダムハウス英語辞典（第二版）をDictionary.app用に変換してみることにする。
ランダムハウス英語辞典が使えるMac用の辞書ソフトとしては、すでにJammingがあるが、できればDictionary.appにまとめたいところ。検索機能はJammingが格段に優れているが、日常的にさっと調べるならDictionary.appの方が使いやすく感じる。まあ、変換処理自体が面白くなってきたというのもあるのだけど。

○Windows上で辞書データを吸い出す
ランダムハウス英語辞典のデータは独自形式になっていて、私ではとても手に負えない。そこで、太田純氏が作成されたランダムハウス英語辞典Toolkitを使わせていただいた。これは、ランダムハウス英語辞典のデータをHTMLに変換するWindows用のツール。当然、利用するにはWindows（Parallels Desktop for Macなどの仮想環境でもOK）が必要になる。ランダムハウス英語辞典Toolkitでは、srd2html.iniというファイルで設定を行うが、私は以下の内容にした。

BASEPATH = c:\srdtmp\
OUTPATH = c:\srd\
DICPATH = c:\Program Files\小学館\ランダムハウス英語辞典\
DATAPATH = c:\Program Files\小学館\ランダムハウス英語辞典\
SORTCMD = c:\Windows\System32\sort.exe
MACINTOSH = 0
FIGURE = 1
JPEG = 1
SOUND = 0
GENSOUND = 0
COMPLEX = 0
QUICKJUMP = 0
QJITEMS = 3
QJLINES = 30
QUICKRET = 1
ITALIC = 0
PRONSYM = SPEAKER
JUMPSYM = BIPOD
ARROWSYM = JUMP
RETSYM = RETURN

これで、srd2html.exeを実行すればsrd.htmlが生成される。また、figフォルダにはBMPの画像ファイルがコピーされるので、これを適当なツールでJPEG形式に変換しておく。

○生成されたHTMLを修正する
私の手元にあるランダムハウス英語辞典は、どうもデータにバグがあるようで、そのままではエラーが出てしまう。そこで、適当なテキストエディタを使ってsrd.htmlを修正する。修正内容は以下の通り。

・Avalementの項目の文字化け
Avalementの項目（ID=”1190300″)に文字化けがある。「屈曲によってスキーが」という文章に修正。
・adsuki beanの重複
adsuki beanという項目が重複している。ID=”224900″の方は文章量の少ない項目（ID=”239400″を参照している方）を残し、ID=”239400″の方は文章量の多い項目を残す。
・その他の重複項目
その他にもいくつかの重複項目がある。
IDを列挙すると、
353200, 393700, 1076900, 1077000, 1077100, 1121500, 1225000, 1396900, 1885200, 1904900, 1914600, 2088900, 2101900, 2106100, 2108500, 2365200, 2452600, 2536200, 2536600, 2717300, 3121300, 3167800, 3265100, 4445800, 5760300, 5861700, 5873700, 5959500, 6897700, 6907700, 7160400, 7193700, 7194400, 7286000, 7298600, 7625900, 7679100, 7696200, 7789200, 7792900, 8064000, 8211700, 8229600, 8257300, 8501900, 9015400, 9047000, 9051400, 9199600, 9318000, 9327700, 9336700, 9338000, 9338700, 9350700, 9351200, 9351400, 9370200, 9443000, 9466600, 9549300, 9553900, 9746700, 10118300, 10661800, 10781200, 11034200, 11085300, 11321500, 11414300, 11414400, 11582200, 11600800, 11608200, 11853900, 11854400, 11856600, 11858300, 11858400, 11858500, 11860000, 12068100, 12214700, 12216400, 12585600, 12596500, 12596600, 13562000, 14796100, 14821200, 15057600, 15098200, 15157400, 15163100, 15205800, 15243200, 15251400, 15288700, 15560100, 15654900, 15841300, 15841400, 15848500, 15877300, 15877400, 16102800, 16110300, 16125800, 16402500, 16403100, 16465100, 16465200, 16465300, 16465400, 16465500, 16465800, 16466000, 16466100, 16466400, 17115600, 17138800, 17231400, 17435800, 17543200, 17919100, 17928100, 17934200, 17936600, 17936700, 17936800, 17960800, 18293800, 18403900, 18432400, 18440900, 18795400, 19176600, 19441700, 19639100, 19763300, 19789700, 19807900, 19827700, 19852500, 19856600, 19879300, 19879700
……勘弁してください。どうも「kimono」とか「harakiri」など、日本語由来の単語に問題があるようだ。重複しているIDの項目を削除する（実は、同じIDでも内容が微妙に異なる。片方は説明が詳しく、片方は出典が書かれているという具合。気になる人は適宜編集してほしい）。

○Xcodeをインストールする
ここからはMac上での作業になる。
・英辞郎の場合と同じく、Mac OS X用の開発ツール「Xcode」をインストールする（Leopardのインストールディスクの「Optional Installs」→「Xcode Tools」→「XcodeTools.mpkg」を実行）
・「/Developer/Exmaples/Dictionary Development Kit/project_templates」フォルダを適当な場所にコピーする

○変換用のスクリプトを準備・実行
・ここから、変換用のスクリプトをダウンロードして、（コピーした）「project_templates」フォルダに解凍する（同じファイル名は上書き）
・生成したsrd.htmlも、同じく「project_templates」フォルダにコピーする
・画像の含まれる「fig」フォルダは、「project_templates」内の「OtherResources」フォルダにコピーする。
・「ユーティリティ」フォルダの「ターミナル」アプリケーション（Terminal.app）を起動して、「cd」コマンドで（コピーした）「project_templates」フォルダに移動する
・ターミナルで、「ruby srd_conv.rb < srd.html | ruby gaiji_rep.rb srd.lst | ruby ucs4_to_utf8.rb > MyDictionary.xml ; make ; make install」と入力。
・「辞書」アプリケーション（Dictionary.app）を立ち上げると、ランダムハウス英語辞典（SRD）が使えるようになっているはず。

○発音記号もコピー＆ペーストできる
オリジナルのランダムハウス英語辞典では、発音記号などをすべて外字によって表現していた。そのため、説明文を別のアプリケーションにコピーしても、文字化けしてしまう（Jammingを使った場合でも同じ）。
Dictionary.app用に変換したデータでは、これらをUnicodeの文字で表示しているので、見たとおりの状態でコピー＆ペーストできる。この変換テーブル（srd.lst）は、私が近い形を探して作ったので、間違いがあるかも。手書き文字のように、Unicodeではどうしても表現しきれなかったものもいくつかある。

○日本語のキーワードからも引ける
ランダムハウス英語辞典には、日本語の検索インデックスも用意されている。和英辞典ほどではないが、結構便利である。

○変換スクリプトの話
・srd_conv.rbは、srd.htmlをXML形式に変換。
・gaiji_rep.rbは、外字をUnicodeの文字に変換。
・一部の文字が文字実体参照（&#x????という形式で文字を表現する）になっているので、これをucs4_to_utf8.rbで実際の文字に置き換えている。Unicodeのいわゆる文字コード（UCS-4）からUTF-8への変換方法は、『文字コード超研究』を参考にしている。この本は、文字コードの基本知識から具体的な変換方法まで、わかりやすく書かれていてオススメ。

Leopardの「辞書」アプリでEPWING辞書を使う

Tats_y — Tue, 12 Feb 2008 13:55:10 +0000

これまでに、Leopardの「辞書」アプリケーション（Dictionary.app）で英辞郎や郵便番号辞書を使う方法を紹介してきたが、EPWING形式の辞書を使いたいという要望が結構あるようなのでチャレンジしてみた。
ありがたいことに、hishida氏がEPWING構造解析ツール「EBDump」を、太田純氏がEBDumpの出力をHTMLに変換する「ebd2html」を発表されているのでこれらを利用させていただいた。なお、両ソフトともWindows用なので、以下で述べる作業を行うにはWindowsが必要になる（Parallels Desktop for Macなどの仮想環境でもOK）。

○EPWINGのデータをHTMLに変換する
変換に使ったEPWING辞書は、COLLINS COBUILD Resource Pack on CD-ROMをEBStudioでEPWING化したもの。
まず、このEPWING辞書をebd2htmlのページで紹介されている方法でHTMLファイル（COBUILD.htmlとする）に変換する（Windows上での作業になる）。
（ここでEPWING化したCOBUILDを用いているのは、外字の数が少なくて検証が楽だったため。COBUILD→辞書アプリの変換が目的なら、COBUILD変換スクリプトが生成したHTMLをそのまま使えばいいだろう。）

○変換用のスクリプトを準備・実行
・ここから、変換用のスクリプトをダウンロードして、（コピーした）「project_templates」フォルダに解凍する（同じファイル名は上書き）
・EPWINGから取り出したHTMLファイル（COBUILD.html）も、同じく「project_templates」フォルダにコピーする
・「ユーティリティ」フォルダの「ターミナル」アプリケーション（Terminal.app）を起動して、「cd」コマンドで（コピーした）「project_templates」フォルダに移動する
・ターミナルで「ruby epwing_conv.rb < COBUILD.html | ruby gaiji_rep.rb cobuild.lst > MyDictionary.xml ; make ; make install」と入力
・「辞書」アプリケーション（Dictionary.app）を立ち上げると、COBUILDが使えるようになっているはず

○他のEPWING辞書を変換する際のポイント
・日本語の辞書を変換する際は、「epwing_conv.rb」内の「iconv = Iconv.new(‘UTF-8′, ‘Shift_JIS’)」という箇所を変更する（’Shift_JIS’を’ISO-2022-JP’にする）
・EPWINGの辞書で使われている外字を、Unicodeキャラクタに変換するためのテーブルを用意する。COBUILDの場合は、「cobuild.lst」がそれに当たる（広辞苑などでこれを作るのは大変だと思う……）
・ebd2htmlが生成するHTMLでは、最後の近くの項目のタグが閉じられていないことがあるようだ。変換されたHTMLファイルを開いて確認した方がいいだろう
・MakefileやMyInfo.plistの辞書名を変更すること

COBUILDの辞書はうまく変換できたようだが、きっと辞書ごとにうまくいったりいかなかったりするんじゃなかろうか……。

（2008年5月5日追記）
COBUILDにスタイルシートを適用してみた。多少は見やすくなったかも。変換用のスクリプトはここから。使い方は上記説明の通りだが、「ruby cobuild_conv.rb < COBUILD.html | ruby gaiji_rep.rb cobuild.lst > MyDictionary.xml ; make ; make install」と入力する。

Leopardの「辞書」アプリで「英辞郎」を使う

Tats_y — Tue, 06 Nov 2007 05:49:27 +0000

先の記事でも書いたように、Mac OS X v10.5 “Leopard”の「辞書」アプリケーション（辞書.app / Dictionary.app）用の辞書はユーザーが追加できるようになっている。そこで、定番の英和辞書「英辞郎」を変換するツールを作ってみた。英辞郎は、現時点で最新のv108を使用している。

使い方は以下の通り。
・Leopardのインストールディスクに含まれる開発ツールをインストールする（「Optional Installs」→「Xcode Tools」→「XcodeTools.mpkg」を実行）
・「/Developer/Exmaples/Dictionary Development Kit/project_templates」フォルダを適当な場所にコピーする
・コピーした「project_templates」フォルダに、英辞郎の英和辞書データ「EIJI-???.TXT」、略語郎「RYAKU???.TXT」をコピー（英辞郎と略語郎は1つの辞書にした方が使い勝手がよいのでこうしている）。???は英辞郎のバージョンによって異なる
・ここから「eiji_conv???.zip」をダウンロードして解凍し、同じく「project_templates」フォルダにコピーする（同じファイル名は「上書き」）
・「ユーティリティ」フォルダの「ターミナル」アプリケーション（Terminal.app）を起動して、「cd」コマンドで（コピーした）「project_templates」フォルダに移動する
・ターミナルで、「ruby -Ks ryaku_conv.rb < RYAKU???.TXT > Ryaku.txt」と入力（略語郎内のリンクを英辞郎の表記に合わせている）
・「ruby -Ks cat.rb EIJI-???.TXT Ryaku.txt > Eijiro.txt」と入力（英辞郎と略語郎のファイルを連結して「Eijiro.txt」というファイルを生成）
・「ruby eiji_conv.rb < Eijiro.txt > MyDictionary.xml」と入力（2GBのメモリを搭載したMacBook（2GHz）で約20分）
・「make」と入力（同環境で約40分）→（Snow Leopardの辞書ツールでは、生成される辞書のサイズが小さくなる代わりに作成時間が大幅に伸びた。十数〜数十時間を要することがある）
・「make install」と入力
※「ruby eiji_conv.rb < Eijiro.txt > MyDictionary.xml ; make ; make install」と入力すれば、3つの作業をまとめて実行できる
・「辞書」アプリケーションを立ち上げると、英辞郎（Eijiro）が使えるようになっている。なっていない時は、「環境設定…」で英辞郎にチェックを入れる

control＋command＋Dを押しっぱなしにしていると、マウスカーソル近くの単語を自動認識して辞書を引いてくれるのでとても快適だ。

出来上がったデータはけっこう大きくなる（略語郎こみで1.36GB）。
アップルが提供するツールでは、他の項目とリンクしうる本文内の箇所について自動的にインデックスを作成する模様。このインデックスがかなり大きくなっているようだ。リンクさせたい箇所を明示的に指定すれば、インデックスは小さくなるだろう。ただ、自動的に作ってくれるインデックスの方が使い勝手がよいのではないかと思う。

（2007年11月9日追記）
いくつかバグ取りと改良を行った。
○v0.01→v0.02の変更点
・品詞が間違って付けられることがあったのを修正
・＜→単語＞という形式で飛び先が明示されているものにはリンクを張った
・URLをクリックすると、該当ページにジャンプするようにした
※URLの判別ルーチンは、『Ruby Magic―Rubyで極める正規表現』を参考にしている。

（2007年11月12日追記）
○v0.02→v0.03の変更点
・空行処理
○v0.03→v0.04の変更点
・スタイルの指定（品詞、定義の順、ルビ、文例）

表示が見づらかったので、スタイルシートで体裁を整える。一部行間隔がおかしいところもあるが（スタイルシートって難しい……）、けっこう見やすくなった。
スタイルシートを変えたい場合は、「~/Library/Dictionaries/Eijiro.dictionary/Contents/DefaultStyle.css」を修正すればOK。スタイルシートの修正だけならば、辞書データを再作成する必要はなく、辞書アプリを再起動するだけでいい。

（2007年11月12日追記（続き））
○v0.04→v0.05の変更点
・品詞名のついていない項目で、スタイル指定が間違っているのを修正
静的なデータを加工するだけなのに、けっこうバグが出る……。これで問題はなくなったと思いたい。

（2007年11月15日追記）
○v0.05→0.06の変更点
・名詞の複数形や動詞の過去形など、変化形でも引けるように改良。
※ただし、熟語になっているものは変化形では引けない。

（2007年11月20日追記）
日本郵便の郵便番号データの変換ツールを公開。詳しくはこちら。

（2007年11月27日追記）
○v0.06→0.07の変更点
・2通りの変化形に対応。例えば、「evil」の比較級は「eviler」と「eviller」があるが、どちらでも引けるようにした。
・リンク先が2つ以上ある場合にも、きちんとジャンプできるようにした。
・辞書名を「Eijiro」から「英辞郎」に変更。

（2008年2月12日追記）
EPWINGの辞書を使えるようにしてみた。詳しくはこちら。

（2009年8月31日追記）
Snow Leopard付属ツールで辞書データを作成すると、Leopard上で作った場合に比べてサイズが2/3になる。ただし、作成時間も延びているので注意。英辞郎＋略語郎のデータを初代MacBookでmakeするのに、22時間を要した。

（2010年5月14日追記）
○v0.07→0.08の変更点
見出しが長すぎる項目があるとエラーが出てしまうことがあった。そこで、見出しが長すぎる（512文字以上）項目はスキップするようにした。

（2011年4月11日追記）
○v0.08→0.09の変更点
・スタイルシートを一部修正（例文前後の空行など）。
・解説文中の読みがなの表示／非表示が選択可能に。これを行うためには、eiji_conv009.zipの「extras」内にある「MyDictionary_prefs.html」と「MyDictionary.xsl」を、（コピー済みの）「project_templates」フォルダ→「OtherResources」フォルダにコピーしてから、辞書の変換作業を実行する。変換作業終了後、辞書.appを立ち上げ、「環境設定」から英辞郎を選択して「読みがな」の設定を行う（読みがなの設定を行わないと、解説文が正常に表示されないことがある）。
※スタイルシート修正および読みがな設定は、滝本さんからの情報を元にしています。どうもありがとうございました。

Mac OS X Leopardの「辞書」アプリ用データは自分で作成できる

Tats_y — Sat, 27 Oct 2007 03:38:44 +0000

Mac OS X 10.5 Leopardに環境を移行した。かなり新機能が盛り込まれているにもかかわらず、これまでのバージョンとまったく違和感なく入り込めるというのは、何気にすごい。最初にLeopardを見た時は、「便利なユーティリティを載せただけなんじゃないの」と思ったが、内部的にもかなり改良されているようだ。例えば、本田雅一の「週刊モバイル通信」でも取り上げられているように、全体的な動作が快適になった。単純に速くなったというより、滑らかになったような印象なのだ。Windows Vistaは、十分なスペックのマシンで動かしていても何だか時々カクカクする感じがあるのだが、Leopardはそういうことがない。

さて、目立つ新機能はその他のメディアにまかせるとして、私にとってうれしい改良の1つが「辞書」アプリの強化だ。これまでの英英辞典に加えて、国語辞典や英和辞典、類語辞典、Wikipediaが追加されている。
さらに、この「辞書」アプリ用の辞書は、自分でも作成できるようだ。

Leopardのインストールディスクに含まれている開発ツールをインストールすると、「/Developer」フォルダから各種ツールやドキュメント類を利用/参照できるようになる。「/Developer/Extras/Dictionary Development Kit/documents」フォルダには、「Dictionary Development Kit.rtf」というドキュメントがあり、ここに辞書アプリ用辞書データの作成方法（XMLのフォーマットなども）が詳しく書かれている。
今後、Leopard用辞書や変換ツールが増えてくることを期待したい。

（2007年11月6日追記）
「英辞郎」の変換ツールを公開。詳しくはこちら。

（2007年11月20日追記）
日本郵便の郵便番号データの変換ツールを公開。詳しくはこちら。

（2008年2月12日追記）
EPWINGの辞書を使えるようにしてみた。詳しくはこちら。

Mac OS X Leopardビュンビュンテクニック (アスペクトムック)

Amazonで詳しく見るby G-Tools

携帯電話でのRSS、Webブラウジングについてあれこれ

Tats_y — Mon, 11 Sep 2006 02:32:58 +0000

前のエントリーでも書いたが、RSSリーダーとしてNetNewsWireとNewsGatorの組み合わせはかなり使いやすい。Mac OS X上では、NetNewsWireでサクサクSpotlight検索もできるし、フィードの整理も楽。未読や既読の状態をNewsGatorにそのまま引き継げるから、携帯電話上で続きを読める（フィードによってはなぜかNewsGator側で読み込まれないものもあるけど）。
ただ、気になった記事を携帯電話から「はてなブックマーク」に登録するのがちょっと面倒。はてなブックマーク登録用のブックマークレットは、私が使っているauのW41CAでも使えることは使える。しかし、ブックマークレットを呼び出すといちいちはてなのIDとパスワードを入力しないといけない（PCサイトビューアを終了するまでは覚えていてくれるが）。要するに、W41CAのPCサイトビューア（Opera）にはパスワードなどの認証管理機能が搭載されていないのだ。W41CAのメモ帳にIDやパスワードを書き込んでおいて、入力画面で呼び出すということをやっているが、これだと使い勝手がイマイチ。しかし、かなり気に入っているW41CAを認証管理機能のためだけに買い換えるのもちょっとなあ……。

あと、パソコンと携帯電話の連携ということで、パソコンのブラウザで開いているページをそのまま携帯電話でも見られると便利なのではないかと考えた。開いているページのURLをすべて取得して、それらをはてなブックマークに登録して「あとで読む」タグを付けておくとよいかなと。簡単なスクリプトでできそうに思えたのだが、これが意外に厄介。Mac OS XのSafariはAppleScriptでコントロールできるようになっているのだが、実はJavaScriptを実行する機能と現在のページのURLを取得する機能ぐらいしかなかったりする。開いているタブやウィンドウの数をAppleScriptで取得して、処理してやればいいだけのはずなんだけど。

NewsGator + NetNewsWireで読むRSSフィード

Tats_y — Wed, 02 Aug 2006 00:56:34 +0000

ここのところしばらくRSSリーダーをほとんど使っていなかった。せいぜい共同作業用Wikiの更新チェックをするくらい。理由はやはり大量の未読エントリ恐怖症。大量のエントリがたまって憂鬱になってしまうのだ。
しかし、特定のトピックを追いかけたりするには、RSSリーダーが便利なことも事実だ。よく読むフィードと読まないフィードを随時整理していけばいいんじゃないかと思い直して、改めてRSSリーダー環境を整備してみることにする。
レンタルサーバーを借りているんだからとFreshReaderをインストールしてみたり、FeedPathでタグを使ってみたりしたのだが、イマイチしっくりこない。どのサービスもかなりよく考えられており、特にソーシャルブックマークの考え方を取り入れたFeedPathのタグはすばらしいのだけど、Webブラウザで使う限りユーザーインターフェイスに制約がある。登録したフィードのカテゴリをあれこれいじって整理しようとした時に、Web上のRSSリーダーだとやりにくい。
じゃあ、アプリケーション型のRSSリーダーにするかというと、複数のパソコンでの未読／既読の同期とか、携帯電話からのアクセスがしにくいということもあって……。
そういや、愛用していたMac用のRSSリーダー「NetNewsWire」がNewsGatorに買収されたのだったなと思って久しぶりに使ってみると、これが実によいのだ。NewsGatorはWeb上のRSSリーダーサービスなのだけど、NetNewsWireやWindowsのOutlook用プラグイン「NewsGator Inbox」、「FeedDemon」と同期できる。登録フィードだけでなく、未読・既読の状態も同期できるのだ。こういうことを行うためには、有償のNewsGator Online Premiumでないといけないのだけど、NetNewsWireのユーザーなら2年間無料で使えるようだ。完全に見逃していたなあ。
NetNewsWire上でフィードの整理も楽にできるし、携帯電話からの閲覧機能も必要最小限とはいえ使い勝手は悪くない（W41CAの場合、EZブラウザではうまく日本語が表示されないが、PCサイトビューアなら問題ない）。AppleScriptを使えば、はてなブックマークへのエントリ追加も楽にできる（Brewed Fresh Dailyで公開されているdel.icio.us投稿スクリプトをちょっと修正すれば、はてなブックマーク用のスクリプトになる。最後から2行目を「open location “http://b.hatena.ne.jp/add?mode=confirm&url=” & u」に変更すればOK）。
しばらくはこの環境でやっていこう。

Office2007のODF対応が示唆するマイクロソフトの戦略転換

Tats_y — Fri, 07 Jul 2006 01:02:36 +0000

マイクロソフトが、Office 2007でのODF対応を発表したというニュース（ITpro）。これからのデータ形式はネット上であれ、ローカルなパソコン上であれ、すべてXMLがベースとなるというのは衆目の一致するところ。しかし、オフィスソフトの文書形式としては、「Open Document Format（ODF）」と、マイクロソフトがOffice2007で標準形式にしようとしている「Open XML Document」が対立している状態だ。
今回のニュースは、Open XML Document形式をODF形式に変換するツールを提供ということであり、Office 2007自体が直接ODFをサポートするわけではないようだ。それでもこのニュースは、マイクロソフトの持つ危機感を表しているようで興味深い。これは、もしかするとマイクロソフトがCGM（Consumer Generated Media：消費者側が生成するメディア）の価値を高く評価するようになってきたということなのかも。つまり、独自形式で顧客を囲い込むより、価値の高いコンテンツをOfficeからシームレスに利用できた方が得策という考え方だ（Googleをはじめとする今時の企業からすれば今さら何をという感じだろうが）。
直接の関係があるかどうかはわからないが、GoogleはGoogle Spreadsheetという表計算サービスを開始している。Google Spreadsheetでは、複数人が1つの表を共有して作業を行うことも可能だ。今後、インターネットを介した文書共有などを展開していく場合、マイクロソフト独自形式はもはや足かせにしかならないと考えた、というのはちょっと希望的観測が入り過ぎかな。

データ同期技術が盛り上がってきているような

Tats_y — Thu, 24 Nov 2005 05:40:23 +0000

MicrosoftがRSSの拡張「SSE」（Simple Sharing Extensions）を進めているというニュース（ITmediaエンタープライズ）。
データの同期技術は、需要はものすごくあるにもかかわらずイマイチ盛り上がっていなかったが、ようやく盛り上がってきたか。
同期のための標準規格としては「SyncML」が2000年に制定されたが、それほど普及していなかった（少なくとも日本国内では）。こちらも携帯電話の普及とともに少しずつ広まってきているようだ（ケータイWatch）。来年には新バージョンも発表されるという。
現時点でSSEの詳細は不明だが、差分を取り出して同期するSyncMLに対して、SSEでは1つ1つのデータをフィードとして公開するようなイメージになるのだろうか。このあたりどうもわからないところが多いのだが、用途によってはSyncMLとSSEが競合するシーンが多くなるかも。またしてもMS対その他という構図になるのは勘弁してもらいたいものだ。
話は変わるが、今のところ個人的に熱望しているのは、Windows←→Mac間の手軽な同期ソリューション。Missing Sync for Windows Mobileが日本語に対応してくれれば、あとはW-ZERO3などのWindows Mobileを経由して手軽に同期できるかもしれないと期待している（Palmや携帯電話経由でOutlookのデータをMacと同期するのは諦めてしまった）。

プレイリスト型ポッドキャスティングというのはどうだろう

Tats_y — Sat, 29 Oct 2005 05:29:03 +0000

ようやく第5世代iPod（黒の60GB）が到着した。ムービーの表示品質は思った以上で、満足できる出来である。解像度が320×240ピクセルと低いが、画面が小さいため意外とシャープに見える。ムービー再生が始まるまでに一瞬待たされたりとか細かな不満はあるけれど、まあ許容範囲内だ。
さっそくあれこれビデオキャスティング（Vodcasting）を表示してみる。きっちりと作り込んでいて面白い番組もあるが（CNET Japanでも紹介されていたSuicide GirlsはHでお洒落な感じがいい）、個人のブログでやっているようなちょっとしたムービーはほとんど視聴の対象にならないのではないか。テキストと違って音声やムービーは記憶装置の容量を食うし、ざっと流し読みしていくようなことができない。
そこで、プレイリスト型ポッドキャスティングを行うサービスというのはどうだろう？　以前ストリーミングで動画が流れ始めた頃、あちこちのストリーミングをかき集めてきて、それらを1つの番組として流すサービスがあれば面白いのではないかと考えた。サービスで公開するのはプレイリストのみで、実際にあちこちのストリーミングサーバーにアクセスするのはユーザーのパソコンというわけだ。このアイデアはポッドキャスティングでも使えるのではないだろうか。すでにYahoo! Video Searchのようにキーワードに合致するムービーのRSSを配信するサービスは始まっているが、これは雑多なネタの塊だから見ていてかなり疲れる（キッチュで面白いことは面白いけど）。
そうではなくて、ソーシャルブックマークで人気の高いムービーなどを収集し、編集者が1つの番組として構成。実際のデータを流すのではなく、あくまでムービーの再生順を記述したプレイリストを流すようにする（ムービー間に入れるテロップなどはサービス側が作り込む）。プレイリストを受け取ったユーザーのパソコンは、それにしたがってムービーをダウンロードし再生するのである。SMILなどの技術を使えば実現できそうな気がする。

（補足）
Vodcastingの問題点はCNET Japan「携帯ビデオがパッとしない7つの理由」で言及され、それへの解決策がPOLAR BEAR BLOG「「携帯ビデオがパッとしない7つの理由」を解決する」やnobilog2「携帯ビデオをパッとさせる、video iPodのポテンシャル」で述べられている。

自動組版のセミナーに参加してきた

Tats_y — Thu, 20 Oct 2005 13:20:17 +0000

JAGAT（日本印刷技術協会）が主催する「紙面制作の自動化とページデザイン」のセミナーに参加してきた。PCJapan用語辞典のワークフロー作りをお手伝いしたということで、無理を言ってタダで（←ここ重要（笑））聴講させてもらったのだ。

このワークフローについて簡単に述べておこう。ハッカー用語辞典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で活躍しているものだ。