- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Tue, 20 Oct 2020 09:05:18 +0900
- To: 木田泰夫 <kida@mac.com>, "Atsushi Shimono (W3C Team)" <atsushi@w3.org>
- Cc: public-i18n-japanese@w3.org
- Message-Id: <87D6A674B1B615A6191A4D@k.email.ne.jp>
木田泰夫 様 下農 様 小林 敏 です. 1/18という基準は,欧文文字の設計する際の最小数字をどうするかという際に考 えられたもので,1/18に限られるわけではありませんが,かなり有力な考え方で す.ちなみに,日本の写真植字では,1/16でした. ご参考までに活字時代の文字幅(これを公開したものはほとんどなく,唯一見つ けたもの)を,まとめた資料がありますので,PDFを添付いたします. この資料を見ればわかるように,1/18の元の大きさは,必ずしも全角ではありま せん.そのへんの事情は,PDFを見てください. 添付ファイル名:欧字の字幅_2.pdf 以上です. 木田泰夫 さんwrote >おー、貴重な情報が。やはりあるんですね。空白幅の微妙な調整が。 > >木田 > >> 2020/10/19 23:50、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール: >> >> shimonoです >> >>> On 2020/10/19 11:07, 木田泰夫 wrote: >>> 例えば欧文組版において数字と単位記号との間に通常の単語間スペースを使ってい >>> る場合、JLReq で、いやこれは別の幅であるべき、と規定する意味がどのくらいあ >>> るのか。例えば欧文組版において数字と単位の間で行がえが起こることを許容して >>> いるとしたら、JLReq でいやだめだ、と規定する意味がどのくらいあるのか。とい >>> うことです。 >>> 敢えて違える重要性はそれほど高くないのではないだろうか、と思うわけです。 >>> もちろん、欧文組版、特に科学論文などの組版の歴史の中で、数字と単位の間のス >>> ペースの最適な大きさや改行の可否について深く考えた人がいなかったとは思えま >>> せんので、ちゃんと規定があるのではないかと想像します。もしくは一旦あったも >>> のが淘汰されて今や単純化されているのかもしれません。どちらにせよこれは欧文 >>> 組版の問題ですから、JLReq の中で欧文組版の領域であると思われる事項を別個に >>> 分けて、欧文組版の問題として提起してみるのはどうでしょう? >> >> 論文の場合、数字と単位の間は半角空白でなくて各論文誌で規定された(たいてい >> \,か\>あたり)空白命 >> 令を入れるという書式規定がありますので、その部分での改行は原理的になされな >> い処理になると思いま >> す。 >> >> # これ以降は本題とそれたところに行くコメントだと思いますので、雑感としてみ >> てください。 >> >> LaTeXでは、文字間の空白について1/4とか1/8ではなく、基準がmu = 1/18 \quad >> (1em, nbsp)の整数倍 >> になっていて、例えば物理・天文の論文では、通常の単位の前・単位の間(m s^-2と >> か)は4mu (4/18 em)を >> 入れ、主にUS-ASCII以外の一部の単位のÅとかM_◉ (◉は下付き、太陽質量)とかの前 >> は3mu、演算子の前後 >> はnbsp (18mu)にするというような運用になっていました。 >> cf. https://www.overleaf.com/learn/latex/Spacing_in_math_mode >> cf. http://www.ioa.s.u-tokyo.ac.jp/~sofue/pasj/PASJ% >> 20author_guidelines_201703.pdf >> ということを思うと、1/18が単位になる文化的な長年の背景とかもあるでしょう >> から、適切な大きさの >> 定義というものをそのまま援用してくるというのは、そこまで有用な方向性でもな >> いのではないかと思っ >> たりもするところです。。 >> <OpenPGP_0x72397AFC0905265D.asc> ―――――――――――――――――― 小林 敏(toshi) 2020年10月20日 e-mail: binn@k.email.ne.jp ――――――――――――――――――
Attachments
- application/pdf attachment: ________________2.pdf
Received on Tuesday, 20 October 2020 00:06:39 UTC