RE: CJKフォントのpalt(詰め組)とkernの関係

  *   なるほど、ブラウザだけでなく多くの既存アプリケーションがOpenType/OFF仕様の "If 'kern' is activated, 'palt' must also be activated if it exists." を無視した実装をしてきたということですね。

書いてあることを、無視して実装することの結果、あるいは適合性の条件の記述として求められる表現形式でないのだから、そこで書いてあることを無視しても良いのだと考えて実装することの結果、に対して、おそらく想像力を欠いていたことの代償を、むしろ、たとえ規格の文言としては不完全ではあっても、書かれてある内容を、それなりに妥当に解釈して、書いてあることと反対に解釈したりするような無茶はせずに、あるいは規格の書き方が悪いために理解しにくい場合には他の実装などをも参考にしながら、まじめにフォントを実装してきたフォントメーカーのフォントの表示結果を、その期待どおりにさせないことよって支払わなければならないことに合理性があるとは考え難いのですが、いかがでしょうか。


  *   paltとkernの両方を持った日本語フォントの開発者は、kernはpaltとの組み合わせで使われる前提で設計しているとしても、アプリケーション側ではpaltを有効にしないでkernだけを有効にすることが普通に行われていて、それに対してユーザーからのクレームはなかったのだろうと理解できます。

従来、ブラウザー上では必ずしも全角ボディベースのグリッドが常に使えていたわけではないと理解しています(この私の認識は既に古いかもしれませんが)。また、必ずしもジャスティフィケーションが行われてこなかった状況もあったと理解しています。そのような状況では、kernだけを適用することが、日本語の組み方をベタ組の制約から強制的に、微妙にとはいえ、乖離させてしまったとして、そういう組み方だけしかWeb上で見慣れていなかった利用者が「和文をベタで組めないではないか。微妙に意味なく詰まっている個所があって気持ち悪い」などとクレームをすることを期待することは難しいと想像します。

エンドユーザーの声は貴重であって尊重すべきは当然ですが、エンドユーザーがクレームを出していないような場合にこそ、専門家がそこに問題があれば、正しく指摘しなければなりません。


  *   これに対して、paltを有効にしないでkernだけを有効にするのではフォント制作者の意図どおり美しく読みやすい日本語テキスト表示にならないと反論があるかと思います。しかし、これまでブラウザでの日本語テキストがそのような表示であった(AppleのOSで標準的なヒラギノフォントにはpaltとkernの両方があるけどSafariもChromeもkernだけデフォルトで有効にしている)のに、多くのユーザー(とくにAppleのOSのユーザー)はそれが美しい日本語テキスト表示であると満足していたのではないでしょうか?

「す。」の字間を詰めるために、kernを有効にすることに反対はしません。しかし、paltを有効にした上でkernをかけた場合とは違って、ツメ量が期待通りにならない可能性が高くなります。「す」の両サイドのサイドベアリングがカットされないからです。そして、そのより目立たなくなったツメ量のために、そのことに気が付くユーザーがいなかったとしても不思議はないでしょう。しかし、そもそも、「す。」の字間だけを詰める場合には、他の文字間の組み合わせに対してpalt無しで有効になっているkernは意味がなくなります。なぜ、それらの文字の間は、ベタで送られる権利を剥奪されて、フォントの制作者が予想もできない詰め方で表示されなければならないのでしょうか。

どうも、問題が正しく理解されていないようです。私は、「す。」の字間のように、詰めたい文字の組み合わせに対して、それらをpaltを掛けない状態であっても、詰めて満足する結果を得ようとする行為自体を否定しているのでは、まったくありません。そのようにユーザーがペアによるツメ量を設定できる機能があれば、便利かもしれません。記事や文書の傾向ごとにその設定を切り替えられれば、さらに便利かもしれません。

しかし、そのことと、palt及びkernとは別の話なのです。なぜなら、日本語フォントの場合(あるいは和文のグリフの場合)には、kernとpaltとは相互に連関していて、kernの情報はすべてpaltの情報に依存しているからです。

このフォント中のkernとpaltの情報に内在している相互関係を無視しても良いという議論は、「設計思想」の観点からは、暴論・本末転倒でしかないと考えます。

山本
アドビ

Received on Monday, 17 April 2023 14:29:02 UTC