JLReq TF font group meeting notes 8/17

英語: https://github.com/w3c/jlreq/issues/295 <https://github.com/w3c/jlreq/issues/295>

JLReq TF font group meeting notes 8/17

議論
・木田がUAX50への対応に必要なフォントの変更点を説明した（議論で出たコメントを入れたアップデート版を下に添付）
	・必須の、及び必須でない変更点の説明
	・変更を行わない場合の問題点
	・移行の利点と問題点
	・利点を享受して、問題点を少なくする一つのアイディア

・Nat による問題提起：CSS upright の動作や意味が名前に合っていない。つまり、upright を指定すると vert を適用する動作を行うが、vert の適用の結果横転する文字も多い（e.g. UAX#50 Tr）。Nat が問題点をまとめて JLReq TF に報告


合意事項
UAX50 と AJ1  フォントの食い違いは四点しかないので、UAX50を変更する方向での解決を UTC に提案する。JLReq TF でドラフトし、文字情報技術促進協議会に取り次いでもらう。ことで合意した。

TODO 
・山本太郎さん：縦書きにおける文字の回転方向の食い違いが UAX50 vs AJ1 フォント間でこの四文字しかないことを確認する
・村田さん：UTC へのサブミッションを書く
・小林さん：文字情報技術促進協議会においてサブミッションの取次を行う
・Nat：CSS upright の動作の問題をまとめて JLReq TF に報告



–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
UAX50 への対応に必要なフォントの変更点
UAX#50の背景

印刷からデジタルテキストへ、モデルの移行が、UAX#50 の必要になる要因。印刷モデルでは画面上の結果を紙やPDFに印刷して固定できればよかったので、異なるフォントやアプリケーションで動作がバラバラでも困らなかった。web や EPUB などのデジタルテキストは、アプリケーションやフォントに関わらず同じ結果を得られる必要がある。

必須の、及び必須でない変更点

縦書き字形を UAX#50 の期待する方向に合わせるために必要な変更

vert を取り除く *1

U+2016 双柱, DOUBLE VERTICAL LINE *3
U+2702 ハサミ *4
90度回転した縦書き字形への vert を加える *1

U+FF1B 全角セミコロン, FULLWIDTH SEMICOLON *2
U+3030 WAVY DASH *5
対応には必須ではないが、長期的に期待される変更点 *1

従来正立だったものが回転になるに従い欧文扱いになり、これらの文字はプロポーショナルが期待される

ギリシア文字
キリール文字
算術記号（ただし、ヒラギノは現在でもプロポーショナル）
矢印の一部など
このカテゴリの文字のリストは、私がメーリングリストに 7/19 に出したメール 「縦書き字形の問題：アプリケーションの動作」の「まずは InDesign で正立するが、UAX#50 では横転する文字たちです」セクションにあります。

使われなくなる vert

これらの文字は、AJ1 フォントが、全角中心で回転されることを保証するために vert を持っている文字たち。欧文約物や罫線素片など。これらはUAX#50アプリケーションの場合アプリケーションが横倒しにするので、vert は使われない

U+00B0, U+2010, U+2015, U+2025, U+2026, U+2032, U+2033, U+2190, U+2191, U+2192, U+2193, U+21C4, U+21C5, U+21C6, U+21E6, U+21E7, U+21E8, U+21E9, U+239B, U+239C, U+239D, U+239E, U+239F, U+23A0, U+23A1, U+23A2, U+23A3, U+23A4, U+23A5, U+23A6, U+23A7, U+23A8, U+23A9, U+23AA, U+23AB, U+23AC, U+23AD, U+23B0, U+23B1, U+2500, U+2501, U+2502, U+2503, U+2504, U+2505, U+2506, U+2507, U+2508, U+2509, U+250A, U+250B, U+250C, U+250D, U+250E, U+250F, U+2510, U+2511, U+2512, U+2513, U+2514, U+2515, U+2516, U+2517, U+2518, U+2519, U+251A, U+251B, U+251C, U+251D, U+251E, U+251F, U+2520, U+2521, U+2522, U+2523, U+2524, U+2525, U+2526, U+2527, U+2528, U+2529, U+252A, U+252B, U+252C, U+252D, U+252E, U+252F, U+2530, U+2531, U+2532, U+2533, U+2534, U+2535, U+2536, U+2537, U+2538, U+2539, U+253A, U+253B, U+253D, U+253E, U+253F, U+2540, U+2541, U+2542, U+2543, U+2544, U+2545, U+2546, U+2547, U+2548, U+2549, U+254A, U+261C, U+261D, U+261E, U+261F, U+27A1, U+2B05, U+2B06, U+2B07, U+FF1D

注

*1: 変更に対しては、元のグリフを得るための適切な OpenType テーブルを加える必要があるかもしれない。

*2: UAX#50 では全角コロンに合わせて vert を加えて回転にしている。が、縦書きでの確立された用法がなく、中国語、韓国語でも現在成立のまま。よって vert を加えず正立のままも許容

*3: ただし、この文字の使われ方を考えると縦書きで回転するのが適切に思われる。その場合、vert を取り除かないことで回転を達成できる。同時に UAX#50 の変更を提案すべきであろう

*4: この文字は絵文字としても使われている。文字名がハサミなため、フォントによって方向が異なる。絵文字的な文字と考えて、正立が合理的だと思われる。同時に、フォントによって方向が異なることの注意をユーザーに伝える必要があるかもしれない。

*5: Dash であるので UAX#50 の期待通り回転が合理的だと思われる

上記変更を行わない場合の UAX#50 対応アプリケーションにおける影響

vert を取り除かないと UAX#50 の期待に反して回転になる文字

U+2016 双柱, DOUBLE VERTICAL LINE *3
U+2702 ハサミ *4
vert を加えないと UAX#50 の期待に反して正立になる文字

U+FF1B 全角セミコロン, FULLWIDTH SEMICOLON *2
U+3030 WAVY DASH *5
・「プロポーショナルグリフが望まれる文字」は全角のまま横転となるが、それ以外の問題はない
・「使われない vert」は残しておいても単に使われず害なし

UAX#50 に合わせるメリット、デメリット

メリット

全ての対応が完了すると、どのアプリケーション & フォントの組み合わせでも同一の結果が期待できる
変更の内容の多くは国際化システムから見て合理的に思える
デメリット

フォントの縦書き文字の方向ほ変更は互換性のために不可能であるので、別のフォント名を持った新しい商品を作る必要がある。開発および商品ラインアップを増やすコスト
UAX#50 の目標達成のためには、ユーザーが所有するフォントを全て入れ替える必要がある。そのコスト及び移行にかかる期間の問題
移行期間中、一時的に不統一が拡大する。対応／非対応アプリケーション、対応／非対応フォント、の四つの組み合わせができる
メリットを享受して、デメリットを少なくする一つのアイディア

UAX#50 の最小限の変更、もしくはUAX#50からの最小限の逸脱で、vert に関わる変更を不要とし、対応を不要とする方法

U+2016 双柱, DOUBLE VERTICAL LINE
現在のアプリケーションの互換性：InDesign は vert を使わず回転。ブラウザはブラウザとフォントの組み合わせで複雑にバラバラ
→ フォントの変更なしで回転を追認 (UAX#50: U→R or Tr)

注：石井さん：この文字は数学記号として使われる場合がある。木田：その場合も横倒しが順当だろう

U+2702 ハサミ
現在のアプリケーションの互換性：InDesign は回転？ ブラウザとフォントの組み合わせで複雑にバラバラだが U+2016 の方向と同一
→ フォントの変更なしで回転を追認。本来は正立が望ましいが、レガシーとして現状追認（UAX#50: U→R or Tr）。もしくはこの文字だけは移行による混乱を許容して、vert を取り除いて正立させる

U+FF1B 全角セミコロン, FULLWIDTH SEMICOLON
現在のアプリケーションの互換性：InDesign 正立。ブラウザはほぼ正立。例外は Firefox。フォントに関わらず回転させる
→ vert なしのまま。正立を追認 (UAX#50: Tr→U or Tu)

注：石井さん：ドキュメントには明確に書かれていないが、Tr の場合 Tu の動作でも許容。木田：その場合、ドキュメントの明確化だけで済むかもしれない

U+3030 WAVY DASH
現在のアプリケーションの互換性：InDesign 正立。ブラウザはほぼ回転。例外は Chrome。フォントに関わらず正立
→ UAX#50 を Tr → R に変更することでフォントに関わらず回転させる。もしくは、vert なしのままで正立を追認

注：石井さん：一部のフォントは回転かつ反転している。その動作を保存する必要のある場合のために Tr になっている。村上さん：そのようなフォントは例外的。村田：正立の場合、漫画で困らないか？木田：現時点で正立するので新しい問題ではない。既に解決をしているはず。また、本来論で言えば、長音として使う方法は例えば長音文字のグリフバリエーションとして解決すべきではないか。


「プロポーショナルグリフが望まれる文字」については対応アプリケーション側で回転にするので、フォントが対応する必要なく回転になる。
長期的には「プロポーショナルグリフが望まれる文字」についてプロポーショナルに移行