JLReq TF Meeting Notes - 2023-10-10

(日本語は英語の後ろにあります)

JLReq TF Meeting Notes - October 10, 2023

Attendees: atsuda, atsushi, kida, kobatake, murata, nat, shinyu, suzuki, tajima, taro, tlk, toshi, yamashige

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Agenda

Ruby Terminology (Murata)
WCAG Updates (Murata)
Definition of Full-width (Kida)
Miscellaneous Topics
Next Meeting
Ruby Terminology

Murata-san explained that the terminology related to ruby annotation is not standardized, causing confusion. A few years ago, Murata, along with Florian, Erika, and Shimono, started working on solving this issue. They created a presentation <https://docs.google.com/presentation/d/1x-cIsFinp4MKQkNve4UWAQ0_GTR22hX2PwIYc6MrOS4/edit#slide=id.g122e38f3b6d_0_50> and a wiki <https://github.com/w3c/jlreq/wiki/English-ruby-terminology>, but the discussion was halted. Murata would like to restart the discussion. As JLReq, we would like to discuss it with clreq since ruby is also used for bopomofo.
Todo: We will discuss the topic at the next meeting before inviting clreq to the discussion. Everyone, please take a look at the presentation and wiki for preparation.

WCAG Updates

Murata-san reported that WCAG 2.2 was officially promoted to Recommendation (REC). He believes it would not have any adverse effects on vertical text, even though it did not cover it. Kida believes the biggest achievement of raising the issue is that there was an agreement between the WCAG team and I18N WG to cooperate on internationalising 3.0.

Definition of Full-width

Background: Currently, the definition of the term "zenkaku" (full-width) in JLReq assumes a square character frame; the same term can refer to both horizontal and vertical length. The term 'zenkaku' is also used to describe a character frame as square, as in 'zenkaku characters'. The issue is that the layout in JLReq is described using zenkaku as the base unit, excluding typefaces that have a non-square character frame. The goal of the discussion is to streamline the terminology used, allowing us to generalize the layout description in jlreq-d. Although it is not the focus of this particular discussion, our ultimate goal should be to describe the layout for typefaces with proportional kana and fixed-width Kanji, such as fonts bundled with Microsoft Windows.

There was no conclusion at the meeting. The ongoing discussion on the mailing list is showing some divergence; the proposal from Bin-sensei and the definition of the 'ic' value in CSS agree on their important points.

Other Topics

Chapter 2 "Layout Details"

Bin-sensei drafted the content of chapter 2 "Layout details." He is not sure how it should be written. We still do not have a clear idea of exactly what should change in jlreq-d and its style. We need to resolve this as we proceed.
Todo: We will review it at the next meeting. Everyone, please read the chapter 2 draft and add comments if possible.

A Chat About Converting Between Horizontal and Vertical Text

Bin-sensei explained that there aren't many problems with changing the text direction from vertical to horizontal. Converting horizontal to vertical is more challenging, as there are styles that are not optimal for the vertical direction.

Bin-sensei uses different styles for vertical and horizontal text. For horizontal text, he uses FULLWIDTH COMMA/FULL STOP instead of IDEOGRAPHIC COMMA/FULL STOP and avoids using CORNER BRACKETS. He explained that the number of people using styles specific to horizontal text is decreasing. For example, the government's style rules for horizontal text transitioned from FULLWIDTH COMMA/FULL STOP to IDEOGRAPHIC COMMA/FULL STOP, making it consistent across directions.

Tokyo Newspaper recently started using Arabic numbers for vertical text.
C.F. 数字表記で4苦8苦 <https://note.com/kotoba_no_genba/n/n5a53ab17d335>
Re: text-spacing-trim: trim-all <https://github.com/w3c/jlreq/issues/377>
Todo: Bin-sensei will add a note in Japanese. Kida will post the translation (done).

The Next Meeting is on October 31st (Tue).

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
議題

ルビの用語 (村田)
WCAG の最新情報 (村田)
全角の定義 (木田)
その他のトピック
次回ミーティング
ルビの用語

村田さんは、ルビ注釈に関連する用語が標準化されていないため、混乱が生じていることを説明しました。数年前、村田さんはFlorian、Erika、Shimonoと共に、この問題の解決に取り組み始めました。彼らはプレゼンテーション <https://docs.google.com/presentation/d/1x-cIsFinp4MKQkNve4UWAQ0_GTR22hX2PwIYc6MrOS4/edit#slide=id.g122e38f3b6d_0_50>とウィキ <https://github.com/w3c/jlreq/wiki/English-ruby-terminology>を作成しましたが、議論は中断しました。村田さんは議論を再開したいと考えています。私たちJLReqとして、bopomofoにルビが使用されているため、clreqとも議論したいと考えています。
Todo: 次回のミーティングでトピックを議論し、clreqを議論に招待する前に、皆さん、準備としてプレゼンテーションとウィキをご覧ください。

WCAG の最新情報

村田さんは、WCAG 2.2が正式に推奨事項(REC)に昇格したことを報告しました。彼は、それが縦書きに悪影響を及ぼすことはないと信じていますが、縦書き自体はカバーされていません。木田さんは、私たちがこの問題を提起した最大の成果は、WCAGチームとI18N WGの協力に合意があったことだと考えています。これにより、3.0の国際化が推進されることになります。

全角の定義

背景: 現在、JLReqの「全角」という用語の定義は、正方形の文字枠を前提としています。つまり同じ用語が水平と垂直のサイズの両方を指します。「全角」という用語は、例えば「全角文字」という言葉のように、文字枠を正方形であること自体を表すのにも使用されます。問題は、JLReqのレイアウトが基本単位として「全角」を使用して記述されているため、正方形の文字枠を持たない書体が除外されていることです。議論の目標は、使用される用語を合理化し、jlreq-dでレイアウトの記述を一般化できるようにすることです。この特定の議論の焦点ではないものの、最終的な目標は、Microsoft Windowsにバンドルされているようなプロポーショナル仮名と固定幅漢字を備えた書体のレイアウトを記述することです。

ミーティングでは結論は出ませんでした。メーリングリストでの継続的な議論では、Bin-senseiからの提案とCSSでの 'ic' 値の定義が重要なポイントで一致しています。

その他のトピック

第2章「レイアウトの詳細」

Bin-senseiが第2章「レイアウトの詳細」の内容を草案としました。彼はそれがどのように記述されるべきかよくわかりません。私たちはまだjlreq-dで何が具体的に変更されるべきか、そのスタイルについては明確なアイデアを持っていません。進行中の議論を解決する必要があります。
Todo: 次回のミーティングでそれを見直します。皆さん、第2章の草稿を読んで、可能であればコメントを追加してください。

水平と垂直テキストの変換に関するチャット

Bin-senseiは、テキストの方向を垂直から水平に変更する際には多くの問題がないことを説明しました。水平から垂直への変換は、垂直方向に最適でないスタイルがあるため、より難しいです。

Bin-senseiは、垂直と水平で異なるスタイルを使用しています。水平テキストではIDEOGRAPHIC COMMA/FULL STOPの代わりにFULLWIDTH COMMA/FULL STOPを使用し、CORNER BRACKETSを使用しないようにしています。彼は、水平テキストに特有のスタイルを使用する人々の数が減少していると説明しました。例えば、政府の水平テキストのスタイルルールはFULLWIDTH COMMA/FULL STOPからIDEOGRAPHIC COMMA/FULL STOPに変わり、方向に関係なく一貫性があります。

東京新聞は最近、垂直テキストにアラビア数字を使用し始めました。
参照: 数字表記で4苦8苦 <https://note.com/kotoba_no_genba/n/n5a53ab17d335>
Re: text-spacing-trim: trim-all <https://github.com/w3c/jlreq/issues/377>
Todo: Bin-senseiが日本語でノートを追加します。木田さんが翻訳を投稿します(完了)。

次回のミーティングは10月31日(火)です。
//

Received on Tuesday, 17 October 2023 11:01:13 UTC