Re: 結合文字の扱い



> 2023/11/26 13:37、Taku Yamaguchi <study.yamahige@gmail.com>のメール:
> 
> was: 2023-11-24 F2F ミーティングの議題
> 木田さま、みなさま、
> 山口です。
> 
>>> 時々見るので、念を押した方がよいと思って、「1.2.5.4 結合文字」を書きました。
>> 
>> おっしゃる通り、何か書いておいた方が良いかもしれませんね。結合文字に特化せずに、Unicode への対応で注意すべきことをまとめた部分を作るのはどうでしょう。
> 
> そうですね。
> Macでですが、今でもPages、Keynote、Word、PowerPointは検索で結合文字を拾ってくれません(日本語だけじゃありませんが)。スクリーンショットを添付します。
> ブラウザではSafari、Chrome、Edgeは大丈夫、Firefoxはダメみたい。

Wow これは酷い。Pages / Keynote にはバグを出しておきます。

mac のシステムに最初から付属しているアプリケーションは大丈夫のようです。おそらくペーストした途端に（もしくは外部に取り出す瞬間に？）composed 方向に正規化されているように見えます。例えば mac Mail で見ると下の「が」は両方とも U+304C です。

> 次の文字たちをコピーして普段使ってるアプリに貼り付けて、これらを検索タームにして互いにヒットするか見てみてください…そもそも、これら文字がそのままメールで伝わるかどうかも定かでありませんが…
> が(U+304C)
> が(U+304B, U+3099)
> ä(U+00E4)
> ä(U+0061, U+0308)
> また、「か」や「a」でも検索を試してみてください。「か」や「a」で検索すると結合文字の「が」や「ä」の方**だけ**がヒットするアプリがあります。
> (そもそも、「か」で検索して「が」がヒットするのが良いか悪いかについても議論がありそうですが。)

「か」で検索して「が」がヒットすべきか：おそらく期待と異なりますよね。つまりヒットすべきではない。

a/äはどうなんでしょう。Unicode 一般で考えると何か指針はあるんでしょうかね？mac のシステム付属のアプリケーションだとどちらもマッチしませんので、おそらくそれが正しい？

では「か」で検索して「カ」がヒットすべきか？：これは？ mac だと、メモではマッチせず、Mail だとマッチします。ううむ…

木田


> 2023年11月24日(金) 14:16 木田泰夫 <kida@mac.com>:
>> 
>> 
>> 
>> 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 日本語のテキスト）の章がありますので、そこかな？
>> 
>> 木田
>> 
>> 私は勝手に“段落読み”と読んでいるのですが，主に段落の先頭にある文だけを読んでいく方法をとることがあります．段落の構成を考えたテキストでは，これで結構意味を理解していくことが可能です．この方法は，私だけでなく，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 行を指定して、各列の該当するセルを順に読める。
>> 
>> 
>> これで必要十分かどうかを議論したいということですか？
>> 
>> 木田
> <結合文字で検索.jpg>

Received on Wednesday, 29 November 2023 07:57:48 UTC