Re: CJKフォントのpalt（詰め組）とkernの関係

> 石井さんの主張で理解できなかったのは、paltとkernの両方を持った日本語フォントで、paltを有効にしないでkernだけを有効にする前提で作られているものがあると主張されていたことです。これは、フォント制作者の意図は両方を有効にしたとき最適な詰め組みになるようにということであっても、その意図と違ってkernだけを有効にしても「す。」などが少し詰められて、それなりによい結果になっていたということではないかと思います。それで多くの人が満足していたのに修正する必要はないというのは一理あります。


おっしゃるように、石井さんの主張されているのは、従来の仕様に加えて、そのような新たな仕様を追認しようということなのかな、と感じます。具体的には知りませんが、そのようなフォントが実際にある、と。

その場合、フォントの設計意図をどのようにアプリケーションに伝えるかが問題になりますかね？

> それが美しい日本語テキスト表示であると満足していたのではないでしょうか？

三者三様の実装で大きな問題にならなかったのは、おそらく web の読者が求める精度と比べて違いが微妙だったんでしょうね。電子書籍ではどのようになってるんでしょう？

木田

> 2023/04/17 19:48、Shinyu MURAKAMI <murakami@vivliostyle.org>のメール:
> 
> 石井さん：
> 
>> 現在の仕様が曖昧なため、Windows/macOSや既存アプリケーションの多くが、20年以上これに沿わない実装をしてきました。
>> 
>> 仕様を改善することは好ましいのですが、仕様と実装の乖離が20年以上ある時に、大元の問題を解決せず、仕様文面だけを改善するのは、これらの実装がより難しい立場になるだけで、状況を改善するとは思いません。実装者をより難しい立場にするだけの仕様の改変には反対です。
> 
> 
> なるほど、ブラウザだけでなく多くの既存アプリケーションがOpenType/OFF仕様の "If 'kern' is activated, 'palt' must also be activated if it exists." を無視した実装をしてきたということですね。
> 
> paltとkernの両方を持った日本語フォントの開発者は、kernはpaltとの組み合わせで使われる前提で設計しているとしても、アプリケーション側ではpaltを有効にしないでkernだけを有効にすることが普通に行われていて、それに対してユーザーからのクレームはなかったのだろうと理解できます。
> 
> 石井さんの主張で理解できなかったのは、paltとkernの両方を持った日本語フォントで、paltを有効にしないでkernだけを有効にする前提で作られているものがあると主張されていたことです。これは、フォント制作者の意図は両方を有効にしたとき最適な詰め組みになるようにということであっても、その意図と違ってkernだけを有効にしても「す。」などが少し詰められて、それなりによい結果になっていたということではないかと思います。それで多くの人が満足していたのに修正する必要はないというのは一理あります。
> 
> そうするとOpenType/OFF仕様の "If 'kern' is activated, 'palt' must also be activated if it exists." を明確化するというのではなくて、kernだけを有効にすることを許容する仕様に改めたほうがよいのかもしれません。
> 
> これに対して、paltを有効にしないでkernだけを有効にするのではフォント制作者の意図どおり美しく読みやすい日本語テキスト表示にならないと反論があるかと思います。しかし、これまでブラウザでの日本語テキストがそのような表示であった（AppleのOSで標準的なヒラギノフォントにはpaltとkernの両方があるけどSafariもChromeもkernだけデフォルトで有効にしている）のに、多くのユーザー（とくにAppleのOSのユーザー）はそれが美しい日本語テキスト表示であると満足していたのではないでしょうか？
> 
> どうも考え直す必要がありそうです。
> 
> 
> ----
> 村上 真雄 (MURAKAMI Shinyu)
> Vivliostyle Foundation
> 
> 
>> On Apr 17, 2023, at 17:35, Koji Ishii <kojii@chromium.org> wrote:
>> 
>> On Mon, Apr 17, 2023 at 5:28 PM 木田泰夫 <kida@mac.com <mailto:kida@mac.com>> wrote:
>>> いいえ、具体的な問題がない限り、期待される仕様と異なるフォントが「あるかもしれない」というイマジナリーな話をする価値はないと思います。
>>> 
>>> 仕様を固めて、もしそれと異なる実装が、実利上、無視できないとしたら、それは実装上もしくは何らかの対処が必要な課題ですが、仕様の問題ではありませんよね。
>> 
>> 現在の仕様が曖昧なため、Windows/macOSや既存アプリケーションの多くが、20年以上これに沿わない実装をしてきました。
>> 
>> 仕様を改善することは好ましいのですが、仕様と実装の乖離が20年以上ある時に、大元の問題を解決せず、仕様文面だけを改善するのは、これらの実装がより難しい立場になるだけで、状況を改善するとは思いません。実装者をより難しい立場にするだけの仕様の改変には反対です。
>