JLReq TF meeting notes 2023-5-30

[Yasuo Kida （木田泰夫）]

JLReq TF meeting notes 2023-5-30 (日本語訳は下の方)

Attendee

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

Agenda

• 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 model and scope discussions

Page vs. Scroll

Kobayashi: JLReq-d should discard the page model, where pages with fixed kihon-hanmen are bound together to make a book. Instead, we should focus on the reflow & scroll model.

• background: He and some of us believe that the codex/book model is just a reminiscence of physical media. It loses all of its advantages in digital media except that the form plays a role in facilitating the transition from print to digital.
• general agreement with the following good points:
• Tsuda: Page flipping could be a good UI for transitioning between pages or locating a part of the document.
  • kida: It is an interesting point. Similar UIs can still be applied even on the scrolling model. We want to know more about this. At least we should not give an impression in jlreq-d that we discourage such a UI.
• Murakami: Does it mean we would also discard ebooks?
  • It is not that JLreq-d will forbid something. People who want to simulate traditional books on digital media (and doing so makes sense for some time) can still do it by reading both JLreq-d and JLreq.
  • kida: We should mention in jlreq-d that we will not handle this model and refer to jlreq for page binding. Alternatively, we can make a section in jlreq-d about bookbinding and explain why we will not cover the model.
• Murakami & Bin-sensei: How about columns?
  • kida: Columns can still be used on short and long content with sections. We can see examples on the web.
• Murakami: Do we handle vertical writing? A major application of vertical writing is ebooks.
  • kida: We will. The value does not diminish with the transition from print to digital.
  • Shimono: Web literature often has a switch that lets users change the text direction.
• Kobayashi: We should be unrestricted by the limitations of the current css or other technologies.
• Shimono: Let’s not mix up two different kinds of pages. One is the page as the unit of making up a book. The other is the page as a text segmentation similar to lines.

Line layout

• Bin-sensei: In traditional book publishing, there was an assumption that a line of text consists of about 40 characters for vertical composition on B6 paper, around 25 characters for two-column composition on A5 paper, about 35 characters for horizontal composition on A5 paper, and it becomes 12 characters for newspapers. Once set for publication, it doesn't change. This is a part of the concept of the kihon-hanmen, as explained in JLReq. The optimal kinsoku (a set of characters that inhibits line break) rule depends on the number of characters per line. Once the kihon-hanmen is determined, the number of characters per line is fixed, and so is the optimal kinsoku rule. However, such assumptions break on digital media with dynamic line length. Therefore, the kinsoku rules need to adapt as the line length changes.
• Nat: JLReq does not fully explain the concept of the virtual body (仮想ボディ) and how it works. With most implementations, an appropriate alignment between the Latin font and Japanese font breaks every time you change the Latin side of the font. It also breaks when you switch the size of the Japanese font in the middle of a line. In short, Japanese characters should not be placed using the baseline value embedded in fonts. Even if the text system is built on top of the Latin baseline architecture, one should create a layer so Japanese characters are laid out using their virtual body. That’s a part of the basics, but it is missing.
  • kida: I agree this is an important point.
• Nat: jlreq-d should explain rules for spacing (文字組み空き量設定) and rules for mono-space layout. If you look at SNS especially, I believe we need to develop rules for short sentences or phrases and rules for text containing more and more English words.
  • Bin-sensei: Nobody knows when/how to use the proportional layout of Japanese text. It is something new, and we should cover it in jlreq-d. (kida: really? Designers have long been using tsume-gumi, which is proportional and optionally kerning of Japanese text)
• Kobayashi: I recommend everybody to read “杉浦康平と写植の時代: 光学技術と日本語のデザイン.” It illustrates how Mr. Sugiura faced and struggled with phototypesetting, the new technology of his era, and moved text layout and editorial design forward. It is encouraging.
• Bin-sensei: We need to have a way to limit the number of characters per line within a specific range. Text is hard to read when a line becomes too long. When the width of a window becomes too wide, either the margin needs to be made larger, or columns need to be used. It should be automatic.
• Bin-sensei: How can columns be used under the scroll model?
  • Kobayashi: We see dynamic layout (responsive design) on the web. We can learn from them.
  • kida: We can learn from the web folks. Yet, we do not necessarily need to show solutions on jlreq-d. Web technologies and design are evolving. What we should explain is the nature and the background of the issues. We present the optimal result and why it is so, not necessarily how one can achieve it.
• Kobayashi: We might want to update JLReq as necessary to capture our thoughts for things we do not carry on to the digital version.
• Kobayashi: We want to capture the discussion as these are important topics for JLreq-d.
  • todo: kida to create a discussion thread at GitHub (done. w3c/jlreq-d#30 ).

How to author

Kida: I would like to agree on an approach we take to author the JLreq-d document. The original JLreq was based on the translation of the original Japanese text. Instead, I would like to compose JLreq-d in English first. Most of the original text would still be written and discussed in Japanese. English speakers (Kida, Nat, etc.) would digest the information and draft the content in English. The purpose is to eliminate assumptions that inevitably sneak in when we think and write in Japanese. By the assumption, I mean knowledge and experience in the Japanese language and layout. We will improve the process as we build up the experience. The Japanese version would start from the automatic translation (e.g., deepL or chatGPT) and will be brushed up by the team.

There was an agreement on the approach.

simple-ruby document

kida: At the last meeting, we agreed to update the working draft after fixing existing issues. After reviewing the whole document, I felt the document still has a few issues:

• As a whole, the English text could be better written.
• It is not “simple”. It contains double-sided ruby that is very much complex, and even JLReq does not explain it. Also, JLReq describes it as being extremely rare. If so, it does not make sense to put it in this “simple” version of the ruby layout document (even if we might include it in jlreq-d).
• The content is outdated. In our discussion towards jlreq-d, we agreed not to use the mono- and group- terminologies in the description. It is much simpler to explain the unified ruby and its exceptions for the mono case. As jlreq-d development is on the way, publishing this with this outdated content might make little sense.

We have a few options:

• Publish it with minimal fixes by fixing existing gh issues.
• Do a significant update. The content will also be a part of jlreq-d.
• Discontinue this document in its draft state. We will then focus on jlreq-d.

After discussions, JLReq TF agreed that JLReq TF will discontinue the document.

Todo: Kida to communicate it to Richard, Florian, and fantasai.

Discussions

• Nat: I would like jlreq-d to cover more sophisticated methods also.
• kida: agreed. jlreq-d is not a simple version of jlreq. It would cover sophisticated methods while showing how they can be simplified with drawbacks and benefits.
• Bin-sensei: We could write up the ruby part of jlreq-d first.
• Nat: Ruby is too complex to fully implement even in a professional publishing app like InDesign. The double-sided ruby can be found in textbooks (also history books (Bin-sensei))), but the use is rare, and I have yet to see it elsewhere. The market is not big enough compared to the cost it takes.
• Nat: We did not implement jukugo-ruby in InDesign for two reasons. One is allowing line break within takes a lot of computation. Two is that manually achieving the same thing is relatively easy. On the web, where all the layout is done automatically, jukugo-ruby would be more important.
• Bin-sensei: If allowing line break costs, it is ok not to allow it within.
• Bin-sensei: Overhanging is making ruby significantly complex.
• Shimono: Some places in css document refer to the current draft. We should let Florian and fantasai know.
• Nat: How about writing jlreq-d like we are in a “writing room”? (kida: what is it?)
• Kida: Would like to separately discuss with Nat & Ishii-san to see if there are ways to make ruby line breakable.

EPUB 3.3, any impacts?

kida: Shimono-san told me that EPUB 3.3 is now a W3C Recommendation. Is there anything we should know? Are there impacts on Japanese ebooks?

• Murata: There are major editorial changes between 3.0 and 3.3. There aren’t many content updates, however. I do not see much impact on Japanese ebooks.
• Tajima: The Denshikyo is planning an update of the Denshikyo ebook guide, unrelated to EPUB 3.3. The last update was in 2015.
• Murata: I hope accessibility requirements are improved.

ruby-t2s-reqs document updates?

Murata: no updates yet.

TODOs

• done: Kida and Shimono-san finish reviewing the simple-ruby document.
• done: Bin-sensei send a link to Mr. Hasegawa’s article.
• done: Kobayashi-san to update his memorandum re: jlreq-d scope and model.
• in progress: Kida will meet Nat/Ishii-san to discuss how ruby can be simplified to reduce the computation required to line breaking within the ruby.
• in progress: Nat / Murata-san to draft the proposed update of ‘kern’ and ‘palt’ features of Open Type / Open Font Format specification.
• Kobayashi-san to draft the guideline to make text compatible with horizontal and vertical writing directions.
• Shimono-san to draft a questionnaire for EPUB reader developers to ask how they achieve the feature that allows switching text direction even with ebooks that do not support such a switch.
• Kida will discuss with clreq at w3c/clreq#500 regarding the “progress, meter & input=range” elements.
• Kida: Communicate the discontinuation of simple-ruby document to Richard, Florian, and fantasai.

Next meeting is on 6/20 10am JST

---

参加者

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つは、行と同様のテキストの区切りとしてのページだ。

行レイアウト

• 敏先生：書籍において伝統的に、テキストの行はB6判の縦組では約40文字、A5判の2段組になると25文字くらい、A5判の横組で35文字くらい，それが新聞になると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）。

  著述方法について

木田：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"の要素について、w3c/clreq#500 でclreqと議論します。
• 木田：simple-rubyドキュメントの中止をRichard、Florian、そしてfantasaiに伝える。

次回の会議は

6/20 10am JSTです