- From: Yasuo Kida <kida@mac.com>
- Date: Sun, 10 Jul 2022 18:55:52 +0900
- To: Shinyu MURAKAMI <murakami@vivliostyle.org>
- Cc: 下農 <atsushi@w3.org>, JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-Id: <13C1BAD8-1BCB-4D03-8996-B413B6B6088E@mac.com>
> ところで、AppleのOSでの漢字・仮名文字と欧字との間に自動的に入るようになったスペースの量なのですが、私は1/6emだと思ってました。 実験してみるとおおむね 1/8 em のようです。私の日本語環境で見てみました。 下のイメージの最初の行は「あ」と「M」の繰り返しが5回、合計10文字で、9つの和欧間があります。次の行は「あ」が6つと「M」が5つで和欧間が一つ。これらの文字列長が等しいので、8つの和欧間が一つの「あ」に等しいことになります。システムフォントでしか動かないようでフォントを指定すると和欧間が消えます。最初の例が14ポイント、次の例が12ポイントなのですが、12ポイントでは終端がほんの少しずれていますがこれも不明。 ともあれ、私もこの約 1/8 em を気持ちの良い和欧間間隔と感じます。 下のイメージは、上はスペースあり(システムフォントのまま)、下はスペースなし(ヒラギノ角ゴシック指定)。欧文のフォントが異なるので正確な比較ではありませんが、雰囲気を理解していただけるかと。 木田 > 2022/07/10 14:46、Shinyu MURAKAMI <murakami@vivliostyle.org>のメール: > > 村上です。 > > CSS text-spacing プロパティの今のドラフト仕様での定義では、 > https://www.w3.org/TR/css-text-4/#valdef-text-spacing-ideograph-alpha <https://www.w3.org/TR/css-text-4/#valdef-text-spacing-ideograph-alpha> > > ideograph-alpha > Creates extra spacing between runs of ideographs and non-ideographic letters. > > ideograph-numeric > Creates extra spacing between runs of ideographs and non-ideographic numerals glyphs. > > となってます。そして、Noteとして、次のように書かれてます: > > Note: A commonly used algorithm for ideograph-alpha and ideograph-numeric is specified in [JLREQ]. Spacing conventions vary, but values typically range from 1/4em to as low as 1/8em, with 1/4em being particularly common in monospace contexts and 1/6em being more common in proportional typesetting. > > 以前は "Creates 1/4em extra spacing…" という定義だったのに対して、1/4em は必ずしも適切ではないという意見が反映されてこのようになったと思います。 > 関係issue: https://github.com/w3c/csswg-drafts/issues/7050 <https://github.com/w3c/csswg-drafts/issues/7050> > > しかしこのままでは、実装依存で和欧文間のアキ量が変わるということになってしまい問題かもしれません。アキ量の指定を可能にするCSSプロパティを新たに設けるとしても、デフォルトの和欧文間のアキ量は決めたほうがよさそうです。 > > デフォルトをどうするかの議論について、 > >> On Jun 28, 2022, at 16:15, Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>> wrote: >> >> 関連して、文字クラス依存のプロパティーの話について別のissueが(このissueの中の文章を持って >> きて)立っております。 >> https://github.com/w3c/csswg-drafts/issues/7183 <https://github.com/w3c/csswg-drafts/issues/7183> >> ご参考まで。 > > > このissueについてのCLREQグループでの議論 > https://www.w3.org/2022/04/15-clreq-minutes.html#t02 <https://www.w3.org/2022/04/15-clreq-minutes.html#t02> > がとても参考になります。 > > > Eric: Apple's operating systems have 1/8em extra spacing by default > > … This is what Apple has implemented > > > Eric: If the spacing is 1/4em, the user may think they have entered a space by mistake, or the text may overflow. > > … Although jlreq and clreq say 1/4em is fine, and there are many print publications that use 1/4em > > … for digital media, 1/4em value is too large > > … I think there is consensus on this point > > > Bobby: I think Apple's 1/8em is an acceptable default under digital media > > > 従来の紙の組版での標準が1/4emであったとしても、デジタルでのデフォルトは 1/8em でよいだろうという議論、まさに xLREQ-D にふさわしいと思います。 > > 私も1/8emデフォルトに賛成です。 > > ところで、AppleのOSでの漢字・仮名文字と欧字との間に自動的に入るようになったスペースの量なのですが、私は1/6emだと思ってました。もしかしたら、中国語と日本語とで変わるのしょうか。あるいはフォント依存でそのフォントでの欧文スペースの幅の半分(Appleの標準の日本語のフォント Hiragino Sans や Hiragino Mincho は欧文スペースの幅が 1/3em だが、ほかの多くのフォントでは 1/4em くらいのものが多い)とか。AppleのOSのこの機能についての資料、どこかにないでしょうか? > > アキを入れる場合のデフォルトは 1/8em と決めるとよいと思います。 > 問題は、アキを入れることをデフォルトとするかどうかですね。 > > 既存コンテンツで問題が起きないように、CSSのデフォルト(text-spacing: normal)ではアキを入れるべきではないという意見はもっともだと思います。しかし、これまで和欧文間のアキの標準とされてきた 1/4em よりもずっと控えめな 1/8em であれば、既存コンテンツで問題になる可能性もだいぶ低いかと思います。ぜひこのアキを入れることをデフォルトにすることを検討してほしいです。 > > また、CSS text-spacingのデフォルトをよりよいものにする議論、行頭と行末の約物についても進むことを期待します: > > 折り返し行頭約物を詰めるのをデフォルトにする提案: > https://github.com/w3c/csswg-drafts/issues/2462 <https://github.com/w3c/csswg-drafts/issues/2462> > > 行末約物を詰めるのをデフォルトにする提案: > https://github.com/w3c/csswg-drafts/issues/7055 <https://github.com/w3c/csswg-drafts/issues/7055> > > > > > > ---- > 村上 真雄 (MURAKAMI Shinyu) > Vivliostyle Foundation >
Attachments
- text/html attachment: stored
- image/png attachment: ____________________________2022-07-10_18.34.48.png
- image/png attachment: ____________________________2022-07-10_18.50.48.png
Received on Sunday, 10 July 2022 09:56:11 UTC