- From: 木田泰夫 <kida@me.com>
- Date: Tue, 16 Mar 2021 16:03:00 +0900
- To: Kobayashi Toshi <binn@k.email.ne.jp>
- Cc: 下農 <atsushi@w3.org>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
敏先生、 > いっそのこと，ごく > 簡単に問題になる事項，最初は必須の処理事項をしぼり，国際化を考慮してクラ > ス分けしてみる．次に，それに新たな目的を追加し（組版レベルが上がるという > ことでもある），どう細分化するのか考えてみるのもよいかもしれない．（いっ > てみれば，細かい状況になっているものを見直すのでなく，最初からやりなおし > てみるということです ありがとうございます。敏先生のご意見は規則を作ってきた者ならではの自在さと重みがあります。 全角問題を考えても、単純に文字クラスを拡張すれば済む問題ではないことが見えてきたように思います。クラス分けとその組版を組み立て直してみるのが良いのかもしれませんね。 > 文字間のアキ（行頭・行末を含む）で以下 > アキを抱える括弧類と句読点，中点 文字間のアキのための文字クラスには、文字の中にアキが含まれているのか、どこにあるのか。それが最重要ということですね。 これは言われてみれば当然に思えますが、JLReq の文字クラスを Unicode のプロパティで表そうとして突き当たる問題にも現れてきます。JLReq のクラスはアキの制御に使われるのに、Unicode にはアキのことを考えたプロパティがないのです。 それがよくわかるのが cl-04 区切り役物 や cl-05 中点類です。 cl-04 は疑問符と感嘆符ですが、これらは機能的には句点 cl-06 と同じで一つの文を終わらせる機能があります。ではなぜ cl-04 と cl-06 が分かれているかというと、後ろのアキの量が違う。cl-06 は後ろに半角のアキを要求し、デジタルフォントのグリフにはこのアキが既に含まれています。cl-04 は後ろに全角を要求します。cl-04 と cl-06 の違いはアキの違いです。ところが、Unicode のプロパティで一文を終わらせる機能を持つ役物を見つけることはできますが、アキの要求量の異なる句点と疑問符感嘆符を見分けることができません。 もう一つの例は cl-05 です。ここには片仮名中点、全角コロンとセミコロンが含まれます。機能的に言うと中点は単語を繋ぐハイフンの仲間、コロンとセミコロンはフレーズを終える読点の仲間。機能的には異なる文字が cl-05 に集められているのは、両側に四分空きがあるという共通点があるから。アキ要求が同一なこれらの文字を集められるプロパティは Unicode にありません。 > 次のレベルは > 欧文が組み込まれた場合の問題はなにが問題になるか，新たな文字クラスは必 > 要になるか > ここでは，プロポーショナルの文字が含まれる問題を考えてもよい． > 仮名などがプロポーショナル，約物がプロポーショナルの場合は？ JLReq で全角を前提としている約物の多くが Unicode において必ずしも全角でないという問題に対処する必要があります。 これらの文字は三つくらいのグループに分けることができるように思います： A) Unicode に新たな文字を追加すべき可能性のある文字たち。クォーテーションマークやダッシュ、リーダ類 B) 日本語組版では全角であることを期待すると宣言すれば良さげな文字たち：二重感嘆符・疑問符の類 C) 全角であることの期待をやめて、プロポーショナル前提で考えるべきであろう文字たち：cl-17/18 の演算子の多く。cl-19 漢字類に含まれる漢字以外のものの多く、例えばギリシャ、キリル文字や記号類 この三つの区分けは今の思いつきですが、その区分けが適当なのかどうかは議論の余地があります。 またそのグループ分けが適当だとして、さてどの文字がどこに含まれるべきかの判断は難しいものになると思われます。例えば丸の中に文字が入るものたち、どれは全角であることが当然期待しても良いでしょうか。また黒三角のような幾何学的記号のどれが全角であるべきでしょう。もしかすると、East Asian Width 的な、日本語書体ではこの幅を期待する、チャートができあがるのかもしれません。現在のフォントの実態調査が必要になりましょう。 また、全角を期待する文字が全角でなかったらどう組版すれば良いかを考える必要があります。 Unicode という大海に泳ぎ出すと、全てが制御できた JIS 的箱庭的な環境ではなくなり、今まで想像しなかった状況に備える必要が出てきますね。 敏先生、腰痛のお具合はいかがですか？ くれぐれも無理をなさらないように。ぜひ無理のない範囲で付き合っていただけると嬉しいです。 木田 > 2021/03/15 14:25、Kobayashi Toshi <binn@k.email.ne.jp>のメール: > > 木田泰夫 様 > みなさま > > 小林 敏 です． > > 資料を十分にみたわけでなく，おもいつき段階なのですが，いっそのこと，ごく > 簡単に問題になる事項，最初は必須の処理事項をしぼり，国際化を考慮してクラ > ス分けしてみる．次に，それに新たな目的を追加し（組版レベルが上がるという > ことでもある），どう細分化するのか考えてみるのもよいかもしれない．（いっ > てみれば，細かい状況になっているものを見直すのでなく，最初からやりなおし > てみるということです（場合によってはルールそのものを見直してもよい）．そ > れで，現状と比較して考える．） > > 最初の段階は，以下，行の調整処理もルビも考えない > > 文字間のアキ（行頭・行末を含む）で以下 > アキを抱える括弧類と句読点，中点 > 文字間の分割では，以下だけ考える > 行頭禁止文字 > 括弧類，句読点，??記号，?書きの仮名（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 Tuesday, 16 March 2021 07:03:19 UTC