JLreq TF meeting notes 2022-6-14

JLreq TF meeting notes 2022-6-14
English follows.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
議題
JLreq-d の readme のレビュー
SC29 に関する課題の説明（村田）
CITPC での UAX#50 提案に関するミーティングの報告（村田）

Lreq-d の readme のレビュー
英語版にした Readme をRichard に早めに見せるべき。jlreq の時は完成してから英訳して他の言語の人も見られるようになったが、今回は早くからシェアしたい（小林）todo: read me を翻訳して Richard に見てもらう（木田）
翻訳のワークロードの負担という意味でも、技術の継承という意味でも、若い人たちの参加がもっと欲しい（木田）
jlreq-d は全ての言語の先駆けになるはず。言語共通の課題が多く現れるだろう（木田）
モバイル対応（見る人によって判型が変わる）（木田）
ユニバーサルデザインという言葉、最近ではインクルーシブデザインという言葉もある。どちらの意味か（津田）特定のデザインアプローチを前提とすることはない（木田）これをすれば全員大丈夫というようなことはない。必要であれば対応できるように仕組み・考え方を提供するのが大切（敏先生）
見開きにわたる表などは？（村田）電子書籍については言いたいことが多く出てくると思う。より良い方法があれば、紙をそのまま再現する必要性はない（木田）日本独特の要素として、縦書きの中での表、カラムによって縦横が混在するもの、その他独特の要素で残すべきものがあれば書いておく（木田）
表などを別画面で表示しながら読むということも可能。どのように指示を埋め込むか？（田嶋）
対象にしない応用について、議論、執筆中にも、これは議論しないという項目が出てくると思う。議論対象外の項目は出てくるたび追記してゆくべき（敏先生）
書き方の方針について、デジタル上の組版は進化しつつある技術なので、印刷と異なり、権威を持って定義するというような内容にはならない。逆に、現状に追い越されないように、定期的なアップデートが必要だろう（木田）
答えのない部分についても、はっきりさせる必要がある。答えがないことと、技術の進歩はまた別の側面なので（敏先生）
read me や、本文の先頭のどこかに、これは working document、変化し続ける内容であることを示そう（木田）
JLreq をベースにする、と言わないほうが良いのでは。JLreq にあろうがなかろうが必要なものを考える（敏先生）
方針の箇条書き部分は重要。議論にあたって考慮すべき内容になっている。書き方の方針も箇条書きに。書き方、簡単→高度な機能の順（敏先生）
ナビゲーション機能についてちゃんと考えるべき（敏先生）方針に一言入れておく（木田）
翻訳機能が使われる場面も多い。それに対して考慮すべき点はあるか（津田）関連して、形態素区切りの保存という議論はあった。編集履歴の保存（小林）アダプティブなレンダリングには可能性がある（村田）見えない要素を保存するのは注意が必要。誤りに気がついたり訂正する方法がない（木田）
組版で奥の細道と聖書とかの複雑怪奇な組版の例をたくさん集めている。そこで編者がやりたかったことを電子的にどう実現するのか。紙の形で出ているものを、元の目的に戻って、その意図をデジタルでどう実現するか。議論するのが面白い。一度プレゼンさせて（小林）やりましょう（木田）
必要性があるのにそれを実現する規格がないといったものも抽出して行きたい（木田）

SC29 に関する日本側の課題（村田）
SC29 (ISO/IEC JTC 1/SC 29) がフォントの仕様の国際規格を決めているが、日本からのチャネルがゼロ。日本からの参加が必要。送り込もう

CITPC での UAX#50 提案に関するミーティングの報告（村田）
そこで説明したスライドをシェアする（村田）
総論賛成で、現場は困っているが、標準化の意識は低い。これまで接点がなかったので、あのような場が増えると良いと思う。引き続き CITPC の中で議論を継続してゆこうということになっている。フォントを作る人と、使う人の交流がもっと増えるといい。上場企業ではコーポレートガバナンスコードの中に「標準化」が入った（田原）
前回の UTC では Peter が MS を代弁しているという話があったが、日本 MS の意見とは違う。文章を作るよりもミーティングの当日に話せば良いのではないか（村田、小林）
MS フォントへの影響は昔 CITPC で調べた。そのデータがある（村田）

TODO
紙の形で出ているものを、元の目的に戻って、その意図をデジタルでどう実現するか、のプレゼン（小林）と議論
Read me を英語に（木田）not done yet
Ken Lunde に次のミーティングに招いてもらう（木田）ongoing

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Agenda
Review JLreq-d Read Me
SC29 and Japan (Murata-san)
Updates from a meeting at CITPC regarding the UAX#50 proposal (Murata)

Review JLreq-d Read Me
We should translate the read me early in the process and get review from Richard. When the original JLreq was developed we developed it solely in Japanese and then the completed work was translated so others can read. For this time we want to make the development process visible so we can get feedback early (Kobayashi). Completely agreed. Actually we agreed to write it in English and translate it to Japanese (kida)
todo: translate the read me and get it reviewed by Richard, et. al.
issue: the translation work will be large. how we handle it? who? we want participation from younger generations.
JLreq-d will be the first in all languages, at leat within W3C, that tackles issues of text layout and books in digitally native environment. We will face many issues that are common across languages (kida)
It will cover mobile devices that have smaller screen and wide variety of screen sizes (kida)
Regarding the term “universal design”, I recently learned a different term “inclusive design”. They have slightly different approaches. Which approach does this document take? (Tsuda). We will not have or assume any specific design approaches (kida). There is no single design that covers everybody. The document should be something that raise the awareness, rather than suggesting specific design approach (Bin-sensei)
How about charts that span two facing pages? (Murata) If there are better way to implement charts on digital devices, we do not necessarily need to implement how it looks on printed books (kida) Are there Japanese specific considerations on charts? e.g. such as vertical and mixed-orientation. We want to mention these in the document (kida) If it digital we can open charts in a different window / area of the screen, and put side by side with the document. but how we embed such charts in the document? (Tajima)
Regarding the list of applications that we do not discuss in the document (e.g. applications that are primarily for printing and graphic design area), we might find more as we make progress. We should add them to this list. (bin-sensei). agreed.
The readme will be a living document and we will keep revising it throughout the process. Likewise, the JLreq-d itself will be a living document in a sense. Unlike printing technologies, the digital text layout / ebooks are areas that are still showing rapid progress. Therefore the document can’t be something that is authoritative. It will be a living document that requires constant updating by the future JLreq teams. Let’s clearly state in the documents that they are living documents. (kida)
The “policy on constructing the TOC and the contents” section would also become clearer if it shows bullet points. (Bin-sensei)
There are many issue where there is no, or we do not have, a good answer. Probably we should make these clear in the document.(Bin-sensei)
Probably we should not state that jlreq-d is based on jlreq. Digital do not have limitations that existed on print and vice versa. We’ll consider what is necessary.(Bin-sensei). OK.
We should somehow touch on navigation feature in the document. The function existed in printed books, and it exists in digital world in different forms. This is one of the area that books can take advantage of digital technology (Bin-sensei). Will add it to the readme (kida)
Automatic translation is becoming popular (and it does not exist in printed documents). Are there things we should consider to better support the feature? (Tsuda) Related to the issue there are ideas that puts bunsetsu boundaries in the document data (Kobayashi). There are many possibilities in adaptive rendering (Murata) We need to be cautious when we attach invisible information to the text. It is hard to detect errors and correct them and they can be hidden factors in unexpected rendering. (kida)
I am collecting examples of complex print layout such as Oku-no-hosomichi and the bible. It would be interesting and worth discussing how we can achieve the intention, not the look, with digital technologies. I can prepare a presentation. (Kobayashi)
We want to find, along the way, areas where we do not have adequate support from various standards (css, unicode, etc). (kida)

SC29 and Japan (Murata-san)
SC29 (ISO/IEC JTC 1/SC 29) defines international standards for fonts. However there is no channel that we can feed requests from Japan. We might want to send somebody to SC29.

Updates from a meeting at CITPC regarding the UAX#50 proposal (Murata)
Murata-san shared a presentation that he presented at the meeting. It is mostly regarding the aforementioned SC29 issue.
Everybody understands the benefit of improving the standards. Especially users are suffering. Font venders etc., however, do not have knowledge on if standards can be changed or how they can do it. They do not have such an experience. What they do now is to just ignore standards that do not work for them. So, the meeting was a good opportunity to raise awareness. It was agreed that they want to keep discussing about it in CITPC. Also, he felt that more communication would be beneficial between font makers and users. (Tahara)
At the previous UTC, Peter Constable represented MS, but MS Japan do not agree with him. We want to discuss it at the meeting with Ken/UTC. (Kobayashi-san)
We understands that the change (UAX#50 proposal) does affect MS fonts. We did the research in the past and I have the data (Murata)

TODO
Kobayashi-san to present and discuss re: examples of complex layout in print, and how we achieve the intention with digital.
Kida to translate the readme.
Kida to talk to Ken Lunde for a meeting re:UAX50 proposal.

The next meeting is on 7/12 Tuesday 10 am JST.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

- kida