Re: 文字クラスの国際化

以下は二、三やってみた結果の考察です。

cl-03 ハイフン類
下農さんのやられたように cl-03 を全角かつ General Category = “Pd” (Dash) でフィルターすると（* Form Variants とりあえず無視）、JLReq で規定している文字のうち、日本語用の文字がないという議論になった二分と四分のダーシ（U+2010, U+2013)、が撥ねられてしまいます。これらはプロポーショナルという定義ですから当然です。これは色々なクラスに共通の問題です。また JLReq の範囲外からは新たに WAVY DASH U+3030 が引っかかってきます。これは cl-03 として扱っても可？

cl-04 区切り約物
PropList の “Sentence_Terminal”、スクリプトが “Common”、Vertical Orientation != “R" でフィルターすると大体良いのですが、和文の句点が含まれてしまいます。確かにこれらはどれもセンテンスを終える記号ですので、疑問符と感嘆符だけを区別する理由は普通ありません。しかし和文組版の中では、句点はその全角幅の中に空白を含んでいるので追加の空白不要、疑問符感嘆符は全角に作るので追加の空白が来る、その区別が必要ということですね。また、試しにフィルターに文字幅 = 全角、を入れると二重の疑問符と感嘆符が抜け落ちます。これらはプロポーショナルの規定なので落ちるのです。もしフォントが持っているグリフがプロポーショナルであった場合、どのような組版になるべきでしょう？

今のところこんな感じ。敏先生が腰痛から復帰されるのを待ちましょう。

木田

> 2021/03/14 11:06、木田泰夫 <kida@me.com>のメール:
> 
> 私もつらつら見ているのですが、全角問題がキモですね。JLReq では（本来の英字以外の）文字が全角半角幅であることを期待してあらゆるルールが組み立てられています。しかるに、現実的にはそうではない。で、この現実にはそうではないという事実にどう対処するのか、ということです。
> 
> 例えば cl-04 区切り約物をとってみると、所属する6つの文字のうち必ず全角なのは「全角感嘆符」と「全角疑問符」のみ。残り4つの、「感嘆符二つ」、「疑問符二つ」、「疑問符感嘆符」、「感嘆符疑問符」は UAX11の規定に従うとプロポーショナルです。
> 
> 同様な問題が cl-12 前置省略記号、cl-13 後置省略記号にも当てはまります。今までの議論で、これらの文字クラスは削除し、全角のものは漢字 cl-19 と同じ扱い。そうでないものは cl-27 という結論になっています。が、「全角のもの」とは一体どの文字でしょう？ 例えば「全角NO」は Unicode 的には Ambiguous つまり全角の場合もあるしプロポーショナルの場合もあります。
> 
> どちらの例でも、おそらく「日本語」フォントはこれらの文字を全角で実装しているのでしょうけれど、実際の環境においてこれらの文字に日本語フォントが使われるかどうかわかりません。特に国際化システムにおけるシステムフォントで表示した場合、これらがプロポーショナルになる可能性は高いでしょう。
> 
> 問題点は、もし文字がプロポーショナルであったらどのような組版規則が適用されるのか、という一点に集約されるように思います。
> 
> もし全角であろうとプロポーショナルであろうと同じ規則が適用されるなら、ある意味安心して現在の JLReq 文字クラスを拡張できます。全角かどうかのプロパティが使えないので、拡張の難しさはあるでしょうけれど。
> 
> もし文字が全角である場合のみ現在の JLReq の規則が適用されるなら、全角でない場合にはどのような規則になるかを考える必要があります。必ず全角であること、という規則にしたくなりますしそれも可能性の一つでしょうけれど、現実に全角でなかったら何が起こるべきでしょう？
> 
> いずれにせよ国際化された JLReq 文字クラスは文字のみならず、適用されるフォントによって異なってくることになります。
> 
> 
> 敏先生、みなさま、乞う色々なご意見。
> 
> 木田
> 
>> 2021/03/13 10:21、木田泰夫 <kida@me.com <mailto:kida@me.com>>のメール:
>> 
>> 下農さん、
>> 
>> ありがとうございます。この表でわかる下の三種類のケースのうち：
>> 
>> 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, 以外に使えそうなプロパティはあります？
>> 
>> 木田
>> 
>>> 2021/03/12 20:41、Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>>のメール:
>>> 
>>> 
>>> 
>>> On 2021/03/09 22:55, Atsushi Shimono (W3C Team) wrote:
>>>>> *文字クラスの国際化
>>>>> *ほとんど時間がなく、1) 今まで議論してきた字間クラスをまとめたデータを作り、Unicode のプロパティに落とし込むことができるか調査する（木田、下農） 2) 次回のミーティングでは、字間以外にどのような文字クラスが必要か、どのような機能が文字による挙動の違いの影響を受けるかをレビューすること、を決めた。
>>>> 　メールで書いていたと思って書き忘れていたことに気付いたのですが、cl-01の際に話題になった縦書用
>>>> のコードポイントの除外は、Decomposition TypeがVerticalでフィルターできていました。これに入るの
>>>> は、ほとんどがU+FExxのポイントではありますが。。。
>>>> https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=[:Decomposition_Type=Vertical: <https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=[:Decomposition_Type=Vertical:>]
>>>> 　cl-02移行については順次進めていっております。。次回MTGまでには半分以上は終わらせるぞとは思って
>>>> おりますが、、はい。
>>> 
>>> 　以前にお送りしたような表を後ろまでやっていったものを添付します。
>>> 　大方の皆様の予想通り、かな、とは思うのですが、cl-01/02についてはほぼUnicodeのプロパティーなど
>>> で置き換えられる感じです。
>>> 　cl-03以降の記号の分類については議論の中で出ていたようにかなり厳しそうな気もします。。
>>> 
>>> 　添付ですが、Coverというシートに説明がありますのでそちらをまずご覧ください。
>>> 　cl-PoLm-uniのシートは04-10の文字クラスについては該当があれば記入していますが、11以降については
>>> 入っておりませんのでご注意くださいませ。(あれば順次追記していって近いうちに流したいとは思いますが)
>>> 
>>> 
>>> 
>>> 
>>> <jlreq-cl-with-unicode-202103.xlsx>
>> 
>