Re: [Mlterm-dev-ja] selection options

[Tomohiro K. <tk...@ri...>]

久保田です。

At 18 Dec 2001 14:11:08 +0900,
Araki Ken wrote:

> というわけで、もう少し拡張し、(a)のケースおよび(b)のケースについて、
>         
> 1. UCS を経由した変換により、同一視できる文字は極力端末
>    エンコーディングに準拠する形で受け取れるようにする。
>    UTF8_STRING によるセレクションを優先するのと同値(オプション(d),(e)を包接)
>    (prefer utf8 in receiving)
> 
> 2. 端末エンコーディングでサポートされる文字集合に属する文字は
>    それに変換し、そうでない文字は ISO2022 エスケープシーケンスを
>    用いた表現で端末に送る。
>    (forcibly convert inconvertible char)
> 
>    # 2の機能は、ちょっと面倒ですけれど、なんとか実装してみます。


>     端末エンコーディング 受信タイプ       変換処理
>    -------------------------------------------------------------
>           UTF8           COMPOUND_TEXT    変換して受け取る
>           UTF8           UTF8_STRING      そのまま受け取る
>      UCS-subset,2022     COMPOUND_TEXT    オプション1,2
>      UCS-subset,2022     UTF8_STRING      オプション1,2
>      UCS-subset,non2022  COMPOUND_TEXT    オプション1
>      UCS-subset,non2022  UTF8_STRING      オプション1
>          others          COMPOUND_TEXT    オプション2
>          others          UTF8_STRING      オプション2

いいと思います。2 がオフのときは、「端末エンコーディングでサポート
される文字集合に属する文字はそれに変換し、そうでない文字は捨てる」
ですよね。


> ついでに、UCS subset encodings の場合に、相手方に送信する際の動作として、
> 
> 3. UTF8_STRING 要求に応える
>    (accept utf8 in sending)
> 
> というオプションも設けたいです。

>     端末エンコーディング  優先する受信タイプ 優先する送信タイプ
>    -------------------------------------------------------------
>           UTF8            UTF8_STRING        UTF8_STRING
>      UCS-subset,2022      オプション1        オプション3
>      UCS-subset,non2022   オプション1        オプション3
>          others           COMPOUND_TEXT      COMPOUND_TEXT

これは、

>    端末エンコーディング  優先する受信タイプ 優先する送信タイプ
>   -------------------------------------------------------------
>          UTF8            UTF8_STRING        UTF8_STRING
>     UCS-subset,2022      オプション1        オプション1
>     UCS-subset,non2022   オプション1        オプション1
>         others           COMPOUND_TEXT      COMPOUND_TEXT

に変更するということですが、送信タイプについて、「優先」って
決めることができましたっけ? (すみません、セレクションのことが
あまりよく分かってないのですが、セレクションのタイプとして
[サポートされているなかで] 何を使うか、というのは、セレクション
要求側つまり受信側、ペースト側が決めることですよね)。UTF8_STRING
要求に「答える/答えない」ならできますが、あえて「答えない」
メリットというのは何かありますか?

>   +--------+----------+----------+-----+
>   |encoding|copy&paste|appearance|other|
>  ++ - - - -            - - - - - - - - +------+
>  | +- UCS subset encodings -----------------+ |
>  | |[ ] prefer utf8 to xct                  | |
>  | +----------------------------------------+ |
>  | +- encodings based on ISO2022 -----------+ |
>  | |[ ] forcibly convert inconvertible char | |
>  | +----------------------------------------+ |
>  +--------------------------------------------+

英語表現をもうちょっと練ったほうがいいかも。ぼくもあまり良い案は
ないですが、たとえば、



UCS subset encodings
   --->  for Unicode-subset encodings
encodings based on ISO2022
   --->  for ISO2022-based encodings
   --->  for ISO2022-compliant encodings

上記のふたつは、話題にしているエンコーディングというのが mlterm の
エンコーディングのことだということが明確になればいいのですが。
(ぼくの案でもその点はいまいちです)。また、UCS のサブセットである
ということと、ISO2022 に準拠しているということが、直交している概念
であり、排他的な概念ではない、ということがうまく伝わるかどうか、
ちょっと心配です。後者については -compliant の案の方がいいと
思います。また、UCS を Unicode とするほうが通りがいいと思います。

UCS subset encodings
   --->  when mlterm encoding is a subset of Unicode
encodings based on ISO2022
   --->  when mlterm encoding is compliant with ISO2022

とするのも、ひとつの手ですね。




prefer utf8 to xct
   --->  prefer UTF8_STRING to COMPOUND_TEXT for paste
   --->  process the received strings via UCS
forcibly convert inconvertible char
   --->  receive illegal chars using ISO2022 escape sequence

これらについては、受信側に立つときの動作を規定している、という
ことが明確になればいいと思います。また、専門用語については、
UTF8_STRING だとか COMPOUND_TEXT というような正式名称を用いた
ほうがいいと思います。どちらにせよ、ほとんどの人は知らない言葉
ですが、知りたい人は調べることができるように。

prefer utf8 to xct については、「COMPOUND_TEXT よりも UTF8_STRING
を好む」ということよりも、「UCS を経た変換を用いることにより
文字の同一視を行う」ということのほうが重要な点だと思います。
ですので、ふたつの案のうち、process the received strings via
UCS のほうがおすすめです。ただこの案だと、「同一視」という
ことが入っていません。どれだけ長くてもいいのなら、
「identify equivalent characters from different character sets
by converting/processing the received selection via UCS」という
感じなのでしょうが、「同一視」ということを表現するためだけに、
「identify」「equivalent」「different character set」という
長い言葉遣いが必要になり、これはちょっと諦めないといけないかな、
という感じです。(identify だけでも同一視という意味はないことは
ないですが、それだけだと別の意味にとられる恐れがありそう)。

forcibly convert inconvertible char については、「当該エンコー
ディングには含まれない文字を ISO2022 のエスケープシーケンスを
用いて無理やり受信する」という意味が伝えられればいいと思うの
ですが、ぼくの案だと「当該エンコーディングに含まれない」という
のが「illegal」となり、ちょっと意味があいまいになっています。
が、これを正しく伝えるとなるとやはり長くなってしまいます。いくら
長くなってもいいのなら、「receive characters which don't belong
to the mlterm encoding forcibly by using ISO2022 escape sequence」
という感じでしょうか。「ISO2022 のエスケープシーケンスを用いて」
という部分は絶対に削れないと思ったので、ぼくの案ではそれを残し、
「当該エンコーディング」とか「無理やり」とかを削ってあります。


文字数制限はかなり厳しいので、短かくしなければならないのですが、
一方で、かなり難しい概念を表現しようとしているのも確かです。
詳しい説明は manpage に任せるとしても、最低限必要な説明でさえ、
ある程度の長さになるのは仕方がないのではないかと思います。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/