-
-<dl>
-<dt>iso-2022へのencodeはどう実現すればよいのか?
-<dd>Characterはどうencodeするかの属性を持っていて、
-XStringはその実際のencodeの処理を行うという分離でいいかな。
-
-<dt>iso-2022-jpの処理はどうすればいいのか?
-<dd>iso-2022-jpは行末ではASCIIに戻すという行単位の扱いが必要になるが、
-XStringの中からはその判断はできない。
-class IOを拡張するのがいいのか?
-</dl>
-
-<hr>
-<h3>■字形合成</h3>
-<dl>
-
-<dt>"+木木"(+はU+2FF0を意味する)という文字列が
-あるとして、しかしこれは実は"林"という一文字を表している。
-この二重性をどう取り扱うか?
-<dd>newされた時点で問答無用で"+木木"を"林"というCharacter一文字に変換
-してしまうと、その時点で区別ができなくなってしまう。つまり必要に応じて
-composeするべきである。しかしその必要に応じてというのはどのように判定
-すればいいのだろうか? 明示的に指定するしかないということか。
-
-<dd>Unicode対応のeditorはどうとりあつかっているのだろうか?
-Unicodeの規定によれば、このIDSによって指定された文字列は、合成された文字そのものを
-表すと規定されている。合成された文字を表示可能である場合は、IDS自体を表示してはいけない。
-逆に合成した文字を表示できない場合は、IDS自体を見えるように表示しないといけない。
-とすると、Unicode対応のeditorが適切な文字合成の機能を持っていた場合、
-それは合成された結果の文字を表示するのがいいのか? 合成される前の文字列を
-表示するのがいいのか? 結局ユーザーが明示して切り替えられるようにするのがいいのか?
-
-<dt>もしエラーが含まれていた場合は?
-<dd>"+木".to_x.compose_ids
-とした場合は、オペレータの対象が一文字しか無いので、処理できない。
-これは例外をraiseするか、元の文字列をそのまま返すか、悩みどころ。
-
-<dt>もし文字が存在しなかった場合は?
-<dd>"+林林"とかした場合は、"木"が横に四つ並んでる漢字は存在しない(と思う)ので、
-これも例外とするか、元の文字列をそのまま返すか悩みどころ。
-どの文字コード体系にも存在しないような文字を表示できる字形合成エンジンがあると
-仮定して、そのエンジンに手渡されるまでは、情報が失われないように処理
-するべきである。
-
-<dd>また、本来Chaonモデルはこのような「存在しない文字」をとりあつかえるように
-するためのモデルなので、こういった文字もシームレスに扱えるようにするべきである。
-しかしどのようにすればいいのかわからない。
-
-</dl>
-
-<hr>