Re: 明後日3日のお題

そうですね。では Eric の提案の中から前回話し合った文脈依存クラスに関係する項目についてまず議論するのはどうでしょう。

1. 文脈依存クラスをどうするか
前回の議論は、文字クラスを純粋な文字のプロパティにするために、文脈依存クラスを無くすことが目的でした。そのようなケースは説明で処理するという解決方法を議論しました。

Eric はこれとは異なる解決方法を提案していて、それは非常に優れた方法に感じられます。彼の提案は、縦中横、などの仮想クラスを導入すること。

現在の JLReq でも例えば Appendix D 表3 で “line head”, “line end” と言う仮想クラスを使っていますし、九つある文脈依存文字クラスのうち五つ、cl-20〜23, 30 は「どの文字も xyz の文字として使うことができる」と書いてあって、事実上仮想クラスです。

こうする方法の利点は、エンジニアが実装する際に、それぞれの機能の説明を読んで理解しなくても、データテーブルを解釈するエンジンがあれば簡単に高速に実行できる点です。説明にしか書いていない場合、それを理解して、例外処理を一つ一つ書かなくてはなりません。Eric が分離禁止文字を文字ごとに別クラスにすることを提案しているのも全く同じ理由です。データテーブルが少々大きくなっても、例外処理が少なくなるならそちらの方が全体としてはシンプルになります。

我々にとっては別の利点があるかもしれません。「JLReq は複雑なので、全容を理解して、それぞれの機能を実装するのはとても無理。どれが結局重要なの？」というのは我々がよく得ていたフィードバックです。そのために、日本語組版をシンプルにすることを私は主張してきました。シンプルにすることは依然として重要だと思いますが、データテーブルにして統一的に処理できることを示せたなら、その部分に関してプレッシャーは下がると思います。より上を目指せると言うわけです。

と言うことで、前回のミーティングの結果を読み直して、どのようにデータテーブルにできるのか考えてみるのはどうでしょう？　「どの文字も…」ではない文脈依存文字クラスは下の三つですが、それ以外にも、分離禁止文字のように、動作が説明で書いてあってテーブルに現されていない例（ルビ？）があればそれも洗い出す。

・単位記号中の文字（cl-25） 
・割注始め括弧類（cl-28） 
・割注終わり括弧類（cl-29） 


2. 行の折り返しを分離すること
Eric のもう一つの重要な提案は、字間だけを考えてクラスを作ること。つまり行の折り返しは別に考えるということです。その理由は Unicode の UAX14 / CLDR を使った行の折り返しがうまく動いているのでそれを使えばいいじゃない、ということです。

JLReq は「どうあるべきか」を示す必要がありますので、Unicode のでいいじゃないとは言えません。しかし行の折り返しのためのクラスと、字間のためのクラスを分離すること自体は JLReq にとっても合理的な可能性があります。特に、行の折り返しのために必要なクラスと、字間のために必要なクラスが異なるなら、そう言えるでしょう。

また、gap analysis (!) のタスクとして、Unicode での行の折り返しと、JLReq とのギャップを調べること、がありますね。

3. 縦書きと横書きで異なるクラス
Eric は縦書きと横書きで文字の属するクラスを一部変えています。Eric の GitHub コメントによれば、例えば U+0041 A や U+00C6 Æ は、横書きや縦書きで横倒しされた場合には欧文としての挙動（cl-27）、縦書きで正立した場合には漢字と同じ挙動（cl-19）をするだろう？との説明でした。時間があればこのポイントについて。


みなさま、他に関係する重要な点はありますか？　私が見落としている可能性もありますので、ぜひ教えてください。

木田

> 私の理解で Eric の提案の重要なポイントをまとめますと：
> 
> ・行の折り返しは UAX14 / CLDR に任せていること。これは Unicode 化にあたって順当ですね。我々は、UAX14 / CLDR と JLReq の相違している点をチェックする必要がありますね。
> 
> ・それによって文字クラスは字間だけ取り扱えば良いことになります。字間クラスと呼び変えた方が良さそうです。で、それを Unicode のプロパティとして提案するという点。これは我々の議論でも出てきていましたが、重要なポイントですね。
> 
> ・パラグラフの最初、縦中横、などの仮想的なクラスの提案。先週我々が議論した、文脈依存の文字クラス、を含めて統一的に処理できるように思います。なぜこれを思いつかなかたんだ！と思っております。
> 
> ・縦書き専用クラス、横書き専用クラスのあること。これの具体的な利点がまだよく理解できていないのですが、重要なポイントの可能性があるので挙げておきます。
> 
> ・糊、つまりデフォルトの字間とその調整の流儀を明に扱おうという提案。
> 
> ・また、マークアップにより字間クラスを明に変更できるようにとの提案。
> 


> 2020/11/01 11:48、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
> 
> 木田泰夫　様
> 
> 　小林　敏　です．
> 
> Ericの提案は，原則的な問題を含んでいますから，木田さんの要約していただい
> たメールから，そこから出てくる課題をまず拾い出すとからはじめたらどうでし
> ょうか（簡単に解決できればその場で中身も），で，難しい問題は問題として残
> しおく．そして，次に欧文の問題を考えるという順序，でも，欧文の問題は多岐
> にわたるので，ベースとなる全角と半角をどう考えるか，ということから始めて
> はどうかな？
> 
> 木田泰夫　さんwrote
> 
>> みなさま、
>> Eric の提案に含まれる諸アイディア、欧文の問題、など JLReq Unicode 化（もっと
>> 一般的に言って国際化ですね）の話題が豊かになってきていますが、明後日3日はどれ
>> から手をつけましょうか？
>> 木田