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

Nat さん、

確かに何が重要で何がそうでないかの見極めは難しいと思います。ただ、優先順位づけ、レベル分けの作業では、JLReq からその記述がなくなるわけではありません。例えば今読んでいるメール、レポート、書籍、では自ずから要求される組版のレベルが異なってくるでしょう。例えばメールでは入力の手間がかからないことがとても重要ですし、組版指示などしないでしょう。プレーンテキストの場合そもそも不可能ですので文字情報だけで自動的に判断できる機能しか使えません。反対に書籍の場合は、美しく読みやすくするために、場合によっては語句を調整までして、さまざまな組版テクニックを駆使するでしょう（だからこそ InDesign のような専門家のためのソフトウェアが必要なのですね）。その時に必要な組版の機能はメールに求められるものと自ずから違ってきます。その差が今の JLReq では判然としません。

また、実装者にとっても、どの機能が重要なのかの参考になるような情報がありませんので、それは JLReq のユーザーからの長年の要求でした。優先付けがない状態では実装者は膨大な作業量の前に挑戦を諦めてしまいます。これは私の思いですが、ベースをきちんと示すことによって、メールのような日常目にするテキストの美しさの底上げをしたいのです。

レベル分けとは別に、何かの記述を削除する場合にはとても注意深くする必要がありますね。

さて、連数字中の話、「読点やカンマを半角にする機能」というのは JLReq に書いてあります？　記憶にないので JLReq を再度読み中ですが、説明してもらえると助かります。

木田

> 2020/10/20 5:04、Nat McCully <nmccully@adobe.com>のメール:
> 
> 
> 基礎から一歩一歩、というアプローチですが、賛成です。しかし、どの辺までが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
> ――――――――――――――――――