JLreq TF meeting notes 2024-2-6

https://github.com/w3c/jlreq/discussions/414
（日本語は英文の下に）

JLreq TF meeting notes 2024-2-6

attendee

atsushi, kida, kobatake, makoto, nat, shinyu, suzuki, tajima, taro, tlk, toshi, yamashige

Revising the JLReq document

#395 Publish new version of jlreq? <https://github.com/w3c/jlreq/issues/395>
Fuqiao suggested to update the JLReq document since several fixes are ready in the queue. Kida agrees. It would be a good idea to include fixes of most if not all remaining issues that we are intending to address in JLReq. As JLReq is in the maintenance mode, we are only fixing errors. Enhancements will be considered for jlreq-d, Kida commented.

#154 <https://github.com/w3c/jlreq/issues/154>: Need a systematic way of assigning ID to elements (sections of a document). → Not for JLReq. Will evaluate for jlreq-d. Kida commented.
#311 <https://github.com/w3c/jlreq/issues/311>: Usabilitty issues related to switching languages. Blocked by #264 <https://github.com/w3c/jlreq/pull/264> と #262 <https://github.com/w3c/jlreq/pull/262>. Shimono-san to evaluate if we want to fix it in JLReq.
todo

Bin-sensei to send issues that he recognizes (done). → #399 <https://github.com/w3c/jlreq/issues/399> → all fixed and closed.
kida to review #322 <https://github.com/w3c/jlreq/pull/322> and #396 <https://github.com/w3c/jlreq/pull/396> (done)
Shimono-san to merge possible editorial fix of English? #322 <https://github.com/w3c/jlreq/pull/322> and Make the Japanese and English termref consistent #396 <https://github.com/w3c/jlreq/pull/396> once the review is done. Fix #399 <https://github.com/w3c/jlreq/issues/399> (done) and evaluate need to update multi-language script per recent respec update #311 <https://github.com/w3c/jlreq/issues/311>.
Once all are settled, kida to propose to the i18n WG for re-publication of JLreq. (xfq is off line until the working group meeting on 2/22)
Once we almost completed jlreq-d, we will clean up issues (mostly enhancements and future).
Ruby terminology and TTS

#45 <https://github.com/w3c/jlreq/pull/45> Scope: Japanese only? <https://github.com/w3c/ruby-t2s-req/issues/45> → resolved and closed

Murata-san discussed with clreq re:#39 <https://github.com/w3c/ruby-t2s-req/issues/39> / #45 <https://github.com/w3c/ruby-t2s-req/issues/45>. They are planning to unify the term to use “ruby”. As a consequence we can develop a consolidated ruby document. → Update the ruby-t2s document to include Chinese cases. Closing #45 <https://github.com/w3c/jlreq/pull/45>.

#39 <https://github.com/w3c/jlreq/pull/39> Mention Chinese in the document <https://github.com/w3c/ruby-t2s-req/issues/39>
This one will track updating the ruby-t2s document to cover Chinese language.

#385 <https://github.com/w3c/jlreq/issues/385> todo: Update Ruby terminology wiki and solicit feedback from clreq <https://github.com/w3c/jlreq/issues/385>
Still has remaining tasks. Murata-san to follow up.

#41 <https://github.com/w3c/jlreq/pull/41> Proposed Subsections for Zaima Annotation <https://github.com/w3c/ruby-t2s-req/issues/41>
This is a request to include Zaima in the ruby-tts document. Agreed with the originator that Zaima is more akin to a kind of musical notation and therefore is outside of the scope of the TTS document. A remaining issue is that if Zaima uses ruby tag but should be ignored for TTS, there should be some mechanism so that TTS knows to ignore it.

simple-ruby

Kida to notify the i18n WG of the intention (#400 <https://github.com/w3c/jlreq/issues/400>), Shimono-san to publish the current editor draft and make it a discontinued document.

Clreq Gap Analysis items

#397 <https://github.com/w3c/jlreq/issues/397> Adjacent items with text decoration should be separated by a small gap <https://github.com/w3c/jlreq/issues/397>
Two adjacent underlines are hard to distinguish by nature and such a usage is not seen with printed books. The improvement is desired but not critical. No specific comments from JLReq TF.

#368 <https://github.com/w3c/jlreq/issues/368> Emphasis dots should be centre-aligned with the text after the letter spacing is increased #368 <https://github.com/w3c/jlreq/issues/368>
Emphasis dots are to be attached to each character and should be center aligned to each character. Commented on the original issue in Clreq.

Spacing between Fullwidth and Latin characters (aka auto-space in css)

Report from Kida

Ishii-san submitted a proposal to the Unicode Technical Committee (UTC) suggesting the creation of a table that determines default spacing between adjacent character codes. As anticipated, the feedback from the members was mixed.

The next step involves developing this data table. Kida, in collaboration with Ishii-san and Fuqiao from the CLReq team, will work on crafting the table. Achieving a solid consensus between the Chinese and Japanese requirements will increase the likelihood of the UTC approving the proposal. Kida will seek guidance from the JLReq Task Force on critical decisions.

A prior discussion within the JLReq Task Force highlighted the importance of allowing customization because spacing requirements cannot always be determined by character codes. For instance, the U+2000 block, which unifies fullwidth and proportional punctuation, serves as a pertinent example.

The CLReq team raised #9479 <https://github.com/w3c/csswg-drafts/issues/9479> regarding instances where spacing is not balanced at the start and end of a word, like in "あああ12%あああ". According to Bin-sensei, spacing is intended to prevent characters from being too close together, not to highlight words like parentheses do. Such 'unbalanced' situations are actually common practice in publications.

Disucssions

No new discussions except that Nat is hopeful that the system will evolve to become more intelligent, enabling it to determine spacing by utilizing glyph information directly from fonts.

Related issues:

Footnote marks → O (jlreq-d/#44 <https://github.com/w3c/jlreq-d/issues/44>)
Emojis → O (jlreq-d/#43 <https://github.com/w3c/jlreq-d/issues/43>)
Combined characters “㌔”や“㍉” → O (jlreq-d/#42 <https://github.com/w3c/jlreq-d/issues/42>)
Characters enclosed by circle, square etc → O (jlreq-d/#41 <https://github.com/w3c/jlreq-d/issues/41>)
% → O (csswg-drafts/#9479 <https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-1907365694>)
Halfwidth Katakana → O (csswg-drafts/#9471 <https://github.com/w3c/csswg-drafts/issues/9471>, jlreq/#378 <https://github.com/w3c/jlreq/issues/378>)
Black square & white square → O (csswg-drafts/#9603 <https://github.com/w3c/csswg-drafts/issues/9603#issuecomment-1821984613>)
Issues that discusses dynamic behaviors related to autospace

#9840 <https://github.com/w3c/csswg-drafts/issues/9840>: autospace property has a feature that makes web browsers to remove existing space characters and replace them with expected autospace between characters (‘replace’). This feature helps to achieve consistent results even when the original text has space characters manually inserted between Kanji and Latin. That is “漢a” and “漢<U+0020>a” results in the same gap between “漢” and “a”. The issue suggests to improve the feature so that this consistency is achieved even when no-autospace is specified.
#8511 <https://github.com/w3c/csswg-drafts/issues/8511>: When autospace is in effect and the text is copied, what should get copied? There would be two possible thinking. One is that the text should reflect how it currently looks. Another is that the text should be the same as the original as-is. No conclusion. Do we have comments?
Trimming space at the start and end of lines (text-spacing in CSS)

Murakami-san kindly summarized the current status:

There was an agreement to make the default value of text-spacing properties ‘normal’. However it is not an ideal value, it ensures compatibility. The ‘normal’ value collapses space between punctuation characters, does not trim line start, line end will be trimmed only when trimming makes the punctuation to fit. (what is the GH issue # ?)

Discussions

Murakami-san was worried that the behavior of ‘auto’ depends on web browsers. Others thought it is expected with the auto value in general. If one wants to make results predictable and make it consistent across browsers, specific values can be used.

Bin-sensei commented that however jlreq-d will describe general recommendations, it should also be noted that there is no single ‘correct’ answer that works for all cases.

Progress meter on vertical text direction

#8413 Clarify value direction for elements "progress" and "meter" with vertical writing mode <https://github.com/whatwg/html/issues/8413>
todo: kida to comment based on the past JLReq TF consensus.

Italic or oblique on vertical text

[css-fonts-4] oblique angle for synthesis in vertical text #2869 <https://github.com/w3c/csswg-drafts/issues/2869>
https://lists.w3.org/Archives/Public/www-archive/2018Jul/0003.html

There is no such a thing as Italic in Japanese typography. web browsers synthesize them however.
Slanting did exist in phototypesetting. It makes the horizontal strokes slope upwards to the right. Vertical strokes stay vertical. (which is different from what is being discussed)
Probably JLReq-d would just explain the traditional method.
The next meeting

The next meeting will be on Feb 27th Tuesday.
Nat will be in Japan around 4/10. Let’s do off-line meeting around that time.
JLreq TF 会議メモ 2024-2-6

JLReqドキュメントの更新について

#395 jlreqの新バージョンを公開？ <https://github.com/w3c/jlreq/issues/395>
Fuqiaoは、いくつかの修正がキューに準備されているため、JLReqドキュメントを更新することを提案しました。Kidaも同意しました。JLReqで対処しようとしている残りの問題のほとんど、もしくは全てに対する修正を含めることが良いアイデアだと思います。JLReqはメンテナンスモードにあるため、私たちはエラーの修正のみを行っています。強化はjlreq-dで検討される予定です、とKidaはコメントしました。

#154 <https://github.com/w3c/jlreq/issues/154>: 文書（ドキュメントのセクション）の要素にIDを割り当てる体系的な方法が必要です。→ JLReqには該当しません。jlreq-dで評価します。Kidaがコメントしました。
#311 <https://github.com/w3c/jlreq/issues/311>: 言語の切り替えに関連する使い勝手の問題。#264 <https://github.com/w3c/jlreq/pull/264> と #262 <https://github.com/w3c/jlreq/pull/262> によってブロックされています。Shimono-sanが、JLReqで修正するかどうかを評価します。
todo

Bin-senseiが認識している問題を送信（完了）。→ #399 <https://github.com/w3c/jlreq/issues/399> → 全て修正され、クローズされました。
kidaが#322 <https://github.com/w3c/jlreq/pull/322>と#396 <https://github.com/w3c/jlreq/pull/396>をレビュー（完了）
レビューが完了したら、Shimono-sanが#322と#396をマージします。#399 <https://github.com/w3c/jlreq/issues/399>を修正（完了）し、#311を評価します。
全てが解決したら、kidaがi18n WGにJLreqの再公開を提案します。（xfqは2/22のワーキンググループ会議までオフラインです）
jlreq-dをほぼ完成させたら、問題（主に強化と将来のもの）をクリーンアップします。
ルビ用語とTTS

#45 <https://github.com/w3c/jlreq/pull/45> スコープ: 日本語のみ？ <https://github.com/w3c/ruby-t2s-req/issues/45> → 解決してクローズ

Murata-sanはclreqと#39 <https://github.com/w3c/ruby-t2s-req/issues/39> / #45 <https://github.com/w3c/ruby-t2s-req/issues/45>について議論しました。彼らは“ruby”という用語を統一することを計画しています。その結果、統合されたルビドキュメントを開発できます。→ 中国語のケースを含むようにruby-t2sドキュメントを更新します。#45をクローズします。

#39 <https://github.com/w3c/jlreq/pull/39> ドキュメントで中国語に言及する <https://github.com/w3c/ruby-t2s-req/issues/39>
これは、ruby-t2sドキュメントを更新して中国語をカバーすることを追跡します。

#385 <https://github.com/w3c/jlreq/issues/385> [todo: ルビ用語のwikiを更新し、clreqからフィードバックを募集する](https://github.com/w3c/jlreq/issues/

まだ残っているタスクがあります。Murata-sanがフォローアップします。

#41 <https://github.com/w3c/jlreq/pull/41> Zaima annotation のための提案 <https://github.com/w3c/ruby-t2s-req/issues/41>
これは、ruby-ttsドキュメントにザイマを含めるように要求するものです。提案者との合意は、ザイマが音楽記譜法の一種であるため、TTSドキュメントの範囲外であるというものです。残っている問題は、ザイマがrubyタグを使用しているがTTSに無視されるべき場合、TTSがそれを無視することを知るための何らかのメカニズムがあるべきだということです。

simple-ruby

Kidaが意図をi18n WGに通知し (#400 <https://github.com/w3c/jlreq/issues/400>)、Shimono-sanが現在のエディタドラフトを公開し、それを廃止されたドキュメントにします。

Clreqギャップ分析アイテム

#397 <https://github.com/w3c/jlreq/issues/397> テキスト装飾がある隣接アイテムは小さな隙間で区切られるべき <https://github.com/w3c/jlreq/issues/397>
二つの隣接する下線は、自然に区別がつきにくく、印刷された本ではそのような使用法は見られません。改善が望まれますが、重要ではありません。JLReq TFから特にコメントはありません。

#368 <https://github.com/w3c/jlreq/issues/368> 文字の間隔が広がった後の強調点は、文字と中央揃えであるべきです #368 <https://github.com/w3c/jlreq/issues/368>
強調点は、各文字に添付され、各文字と中央揃えであるべきです。Clreqの元の問題にコメントしました。

全角とラテン文字の間のスペーシング（cssでの自動スペース）

Kidaからの報告

Ishii-sanは、隣接する文字コード間のデフォルトのスペーシングを決定する表の作成を提案する提案をUnicode技術委員会（UTC）に提出しました。予想された通り、メンバーからのフィードバックは賛否両論でした。

次のステップは、このデータテーブルを開発することです。Kidaは、Ishii-sanおよびCLReqチームのFuqiaoと協力して、このテーブルを作成する予定です。中国語と日本語の要件の間でしっかりとした合意に達することが、UTCがこの提案を承認する可能性を高めます。Kidaは、重要な決定についてJLReqタスクフォースからの指導を求めます。

JLReqタスクフォース内の以前の議論では、スペーシングの要件は常に文字コードによって決定されるわけではないため、カスタマイズを許可することの重要性が強調されました。例えば、全角と比例句読点を統一するU+2000ブロックが、適切な例として挙げられます。

CLReqチームは、"あああ12%あああ"のように、単語の開始と終了でスペーシングが均等でない場合に関する#9479 <https://github.com/w3c/csswg-drafts/issues/9479>を提起しました。Bin-senseiによると、スペーシングは文字が近すぎるのを防ぐために意図されており、括弧のように単語を強調するためではありません。このような「不均等」な状況は、実際に出版物で一般的な慣習です。

議論

新たな議論はありませんでしたが、Natはシステムがより知的に進化し、フォントから直接グリフ情報を利用してスペーシングを決定できるようになることを期待しています。

関連する問題:

脚注マーク → O (jlreq-d/#44 <https://github.com/w3c/jlreq-d/issues/44>)
絵文字 → O (jlreq-d/#43 <https://github.com/w3c/jlreq-d/issues/43>)
組み文字「㌔」や「㍉」 → O (jlreq-d/#42 <https://github.com/w3c/jlreq-d/issues/42>)
円、四角などで囲まれた文字 → O (jlreq-d/#41 <https://github.com/w3c/jlreq-d/issues/41>)
% → O (csswg-drafts/#9479 <https://github.com/w3c/csswg-drafts/issues/9479#issuecomment-1907365694>)
半角カタカナ → O (csswg-drafts/#9471 <https://github.com/w3c/csswg-drafts/issues/9471>, jlreq/#378 <https://github.com/w3c/jlreq/issues/378>)
黒四角 & 白四角 → O (csswg-drafts/#9603 <https://github.com/w3c/csswg-drafts/issues/9603#issuecomment-1821984613>)
自動スペースに関連する動的な振る舞いを議論する問題

#9840 <https://github.com/w3c/csswg-drafts/issues/9840>: autospaceプロパティには、Webブラウザが既存のスペース文字を削除し、漢字とラテン文字の間に期待される自動スペースに置き換える機能（「置換」）があります。この機能は、元のテキストに手動でスペース文字が挿入されていた場合でも、一貫した結果を得るのに役立ちます。つまり、「漢a」と「漢<U+0020>a」は「漢」と「a」の間の同じ間隔を結果として得ます。この機能を改善し、no-autospaceが指定されている場合でもこの一貫性を達成できるようにすることが提案されています。
#8511 <https://github.com/w3c/csswg-drafts/issues/8511>: autospaceが有効の場合、テキストがコピーされたとき、何がコピーされるべきか？二つの考え方があります。一つは、テキストが現在どのように見えるかを反映すべきだというものです。もう一つは、テキストが元のままであるべきだというものです。結論は出ていません。コメントはありますか？
行の開始と終了のスペースをトリミングする（CSSのtext-spacing）

村上さんが親切に現状をまとめました：

text-spacingプロパティのデフォルト値を「normal」にすることで合意しました。これは理想的な値ではありませんが、互換性を保証します。「normal」の値は句読点間のスペースを省略し、行の開始をトリミングしませんが、トリミングが句読点を収めるのに役立つ場合のみ、行の終了をトリミングします。（GitHubの問題番号は？）

議論

村上さんは、「auto」の振る舞いがWebブラウザに依存することを心配していました。他の人は、一般にauto値で期待されるものであると考えています。ブラウザ間で結果を予測可能にし、一貫性を持たせたい場合は、具体的な値を使用できます。

Bin-senseiは、jlreq-dが一般的な推奨事項を記述するとしても、全てのケースに対して「正しい」単一の解答が存在しないことも注記されるべきだとコメントしました。

縦書きテキストの進捗メーター

#8413 縦書きモードでの要素「progress」と「meter」の値方向を明確にする <https://github.com/whatwg/html/issues/8413>
todo: 過去のJLReq TFの合意に基づいて、kidaがコメントする。

縦書きテキストでのイタリックまたは斜体

[css-fonts-4] 縦書きテキストにおける合成のための斜体角度 #2869 <https://github.com/w3c/csswg-drafts/issues/2869>
https://lists.w3.org/Archives/Public/www-archive/2018Jul/0003.html

日本のタイポグラフィにイタリックは存在しません。Webブラウザは斜体を合成します。
フォトタイプセッティングでは傾斜が存在しました。これは、水平線を右上に傾斜させ、垂直線を垂直に保つものです（これは議論されているものとは異なります）。
JLReq-dはおそらく伝統的な方法を説明するだけでしょう。
次回会議

次回の会議は2月27日の火曜日です。
Natは4/10頃に日本にいます。その時にオフライン会議をしましょう。

//