Re: JLReq の文字クラスと Unicode の文字クラスとの関係

>
> JLReq 文字クラスが影響を与えるのは：A) 改行（分割の可否）、B) デフォルトの空き量、C) 行長の調整のための開け詰め、D)
> 本文の記述、でしょうか。文字詰めも Unicode に定義されているんですか？


ここがちょっとグレーなところで、justification
は一度却下されています。その理由としては、Unicodeは情報交換符号であり、レイアウトは上のレイヤー、ということが原則なんですが、Bidi や
Vertical_Orientation
はレイアウトに拘りますし、そもそも改行規則もレイアウトと言える分野なので、条件が合って、うまく説得できれば、というグレーエリアです。Aを中心に持っていきつつ、B-Dも潜り込ませられれば、という塩梅でしょうか。

いやはや、あなたにもできる簡単なお仕事 ♪ と言われて引き受けたのに、仕事がどんどん大変になってゆくような ^^;


あなた「なら」できる、の間違いじゃないでしょうか（笑

あと、考えなければならないのは、どのチャンネルでUTCにインプットするか。まあ、GoogleにはMark
> Davisもいることだし、わりとストレートに持ち込んでもいけるような。


インプットすれば「なるほど」とは言ってもらえると思いますし、UAX#14のEditorのAndyもGoogleなので、議題に上げることは可能だと思います。が、そこそこの作業量があり日本語の知識も必要そうな議題で、各メンバーは仕事の一部として作業しているので、投げ込んで、やってもらえるか、というと、そこで停滞してしまう可能性が高いのではないかと思います。

誰かUTCに行きませんか？
個人会員なら確か年間６万円とかです。ニーズのインプットがあり、CSSで必要で、エディターも誰かがやってくれる、という条件が揃えば、UTC
が協力してくれる可能性はだいぶ上がるのではないかと思います。UTR#50
の時は、個人会員になって、自費でUTCに行ったら、エディターやらせてもらえました。


2020年2月3日(月) 14:18 KOBAYASHI Tatsuo(FAMILY Given) <tlk@kobysh.com>:

> 木田さま、石井さま、
> 小林龍生です。
>
> なんだか、いい方向に向かいつつありますね。
> 木田さんの生きがいにもなるし。
>
> あと、考えなければならないのは、どのチャンネルでUTCにインプットするか。まあ、GoogleにはMark
> Davisもいることだし、わりとストレートに持ち込んでもいけるような。
>
> 2020年2月3日(月) 13:03 木田泰夫 <kida@mac.com>:
>
>> 石井さん、
>>
>> なるほど。似たような作業の経験者のお言葉とてもありがたいです。
>>
>> UAX#14ではJLREQの定める改行規則が実現できません。例えば村上さんが報告してくれたこちらの問題 crbug.com/827538
>>
>>
>> そのような問題があるのなら、Line_Breaking プロパティの改訂をゴールにするのは望ましい方向ですね。そもそも JLReq
>> 独自の改行規則を定めても採用してもらえませんしね。
>>
>> JLReq 文字クラスが影響を与えるのは：A) 改行（分割の可否）、B) デフォルトの空き量、C) 行長の調整のための開け詰め、D)
>> 本文の記述、でしょうか。文字詰めも Unicode に定義されているんですか？
>>
>> この問題に対して、https://github.com/w3c/jlreq/issues/166 を作りましたのでご活用ください。
>>
>>
>> いやはや、あなたにもできる簡単なお仕事 ♪ と言われて引き受けたのに、仕事がどんどん大変になってゆくような ^^;
>>
>> 木田
>>
>> 2020/02/03 12:08、Koji Ishii <kojii@chromium.org>のメール:
>>
>> とてもいいお話ですね。横からすみません、いつやるか、という議論とは別に、少しコメントさせてください。
>>
>> Unicodeプロパティを組み合わせて何かを定義する、というのは、思うよりも難しいです。縦書きのVertical_Orientationも当初それでやっていたのですが、それなりに複雑な組み合わせになってしまい、カーブフィッティングをしてしまう恐れがある、という指摘がCSSWGから上がりました。つまり、現在の値を元に式を作り込みすぎてしまい、追加される文字コードには結局対応できない、あるいはUnicodeのプロパティ値決定に悪影響を及ぼしてしまう（そのプロパティとしては正しい値でも、CSSに悪影響が出るためにできなくなる）という危惧です。最近では、日本語文字間でwhitespace
>> collapsingをするルールを決めるための議論でも、複数プロパティの組み合わせルールが複雑になってきたため、同様に断念して別の方向を模索しています。
>>
>> 作業がより大変になってしまうかもしれませんが、UAX#14 <http://unicode.org/reports/tr14/>の
>> Line_Breakingプロパティ <http://unicode.org/reports/tr14/#Properties>の改訂をゴールにする、というのはいかがでしょう？
>> 文字クラスは、詰めだけでなく、改行規則にも影響を及ぼしていて、UAX#14ではJLREQの定める改行規則が実現できません。例えば村上さんが報告してくれたこちらの問題
>> crbug.com/827538
>>
>>
>> せめて改行に関わるものだけでも、あるいは可能なら文字詰めに関わるものも含めて、JLREQで拡張するのではなくて、Unicodeの中に入っていただけると、実装側としては大変ありがたいですし、他のブラウザーやOSも含めて実装して貰える確率が格段に上がることは、木田さんもご存知かと思います。
>>
>> その分難易度は上がるとは思うのですが、ご検討いただけると幸いです。
>>
>> 2020年2月1日(土) 3:14 木田泰夫 <kida@mac.com>:
>>
>>> 先日のミーティングにおいて、文字セットを Unicode に移そうよ（大賛成！）、amendment でやりたいね（うっそ
>>> ー！）と言う会話がありました。
>>>
>>> 文字コードを Unicode
>>> 全体に拡張するには、文字クラスも拡張する必要があります。そのためには、独自に文字を列挙するのではなく、Unicode
>>> に文字が足されてもそれに応じてメンテナンスされ続けている Unicode
>>> の文字プロパティを使うべきでしょう。この変更が見かけほど単純ではなく、作業の量だけではなく、議論すべき項目がたくさん出てきそうだとの印象を持っていたので、短期的には無理だろうと思ったわけです。
>>>
>>> ただ、ひょっとして案ずるより産むが易しだったりして？JLReq の文字クラスと Unicode
>>> の文字プロパティの間に、意外に綺麗な包含関係にあるなんてことがひょっとしてひょっとしたらあったりして？ と思ってちょっと予備的調査をしてみました。
>>>
>>>
>>> *予備的調査*
>>> JLReq
>>> の文字クラスを見ると、文字が本来的に持っている性質ではなく、その文字が現れたコンテキストを表しているものがいくつかあります。これらはそもそも「文字クラス」ではなく、Unicode
>>> の文字プロパティで表すことができません。故にこれらは文字プロパティとは別の方法で記述する必要があります。まずこれらのクラスを省いて考えることにします。期待通り、これらのクラスにのみ含まれる文字はありませんので、これらを省いても分類から漏れる文字はありません。
>>>
>>> A.20 合印中の文字（cl-20）
>>> A.21 親文字群中の文字（添え字付き）（cl-21）
>>> A.22 親文字群中の文字（熟語ルビ以外のルビ付き）（cl-22）
>>> A.23 親文字群中の文字（熟語ルビ付き）（cl-23）
>>>
>>> A.30 縦中横中の文字（cl-30）
>>>
>>> A.24 連数字中の文字（cl-24）
>>> A.25 単位記号中の文字（cl-25）
>>> A.28 割注始め括弧類（cl-28)
>>>
>>> A.29 割注終わり括弧類（cl-29）
>>>
>>>
>>> これで JLReq 文字クラスが本来の文字クラスに近づきました。残った JLReq 文字クラスと Unicode General
>>> Category の対応を調べてみました。cl-nn が JLReq 文字クラス、アルファベット大文字と小文字の組み合わせがそこに含まれる文字の
>>> General Category です。
>>>
>>> cl-01 Pi Ps
>>> cl-02 Pe Pf
>>> cl-03 Pd
>>> cl-04 Po
>>> cl-05 Po
>>> cl-06 Po
>>> cl-07 Po
>>> cl-08 Lm Pd Po
>>> cl-09 Lm
>>> cl-10 Lm
>>> cl-11 Lo
>>> cl-12 Po Sc So
>>> cl-13 Ll Po Sc So
>>> cl-14 Zs
>>> cl-15 Lo
>>> cl-16 Lo
>>> cl-17 Sm So
>>> cl-18 Sm
>>> cl-19 Ll Lo Lu Nd Nl No Po Sm So
>>> cl-26 Zs
>>> cl-27 Cf Ll Lm Lo Lu Mn Nd No Pc Pd Pe Pf Pi Po Ps Sc Sk Sm So Zs
>>>
>>>
>>> *やっぱりな結論*
>>> 多くの General Category プロパティが複数の JLReq 文字クラスに現れていますので、General Category
>>> だけを用いて JLReq 文字クラスを表すことはできないことがわかります。Unicode
>>> には他にもたくさん文字プロパティがありますのでとりあえず悲観しなくても大丈夫ですが、それほど単純でないことがわかります。
>>>
>>> 加えて、今まで JLReq
>>> で扱ってこなかった文字たち（アラビア文字、ハングル、絵文字などなど）がどの文字クラスに入るべきなのかを議論して決め、それらを包含した定義にする必要があります。また
>>> bi-di との関わりは何か考える必要があるでしょうか？（ないといいな）
>>>
>>> やはり、JLReq の JIS X 4051 的文字クラスから、Unicode 的な世界への移行にはそれなりの議論と作業量が必要そうです。
>>>
>>> また、Unicode への移行は、自分の世界だけで閉じていた JLReq
>>> を、他の言語も混じる多言語処理の一部として定義し直す良いチャンスです。例えば、JLReq で添字について記述する必要はあるでしょうか？
>>> とすると、これはデジタルテキストのための次世代 JLreq と一緒にやった方が効率が良いのではないか、とそんな風に思うわけです。
>>>
>>> いかがでしょうね？
>>>
>>> 木田
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> KOBAYASHI Tatsuo（小林龍生）
> Scholex Co., Ltd. Yokohama
> homepage) http://kobysh.com/ <http://www.kobysh.com/tlk/>
>