マルチリンガルで動くソフトウエアを真剣に考え始めると、アジア各国の文字について考えることになる。手始めには、「CJKV」（Ken Lunde 1998/O'Reilly、邦訳「CJKV日中韓越情報処理」(2002)を購入して勉強することになる。ついつい漢字や語彙の多さや入力メソッドの複雑さから、日本語が一番難しいだろうと思ってしまいがちだ。

そんなとき、「文字符号の歴史 A history of character codes in Asia」（三上喜貴/2002 共立出版）を見たら、他国の言語のもつ複雑さに驚愕するだろう。

...

本書は、アラビア系文字、インド系文字、アルファベットなどの世界の文字の符号処理について体系的な解説を試みたあと、中国、モンゴル、韓国、ベトナム、インド、タイ、ラオス、カンボジア、ミャンマー（ビルマ語）、スリランカなどの文字符号表について詳細に歴史をひもときながら解説している。また、蒙古系文字やキリル文字、デーヴァナガリ文字、ベンガル文字、タミル文字などUnicodeに採録されるに至るまでの困難をまざまざと見せつけてくれる。

Emacsのバージョン23（未リリース）では、Unicode完全対応しているのだが、これらの文字ももちろん対応している。さて、これらの複雑な合字を持つ文字符号を正しく表現するには、あるいは処理するにはどうしているのか、興味は尽きない。

先日のCodeFestでは、半田さんや川幡さんらと、マルチリンガルターミナル（mlterm)上のUnicode Emacsにおいて、インド系文字の合字を扱ったとき、ターミナル上のColumn, Rowと、文字コードにおける位置、そして表示のされ方はどうあるべきか、その制御はどうあるべきかを議論した。

同じ文字コードの表現であっても、ターミナルの表現力とフォントのグリフと合字の処理方法によってColumn,Rowは一定しないため、日本語の漢字のように全角、半角といったようにアプリケーション側で仮定をおくことができない。あるいは仮定してもこれが崩れる可能性が高いのである。
UTF-8のように文字の幅とコード幅が一定しない場合や、プロポーショナルフォントを使った場合も含めて、処理のありように難しい課題を突きつけている。