Re: 文字クラスunicode化の際の縦火器用の除外 (was: Re: JLReq meeting notes 3/9)

On 2021/03/13 10:21, 木田泰夫 wrote:
> ありがとうございます。この表でわかる下の三種類のケースのうち：
> 
> A) CL-List/IDが●かつCL-List/RM?が空白かつUnicode/filterが●のものは問題ない文字
> B) Unicode/filterのみ●のものはUnicodeの属性で記述した時に追加されてしまう文字
> C) CL-List/IDが●かつCL-List/RM?が空白かつUnicode/filterが空白のものはUnicodeの属性で記述した時に消える文字
> 
> これらのうち、A は期待通りですね。
> 
> 
> B はその文字クラスに加わってくれて期待通りもしくは加わって問題のない文字と、問題のある文字とが混じっている。この判定は難しい場合や、判定は簡単だけれどフィルターで除去しにくく、でも影響が少ないからまあいいや、なんてものもあるかもしれませんね。例えばヘブライ語ハイフンとか。
> 
> 
> C がおそらく一番問題で、フィルターの工夫が必要、という理解で良いですかね。ただ場合によっては C は JLReq 文字クラスの見直し、もしくは文字が足らないことを示唆している場合もあるのかもしれません。例えば、cl-03 ハイフン類（これは国際化的コンテキストの中で名前をつけると「日本語用ハイフン類」でしょうか、もしくは ideographic hyphen でしょうか）。cl-03 には文字クラスの見直しの際に次のような議論がありました：現在の Unicode 文字でこの文字クラスであることに疑問がないのは波ダッシュ U+301C と二分二重ダッシュ U+30A0 のみ。四分と二分のダーシ U+2010, U+2013 は日本語用のものと英文用のものでは振る舞いが異なるのに一つのコードポイントしか与えられていない。これを受けて考えると、Unicode のプロパティで絞れないのはその問題のもう一つの表れと捉えることができるかもしれません。つまり絞れない場合はそのこと自身が問題のありかを示唆している可能性がある。
> 
> 
> 下農さん、この作業をしていて、GC, EAW, DT, UAX50, 以外に使えそうなプロパティはあります？

 何か使えそうなプロパティー、というのは、パッと見たところではありますがまだ見つかってません。。
 どちらかというと、ざっくり眺めてというよりは、もう文字数も少ないので全部表に突っ込んで眺めない
となとは思うところです。

 cl-03での日本語と英文とで振る舞いが違うのにコードポイントが同じ、という観点は議論の中でのあら
ためてのわれわれの一つの気づきではありましたが、それと同様にコードポイントが割り当てられている文
字について何の言語からの出自かという点は約物についてはあんまり考えられてないし情報もつけられてな
いのかな？、とは思ったところではありました。