Re: (reminder) JL-TF Zoom Next Jan/26

下農さん、リマインダーありがとうございます。

前回12/16のミーティングのノート（のドラフト）を下農さんのメールの下に貼り付けておきました。時間が経っているので、コンテキストを思い出すのに使ってください。どうも正式英語版の meeting notes を出すのをすっかり忘れているようです。

前回のミーティングを受けて、今回議論すべきことはなんでしょう。私もノートを見ながら思い出しますが試験で頭が溶けてしまった私のためにどなたかまとめていただけると嬉しいです。

あと村田さんから一つリクエストがありました。

> 日本デイジーコンソーシアムの技術委員会で作成した仕様書について、ことしは皆さんにもお見せしてご意見をお聞きするつもりです。ルビ、分かち書き、縦横切替に関するものです。


木田

> 2021/01/21 16:19、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール:
> 
>   hi all,
> 
> Next call will be Jan/26 as usual time, with usual Zoom link (reminder will be sent next week).
> 
> 　みなさま、あけましておめでとうございます（というメールはすでに新年早々に流れておりますが）
> 
> 　というところで、センターも無事に終了し(いろんな意味で無事だったかは来週末まで待たないとい
> けない？？)、次回の定例会は来週火曜の1/26となりました。だいぶ長らくあきましたので、リマイン
> ダーを流させていただきます。
> 
> 　Zoomリンクは、来週早々にもリマインドする予定ですが、以前に利用敷いたものと同じです。
> 
> 　わたしの方の進捗はあまりありませんが、、
> ・CL-01でやって流したunicodeのcategoryをベースにした調査を02以降にやらないとという作業は未着手
> ・githubでいくつか細かいeditrialな修正についての議論が行われてます
> ・サマリーがついた議論や、(主に敏先生の)ノートを英訳してgithub issueに上げるのをはじめようとしてます
> <OpenPGP_0x72397AFC0905265D.asc>


転送されたメッセージ:

> 差出人: 木田泰夫 <kida@mac.com>
> 日時: 2020年12月16日 16:35:12 JST
> 宛先: JLReq TF 日本語 <public-i18n-japanese@w3.org>
> 件名: ミーティングノートのドラフト & 質問
> 
> みなさま、
> 
> 今日のミーティングは白熱しましたね！　この議論をきっかけにして行き着く先が楽しみです。ノートをまとめてみました。抜け、訂正の必要があったら教えてください。修正ののち英語版を作ります。いくつか質問もあります。
> 
> 
> cl-15/16 ひらがな、カタカナ
> ・変体仮名や仮名の合字→このクラスに含める（U+309F こと→ cl-19 から cl-15 へ、U+30FF より cl-19 から cl-16 へ、Unicode で変体仮名や仮名の合字が加えられている。それらもここ）。濁点半濁点合成の文字もここ（すでにそうなっているが念の為）。enclosed circle が加わるのは別（cl-19）
> ・漢字との違いはルビがかかるかどうか（木田質問：つまり、字間のためだけなら特に別クラスにする必要は特にないということ？）
> 
> cl-17/18 等号類、演算記号
> ・cl-17, cl-18 は整理し直す。日本語の縦組みコンテキストで日本語の一部として使われる文字のみ、例えば＋－など、を拾い上げてそれらの挙動を記述する（クラスが残るかどうか不明）。その他の文字は JLReq 担当外。例えば数学専用の文字組みルールに任せる。
> 
> 
> 
> 議論
> 
> 縦書きにおける記号の正立回転問題
> 色々な議論がありましたが、一つの総意は、Unicode 上で分けるべき文字がありそう、ということかと思います。
> ・記号は unify しすぎ。別個のコードポイントが必要。例：長音 wave dash、三点リーダ（小林）、三点リーダ、スマートクオート=左右別々のもの e.g. U+2019（Nat）
> ・縦横の動きが異なるなら分けた方が良い（小林、Nat）。InDesign で UR のもの、別コードポイントが欲しい（Nat）
> ・X0213で追加された二重ハイフンの利用が進んでいない（小林）（これは何が問題で何がゴール？）
> ・ハイフンと二分ダーシ（及び二重ハイフン／二分二重ハイフン／イコール？）が混用されている。意味とデザインが違うので使い分けが好ましい。動作は JLReq では両方とも行頭禁止（敏先生）
> ・電子書籍化において例えば縦書きに現れる割り算記号は縦横方向に気をつける必要がある（田嶋）
> （木田質問：これは、意識しないと回転するが、正立で必要な場合がある、というお話でしたっけ）
> ・FFxx だけ別クラスにして、例外なく正立にすれば良いのでは（小林）（木田：現在 UAX 50 において、全角互換文字のうち “＜＝＞－” の4文字が R、つまり縦書きで回転する規定になっている）。全角 “＋” が回転から外れているが、問題がある。縦横でストローク幅を変えてある例などあるので（敏先生）
> ・全角グリフの違いは、幅が全角かどうか、だけではなく、中心線に揃っているか（敏先生）
> ・縦組みでの記号の正立回転挙動について例を調べたい（小林）国語研のことのはコーパスは使えるか？（木田）ブルーバックスが科学技術系なのに縦書き（小林）良いサンプルになりそう（木田）
> ・プレーンテキストで指定する方法は入力し次第反映され、またプレーンテキストでも動くので、後でマークアップする方法に比べユーザビリティに優れる（木田）
> ・Unicode に正立か横組みかを指定する仕組みを作るのはどうか。bidi 制御文字のように（村上）そのために variation selector を使うのはどうか（小林）
> ・Hyphen-Minus やクオートとアポストロフィの例のように、タイプライター、7bit ascii、8 bit ascii など昔の限られた環境で同じだったものが、Unicode で意味的、機能的に分けることができるようになった（小林など）
> 
> 
> そのほか
> ・議論から、「その文字そのものについて述べている文脈」は除く。その議論を含めてしまうと全ての文字が縦書きで正立すべきという議論になる（木田）。また、デフォルト動作を決めているのであってマークアップで変更可能、という意識が必要。こういう場合もある、ではなくこういう場合が多い、という意識（木田）
> ・CJK ideograph 過剰に un-unified されている。それらの文字の使用を制限したい（小林）。制限は難しく normalization で対処すべきでは（木田）
> ・この文字は日本語で使われている、と文字を抜き出すことには危険性もある。例えば JIS は ￥＄ を採用したが、Unicode にはさまざまな国の通貨記号が含まれている。これらは縦書きでどう挙動するのか。拡張可能な仕組みが必要（木田）
> ・この記号の整理、どのくらい時間をかけるつもり？（小林）半年くらい？（木田 :）
> 
> 
> 次回は1月26日火曜日
> 
> 木田