Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JLReq TF font group meeting notes 8/17 #295

Closed
kidayasuo opened this issue Aug 18, 2021 · 0 comments
Closed

JLReq TF font group meeting notes 8/17 #295

kidayasuo opened this issue Aug 18, 2021 · 0 comments

Comments

@kidayasuo
Copy link
Contributor

kidayasuo commented Aug 18, 2021

JLReq TF font group meeting notes 8/17

Discussions

  • Kida explained changes required for AJ1 (de-facto) Japanese fonts to adopt UAX#50 (the report attached at the bottom)

    • Required changes and non-mandatory expectations
    • Issues with UAX#50 compliant applications when AJ1 fonts do not change
    • Benefits and issues caused by the changes
    • An idea to solve issues while achieving the goal
  • Nat raised an issue with CSS Text upright. Upright uses vert feature to get the upright glyph. However, there are many cases where vert rotates it (e.g. UAX#50 Tr). Nat is to summarize the issue.

Agreements

The discrepancy of vertical orientation between UAX#50 and AJ1 fonts are only on four characters. To avoid costly update of fonts, JLReq TF group will propose to UTC to solve the issue by changing the UAX#50 definition for these four characters to match AJ1. Murata-sen to draft the submission, and 文字情報技術促進協議会 (CITPC) of which Kobayashi-san is the chair and has a liaison relationship with Unicode Consortium and, will send the submission.

Todo

  • Taro Yamamoto will verify if the mandatory change is really limited to these four characters. Send the answer to JLReq TF mailing list.
  • Murata-san will draft the submission document to UTC (ongoing)
  • Kobayahi-san will send the submission from CITPC.
  • Nat will summarize the issue with CSS upright (are there any other similar issue?) and report it to JLReq TF mailing (or GitHub?)

—————————————————————————————

Changes required for AJ1 Japanese fonts to adopt UAX#50

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 になっている。村上さん:そのようなフォントは例外的。村田:正立の場合、漫画で困らないか?木田:現時点で正立するので、新しい問題ではない。既に解決をしているはず。また、本来論で言えば、長音として使う方法は例えば長音文字のグリフバリエーションとして解決すべきではないか。

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant