JLReq TF meeting notes 2023-5-30

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 kihon-hanmen and the book model where fixed-size pages are bound together. 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 except for 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: Traditionally, there has been an assumption that a line of text consists of around 40 characters, columns have 25, and newspapers 12. Once it is set for publication, it does not change. It is a part of the concept of kihon-hanmen, as explained in JLReq. An optimal kinsoku (a set of characters that inhibit line fold) rule depends on the number of characters per line. The number of characters was a constant variable in a printed publication, and the kinsoku rule is also so. Such assumptions break on digital media with the dynamic line length. As a result, kinsoku rules need to follow as the line length change.
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. JLreq-d のモデルとスコープの議論 jlreq-d#30 <https://github.com/w3c/jlreq-d/issues/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 it 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 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> 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