- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Mon, 19 Oct 2020 13:53:52 +0900
- To: 木田泰夫 <kida@mac.com>
- Cc: W3C JLReq TF <public-i18n-japanese@w3.org>
木田泰夫 様 小林 敏 です. 欧文組版でも,実は個別の事情でアキを区別する方法が行われてきました. 例えば,コンアの後ろは語間スペースでいいが,ピリオドは,文末だけらアキを 大きくし,全角アキにしていた例もかつてはありました.これは,それほど意味 はあるの,語間というアキがあれば区別がつくのだから,その必要はない,とい うことから,今日というか,ずっと以前からピリオドの後ろもコンマと同じで語 間スペースでいいということで,ほとんどというか,全部がそうしていると思い ます. こうした細かいアキは,欧文組版でも,一部というか,かつてはというか,ピリ オド以外に以下のようなアキが行われていたようです. コーテーションマークの内側をほんのすこし空ける(活字組版でもhair space というものがあり,unicodeでもU+200A((HAIR SPACE)がある) 感嘆符(!)や疑問符(?)の前をほんの少し開ける(五分などといわれていた ことがある) こうしたことは,今でも行われている例もあるようだが,傾向としては単純化に むかって,多くは,こうした処理はしていないでしょう. その傾向を考えると,数字(量を示す欧字)と単位記号とのアキは,もう語間ス ペースでいいのではと,私は考え始めています. ただ,そうした組版はあるということは,どかに書いておいた方がよいでしょう が,JLReqに書いてあるので,それでいいかと思っています. これに対し,数字の位取り(一般に三桁ごと)を示す方法に,空白をとる方法と, コンマを入れる方法がある.この空白は,固定したアキが望ましく,しかも,数 字と同じ幅ではなく,その半分,つまり四分アキが望ましいと考えています(な ぜなら,小数点のピリオドは字幅がだいたい四分).ですので,U+2007(FIGURE SPACE)は使いたくないし,この位取りは2行にわたる分割禁止ですから,数字 (量を示す欧字)と単位記号とは別問題のように思います. 木田泰夫 さんwrote >敏先生、 > >詳細な議論ありがとうございます。理解するのにとても助かります。 > >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)を入ればよい.つま >> り,一般の欧文のルールで解決できる. >> >> 以上です.
Received on Monday, 19 October 2020 04:54:29 UTC