JLReq TF font group meeting notes 5/18

[kidayasuo]

A trial of posting a meeting notes as a GitHub issue. The expectation is that it can capture follow up discussions in one place. Also, issues stem from the discussion or related issues can easily be inter-linked to give them a context.

Previous meeting: https://github.com/w3c/jlreq/issues/269 ––––––––––––––––––––––––––––––––––––––––– (English translation follows)

JLReq TF Meeting notes draft フォント分科会 5/18

背景

文字の縦書き字形には実装による不統一があり、電子書籍の作成などで課題になっている。また、約物間の半角詰めをOSレベルで実現するためのテーブルが提案されている。これらの機能の実現にはフォントとレイアウトが協調して動く必要があり、つまりオープンな仕様が必要である。フォントとレイアウトエンジンとの間の問題点を理解するため、フォントに知識のある人を招いてフォント分科会を作った。

第一回 3/30 のミーティングで村田さんの提起した縦書き字形の問題を議論した。第二回 4/20 のミーティングでは CITPC からのメンバーが加わり、石井さんの提案による約物間の半角詰めをOSレベルで実現するための OpenType テーブル chws について議論した。今回のミーティングでは、chws テーブルでカバーされない約物半角詰めについて議論する

今日のゴール

chws テーブルでカバーされない約物半角詰めをサポートする方法のオプション、フォントに何が必要かを理解する

参加者

CITPC

• 田原恭二さん（凸版印刷）
• 中内智浩さん（モリサワ）
• 水野昭さん（イワタ社長さん）
• Masao Kyo さん（漢字のお名前、所属？）
• 宮田愛子さん（大日本印刷、秀英体開発室）

W3C / JLReq

• 石井さん
• 小林さん
• 下農さん
• 田嶋さん
• Nat McCully さん
• 敏先生
• 村上さん
• 木田泰夫

議論

イントロダクション（木田）

• 前回の議論から、フォントをバージョンアップするのはフォント名を新しくした商品を出す必要があるなど、大きなコストが伴うことがわかった。ゆえフォントベンダーさんに対しては、小さな改良提案をバラバラに出すのではなく、ひとまとまりとして次世代のフォントはこうあって欲しい、と提案すべきかと思われる
• その意味で、約物の詰めで chws でカバーできないケースについて検討しておきたい
• 同時に、OSやデバイスにバンドルされる場合など、限定された場所で短期にできる改良もある。そちらの方向も重要
• OSバンドルやウェブフォントのベンダーの場合細かい単位でアップデートできる（石井）

前提として Shaping engine の説明（石井）

• 事実上 Shaping engine は三つ
  • Google の halfbuzz（Android/Chrome/Firefox/Linuxが使う）
  • Apple の CoreText（iPhone/iPad/Mac が使う）
  • Microsoft の DirectWrite（Windows）
• halfbuzz は一つのスタイルごとに処理。OpenType ライブラリに近い
• CoreText / DirectWrite は行単位・段落単位の処理も可能になっている
• この違いにより、エンジンでやれること、アプリケーションがやること、の分担が違ってくる

行頭行末は二つの可能なアプローチがある（石井）

• 一つはアプリケーションが行頭文字行末文字に対して halt を適用する方法。欧文で optical bounds の処理をするケースに似ている。この場合は halt があれば処理が可能で、行頭行末2文字だけなのでパフォーマンスへの影響も許容範囲
• もう一つは、例えば行頭に全角空白を一時的に入れて chws を適用するといったコンテキストを使う方法

マルチフォントはもっと厄介（石井）

• Run が別れるので、前のテキストの後端、後ろのテキストの前端を halt で全部削った後スペースを入れるという処理になる。入れるスペースの量を決める必要がある

そもそもどうすべきかが不明確（石井）

• フォントサイズが異なる、筆文字で半角にできない、70%にはできる、といった場合にどういうような処理を行う必要があるか。日本語組版として提示すべきでは
• chws での処理（一つのスタイル内）の場合は空きをフォントデザイナが指定できるので、二分とは限らないデザインの自由度がある。ここは chws の良い点の一つ
• 二分だったのは活字組版の制限（敏先生）
• JIS X 4051 の規定は参考にならない。そのようなケースについての記述があるが、その当時の例を前提に書いてあるので。平均ととると言う方法、大きい方が勝つという方法が考えられるが、大きい方が勝つという処理が良いと思う（敏先生）
• JLReq で何か文書化したい。GitHub 作って（木田）
• 考えをまとめてメールで流す（敏先生）
• 行書などプロポーショナルで組む物は、全角ベースとは別の考え方が必要なのではないか（Nat）
• 昔からプロポーショナル問題はある。活字時代に鍵括弧やパーレン、字形が2分、空きが2分、だったが、2分は開きすぎだという議論は昔からあった。もしくは鍵括弧を全部四部とか。活字では難しかったからやっていなかった。パーレンについては、欧文が1/3だった。というのを２分の活字に入れ込んで組んだというような事例はあった（敏先生）
• 行頭行末をそろえてしまった時点で、約物を詰めるか、調整を避けるのを優先するか、という話が出てくる（敏先生）
• 前から言っている、日本語もラグでいいのではないか？というのに近づいている（木田）
• 認めていいとは思うが、習慣の問題でもあるので。欧文も昔は full justfy が主流だったものが、今は圧倒的に不ぞろいになっている。日本語でもいずれなってくるのではないか？（敏先生）

chws でのレイアウトのレビュー結果（敏先生）

• コーテーションマークについてメールを流した

結論として、約物詰めのためにはフォントに chws と halt があれば ok（木田）

• ただし、Nat が提起している問題をちゃんと理解したい。https://github.com/w3c/font-text-cg/issues/45 にコメントして
• もっとアドバンスドで足らない可能性はあるとは思う（石井）
• chwsはいまの定義だと他の機能と併用できない（Nat）
• これもどんな場合に困るのかぜひ詳しく

文字情報技術促進協議会から参加してくださっている方々との議論・コミュニケーションの方法（木田）

• JLReq TF のメールリストは話題が組版全般。もし興味があればぜひ参加して欲しい。私まで連絡を
• 特定の議論は W3C github issueでやるという手がある。また、CITPC の GitHub や MS Teams でやるオプションもある
• 全体に参加という希望者がいるかもしれないが、フォントの話をする際にバックグラウンドの分かりにくさというのがある気もする
• バックグラウンドについて丁寧に説明する工夫をしたい（木田）

次回

• 6/15 10am JST。Nat さんが用意してくれるデータをもとに、縦書き字形問題に戻る

––––––––––––––––––––––––––––––––––––––––––––––––––––

JLReq TF meeting notes, font sig 4/20

Background

Shapes of some characters in vertical orientation are inconsistent depending on the combination of the font and the application used. Such inconsistencies are problematic especially with ebooks. Solving the issue in open environment where you can’t assume specific combinations require a good open standard that fonts can agree and follow. Similar issue exists in controlling spacing around Japanese punctuations. It requires cooperation from fonts as applications do not know where and how much extra space exists in a glyph. To help solving the issue it was agreed to create a font specific discussion thread in JLReq TF.

The first meeting on 3/30 discussed issues Murata-san raised regarding vertical orientation shapes. The second meeting on 4/20 discussed a proposal of ‘chws’ OpenType font table which allows shaping engines to adjust spacing between punctuations in a good performance. Font experts from CITPC including font venders joined from this meeting. This meeting will continue discussing punctuation spacing especially cases that are not covered by ‘chws’ table.

Today’s goal

• ‘chws’ OT table does not cover space adjustment at the beginning and ending of a line, and also when it spans multiple style runs. Understanding options for supporting them.
• Are ‘halt’ and ‘chws’ provide complete solutions for various applications to appropriately support punctuation spacing?

Attendees

CITPC: Tahara-san (Topan), Nakauchi-san (Morisawa), Mizuno-san (Iwata), Kyo-san, Miyata-san (Dainippon Printing)

W3C / JLReq: Ishii-san, Kobayashi-san, Shimono-san, Tajima-san, Nat-san, Bin-sensei, Murakami-san, Murata-san & Kida-san

Discussions

Introduction (kida)

• With the previous meeting we understood that adding new features to fonts is a big change / investment for font vendors. Therefore, we would need to propose a complete set of features next generation fonts would support instead of requesting them to implement individual features in piecemeal fashion. In this regard we want to understand how cases of punctuation spacing that are not covered by ‘chws’ will be supported. esp. if ‘halt’ and ‘chws’ are everything we want them to support in terms of punctuation spacing.
• At the same time like mentioned by Tajima-san, there are areas such as EPUB readers, OS standard text and web font venders that can move more quickly.

Brief introduction of low level software that implements layout (Ishii)

• Shaping engine is the low level framework for text layout. Effectively there are only three of them.
  • Halfbuzz by Google, used by Androids, Chrome, Firefox and Linux
  • CoreText by Apple used by iPhones, iPads and Macs
  • DirectWrite by Microsoft used by Windows
• Halfbuzz process one style run at a time. It is closer to OpenType library
• CoreText and DirectWrite can process multiple runs / lines at a time
• Because of the difference sometimes the same feature needs to be implemented in a different layer depending on the shaping engine used.

Two approaches for punctuation spacing at the beginning / ending of a line (Ishii)

• One approach is that applications apply ‘halt’ to the character at the beginning and ending of a line. This is similar to how optical bounds are supported for Latin typeface. It only require ‘halt’ from the font. As it is applied to only two characters in a line, the impact to the performance would be at a reasonable level.
• The other approach is to insert a dummy character before and/or after a line before giving it to the shaping engine so ‘chws’ process them as if the beginning and ending of a line is a character.
• Further discussions would be required to determine which of the two approaches should be used (perhaps the answer is different between shaping engines?)

It is harder to solve the cross style run case (Ishii)

• It would require three steps - processing the preceding style run to trim the extra space at the end of the run, processing the following style run to trim the extra space at the beginning of the run, inserting some space in-between.
• However…

for the first place it is not clear how much space is necessary when styles are different between adjacent punctuations (Ishii)

• Cases like different font sizes, when the font is proportional such as So-sho (brush stroke), etc.
• When it is within a style run, ‘chws’ gives designers a freedom to change the amount of space. It is an advantage of ‘chws’ approach (Ishii)
• Right now the space is always half-width but it came from the limitation of metal type setting. (Bin-sensei)
• JLReq does not mention how such cases should be processed. However X4051 touches on it it is not useful as it assumes specific cases that do not apply any more (Bin-sensei)
• There would be two ways, one is to take an average of a half width of two sizes. The other is to apply a half width of the bigger one. I think the latter is more preferable. (Bin-sensei)
• Shouldn’t we add a note to JLReq? Could you (Shimono-san) create a GitHub issue? thanks. (Kida)
• Will write up something for the multiple font size case and send it out to the mailing list (Bin-sensei) (done)
• It would require completely different thinking / system for proportional Japanese brush stroke styles such as gyo-sho (Nat)
• The half-width space is used not necessarily because it creates the better layout. There has been discussions that a half-width space is too wide. Quarter-width corner bracket existed. etc. (Bin-sensei)
• The half-width-ness was a requirement from efficiency. Characters that are not in unit width create extra space at end of lines and such lines required manual adjustments = extra work in fully justified style. (Bin-sensei)
• Well, it seems the discussion is coming to the logical conclusion that Japanese text should adopt rugged-right layout :) (kida)
• People are not accustomed to it but I think someday it will be accepted. European languages were also fully justified but nowadays rugged-right is far more popular (Bin-sensei)

Bin-sensei reviewed ’chws’ layout samples. How’s the result?

• Commented on how quotation marks are rendered and sent it out to the list.

Conclusion: to support punctuation spacing are ‘halt’ and ‘chws’ the only tables font should prepare? (Kida)

• It seems yes.
• We want to understand possible issues that Nat raised. Nat to comment on https://github.com/w3c/font-text-cg/issues/45 .
• It is possible that advanced layout software need some more (Ishii)
• ‘chws’ can’t be used with other features (Nat) Could you elaborate? (Kida)

What is the best way to communicate with people joining from CITPC? (Kida)

• JLReq TF list is not limited to font related issues. But if you are interested you are more than welcome to join. Please contact me or Shimono-san.
• Another possibility is JLReq GitHub Issues. (However it would not work well for administrative communications such as meeting reminder). We can also use CITPC GitHub (the same issue) or MS Teams (not good at archiving).
• There might be people who want to join JLReq TF. There are cases, however, the background of discussion is not clear (to new people). (Tahara)
  • Will try to cover background as much as possible (kida)

next meeting

• The next meeting is on 6/15 10 am JST. Will come back to the vertical orientation issue based on reports Nat-san will share.

[kidayasuo]

Bin-sensei commented on rugged-right discussion.

日本語のラグ組が増えていかない理由として，多くの文字が全角で，行長を文字 サイズの整数倍にし，仮名や漢字を文字間で2行にわたる分割できるとした場合 で，これをラグ組にすると，多くの行で行末がそろい，少しの行だけで，行末が そろわないということになる．欧文のラグ組のようにすべてというか，多くの行 末の位置がそろわないということにはならない．このほんの一部だけが行末がそ ろわないということは，その一部に何か意味があるのかという疑問を抱かせる恐 れがあること，また，ほんの少しの不ぞろいは，見た目の印象を悪くする，とい うことがあるのではと，私は思っている．

ですので，日本語のラグ組は，単語又は文節単位での2行にわたる分割とセット で考えていく必要があるように思います．単語又は文節単位での2行にわたる分 割の場合，行頭・行末そろえは，ほぼ不可能で，ラグ組しか考えられません．

ですので，単語又は文節単位での2行にわたる分割の自動処理が簡単に処理でき るということが進むにつれ，日本語のラグ組も普及していくと考えられるでしょ う．

以上です．

One reason that rugged right has not become popular in Japanese layout might be that because most characters are multiple of full-width naturally the length of most lines become consistent, with small number of lines in a different length. This is unlike English case where all lines are equally uneven. When only a small number of lines are shorter it looks as if it has a special meaning (e.g. it might be an end of a paragraph). also it does not look good.

I think in case of Japanese rugged right needs to be combined with folding lines at word or phrase boundary. Folding lines at word or phrase boundary is only possible with rugged right (because adjustments becomes too large).

When automatic word / phrase segmentation becomes easily available I think rugged right will also be accepted.