Re: 文字クラスの国際化: Appendix B 文字間の空き量の表より

（私が間違えて JLReq admin の方に出していたので、JLReq TF 日本語の方に移します）

Nat さんありがとうございます。

> As far as using spaces for Latin-J, I have a concern about using spaces as the way to separate scripts since the space glyph width is not controllable by the user and is so uneven font by font, when clearly the practice in Japanese publishing is to strictly control the 和欧間隔 and allow it to expand or contract according to different rules than those which govern English space width adjustment during justification. The space character U+0020 is another case of Unicode unification that is biting us, I think, since different scripts need different rules for the width adjustments for it.

漠然と、U+20 を入れることにして、U+20 の幅をコントロールすれば良いのでは、と考えていました。この方法は問題点があるでしょうか？　国際化環境で U+20 は和文でないフォントから出てくる可能性が高いでしょうけれど、それのコントロールって難しいのかな。そうかも。

> 結局日本語じゃない文字に対するルールは無視して、日本のルールを使ってしまう。日本のルールはないときは、その言語のルールはいつ使うかになります。Justificationの余ったスペースを使ってどう調整するかは、順番を付けて日本語をかるべく美しく、あるいは、他言語を標準の文字組み（無調整の組み）にして、日本語をルールに沿って調整する。
>  
> The rules in JIS covering Romaji spacing override the rules for English--observe how Latin is spread out using mojikumi rules when force-justifying, but only the spaces would expand if using English-only rules. This is the difference in using the Japanese composer (favoring JIS rules) over using a Latin-centric or Latin-first composer.

InDesign のような日本語専用エンジンならそれで良いのですが、どんな言語でも現れる html のエンジンや、国際化されたエンジンはどのように動くべきでしょう？　確かに優先順位の問題はむずしくなりますね。一行のテキストをスクリプトの run に分けたとして、各々のスクリプトにどのくらいの割合を割り振るか、それとも100%を特定のスクリプトに割り振るのか、とか。おそらく ICU はその辺りをうまくしているんでしょう。

木田

> 2021/03/24 3:08、Nat McCully <nmccully@adobe.com>のメール:
> 
> 
> ナットです。
>  
> 空白を入れると、空白の幅もコントロールする必要がありますので、文字として入れるメリットは幅以外にないといけないと思います。韓国組版では、空白文字を使って単語区切りとして入れていますが、問題はフォントのデザインによって幅が合わない場合が多くて、なとかのフィーチャーでコントロールしたいと文字組みする人が言っています。ハングル・ハングルの幅、欧文・ハングルの幅、数字・ハングルの幅、それぞれ違う幅ですので手動でカーニングしているそうです。ジャスティファイで幅の調整もそれぞれ違う、とかも。
> 和文では、欧文や日本語じゃない文字に関しては、私は日本語が周りにあれば、その行の文字組み調整は日本語のルールを守って調整すべきだと思います。欧文の調整方法（justification settings内の字形調整、スペース調整、文字間調整）はあるのですが、タイミング的には同時に和文空き量調整もする場合、欧文間のアキ量設定を先にあてて、JIS風にJustifyした方がわかりやすい、というか、日本語的というか。結局日本語じゃない文字に対するルールは無視して、日本のルールを使ってしまう。日本のルールはないときは、その言語のルールはいつ使うかになります。Justificationの余ったスペースを使ってどう調整するかは、順番を付けて日本語をかるべく美しく、あるいは、他言語を標準の文字組み（無調整の組み）にして、日本語をルールに沿って調整する。
>  
> The rules in JIS covering Romaji spacing override the rules for English--observe how Latin is spread out using mojikumi rules when force-justifying, but only the spaces would expand if using English-only rules. This is the difference in using the Japanese composer (favoring JIS rules) over using a Latin-centric or Latin-first composer.
>  
> As far as using spaces for Latin-J, I have a concern about using spaces as the way to separate scripts since the space glyph width is not controllable by the user and is so uneven font by font, when clearly the practice in Japanese publishing is to strictly control the 和欧間隔 and allow it to expand or contract according to different rules than those which govern English space width adjustment during justification. The space character U+0020 is another case of Unicode unification that is biting us, I think, since different scripts need different rules for the width adjustments for it.
>  
> I think that grouping classes together to match common practice is a good direction for simplification of the rules. Most of the adjustment is the same, and is about how to expand the space between when force-justifying (e.g. 最小、最適が0％、最大が１００％). However, if the expansion amount, or the expansion timing (優先順位) is different, you must separate the classes.
>  
> --Nat
>  
> From: 木田泰夫 <kida@mac.com>
> Date: Tuesday, March 23, 2021 at 2:16 AM
> To: Kobayashi Toshi <binn@k.email.ne.jp>
> Cc: JLReq TF <public-jlreq-admin@w3.org>
> Subject: Re: 文字クラスの国際化: Appendix B 文字間の空き量の表より
> 
> 敏先生、
>  
> ありがとうございます。
>  
> 非漢字から“漢字的なもの”と“そうでないもの”とを分ける必要はありますか．
> 一括して扱ってもよいように思います．
>  
> そう思います。
>  
> ただ、Unicode は一筋縄では行かないようで、"々” の例のように、仮名や漢字の仲間として扱うべきであろう文字が、Unicode では記号として入っていることがあります。これらが少々紛らわしいのです。そのような cl-19 文字を下に抜き出しました。これらはどうでしょう？
>  
> ”〓” は仮名漢字一文字と交換してレイアウトが崩れない方が良さそうで、そうすると仮名漢字と同じ扱いが良いかもしれませんね。
> ·         U+3003 〃 DITTO MARK
> ·         U+3006 〆 IDEOGRAPHIC CLOSING MARK
> ·         U+3007 〇 IDEOGRAPHIC NUMBER ZERO
> ·         U+3013 〓 GETA MARK
> ·         U+303C 〼 MASU MARK
> ·         U+303D 〽 PART ALTERNATION MARK
>  
> これらに加え、漢字文化から派生した or 影響を受けた全角の文字をどうするかの判断が必要です。が、これらは日本語組版にとって重要なケースではない、かつこれらの言語の組版規則を良く知っているわけではないので、空けるべきことがはっきりしない限り、日本語組版としては何もしない = ベタ、が一番安全でしょうかね。
>  
> 下のリストが仮名や漢字以外で Unicode で全角と定義されている文字（Letter）です：
> ·         注音符号（ボポモフォ https://ja.wikipedia.org/wiki/注音符号）

> ·         ハングル（https://ja.wikipedia.org/wiki/ハングル）

> ·         契丹文字（https://ja.wikipedia.org/wiki/契丹文字）

> ·         女書（https://ja.wikipedia.org/wiki/女書）

> ·         西夏文字（https://ja.wikipedia.org/wiki/西夏文字）

> ·         イ文字（ロロ文字 https://ja.wikipedia.org/wiki/彝文字）

> この中で現代の使用実績の一番多いであろうハングルは単語間をスペースで区切りますし、HLReq 3. にはっきりは書いていないのですが、空白文字のない場合のラテン文字との間はベタのように見えます（おそらくそれが当たり前すぎて何も書いていないのでしょう）。
>  
>  
> これと関連し，ラテン文字も文字と記号と分けるだけでいいのではないかな．
>  
> それが単純で良さそうですね。空いているのをベタにするのは大変ですが、空いていないのを空けたければ空白を入れれば良いのですから。
>  
> Latin スクリプト以外の文字、例えばヘブライ、ギリシャ、キリル、アラブ、タイ、デヴァナガリなどはどうすべきでしょう？　これらも何もしない、ですかね。Nat かな?
>  
>  
> 反対意見があちこちから飛んできそうですが、:)  漢字とラテン文字との間も空けない選択も私は大ありだと思っています。空けたければ空白文字を入れれば良いのですから。現実に、いま毎日生み出されるテキストの殆どはこのメールのように手で欲しい場所に空白を入れているわけです。
>  
> 自動で空けるのを止めればここでやっている、漢字か、ラテン文字か、それ以外か、なんて区分けが全く必要なくなります。空けたければ空白を入れる。どうでしょう？　What do you think, Nat?
>  
> 木田
>  
> これと関連し，ラテン文字も文字と記号と分けるだけでいいのではないかな．
> 
> 実務で例があるのは，和欧文を四分アキにした場合，ちょっと困るなと思う例は，
> 和文と括弧類が並ぶ，ピリオドの後ろに和文が配置される場合かな．括弧の場合
> はベタでいいし，ピリオドの場合もベタでいいように思います．
> 
> アラビア数字と和文とのアキ
> 
> 活字組版で採用されていたのは，木田さんのいう違和感があるという3番目の方
> 式です．
> 
> ラテン文字と同様に設計されているアラビア数字と和文をベタ組にすると窮屈な
> 印象を与えるからです．そこで，アラビア数字の前後も，ラテン文字と合わせて
> 四分アキにする方法が採用されていました．
> 
> 2番目は，数字の前だけ空ける方法は，理屈で考えるといいように思いますが，
> この方式は，私の経験では違和感があります．私の場合は，目が訓練されている
> ので，少しのアキも目に入り，そこだけが何か特別な意味を示しているのかなと
> 一瞬思うからです．
> 
> 以前にお送りした“和欧混植組版例20_10_2.pdf”に，アラビア数字と和文との
> アキをいろいろと変化させた組版例を掲げているので，参照してみてください．
> 
> 書体にもよりますが，活字組版では，アラビア数字の字幅は一般に二分でしたの
> で．数字の前後をベタ組にすると“例1.6”のような印象になります．この例の
> ように数字の前後は窮屈なので，それをなんとかしようと考えたのがアラビア数
> 字の前後を四分アキにする方法です．
> 
> ただし，四分アキは，書体によってはアキ過ぎになるかもしれないので，少し狭
> くした方がよいかもじれません．“和欧混植組版例20_10_2.pdf”では六分アキ
> や八分アキの例も掲げています．
> 
> 上記，PDF，必要なら再送いたします．
> 
> 参考まで
> 
> 最近のビジネス文書では，ワラビア数字の場合，1桁は全角文字，2桁以上は半角
> またはプロポーショナルという使い方が推奨されていますが，これは，写真植字
> の作業性を考えた，あるいはワープロの機能が不十分な時代の便宜的な方法であ
> る，と私は，悪しき伝統だと思っています．（私は推奨しないし，経験のある出
> 版社の出版物では採用されていません．）
> 
> なお，文化審議会で横組の句読点の見直しを行っていますが，アラビア数字の使
> い方は，1桁は全角文字，2桁以上は半角またはプロポーショナルという使い方を
> 推奨する案が出ているようですが，どうなんでしょうかね．
> 
>  木田泰夫 さんwrote
> 
> 
> cl-19 と 27 についてまとめてみました。
> 
> cl-19 の再分類
> 英字との間にアキの欲しい「漢字的なもの」とそうでないもの。
> 
> 
> ですから，見た目のバランスが問題ですから，アキは四分でなくてもよいので
> （活字では，材料の関係で，四分が選ばれたのです），活字組版では，四分アキ
> にしないで，二分アキにした例もありまし”た．また，ベタ組にした例もけっこう
> ありましたし，それでも読めるという意味では読めました．ただ，“体裁よくな
> いな”と言われる恐れはありますが，
> 
> このアキはフォントの設計もよるでしょう．最近の印刷物を見ていると，四分よ
> り狭い組版をよく見かけますし，ベタ組でも，文字の並びによっては問題ない
> ケースもありますが，逆に文字の組み合わせで，ベタ組だと，えらく詰まった
> ケースもあり，悩ましい問題です．
> 
> 一つの考え方として，ある限られた欧文，それと漢字と仮名だけの字間を空ける
> 処理ができるようにして，あとは“知らん”（つまりベタ組）といってもよいか
> もしれない．
> 
> 確かに、記号ではない発音できる文字＋もしあれば少数の追加文字、についてはア
> キを定義して、そうでない場合には放っておく方が、少なくとも理解・管理がしや
> すいように思います。
> 
> アキを開ける対象として、漢字（Ideograph）と仮名は当然として、他に必要な文字
> はあるでしょうかね。韃靼文字など、中国の漢字の派生的な文字である and/or 全
> 角である and/or 単語間に空白がない文字、これは仮名もそうですね、は入れるの
> が適当に思えます。きちんとリストできるか見てみます。
> 
> 現在 cl-19 に入っている全ての約物、記号は cl-19 から除外して良いでしょう
> か？
> 
> cl-19 に含まれる非漢字のうち、英字との間にアキが欲しい「漢字的なもの」の候補
> を拾い出してみました。
> 
> cl-19 のうち下のものは記号の分類ではありますがほぼ漢字のように見えるもの。
> これらはどうでしょう？
> U+3003 〃 DITTO MARK
> U+3006 〆 IDEOGRAPHIC CLOSING MARK
> U+3007 〇 IDEOGRAPHIC NUMBER ZERO
> U+3013 〓 GETA MARK
> U+303C 〼 MASU MARK
> U+303D 〽 PART ALTERNATION MARK
> 
> 
> 下のものは前置省略記号的であって、前置省略記号はハイフン類と同じ字間の挙動を
> しますので、同じ、つまり約物を全角としてベタ、で良いですかね？
> U+337B ㍻ SQUARE ERA NAME HEISEI
> U+337C ㍼ SQUARE ERA NAME SYOUWA
> U+337D ㍽ SQUARE ERA NAME TAISYOU
> U+337E ㍾ SQUARE ERA NAME MEIZI
> 
> 下のものは元々カタカナですが、顔つきのもの共々前置省略記号的、つまりベタです
> かね
> U+3012 〒 POSTAL MARK 郵便記号
> U+3020 〠 POSTAL MARK FACE 郵便マーク
> 
> 丸付き数字、漢字、片仮名はベタでしょうか。でないと箇条書きに使いにくいです。
> 
> 下のものは漢字を含みますが、括弧を持っていますのでベタっぽいですね
> U+3231 ㈱ PARENTHESIZED IDEOGRAPH STOCK
> U+3232 ㈲ PARENTHESIZED IDEOGRAPH HAVE
> U+3239 ㈹ PARENTHESIZED IDEOGRAPH REPRESENT
> これらをどうするかは、下のような現在 cl-19 / JIS X 0213 以外の漢字囲み文字た
> ちをどうするべきか、また漢字でない囲み文字たちをどうするべきかにも関係してき
> ます：
> ㈠㈡㈢㈣㈤㈥㈦㈧㈨㈩㈪㈫㈬㈭㈮㈯㈰㈱㈲㈳㈴㈵㈶㈷㈸㈹㈺㈻㈼㈽㈾㈿㉀㉁㉂㉃㉄㉅
> ㉆㉇㊀㊁㊂㊃㊄㊅㊆㊇㊈㊉㊊㊋㊌㊍㊎㊏㊐㊑㊒㊓㊔㊕㊖㊗㊘㊙㊚㊛㊜㊝㊞㊟㊠㊡㊢㊣
> ㊤㊥㊦㊧㊨㊩㊪㊫㊬㊭㊮㊯㊰
> 
> 全角の英字や数字、これらはプロポーショナルの英字や数字と使うべきではないので
> しょうけれど、もし使われたらベタで良いでしょうかね。
> 
> 以上で cl-19 を、英字との間にアキが必要な「漢字的なもの」と、ベタに組む「漢字
> 的でないもの」に分けることができます。
> 
> 
> cl-27 の再分類
> このように cl-19 を分けると、同様の問題が cl-27 にも生じます。cl-27 には単語
> を構成する字（Unicode で言う Letter）以外に、記号や約物が含まれます。cl-19 の
> 多くの記号や約物が cl-27 にも重複して所属していますので、ベタのクラスを作るな
> ら、これらおよも cl-27 からベタクラスに移動が合理的に思えます。ただし英字と同
> じように漢字との間を空けるのが適当な文字があるかもしれません。
> 
> cl-27 に含まれるものを General Category の大分類で見てゆきますと、
> 
> - C (Other) のソフトハイフン：これはアキ不要ですね
> - Z (Separator) のノーブレークスペース：これもアキは不要ですね
> - S (Symbol) ：
> - Sm (Math Symbol)：これは？ 仮名漢字の隣にプロポーショナルの演算記号、あ
> まり重要なケースには思えませんが決める必要がありますね
> - Sc (Currency Symbol)：通貨記号
> - Sk (Modifier Symbol)：これはベースの英字に付ける文字なので、単独で現れな
> いはずのもの
> - So (Symbol Other)：種々雑多ないわゆる記号。幾何学的な形の記号、絵文字的な
> もの、矢印、丸付きアルファベット、などなど。これらもアキは不要に思います
> - P (Punctuation) 種々の約物
> - N (Number) 種々の数字。数字、丸付き数字、分数。このうち普通の数字は漢字と
> の間にアキを要求するとして（下記メモ参照）、丸付き数字は不要、分数は？
> - L (Letter) アルファベットの類。これは明らかに漢字との間にアキを要求します
> ね
> 
> 数字と漢字の間のアキについて
> 数字と漢字の間にアキを入れるべきか、私は悩ましいと思います。例えば：
> 
> 　今日は3月22日です
> 
> 　今日は 3月 22日です
> 
> 　今日は 3 月 22 日です
> 
> 最初のはOK。次のは数字が強調される感じ。最後のは違和感があります。何か空欄付
> きのフォームに数字を書き入れたような後付け感。ここで使っているのは欧文空白で
> 私の環境では漢字に比べて約三分の大きさですが、これをワープロなどで四分になる
> ように調節しても印象は同じです。「料金は 10,500 円」など桁数が大きくなると後
> ろ側が空いていても違和感が少なくなりますが、やはり後ろの単位にくっついている
> 方が自然に思えます。
> 
> ここにはおられませんが、数字に関して潤平さんも似たようなことを言っておられま
> した。
> 
> 木田
> 
>