Re: 文字クラス整理・Unicode化に関連する論点リスト

敏先生、

ありがとうございます。ポイントが整理できると良いですね。

二つのレベルがあるのかなと思っていて、一つは組版の挙動の記述が文字コードに基づいているので、それぞれの文字、特に役物の使われ方を仮定する必要があることや、またデジタルのアーキテクチャからくる制約（例えば同じデータが縦書きにも横書きにも使われる可能性のあること）を考慮する必要のあること。これら技術的に必要な想定や、派生するガイドラインが一つ。デジタルネイティブ的、未来向きな立場で考えたいですね。

もう一つは JWT で扱うような本来的なデジタルネイティブ正書法の考察。

この二つに明確な境はないのですが、前者に重心を置きつつ考えたいと思っています。考えたいというよりも、Unicode 化のために幾らかの明確化が避けて通れなさそうなので、というところでしょうか。

子カギは面白い例ですね。使い分けが一般的なら別個のコードポイントが欲しくなるところですね。

英語では、会話文や、その他の意味で使われるダブルクオーテーションがさらに会話文に含まれる場合にどうするんでしょうね。

木田

> 2020/10/09 8:45、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
> 
> 木田泰夫　様
> 
> 　小林　敏　です．
> 
> 以下の件，了解いたしました．
> 
> “約物の正書法”は，何を言うかは問題ですが，何か整理できればいいですね．
> 
> ところで，横組の句読点は3種類の方法があり，“公文書作成の要領”で決めら
> れている方法は，現在は教科書などでは採用されていますが，一般の文書やWeb
> では採用される例は少ないのが現状で，現在，文化庁の文化審議会（名称は間違
> っているかも）で検討がすすめられており，現状の追認になるだろうと思ってい
> ます．
> 
> 字形IDで考えないといけない問題，私も例を調べてみます．今，思いつくの“大
> カギ”（通常のかぎ括弧）と“小かぎ”です．縦組でいうと，水平線が短いのが
> “小かぎ”です．括弧が入れ子になる場合，一般に「〇『〇』〇」となりますが，
> 引用する場合，元の文章では「」ですが，引用を「」でくくると，元の「」を
> 『』に変えないといけない．そこで，入れ子の『』を小かぎにすると，それが避
> けられるというわけです．いくつかの出版社では，この方法が採用されています．
> 
> 以上，よろしくお願いいたします．
> 
> 
> 木田泰夫　さんwrote
> 
>> とってもカタツムリなレスポンス（とっても遅い）ですが、
>> 下農さん、まとめをありがとうございます。問題点がよく把握されていると思います。
>> Unicode 化には文字クラスの拡張が必要なのですが、Unicode の文字クラスが文字の
>> プロパティであるのに比べて、JLReq の文字クラスは文字の静的なプロパティに加え
>> て動的な場合わけ、ステートが混ざっていて、このアーキテクチャの違いを克服する
>> のに控えめに言って大変な変換作業になりそう。
>> もちろん、Unicode の文字クラスその他の文字プロパティとはあまり関係ない形で現
>> 在の JLReq 文字クラスを拡張することも可能だと思います。が、成長する Unicode
>> に合わせて JLReq 独自の文字クラスをメンテナンスし続けるのは現実的ではないでし
>> ょう。また、国際的なアーキテクチャに整合させておくのは日本語組版の将来の発展
>> に向けて、いつかはやらなければならないことかと思います。
>> どこから手をつけましょうね。敏先生が、文脈依存のクラスを外すための議論を始め
>> てくださっていますので、まずそれを片付けましょう。これに関してオンラインで
>> ミーティングしましょう。後で調整さんを送りますので、来週、単純のために午前10
>> 時からとして、OK な曜日を教えてください。また9時からの方がよければ教えてくだ
>> さい。この議論にインプット・興味がありそうな人だけで OK です。
>> –––––
>> Unicode / 国際化アーキテクチャへの整合化と同時に、必要に応じて「役物の正書
>> 法」についても考えてゆきましょう。下農さんが言われたように、技術的な整理をし
>> てゆく際に必要になると思われます。本来我々が、この文字はこうだ、と決める立場
>> ではないとは思いますが、かといって他の誰も決めてくれませんし、それを曖昧にし
>> たままでは技術的な仕様も曖昧になってしまいます。「技術的にはこう考えていま
>> す」的に考えるのはどうでしょう。下農さんがリストしてくださった 3, 4, 6 が大体
>> これに当たりますね。
>> ––––––
>> Nat さん、字形 ID で考えなければならないものがあるんですね。具体的にどんな文
>> 字があるんですか？　OpenType フィーチャーに関しては旧字体への変換など、本来の
>> 文字コードがそもそも変わってしまうような変換が可能なので、プレーンテキストと
>> しての文字データと、見かけの差の問題が出てきますね。
>> 木田
>>> 2020/09/23 11:38、Nat McCully <nmccully@adobe.com>のメール:
>>> 上のカテゴリにまたがると思いますが、ユニコードからクリフに変換するshapingの
>>> 場合、縦書きが横書きか、OTF機能の適用かで、文字組みクラスが標準のと変わるこ
>>> とを考えると字形id でクラスを決めることも考えないといけないですね。
>>> —Nat
>>> From: Atsushi Shimono (W3C Team) <atsushi@w3.org>
>>> Sent: Tuesday, September 22, 2020 6:09:05 PM
>>> To: W3C JLReq TF <public-i18n-japanese@w3.org>
>>> Subject: 文字クラス整理・Unicode化に関連する論点リスト
>>> 　shimonoです
>>> 　これまでにメールで流れた論点の整理・リスト化です。
>>> 1. JLreq文字クラスのUnicodeへの移行
>>>  こちらはどちらかというと他の論点(3.以降)を煮詰めたら解が見えてくる話でし
>>> ょうか。
>>> 1.a) CL-01/02とPi,Ps/Pe,Pfの関係、その約物の幅
>>> 1.b) CL-19,27のような全般的な文字クラスの拡張方策
>>> 1.c) 単位記号など分割禁止として定義されているがUnicodeで対応が難しいもの、
>>> と、Unicode禁則処理定義
>>> 2. JLreq文字クラスの整理・統合
>>> 　1.とは独立に、木田さん提示の文字自体でなく文脈由来の文字クラスを外してし
>>> まうプラン、敏先生
>>> のJWT報告書(2019/3)の集約案などから、整理・統合した簡単な文字クラスを定義す
>>> る議論があります。
>>>  あと、InDesignの文字クラスやIllustratorの整理での問題点も参考にしてみるこ
>>> とが提示されてい
>>> ます。
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fworks014.

>>> hatenablog.com%2Fentry%2F20141022&amp;data=02%7C01%7Cnmccully%40adobe.com%
>>> 7C3af2f639501f4685e8f008d85f5d4bdd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%
>>> 7C0%7C637364201594655514&amp;sdata=lCehR9yrNaprjeI0leZkb%
>>> 2BqKO1q6amkrSTDpg2aVFWE%3D&amp;reserved=0
>>> 3. 約物の機能論的包摂分離
>>>  「約物の正書法」的なガイドラインを策定する議論がいくつかあげられています。
>>> 3.a) U+2016, U+30A0
>>> 3.b) 罫線素片
>>> 3.c) 漢字とも仮名とも判然としない記号類の扱い
>>> 3.d) 「ヨリ」「コト」の合字
>>> 3.e) U+301C / WaveDash, U+FF5E / FullWidthTilda, U+30FC / Katakana-Hiragana
>>> Prolonged Sound Mark
>>> 4. 記号類の縦横問題、同一か異なる縦横のコードポイント、U+FFXX
>>>  主にJWTの約物の意味論議論ではありますが、フォント・CSSも絡んだ問題として、
>>> 記号類の縦横グリ
>>> フの問題、3.の包摂分離に近い話かもしれませんが、くの時のような複数文字を並
>>> べた表現の縦横問題
>>> が挙げられています。
>>> 4.a) くの字点、ダブルミュート / Double Vertical Line、U+2702
>>> 4.b) 村田さんの弥縫策、Text Shaping WG
>>> 5. 全角半角論、約物の幅とは何か
>>> 　約物のspacingをどう扱うか、というところから話が広がり、
>>> 5.a) 約物のspacingの詰め処理をどう記述するか、文字全般にどう拡張するか
>>> 5.b) 現実のフォントでは全角グリフが通例だが、「半角＋spacing」と記述されて
>>> いる約物について、現
>>> 実のフォントについてJLreqでどう言及するか
>>> 5.c) 欧字=半角、ではなくなっているフォントの現実において、和欧混在文での揃
>>> え
>>> 6. 原語で"全角"の概念がない文字について、全角文字を使う場面のガイドライン
>>> 　この点についてこれまでに出ていたのは
>>> 6.a)「全角欧文は、日本語の文脈だけで使用」についてその文脈についてのガイド
>>> ライン
>>> 6.b) ギリシア文字やキリル文字など全角として実装されている文字カテゴリの扱い
>>> でしょうか。

Received on Friday, 9 October 2020 07:11:37 UTC