Re: 文字クラス整理・Unicode化に関連する論点リスト

 shimonoです

 ちょっと横入りで論点整理・確認させてください。。
# というよりは、今日数時間位悶絶して結局整理できなかった絶望の念を開陳する的な感じかもですが、、。

On 2020/10/11 13:00, 木田泰夫 wrote:
>> いいえ、普通はOTFの適用は元のUnicodeデータをそのままにして、shapingの時点で字形を決めます。
> 
> 特定のアプリケーションにおける一つの実装はそうかもしれませんが、特定の実装とは関係のない仕様を JLReq にどう書くか、という話です。実装はどうあれ、文字コードが変わったと「解釈して」挙動を決められるとしたら、JLReq が現在採用している文字コードで文字の挙動を記述するやり方を変更する必要はありません。よね、というのがポイントです。

 字形、について、
・特に約物に顕著な、文字の幅の違い、フォントの実装に置いての、古典的な全角・半角とプロポーショナル
・OTF機能での文字の変形、fwidなどの適用によって文字の形態を変更する
  これはcharacter class的な概念においてはクラスの変更、Unicodeのコードポイント的には同形の異体字（IVSでないにせよ）と思える？
  (Unicode的にどういう扱いの定義なのかというのは、こいつはOTF側の話なのでなさそうな気もしなくはないですが)
・"日本語"フォントに内包される非日本語文字の実装依存でのプロポーショナル・全角の差異
のような複数のパターンがあって、それぞれについて考えていくというような感じでしょうか。。。


> 逆に、同じ文字コードに属すると考えるべき複数の字形の間で挙動が違ってくるケースがあるとしたら、それは文字コードでの記述では足りず、これこれの字形の場合には、などと書く必要が出てくるでしょう。そのような例はあるかなと。現在の JLReq で特にそのような問題は報告されていない、と理解していますが、Unicode や国際化との整合性を考えたときに新たな問題が出てくるかもしれません。例えば、ギリシャ文字を全角で扱うのが非常に重要だとしたら（そうではないと思いますが）、国際化との整合を考えた時に、ギリシャ文字がプロポーショナルな場合と、全角な場合で挙動を分ける必要が出てくるかもしれません。

 個人的な雑感ではありますが、、日本語・非日本語の混在文において、ページ記述者による明示的指定が
ない(デフォルトフォントを選択せよ、を含め)場合に、実装・環境依存の挙動の変化を入れる、という方向
はJLreqで取っていい流れではないんじゃないかな、という気はするところです。。。


>> 日本語組版に区別が必要である約物は、SJISにあったもの全て、全角のコードを別に入れたら良かったのに、とよく思ったりします。
> 
> この議論、想像するに今までもあったのかと思いますが、文字ごとにどういう議論があってどういう結論になったのか、どこかに残ってますかね。もしないなら、一度議論して JLReq なりの結論を出して記録しておくのも良いアイディアかもしれませんね。もしかしたら、重要度が大きく、将来的に Unicode に提案したい、なんてケースが見つかる、かも、しれませんよ。大変なのでそんなケースのないことを期待しますが。 ^^;

 日本語での約物に限定すればそれほど文字数はないような気はするので、、対照表はそれなりの労力でつ
くれ、、、る・・・？(すでにありそうですが、約物のくくりで抜いてくるのもちょい大変そう、、、)