Re: JLReq のクラスと Eric の提案クラスとの比較

 shimonoです

On 2020/11/23 16:23, 木田泰夫 wrote:
> 少しだけ分析（の予備考察を）してみました。
> 
> まず、JLReq の文字クラスのうち、特定の文脈を指定するクラス cl-20/21/22/23/24/25/28/29/30 を除いた状態で、一つの文字が複数のクラスに含まれる例は、一文字の例外を除いて全て "cl-27 欧文用文字” との重複でした。
> 
> 一例だけ、"cl-17 等号類”、“cl-19 漢字等”、"cl-27 欧文用文字" の三つのクラスに現れるのが、U+2194, ↔, LEFT RIGHT ARROW なのですが、これは他の矢印を差し置いて（？）これだけ特別な理由がちょっとわかりませんでした。
> 
> この例はちょっと傍へ置いておいて、全ての重複例が、漢字等と欧文用文字の重複だとすれば、文字を見た時にその文字がどのクラスかを一意に決めるカギは、それが和文コンテキストなのか、欧文コンテキストなのか、ということですね。

 どう反応しようかとずっとうなっていたのですが、欧文コンテキストでの文字用にJLreqで文字クラス
や分類を立てる、というのはちょっと違和感があったりします。。もちろん、改行・文字間の扱いのため
の仮想クラス的なのは必要かとは思いますが、JLreqの文脈として(JISでなくUnicodeの文字セットに拡張
したときに)文字の分類として必須なのかな？もしくは現実的なのかな？と。
# 現実問題として(CJKを除き?)和欧混植が一番多いでしょうけれど、アジアの諸言語とかアラビア語とか
も混植になることはあると思うと、Unicodeへの拡張という文脈を思うとそれぞれの仮想クラスを立てるの
か？とか、、。

 もちろん、htmlのようなマークアップで書記情報を別途複雑に指定できるデータではないところできち
んとした表示ルールを(自動)適用するときには何らかのものがルールにないと困るところですが、、。


> Eric の提案では、横書き、縦書き、日本語でない場合、と三つのコンテキストを設定していて、ぱっと見ですが、横書きならより欧文コンテキスト、縦書きなら和文、という区分けをしている文字が多いような印象を持ちました。
> 
> ただ、そうなっていないケースも多く、JLReq に和字としての役割と欧文文字としての役割両方が書いてあるのに、Eric の提案では常に和字のルールで扱っている文字もあります（例：左シングル or ダブル引用符）。また、JLReq の分離禁止文字で、縦書の場合には分離禁止ではなくしている文字がありました（例：三点リーダ）。
> 
> みなさまの分析も聞かせてください。
> 
> 来週のミーティングでは、仮想クラスは脇に置いておいて、先に Eric の提案を JLReq と付き合わせながら、コンテキスト依存性をどうするのが良いのか考えるのはどうでしょう？

 コンテキスト依存性についての議論は必要かとは思うのですが、"欧文用文字"というのを今の形で残す
のもそれでいいのかな？というのもちょっと気になっているところです。
# 今の形で、という点でいえば、漢字等とかもかもしれませんが、、（ある意味約物でない全角で使われ
た文字全部的な感じもしたりして。。