JLReq TF font group meeting notes 4/20

[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.

––––––––––––––––––––––––––––––––––––––––– (English translation follows)

JLReq TF meeting notes フォント分科会 4/20

背景

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

第一回 3/30 のミーティングで村田さんの提起した縦書き字形の問題を議論した。今回のミーティングでは石井さんの提案による、約物間の半角詰めをOSレベルで実現するための OpenType テーブル chws について議論する。また今回から文字情報技術促進協議会 (CITPC) からフォントの専門家が参加する。

今日のゴール

石井さんの chws テーブルを理解する

参加者

CITPC

• 安藤央さん（フォントワークス）
• 田中さん（台湾から）
• 田原恭二さん（凸版印刷）
• Masao Kyo さん（漢字のお名前、所属？）
• 水野昭さん（イワタ社長さん）
• 宮田愛子さん（大日本印刷、秀英体開発室）
• 山本太郎さん（Adobe）

W3C / JLReq

• 石井さん
• 小林さん（前半）
• 下農さん
• せきさん（xfqさん, W3C, clreq）
• 田嶋さん
• Nat McCully さん
• 敏先生
• Florian Rivoal さん (W3C)
• 村上さん
• 木田泰夫

議論

自己紹介とコンテキストの説明

• CITPC から数名が参加してくださったので、自己紹介
• Florian が他の言語でフォントの関わる問題についていくつか紹介してくれた。必要なベースラインやメトリックが定義されていない言語がある。日本語と繁体中国語では、句読点の周りのスペースが異なる。

半角詰めに halt では不十分か？（石井さん）

• halt があればアプリケーションが自分で半角詰めを実装できる。ただし halt で全て行うとパフォーマンスが悪い
• また halt で問題のあるケースがあるかもしれないと Nat（https://github.com/w3c/font-text-cg/issues/45）

chws テーブルの説明（石井さん）

• 約物半角詰めをOSに入れたい。OS/ウェブブラウザが行う簡易な組版の中で連続約物の詰めを実現するのが目的。カスタマイズ性は低い。chws なら約物の連続する場合を高速に実行できる
• サンプルページの紹介
• https://kojiishi.github.io/chws/samples.html
• https://kojiishi.github.io/chws/test.html

chws テーブル質疑

• プリミティブが欲しい場合は halt で大丈夫そう（木田）
• chws テーブルではでカバーできないケース（木田）
  • 行頭行末の約物半角詰め
  • フォントやサイズの異なる run の間の約物半角詰め
  • 行頭で halt を使うのか、コンテキストで行くのか（つまり chws を使う？）のはこれからの議論の課題（石井）
• 全てのフォントとアプリケーションが変わってゆくのに長い間、10-20年かかるかもしれない（石井）
• フォントにテーブルがない場合はどうする？
  • JLReq に従って決め打ち？（Florian） - word は決め打ちもある（石井）
  • テーブルがあるかどうかどうやって見分ける？
  • TrueType は開けてみないとわからない。OpenType は比較的仕様がまとまっている
  • （結論？）

フォントの立場から

• テーブルを加えるためにフォントをバージョンアップすることになるが可能か（木田）
• フォントは基本的にバージョンアップはできない。印刷事故につながる。機能を加えるとしたら、別の名前で新しい製品となる（水野、山本）
• 微細な変更の場合は、バージョンアップでやることもある。メーカーによって方針が異なる（山本）
• フォント名ではなく、構造的に何か区別がつけられる属性があると良いね（木田）
• OS バンドルの場合はバージョンアップで対応（石井、木田）。Windows で古いバージョンのフォントをインストールする方法をサポートというケースがあった（山本）

電子書籍の印刷事故？

• 出版社は紙と同じ基準を電子書籍にも当てはめようとする。出版社が直してと言う場合には外字にするしかない（田嶋）
• 通常は包摂されている文字について別な文字と気にしてはいけないはず（山本）
• 漢字字形に対する教育。電子書籍はゆるい、ソフトウェア的、という認識、啓蒙が必要。JLReq で何か言えないか？（木田）

UTR#50 vs AJ1 の食い違い

• どこかで互換性を断ち切るという考えもある（石井）
• 挙動の食い違いの原因は複雑。原因が、フォントとアプリケーション独自の動作の組み合わせで8類型位に分類される（山本）
• ぜひ資料をシェアして欲しい（木田）次の会議までに流す資料を用意する（Nat）
• AJ1とUAX#50の齟齬というところに矮小化せず、フォントが何をしてアプリケーションが何をするかというような議論をしたい（木田）

Wrap up

• JLReq では問題を理解して文書化できればいいと思う（木田）
• 次回は 5/18 10a 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. This, second, meeting on 4/20 will discuss a proposal of “chws” OpenType font table which allows shaping engines to adjust spacing between punctuations in a good performance. Font experts from CITPC *1 including font venders join the discussion starting from this meeting.

*1: Coded character-sets Information Technology Promotion Council. https://moji.or.jp

Today’s goal To understand the “chws” OpenType table proposal, its advantages and possible issues.

Attendees CITPC Ando-san (Fontworks), Tanaka-san (from Taiwan), Tahara-san (Toppan), Kyo-san, Mizuno-san (Iwata), Miyata-san (Dainippon Printing), Yamamoto-san (Adobe)

W3C / JLReq Ishii-san, Kobayashi-san, Shimono-san, Seki-san (xfq), Tajima-san, Nat-san, Bin-sensei, Florian-san, Murakami-san, Kida

Discussions Introduction

• Self introduction as we have many new people
• Florian explained that similar issue (i.e. font dependent) exists in other languages also. Examples are missing language specific baseline or metrics.
• It might be worth cooperating with clreq and possibly klreq if they share similar issues with J.

Is ‘halt’ table sufficient for applications to implement punctuation spacing?

• With the ‘halt’ table applications can implement punctuation spacing. It however has a visible performance impacts for example for rendering web pages (Ishii)
• Nat suggested that ‘halt’ might have some issues for high end layout software (https://github.com/w3c/font-text-cg/issues/45)

What is ‘chws’ table? (Ishii)

• The goal is to implement spacing of adjacent punctuations at the OS level, e.g. web browser and mail. It is right now only available with high end layout software. It focuses on performance. It works just like kerning pairs.
• It does not allow much customizations (i.e. not for high end layout software). It does not support punctuation spacing at the beginning and end of a line. It does not also support spacing between across different font styles. They need to be implemented in some other ways.
• Sample pages
  • https://kojiishi.github.io/chws/samples.html
  • https://kojiishi.github.io/chws/test.html

Q&A re: ‘chws’

• It looks like ‘halt’ is a good primitive, meaning it provides most low level basic information. Apps can implement punctuation spacing on its own by using the table, however ‘chws’ provides performance boost for typical case (kida). We want to understand possible issues that Nat raised.
• ‘chws’ do not support one important case of punctuation spacing — at the banning and ending of a line. It also does not work when it spans multiple style runs. What is Ishii-san’s thoughts on solving these cases? (Kida)
  • There are two possible implementations: 1) Using ‘halt’ at the beginning and ending of a line. Optical bounds are done in a similar way. 2) Using ‘chws’ by inserting a dummy character. Further discussions are required to determine the implementation.
• It would take a long time, e.g. 10-20 years, until all fonts and applications supports this feature (Ishii)
• What if a font does not have the table?
  • Can we go with blindly removing the halfwidth space based on JLReq’s table? (Florian)
    • Yes, MS Word does the same thing (Ishii) (CSS Text also?)
    • Traditional Chinese punctuation have spaces in different location for the same code point. How can you tell?
  • You can’t tell if a TrueType has a specific table until you open the font (what does it exactly mean?). OpenType is relatively consistent in terms of the spec. (Yamamoto)

Comments from font experts

• Can you “version up” fonts to add the ‘chws’ table? (Kida)
• Fonts can’t do version up because revised fonts might not produce exactly the same printing image. If we need to add a new feature it would be a new product with a new font name (Mizuno, Yamamoto)
• In case changes are small there are cases that we make a new revision of fonts. Different vendors have different policies (Yamamoto)
• They can’t revise fonts because fonts are distinguished by their name. There should be something other than name that would distinguish one revision from another (but we do not have such a thing) (kida)
• OS bundled fonts do not have such a restriction - new features can be added (Ishii, Kida). Well, Microsoft did it once and MS ended up providing an installer that lets customers to install old fonts (Yamamoto)

Are people expecting producing exactly the same image in ebooks??

• Publishers apply the same standard as printed books to ebooks. When such client asks us to fix a glyph (that does not match printing) we have no way other than resorting to “gaiji”. (Tajima)
• They should tolerate glyph variations that are unified to one code point (Yamamoto)
• Ebooks are rendered in variety of fonts / reader applications when they are on customer’s device. It is the nature of ebooks. Publishers needs to be aware of it. Probably it is a matter of literacy and education. Are there anything we can do at JLReq TF to fix the unrealistic expectations, e.g. by documenting expectations? (Kida)

Discrepancy of UTR#50 against AJ1 which is a de-facto of current fonts

• One thinking is that we could break compatibility once now (Ishii)
• Can we fix UTR#50? (Kida)
• The cause of inconsistent result is not very simple. There are cases, for example, a font is rotating a glyph incorrectly, and app is rotating it also incorrectly, creating perfectly fine result. We did a research internally in Adobe and found 8 different cases (Yamamoto)
• Can you share the document and make it public? (Kida). Will prepare the document by the next meeting (Nat)

Wrap up

• Our first goal is to understand issues and make it a document so it becomes a common understanding to tackle the issues (Kida)
• The next meeting is 5/18 10 am JST. Will discuss vertical orientation based on the document Adobe shares.

[kidayasuo]

Comment from Tajima-san after the meeting: He says even if it takes like 10-20 years to change all fonts/applications, we should be able to provide solution to limited areas such as EPUB readers (and OS's standard text).

Ishii-san responded that he agreed. Implementing punctuation spacing using chws and halt is straightforward.

「昨日聞かせていただいての感想的なものなのですが、OSやブラウザデフォルトレベルで日本語組版を正しく処理するのにはフォントを含めた最適化が必要でそれには10〜20年かかる、というのはよくわかったのですが、例えばEPUBのビューアのようなもっと小さな環境向けに「こういう処理が望ましい」という指針があればユーザーはその中ではいち早く最適化のメリットを享受できるのかな、と。その範囲なら使用されるフォントも絞り込めますし処理速度も問題にはならなさそうです。まあhontoやKinoppyなどの日本向けRSは既にやっていることですし、そのためにあるのがJLREQだと言われればその通りなのですが。」