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

> 石井さん曰く
>> 私が議論したいと思っているのは、そうでないフォントが、多くのアプリケーションにおいてこの20年間、そのフォントの設計意図通りに表示されてきたことを踏まえ、そういったフォントの存在を確認し、存在するなら対処方法を示すことが、実装を進めるにあたって必須ではないでしょうか、という点です。

> 


私は次のように書きました：

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

私が言いたかったことは、フォント制作者の意図と違ってkernだけを有効にしてもそれなりによい結果になっていたのを、石井さんはそれがフォント制作者の意図であると勘違いしていたのではないかということです。

paltとkernの両方を持った日本語フォントで、paltを有効にしないでkernだけを有効にする前提で作られているものがあるとは考えられません。なぜならpaltとkernの組み合わせで最適になるようにkernを設定しないと、そのフォントが詰め組に対応するためにpaltとkernの両方を持っている意味がないし、もしも片方を有効にすることしか考慮されていないフォントがあったら、そのフォントは正しい詰め組の設定（paltとkern両方有効）をしたとき正常な結果にならないでしょう。

ですので、ここの認識は石井さんが間違っていると私は考えます。

しかし、「多くのアプリケーションにおいてこの20年間」フォントの設計意図通りではない表示がされてきたけど、それなりによい日本語テキスト表示になっていてユーザーは満足しているのに、それら多くのアプリケーションに修正を求めるということは無理があるのでないか、という主張であれば検討する必要があると私は考えます。

問題は個々のアプリケーションというよりも、OSの標準のテキスト表示の機能やフォントを扱うライブラリにあるかと思います。そこでOpenType/OFF仕様の "If 'kern' is activated, 'palt' must also be activated if it exists." がサポートされないかぎり、個々のアプリケーションにそのサポートを求めても実現が難しいでしょう。また、もしもOSやライブラリが修正されて、正しい仕様に沿う動作（例：ペアカーニングを有効にしようとしても、ペアのグリフの少なくともどちらかにpaltが設定されているならpaltを有効にしないかぎりkernを有効にしない）に変わったら、日本語テキストの表示がそれまでと違う結果になるので互換性の問題が生じます。

発生する互換性の問題としては、それまで仮名文字のペアカーニングがデフォルトで効いていたのが効かなくなることで、ある領域に収まっていたテキストが収まらなくなりオーバーフローして読めなくなるなどです。これは和欧文間スペースがデフォルトで入ることになることでの互換性の問題とも同じことですが、和欧文間スペースの場合はそれによって読みやすさが改善するというメリットがあるのに対して、仮名文字のペアカーニングがデフォルトで効いていたのが効かなくなることのメリットがそれほどあるのかどうかが問題です。

現状のAppleのOSなどの標準の日本語テキスト表示は、paltを有効にしないでkernだけを有効にするものですが、それなりによいテキスト表示結果になっていると思います。完全なベタ組で仮名文字が全角固定ピッチで表示されるよりも、むしろ好ましいといえるかもしれません。フォント制作者の意図ではkernはpaltの詰め組みのためものだとしても、それを全角固定ピッチに適用すると少し補正されたべた組という結果になって、そんなに悪くはない気もします。

設計者が意図していない間違った使われ方がされて、それが案外役に立って普及してやがて標準になるということはあるものだと思います。


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



> 2023/04/18 9:28、木田泰夫 <kida@mac.com>のメール:
> 
> 
> 石井さん曰く
>> 私が議論したいと思っているのは、そうでないフォントが、多くのアプリケーションにおいてこの20年間、そのフォントの設計意図通りに表示されてきたことを踏まえ、そういったフォントの存在を確認し、存在するなら対処方法を示すことが、実装を進めるにあたって必須ではないでしょうか、という点です。
> 
> そのようなフォントが実際に存在して重要なら、それらが仕様に沿っているかどうかの議論と関係なく、より良い対処方法を示すのが必要なことに全く同意です。
> 
> そのためには、兎にも角にも、どのうな設計のフォントがあるかの調査が必要でしょう。それをしましょうよ。
> 
> どのように行うのが良いでしょう？ CITPC? Nat/太郎さん？ 石井さん？
> 
> 
> どのような設計のフォントがあるのかを確認できたら、それらを仕様として追認するか、どう解決するのが良いかという議論ができます。OS付属のフォントのようにアップデート容易なら、フォントのアップデートが解の可能性もあるかもしれません。仕様を追認するのが良いとなった場合は、それらは存在していることがわかっているフォントと異なる設計で動いているので、それぞれが新たな仕様となりますし、現在あることがわかっているフォントに対する仕様の明確化とは独立に議論できます。また現在バラバラなアプリケーション側の動作を複数のフォント仕様にどのように対応させるかの議論が必要ですね。
> 
> 木田
> 
>> 2023/04/18 0:03、Koji Ishii <kojii@chromium.org>のメール:
>> 
>> そうですね、論点がなかなか揃わないですね。どうしたらいいでしょうか。太郎さんやNatの設計思想に沿って作られたフォントを否定しているわけではないことはご理解いただけているかと思います。
>> 
>> 私が議論したいと思っているのは、そうでないフォントが、多くのアプリケーションにおいてこの20年間、そのフォントの設計意図通りに表示されてきたことを踏まえ、そういったフォントの存在を確認し、存在するなら対処方法を示すことが、実装を進めるにあたって必須ではないでしょうか、という点です。壊すかもしれないし、壊さないかもしれない、と言われて、20年の実装を変更できる実装者は、多くはないと思いますので、仕様を明確化されても、困るだけで、実装が進むわけではありません。
>> 
>> その上で、「その調査と議論が進むまで、現仕様の明確化を遅らせる」オプションと、「とりあえずの仕様の明確化を行い、その後に調査する」オプションを比べると、前者のほうが妥当に思えるため、村田さんのご提案には反対しています。
>> 
>> 
>> On Mon, Apr 17, 2023 at 11:43 PM Nat McCully <nmccully@adobe.com <mailto:nmccully@adobe.com>> wrote:
>>> If it is true that there are major engines applying only kern to CJK fonts and text, those engines will not behave according to the font maker’s desire. I am extremely surprised people are saying Safari and some Windows apps only apply kern to cjk text (and by default, too!) Most cjk fonts, especially those used outside professional print publishing, have no kerning info in the cjk section and so such apps may have got away with it for years. But now that professional quality fonts with kana and punctuation kerning pairs are available to the web and on all platforms, one can only look at the result of such engines and say this is not correct and only contributes to the poor impression experts have about the state of cjk typography in digital media. Why we think it is reasonable to further support such basic mistakes in implementation is beyond my understanding. 
>>> 
>>> —Nat
>>> From: Taro Yamamoto <tyamamot@adobe.com <mailto:tyamamot@adobe.com>>
>>> Sent: Monday, April 17, 2023 7:28:52 AM
>>> To: Shinyu MURAKAMI <murakami@vivliostyle.org <mailto:murakami@vivliostyle.org>>; Koji Ishii <kojii@chromium.org <mailto:kojii@chromium.org>>
>>> Cc: 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>; JLReq TF 日本語 <public-i18n-japanese@w3.org <mailto:public-i18n-japanese@w3.org>>
>>> Subject: 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の情報に内在している相互関係を無視しても良いという議論は、「設計思想」の観点からは、暴論・本末転倒でしかないと考えます。
>>> 
>>>  
>>> 山本
>>> 
>>> アドビ
>>> 
>>> 
>