Re: 文字クラスの国際化

木田泰夫 様
みなさま

 小林 敏 です．

いってみれば，日本語組版の基本は，文字間は全部ベタでいいのですが，そこか
ら例外が出てくる．その例外だけを括りだしてしまえば，その他は同じでよいと
いう発想です．

この基本的な問題で問題となるのは，
 句読点，括弧類，中点類の問題
 ベタ組ゆえに，分割禁止（行頭・行末禁則）の問題

これをまず考え，行の調整，ラテン文字，ルビ，その他を順次に加えて考えると
いうことです．

腰痛は，整形の医者に通っていますので，徐々によくなっています．

以下，すこしだけコメントしておきます．

たしかにcl-04のとcl-06の疑問符は同じ役割です．アキを自身で保持しているか
いないかであるが，実をいうと，疑問符の後ろの全角アキは，一般に全角スペー
スでアキを確保しているので，行の調整処理の対象から外しています．しかし，
活字組版時代は，この全角も行の調整処理の対象とする方式もありました．です
ので，疑問符の後ろの全角アキを文字自身に保持させれば，コンピュータ組版で
も，それが可能になります．

また，活字組版では，句読点や括弧類も，アキを持たないもの（つまり二分幅）
が原則だったようです．それがモノタイプなどの影響から全角台のものが使われ
てきたようです．

ですから，字形にアキを持たせるか，持たせないかは，決めればよいことだとも
いえます．（最初から決められれば）

次に，コーテーションマークやコロン，セミコロンです．これらは元々は欧文用
のものです．それを和文ように流用したもので，これも元々はアキを持っていな
かった．で，アキを持たない，これらを和文用に使う場合，その前後にスペース
を入れていました．“出版編集技術”では，この方式で，四分のコーテーション
マークの後ろに四分スペースを入れていました．ですからダブルの場合は，アキ
を含めて二分四分の幅にしていました．

ということで考えれば，フォントにアキがあるか，ないかの情報があればよい，
ということになるが，ないときはどうするか，……

こう考えてくると，この辺が国際化で乗り越えないといけない壁かもしれません
ね．

と，とりとめなく書いてきました．現状では，この程度はなんとか可能というこ
とです．

  木田泰夫 さんwrote

>敏先生、
>
>> いっそのこと，ごく
>> 簡単に問題になる事項，最初は必須の処理事項をしぼり，国際化を考慮してクラ
>> ス分けしてみる．次に，それに新たな目的を追加し（組版レベルが上がるという
>> ことでもある），どう細分化するのか考えてみるのもよいかもしれない．（いっ
>> てみれば，細かい状況になっているものを見直すのでなく，最初からやりなおし
>> てみるということです
>
>ありがとうございます。敏先生のご意見は規則を作ってきた者ならではの自在さと重
>みがあります。
>
>全角問題を考えても、単純に文字クラスを拡張すれば済む問題ではないことが見えて
>きたように思います。クラス分けとその組版を組み立て直してみるのが良いのかもし
>れませんね。
>
>
>> 文字間のアキ（行頭・行末を含む）で以下
>>  アキを抱える括弧類と句読点，中点
>
>文字間のアキのための文字クラスには、文字の中にアキが含まれているのか、どこに
>あるのか。それが最重要ということですね。
>
>これは言われてみれば当然に思えますが、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 Wednesday, 17 March 2021 05:01:18 UTC