Re: 2023-11-24 F2F ミーティングの議題

> 2023/11/24 13:57、Taku Yamaguchi <study.yamahige@gmail.com>のメール:
> 
> 木田さま、
> 山口です。
> 
>> Unicode を正しく扱っていることは日本語以前の問題として必須
> そうなのです、「結合文字」については、そこが迷うところですが、
> 
>> …特に追加で議論すべきことはあるでしょうか？
>> …が、アプリケーションが正しく文字を扱っていないと思われる例は時々見ます。
> 
> 時々見るので、念を押した方がよいと思って、「1.2.5.4 結合文字」を書きました。

おっしゃる通り、何か書いておいた方が良いかもしれませんね。結合文字に特化せずに、Unicode への対応で注意すべきことをまとめた部分を作るのはどうでしょう。ユーザー向け情報ではなく開発者向け情報なので、2章以降のどこかでしょうか。

>> b1 行と列を指定して、そこに属するセル(こま)を読める。
>> b2 セルが属する行と列を読める。
>> b3 列を指定して、各行の該当するセルを順に読める。
>> b4 行を指定して、各列の該当するセルを順に読める。
>> 
>> これで必要十分かどうかを議論したいということですか？
> 
> 表については、それです。表以外にも、段落についてissue #37に敏先生の次のような指摘があります:

なるほど。『表うんぬん以前に「◯◯という読み方ができる」というスタイルの要件』はそういう意味でしたか。段落に対して topic sentence をちゃんと作れ、は組版の問題ではなくて、書き方、書記技術の問題ですね。現在の目次案でも、テキストの作り方（1.5 日本語のテキスト <https://github.com/w3c/jlreq-d/wiki/1.5-%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%81%AE%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88>）の章がありますので、そこかな？

木田

>> 私は勝手に“段落読み”と読んでいるのですが，主に段落の先頭にある文だけを読んでいく方法をとることがあります．段落の構成を考えたテキストでは，これで結構意味を理解していくことが可能です．この方法は，私だけでなく，2冊ほど，この方法があるよと書いた本を読んだことがあるので，数は多くないが，こうした読者がいると予想されます．
> Ideal spacing before fullwidth opening punctuations at the beginning
> of sentences or lines #37
> https://github.com/w3c/jlreq-d/issues/37

> 
> これってparagraphの先頭にtopic sentenceを置く英文の書き方に対応する、正しい読み方の1つだと思います。
> MIcrosoft Wordのアウトライン表示には「1行目のみ表示」という機能があります。この機能が応えてる要件が、敏先生が指摘した「主に段落の先頭にある文だけを読む**読み方**」だと思うのです。
> 
> 段落の組み方には
> 「段落の先頭にある文だけを読む」読み方がしやすい
> という要件があるのではないでしょうか。
> この要件は、段落先頭の括弧の組み方だけでなく、デジタル・リーダーの「1行目のみ表示」機能にも及ぶ、と。
> 
> 
> 2023年11月24日(金) 13:18 木田泰夫 <kida@mac.com>:
> 
>> 
>> 山口さん、
>> 
>> 議題の提案ありがとうございます。
>> 
>> 2023/11/24 12:35、Taku Yamaguchi <study.yamahige@gmail.com>のメール:
>> 
>> 皆さま、
>> 山口です。
>> 
>> * 検索、コピー＆ペースなどに関係する話題が最近は少ないので、蒸し返してみたいです。ネタとして「1.2
>> 日本語で使用する文字」の「1.2.5.4 結合文字」はいかがでしょう？
>> 
>> 
>> これは Unicode に沿えば書いておられる期待通りに動きます。特に追加で議論すべきことはあるでしょうか？
>> 
>> 
>> 関連して、jlreq-d の前提として、システムが Unicode を正しく扱っていることは日本語以前の問題として必須です。が、特に何が重要、とういのはどこかにまとめて書いておくべきでしょうかね？　結合文字を正しく扱えること、コードポイントにして16bitを超える領域もちゃんと扱えること、検索や排列に使う文字比較は正規化をちゃんとすること、字形を正しく扱うためには互換文字を正規化してしまっては困る、などなど。OSは流石にきちんとしていてこれらで問題を起こしたりはしませんが、アプリケーションが正しく文字を扱っていないと思われる例は時々見ます。最近はないかな？
>> 
>> * 「デジタルテキストにおける表の組版#36」で、表うんぬん以前に「◯◯という読み方ができる」というスタイルの要件定義を提案しました。村田さん(？)の「6.読みやすさとアクセシビリティ」という章もありますし、いかがでしょう？
>> 
>> 
>> 行に求められる機能として下のような種類の読み方が可能であるべきという提案ですね。
>> 
>> b1 行と列を指定して、そこに属するセル(こま)を読める。
>> b2 セルが属する行と列を読める。
>> b3 列を指定して、各行の該当するセルを順に読める。
>> b4 行を指定して、各列の該当するセルを順に読める。
>> 
>> 
>> これで必要十分かどうかを議論したいということですか？
>> 
>> 木田
>> 
>> 2023年11月24日(金) 10:55 木田泰夫 <kida@mac.com>:
>> 
>> 
>> 皆さま、
>> 
>> 遅くなりましたが今日の議題案を送ります。追加などあれば提案を歓迎します。
>> 
>> CSS WG において、和欧文間のアキについての議論が盛んですので、まずそれを処理してしまいましょう。付随して、約物のアキの問題、そして最近アップデートされた GitHub issue を見て行きたいと思っています。
>> 
>> 
>> 管理的な問題
>> 
>> GitHub issue の処理方法
>> 
>> 問題に対してコンセンサスが得られてとりあえずそれ以上の議論は必要なく、jlreq-d なりのドキュメントに組み込まれているのを待っている状態をどう取り扱うか？　他のグループではどうだろう？
>> 
>> ドラフトを作ってゆく方法に関して
>> 
>> 現在ドラフトがとても柔らかい状態ですので Wiki 上で行っていますが、特定の問題に関しては敏先生が「段落の示し方 #40」などを作ってくださったように、GitHub issue としてトラックするのはどうでしょう
>> 
>> 
>> 和欧文字間クラスの再定義
>> 
>> CSSで再定義しようとしている。石井さんと私が、Unicode でプロパティとして定義する提案を準備中。
>> jlreq-d に向けて spacing property の提案を作ったが、議論に合わせてこれのアップデートが必要。また、現在の版では約物の処理も含めているが、CSS などでは約物のアキと漢字・欧文間の空きを分けて実装しているので、これらを分離させる必要がある。
>> issues
>> 
>> 和欧間スペース：フットマーク用の記号 *†‡◊ #44
>> 和欧間スペース：絵文字 #43
>> 和欧間スペース：組文字（㌀㎏）の扱い #42
>> 和欧間スペース：丸つき文字の扱い #41
>> [css-text] Extra spacing between ideographs and non-fullwidth punctuation/symbols #9479
>> [css-text][text-autospace] Is halfwidth Kana "non-ideographic letters"? #9471 (JLreq #378)
>> [css-text] The definition of ideographs includes punctuation marks #9501
>> [css-text] Add black square & white square characters to the definition of ideographs? #9603
>> 
>> 
>> 和欧文字間のアキ量
>> 
>> 和文文字とラテン文字の字詰め方向の字間の幅 #38
>> 
>> 
>> 約物のアキ処理
>> 
>> [css-text-4] text-spacing-trim and classes of closing punctuation #9504
>> 
>> 
>> スタイル付きの場合の和欧文字間や約物のアキの処理
>> 
>> 上記の議論では字間を文字の組み合わせに対して規定している。しかし JLReq における字間は文字のつかわれかたに影響を受ける。典型的には全角かプロポーショナルか。しかし、システムがある文字が全角か、プロポーショナルであるかを見分けるのは難しい。また、言語設定はシステム全体に適用されることが多いので、例えば日本人が英語も書くなど、複数言語を使うユーザーを対象にしにくい。
>> コーテーションマークの文字クラス #46
>> 
>> 
>> その他の jlreq / jlreq-d / clreq / csswg の open issue をスキャン
>> 
>> √  付きは議論が終わって結論が出ているもの
>> jlreq-d
>> 
>> 段落の示し方 #40
>> 文字サイズなどが異なる括弧等が連続した場合の処理 #39
>> デジタルテキストにおける表の組版 #36（結論が必要？）
>> √ Come up with a definition of 全角 that are generic enough to cover non-square typefaces #35
>> 
>> [css-values] Comments on the ic unit #8769
>> 
>> √ 割注と検索 #45
>> √ Ideal spacing before fullwidth opening punctuations at the beginning of sentences or lines #37
>> 
>> jlreq
>> 
>> todo: Update Ruby terminology wiki and solicit feedback from clreq #385
>> todo: Are there better ways to manage comments and changes to draft level documents? #384
>> Translate new text in README.md #381
>> √ Do we need a specialized version of text-spacing-trim: trim-all for brackets vs commas? #377
>> 
>> clreq
>> 
>> Emphasis dots should be centre-aligned with the text after the letter spacing is increased #550 (JLReq #368)
>> Lack of support for applying extra spacing between Chinese/Japanese and Western text #401
>> 
>> 
>> 木田
>> 
>>