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

石井さん、

なるほど。似たような作業の経験者のお言葉とてもありがたいです。

> UAX#14ではJLREQの定める改行規則が実現できません。例えば村上さんが報告してくれたこちらの問題 crbug.com/827538 <http://crbug.com/827538>
そのような問題があるのなら、Line_Breaking プロパティの改訂をゴールにするのは望ましい方向ですね。そもそも JLReq 独自の改行規則を定めても採用してもらえませんしね。

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

この問題に対して、https://github.com/w3c/jlreq/issues/166 <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 <http://crbug.com/827538>
> 
> せめて改行に関わるものだけでも、あるいは可能なら文字詰めに関わるものも含めて、JLREQで拡張するのではなくて、Unicodeの中に入っていただけると、実装側としては大変ありがたいですし、他のブラウザーやOSも含めて実装して貰える確率が格段に上がることは、木田さんもご存知かと思います。
> 
> その分難易度は上がるとは思うのですが、ご検討いただけると幸いです。
> 
> 2020年2月1日(土) 3:14 木田泰夫 <kida@mac.com <mailto: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 と一緒にやった方が効率が良いのではないか、とそんな風に思うわけです。
> 
> いかがでしょうね？
> 
> 木田
> 
> 
> 
> 
>