Re: JLReq TF meeting notes 2023-5-30

日本語訳です by chatGPT, minimal editing by kida.

英語の段階でですが、語られていない前提を私の解釈で補ったので、自分の発言が正しく伝わっているかチェックしてください。

参加者

atsuda, atsushi, kida, murata, nat, shinyu, suzuki, tajima, tlk, toshi

議題

JLReq-d model and scope discussions
simple-ruby document updates
EPUB 3.3, possible impacts?
ruby-t2s-reqs document updates
reviewing previous todo’s
JLReq-d モデルとスコープの議論

ページ対スクロール

ページ対スクロール

小林：JLReq-dは、ページモデル、すなわち基本版面という固定したページが束ねられた冊子のモデル、を廃棄すべきである。代わりに、我々はリフロー＆スクロールモデルに焦点を当てるべきだ。

バックグラウンド：彼と私たちの一部は、コデックス/冊子のモデルは物理メディアの名残であると信じている。印刷からデジタルへの移行を助けることに一役買う以外、デジタルメディアではそのすべての利点を失っている。
以下の良い指摘とともに一般的な合意があった：
津田：ページをめくることは、ページ間を移動したり文書の一部を見つけるための良いUIになる可能性がある。
木田：それは興味深いポイントだ。類似のUIは、スクロールモデルでも依然として適用可能だ。これについてもっと知りたい。少なくとも、jlreq-dではそのようなUIを薦めない印象を与えてはならないと思う。
村上：それは、私たちも電子書籍を捨てるということですか？
JLreq-dが何かを禁止するわけではない。伝統的な本をデジタルメディアで模倣したい人々は（そしてそれは一定期間、意味がある）、JLreq-dとJLreqの両方を読むことで依然としてそれを行うことができる。
木田：私たちはjlreq-dで、このモデルを扱わないこと、そしてページの束ね方についてはjlreqを参照することを言及すべきだ。あるいは、jlreq-dに冊子やページについてのセクションを作成し、なぜそのモデルをカバーしないのかを説明することもできる。
村上と敏先生：カラムはどうですか？
木田：カラムは依然として、短い内容や長い内容にセクションとともに使用することができる。ウェブ上の例を見ることができる。
村上：我々は縦書きを扱うのですか？縦書きの主な用途は電子書籍です。
木田：はい、扱うべきだと思う。価値は印刷からデジタルへの移行とともに減少しない。
下農：ウェブ文学はよく、テキストの方向を変更するスイッチを持っている。
小林：我々は現在のcssや他の技術の制約に縛られてはならない。
下農：2つの異なる種類のページの概念を混同しないようにしよう。1つは、本を作る際の単位としてのページだ。もう1つは、行と同様のテキストの区切りとしてのページだ。
行レイアウト

敏先生：伝統的に、テキストの行は約40文字、コラムは25文字、新聞は12文字から成るという前提がありました。一度出版のために設定されたら、それは変わりません。それはJLReqで説明されている基本版面の概念の一部です。最適な禁則処理（行折りを抑制する文字のセット）のルールは、行あたりの文字数に依存します。文字数は印刷物では一定の変数であり、禁則処理のルールも同様です。そのような前提は、動的な行長を持つデジタルメディアでは壊れます。その結果、禁則処理のルールは行の長さが変わるにつれて追随する必要があります。
Nat：JLReqは仮想ボディ（仮想ボディ）の概念とその動作を完全に説明していません。ほとんどの実装では、ラテン文字のフォントと日本語のフォントとの適切な整列が、ラテン文字側のフォントを変更するたびに壊れます。また、行の途中で日本語のフォントのサイズを切り替えるときも壊れます。短く言えば、日本語の文字はフォントに埋め込まれたベースラインの値を使って配置すべきではなく、仮想ボディを使って配置すべきです。テキストシステムがラテンのベースラインのアーキテクチャの上に構築されていても、日本語の文字がその仮想ボディを使って配置されるようなレイヤーを作るべきです。それは基本の一部ですが、それが欠けています。
木田：私はこれが重要な点だと同意します。
Nat：jlreq-dは、文字組みの空き量設定とモノスペースのレイアウトのルールを説明するべきです。特にSNSを見ると、私は短い文やフレーズのルールや、ますます多くの英語の単語を含むテキストのルールを開発する必要があると思います。
敏先生：日本語のテキストの比例レイアウトをいつ/どのように使用するかは誰も知りません。それは新しいことであり、私たちはjlreq-dでそれを取り上げるべきです。（木田：本当に？デザイ
ナーたちは長い間、詰め組みを使用してきました。それは日本語のテキストの比例で、オプションでカーニングです）

小林：私は皆さんに「杉浦康平と写植の時代: 光学技術と日本語のデザイン」を読むことをお勧めします。それは杉浦氏が彼の時代の新技術である写植に直面し、それに苦労し、テキストレイアウトと編集デザインを進めた方法を示しています。それは励ましになります。

敏先生：特定の範囲内で行ごとの文字数を制限する方法を持つ必要があります。行が長すぎるとテキストは読みにくくなります。ウィンドウの幅が広すぎる場合、マージンを大きくするか、カラムを使用する必要があります。それは自動的であるべきです。

敏先生：スクロールモデルの下でどのようにしてカラムを使用できますか？

小林：ウェブ上ではダイナミックレイアウト（レスポンシブデザイン）を見ることができます。私たちはそれらから学ぶことができます。
木田：私たちはウェブの人々から学ぶことができます。しかし、jlreq-dで解決策を必ずしも示す必要はありません。ウェブの技術とデザインは進化しています。私たちは説明すべきなのは問題の性質と背景です。私たちは最適な結果とその理由を提示しますが、それを達成する方法は必ずしも示さない。
小林：私たちはデジタル版に持ち越さないものについては、必要に応じてJLReqを更新して、私たちの考えを捉えることを望むかもしれません。

小林：これらはJLreq-dにとって重要なトピックであるため、議論を記録したいと思います。

Todo：木田がGitHubでディスカッションスレッドを作成する（完了。https://github.com/w3c/jlreq-d/issues/30）。 <https://github.com/w3c/jlreq-d/issues/30%EF%BC%89%E3%80%82>
著述方法について

木田：JLreq-d文書の作成方法について合意したいと思います。オリジナルのJLreqは、元の日本語テキストの翻訳に基づいていました。それに代わり、私はまずJLreq-dを英語で作成したいと考えています。オリジナルのテキストの大部分はまだ日本語で書かれ、議論されるでしょう。英語を話す人々（木田、ナットなど）が情報を消化し、英語で内容を草稿にします。目的は、日本語で考え、書くときに避けられない仮定を排除することです。その仮定とは、日本語とレイアウトに関する知識と経験を指します。私たちは経験を積み重ねるにつれてプロセスを改善します。日本語版は自動翻訳（例えば、DeepLやChatGPT）から始まり、チームによってブラッシュアップされます。

このアプローチについては合意がありました。

simple-ruby文書について

木田：前回の会議で、既存の問題を解決した後に作業草稿を更新することに合意しました。全文を見直した後、私はまだいくつかの問題があると感じました：

全体的に、英語のテキストはもっとよく書くことができます。
それは「シンプル」ではありません。非常に複雑な両面ルビを含んでおり、JLReqでさえそれを説明していません。また、JLReqはそれを極めて稀であると記述しています。だとすれば、この「シンプル」な版のルビレイアウト文書にそれを入れる意味がありません（jlreq-dには含めるかもしれません）。
内容が古いです。jlreq-dに向けた議論で、説明にモノ-とグループ-の用語を使用しないことに合意しました。ユニファイドルビとそのモノのケースの例外を説明する方がずっと簡単です。jlreq-dの開発が進行中であるため、この古い内容でこれを出版する意味はほとんどないかもしれません。
いくつかの選択肢があります：

既存のgh問題を修正して最小限の修正で公開する。
大幅な更新を行う。その内容もjlreq-dの一部となります。
このドキュメントの草案の状態での作業を中止する。その後、jlreq-dに集中します。
議論の結果、JLReq TFは、JLReq TFがドキュメントを中止することに合意した。

Todo：木田がRichard、Florian、そしてfantasaiに通知する。

議論

ナット：私は、jlreq-dがより洗練された方法もカバーするようにしたいと思っています。
木田：同意します。jlreq-dはjlreqのシンプルなバージョンではありません。洗練された方法をカバーしつつ、それらがどのようにシンプル化できるか、欠点と利点を示すことになります。
敏先生：jlreq-dのルビ部分を最初に書き上げることができるかもしれません。
ナット：ルビは、InDesignのようなプロフェッショナルな出版アプリでも完全に実装するのが非常に複雑です。両面ルビは教科書（そして歴史書（敏先生））に見られますが、使用は稀で、私はそれ以外の場所では見たことがありません。それにかかるコストに比べて市場は十分大きくありません。
ナット：InDesignでは、二つの理由で熟語ルビを実装しませんでした。一つは、行内での改行を許可すると大量の計算が必要になることです。もう一つは、同じことを手動で達成するのが比較的簡単であることです。ウェブでは、すべてのレイアウトが自動的に行われるので、熟語ルビがより重要になるでしょう。
敏先生：行内での改行にコストがかかるなら、それを許可しないでも良いです。
敏先生：オーバーハングがルビを大幅に複雑にしています。
下農：css文書の一部で現在のドラフトを参照しているところがあります。フロリアンとfantasaiに知らせるべきです。
ナット：「ライティングルーム」のような形でjlreq-dを書くのはどうでしょうか？（木田：それは何ですか？）
木田：ルビを改行可能にする方法があるかどう
か、ナットと石井さんと別途議論したいと思います。

EPUB 3.3、何か影響は？

木田：下農さんから、EPUB 3.3が現在W3Cの推奨事項になっていると聞きました。私たちが知るべき何かありますか？日本の電子書籍に影響はありますか？

村田：3.0と3.3の間には大きな編集上の変更があります。しかし、内容の更新はそれほど多くはありません。日本の電子書籍に大きな影響はないと思います。
田島：電子書籍協会は、EPUB 3.3とは関係なく、電子書籍ガイドの更新を計画しています。最後の更新は2015年でした。
村田：アクセシビリティ要件が改善されていることを願っています。
ruby-t2s-reqsドキュメントの更新は？

村田：まだ更新はありません。

TODOs

完了：木田と下農さんがsimple-rubyドキュメントのレビューを終える。
完了：敏先生が長谷川さんの記事へのリンクを送る。
完了：小林さんがjlreq-dのスコープとモデルに関する覚え書きを更新する。
進行中：木田は、ルビ内での改行に必要な計算を減らすために、ルビをどのように単純化できるかについて、ナット/石井さんと会議を行う予定です。
進行中：ナット/村田さんが、Open Type / Open Font Formatの仕様の「kern」と「palt」の機能の提案された更新を草案化します。
小林さんが、テキストを横書きと縦書きの両方に対応させるガイドラインを作成します。
下農さんが、EPUBリーダーの開発者に対するアンケートを作成します。そのアンケートでは、そのような切り替えをサポートしていない電子書籍でもテキストの方向を切り替える機能をどのように実現しているかを尋ねます。
木田は、"progress, meter & input=range"の要素について、Should bars in HTML progress, meter & input=range elements be read upwards or downwards in vertical text? clreq#500 <https://github.com/w3c/clreq/issues/500> でclreqと議論します。
木田：simple-rubyドキュメントの中止をRichard、Florian、そしてfantasaiに伝える。
次回の会議は6/20 10am JSTです