JLReq TF meeting notes 2023-12-19

JLReq TF Meeting Notes <https://github.com/w3c/jlreq/issues/391> - December 19, 2023

Attendees

atsushi, kida, kobatake, murata, nat, shinyu, tajima, tlk, toshi, yamamoto, yamashige

Administrative Issues

Distinction between GitHub Issues and Discussions

Generally speaking, Discussions is more open-ended and does not need to have a clear outcome, while Issues are for when clear outcomes are needed. However, there isn't a strict separation. The approach will evolve with practice.
todo: Add screenshots to the Howto page (Shimonou) #390 <https://github.com/w3c/jlreq/issues/390>
Labels for GitHub Issue Status

There's a need for a way to indicate that consensus has been reached and further discussion isn't necessary, but the text hasn't been created yet, and it's not reflected in the document. Since GitHub Issues only have Open/Close states, this situation cannot be represented. Although using Projects was considered, the decision was to create labels.
todo: Create labels (Kida) #389 <https://github.com/w3c/jlreq/issues/389>
Structure of jlreq-d

Currently, it's divided into Chapter 1: Basics and Chapter 2: Details. At the same time, we discussed that the Chapter 1 is aimed at users, while Chapter 2 is for engineers, and it's not well-organized. After discussion, it was agreed to divide it into four parts for clarification. We'll review it after proceeding with writing in this structure.

How to Create Japanese Text
Japanese Layout
Accessibility
Features Required in Text Engines
todo: Re-edit the current text according to this structure (Kida)
Discussions

Nat: In the U.S., the creators of text are split into text creators and web designers. Kida: It's the same in Japan. Sometimes, web design involves using ready-made templates.
This structure is almost reflected in the new organization (Kida)
Kobayashi: Requirements and Recommendations are different. Kida: As a reflection on JLReq, defaults should be indicated, but in many cases, they should be Recommendations, not Requirements. The range of supported values is also crucial for accessibility. Murata: Considering accessibility, it's vital for users to be able to change defaults. It would be great if they can carry their settings in a device-independent manner. Professor Toshi: What kind of settings? Murata: For example, whether to write in separate words or not.
Kobayashi: When thinking in terms of layers, there's also the "consumer". Kida: If we create a chapter on that, what would we write?
Nat: The default for English is not always appropriate for Japanese, like line spacing. 120% is too narrow for Japanese. Professor Toshi: Who is the desired line spacing written for? → Both. It should explain that it's wider than in Western texts.
Font Families

The discussion is ongoing here <https://github.com/w3c/i18n-discuss/wiki/Generic-font-families>. Are there any typefaces from Japan that should be registered?

Kai style is used in Japan but not included in the description of kai. However, there is no Kai style in Apple's platform. Kida: Traditional typefaces that are hardly used digitally were not chosen.
Maru Gothic is desired, but round is defined in Font Level 4.
Kyokasho (textbook) typeface, derived from Kai, has become an established category of typeface. The shapes of Kanji are indicated by the Ministry of Education in the "Elementary School Kanji Learning Guidelines". Although there's no such official standard for Hiragana and Katakana, there is consistency among different vendors' Kyokasho fonts. These shapes differ from the original Kai style, as well as Mincho and Gothic styles. Kyokasho style exists on both Microsoft and Apple platforms.
todo: Propose kai and textbook styles at the link above (Kida) #388 <https://github.com/w3c/jlreq/issues/388>
Other Agendas Uncovered Due to Time Constraints

Redefinition of Inter-Character Classes for Japanese and Western Characters

Spacing Between Japanese and Western Characters #38 <https://github.com/w3c/jlreq-d/issues/38>
Full-Width/Proportional Issues

GitHub Issue Watch

Next Meeting: January 9

JLReq TF meeting notes 2023-12-19

Attendee

atsushi, kida, kobatake, murata, nat, shinyu, tajima, tlk, toshi, yamamoto, yamashige

管理的な問題

GitHub Issues と Discussions の使い分け

大雑把に言うと、Discussionsは結論の必ずしも必要のない自由なディスカッションで、Issueは明確な結果が必要。ただし明確な区切りがあるわけではない。運用しながら考えてゆく。
todo: Howto ページにスクリーンショットを加える（下農） #390 <https://github.com/w3c/jlreq/issues/390>
GitHub Issueの状態に対するラベル

コンセンサスが得られてそれ以上の議論は必要ないが、まだ文章は作られておらず、ドキュメントに反映されていない状態を示す方法が欲しい。GitHub IssuesにはOpen/Closeの二つしかないので、この状態を表すことができない。Projectを使う方法も検討したが、ラベルを作ることにする。
todo: ラベルを作る（木田）  #389 <https://github.com/w3c/jlreq/issues/389>
jlreq-d の構成について

現在、1章基礎、2章詳細、となっているが、1章はユーザー向け、2章はエンジニア向けという側面もあって、うまく整理できていない。議論ののち、これを四つに分けて以下のように明確化することで合意した。この方針で書き進んだのち見直す。

日本語テキストの作り方
日本語のレイアウト
アクセシビリティ
テキストエンジンに求められる機能
todo: 現在のテキストをこの構成に再編集（木田）
議論

Nat：米国では作る側の人が、テキストを作る人、Webデザイン、と分かれている。木田：それは日本でも同じ。Webデザインの部分は既製のテンプレートを使う場合もある。
この構造は上記の新しい構成にほぼ反映されている（木田）
小林：RequirementsとRecommendation は別。木田：JLReqの反省としてデフォルトは示すべきだが、多くの場合それはRecommendationであって、Requirementではない。またサポートすべき値の範囲はアクセシビリティに重要。村田：アクセシビリティを考えるとユーザーに許されるセッティングが非常に重要。設定をデバイス独立な形で持ち歩きたい。敏先生：どのような設定？村田：例えば分かち書きするかどうかなど。
小林：レイヤーとして考えると、「消費者」もある。木田：その章を作ったとして何を書く？
Nat：英語のデフォルトは日本語のデフォルトとして不適当な場合がある。例は行間。120%では日本語には狭すぎる。敏先生：望ましい行間は誰に対して書くか？→両方。欧文より広いよ、と説明。
フォントファミリー

ディスカッションがここで <https://github.com/w3c/i18n-discuss/wiki/Generic-font-families>行われている。日本から登録すべき書体はあるか？

楷書体は日本でも使われるが、kaiの説明には含まれていない。ただし、Appleのプラットフォームには楷書体はない。木田：デジタルでほとんど使われない伝統書体は選ばなかった。
丸ゴシックは欲しいが、Font Level 4でroundが定義されている。
教科書体は楷書から派生したが、確立された一つの書体カテゴリになっている。漢字の字形は文科省が「小学校学習指導要領 学年別漢字配当表」で示している。ひらがな・カタカナなそのような公的基準がないが、手で書くときの形として異なるベンダーからの教科書体の間でも安定している。これらの形はもとの楷書体、また明朝体やゴシック体と異なっている。教科書体はicrosoft/Apple双方のプラットフォームに存在する。
todo: 上のリンクに示されている場所に、kai と教科書体の提案をする（木田） #388 <https://github.com/w3c/jlreq/issues/388>
その他のagendaは時間切れでカバーできなかった

和欧文字間クラスの再定義

和欧文字間のアキ量 #38 <https://github.com/w3c/jlreq-d/issues/38>
全角/プロポーショナル問題

GitHub issueワッチ

次回ミーティングは1/9