CSS text-spacingドラフト仕様への改良提案とVivliostyleでの先行実装について

Vivliostyle 村上です。

最近、CSSで和欧文間のスペースや行頭・行末・連続の約物の詰めを指定する text-spacing プロパティを Vivliostyle.js に先行実装しました。そのときに気になった現状のドラフト仕様の問題点について修正提案をissueにしました：

[css-text-4] change "Creates 1/4em extra spacing between" to "Creates extra spacing between" <https://github.com/w3c/csswg-drafts/issues/7050>
[css-text-4] text-spacing: trim-end is better than allow-end for the normal value <https://github.com/w3c/csswg-drafts/issues/7055>

最初の提案は、和欧文間のスペースを1/4emと決めないで、より適切なスペース幅にできるようにというものです。これまでも議論されてきましたが、1/4emの幅では多くの場合空きすぎであり、より狭いスペース（1/6emなど）のほうが違和感がもたれないことが多いです。条件によって最適なスペース幅は変わるでしょうから、将来のより賢い実装ではコンテキストによって最適な幅のスペースを自動で入れるというのもありかもしれません。

最近iOSのテキスト表示で和欧文間のスペースが勝手に入るようになったということが一部で話題になりました。見てみると、そのスペース幅は1/6emくらいのようです。たぶんApple社が独自の調査のうえで、JLREQや現状のtext-spacingドラフト仕様の1/4emではユーザーが違和感を持つと判断して、狭めのスペース幅にしたのでしょう。しかし、それでもTwitterでの反応をみると、次のように違和感があるという否定的な反応のほうが目につきます：

> iOSアップデートしたら半角英数字の前後に半スペみたいな謎空間出来ちゃってめちゃくちゃキモい😢 少なくとも半角と全角を使い分ける日本語には適してないよねどうにかしてくれ

> iOSのバージョンを上げてから英数字と日本語を組み合わせた場合の文字詰めの間隔変わった？なんか気持ち悪いんだけど。最近のツイートの誤字がほとんどそれに起因しとる

> iOSを15にアプデしたら半角英数字の前後のスキマが気になる…… って書いてる「iOSを15に」の部分がもうきもちわるい

> iOSアプデしたら英数字と日本語の間に不自然な間隔開いて違和感

> 新しいiOS、日本語と英数字に若干スペース作ってくる仕様がなんか…慣れん！

（以上は Twitterで「iOS 英数字」を検索 <https://twitter.com/search?q=iOS%20%E8%8B%B1%E6%95%B0%E5%AD%97&src=typed_query&f=top>  して出てきたものから拾ったもの）

たぶん、良くなった、テキストが読みやすくなったと感じている（あるいは、気が付いてもいないけれど実は読みやすくなっている）というユーザーも多いのだろうけれど、このように否定的な反応が目立つことは興味深いです。もしもこれが、JLREQのとおり1/4emの和欧文間スペースになっていたならば、ユーザーからの否定的反応はさらに大きかっただろうと想像できます。


2つ目の提案は、text-spacing のデフォルト（初期値 normal）の定義に現在含まれている allow-end（行末約物全角/半角＝行末約物をなりゆきで半角幅か全角幅のどちらかにする）を trim-end（行末約物半角）に変更するというものです。

text-spacing のデフォルトでの行頭側については以前に、space-start（行頭約物全角）から space-first（段落先頭約物全角、折り返し行頭約物半角）に変更する提案を行っています：

[css-text-4] Propose 'text-spacing: space-first' (trim-start-except-first-line) as a normal behavior  <https://github.com/w3c/csswg-drafts/issues/2462>

これと今回の提案とをあわせると、text-spacingのデフォルト（初期値 normal）の定義を、現在のドラフトの `space-start allow-end trim-adjacent` （行頭約物全角、行末約物全角/半角、連続約物半角）から `space-first trim-end trim-adjacent` （段落先頭約物全角、折り返し行頭約物半角、行末約物半角、連続約物半角）に変更する提案となります。

行末側のデフォルト動作を allow-end（行末約物全角/半角）から trim-end（行末約物半角）に変更する理由は次の2点です。

多くの場合 trim-end のほうが allow-end よりもタイポグラフィ的に優れている
trim-end の動作の方が allow-end よりも単純であり、処理のオーバーヘッドが少なくて済む

trim-end と allow-end のどちらがタイポグラフィ的に優れているかは、もちろん一概には言えません。しかし、CSS仕様が主なターゲットとしているWebで、行頭行末を揃えるジャスティフィケーションのスタイルが使われる場合（trim-end/allow-end はジャスティフィケーション無しなら関係ない）を考えると、行末を揃えることで美しいレイアウトにしたいということなので、約物のある行末が揃わない allow-end よりも trim-end が好ましいことが多いと思います。したがってデフォルトとしては trim-end のほうが適切でしょう。CSSで書籍のような組版レイアウトを再現したいなどという場合には、そのためのほかのCSSの設定とともに text-spacing: allow-end も指定すればよいのだから、デフォルトが allow-end である必要性はないはずです。


trim-end の動作の方が allow-end よりも単純であり、処理のオーバーヘッドが少なくて済むということは、実際に Vivliostyle.js に実装してみて実感したことです。

trim-end の場合、対象となる全角幅の約物を、基本的に半角幅の約物＋半角幅のスペースとして扱って、そのスペースが行末になれば通常のスペースと同じく行末に吸収されて消えるというような比較的単純な処理で実現できます。一方 allow-end の場合は、約物が行末ぴったりの位置にあるかどうかで半角どりにするか全角どりにするか変える必要があるので、処理が trim-end ほど単純ではなく処理時間がかかってしまいます。ユーザーが指定しなくても働くデフォルトの動作で、余計な処理時間がかかるのは最悪です。

以上のことから、allow-end をデフォルトにすることはできないと判断して、今回提案している新しいデフォルト(normal)の定義 `space-first trim-end trim-adjacent` （段落先頭約物全角、折り返し行頭約物半角、行末約物半角、連続約物半角）を採用した実装としています。
（より正確に言うと、最初に text-spacing と hanging-punctuation を実装した昨年秋の段階では allow-end はサポートしていなかったのを、今回そのサポートを含めた実装の改良を行ない、そこで現ドラフト仕様のとおり allow-end をデフォルトにしようとしたら、それでは組版処理が重くなることが分かったため、trim-end をデフォルトとして、ドラフト仕様を修正するこの提案をすることにしたということです。）


以下は参考として：

関連するVivliostyleサイトのブログ記事：行末処理が進化して多様な組版ができるように <https://vivliostyle.org/ja/blog/2022/02/08/Improved-of-line-end-handling-and-support-for-page-progression-direction-in-PDF/>
Vivliostyle Viewer での text-spacing と hanging-punctuation のテストページ <https://raw.githack.com/vivliostyle/vivliostyle.js/master/packages/core/test/files/#Text_Spacing>
各テスト項目の [canary] あるいは [stable] のリンクをクリックすると、Vivliostyle Viewer で組版結果が確認できます。
ブラウザのウインドウ幅を変えることで、行の折り返し位置による text-spacing や hanging-punctuation の各値の効果を確認できます。


Vivliostyle.js は、ブラウザで未実装のCSSの機能（主に CSS Paged Media 関連）をJavaScriptで実現している一種のpolyfillです。今回行なった text-spacing と hanging-punctuation の実装は、これらのプロパティがブラウザで標準で利用できるようになれば不要になるものです。せっかく実装したけれど、早く不要になるとよいです。
この先行実装の経験が、仕様標準化が進むのに役に立つようにと思ってますので、どうぞよろしくお願いします。


----
村上 真雄 (MURAKAMI Shinyu)
Vivliostyle Foundation