名前: anonymouse 日時: 2006-10-13 00:24:27 IPアドレス: 66.226.79.*
>>45444 判りにくい表現で誤解されてもいけないので、まとめ直しておくと、 現在国際化されたと名乗るアプリケーションは、OpenTypeフォントさえ あれば、複雑な表記方法を持つ文字であっても、一次元のデータ構造で ある文字列を与えてやれば、自動的に、正書法に従った表示に直して くれるはずだと言う事です。つまり、フォントさえ開発すれば、理屈では あとは何もしなくて良い訳です。 > e > s > bskyed と打てば bkd と出力させる環境も出てきつつあるかな、と。 > y このような仕組みは必要なくなって来ているのです。bskyed と打てば、 アプリケーションは bskyed と文字列を受け取り、bskyed と保存する だけでよいのです。それを画面やプリンタで e s bkd y と表示するサービスはOSなり、共有ライブラリが提供してくれるからです。 インプッドメソッドは日本語、中国語などのように膨大な数の文字を 使用する言語や、トルコ語やベトナム語のようにdiacritical markを 酷使する言語では、ほとんど必須ですが、チベット文字などのインド 東南アジア系の文字を使用する言語では全く必要ありません。 キーマップを使って、発音順に文字列を入力するだけです。 > このあたりへのポインタを教えていただけないでしょうか。 どのような情報を必要とされているのか良く判らないのですが、 OpenType技術についてはMicrosoft Typographyでしょうか。 > ただウメの場合はもう一つ厄介なことがありまして、前後のどのくらい離れた音節に > どういう母音があるのか、でグリフを変える必要があります。 横に連なる子音、縦に重なる子音、形に従い分類した母音を各々別のグリフ クラスに入れて、Context Substitution Format 2で、BackTrack Count, LookAhead Countを大きめに設定して、対応すべきすべての組合せに置換を 設定していけばなんとかなるでしょう。 ただし、アプリケーションによっては、tseg(音節区切り符)をまたぐ フィーチャーを正しく処理しない可能性があります。 チベット文字ではtsegの箇所で改行が可能なため、アプリケーションが 個々のブロック(音節)毎に個別に、OpenTypeレイアウト処理サービスを利用 するかもしれないからです。 XeTeXが日本語OpenTypeフォントのdligフィーチャーを、\hboxに入れないと 正しく処理しないのと、全く同じ理由です。
この書き込みへの返事：