- From: <kida@mac.com>
- Date: Wed, 2 Nov 2022 16:19:28 +0900
- To: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-Id: <CEAA8683-1F16-44EE-81F5-E94E5AC8971F@mac.com>
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 > 2022/09/21 14:43、Yasuo Kida <kida@mac.com>のメール: > > JLreq TF meeting notes 2022-9-20 > > 出席 > > atsushi, kida, murata, shinyu, tabata, tajima, tlk, toshi, tsuda, yamamoto > > 議題 > > jlreq-d の原稿の編集方針 > JEPA セミナー > グループルビの折り返し提案 version 2 > WCAG 2.2について > TPAC 持ち帰り話題 > jlreq-d の原稿の編集方針 > > 下記の方針を提案、了承 > > 章ごとなど、部分に分けてソース文章を作成することができること > 完成形は単一のファイル。ランタイムでまとめ上げる方法は表示に時間がかかる > 英語・日本語を一つのページにまとめない。英語と日本語が繰り返し現れる表示を避けるため > 上記方針のもと技術的に何が可能かを下農さんが試し、サンプルを作成した。「respecでの複数ページに分割しての編集」というタイトルの8/24のメール参照。GitHub の自動化の仕組みを使って、部分に分けられたソース文章をチェックインの度に単一ファイルに組み上げることが可能だと言うことがわかった。文書の分割単位は進みながら決める。日本語が元の原稿と英語が元の原稿ができるだろう。 > > JEPA セミナー > > 10/24にJEPA主催でjlreq-dを紹介するセミナーを行う。レビューのため木田がプレゼンのドラフトのドラフトを共有した。 > > todo: 皆:プレゼンを見てわかりにくい箇所、フォーカスがぼやけている箇所などあればインプット。 > > グループルビの折り返し提案 version 2 > > 前回のミーティングでのいくつかのフィードバックをもとに木田が提案をアップデートした。内容について了承。細かな点は実際に原稿を書きながら考えることになった。 > > 議論 > > 敏先生から: > この一ヶ月、書籍でルビを分割している例を注意してみていたが、意外と分割している例が多い。こんなに多いとは思わなかったとのこと。 > 分割している例には、親文字の字数の多いのが多い。分割しないと調整量がおかしくなるからだろう。 > 分割する場合、熟語の構造を気にせずひと文字の単位でどんどん分割している。例えば「行/動計画」。 > 岩波文庫に問い合わせたが、特にルールがないとのこと。 > 複数の親文字に一文字のルビというケースは日本語でもある。「坐(ざ)右衛(え)門(もん)」 > 出版会は、熟語ルビ派、モノルビ派に別れている。JLreq は熟語ルビを単純化した。本来の複雑なルールは JLReq の付属書に書いてある。 > 村田さんが問題を提起:モノルビ、グループルビ、熟語ルビ、は全てスタイル、表示の問題であって、文書構造の問題ではない。すなわち、後から切り替えられるべき。TFはこの問題提起に同意。jlreq-d に、そのように記述することになった。また、検索の動作について、マークアップで分割されても検索できるべきであることも明記。 > 村上さんから:css に ruby-merge があり複数のルビを統合することができる。 > 村上さんから、熟語ルビやその拡張で区切りを示す必要があるが、それは文書構造とは本来は関係がない。ルビ内部の分割はマークアップなしに賢く自動分割できるべきではないか、と問題提起あり。確かに、区切りを示すことは例えば英単語のハイフネーションに事前にタグを挿入するようなもの(木田) > 課題:jlreq-d に記述を入れよう、ということになった場合、それをどのように記録しておくべき? > > WCAG 2.2について > > 下農さんが、WCAG 2.2のセクション1.4.8に日本語でも通用するか疑わしい記述のあることを見つけてくれた。 > https://w3c.github.io/wcag/guidelines/22/#visual-presentation > > 具体的なポイント > > text is not justified の理由。日本語に当てはまるかどうか > 150% は行間狭すぎる。普通の人では 150-200%。アクセシビリティではもっと広い。ただし明確なガイドラインはない > 段落間を開ける方法は日本語では一般的ではない。字下げ。 > また 1.4.12 にも疑問点が見つかった。 > todo: 木田が wcag に github issue を投げる。→ done > w3c/wcag#2680 <https://github.com/w3c/wcag/issues/2680> > TPAC 持ち帰り話題 > > 全角でない括弧類の挙動はどうあるべきか > [css-text-4] text-spacing needs to handle non-fullwidth punctuation also <https://github.com/w3c/csswg-drafts/issues/6091> > ベタ! > そのような文字の組み合わせをするべきではないので、印刷では編集の段階で修正する。デジタルテキストでは規則を作っておく必要あり > また、関連して、「印刷では編集の段階で修正する」の作業をデジタルではテキストを作る人が知っている必要がある。テキストの書き方、のガイドラインが必要。 > 村上さん:Unicode に拡張した文字クラスはこれを考慮しているか? 木田:不明なのでチェックする > → 敏先生が規則をドラフトしてくださった > → todo: Unicode に拡張した文字クラスで全角と半角の約物の組み合わせがサポートされているかチェックする > > 次回ミーティングは 2022-11-1
Received on Wednesday, 2 November 2022 07:19:55 UTC