- From: 木田泰夫 <kida@mac.com>
- Date: Tue, 30 Mar 2021 08:27:48 +0900
- To: "Atsushi Shimono (W3C Team)" <atsushi@w3.org>
- Cc: public-i18n-japanese@w3.org
> ふと思い出したので、文字間の空き量の扱いをいじるときは、そこらへんも要考慮なのかなという気がしました。 > # とりあえずの頭出しまで 英語でもありますよね。単語間スペースとセンテンス間スペースは幅が違う。タイプライターの時にはスペースを二つ入れていましたが、今はおそらくそんなことしません。Word などワードプロセッサーは適宜空白の幅を調節していたかと思います。iPhone はセンテンスの後ろに2回スペースを押すという伝統・癖を利用して、ダブルスペースでピリオドと空白一つを出力します。 html/css ではどうなっているんでしょう? どなたかご存知? 木田 > 2021/03/29 15:56、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール: > > > >> On 2021/03/13 10:21, 木田泰夫 wrote: >> ありがとうございます。この表でわかる下の三種類のケースのうち: >> 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 のプロパティで絞れないのはその問題のもう一つの表れと捉えることができるかもしれません。つまり絞れない場合はそのこと自身が問題のありかを示唆している可能性がある。 > > : : snip : : > >>> On 2021/03/09 22:55, Atsushi Shimono (W3C Team) wrote: >>>>> *文字クラスの国際化 >>>>> *ほとんど時間がなく、1) 今まで議論してきた字間クラスをまとめたデータを作り、Unicode のプロパティに落とし込むことができるか調査する(木田、下農) 2) 次回のミーティングでは、字間以外にどのような文字クラスが必要か、どのような機能が文字による挙動の違いの影響を受けるかをレビューすること、を決めた。 >>>> メールで書いていたと思って書き忘れていたことに気付いたのですが、cl-01の際に話題になった縦書用 >>>> のコードポイントの除外は、Decomposition TypeがVerticalでフィルターできていました。これに入るの >>>> は、ほとんどがU+FExxのポイントではありますが。。。 >>>> 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以降については >>> 入っておりませんのでご注意くださいませ。(あれば順次追記していって近いうちに流したいとは思いますが) > > ここら辺、ちと情報が散乱して頭のなかで整理できなくなってきたので、個人的に集積したページを以下に > おいています。 > https://himorin.github.io/jlreq-unicode-notes/AllClasses.html > > とりあえず、のところですが、既存文字クラスの文脈の範疇でUnicodeにどうやって置き換えるかについては > ほぼ議論・論点が出尽くしたのかな、という気がしてきました(小書きの分離ができないとか、cl-03-10の議論 > などは未解決として残るとして)ので、以前のタスクリストの積み残しのうち > ・JLReqで文字クラスでなく単独文字として機能の解説で参照されているものの分析 > ・Appendixの表(文字間の空き量などなど)と文字クラス利用場所の表の対応 > あたりに手を付けていこうと思っています。 > > > 閑話休題 > > まとめてる間にcl-14/27のそれぞれ一文字ずつが入ってる文字間隔のところで思い出したのですが、 > https://github.com/w3c/sealreq/issues/46#issuecomment-782795767 > とか(これはタイ語で文の間と単語の間の空白のサイズが違うのはどうしている話)の議論を思い出して、そうい > えばCSSではjustificationに利用可能な空白に1/3とか1/6とかのは入っていない(というよりは今はU+0020/3000 > だけ?)という話があった(CSSのissueに何かあった気がしているんですが見つけられていない)な、というのを > ふと思い出したので、文字間の空き量の扱いをいじるときは、そこらへんも要考慮なのかなという気がしました。 > # とりあえずの頭出しまで > >
Received on Monday, 29 March 2021 23:28:05 UTC