Re: 文字クラス整理　20日ミーティング・メモ

JLReq の範囲についてですが、日本語組版ルールに沿って外国語文字組みをする（例えば和欧混植の）場合は、段落や行内のルールは日本語のルールの中で外国語を組んでいると私は思います。なので、仮想ボディーの中で外国語をどう組むか、日本語とのバランスはどうするか、アキ量と欧文ジャスティフィケーションをどう振り分けるか、などは言語の優先順位によって異なります。JLReqは日本語が第一の場合、のルールでしょう。英語のルールを優先すると同じコンテンツでもアキや行の配置は違うはずだと私は思います。

—Nat
________________________________
From: 木田泰夫 <kida@mac.com>
Sent: Sunday, October 18, 2020 8:35:38 PM
To: Kobayashi Toshi <binn@k.email.ne.jp>
Cc: W3C JLReq TF <public-i18n-japanese@w3.org>
Subject: Re: 文字クラス整理 20日ミーティング・メモ

この議論でもう一点。

JLReq が、欧文組版で通常（の定義は色々ありますが）行われない欧文の振る舞いについて規定しているのはなぜだろうかという点について。

先のメールの最後に書いた、それが和文の中に出てきた時にのみ重要だからという可能性がひとつですが、もう一つの可能性は、JLReq がより高度で精緻な質を持っているということ。

この件に限らず JLReq に書いてある各々の機能がどの程度の重要性があるのか。例えば、メールのようなほぼプレーンテキストであっても実現したいこと、ワープロつまり日々のレポートやビジネスレターなどで欲しい機能、高度な出版で望ましい機能、と三段階程度に分けて整理してみると我々にとっても読む人にとってもスッキリし、かつ JLReq に新たな深みが出てくるかもしれません。

例えばですが、数字と演算子の間に行の区切りが来ないのは教科書などで特に重要、それ以外では望ましいけれど重要ではない程度。とか。そういうことがわかれば読み手にとっても我々にとっても大きな価値があるのかなと。

木田

> 2020/10/19 11:08、木田泰夫 <kida@mac.com>のメール:
>
> 敏先生、
>
> 詳細な議論ありがとうございます。理解するのにとても助かります。
>
> b 連数字と単位記号の議論において、スペースの問題を説明してくださいました。この連数字や単位記号に伴うスペースの幅や改行の可否について、欧文で行われている方法を訂正して JLReq で別のことを決める必要があるのか？　というとどうでしょう？
>
> 例えば欧文組版において数字と単位記号との間に通常の単語間スペースを使っている場合、JLReq で、いやこれは別の幅であるべき、と規定する意味がどのくらいあるのか。例えば欧文組版において数字と単位の間で行がえが起こることを許容しているとしたら、JLReq でいやだめだ、と規定する意味がどのくらいあるのか。ということです。
>
> 敢えて違える重要性はそれほど高くないのではないだろうか、と思うわけです。
>
> もちろん、欧文組版、特に科学論文などの組版の歴史の中で、数字と単位の間のスペースの最適な大きさや改行の可否について深く考えた人がいなかったとは思えませんので、ちゃんと規定があるのではないかと想像します。もしくは一旦あったものが淘汰されて今や単純化されているのかもしれません。どちらにせよこれは欧文組版の問題ですから、JLReq の中で欧文組版の領域であると思われる事項を別個に分けて、欧文組版の問題として提起してみるのはどうでしょう？
>
> その過程で、これらが欧文組版の問題でありながら、和文の中にそれが出てきたときにのみ重要になるのだ、もしくは縦書きの時にのみ重要なのだ、ということに気がつくのかもしれません。それはそれで素晴らしい知見になるでしょう。
>
> いかが思われますか？
>
> 木田
>
>> 2020/10/18 9:50、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
>>
>> 木田泰夫　様
>> みなさま
>>
>> 　小林　敏　です．
>>
>> 文脈に依存する文字クラスの扱いについて，別の面から考えてみました．
>>
>> 文脈に依存する文字クラスは，大きく2つに分けられます．
>>
>> a　文字列を<span>…</span>などでくくり，属性指定が必要
>>
>>> 合印中の⽂字（cl-20）
>>> 親⽂字群中の⽂字（添え字付き）（cl-21）
>>> 親⽂字群中の⽂字（熟語ルビ以外のルビ付き）（cl-22）
>>> 親⽂字群中の⽂字（熟語ルビ付き）（cl-23）
>>> 割注始め括弧類（cl-28）
>>> 割注終わり括弧類（cl-29）
>>> 縦中横中の⽂字（cl-30）
>>
>> b　文字列を<span>…</span>などでくくり，特に属性指定を必要としない
>>
>>> 連数字中の文字（cl-24）
>>> 単位記号中の⽂字（cl-25）
>>
>> aは，該当文字の振る舞いについては，なんらかの属性指定が必要なので，その
>> 属性を適用すればよく，属性を説明（規定）すれば，その振る舞いは決まる．特
>> に文字クラスとして，つまり個々の文字の振る舞いを明示しなくてよい．
>>
>> bは，結論から言えば，特に，この2つの文字クラスを作成しないで，一般の欧文
>> のルールで基本的によい．
>>
>> 連数字中の文字（cl-24）は，そもそも，今ではこのような文字は使われていな
>> いということから削除を考えたわけです．しかし，連数字には，アラビア数字以
>> 外にコンマ，ピリオドと四分スペースが含まれていますが，四分スペース（これ
>> の扱いは後述）以外は，欧文文字に含まれるアラビア数字，コンマ，ピリオドと
>> 同じ振る舞いであり，連数字があったとしても，特に別の文字クラスにする必要
>> はないのです．（アラビア数字の位取りや小数点のコンマ，ピリオドの前後では
>> 2行にわたる分割禁止ですが，これは一般の欧文でもコンマ，ピリオドの後ろに
>> 欧文スペースが入ら場合と同じで分割禁止．）
>>
>> 単位記号も，実は同じです．問題は，乗算を示す方法として，単位記号中に四分
>> スペースが入る形式もある（これはJLReqで含まていないいと前に書いたが，単
>> 位記号の文字クラスにはスペースも含めているので，これも含む）．この四分ス
>> ペースの問題を除くと，欧文文字と同じ振る舞いであり，別の文字クラスにする
>> 必要がない．
>>
>> 次に，連数字や単位記号に含まれる四分スペースについてですが，これは，この
>> を属性で指示するのか，あるいはなんらかのスペースを入れるかということにな
>> る．属性で指示するなら文字クラスの必要性が出てくるが，実務を考えれば，そ
>> れは手間であり，なんらかのスペースを入れればよい．つまり分割を禁止する四
>> 分スペースがあればよい．
>>
>> U+2005（FOUR-PER-EM SPACE）は四分スペースですが，これは分割禁止しないの
>> では？ また，U+00A0（NO-BREAK SPACE）またはU+202F（NARROW NO-BREAK
>> SPACE）は分割禁止だが，アキの大きさはどうなっているのかな？　U+2007
>> （FIGURE SPACE）は分割禁止だが，数字の字幅と同じなので，位取りの場合には
>> 使いたくない．U+2060（WORD JOINER）も分割禁止だが，これはアキがないので
>> は？
>>
>> U+2061（FUNCTION APPLICATION）とU+2062（INVISIBLE TIMES）は，連数字や単
>> 位記号に含まれる四分スペース用みたいだが，アキの大きさは？
>>
>> U+200B（ZERO WIDTH SPACE）とU+2005（FOUR-PER-EM SPACE）の四分スペースを
>> 組み合わせればいいのかな？
>>
>> 最後の問題は，単位記号の前に配置するアラビア数字または量を示す欧字との字
>> 間の問題
>>
>> ここのU+2005（FOUR-PER-EM SPACE）またはU+0020（SPACE）を入ればよい．つま
>> り，一般の欧文のルールで解決できる．
>>
>> 以上です．
>> 　
>>