W3C

– DRAFT –
JL-TF main call

28 September 2021

Attendees

Present
atsushi, kida, murata, shinyu, tahara, tajima, tatsuo, toshi, xfq
Regrets
-
Chair
kida
Scribe
atsushi

Meeting minutes

UAX 50へのフォントのレター

kida: 3文字変更したらUAX 50がAJ1互換になるということが分かった
… 中国語の方が問題なかった。韓国の方は村田さんから報告がまだない。
… Adobeからはこの3文字で問題なさそうという話が来た。
… Richardにproofreadしてもらった結果が来たので統合する。
… W3CとCITPCからもendorseが得られたので、これをunicodeに送るということになったので報告する。

tatsuo: richardにこれを投げてと木田さんから頼むのが一番いいのではなかろうか?

kida: 送る主体はJL-TFである

tatsuo: richardを通して送るのがいいと思う
… Richardの名前を入れるかどうかは聞くとしても、それがいいと思う。

ruby-a11y文書

murata: a11yが軽視されていて、さまざまな表示・処理ができないという問題がある
… そこを全部まとめて、a11yの点を考えないといけないというような点のまとめ
… どうするかというのはCSS rubyとhtmlへのプルリクエストをやる話なので、技術面は明記していない
… googleなどの実装者向けに技術面でなくdaisyなどのアクセシビリティーの大家から発言することが重要な状況ではないかと思っている

kida: JLReqから流していいかという同意を撮ることがここでは重要?

tatsuo: こういうletterをJL-TFを通して流すというのはいいと思う

murata: Florianなどと議論していたが、W3Cをいれて、W3Cも含めたletterにした方がいいという話も出た

tatsuo: DAISYからのletterという形にする?

murata: JL-TFからの賛成というのもなくてもいい?

kida: DAISYから直接W3Cに投げて、JL-TFはあとでそれでいいんではないか、という話でもいい?

murata: このレターについてはそうである
… 細かい技術的な話は別な文書

kida: このオープンレターに関してはJL-TFではノーアクションである

murata: ruby-a11yの文書についてはWG Noteに向けての活動をしたい

kida: どのような流れでやる?
… この文書についてのレポジトリを作るという合意を取る。内容については新しく作るレポジトリで議論する。
… JL-TFからRichardにこの文書の新規レポジトリを作るという提案を投げることにする。

murata: ruby-t2s-user-requirementsという名前はどうか
… 実装のアーキテクチャに関しても書けたらいいが、要求までしか書ききれないとも思っているのでこの名前を提案する

次期JLReq目次案

kida: 最初に方針を書き下した
… デジタルネイティブ、国際化環境に対応する、というトップレベルの方針

toshi: デジタルネイティブというよりはモニターに表示するというニュアンスを出すのは同か

kida: そういう意味だとは思うのではあるが。。。

toshi: われわれも昔デジタルには転移したのではある

kida: 確かに少し書いた方がいいとは思った。
… 書籍を作るためにデジタルになるのは中間で利用しているという話だった。ここでは完全にデジタルで閉じるところ。

murata: ユニバーサルデザインも入れたい

kida: これにより、内容に対して、これらの考えを取り入れて変更を加える
… ただし、新しい実験や発明の場所ではないので、行き過ぎには注意したい。
… ある程度現在のJLreqが持ってる規範性を崩したくない
… 記述を現在の固定したページ向け、書籍を作るというコンテキストで説明するのではなく、リフローアーキテクチャー中心に変更する

nat: 新しい発明をしないという点はいいが、西洋的な開発者向けに日本語組版は全面的に新しい発明だと思うのでそこは記述したい。

kida: 新しい発明というのは、既存の日本語組版に対して全く新しいまだない新規の何かという意味。

kida: シンプルにする、簡便なルール、unicodeに拡張した文字クラス。ただし、プライオリティーの低いものについても削らずにプライオリティーをつけることで示したい。
… 内容を削りすぎて、これはv2を参照、これはv3を参照という状況は避けなければいけない。
… CSSやrubyの件のように、実装がまだともなっていない部分もある。

kida: そういう点をつまみ出して、JLReqの側から論点整理ができないか、というのは思っている

nat: illustratorでは正しい仮想ボディ—のサポートを横組みではしていないのに、割注があるが、rubyがちゃんとしていないなどもある。
… そういうのもあるので、プライオリティ付けは重要だと思う。

kida: そういう方面も含めプライオリティーを各項目に書く。

tatsuo: 日本の現在の状況を踏まえて、こういう理由でプライオリティーがついている。ただ、昨日としては必要なので他の実現手段で実現しても大丈夫、みたいな書き方もある。

kida: 章立てとして、現在の2勝を大幅に拡充したい。
… 文字・書体の基本、英文字と合わせるという話。
… 行組版。ベースラインシステムとの整合。

toshi: 行組版といった場合には、文字を並べるところの字送り方向・行送り方向があるが。
… 行送り方向について書かれた文書はあまり多くない。

tatsuo: リフローベースというのがあったが、それとも関連するが、文字をどう二次元の空間に表現するか、という何かの表現か。
… 行組版というのは日本語ではあるが、何かいい言葉を発明した方がいいのかもしれない。

kida: 字送りも行送りも、その手の企画では英語で出てくるので、大丈夫なのではなかろうか?

tatsuo: 提案だが、行組版と書いているところを、リフローを含む、、、

toshi: リフローはあまり書かなくていい。リフロー以前の問題。

tatsuo: リフローを前提としないといけないのである。

nat: 行がどう成り立つかどうかという点について、サイズなどを含めて考えないといけない。
… 日本語ではベースラインでなく上下関係もあり、フォントメトリクスから全部の情報があるわけではない。
… ベースラインのことを何とかしないといけない。

tatsuo: 敏さんの行組版のこだわりということを考えると、字送り方向の話を書いて、そのあとで行送り方向の話をちゃんと書くのがいいか?

toshi: 字送り方向がベースラインでは?

kida: そのほうこうで

kida: アクセシビリティー、言及する。読みやすさについても。
… 組版機能全体を概説する。機能へのジャンプを入れたインデックス化するのはどうか。
… どこかで日本語では表記と読みが二つあることを説明しておくべきなのか。
… 表記では動発音すべきかが確定しない文字であるという話。
… 日本語は複数の流れがあるのでルビというものがあるのだ、というのは入れたい。
… 機能的に組版機能を分類して、俯瞰するような節を入れたい。

tatsuo: とてもいい指摘だと思うし面白いと思う。ある語をどう読むかというのがコンテキスト依存であるというのもある。
… もう少し先に行ってからどうするかを考えた方がいいのではなかろうか。
… JLreq全体としてどうするかをもう少し先で。

toshi: 木田さんが考えてる機能的俯瞰という話を突き詰めるとどこかで書きたくなる話ではあると思う。

tatsuo: テキストをどう読むかという話。

kida: 章立ての話に戻って、書籍を作る、ページというものがあって、というような概念の前提がいろいろ張り付いている。
… 今のスクロールする形式には適用されないので、どのようなページ形式、表示形式、でも必要な機能について解説して、ページの場合のみ洗われるもの、
… 書籍で現れるものを章で分けるべきかなと思っている。

shinyu: 対象となるテキストと書かれているところで、電子書籍は見開きはxになっているが、ある場合とない場合の両方があると思う。
… 横長の時は見開き表示になるなどの処理も行われている。
… epubのプロパティーにもpage-spreadというのがある。

murata: 規範として考えると、見開きは盲腸のようなものだと思う

toshi: 本には織り込みというものがある
… 見開きがあるというのを前提とせず、広いものに表示するときにどうするか。横長・縦長になるような状況もあるので、いろいろできるという一般化の話にすればいいのではないか。

tatsuo: なんで電子書籍になっても画面が横になったときに見開き・2つに分けて表示する必要があるのかという必要を考えるといい。
… 紙の本でも段組みがある、電子書籍で紋段組みがある。一行があまりにも長いと読みにくい。
… 横組みにしたときにだらだらっと並んでいると読みにくい。
… 紙の様に見開きにした方が全体的に把握しやすいというので残っている話である。
… 電子書籍なので版面設計がすべて統一しないといけないというのにこだわる必要はないので、ページごとに自由なレイアウトを実現できるようにすべきという話。

nat: ページの作り方には、美しさがある。日本のデザインでは文字と文字以外の領域のバランスの話がある。

tatsuo: 美的感覚を入れる話はしたくない

toshi: 余白を含めるときにどういうように入れるかというのは書いてもいいのではないか?

tatsuo: デザイナーの仕事みたいなところに規範性を書くというのは反対。

kida: いま入っているルールというのは作業性もあるが、美しさも含めて考えて成立してきたものであるのではないか。
… 程度問題だと思う。プライオリティーにも気を付けないといけない。
… 絶対これでないといけないという話を書くのは気を付けないといけない。実験的なものを入れるということには気を付けないといけない。
… まずはnatの文章を見たい。

toshi: 実験的という点が出たが、モニターでの読み方と髪での読み方、読みやすさというのが意外と差がないのではないかというのを感じている。
… 紙での経験がモニターでも生かせるのではないかと思っている。

tatsuo: どんどんディスプレーの性能が上がって読みやすくなっている気もする。

kida: macosにヒラギノを選んで正解だった。紙の品質にどんどんなっていく。

kida: 各項目を考えるときに気を付けたいのは、リフロー・国際化・シンプル化・アクセシビリティー。
… プライオリティーを入れたい。この項目についてはどうか、という異論があるとは思うので、押し付けにならないように理由を示して書く。
… 複数の方法があるものについて、デフォルト、その理由を入れたいが、その点についても注意して描く。
… また何らかの整理を行いたい。
… エッジケースについて書くかどうかについては微妙。
… ルビの長さとか。
… これまでのモデルだと、記述者が気を付けるというのもあったが、デジタルデータだといろいろあるので。

kida: 対象となるテキストについても分類を表にしてみた。この分類から章に分けた方がいいのではないか?という話を出した。

toshi: ウェブでも絵と文字が埋め込まれているようなものがある場合、はどう分類する?

kida: ページがある場合の配置の考慮は、ページがある場合についての記述があるので参考にしてもらう?

kida: 以下の表はドラフトではあるが、章立てを検討している。
… メール中のグリーンの部分は大きな章立てのマーク

kida: 書籍の組み方というのを別建てにすることで、ページの組み方に依存した暗黙の何かをここにまとめたい

kida: どうするかと思ったのはいくつかあり、数式の組み方、見出し処理
… 見出し処理について欧文と一緒という話ではない。サイズ指定なども実際に参考になるのは書籍の時くらいか?

nat: 柔軟性についてはいろいろある

kida: 日本語の美しさを保ったところでの一般化はnatの知識が大きく生きるかもしれない。

toshi: 4.で大きくまとめているが、見出し・注・図版の3つに分けてしまうという手もある。
… 歴史的な経過からまとめてしまっているけれども。
… 4.5を文字送りのパートに
… これは基本へというコメントもあるが。やって見ないとわからないが。

kida: 縦書きというのもあるので日本語特有の書き方がかなりあるのではないかとも思っている。

toshi: 見出しというのはあるくくりをつけて入れ子になっているというのを読者に対してどう出すかという話。
… 紙の本だけでなくウェブでもいろいろあるのではないか。

tatsuo: 見出しについて、日本語以外の文書でも当てはまるような階層構造の話、というのと別に、日本語の縦書きでの見出しで言うと、行どりについて。
… 何行取るという発想はあまり他ではない?
… 行どりが重要というのは、日本語組版の場合は行送りのピッチを固定しようという方向であるが、それに対してどう考えるかというのが一つ。
… あと美的な点。文字が大きくなると字間をつめたくなるという要求も出てくる、というような2つの要素がある。

toshi: 見出しの大きさに従って空間を大きくするという、行どりで考えなくても何らかの方法が必要だが、行どりでやるとやりやすいという点ではあった。
… ウェブではページの概念はないので重要性は下がるが、スペースは重要である。

tatsuo: そこらへんは最初の文書全体のポリシーと関わると思う。

toshi: 見出しの頭に付けるラベル名をつけるとちゃんと読める。
… 第1章とかそういうのは効果的。
… ポイントシステムで統一する

tatsuo: トップレベルに戻って、幾つか思った点がある。ルビのところで、そんなのはつけなきゃいいじゃないか、みたいな話。
… 読者対象を日本語を理解したい、組版システムの実装者だと思っていたが、どんな文章が来るかわからないというエッジケースの話が出た。
… そんなのを作るなよ、という視点もある。
… この文書そのものがデジタルドキュメント製作側向けにもという視点を入れるのもいいのではないか。

kida: フォーカスが広くなりすぎないならいいのではないか。
… 実装者はエッジケースが来てもどうにかしないといけないけれども。

nat: 以前のjlreqでは紙の世界をちゃんと説明していたが、ウェブのリフローの世界でどうすべきかという説明がないので考えないといけない。
… なぜ3行どりがいいのかという説明も足りない。

atsushi: エッジケースが大量にあるものはsimple-rubyみたいに別文書という手もある

murata: 広げすぎるとまとまらないのでエッジケースはあるというメンションでいいのではないか。

kida: 全角数字と半角カナ。

tatsuo: 文字と書体に書くのはどうか?

kida: 今の変更を加えたものをjlreq githubに置くので、以降の議論はそちらでできればいいかなと思う。
… トップレベルについては共有したい。

toshi: 序文を文章にするのはどうか

AOB

kida: 次回はnatの提案文書が欲しい

tatsuo: 全体のプライオリティー付けみたいなところで、アノテーションをつけていくのはどうか

kida: 次回11/2にする。

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

Diagnostics

Succeeded: s/。あ/か。

Succeeded: s/波動/はどう

Succeeded: s/同か/どうか

No scribenick or scribe found. Guessed: atsushi

Maybe present: nat