You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: Need a systematic way of assigning ID to elements (sections of a document). → Not for JLReq. Will evaluate for jlreq-d. Kida commented.
#311: Usabilitty issues related to switching languages. Blocked by #264 と #262. Shimono-san to evaluate if we want to fix it in JLReq.
todo
Bin-sensei to send issues that he recognizes (done). → #399 → all fixed and closed.
Murata-san discussed with clreq re:#39 / #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.
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, Shimono-san to publish the current editor draft and make it a discontinued document.
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.
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 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.
Issues that discusses dynamic behaviors related to autospace
#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: 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.
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
(日本語は英文の下に)
JLreq TF meeting notes 2024-2-6
An update to the JLReq document
#395 Publish new version of jlreq?
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.
todo
Ruby terminology and TTS
#45 Scope: Japanese only? → resolved and closed
Murata-san discussed with clreq re:#39 / #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.
#39 Mention Chinese in the document
This one will track updating the ruby-t2s document to cover Chinese language.
#385 todo: Update Ruby terminology wiki and solicit feedback from clreq
Still has remaining tasks. Murata-san to follow up.
#41 Proposed Subsections for Zaima Annotation
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, Shimono-san to publish the current editor draft and make it a discontinued document.
Clreq Gap Analysis items
#397 Adjacent items with text decoration should be separated by a small gap
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 Emphasis dots should be centre-aligned with the text after the letter spacing is increased #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 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:
Issues that discusses dynamic behaviors related to autospace
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
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://lists.w3.org/Archives/Public/www-archive/2018Jul/0003.html
The next meeting
JLreq TF 会議メモ 2024-2-6
JLReqドキュメントの更新について
#395 jlreqの新バージョンを公開?
Fuqiaoは、いくつかの修正がキューに準備されているため、JLReqドキュメントを更新することを提案しました。Kidaも同意しました。JLReqで対処しようとしている残りの問題のほとんど、もしくは全てに対する修正を含めることが良いアイデアだと思います。JLReqはメンテナンスモードにあるため、私たちはエラーの修正のみを行っています。強化はjlreq-dで検討される予定です、とKidaはコメントしました。
todo
ルビ用語とTTS
#45 スコープ: 日本語のみ? → 解決してクローズ
Murata-sanはclreqと#39 / #45について議論しました。彼らは“ruby”という用語を統一することを計画しています。その結果、統合されたルビドキュメントを開発できます。→ 中国語のケースを含むようにruby-t2sドキュメントを更新します。#45をクローズします。
#39 ドキュメントで中国語に言及する
これは、ruby-t2sドキュメントを更新して中国語をカバーすることを追跡します。
#385 [todo: ルビ用語のwikiを更新し、clreqからフィードバックを募集する](https://github.com/w3c/jlreq/issues/
まだ残っているタスクがあります。Murata-sanがフォローアップします。
#41 Zaima annotation のための提案
これは、ruby-ttsドキュメントにザイマを含めるように要求するものです。提案者との合意は、ザイマが音楽記譜法の一種であるため、TTSドキュメントの範囲外であるというものです。残っている問題は、ザイマがrubyタグを使用しているがTTSに無視されるべき場合、TTSがそれを無視することを知るための何らかのメカニズムがあるべきだということです。
simple-ruby
Kidaが意図をi18n WGに通知し、Shimono-sanが現在のエディタドラフトを公開し、それを廃止されたドキュメントにします。
Clreqギャップ分析アイテム
#397 テキスト装飾がある隣接アイテムは小さな隙間で区切られるべき
二つの隣接する下線は、自然に区別がつきにくく、印刷された本ではそのような使用法は見られません。改善が望まれますが、重要ではありません。JLReq TFから特にコメントはありません。
#368 文字の間隔が広がった後の強調点は、文字と中央揃えであるべきです #368
強調点は、各文字に添付され、各文字と中央揃えであるべきです。Clreqの元の問題にコメントしました。
全角とラテン文字の間のスペーシング(cssでの自動スペース)
Kidaからの報告
Ishii-sanは、隣接する文字コード間のデフォルトのスペーシングを決定する表の作成を提案する提案をUnicode技術委員会(UTC)に提出しました。予想された通り、メンバーからのフィードバックは賛否両論でした。
次のステップは、このデータテーブルを開発することです。Kidaは、Ishii-sanおよびCLReqチームのFuqiaoと協力して、このテーブルを作成する予定です。中国語と日本語の要件の間でしっかりとした合意に達することが、UTCがこの提案を承認する可能性を高めます。Kidaは、重要な決定についてJLReqタスクフォースからの指導を求めます。
JLReqタスクフォース内の以前の議論では、スペーシングの要件は常に文字コードによって決定されるわけではないため、カスタマイズを許可することの重要性が強調されました。例えば、全角と比例句読点を統一するU+2000ブロックが、適切な例として挙げられます。
CLReqチームは、"あああ12%あああ"のように、単語の開始と終了でスペーシングが均等でない場合に関する#9479を提起しました。Bin-senseiによると、スペーシングは文字が近すぎるのを防ぐために意図されており、括弧のように単語を強調するためではありません。このような「不均等」な状況は、実際に出版物で一般的な慣習です。
議論
新たな議論はありませんでしたが、Natはシステムがより知的に進化し、フォントから直接グリフ情報を利用してスペーシングを決定できるようになることを期待しています。
関連する問題:
自動スペースに関連する動的な振る舞いを議論する問題
行の開始と終了のスペースをトリミングする(CSSのtext-spacing)
村上さんが親切に現状をまとめました:
text-spacingプロパティのデフォルト値を「normal」にすることで合意しました。これは理想的な値ではありませんが、互換性を保証します。「normal」の値は句読点間のスペースを省略し、行の開始をトリミングしませんが、トリミングが句読点を収めるのに役立つ場合のみ、行の終了をトリミングします。(GitHubの問題番号は?)
議論
村上さんは、「auto」の振る舞いがWebブラウザに依存することを心配していました。他の人は、一般にauto値で期待されるものであると考えています。ブラウザ間で結果を予測可能にし、一貫性を持たせたい場合は、具体的な値を使用できます。
Bin-senseiは、jlreq-dが一般的な推奨事項を記述するとしても、全てのケースに対して「正しい」単一の解答が存在しないことも注記されるべきだとコメントしました。
縦書きテキストの進捗メーター
#8413 縦書きモードでの要素「progress」と「meter」の値方向を明確にする
todo: 過去のJLReq TFの合意に基づいて、kidaがコメントする。
縦書きテキストでのイタリックまたは斜体
[css-fonts-4] 縦書きテキストにおける合成のための斜体角度 #2869
https://lists.w3.org/Archives/Public/www-archive/2018Jul/0003.html
次回会議
Beta Was this translation helpful? Give feedback.
All reactions