- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Mon, 12 Oct 2020 09:31:13 +0900
- To: 木田泰夫 <kida@mac.com>, Nat McCully <nmccully@adobe.com>
- Cc: W3C JLReq TF <public-i18n-japanese@w3.org>
木田泰夫 様 皆様 小林 敏 です． 木田泰夫 さんwrote >同じ文字コードに属すると考えるべき複数の字形の間で挙動が違ってくるケー >スがあるとしたら、 これに該当するかどうか不明ですが，また，特殊ケースかもしれませんが，“ヒ ラギノ”のダブルコーテーションマーク（シングルもそうかもしれない）を， InDesignで組版すると，和文用の通常のコーテーションマークなのにも関わらず， 何もしないデフォルトでは，プロポーショナルがどうも選ばれているようで， コーテーションマークの内側の和文とのアキが四分となり，外側のアキも四分と なります．ですので，意識的にコーテーションマークを字形パレットで全角字形 に変えないと，一般の日本語組版の形にならない（私はいつもそうしている）． この処理をしないので，コーテーションマークの内側の和文とのアキが四分とな っている本を結構，見かけます． >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
Received on Monday, 12 October 2020 00:31:56 UTC