« TSMのドキュメントわかりにくいよ | トップページ | Mac版でも文脈 »

2007年8月 9日 (木)

TSMに文句を言うシリーズ第二弾

TSM Document Accessというのは、要はInput Methodなどのテキストサービスが、アプリケーションが管理している文書ファイルの内容にアクセスするための仕組み。日本語入力という点では、これを使うと再変換とか文脈依存変換とかの高度なことが実現できる。英語圏でも、これを使うと、自動スペルチェックと修正候補の提示、みたいな機能を、アプリケーションと独立に外付けで実現できる。日本語の再変換とか英語の自動スペルチェックとかは、昔から、ワープロソフトの機能としては存在していたわけで、TSMの意義は、再変換とかスペルチェックとか自体にあるのではなく、そういう機能をアプリケーションから切り離す点にある。

マイクロソフトは、たぶんアップルよりも早くから、再変換のための標準APIとかスペルチェッカのAPIとかを作ってたけれど、仕様を見ればわかる通り、それは「日本語入力で再変換をするためのAPI」だったり、「ワープロでスペルチェックを行うためのAPI」だったりした。汎用性皆無。再変換のAPI (IMR_RECONVERTSTRING) は、再変換以外の用途に使うことは、ほとんど考えられない。アップルのTSMが偉いのは、用途を限定しないように注意して設計されているフシがある点。もっとも、TSM DAとほぼ同時期にマイクロソフトも、TSFという、仕組みだけじゃなくて名前までよく似たAPIセットを作っているので、特別にアップルが先進的というわけではないけれど。

と、TSMをほめたけど、TSM DAには、一カ所サイテーな部分がある。それは、TSM DAはアプリケーションが文書の内部表現をUTF-16で持つことを大前提にしている点。TSM DAでは、テキストプロセッサがアプリケーションの内部にある文書ファイルへのランダムアクセスを可能にするためのインターフェースを定義しているのだが、これがどれも「文書の先頭から数えて、UTF-16で表現されているとしたら××バイト目」という位置指定なんですよ。「文書の内容がUTF-16でベタベタっと並んでいるメモリの先頭アドレスを教えるから、あとは勝手にやって」なんていうAPIまである。(これは、オプションで、サポートしなくてもいい。そのことは、しつこいくらい書いてあるけど。) このインターフェースは、実際に、文書ファイルを UTF-16 で記録しているアプリには有利。でも、そうじゃないアプリは、TSM DA のインターフェースのところで、いちいち、UTF-16との間で変換をしなくちゃいけない。データそのものの変換はしかたないとして、「位置指定」まで毎回変換。しかも、この位置指定は、文字単位での整列が保証されていない。サロゲートペアの後ろ (low surrogate) だけ、とか、そういう位置指定ができる。

でね、SL Viewer って、内部は UTF-8 と UTF-32 でできてるんですよ。UTF-16は使わない。

あー。

« TSMのドキュメントわかりにくいよ | トップページ | Mac版でも文脈 »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/285638/7469546

この記事へのトラックバック一覧です: TSMに文句を言うシリーズ第二弾:

« TSMのドキュメントわかりにくいよ | トップページ | Mac版でも文脈 »