JLReq TF meeting notes 2023-10-31

(English follows after its Japaneses translation (by chatGPT))

JLReq TF meeting notes 2023-10-31

議題

管理的なことがら
「全角」の概念の再考察と一般化；要約
文や行の始まりにおける開き括弧のスペース；要約
漢字と非漢字の間のスペースのための文字クラス；更新情報
ルビ用語（村田さん）
jlreq-d 第2章（レイアウト詳細）のレビュー
管理的なことがら

木田：ToDoをGitHubで管理したいと思います。また議論も焦点が明確なときはGitHub上での議論の方が良いです。一方で、GitHubはブレインストーミングのような議論には向いていないようです。ブレインストーミングは当面、メールで行うことにします。
敏先生：現在、jlreq-dのドラフトはWikiで作成され、議論はメールリストで行われています。コメントや変更履歴を追跡するのは簡単ではありません。もっと良い方法はありますか？　木田：Wikiで変更履歴を見ることができます。Google documentにはより優れた変更追跡機能があります。それが選択肢になるかもしれません。ラフドラフトの段階であって多くの書き直しがある間は、GH issueで管理するのは難しいです。進めながら選択肢を探しましょう。
木田：会議ノートを生成するための録音／書き起こし／自動要約の試みはうまくいきませんでした。手書きで会議ノートを作成するのと同じくらいの時間が必要でした。
todo：木田が保留中のToDoをGH issueに変換する (#383 <https://github.com/w3c/jlreq/issues/383>)
todo：木田（と全員）ドラフトレベルの文書を管理するためのより良い方法を探る (#384 <https://github.com/w3c/jlreq/issues/384>)
全角の概念の再考察と一般化（jlreq-d #35）

メールリストでの広範な議論の後、現在の合意は「全角」をU+3000 IDEOGRAPHIC SPACEの幅に従って定義することです。この定義は、漢字と仮名で幅が変わるフォントに期待される全角スペースの幅と一致しています。そのようなフォントの例には、MS P明朝/ゴシックやAXIS Condensedがあります。これらのフォントでは、U+3000は仮名文字の幅と一致するか、それに近いです。
JLReqの文書では、伝統的に「全角」という用語は、すべての文字が正方形で均一なサイズであるという仮定の下で使用されていました。しかし、この定義は、文字が長方形であったり、漢字と仮名の間でサイズが異なるようなシナリオを含むように一般化する際に問題となります。「全角」の多義性を解決する必要があり、そのようなフォントをカバーするレイアウトの説明を一般化するためです。提案された定義は、「全角アキ（一エムスペース）」として期待される幅を反映しています。他の「全角」の典型的な使用には、文字の幅（現在は変動）や行の進行幅が含まれます。
さらなる議論はjlreq-d #35で行うべきです。
文や行の始まりにおける開き括弧のスペース（jlreq-d #37）

文や行の始まりにおける開き括弧のスペースに関しても、メールリストで広範な議論が行われました。
結論は以下の通りです：
論理的なデフォルトのスペースはツメであり、つまり文の始まり、折り返し行、リストなどのテキストの始まりにおける開き句読点の前の半エムスペースを取り除くことを意味します。これはインデントされた文体と空行文体の両方に適用されます。
それにもかかわらず、異なるハウススタイルや好みもあり、それらも尊重されるべきです。注意すべき点は、これらのハウススタイルはインデントされた文体を前提としているため、ウェブ上のデフォルトである空行で段落を区切るスタイルには必ずしも適用されないということです。
ウェブ上でのデフォルトが何であるべきかについての議論は、互換性の要件のために異なる問題です。
詳細な議論がjlreq-d #37にあります。またさらなる議論はjlreq-d #37を使用するべきです。
漢字と非漢字の間のスペース

漢字と他の文字の間のスペースを制御する文字クラスの定義に関する議論があります。例えば CSSWG#9479 や CSSWG#9503 などがあります。
木田は提案された定義とjlreq-dのスペーシングプロパティを比較し、いくつかの違いを発見しました。SSWG#9503に報告しました。
更新情報：石さんはこの目的のためにUnicode文字クラスを提案したいと考えています。私も共著者になります。JLReqとjlreq-dのスペーシングプロパティは、連続する句読点の間の余分なスペースを取り除くことと、漢字と非漢字の文字の間にスペースを追加することの両方を説明しています。提案は後者に焦点を当てます。この二つは異なるロジックで実現されているので jlreq-d でも分離することを検討するのが良いでしょう。
特定のケースを追跡するためのいくつかの問題を作成しました
和欧間スペース：丸つき文字 #41
和欧間スペース：組文字（㌀㎏）#42
和欧間スペース：絵文字 #43
和欧間スペース：フットマーク用の記号 *†‡◊ #44
ルビ用語（村田さん）

データ：プレゼンテーションとウィキ
jlreq-dのルビレイアウト記述において、モノ、グループ、熟語ルビを使用しないことに決定しました。これらの用語は、基本テキストが漢字の文字列で、ルビ注釈が仮名の文字列であるという前提を持っています。jlreq-dでのルビレイアウトを一般化し、基本テキストやルビ注釈に使用されるスクリプトに関する前提を持たないようにしたいと考えています。これらの用語は副次的なメモで触れられます。
用語に関する残る問題は、基本テキストとルビ注釈の組み合わせに名前を定義するかどうかです。木田：折りたたみ可能なルビの提案を作成したとき、その用語の必要性を感じることがよくありました。敏先生：JIS X 4051では「親文字群（基本テキスト群）」という用語が使用されていました。- 結論なし
村田：関連する話題として、「rb/rb/rt/rt」と「rb/rt/rb/rt」についての用語が必要かどうか？それらが結果としてのレイアウトでどのように異なるかはわかりません。todo：明確にする必要があります。
村田：「ルビ」と言うとき、それは何を意味しますか？時には添付された注釈を説明するために使用され、時には全体としての機能を意味します。注釈部分は「ルビ注釈」と呼ぶべきです。
パラルビとソウルビについて、JLReq TFの人々は、そのまま使用できると考えています。
todo：村田がウィキを更新し、「rb/rb/rt/rt」と「rb/rt/rb/rt」の間に意味の違いがあるかどうかを明確にし、clreqにフィードバックを求める (#385 <https://github.com/w3c/jlreq/issues/385>)
jlreq-d第2章のレビュー

敏先生：どのスタイルを使用すべきか確信がありません。
全ての資料を集めた後に考えましょう。
次回の会議

ナットが町にいるので、次回の会議は11月24日に対面で行われます。敏先生がミーティング会場と食事会の会場を予約してくださいました。
––––––––––––––––––––––
Agenda

Administrative matters
Revisiting and generalising the concept of fullwidth; summary
Spacing of open parenthesis at the beginning of a sentence or a line; summary
Character classes for spacing between ideographs and non-ideographs; updates
Ruby terminology (Murata-san)
Reviewing jlreq-d the second chapter (layout details)
Administrative matters

Kida: I would like to manage todo’s using GitHub. Discussions are better done on GitHub, especially when they have a clear focus. In contrast GH does not seem to be good at brainstorming kind of discussions; brainstormings will continue to be done on mail for now.
Bin-sensei: Currently the jlreq-d draft is done on Wiki and discussions are done on the email list. It is not easy to track comments and the change history. Is there a better way? kida: You can look at change history on Wiki. Google docs has a better change tracking feature. So it might be an option. While we are in a rough draft mode and there are many rewrites it is hard to manage them on GH issue. Let’s explore options while we move on.
The trial of recording / transcribing / auto-summarising to generate meeting notes did not go well. It needed similar time compared to creating meeting notes by hand.
todo: Kida will turn pending todos to GH issue (#383 <https://github.com/w3c/jlreq/issues/383>)
todo: Kida (and all) explore if there is a better way to manage draft level documents (#384 <https://github.com/w3c/jlreq/issues/384>)
Revisiting and generalising the concept of Zenkaku (jlreq-d #35 <https://github.com/w3c/jlreq-d/issues/35>)

After extensive discussions on the email list, the current agreement is to define ‘Zenkaku’ following the width of U+3000 IDEOGRAPHIC SPACE. This definition aligns with the width of Zenkaku space expected by fonts that have varying widths between Kanji and Kana characters. Examples of such fonts are MS P Mincho/Gothic, and AXIS Condensed. In these fonts, U+3000 matches or closely approximates the width of Kana characters.
In the JLReq documentation, the term 'Zenkaku' has traditionally been used under the assumption that all characters are square-shaped and of uniform size. However, this definition becomes problematic when generalizing to scenarios where characters are rectangular and/or vary in size between kanji and kana. The overloading of 'Zenkaku' needs to be resolved in order to generalize the layout descriptions to cover such fonts. The proposed definition reflects the expected width for “Zenkaku Aki (one em space)”. Other typical use of ‘Zenkaku’ includes width of characters (which now varies), and line advance width.
Further discussion should be done on jlreq-d #35. <https://github.com/w3c/jlreq-d/issues/35>
Space before open parenthesis at the beginning of a sentence and a line (jlreq-d #37 <https://github.com/w3c/jlreq-d/issues/37>)

There was also an extensive discussions on the email list regarding the spacing of open parenthesis at the beginning of a sentence or a line.
Conclusions are:
The logical default spacing is ツメ, i.e. removing preceding ½ em space before opening punctuations at the beginning of text such as beginning of sentences, folded lines and lists. This applies to both indented and blank line sentence styles.
Nonetheless there are different house styles and preferences and they should also be honoured. One piece of caution is that these house styles assume indented sentence style and therefore they do not necessarily applicable to blank line sentence style, which is the default on the web.
The discussion of what should be the default on the web is a different issue because of compatibility requirements.
Further discussions should use jlreq-d #37 <https://github.com/w3c/jlreq-d/issues/37>.
Space between ideographs and non-ideographs

There are discussions regarding definition of character classes that controls spacing between ideographic and other characters. such as CSSWG#9479 <https://github.com/w3c/csswg-drafts/issues/9479> and CSSWG#9503 <https://github.com/w3c/csswg-drafts/pull/9503>.
Kida compared the proposed definition and jlreq-d’s spacing property <https://github.com/w3c/jlreq/blob/gh-pages/docs/spacing_property/spacing_property.md> and found some differences. Reported it on SSWG#9503 <https://github.com/w3c/csswg-drafts/pull/9503>. 
update: Ishi-san wants to propose a Unicode character class for this purpose. I will be a co-author. JLReq and jlreq-d’s spacing property <https://github.com/w3c/jlreq/blob/gh-pages/docs/spacing_property/spacing_property.md> describes both removing extra space between consecutive punctuations, and adding space between ideograph and non-ideograph characters. The proposal will focus on the latter.
Created a few issues tracking specific cases
和欧間スペース：丸つき文字 #41 <https://github.com/w3c/jlreq-d/issues/41>
和欧間スペース：組文字（㌀㎏）#42 <https://github.com/w3c/jlreq-d/issues/42>
和欧間スペース：絵文字 #43 <https://github.com/w3c/jlreq-d/issues/43>
和欧間スペース：フットマーク用の記号 *†‡◊ #44 <https://github.com/w3c/jlreq-d/issues/44>
Ruby terminology (Murata-san)

data: 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>
We have decided not to use Mono, Group and Jukugo Ruby in ruby layout descriptions in jlreq-d because these terms have an assumption that the base text is a string of Kanji and the ruby annotation is a string of Kana. We want to generalise the ruby layout in jlreq-d so it does not have assumptions on the script used for the base or the ruby annotation. These terms will be touched on in side notes.
Remaining issue regarding the terminology is if we define a name for the combination of the base text and ruby annotation. Kida: When I drafted a proposal of line-foldable ruby I often felt the need for the term. Bin-sensei: the term ‘Oyamoji-gun (base text group)’ was used in JIS X 4051. - no conclusion
Murata: related to the topic do we need a term for “rb/rb/rt/rt”and “rb/rt/rb/rt” ? I do not know if they are differ in the resulting layout. todo: need to clarify.
Murata: When we say “ruby” what does it mean? It was sometimes used to describe the annotation attached, and sometimes it means the feature as a whole. The annotation part should be called “ruby annotation” for clarify.
For para-ruby and sou-ruby, JLReq TF folks thinks they can be used as-is.
todo: Murata to update the wiki, clarify if there are semantic difference between “rb/rb/rt/rt”and “rb/rt/rb/rt”,  and contact clreq for feedback (#385 <https://github.com/w3c/jlreq/issues/385>)
Reviewing jlreq-d the second chapter

Bin-sensei: Not sure about the style it should use.
Let’s think after we gather all materials.
Next meeting

As Nat is in town the next meeting will be face to face on Nov. 24.