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

> 2020/02/03 16:26、Koji Ishii <kojii@chromium.org>のメール:
> 
> JLReq 文字クラスが影響を与えるのは：A) 改行（分割の可否）、B) デフォルトの空き量、C) 行長の調整のための開け詰め、D) 本文の記述、でしょうか。文字詰めも Unicode に定義されているんですか？
> 
> ここがちょっとグレーなところで、justification は一度却下されています。その理由としては、Unicodeは情報交換符号であり、レイアウトは上のレイヤー、ということが原則なんですが、Bidi や Vertical_Orientation はレイアウトに拘りますし、そもそも改行規則もレイアウトと言える分野なので、条件が合って、うまく説得できれば、というグレーエリアです。Aを中心に持っていきつつ、B-Dも潜り込ませられれば、という塩梅でしょうか。

まあね。plane text に justification が必要か？と問うて私も dismiss しますね ;)

と言いつつ、ICU というもっと踏み込んだ存在もありますし、ever updating unicode に対していつも適切な行長の調整を行うために何が必要かと言う議論は valid ですよね。


> いやはや、あなたにもできる簡単なお仕事 ♪ と言われて引き受けたのに、仕事がどんどん大変になってゆくような ^^;
> 
> あなた「なら」できる、の間違いじゃないでしょうか（笑

いや、もう、心ウキウキな retirement life を送りたいのに。甘言に乗ってしまって反省しきりです。

と言うか、最初のメールの趣旨は、予備調査により amendment では無理そうなことが分かったから、次世代 JLreq  ネタとして小林さんよろしくお願いします、と言いたかったのです。ですよ！


> あと、考えなければならないのは、どのチャンネルでUTCにインプットするか。まあ、GoogleにはMark Davisもいることだし、わりとストレートに持ち込んでもいけるような。
> 
> インプットすれば「なるほど」とは言ってもらえると思いますし、UAX#14のEditorのAndyもGoogleなので、議題に上げることは可能だと思います。が、そこそこの作業量があり日本語の知識も必要そうな議題で、各メンバーは仕事の一部として作業しているので、投げ込んで、やってもらえるか、というと、そこで停滞してしまう可能性が高いのではないかと思います。
> 
> 誰かUTCに行きませんか？　個人会員なら確か年間６万円とかです。ニーズのインプットがあり、CSSで必要で、エディターも誰かがやってくれる、という条件が揃えば、UTC が協力してくれる可能性はだいぶ上がるのではないかと思います。UTR#50 の時は、個人会員になって、自費でUTCに行ったら、エディターやらせてもらえました。

Murata-san also wrote:
> 75USD/yearですね。その10倍払うとlifetime


人身御供が必要というわけですね。私、人身御供にぴったりな若人を JLReq TF の中に一人知っていますよ。

;)

木田

> 2020年2月3日(月) 14:18 KOBAYASHI Tatsuo(FAMILY Given) <tlk@kobysh.com <mailto:tlk@kobysh.com>>:
> 木田さま、石井さま、
> 小林龍生です。
> 
> なんだか、いい方向に向かいつつありますね。
> 木田さんの生きがいにもなるし。
> 
> あと、考えなければならないのは、どのチャンネルでUTCにインプットするか。まあ、GoogleにはMark Davisもいることだし、わりとストレートに持ち込んでもいけるような。
> 
> 2020年2月3日(月) 13:03 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>:
> 石井さん、
> 
> なるほど。似たような作業の経験者のお言葉とてもありがたいです。
> 
>> 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 <mailto: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 と一緒にやった方が効率が良いのではないか、とそんな風に思うわけです。
>> 
>> いかがでしょうね？
>> 
>> 木田
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> KOBAYASHI Tatsuo（小林龍生）
> Scholex Co., Ltd. Yokohama
> homepage) http://kobysh.com/ <http://www.kobysh.com/tlk/>