JLReq TF meeting notes 2023-5-2

JLReq TF のみなさま、前回と同様に日本語は自動翻訳です（ずぼら :）


https://github.com/w3c/jlreq/issues/361

JLReq TF meeting notes 2023-5-2

attendees

atsuda, atsushi, kida, makoto, nat, shinyu, tajima, takeru, tlk, toshi

simple-ruby のアップデート

これまでの状況: グループは、「ruby layout processing in two separate steps」を「two-level」という用語と翻訳で合意しました。まだレビューが必要なPRがいくつか残っています。
リチャードには、細かく変更をレビューしてもらうか、まとめてレビューしてもらうかどちらがいいでしょうか？（彼に聞いたほうがいい）
Kidaさんは、送信や提出する前にgrammarly.comを使って英語のテキストをチェックすることが多いです。彼は皆さんにもお勧めしています。それは良いことです - ネイティブスピーカーも使っています。
Kidaさんは、敏先生にrubyとベーステキストの配置方法についての説明を求めています（simple-ruby #67）
敏先生： 最も一般的な方法は、短い方を完全に両端揃えにし、始めと終わりに小さな、半分のスペースを残すことです。他の方法には、周囲のスペースなしでの両端揃え、両端揃えなしのシンプルな中央揃え、または左揃えがありますが、彼は最後のものをめったに見ません。
下農： 両端揃えは、spacing-propertyドキュメントに記載されている間隔ルールに従って行うことができます。他の言語は、標準的な両端揃え方法に従うことができます。
Todo：Kidaさんがテキストを起草して提案する。
敏先生： ルビのオーバーハングがあると、方法が複雑になることがあります。なぜなら、オーバーハングが片側だけで発生した場合、テキストが中心から見える範囲外になってしまうことがあるからです。InDesignでそのような例を見ることができます。Todo：敏先生がNatに例を送る。ルビのオーバーハングを採用していないため、simple-rubyドキュメントの範囲外です。
まだいくつかのPRが残っています。Todo：下農さんとKidaさんが一緒になってレビューを完了する（5/8 @品川）。
下農さんは、PRを解決した後、JLReq TFミーティングで再度取り上げることなくドキュメントの更新プロセスを進めることを提案しました。チームは同意しました。

横書きと縦書きの両方に対応したウェブページを作成するガイドラインの開発可能性について議論

まず要件を把握することが重要
要件を把握しないと範囲を設定できません。例えば、グラフを縦に作成する必要があるのか、それともガイドラインはレイアウトに関連するのか？ターゲット顧客や重要なシナリオは何か？
要件は何か？
村田: 重要な要件はアクセシビリティから来ています。縦書きのテキストが読めない人や逆に横書きが読めない人もいます。縦書きのテキストに問題が多いです。アクセシビリティにとって品質は優先事項ではありません。
ユーザーの好み、特に電子書籍。
合意: アクセシビリティと電子書籍を対象要件にしましょう。
その他の議論
敏先生: 伝統的に、すべてのテキストは縦方向です。ラテン文字やアラビア数字が増えるにつれ、多くの書籍や文書が横方向になりました。現在では、それらの大半が横方向です。文学書籍はまだ典型的に縦方向です。また、印刷された新聞も縦方向です。
下農: 法律も別の例かもしれません。現在は縦書きがデフォルトですが、横にするニーズが増えています。政府のウェブサイトでは、法律を両方向のPDFでダウンロードできます（pdf！）
村田: ガイドラインが基準を高く設定することで、逆にコストのために両方向に対応した電子書籍の開発を抑制する可能性があると強い懸念があります。
木田: ガイドラインでは、方向反転を許可することがアクセシビリティにとってガイドラインに従って改善するよりもはるかに重要であることを示すことができます。
敏先生: 漢文は横にするのが難しい。→ もう重要ではない。
プレーンテキスト用のガイドライン
そのようなガイドラインはJLReq-dの一部として計画されています
関連する領域には、数値形式、リストの見出し、句読点の使用、同じ文書内のテキストや画像を指す単語や文字の選択（例：右/左、上/下）が含まれます。
敏先生: 名前や慣用表現で使用されているものを除いて、数字は現在、方向に関係なくすべてアラビア数字にすることができます。これにより、両方向に互換性があります。
敏先生: GitHubのどこかにメモを書いています。また、長谷川さんの記事があります。Todo: リンクを見つけてリストに送る（済み）。
Todo: 小林さんが最初の試みを書くことにボランティアしました。
ウェブページ用のガイドライン
どのような問題が関与していますか？例としては、物理的な方向を使用するリストの見出しやタグ（例：margin-leftとmargin-start）があります。他にもありますか？
村田: 両方向に対応したepubサンプルを開発しました。それがどのように達成されたかについての文書はありません。*1 *2
村上: 一部のepubリーダーは、本がそれをサポートしているかどうかに関係なく、方向を切り替えることができます。彼らがどのようにそれを行っているかを学ぶことができます。私が知っているものは、Kinoppy（Infocity社が開発）、honto（森川）、BookLive（凸版印刷）、Cocoro Books（シャープ？）です。
下農: ユーザーが文学を読むことができるようにするいくつかのウェブサイトは、類似した機能があります。田嶋: LINEのエンジニアが似たような問題について話していると聞いたことがあります。
村上さんと田嶋さんは、EPUB関連のメーリングリストや自身のコネクションを通じて、開発者/エンジニアに連絡することができます。小林さんも、彼らがCITPCのメンバー（凸版印刷など）である場合、連絡することができます。
Todo: 下農さんが、開発者/エンジニア向けのアンケートを作成します。 *1 https://github.com/Japan-Daisy-Consortium/samples/tree/main/%E7%B8%A6%E6%9B%B8%E3%81%8D%E3%83%BB%E6%A8%AA%E6%9B%B8%E3%81%8D%E5%88%87%E6%9B%BF%E5%8F%AF%E8%83%BD%E3%81%AAEPUB(alternate%20style%20tags)/epub_with_a11y_metadata *2 https://github.com/Japan-Daisy-Consortium/samples/tree/main/aozora

タイムライン？
もともとの議論は、JLReq-dを縦書きに変換してから、そのような文書を開発することでした。
それはもっと早くできますか？
結論は出ていません。

印刷とデジタルのレイアウト機能の機能分析（ブレインストーミング）

小林さんは「機能論的アプローチへのメモ (a memorandum for functional approach) 」というタイトルのメモを作成し、リストに送りました。

小林: 基本技術が変わると、書記システムも変わります。金属活字がJLReqの基盤である一方、JLReq-dはまったく異なるモデルに立っています。それらはスクロール可能なメディア上の動的コンテンツです。紙にあったすべてのものをデジタルにコピーしようとするのはナンセンスです。代わりに、各レイアウト機能の機能を分析し、デジタルテキストがそれらをどのように実現できるかを考え/提案するべきです。
敏先生: 動機はよく理解していますが、何を捨てて何を残すべきかを判断するのは難しいです。変わる可能性があるものは簡単に見つけることができますが、それがどのように変わるかは簡単ではありません。
木田: 私自身の経験からも同意します。
敏先生: 印刷からデジタルへの変化の衝撃的な例が欲しいのですが、まだ見つかっていません。基本的な枠組み（文字の測定や配置の基本的な枠組み）は消えるでしょうが、それに代わるものは何でしょうか？両面ルビを捨てることができますが、それが大きな影響を与えるわけではありません。全角性への仮定や依存がなくなるかもしれません。など
鈴木: まだ、比例した日本語文字が何を意味するのか、つまり比例させることの影響がわかっていない。
敏先生: もっと読みやすさについて考えてほしいです。50-60文字の長い行を簡単に作成することができますが、そのような行の読みやすさは低いです。行の長さ、行間の距離、間隔が読みやすさの鍵になります。それらは自動的に制御できるのでしょうか？
小林: そのようなモデルの移行について議論するセクションがあるべきです。
木田: 同意します。避けられない変化があるだろうし、変わる可能性もあるでしょう。新しい可能性があります。
Todo: 小林さんがメモを修正し、さらなる議論のために提供します。

EPUB 3.3の影響は？

何か影響がある可能性はありますか？村田さんが早く退出しなければならなかったので、次回の会議で彼が参加しているときに議論しましょう。


その他のアップデート (木田)

progress, meter & input=range 要素
会議を提案したものの、一回のコールよりもGitHubで議論する方が良いと思います。xfqと話し合います（連絡済み。木田がGitHubのclreq/#500にコメントを追加します）
‘palt’ OT仕様
IshiさんとCITPCと協議中。暫定的な合意が得られたら、JLReq TFに承認を求めるために報告します。

次回の会議は5月30日（火曜日）です。

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

simple-ruby updates

Status so far: The group have agreed on the term and the translation for the “ruby layout processing in two separate steps” as “two-level”. There are a few remaining PRs that need review.
Do we want Richard to review changes in a piecemeal fashion or the whole at once? (better to ask him)
Kida usually checks English text using grammarly.com before sending or submitting. He recommends it to everybody. It is a good thing - even native speakers use it.
Kida wants clarification from Bin-sensei on how the ruby and the base text will be aligned (simple-ruby #67)
Bin-sensei: The most common method is to fully justify the shorter of the two, leaving a small, a half amount, space at the start and the end. Other methods include justification without the surrounding space, simple centering without justification, or ragged right, although he rarely sees the last one.
Shimono: The justification can be done by following the spacing rules described in the spacing-property document. Other languages can follow their standard justification method.
Todo: Kida to draft the text and propose.
Bin-sensei: The method can get complicated with ruby overhang because when the overhang happens only on one of the sides, the text can become visibly out of the centre while it should be. You can see such examples in InDesign. Todo: Bin-sensei to send the example to Nat. It is out of the scope of the simple-ruby document because it does not adopt ruby overhanging.
There are a few remaining PRs. Todo: Shimono and Kida will get together to complete the review (5/8 @ Shinagawa).
Shimono proposed to proceed with the document update process after resolving the PRs, without bringing it up again at the JLReq TF meeting. The team agrees.
Discussed the possibility of developing a guideline to create web pages that are compatible with both horizontal and vertical directions

Knowing requirements come first
We can’t set the scope without knowing the requirements. For example, do charts need to be made vertically, or does such a guideline concern layouts? What are target customers and critical scenarios?
What are the requirements?
Murata: The important requirements come from accessibility. Some people can’t read when text is vertical, or vice versa. The majority of issues are with the vertical text. Quality is not a priority for accessibility.
User preference, especially with ebooks.
Agreement: Let’s make accessibility and ebooks the target requirements.
Other discussions
Bin-sensei: Traditionally, all text is in the vertical direction. As words written in Latin characters and Arabic numbers increased, more books and documents became horizontal. Nowadays, the majority of them are horizontal. Literature books are typically vertical still. Also, printed newspapers are vertical.
Shimono: Law might be another example. They currently default to vertical, but there is a growing need to lay them horizontally. The government’s website allows downloading the law in PDF in both directions. (pdf!)
Murata: I have a strong concern that the guideline, by setting the bar higher, could work negatively, discouraging the development of ebooks allowing both directions because of the cost.
Kida: we can indicate in the guideline that allowing direction flipping is much more critical for accessibility than improving it by following the guideline.
Bin-sensei: Kanbun is hard to make horizontal. → Not important anymore.
Guidelines for the plain text
Such guideline is a planned part of JLReq-d
Areas involved include Number format, list headings, use of punctuation, and selection of words and characters that point to text or images in the same document, e.g. right/left and above/below.
Bin-sensei: Numbers except ones used in names and idiomatic expressions can now all be in Arabic numerals regardless of directions. This way, they are compatible with both directions.
Bin-sensei: I drafted a note somewhere in GitHub. Also, there is an article by Mr. Hasegawa. Todo: dig them up and send a link to the list (done).
Todo: Kobayashi-san volunteered to write up the first shot.
Guidelines for web pages
What issues involve? Examples are list headings and tags that use physical direction, e.f. margin-left vs margin-start. Are there others?
Murata: Developed epub samples that are compatible with both directions. There are no documents on how it was achieved. *1 *2
Murakami: Some epub readers allow flipping regardless of whether the book supports it. We could learn from how they do it. The ones I know are Kinoppy (developed by Infocity inc), honto (Morikawa), BookLive (Toppan), and Cocoro Books (sharp?).
Shinono: Some websites that let users read literature have similar features. Tajima: I heard an engineer at Line was talking about similar issues.
Murakami-san and Tajima-san can contact the developers/engineers with their connections or through EPUB-related mailing lists. Kobayashi-san can also contact them if they are members of CITPC (such as Toppan).
Todo: Shimono-san will draft a questionnaire for the developers/engineers. *1 https://github.com/Japan-Daisy-Consortium/samples/tree/main/%E7%B8%A6%E6%9B%B8%E3%81%8D%E3%83%BB%E6%A8%AA%E6%9B%B8%E3%81%8D%E5%88%87%E6%9B%BF%E5%8F%AF%E8%83%BD%E3%81%AAEPUB(alternate%20style%20tags)/epub_with_a11y_metadata *2 https://github.com/Japan-Daisy-Consortium/samples/tree/main/aozora

Timeline?
The original discussion was developing such document after we’ve done JLReq-d by converting it to vertical.
Can it be done earlier?
No conclusion.
Functional analysis of layout features on print and digital (brainstorming)

Kobayashi-san came up with a note titled 「機能論的アプローチへのメモ (a memorandum for functional approach) 」 and sent it out to the list.

Kobayashi: The writing system changes when the base technologies change. While the metal type is the foundation of JLReq, JLReq-d stands on a completely different model; they are dynamic contents on scrollable media. Trying to copy everything we had on paper to digital is nonsense. Instead, we should analyse the function of each layout feature and think/propose how digital text can achieve them.
Bin-sensei: I understand the motivation very well, but telling what we can throw away and what needs to stay is challenging. It is easy to spot things that could change, but it is not easy to tell how.
Kida: Agreed from my own experience.
Bin-sensei: I want shocking examples (of things that change from print to digital), but I have yet to find any. The kihon-hangmen (the base framework for measurement and placement of characters) will disappear, but what is the thing that would replace it? We can throw away two-sided ruby, but it does not significantly impact. Assumptions and dependency on fullwidth-ness might go away. Etc.
Suzuki: We still do not know what the proportional Japanese characters mean, i.e. the impact of making them proportional.
Bin-sensei: I want people to think more about readability. We can easily make long lines containing 50-60 characters, but the readability of such lines is low. The length of a line, the distance between lines, and the spacing would be keys for readability. Can they be controlled automatically?
Kobayashi: There should be a section discussing such transition of models.
Kida: Agreed. There would be things that change inevitably, and also something that could change; new possibilities.
Todo: Kobayashi to revise his note for further discussions.
Impacts of EPUB 3.3?

Are there any possible impacts? As Murata-san had to leave early let’s discuss at the next meeting when he is in the meeting.

Other updates (kida)

progress, meter & input=range elements
However I proposed a meeting, I think discussing on GitHub is better than having one shot call. I will talk to xfq (communication done. Kida to add comments on the github clreq/#500)
‘palt’ OT spec
Discussing with Ishi-san and CITPC. Will get back to JLReq TF for approval when we have tentative agreements.
The next meeting will be on 5/30 Tuesday

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––