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

木田 様
Nat McCully 様
皆様

 小林 敏 です．

まずは文字クラスの議論を終わらせる必要がありますが，その次には木田さんの
いうレベルを3つにする議論，木田さんの示す方法で何か考えれるかもしれませ
ん．

JIS X 4051は，現行のものは第3次規格です．第1次規格では，“ビジネス用文書
の組版規則に適用する”とあり，第一レベルの範囲を決める参考になるかもしれ
ない．

Natさんの言う連数字は，漢数字のことではないですか．JLReqで規定している連
数字はアラビア数字です．JIS X 4051では，連数字は必ずしも半角のアラビア数
字ではありませんが，最初の案では半角数字とあったように，主に半角アラビア
数字を対象に考えられたもので，コンアやピリオドは，その後ろにアキをとりま
せんから，幅はコンアやピリオドの字幅で四分が考えられます（二分としたフォ
ントもあるが）．

連数字がアラビア数字ということは，JIS X 4051の附属書1（JIS X 0213との対
応が示されている）で，連数字中の文字として“1-3-16～1-3-25（数字）”とあ
ることで示されています．

以上です．

  Nat McCully さんwrote

>基礎から一歩一歩、というアプローチですが、賛成です。しかし、どの辺までがMVP
>（最低限の機能性と有効性）なのかは、はっきり定義しないといけません。連続して
>いる括弧類を半角にして「はい終わり」、というのを避けたいと思います。
>
>文字組みクラスを合併するとspacingと伸縮の優先度と他のクラスとの区別は一緒にし
>てしまい、日本語組版の「基礎」はクラスの種類をどこまで細かくしないと日本語組
>版の真髄から離れてしまうかは難しいところです。AVANASとかEDIColorとかは簡易設
>定が１０種類ぐらいです。
>
>連数字中の文字クラスの省きのことですが、読点やカンマを半角にする機能として必
>須ではないかと思いますがいかがでしょうか。やはり、普通と違うコンテクストで独
>特な空き量や空き伸縮や優先度が必要であればクラスを残す必要があるかな、と。上
>のMVPの中に連数字処理が入っていることを前提としていればですが。
>
>ナット
>
>
>From: 木田泰夫 <kida@mac.com>
>Date: Monday, October 19, 2020 at 3:36 AM
>To: Kobayashi Toshi <binn@k.email.ne.jp>
>Cc: Nat McCully <nmccully@adobe.com>, W3C JLReq TF <public-i18n-japanese@w3.
>org>
>Subject: Re: 文字クラス整理 20日ミーティング・メモ
>
>
>Nat さん曰く：
>
>> 
>> 段落や行内のルールは日本語のルールの中で外国語を組んでいると私は思います。
>> なので、仮想ボディーの中で外国語をどう組むか、日本語とのバランスはどうする
>> か、アキ量と欧文ジャスティフィケーションをどう振り分けるか、などは言語の優
>> 先順位によって異なります。
>
>
>確かに、違いに理由があるとしたら、それは周りが日本語だからというより、むしろ
>日本語の文字配列アーキテクチャから来ている、もしくは言語の優先度の問題かもし
>れませんね。
>
>
>ただ、理由があるのかの判断、切り分けが難しそう。
>
>
>敏先生：
>>
>> それなりに難しいのは，かなと漢字だけ，あきらかに欧文だという部分ではなく，
>> 和文なのか，それとも欧文なのか，扱いがどちかわからないような例です．JLReqで，
>> この点では，あまり触れていません．
>
>
>そうなんです！ これ私も文を書くときによく悩みます。誰か基準をぜひ！
>
>
>私は、前の文字に付随している、もしくは一塊、と考えられる場合はその中で統一し
>ます。1.、1)、J.M. など。括弧書きで中に入るのが英字だけなら周りが日本語でも英
>字の括弧を使って、スペース一つ開けます。つまり英字括弧を使う理由は縦方向の問
>題。日本語も入る場合は全角で統一。でも（abc と def ）など両端英字の場合は迷い
>ます。(abc と def) の方が馴染みます。ただどんな場合でも開きと閉じは必ず統一さ
>せます。列挙が一番悩みます。まずはベースの言語の句読点を使おうとします。「A、
>B、C の三つ」みたいな感じ。ですがこの例だと「A, B, C の三つ」の方が見た目のバ
>ランスも良くかつ入力も簡単です。さらに列挙の中に英字と和字の両方が含まれてく
>るともう訳がわからなくなります。が、これもセパレーターは必ず統一させます。イ
>ンラインタイトル（わたくしの勝手な造語）を示すコロン：も全角か欧文かを迷うこ
>とがあります。「名前：木田泰夫」ですが「web: http://…」でしょう。ですが、こ
>れらが列挙だった場合は統一しなければなりません。が、どちらに統一？
>
>
>これは組版方法の問題というより書記技術の問題ですから、小林さん引退後の楽しみ
>にぜひお願いしたく。
>
>
>>
>> これらの方は，欧文組版にとても詳しい方々で，日本語組版は，欧文組版に学び
>
>> 
>> ながら考えてきた可能性が高いとにらんでいるのです．こうした傾向が，日本語
>> 
>> 組版の中に欧文的なルールが多く説明されてきたのではとも推測しているのです．
>
>
>先人の努力には頭が下がります。
>
>
>日本語組版技術はそれだけで一つの小宇宙なんですよね。その中に、日本の出版産業
>の必要性のある範囲でではありますが、マルチリンガルが含まれている。JIS 文字セ
>ットの成り立ちにも似ています。
>
>
>> 
>> 次に，三段階程度に分けて整理してみるという提案
>> 
>> うーん，考える意味はとても高いと思いますが，どうやって考えていくか，とて
>> 
>> もむつかしい，なぜなら，その判断の基準はどこにあるか？ という点が明確で
>> 
>> ないことがあるように思います．
>
>
>実はこれ的なこと、今までにもちょっとづつ（そして途中で止まっていますが）作業
>を行ってきましたよね。優先度、というやつです。JLReq には膨大な規則が書いてあ
>るけれど、どれが重要なのかわからない、という実装者からのフィードバックに対す
>る答えの準備でした。
>
>
>例えばですが、こういう風に考えるのはどうでしょう。
>
>
>まず基礎的で重要な機能を決めます。プレーンテキストでもそうなって欲しいような
>組版。逆にいうと、<span> とか <ruby> などの組版指示に頼らずに、純粋に文字だけ
>を見て判断できる必要があるという技術的制約があります。全角ベタ組み（フォント
>が実装）、及び基本的な禁則処理などが現在達成されていると思います。他に必要な
>ものはありますか？ 例えば行頭行末の役物、連続役物はどうでしょう。
>
>
>これを決めると、残りは二つのレベルですから、なんとか左右に振り分ける。もしく
>は、右、左、要検討、の三つに振り分ける。おそらくですが、大きな括りの機能その
>ものは重要で、その中の細かな規則にグラデーションが出てくるのかな、と想像しま
>す。
>
>
>判断の結果と同等に、もしくはより重要なのは、なぜそのように判断したかなのでは
>と思います。これも書いておきます。
>
>
>ともあれ一旦決めたら、間違いや足らないところもよりよく見えて来るでしょう。そ
>れはその時に直せば良いのかと。間違いがないことは目指さず、前に進むことを優先
>するということです。そんな感じで。
>
>
>とは言え、一歩一歩、まずは文字クラスの問題を片付けましょう。
>
>
>木田
>
>
>> 2020/10/19 14:13、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
>>
>>
>>
>> Nat McCully 様
>>
>>
>>
>>  小林 敏 です．
>>
>>
>>
>> 原則は， Natさんのおっしゃるとおりだと思います．
>>
>>
>>
>> しかし，JLReqで書いたのは，欧文のルールを書いたのではなく，あくまで，日
>>
>> 本語組版として欧字を含む文字列をどう扱うかという，いう立場です．ただ，そ
>>
>> の考え方は，相当程度は欧文のルールを前提にしているということです．なかに
>>
>> は，ここは全部欧文のルールでといいよ，という箇所もあります．
>>
>>
>>
>> 以下は，ついでに書くのですが，それなりに難しいのは，かなと漢字だけ，あき
>>
>> らかに欧文だという部分ではなく，和文なのか，それとも欧文なのか，扱いがど
>>
>> ちかわからないような例です．JLReqで，この点では，あまり触れていません．
>>
>>
>>
>> 前のメールにも書いた，以下のような例です．どこが和文，どこが欧文か，望ま
>>
>> しい形にする方法も，いろいろあります．
>>
>>  1）…… 2）…… 1) …… 2) …… 
>>
>>  1．…… 2．…… 1. …… 2. ……
>>
>>  1, 2, 3,…, n
>>
>>  とは（スペースspace）が とは（スペースspace)が とは(スペースspace)が
>>
>>  J. M. ケインズ J．M．ケインズ
>>
>>
>>
>> 以上です．
>>
>>
>>
>> Nat McCully さんwrote
>>
>>
>>
>> >
>> > 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）を入ればよい．
>> > > > つま
>>
>> >
>> > >
>> > > >
>> > > > り，一般の欧文のルールで解決できる．
>>
>> >
>> > >
>> > > >
>> > > >
>>
>> >
>> > >
>> > > >
>> > > > 以上です．
>>
>> >
>> > >
>> > > >
>> > > >  
>>
>> >
>> > >
>> > > >
>> > > >
>>
>> >
>> >
>>
>> >
>> >
>>
>>
>>
>> ――――――――――――――――――
>>
>>  小林 敏（toshi）  2020年10月19日
>>
>>  e-mail: binn@k.email.ne.jp
>>
>> ――――――――――――――――――
> 

――――――――――――――――――
 小林 敏（toshi）  2020年10月20日
 e-mail: binn@k.email.ne.jp
――――――――――――――――――

Received on Monday, 19 October 2020 23:52:48 UTC