非「普通の全角」の文字クラスの確認 (was: Re: 和文と欧文の約物の連続)

　shimonoです

# ずれてきたのでタイトルなおしました

On 2022/09/23 10:09, Yasuo Kida wrote:
>>> 下に記録しました。
>>> https://github.com/w3c/jlreq-d/issues/24 <https://github.com/w3c/jlreq-d/issues/24>
>>> またこれに対して Unicode 拡張字間クラスのドキュメントのレビューを行い、必要ならアップデートします
>>> https://github.com/w3c/jlreq/issues/340 <https://github.com/w3c/jlreq/issues/340>
>>
>>  Unicodeベースの文字クラスを見たところ、基本的にEAW=W/FでフィルターしたうえでのGeneral
>> Categoryなどで文字クラスを定義していました。e.g.
>>> 前に空間を必要とする約物：始め括弧類の拡張
>>> 普通の全角かつ General Category = Ps (Open_Punctuation: an opening punctuation mark (of a pair))
>>
>>  ということで、EAW != W/Fのものと隣接した場合の条件を追加すると大体は解決できそうな気は
>> しました。
> 
> ありがとうございます！　それで行きましょう。
> 
>> 問題としてはU+0F3A (TIBETAN MARK GUG RTAGS GYON, Open_Punctuation)とかの今の議
>> 論で想定外のものが多数紛れ込んでくる、ということがあるかもしれませんが、、非常にレアケー
>> スでしょうし、。
>> 　とはいえ、中にspacingを含んでいない1emでない狭い文字の場合はいいとして、1emに近い文字
>> の場合は何かしら検討しないといけない、、のかな？とも思うところではありますが。。
> 
> シンプルさを保ちましょう。プライオリティも低いですし。
> 
> と言いつつチベット語開き括弧の実際の使用例を探してみたのですが、10分間では見つけられませんでした。Wikipedia <https://bo.wikipedia.org/wiki/%E0%BD%82%E0%BD%A6%E0%BD%A2%E0%BC%8B%E0%BD%96%E0%BE%B1%E0%BD%B4%E0%BD%84%E0%BC%8B%E0%BD%82%E0%BD%B2%E0%BC%8B%E0%BD%82%E0%BD%93%E0%BD%A6%E0%BC%8B%E0%BD%9A%E0%BD%B4%E0%BD%A3%E0%BC%8D>とかここ <https://bod-rangzen.org>とかここ <https://bodyiglobjong.com>。ということはチベット語の中でも、webでの使用ではとの条件付きですが、この括弧の使用は一般的ではない可能性がありますね。

　これまでに定義した7つの文字クラス、B/A/BA/S/J/L/Oでは
> 「普通の全角」とは、 East Asian Width = W/F（全角）かつ Decomposition Type が vertical や small でない
として、
・B: 前に空間を必要とする約物：始め括弧類の拡張
・A: 後ろに空間を必要とする約物：終わり括弧類と句読点の拡張
・BA: 両側に空間を必要とする約物：中点類の拡張
・S: そのものが空間な約物：和字間隔  （これだけU+3000のみを決め打ち）
については「普通の全角」かつUnicodeのプロパティーで定義し、また
・J: アルファベットとの間に空間を必要とする文字 = 仮名や漢字
について全角かつScriptなどで定義していました。
　B/BAについては混入する文字が発生していましたがこちらは継続議論でした。

　というところで、いまの議論の中で「普通の全角」でない文字との間でspacingを除去するかどうかの規
定を決めようとしていますので、一応Unicodeのプロパティーで文字をリストしてとんでもないものが入っ
てないことを確認しておこう、という話を木田さんとしています。の結果をずらっと以下に一旦並べてお
きます。呼び名は仮にBpなどとしてあります。（プロポーショナルというわけではないけれども全角では
ないという意味で"p"）
　「普通の全角」、の条件に当てはまらないですので、条件を単純に対偶にすると
EAWがWideでもFullwidthでない、またはDecomposition TypeがVerticalである、またはSmallである
となりますが、verticalとsmallの除外は「全角」という定義に関係なくそもそも特殊形態の文字だよね、
という話での除外でしたので、「普通の全角」に当てはまらない文字を抽出する条件も
「非全角」 = EAWがWideでもFullwidthでない、かつDecomposition TypeがVerticalでもSmallでもない
でひとまず抽出しています。（以下の各項目でのリンク先）

　で、リストでspacingが内包されてそうや周りに影響がありそうなどのこれまでの全角約物の前後に来た
場合に全角の中のspacingを取り去るかどうかの議論に対して影響がありそうなものをチェックした、とい
うところです。
　全体的に一つ、ですが、村上さんの指摘の通り、ArabicなどのRTL想定の文字とくっついた場合の開き・
閉じとの関係でのツメアケの規定は、和文文字でのspacingのツメをどうするかというのが表示上での読み
やすさ？キレイさ？を基準としているというのを考えると、別途何か考えないといけないのか！？という
想念は浮かびました・・・


・Bp : 前に空間を必要とする約物の文字クラスの非全角 - Psかつ「非全角」 : 51文字
https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%3AGeneral_Category+%3D+Ps%3A%5D+%26+%5B%5B%3A+East_Asian_Width+%21%3D+W+%3A%5D+%26+%5B%3A+East_Asian_Width+%21%3D+F+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+vertical+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+small+%3A%5D%5D&g=&i=


 特にこれまでの議論で例外を入れないと行けなさそうな文字はなさそうです。

・Ap : 後ろに空間を必要とする約物の文字クラスの非全角 - PeまたはTerminal_Punctuation (Po)かつ「非全角」 : 311文字
https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%5B%3AGeneral_Category+%3D+Pe%3A%5D%5B%3ATerminal_Punctuation%3A%5D%5D+%26+%5B%5B%3A+East_Asian_Width+%21%3D+W+%3A%5D+%26+%5B%3A+East_Asian_Width+%21%3D+F+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+vertical+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+small+%3A%5D%5D&g=&i=


 Peが48文字、Terminal_punctuationが263文字。
　PeはBpのPsと同じく特に問題なさそうです。

　Terminal_Punctuationは"!?"とかに始まり、A/BAの議論と同じくcl-04/05に近いようなものが大量に入
りますが、、というよりはもはや全角の約物の隣に来たときどうするんだ！？というのを論評しずらいも
のばかりで、、Apに入れない方がいいんじゃなかろうか？という気すらしてきました。。

・BAp : 両側に空間を必要とする約物の文字クラスの非全角 - HyphenかつPo または Terminal_Punctuation、の「非全角」 : 264文字
https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=[[[%3AGeneral_Category+%3D+Po%3A]+%26+[%3AHyphen%3A]]+[%3ATerminal_Punctuation%3A]]+%26+[[%3A+East_Asian_Width+!%3D+W+%3A]+%26+[%3A+East_Asian_Width+!%3D+F+%3A]+%26+[%3ADecomposition_Type+!%3D+vertical+%3A]+%26+[%3ADecomposition_Type+!%3D+small+%3A]]&g=&i=

　Terminal_Punctuationを除くと1文字。これはまぁ御党です。
https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%5B%3AGeneral_Category+%3D+Po%3A%5D+%26+%5B%3AHyphen%3A%5D%5D+%26+%5B%5B%3A+East_Asian_Width+%21%3D+W+%3A%5D+%26+%5B%3A+East_Asian_Width+%21%3D+F+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+vertical+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+small+%3A%5D%5D&g=&i=

U+FF65 HALFWIDTH KATAKANA MIDDLE DOT

・Sp : 和字間隔以外の空白の非全角 - Space_separator : 16文字
https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%3Aspace_separator%3A%5D+%26+%5B%5B%3A+East_Asian_Width+%21%3D+W+%3A%5D+%26+%5B%3A+East_Asian_Width+%21%3D+F+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+vertical+%3A%5D+%26+%5B%3ADecomposition_Type+%21%3D+small+%3A%5D%5D&g=&i=


 穏当に、General Punctuation — Spacesみたいな広かったり狭かったりする空白やら、NBSPなどの制御
込みな空白文字なので、和字間隔のようにspacingの処理をせずに何もしない相手にすべきリストかなと
思ったら、
U+1680 OGHAM SPACE MARK
がいました。真ん中に一本線を引っ張って、その線上に点を打ったり線を伸ばしたりとか斜め線を入れた
りとかする文字で、当然ながら空白部分も真ん中の線はあるので空白文字＝点とか線が何もついてない真
ん中の一本線だけ、ということだそうです。

　まぁ、どちらにしてもSpについては処理なしでいいのではないかと思っております。
　敏先生の全角括弧と全角以外の空白はそうそうない、という話では、改行が変換されるU+0020がくっつ
くことはあるかなぁ、とは思いましたが、、そこはまた別なレイヤーの処理で削除されるべき何かですね。


　ということで、プロパティーでひらってみたところでは
・spacingの詰め処理の規定の中にTerminal_Punctuationを取り入れるかどうかは要審議？
・空白は、和字間隔はspacing処理するが、それ以外は処理を入れない
・それ以外について、ケース1-3に適用する非全角の文字クラスは「普通の全角」準拠でいける
なのかなと考えた次第です。