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.
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.
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
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.
Line layout
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:
We have a few options:
After discussions, JLReq TF agreed that JLReq TF will discontinue the document.
Todo: Kida to communicate it to Richard, Florian, and fantasai.
Discussions
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?
ruby-t2s-reqs document updates?
Murata: no updates yet.
TODOs
Next meeting is on 6/20 10am JST
参加者
atsuda, atsushi, kida, murata, nat, shinyu, suzuki, tajima, tlk, toshi
議題
JLReq-d モデルとスコープの議論
ページ対スクロール
小林：JLReq-dは、ページモデル、すなわち基本版面という固定したページが束ねられた冊子のモデル、を廃棄すべきである。代わりに、我々はリフロー＆スクロールモデルに焦点を当てるべきだ。
行レイアウト
ナーたちは長い間、詰め組みを使用してきました。それは日本語のテキストの比例で、オプションでカーニングです）
小林：これらはJLreq-dにとって重要なトピックであるため、議論を記録したいと思います。
著述方法について
木田：JLreq-d文書の作成方法について合意したいと思います。オリジナルのJLreqは、元の日本語テキストの翻訳に基づいていました。それに代わり、私はまずJLreq-dを英語で作成したいと考えています。オリジナルのテキストの大部分はまだ日本語で書かれ、議論されるでしょう。英語を話す人々（木田、ナットなど）が情報を消化し、英語で内容を草稿にします。目的は、日本語で考え、書くときに避けられない仮定を排除することです。その仮定とは、日本語とレイアウトに関する知識と経験を指します。私たちは経験を積み重ねるにつれてプロセスを改善します。日本語版は自動翻訳（例えば、DeepLやChatGPT）から始まり、チームによってブラッシュアップされます。
このアプローチについては合意がありました。
simple-ruby文書について
木田：前回の会議で、既存の問題を解決した後に作業草稿を更新することに合意しました。全文を見直した後、私はまだいくつかの問題があると感じました：
いくつかの選択肢があります：
議論の結果、JLReq TFは、JLReq TFがドキュメントを中止することに合意した。
Todo：木田がRichard、Florian、そしてfantasaiに通知する。
議論
か、ナットと石井さんと別途議論したいと思います。
EPUB 3.3、何か影響は？
木田：下農さんから、EPUB 3.3が現在W3Cの推奨事項になっていると聞きました。私たちが知るべき何かありますか？日本の電子書籍に影響はありますか？
ruby-t2s-reqsドキュメントの更新は？
村田：まだ更新はありません。
TODOs
次回の会議は
6/20 10am JSTです