JLReq TF Meeting Notes 2023-4-11

https://github.com/w3c/jlreq/issues/361



JLReq TF Meeting Notes 2023-4-11
Atendees

atsuda, atsushi, kida, makoto, shinyu, suzuki, tahara, tajima, tlk, toshi

（下記は、下の方にある英語のオリジナルを流行りの ChatGPT を使って翻訳したものです。面白かったのでそのまま載せました。deepl より良い感じです。翻訳のおかしなところはやはりありますので、あれ？と思ったら英語を参照してください。人の名前は不得意のようです。特に Shimono-san は、下記さん、になったり、下嶋さん、になったりと酷かったので、途中で、下農さんですよ、と指摘したら、謝罪して、以降ちゃんとしてくれました。このように、訳語の指定ができるようなので、それをちゃんとすれば翻訳の質を上げられそうです。長すぎると途中までしか翻訳してくれないので、いくつかのブロックに分けて入力しました。）

CJK字間調整 - OpenType仕様の明確化に向けた改善
「palt」は、全角のCJKグリフをプロポーショナルにする機能です。OpenType仕様における「palt」機能の説明は、「kern」機能との相互作用に関して誤解を招くものです。意図としては、「CJKグリフに対して」、「kern」がオンのときに「palt」もオンにするべきです。「CJKグリフに対して」という部分が仕様説明に欠けています。すべての既知のフォントは、Adobeの追加仕様に直接または間接的に従うことで、意図を正しく実装しています。ただし、「palt」を適用せずに「kern」を適用することを意図した異なる実装が存在する可能性があります。

アプリケーション側の実装は、仕様の解釈によっては望ましくない結果が生じるため、一貫性がないことが知られています。Fantasaiはfont-kerningプロパティを拡張することを提案 <https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1411487571>しており、作者がそれらを独立して制御できるようになります。また、石井さんは、OpenType仕様でこれを明確化することを提案 <https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1420204843>しています。CITPCは、ISO SC29が管理するOpen Font Format仕様に変更リクエストを提出する予定です。

議論（フォローアップメールを含む）とアクション：
仕様の明確化が必要であることにすべての関係者が同意しています。ただし、JLReq TFメンバー間で、どのように明確化すべきかについての合意はまだありません。主な意見の相違は以下の2つのアプローチの間で生じています。
A: 仕様は意図に沿って明確化されるべきです。
B: 仕様は、存在するかもしれない代替実装を含めて策定されるべきです。
「意図された」フォント実装では、「palt」テーブルでプロポーショナル化されたCJKグリフを使って「kern」テーブルを設計します。すべての既知のフォントがこの実装に従っています。代替の実装では、「palt」テーブルを持ちながらも、「kern」テーブルを全角のCJKグリフで設計します。
新機能として、石井さんは、全ての日本語フォントで全角のCJKグリフのカーニングを可能にしたいと考えています。彼が提供した例では、「す」と「。」の間にカーニングを行いたいと考えるデザイナーがいることを示していますが、それらをプロポーショナルにはしないでください。
CITPCは、ISO SC29に「palt」仕様の説明の改善に向けた提案の可能性を問い合わせました。
木田さんは、石井さんやCITPCと業界全体の調査を行い、「palt」と「kern」の相互作用に関するフォント実装について議論しています。

シンプルルビ文書 - 2レベル処理の説明を改善
下記さんが議論を主導し、改訂されたテキストの提案を考案しました。ビン先生は、周囲のスペース文字を考慮してさらに改善したいと考えています。ビン先生はテキストを作成する予定でした。
アクション:
ビン先生が提案を作成（完了）。下記さんがテキストを更新し、レビューのために提出し、変更をマージする（完了）。
5/2の次回会議でWDの更新について合意したいと考えています。そのために、その時までにすべてのPRを処理したいと考えています。
その他の議論
シンプルルビでは「ルビのはみ出し」を行いません。一方、SafariやChromeの実際の実装では行われています。これについてどう思われますか？（村上さん）シンプルルビは最小要件を定義しているので、それ以上のことをするのは問題ありません（木田さん）。JLreqではより高度な方法が説明されています。また、その付録にはさらに洗練された技術があります（ビン先生）。両方のレベルをJLReq-dに入れましょう（木田さん）。印刷では紙の使用を最小限に抑えたいため、はみ出しにはメリットがありました。ビン先生は、デジタルでまだ利点があるかどうか確信が持てません（ビン先生）。JLReq-dでそのような議論を情報テキストとして追加しましょう（木田さん。jlreq-d＃28）。
一見、1/4のはみ出しは、はみ出しが主に文字間のスペースにあるため、はみ出していないように見えます。漢字を含むすべての文字で、このような小さく一定のはみ出しを許可するスタイルがあります（ビン先生）。

長いルビの折り畳み
長いルビは、行内での改行が禁止されているため、非常に短い行などのレイアウトの問題を引き起こすことがあります。印刷では、人間の目や校正作業でレイアウトの問題が解決されました。しかし、デジタルテキストでは、すべてが自動化されており、そのような人間の目は存在しません。木田さんは、JLReq-dで長いルビを折り畳み可能にする提案を考案しました。しかし、ルビブロック内での可能な改行の機会を見つけることは、ほとんどのアプリケーションにとって計算コストが高くなります。別のアプローチが必要です。ビン先生は、一般的な注釈として処理することを提案しました。

今回の会議でのアクションはありません。木田さんはもう少し考える時間が必要であり、提案を修正する必要があります。

JLReq-d目次の改訂案
木田さんは、4/11に目次の下書きの最初のセクションを更新し、リストに送りました。最初のセクションでは、日本語の事前知識がなくても、コンテンツクリエーターや実装者向けの基本事項をカバーしています。

議論/カバーすべき追加トピックの可能性
一般
印刷とデジタルの適切な違い。
テキストデータのガイドライン。例えば、プロポーショナルと全角の括弧の使い方、ラテン文字の単語の前後にスペースを追加すべきかどうかなど。
入力方法の役割。例えば、句読点など。
最初のセクションでは基本事項をカバーすることになります。しかし、「基本」を超えるトピックがあってもコンテンツクリエーター向けにカバーすべきであれば、実装者向けの詳細をカバーするセクションと同様に、専用のセクションを作成することがあります。
文字
常用漢字は、固有名詞を除いて、日常的な使用に十分です（これを言及する目的は何ですか？木田さんがビン先生に確認する）。
デジタル独自の文字をカバーする。例えば、全角/半角文字、ラテン/日本語の類似句読点など。
中国語/韓国語の漢字の違い。


（ここで、「である調を使って」と ChatGPT にお願いした）

書体
画面上の可読性。アクセシビリティの考慮事項である。
漢字、仮名、ラテン文字の異なる書体の使用。例としては、仮名の小さいバージョンと大きいバージョン、無地の漢字と組み合わせて使用された「アンティーク」な仮名書体がある（ビン先生）。
本文の書体とタイトルやディスプレイ用の書体（田島）。
レイアウトの基本
漢字と仮名のリズム
ベースラインシステムを用いたレイアウト
数学やその他の日本語以外の要素（範囲外）
縦書き
両方の方向に対応したテキストデータを作成するためのガイドライン
注釈
印刷では固定ページを前提とした注釈方法があるが、リフロー可能なデジタルメディアでは必ずしもうまく機能しない（田島）。デジタルでは、ポップアップやリンクなど、さまざまな新しい方法が可能である。デジタルへの移行によって最も影響を受ける分野の1つである。
ウィキペディアでは、デスクトップ版とモバイル版で注釈UIの形式が異なる。しかし、現在のHTML/cssでは、クライアントのデバイスに応じてUIを最適化しながら、注釈を一貫してマークアップする良い方法がない（鈴木）。


（が、次のブロックではですます調に戻ってしまった）


両方向に対応したウェブページを作成するためのガイドラインは？
両方向に対応したウェブページを作成するためのガイドラインに関する議論があります。下嶋さんは3/22に「縦横切替想定時のCSSのbest practices」というタイトルのメールを送りました。このメールスレッドと次回の会議で議論しましょう。

最適なベースライン位置と調整
下嶋さんは、css WGでJLReq TFからの意見が必要な保留中の議論を指摘しました。
木田さんは、彼とこの件について話し合い、フォローアップします。


（ここで「Shimono-san は下農さん、です。またずっと「である調」を使ってください」とお願いした）


失礼しました。訂正いたします。

新規および保留中のタスク
木田がclreqとのミーティングを設定する： 木田は、縦書きテキストの方向におけるウェブフォーム要素のデフォルトの方向（上または下）について話し合うために、clreqとのミーティングを設定する必要がある。
村田さんがruby-t2s-reqsドキュメントを更新する： 村田さんは、ruby-t2s-reqsドキュメントを更新する必要がある。
木田が下農さんに最適なベースライン位置と調整についてフォローアップする： 木田は、最適なベースライン位置と調整に関して、下農さんにフォローアップする必要がある。
次回のミーティング（5/2）で（またはその前に）グループは以下のことを行う：
「palt」仕様に関する議論についての解決策を見つける。
シンプルルビーWDの次の改訂版を公開する準備ができているかどうかを判断する。
両方の方向に対応したウェブページを作成するためのガイドラインと、ベースライン問題に対して行いたいことがあるかどうかを議論する。
次回のミーティングは5月2日です。

下農さんは、新しいURLをグループに送信する（完了済み）。


–––––––––––––––––––––––––––––––––––––––––––––––––––––––
JLReq TF Meeting Notes 2023-4-11
Atendees

atsuda, atsushi, kida, makoto, shinyu, suzuki, tahara, tajima, tlk, toshi

CJK kerning - Improving the OpenType spec for clarification.

The ‘palt’ is a feature that turns fullwidth CJK glyphs proportional. The description of the ‘palt’ feature in the OpenType specification is misleading regarding its interaction with the ‘kern’ feature. The intention is that “for CJK glyphs”, ‘palt’ should be turned on when ‘kern’ is turned on. The “for CJK glyphs” is missing from the spec description. All known fonts follow the intention correctly, most likely because they directly or indirectly follow additional specs from Adobe. Different implementations, however, could exist which intend to apply ‘kern’ without applying ‘palt’, i.e. without making them proportional.

Implementations on the application side are known to be inconsistent, presumably because depending on how they interpret the spec, it can result in undesired results. Fantasai proposed to extend the font-kerning property  <https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1411487571>to allow authors to control them independently. Also, Ishii-san proposed to clarify this in the OpenType specification <https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1420204843>. CITPC plans to submit a change request to the Open Font Format specification managed by ISO SC29 through the Japan mirror of the SC29 committee.

Discussions (including follow-up emails) and actions:

All agree that the specification needs to be clarified. However, there has yet to be an agreement between JLReq TF members on how it should be clarified. The disagreement seems to be mainly between the following two approaches:
A: The specification should be clarified according to the intention.
B: The specification should be formulated, including an alternative implementation that might exist.
The ‘intended’ font implementation is that they design the ‘kern’ table with CJK glyphs proportionalised by the ‘palt’ table. All known fonts follow this implementation. The alternative implementation designs the ‘kern’ table with fullwidth CJK glyphs while still having the ‘palt’ table.
As a new feature, Ishii-san desires to make kerning of fullwidth CJK glyphs possible with all Japanese fonts. An example he provided is that he knows a designer who wants to kern between ‘す’ and ‘。’ without making them proportional.
CITPC pinged ISO SC29 for a possible proposal for improving the ‘palt’ spec description.
Kida is discussing with Ishii-san and CITPC for industry-wide research on the font implementation regarding the ‘palt’ and ‘krern’ interaction.
Simple-ruby document - improving the description of the two level processing

Shimono-san led the discussion and devised a proposal for the revised text. Bin-sensei would like to improve it further to consider surrounding space characters. Bin-sensei was to come up with the text.

Actions:

Bin-sensei to come up with a proposal (done). Shimon-san to update text, submit for review and merge the change (done).
We would like to agree on the update of the WD at the next meeting on 5/2. To this end, we would like to process all PRs by that time.
Other discussions

The simple-ruby does not do ‘ruby overhang’. On the other hand, actual implementations on Safari / Chrome does. Are there thoughts on this? (Murakami) As the simple-ruby defines the minimal requirements, doing more is OK (Kida). JLreq describes a more advanced method. Also, its appendix has an even more refined technique (Bin-sensei). Let’s put both levels in JLReq-d (Kida). With print, you want to minimize the use of paper, so overhanging had its merit. Bin-sensei is unsure if it still has benefits on digital (Bin-sensei). Let’s add such a discussion as an informative text in JLReq-d (kida. jlreq-d #28)
1/4 overhang at a glance does not look overhanging because the overhang is mainly on the space between characters. There is a style that allows such a small and consistent overhang on all characters, including Kanji (Bin-sensei)
Folding long ruby

Long ruby can cause layout issues such as very short lines because line breaking is prohibited within. On print, human eyes and proofreading resolved the layout issues. Such human eyes, however, do not exist with digital text, where everything has to be automatic. Kida came up with a proposal to make long ruby foldable for JLReq-d. However, finding possible break opportunities within a ruby block can be computationally expensive for most applications. An alternative approach is necessary. Bin-sensei proposed to process them as a general annotation.

No actions at this meeting. Kida needs more time to think, and revise the proposal.

Revised draft of JLReq-d TOC

Kida updated the first section of the draft TOC and sent it to the list on 4/11. The first section covers the basics for content creators and implementors who do not necessarily have prior knowledge of the Japanese language. Discussions / Possible addional topics to cover

General
Differences between print and digital where appropriate.
Guidelines for text data, e.g. how to use proportional and fullwidth parenthesis, if a space should be added before and after words in Latin characters, etc.
Possible roles of input methods, e.g. for punctuation
The first section is to cover basics. If there are topics that are beyond ‘basic’ but shold be covered for content creators, we might want to create a separate section that are specifically dedicated for conent like we will have sections that cover details for implimentors.
Characters
Joyo Kanji is sufficient for the day by day use, exept for proper nouns. (what is the purpose of mentioning this? kida to check with Bin-sensei)
Cover characters that are unique to digital such as fullwidth / halfwidth characters, and similar punctuations between Latin / Japanese.
Differences between Chinese / Korean Kanji.
Typefaces
Readability on screen. Considerations for accessibility.
Use of different typefaces for Kanji and Kana and Latin. Examples are small and large versions of Kana, and “antique” Kana typeface that was used in conbination with sans-serif Kanji (Bin-sensei)
Typefaces for the main body text and titles or display typeface (Tajima).
Layout basics
Rythm between Kanji and Kana
Layout with the baseline system
Math and other non-Japanese elements (which are out of scope)
Vertical text
Guidelines for creating text data that are compatible to both directions
Annotations
Annotation methods on print assumes fixed pages; they do not necessarily work well on reflowable digital media (Tajima). Variety of new methods such as popup and link are possible with digital. It would be one of the most affected area by the transition to digital.
Wikipedia has different form of annotation UIs between the desktop and mobile. Currently however there is no good way in HTML/css to consistently markup annotations while optimizing the UI depending on the clients’ device (Suzuki).
Guidelines for creating web pages that are compatible to both orientations?

Following the previous meeting: there is a discussion regarding creating some guidelines for creating web pages that are compatible with both directions. Shimono-san sent a mail on 3/22 with the title “縦横切替想定時のCSSのbest practices”. Let’s discuss this on this mail thread and at the next meeting.

Optimal baseline position and adjustments

Shimono-san pointed out a pending discussion in css WG that needs input from JLReq TF. Kida to discuss this with him and follow up.

New and pending todos

Kida to setup a meeting with clreq to discuss re:default direction (up or down) of web form elements in vertical text direction.
Murata-san to update ruby-t2s-reqs document.
Kida to follow up with Shimono-san re:Optimal baseline position and adjustments.
At (or by) the next meeting on 5/2 the group would:
Find a resolution on the ‘palt’ spec discussion.
Decide if we are ready to publish the next revision of the simple-ruby WD.
Discuss if/what we want to do with guidelines for creating web pages that are compatible to both orientations, and the baseline issue.
Next meeting is on 5/2

Shimono-san to send out new URL to the group (done).

//