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

Nat さん、

> いいえ、普通はOTFの適用は元のUnicodeデータをそのままにして、shapingの時点で字形を決めます。

特定のアプリケーションにおける一つの実装はそうかもしれませんが、特定の実装とは関係のない仕様を JLReq にどう書くか、という話です。実装はどうあれ、文字コードが変わったと「解釈して」挙動を決められるとしたら、JLReq が現在採用している文字コードで文字の挙動を記述するやり方を変更する必要はありません。よね、というのがポイントです。

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

> 日本語組版に区別が必要である約物は、SJISにあったもの全て、全角のコードを別に入れたら良かったのに、とよく思ったりします。


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

木田

> 2020/10/11 12:25、Nat McCully <nmccully@adobe.com>のメール:
> 
> 
> 木田さま、皆さま
>  
> ナットです。
>  
> From: 木田泰夫 <kida@mac.com>
> Date: Friday, October 9, 2020 at 4:34 PM
> To: Nat McCully <nmccully@adobe.com>
> Cc: Kobayashi Toshi <binn@k.email.ne.jp>, W3C JLReq TF <public-i18n-japanese@w3.org>
> Subject: Re: 文字クラス整理・Unicode化に関連する論点リスト
> 
> Nat さん、例を挙げていただいてありがとうございます。
>  
> 現在 JLReq は文字コードで文字の挙動を決めていますが、可能性として「この文字がこの形で表現される時にはこのルール、別の形の場合にはこのルール」なんて記述をしなくてはならないかもいうことですね。できればしたくないですよねえ…
>  
> OTF 機能を使うと文字の見かけを自由に変えられますから、別のコードを持った文字に変わったと解釈できるような変換も可能です。例えば A (U+0041) に全角 fwid を適用させて全角 Ａ に変える場合、これは U+FF21 に変わったと解釈できます。縦組みのチョンチョンに変わるケースもこれですね。
>  
> このような場合は特に新しい規則は不要で、変化後の本来的な文字コードをもつとして処理できる、と考えて良いでしょうか？
>  
> いいえ、普通はOTFの適用は元のUnicodeデータをそのままにして、shapingの時点で字形を決めます。
>  
> 逆にそうでなく、同じ Unicode 文字のままであると解釈するのが適当で、しかし扱いが変わるという例はありますか？
>  
> InDesignでは、字形パネルをダブルクリックして入力すると、その字形の標準Unicodeは入力されます。なので、Unicodeの入れ替えはそれで可能です。しかし、最近のInDesignやIllustratorでは、もう一つの字形入れ替えの方法が追加されました。太いアンダーバーは選択された文字に付けた状態で字形入れ替え候補が下に出て、それを選択するとOTF適用になり、Unicodeはそのまま変更せずに残ります。
>  
> もう一つの機能は、CID文字組みを使用、という環境設定です。その設定がオンの場合、AdobeJapan1のCIDフォントであれば、文字組みクラスはCIDで決まり、上のややこしいことはなくて済みます。
>  
> 挙げていただいたキリル文字の例はその一つかと思います。これは OTF 機能がなくてもフォントを変えるだけで問題が起きます。一般的に言って、和文フォントでは全角、和文フォント以外では全角ではないような文字たちは JLReq を国際化する際に問題になります。キリル、ギリシャ文字以外に、一部の役物や、演算記号などが確かあったかと。
>  
> Unicodeの統一に依存する問題の一つです。SJISからUnicodeへのlossy変換ですね。キリル文字は別に全角コードは必要ではないでしょうが、日本語組版に区別が必要である約物は、SJISにあったもの全て、全角のコードを別に入れたら良かったのに、とよく思ったりします。
>  
> その手の文字をリストしたデータがあれば良いのですが。Unicode に East Asian Width (EAW) * というヘンテコかつ現実的に便利な表がそれに近いです。しかし、この表において例えばギリシャ文字や演算記号などは N や Na、つまり「全角でない」であって必ずしも和文フォントの現実を追認しているわけではありません。やはり和文フォントの状態を調べる必要がありそう。
>  
> * http://www.unicode.org/reports/tr11/

>  
> 木田
> 
> 
> 2020/10/10 0:21、Nat McCully <nmccully@adobe.com>のメール:
> 
> 
> Nat です。
>  
> 字形id の話ですが、一番大きな問題はOTF機能が適用された場合、或いは縦組みか横組みかで標準字形が変わることによって文字組みクラスが変わってしまうケースです。文字組みクラスが変わることによってアキ量や伸縮の優先順位なども変わります。ユニコードだけでは正しい動きはわからないケースが多いです。字形の変わる仕様は曖昧でフォントに依存します。例えば約物のクラスが全角からpwid の適用によって欧文クラスにかわるとか、横組みのスマートクオートが縦組みのチョンチョンに変わるとか。キリル文字が全角の場合は「その他の和字」ですが、あるフォントではプロポーショナルの「欧文文字」だったり。
>  
> —Nat