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

木田さま、皆さま

ナットです。

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
________________________________
From: Kobayashi Toshi <binn@k.email.ne.jp>
Sent: Thursday, October 8, 2020 4:42:38 PM
To: 木田泰夫 <kida@mac.com>
Cc: W3C JLReq TF <public-i18n-japanese@w3.org>
Subject: Re: 文字クラス整理・Unicode化に関連する論点リスト

木田泰夫 様

　小林　敏　です．

以下の件，了解いたしました．

“約物の正書法”は，何を言うかは問題ですが，何か整理できればいいですね．

ところで，横組の句読点は3種類の方法があり，“公文書作成の要領”で決めら
れている方法は，現在は教科書などでは採用されていますが，一般の文書やWeb
では採用される例は少ないのが現状で，現在，文化庁の文化審議会（名称は間違
っているかも）で検討がすすめられており，現状の追認になるだろうと思ってい
ます．

字形IDで考えないといけない問題，私も例を調べてみます．今，思いつくの“大
カギ”（通常のかぎ括弧）と“小かぎ”です．縦組でいうと，水平線が短いのが
“小かぎ”です．括弧が入れ子になる場合，一般に「〇『〇』〇」となりますが，
引用する場合，元の文章では「」ですが，引用を「」でくくると，元の「」を
『』に変えないといけない．そこで，入れ子の『』を小かぎにすると，それが避
けられるというわけです．いくつかの出版社では，この方法が採用されています．

以上，よろしくお願いいたします．


  木田泰夫　さんwrote

>とってもカタツムリなレスポンス（とっても遅い）ですが、
>
>下農さん、まとめをありがとうございます。問題点がよく把握されていると思います。
>Unicode 化には文字クラスの拡張が必要なのですが、Unicode の文字クラスが文字の
>プロパティであるのに比べて、JLReq の文字クラスは文字の静的なプロパティに加え
>て動的な場合わけ、ステートが混ざっていて、このアーキテクチャの違いを克服する
>のに控えめに言って大変な変換作業になりそう。
>
>もちろん、Unicode の文字クラスその他の文字プロパティとはあまり関係ない形で現
>在の JLReq 文字クラスを拡張することも可能だと思います。が、成長する Unicode
>に合わせて JLReq 独自の文字クラスをメンテナンスし続けるのは現実的ではないでし
>ょう。また、国際的なアーキテクチャに整合させておくのは日本語組版の将来の発展
>に向けて、いつかはやらなければならないことかと思います。
>
>どこから手をつけましょうね。敏先生が、文脈依存のクラスを外すための議論を始め
>てくださっていますので、まずそれを片付けましょう。これに関してオンラインで
>ミーティングしましょう。後で調整さんを送りますので、来週、単純のために午前10
>時からとして、OK な曜日を教えてください。また9時からの方がよければ教えてくだ
>さい。この議論にインプット・興味がありそうな人だけで OK です。
>
>–––––
>Unicode / 国際化アーキテクチャへの整合化と同時に、必要に応じて「役物の正書
>法」についても考えてゆきましょう。下農さんが言われたように、技術的な整理をし
>てゆく際に必要になると思われます。本来我々が、この文字はこうだ、と決める立場
>ではないとは思いますが、かといって他の誰も決めてくれませんし、それを曖昧にし
>たままでは技術的な仕様も曖昧になってしまいます。「技術的にはこう考えていま
>す」的に考えるのはどうでしょう。下農さんがリストしてくださった 3, 4, 6 が大体
>これに当たりますね。
>
>––––––
>Nat さん、字形 ID で考えなければならないものがあるんですね。具体的にどんな文
>字があるんですか？　OpenType フィーチャーに関しては旧字体への変換など、本来の
>文字コードがそもそも変わってしまうような変換が可能なので、プレーンテキストと
>しての文字データと、見かけの差の問題が出てきますね。
>
>木田
>
>> 2020/09/23 11:38、Nat McCully <nmccully@adobe.com>のメール:
>>
>
>>
>>
>> 上のカテゴリにまたがると思いますが、ユニコードからクリフに変換するshapingの
>> 場合、縦書きが横書きか、OTF機能の適用かで、文字組みクラスが標準のと変わるこ
>> とを考えると字形id でクラスを決めることも考えないといけないですね。
>>
>> —Nat
>
>> From: Atsushi Shimono (W3C Team) <atsushi@w3.org>
>> Sent: Tuesday, September 22, 2020 6:09:05 PM
>> To: W3C JLReq TF <public-i18n-japanese@w3.org>
>> Subject: 文字クラス整理・Unicode化に関連する論点リスト
>>
>
>> 　shimonoです
>>
>> 　これまでにメールで流れた論点の整理・リスト化です。
>>
>> 1. JLreq文字クラスのUnicodeへの移行
>>
>> 　こちらはどちらかというと他の論点(3.以降)を煮詰めたら解が見えてくる話でし
>> ょうか。
>> 1.a) CL-01/02とPi,Ps/Pe,Pfの関係、その約物の幅
>> 1.b) CL-19,27のような全般的な文字クラスの拡張方策
>> 1.c) 単位記号など分割禁止として定義されているがUnicodeで対応が難しいもの、
>> と、Unicode禁則処理定義
>>
>>
>> 2. JLreq文字クラスの整理・統合
>>
>> 　1.とは独立に、木田さん提示の文字自体でなく文脈由来の文字クラスを外してし
>> まうプラン、敏先生
>> のJWT報告書(2019/3)の集約案などから、整理・統合した簡単な文字クラスを定義す
>> る議論があります。
>> 　あと、InDesignの文字クラスやIllustratorの整理での問題点も参考にしてみるこ
>> とが提示されてい
>> ます。
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fworks014.

>> hatenablog.com%2Fentry%2F20141022&amp;data=02%7C01%7Cnmccully%40adobe.com%
>> 7C3af2f639501f4685e8f008d85f5d4bdd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%
>> 7C0%7C637364201594655514&amp;sdata=lCehR9yrNaprjeI0leZkb%
>> 2BqKO1q6amkrSTDpg2aVFWE%3D&amp;reserved=0
>>
>>
>> 3. 約物の機能論的包摂分離
>>
>>  「約物の正書法」的なガイドラインを策定する議論がいくつかあげられています。
>> 3.a) U+2016, U+30A0
>> 3.b) 罫線素片
>> 3.c) 漢字とも仮名とも判然としない記号類の扱い
>> 3.d) 「ヨリ」「コト」の合字
>> 3.e) U+301C / WaveDash, U+FF5E / FullWidthTilda, U+30FC / Katakana-Hiragana
>> Prolonged Sound Mark
>>
>>
>> 4. 記号類の縦横問題、同一か異なる縦横のコードポイント、U+FFXX
>>
>> 　主にJWTの約物の意味論議論ではありますが、フォント・CSSも絡んだ問題として、
>> 記号類の縦横グリ
>> フの問題、3.の包摂分離に近い話かもしれませんが、くの時のような複数文字を並
>> べた表現の縦横問題
>> が挙げられています。
>> 4.a) くの字点、ダブルミュート / Double Vertical Line、U+2702
>> 4.b) 村田さんの弥縫策、Text Shaping WG
>>
>>
>> 5. 全角半角論、約物の幅とは何か
>>
>> 　約物のspacingをどう扱うか、というところから話が広がり、
>> 5.a) 約物のspacingの詰め処理をどう記述するか、文字全般にどう拡張するか
>> 5.b) 現実のフォントでは全角グリフが通例だが、「半角＋spacing」と記述されて
>> いる約物について、現
>>    実のフォントについてJLreqでどう言及するか
>> 5.c) 欧字=半角、ではなくなっているフォントの現実において、和欧混在文での揃
>> え
>>
>>
>> 6. 原語で"全角"の概念がない文字について、全角文字を使う場面のガイドライン
>>
>> 　この点についてこれまでに出ていたのは
>> 6.a)「全角欧文は、日本語の文脈だけで使用」についてその文脈についてのガイド
>> ライン
>> 6.b) ギリシア文字やキリル文字など全角として実装されている文字カテゴリの扱い
>> でしょうか。
>>
>>