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

とってもカタツムリなレスポンス（とっても遅い）ですが、

下農さん、まとめをありがとうございます。問題点がよく把握されていると思います。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) ギリシア文字やキリル文字など全角として実装されている文字カテゴリの扱い
> でしょうか。