Re: 文字クラスの国際化

木田泰夫　様
みなさま

　小林　敏　です．

資料を十分にみたわけでなく，おもいつき段階なのですが，いっそのこと，ごく
簡単に問題になる事項，最初は必須の処理事項をしぼり，国際化を考慮してクラ
ス分けしてみる．次に，それに新たな目的を追加し（組版レベルが上がるという
ことでもある），どう細分化するのか考えてみるのもよいかもしれない．（いっ
てみれば，細かい状況になっているものを見直すのでなく，最初からやりなおし
てみるということです（場合によってはルールそのものを見直してもよい）．そ
れで，現状と比較して考える．）

最初の段階は，以下，行の調整処理もルビも考えない

文字間のアキ（行頭・行末を含む）で以下
　アキを抱える括弧類と句読点，中点
文字間の分割では，以下だけ考える
　行頭禁止文字
　　　括弧類，句読点，??記号，?書きの仮名（2つのレベルに分ける）
　行末禁止文字
　　　括弧類
　分離禁止　全角タダーシ
　＊波型（〜）をどう扱うか，ここで新たに決めてもよい
　＊ここでは，必須のものだけにする．

なお，行の調整処理は，文字間のアキと分割禁止を組み合わせて考えればよいこ
とでもある．つまり括弧類などアキがある箇所はできるだけ触らない，分割禁止
箇所はできるだ空けない，ということでもあるので．

次のレベルは
　欧文が組み込まれた場合の問題はなにが問題になるか，新たな文字クラスは必
要になるか
　ここでは，プロポーショナルの文字が含まれる問題を考えてもよい．
　仮名などがプロポーショナル，約物がプロポーショナルの場合は？

次は，ルビ（これも原則掛けないというレベルと，掛ける場合もありとに分けら
れる），行の調整処理（アキ処理だけと，詰める処理を組み合わせる段階と分け
られる），その他

その次は，……

今の段階では，ここまで

  木田泰夫　さんwrote

>私もつらつら見ているのですが、全角問題がキモですね。JLReq では（本来の英字以
>外の）文字が全角半角幅であることを期待してあらゆるルールが組み立てられていま
>す。しかるに、現実的にはそうではない。で、この現実にはそうではないという事実
>にどう対処するのか、ということです。
>
>例えば cl-04 区切り約物をとってみると、所属する6つの文字のうち必ず全角なのは
>「全角感嘆符」と「全角疑問符」のみ。残り4つの、「感嘆符二つ」、「疑問符
>二つ」、
>「疑問符感嘆符」、「感嘆符疑問符」は UAX11の規定に従うとプロポーショナルです。
>
>同様な問題が cl-12 前置省略記号、cl-13 後置省略記号にも当てはまります。今まで
>の議論で、これらの文字クラスは削除し、全角のものは漢字 cl-19 と同じ扱い。そう
>でないものは cl-27 という結論になっています。が、「全角のもの」とは一体どの文
>字でしょう？ 例えば「全角NO」は Unicode 的には Ambiguous つまり全角の場合もあ
>るしプロポーショナルの場合もあります。
>
>どちらの例でも、おそらく「日本語」フォントはこれらの文字を全角で実装している
>のでしょうけれど、実際の環境においてこれらの文字に日本語フォントが使われるか
>どうかわかりません。特に国際化システムにおけるシステムフォントで表示した場合、
>これらがプロポーショナルになる可能性は高いでしょう。
>
>問題点は、もし文字がプロポーショナルであったらどのような組版規則が適用される
>のか、という一点に集約されるように思います。
>
>もし全角であろうとプロポーショナルであろうと同じ規則が適用されるなら、ある意
>味安心して現在の JLReq 文字クラスを拡張できます。全角かどうかのプロパティが使
>えないので、拡張の難しさはあるでしょうけれど。
>
>もし文字が全角である場合のみ現在の JLReq の規則が適用されるなら、全角でない場
>合にはどのような規則になるかを考える必要があります。必ず全角であること、とい
>う規則にしたくなりますしそれも可能性の一つでしょうけれど、現実に全角でなかっ
>たら何が起こるべきでしょう？
>
>いずれにせよ国際化された JLReq 文字クラスは文字のみならず、適用されるフォント
>によって異なってくることになります。
>
>
>敏先生、みなさま、乞う色々なご意見。
>
>木田
>
>> 
>> 2021/03/13 10:21、木田泰夫 <kida@me.com>のメール:
>> 
>> 下農さん、
>> 
>> ありがとうございます。この表でわかる下の三種類のケースのうち：
>> 
>> A) CL-List/IDが●かつCL-List/RM?が空白かつUnicode/filterが●のものは問題な
>> い文字
>> B) Unicode/filterのみ●のものはUnicodeの属性で記述した時に追加されてしまう
>> 文字
>> C) CL-List/IDが●かつCL-List/RM?が空白かつUnicode/filterが空白のものは
>> Unicodeの属性で記述した時に消える文字
>> 
>> これらのうち、A は期待通りですね。
>> 
>> 
>> B はその文字クラスに加わってくれて期待通りもしくは加わって問題のない文字と、
>> 問題のある文字とが混じっている。この判定は難しい場合や、判定は簡単だけれど
>> フィルターで除去しにくく、でも影響が少ないからまあいいや、なんてものもある
>> かもしれませんね。例えばヘブライ語ハイフンとか。
>> 
>> 
>> C がおそらく一番問題で、フィルターの工夫が必要、という理解で良いですかね。
>> ただ場合によっては C は JLReq 文字クラスの見直し、もしくは文字が足らないこ
>> とを示唆している場合もあるのかもしれません。例えば、cl-03 ハイフン類（これ
>> は国際化的コンテキストの中で名前をつけると「日本語用ハイフン類」でしょうか、
>> もしくは ideographic hyphen でしょうか）。cl-03 には文字クラスの見直しの際
>> に次のような議論がありました：現在の Unicode 文字でこの文字クラスであること
>> に疑問がないのは波ダッシュ U+301C と二分二重ダッシュ U+30A0 のみ。四分と二
>> 分のダーシ U+2010, U+2013 は日本語用のものと英文用のものでは振る舞いが異な
>> るのに一つのコードポイントしか与えられていない。これを受けて考えると、
>> Unicode のプロパティで絞れないのはその問題のもう一つの表れと捉えることがで
>> きるかもしれません。つまり絞れない場合はそのこと自身が問題のありかを示唆し
>> ている可能性がある。
>> 
>> 
>> 下農さん、この作業をしていて、GC, EAW, DT, UAX50, 以外に使えそうなプロパテ
>> ィはあります？
>> 
>> 木田
>> 
>> > 2021/03/12 20:41、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール:
>> > 
>> > 
>> > 
>> > On 2021/03/09 22:55, Atsushi Shimono (W3C Team) wrote:
>> > > > *文字クラスの国際化
>> > > > *ほとんど時間がなく、1) 今まで議論してきた字間クラスをまとめたデータ
>> > > > を作り、Unicode のプロパティに落とし込むことができるか調査する（木田、
>> > > > 下農） 2) 次回のミーティングでは、字間以外にどのような文字クラスが必
>> > > > 要か、どのような機能が文字による挙動の違いの影響を受けるかをレビュー
>> > > > すること、を決めた。
>> > > 　メールで書いていたと思って書き忘れていたことに気付いたのですが、cl-01
>> > > の際に話題になった縦書用
>> > > のコードポイントの除外は、Decomposition TypeがVerticalでフィルターでき
>> > > ていました。これに入るの
>> > > は、ほとんどがU+FExxのポイントではありますが。。。
>[a:https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=[:
>Decomposition_Type=Vertical:]> > > https://util.unicode.org/UnicodeJsps/list-
>unicodeset.jsp?a=[:Decomposition_Type=Vertical:]
>> > > 　cl-02移行については順次進めていっております。。次回MTGまでには半分以
>> > > 上は終わらせるぞとは思って
>> > > おりますが、、はい。
>> > 
>> > 　以前にお送りしたような表を後ろまでやっていったものを添付します。
>> > 　大方の皆様の予想通り、かな、とは思うのですが、cl-01/02についてはほぼ
>> > Unicodeのプロパティーなど
>> > で置き換えられる感じです。
>> > 　cl-03以降の記号の分類については議論の中で出ていたようにかなり厳しそうな
>> > 気もします。。
>> > 
>> > 　添付ですが、Coverというシートに説明がありますのでそちらをまずご覧くださ
>> > い。
>> > 　cl-PoLm-uniのシートは04-10の文字クラスについては該当があれば記入してい
>> > ますが、11以降については
>> > 入っておりませんのでご注意くださいませ。(あれば順次追記していって近いうち
>> > に流したいとは思いますが)
>> > 
>> > 
>> > 
>> > 
>> > <jlreq-cl-with-unicode-202103.xlsx>
>> 
>

Received on Monday, 15 March 2021 05:31:02 UTC