次回のミーティングは6日火曜日10:00-

JLReq TF の皆さま、

暖かい秋、、と思っていたら急に寒くなりましたね。

さて、次回のミーティング <https://www.w3.org/2021/04/jlreq-meeting-info.html>は4日後の6日火曜日いつもの時間10時から
下のような議題を考えていますが、提案を歓迎します

議題案
チャーターの更新の確認 (https://github.com/w3c/jlreq/pull/345)
前回 todo の確認（下のリスト）特に非和文約物とのアキ問題の文字確認
石井さんから問題提起のフォントの詰め組テーブル問題、フォント分科会を開きますか？
メールのタイトル: CJKフォントのpalt（詰め組）とkernの関係
私が二月が終わるまであまり時間を使えない、のでその間の進め方
残りの時間：圏点の問題含め、下農さん提案のJLreqに溜まっているissueの整理
メールのタイトル: jlreq github issueトリアージ


TODO
レイアウトの二次元配列が内容の理解に必要であるような教科書の例を探して共有（敏先生 done）
jlreq-d フォント部分の原稿：早期にドラフトを共有（Nat）
縦書きでのプログレスバーなどの方向: GH issue にコメント（木田: done）
和文約物と非和文約物が連続した場合のアキの制御：提案のふるい分け条件にかかる文字を確認して次回検討する（下農）
ルビの折り返しが実装し難い問題：提案文書をアップデート & 技術的可能性を確認（木田：3月に）
文字の方向の指定：信頼できる「upright」の方法が必要とのGitHub issueを作る（誰？まだ）
HTML要素の縦書き対応：要素の仕様をレビュー・テストする（具体的方法未検討）
HTML要素の縦書き対応：jlreq-d の中でカバーする（木田：目次案アップデート まだ）

木田

> JLreq TF meeting notes 2022-11-1
> 
> https://github.com/w3c/jlreq/issues/343

> 
> Attendee
> 
> atsuda, atsushi, kida, murata, nat, shinyu, tahara, tajima, tatsuo, toshi
> 
> Agenda
> 
> 日本電子出版協会でのプレゼンの報告
> jlreq-d フォント部分の原稿の説明（Natさん)
> 縦書きでのプログレスバーなどの方向
> 和文約物と非和文約物が連続した場合のアキの制御
> ルビの折り返しが実装し難い問題
> 山口琢さんからの問題提起に含まれる問題たちを整理
> 日本電子出版協会でのプレゼンの報告
> 
> あらすじを説明（木田）
> プレゼンはここ：JLReq-d presentation @ JEPA jlreq-d#25 <https://github.com/w3c/jlreq-d/issues/25>
> 質問で印象に残ったのは
> アクセシビリティ
> 山口さん（メール）
> 山口さんが挙げたキャプションの問題に対する敏先生の回答で気がついたこと（木田）
> JLReq は書籍を対象としているが、jlreq-d は遥かに幅広い範囲を対象としていること。図版やキャプションの置き方に関しても、JLReqなら書籍ならこう、と言えるがWebではデザインの領分と言える部分が大きい。書籍なら通常こう、とか、何か言い方の工夫が必要そう。
> アクセシビリティについて議論
> 研究が進んでいない分野が多く、最適値がわからない場合が多いが、やらなければならない（小林）
> 経験や実績による値を伝えるしかない。症状によって異なるので、調節可能になっているのが重要だろう。どの要素が調節可能でなければならないかを知る必要がある。
> テキストだけ読んだけで内容が合理的に伝わるようになっている必要がある。日本の教科書にはレイアウトにストーリーがあって、そのまま読み上げても目の見えない人には内容を理解できない。視覚障害者向けのDAISY教科書ではレイアウトで示されていることをを解釈して言葉に直す。これが難しい。全面書き直しに近い作業となる。
> 紙の本の電子化でも似たようなケースがある（コラムなど）
> 注などのパラレル構造も同様な問題がありそう
> 同じ画面内に説明文などを入れたい（コンテキスト忘れた）
> 縦横互換テキスト：前ページの、上の図、など位置の指定が問題
> → todo: 教科書の例を探して共有（敏先生）
> 
> jlreq-d フォント部分の原稿の説明（Natさん)
> 
> Nat から大まかな説明があった。11 pages。太郎さんとレビュー中
> 和文を組むときにどのようにしなければならないか、簡潔にまとめたセクションを作って欲しい（木田）
> 完成してから提出すると、書き直し部分が多くなってしまう可能性がある
> → todo: 早期にドラフトを共有（Nat）
> 
> 縦書きでのプログレスバーなどの方向
> 
> Should bars in HTML progress, meter & input=range elements be read upwards or downwards in vertical text? #342 <https://github.com/w3c/jlreq/issues/342>
> 山口琢さんからの問題提起にも似た問題が含まれる
> 下からがデフォルトで合意
> → todo: GH issue にコメント（木田: done）
> 
> 和文約物と非和文約物が連続した場合のアキの制御
> 
> 前回のミーティングを受けて下農さんが「Unicodeに拡張された文字クラス」の拡張を提案（10/21メール）
> クラスを三つ増やす：B/A/BA の非全角版
> Line_breakプロパティを利用すると対象文字をうまく捉えられるので、Line_breakプロパティを使う。既存のクラスもこれを使うようにアップデート
> 方針に合意。提案のふるい分け条件にかかる文字を確認して次回検討することになった
> https://github.com/w3c/jlreq/blob/gh-pages/docs/spacing_property/spacing_property.md

> Review the spacing property document to cover space collapsing between fullwidth and proportional punctuations #340 <https://github.com/w3c/jlreq/issues/340>
> https://github.com/w3c/csswg-drafts/issues/6091 <https://github.com/w3c/csswg-drafts/issues/6091?fbclid=IwAR00LQ926otASQxHwwbkcWXx1bULqoFDr9pOIeRpTTm0KoQqfD2ZxNGDG5U>
> ルビの折り返しが実装し難い問題
> 
> ルビの折り返しを可能する提案を書いたが、折り返し位置の計算が大変で実装は難しいとのフィードバックが Nat / 石井さんからあった。同じ理由で熟語ルビの実装が進んでいない。
> 敏先生より、1) 短い熟語に限れば計算できないか、2) 程度長いものは行間注として別扱いするという提案あり
> 行間注としてラベルをつける。そのようなものルビは親文字の開始位置だけを用い、親文字の範囲は無視してルビをつける。親文字はルビに関係なく普通に改行。そこにルビ文字列を行に入るだけ配置し、次の行に折り返し。これで折り返し位置によって行の長さが変わらなくなる。ラベルのないものは、前後の行がスカスカになるのを許容する。
> 行間注としてラベルをつける代わりに、字数で判断するというアイディアも出た
> → todo: 提案文書をアップデート（木田）
> → todo: アップデートしながら実装可能性をNat/石井さんと確認（木田）
> 
> 山口琢さんからの問題提起に含まれる問題たちを整理（10/29メール）
> 
> 外部リンクを示す矢印の向き in 縦書き
> UI が左上起点で、「次」が右方向だから、右上か？
> アイコンは良いが、文字の右上矢印を使うと縦書きにした際に右下になってしまう。text-orientation upright はフォントによってうまく動かない
> それは仕様のバグではないか？
> ハックとしては縦中横が使える
> → todo: 信頼できる「upright」の方法が必要とのGitHub issueを作る
> 
> HTML要素の縦書き対応
> キャプションの配置位置
> 縦横どちらでも指定できるべきであろう
> フォームコントロールや置換要素の縦書き対応
> フォームコントロール：ボタン要素(button)、入力欄要素(input)、HTML選択要素(select)、テキストエリア要素(textarea)など
> 置換要素：img, video, canvas, applet など
> 置換要素は外部のオブジェクトだが、縦書き用に変化すべきものはある？少なくとも情報は伝わるべきであろう。
> 展開・折りたたみ方向
> 生成されたテキストの向き
> marker 擬似要素に縦中横を指定すればできるはず。箇条書きは指定しなくても縦にしてよ。
> → todo: これらの要素の仕様をレビュー・テストする
> → todo: これらを jlreq-d の中でカバーする
> 
> 次回ミーティングは 2022-12-6
>