Re: 字間のため（だけ）のクラス、簡便化案

Nat さんありがとう。取り急ぎかいつまんで：

> Eliminate Priority?
Japanese mojikumi distinct とありますが、例えばどのような benefit が現実にあるか、サンプルがあれば理解しやすいと思います

敏先生の提案されている簡便化法では詰める方向は省略されて、空ける方向だけになっています。空ける方向の中のプライオリティについてはどう？　（もちろん、精緻な組版では、実装時間や実行時間のかかる手法を駆使するのだと思いますし、それは保ってゆく必要があると思います）

> where much of the Unicode space is “Unknown” class, and therefore gets no aki added ever

具体的にどのような問題がありますか？　田嶋さんが、スペースがあってほしくない方向の具体例を挙げてくれました（多謝）。そのような具体例はとても役に立ちます。

> the user can control what happens to the J next to any unknown or non-J,
この点で、アキを空けないのが一番簡単だと思うんですよ。空けたければスペースを入れれば良いのですから。自動的に空いてしまうと、詰めたくても大抵の場合どうしようもありません。例えば私が今書いているメールには、和欧間 setting がありません。

木田

> 2021/04/06 9:00、Nat McCully <nmccully@adobe.com>のメール:
> 
> 皆さま
>  
> ナットです。英語ですみません...
>  
> I wanted to note down some thoughts quickly as they relate to this effort:
>  
> Broadly speaking, there are several categories at play in a typical mojikumi implementation:
>  
> Character class, by where the spacing goes
> Open Parentheses: Adding aki on left
> Closing Parentheses: Adding Aki on right
> Middle Dot: Adding aki on both sides equally
> Roman (non-全角 and non-CJK), can be all other languages: Doesn’t add any aki except during justification (on right)
> 全角 and CJK: Adding aki on left only for justification; Adding aki on right otherwise
>  
> Spacing, by range: (this is like the “glue” of Eric’s proposal)
> 0%,0%,0%: e.g. JIS_OtherJ to J Commas
> 0%,0%,100%: e.g. JIS_OtherJ to JIS_OtherJ
> 0%,50%,50%: e.g. Close Paren to Roman
> 0%,50%,150%: e.g. Close Paren to JIS_OtherJ
> 50%,50%,50%: e.g. Line Edge to Open Paren
> 0%,25%,25%: e.g. Middle Dot to ? or !
> 0%,25%,125%: e.g. Middle Dot to JIS_OtherJ
> 12.5%,25%,50%: e.g. JIS_OtherJ to Roman
> 100%,100%,100%: e.g. Paragraph Top to JIS_OtherJ
>  
> Priority, as an ordering of the combination of 1) and 2). There are 11 priorities, 0 meaning なし and 1-10. なし goes last.
>  
> Eliminate Priority?
> I do not think we can throw away Priority – that is what make Japanese mojikumi distinct from simply averaging out the space across every character. I think compression priority is important because at least most of the time the compression of 句点のアキ should be done last. I believe that the other compression priority rules were perhaps imagined as a way to systematize conventional practice by hand-kerning experts, and there is therefore some amount of flexibility possible in simplifying things. However eliminating it altogether is going too far and will result in awkward-looking composition.
>  
> Only include Latin alphabet in “non-J”?
> I believe this will result in the problems Illustrator currently has, where much of the Unicode space is “Unknown” class, and therefore gets no aki added ever. I think that we should characterize the Japanese ranges as those which get mojikumi aki, and everything else be treated as Roman (meaning it gets no aki but J will get aki next to it according to JIS rules for和欧間). This is what InDesign tries to do, and the user can control what happens to the J next to any unknown or non-J, using this 和欧間 setting.
>  
> Hope this helps our discussion...
>  
> --Nat
>  
> From: 木田泰夫 <kida@mac.com>
> Date: Sunday, April 4, 2021 at 5:18 PM
> To: 田嶋淳 <junetaj@gmail.com>
> Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
> Subject: Re: 字間のため（だけ）のクラス、簡便化案
> 
> 田嶋さん、
>  
> 確かに。そのためには E （その他の外国語）をラテンアルファベットだけに限定するのが安全ですね。
>  
> 基本的なアルファベット Ａ–Ｚ 以外のラテンアルファベット、例えばアクセント文字がついたものなどは全角にして逃げる手段はありません。これらは OK？
>  
> 木田
> 
> 
> 2021/04/05 8:59、田嶋淳 <junetaj@gmail.com>のメール:
> 
> 木田さま
> みなさま
>  
> 「ギリシャ文字と漢字が隣あった時」ですが、ギリシャ文字の「α」や「β」などは和文の中に1文字だけ入るケースが結構あり、その場合に自動でスペースが入ってしまうとちょっと困るのではないかなと思います。通常のアルファベットであれば「全角文字を使う」という逃げ方がありますが、ギリシャ文字の場合には全角文字はないからです。ですのでベタになる挙動が望ましく、必要なら手動でスペースを入れるのがよいのかなと。
> 
> 
> 2021/04/04 17:00、木田泰夫 <kida@mac.com <mailto:kida@mac.com>>のメール:
>  
> JLReq TF の皆さま、
>  
> ギリギリになりましたが、前回 3/9 のミーティングで私と下農さんとの宿題になっていた字間のためのクラスの報告・提案です。
>  
> 下農さんが Unicode 拡張に苦労しておられたので、まずUnicode への拡張を考える前に、敏先生からのアドバイスを得つつ、字間のためだけを考えた場合に、現状のクラスをどのように簡便化できるかという視点でまとめてみました。クラスを統合できれば Unicode への拡張がやりやすくなります。
>  
>  
> 前提
> 1) 字間のみを考える。行の折り返しは異なるロジックで実装されていることが多く、両方の挙動をまとめたクラスを作ってもクラス数が増えるだけであまり嬉しくなさそう、という理由です。また行の調整処理に必要なクラスを字間とまとめておいた方が使い良いのかどうかわかりませんが（石井さん、村上さん？）、まずはバラバラに考えてみようと思います。
> 2) いくつかの JLReq クラスは考慮外：従前の議論により、cl-12/13 前置／後置省略記号を削除。コンテキストを表す cl-20-30 は考慮外。
>  
>  
> 簡便化字間クラスの構成
> 簡便化の結果、七つにまとめることができました。それぞれ空き要求の性質でクラスを説明することができます。
>  
> A: 前に空間を必要とする約物：始め括弧類 cl-01
> B: 後ろに空間を必要とする約物：終わり括弧類と句読点 cl-02, 06, 07
> C: 両側に空間を必要とする約物：中点類 cl-05
> D: そのものが空間な約物：和字間隔 cl-14
> E: アルファベットとの間に空間を必要とする文字、漢字類：仮名と漢字 cl-9,10,11,15,16、および cl-19 の漢字
> F: 漢字類との間に空間を必要とする外国語文字：cl-27 のうちLetter であるもの
> G: どの文字ともベタ：その他全ての文字。cl-03, 04, 08, 17, 18, 26、cl-19 の非漢字、cl-27 の非ラテンアルファベット
>  
>  
> JLReq からの変更点
> 以下が JLReq からの変更点です。小林先生、個々の是非についてフィードバックありがとうございます。JLReq の記述に沿って和文約物を半角と考えた場合の空き量で変更点を表しています。
> ・句読点｜中点：3/4 アキ→終わり括弧に合わせて四分アキ
> ・句読点｜和字間隔：二分アキ→終わり括弧に合わせてベタ
> ・区切り約物｜欧文：四分空き→G に含めるためベタ
> ・cl-19：漢字と非漢字を分離し、漢字のみがアルファベットと空間を作り D、非漢字はどの文字ともベタで G
> ・cl-27：ラテンアルファベットと記号を分離。ラテンアルファベットは漢字と空間を作るので F、記号はどの文字ともベタで G
>  
>  
> 議論点
> おそらく、一番影響のある変更は最後の二つ、cl-19/27 からの記号の分離でしょう。記号はどの和欧文文字ともベタとなります。ベタになっては困る文字はあるでしょうか。また、漢数字〇やゲタ〓など漢字と交換して使われる記号の処遇も議論の余地があるかもしれません。Unicode への拡張を考えるとこの手の例外がない方がありがたいです。
>  
> （ところで、記号約物の対語の日本語は何ですかね？ Unicode では Letter と表されています）
>  
>  
> 簡便化字間クラスの空き量数値
> 添付の表
>  
>  
> Unicode への拡張
> 今日後ほどこの簡便化をベースとした Unicode への拡張の可能性について考えてみます。この簡便化案でも垣間見られますが、決めの難しいポイントは「漢字類との間に空きを必要とする外国語文字」の範囲の定義でしょう。アラビア文字やデヴァナガリやギリシャ文字と漢字が隣あった時に空間は必要でしょうか？ ただし決めの難しさの割には重要性は低いように思われます。頻度が低く、また空きが必要だと思ったら U+0020 を入れれば良いから。
>  
> 木田
>  
> <PastedGraphic-2.pdf>
>  
>  
> 文字クラスの国際化
> ほとんど時間がなく、1) 今まで議論してきた字間クラスをまとめたデータを作り、Unicode のプロパティに落とし込むことができるか調査する（木田、下農） 2) 次回のミーティングでは、字間以外にどのような文字クラスが必要か、どのような機能が文字による挙動の違いの影響を受けるかをレビューすること、を決めた。