- From: Kobayashi Toshi <binn@k.email.ne.jp>
- Date: Mon, 19 Oct 2020 13:48:53 +0900
- To: 木田泰夫 <kida@mac.com>
- Cc: W3C JLReq TF <public-i18n-japanese@w3.org>
木田泰夫 様 小林 敏 です． 日本語組版で欧文組版についてふれる点については，以下の事情，これは私の推 測であり，根拠のある話ではありませんが，日本語組版のルールを考えてきたの は，活字組版の現場です，そして，それは欧文組版に学びながら考えてきたので はないか，ということです． ルールを活字組版の現場で考えてきた方々，私もそうした人から学んできたので すが，代表的な方は，例えば以下の方々です． 水沼辰夫，高島義雄，加藤美方，今井直一さんなどです． これらの方は，欧文組版にとても詳しい方々で，日本語組版は，欧文組版に学び ながら考えてきた可能性が高いとにらんでいるのです．こうした傾向が，日本語 組版の中に欧文的なルールが多く説明されてきたのではとも推測しているのです． 次に，三段階程度に分けて整理してみるという提案 うーん，考える意味はとても高いと思いますが，どうやって考えていくか，とて もむつかしい，なぜなら，その判断の基準はどこにあるか？ という点が明確で ないことがあるように思います． 以上です． 木田泰夫 さんwrote >この議論でもう一点。 > >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）を入ればよい．つま >>> り，一般の欧文のルールで解決できる． >>> >>> 以上です． >>> >>>
Received on Monday, 19 October 2020 04:54:30 UTC