Re: JLReq のクラスと Eric の提案クラスとの比較

なかなかいい議論になりそうです！

うちは今、イラレの挙動を吐き出すテストコードを入れていますが、できたら結果をお送りします。のち、インデザインのも。皆さんの議論の結果で色々改善点は生まれてくることでしょう。

大体の問題は、【全角・半角・プロポーショナル】の区別で文字組みクラスやアキ量の計算ができるといいですが、フォントデザインに依存する、SJISフォントからの字形と、欧文用の字形と、同じUnicodeにあるところが一つの問題点です。”Ambiguous Unicode” のU+2xxxがそうです。もう一つの問題はフォントのデザインによって、日本語フォントであっても欧文用のプロポーショナル字形がある場合。これはヒラギノフォントのsmart quoteが全角デザインではなくて欧文用のプロポーショナルにしたことを思い出す。縦書き用の字との区別やフォントによって切り替えの’vert’があるかないか、がもう一つですね。

I also feel as Shimono-san mentioned, how far we must take this discussion to include all of Unicode or all languages. In the JLReq, if we are able to define clearly how all these characters are composed for Japanese layout, that may be enough. Japanese layout is a special beast, when it comes to all these U+2xxx or math symbols, or anything that in some fonts are 全角 glyphs (and therefore specifically used in a Japanese context. I worry about which class we classify these, as if we classify them as Japanese, they get no aki spacing added next to Japanese, but they will possibly get aki spacing added next to non-Japanese characters. So, we must have a mechanism to switch contexts so the correct 和欧間（和－非和？間）is added by the layout engine, and that aki is adjusted correctly along with all other aki on the line.

--Nat

From: 木田泰夫 <kida@me.com>
Date: Monday, November 30, 2020 at 6:25 AM
To: public-i18n-japanese@w3.org <public-i18n-japanese@w3.org>
Subject: Re: JLReq のクラスと Eric の提案クラスとの比較
いやあ、私が旅に出ていた（嘘）間に盛り上げていただいていますね。ありがとうございます！


明日のミーティングですが、Eric の提案との差異を議論する前に、JLReq 中で複数のクラスに含まれる文字たちをちゃんと見るのはどうでしょう？

一番重要なのは、どのクラスに属するかの判断、コンテキストを自動的に見分けられるのかどうか。そうでないとプレーンテキストではどちらかに寄せて、明示的なマークアップがあった時にだけ、もう一つ、といった処理が必要になります。そうするのが適当なケースもありそうです。

それを、下農さんが触れられたのですが、JLReq で扱う必要のないクラスはないか（e.g. 演算記号や単位記号）、を頭の片隅に起きながら考えるのはどうでしょう？

もーし時間があれば、cl-27 を、欧文ではなくて日本語以外の全ての文字、というクラスにできるか。例えば Arabic や Devanagari を入れる。では中国語にしか現れない漢字やその他の全角の文字（韓国語？西夏文字？）はどうするか、も考えてみて良いかと思います。

この辺りがキチンとしたら、Eric の提案に応える準備ができるのかなと。



小林さん：
・CITPCで村田さんが進めている、約物フォントの縦横の振る舞いの違いデータを付け加えました。調査結果の正立と横転のフォント数です。
・JIS X 0213の改正原案委員会やJSC2で議論になったり、JWTやJLreqで話題に上った記号類について、思いつくままに、メモを付加しました。

CITPCデータのついている文字は 8件、小林さんのメモは1件、で正しいですか？

小林さん：
・JIS X 0208とJIS X 0213とで、UCSとの対応付けの考え方に、根っこのところで大きな違いがあって、それが、さまざまな混乱の遠因の一つになっているのではないか。
面白いですね。具体例はありますか？

小林さん：
・活版時代に、罫線（表罫や裏罫）を、（倍角ダーシなどの代わりに）本文中に埋め込むようなことをしていて（→敏さん、本当？）、JIS X0208のシフトJISエンコーディングの時代に、似たようなことがあったのではないか。イコールを二重ハイフンの代わりに使ったり、WaveDashを変形長音記号として流用したり。
その点で、田嶋さんの「不本意ながら倍角ダーシの代わりに罫線素片を使っている」という発言は、大きな示唆を含むのではないか。
うぐぐ。

敏先生：
WaveDashの変形長音記号はとしての流用は，もう認めないといけないかもしれない．ということで，用法は，どこまで認めるか，簡単ではありません．定着しているかどうかの判断は難しいが，定着していない用法は，考えたくない，といいたいな，とも思っています。
そうですよねえ。

小林さん：
・JIS X 0213で追加された約物（二重ハイフンや歌記号など）について、元来原案開発委員会が想定していた使い方と、現状での使われ方／使われない方を比較してみると、何か見えてくるかも知れない。
想定していた使い方、というのはどこかにデータが残ってます？　それ貴重。

田嶋さん：
DTP組版の現場的には「アルファベットの組み合わせで表現した方が安全で正しい」とされ、おそらく今でもその形に沿ってでテキストの修正が行われています。アクセシビリティや検索を考えればきちんとUnicodeのコードポイントのローマ数字を使うべきですが、一度常識化してしまい、「なぜそうしているのか」を説明できる人がいなくなってルールだけが残るとそう簡単には修正されません。
欧文では合字はありませんので、アルファベットの組み合わせが正しい方法です。日本でもそれで良いのではないかと…

せきさん：
U+00B7 MIDDLE DOT [·]
 中国語では、西洋人の姓と名などの区切りに使います。原則として全角字形だけを使いますが、半角字形を使うこともあります。[1]

国際化システムでフォールバックの設計がうまくないと欧文フォントから出てきて全角では無くなったりしそうですね。

敏先生：
U+22C5 DOT OPERATOR [⋅]
掛け算の記号に使います。cl-27またはcl-18？
これは乗算の記号のようですが，乗算の記号としては，U+00B7の方が望ましいんでないかな？

数学では掛け算記号としてドットも使うんですよ。またベクトルの乗算の一つ、内積はこの記号を使います。もう一つの乗算、外積は × を使います。

下農さん：
どう反応しようかとずっとうなっていたのですが、欧文コンテキストでの文字用にJLreqで文字クラスや分類を立てる、というのはちょっと違和感があったりします。。もちろん、改行・文字間の扱いのための仮想クラス的なのは必要かとは思いますが、JLreqの文脈として(JISでなくUnicodeの文字セットに拡張したときに)文字の分類として必須なのかな？もしくは現実的なのかな？と。
# 現実問題として(CJKを除き?)和欧混植が一番多いでしょうけれど、アジアの諸言語とかアラビア語とかも混植になることはあると思うと、Unicodeへの拡張という文脈を思うとそれぞれの仮想クラスを立てるのか？とか、、。
…
　コンテキスト依存性についての議論は必要かとは思うのですが、"欧文用文字"というのを今の形で残すのもそれでいいのかな？というのもちょっと気になっているところです。

大きな方向として、そう思います。単位記号とか数式とか、JLReq の範囲外に追い出してしまう、、、と、JLReq を組版の教科書的に使っている人は困るでしょうけれど。

とはいえ、それが「欧文」なのか、JLReq 独特の使い方であって JLReq に残すべきなのか、ざばっと削除する前に、ちゃんと見るべきかなとも思っています。

木田