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

太郎さん、再度大変詳しいご説明をありがとうございます。

読んでいて、二点ほど前提が異なる点があるかもしれないと思いました。一つは、私が「カーニング」と言った時には、「特定文字間の詰めを調整する」機能全般を指しており、太郎さんは
OpenType `kern`
を指していらっしゃるのかな、と感じました。前にも書いたように、実装をどのようにするべきなのかは、私は現時点で明確な方向性は決めておりません。`chws`
や `locl` でもカーニングと同様のオペレーションを行うこともあるように、一部のカーニングを別の機能で行う、というのも候補になると思っています。

もう一つは、太郎さんが再三「ベタ組み」と「ツメ組み」の2種類に分類されていますが、「ベタ組み」には、原稿用紙や新聞で見られるようなすべての文字が全角で組まれるものと、昨今の一般書籍で見られるような、おおよそ全角送りだけれど、連続約物など一部の文字間を詰めるものと、2種類あると思っております。太郎さんのおっしゃる「ベタ組み」は前者のみを指していらっしゃるのかな、と感じました。

後者の厳密でない「ベタ組み」において、特定の文字間を詰めたい、という希望がフォントベンダーさんからあるのは、妥当だと思われませんか？
それでも太郎さんとは異なる考え方のフォントデザインかもしれませんが、要望としてある以上、却下せずに済む方法を考えようとするべきではないでしょうか？

津田さんへの返信にも書きましたが、実装レベルの話になると、より難しい話になると感じています。太郎さんのおっしゃるお話を前提として作られたフォントがあり、そうでないフォントがあります。アプリケーション側にも、その前提で組版を行っているアプリケーションと、そうでないアプリケーションがあります。そのような状況において、完全な互換性を持って全部のフォントとアプリケーションを望ましい状態に持っていくのは困難でしょう。何をどう変えれば全員にとって一番いいのか、というのを議論していければと思っています。

アプリケーション側から見ると、アプリケーションには、シェイピングを自身で行うアプリケーションと、別のコンポーネントで行うアプリケーションがあります。お話を伺っているとAdobeさんのアプリケーションは前者のようですが、他の多くのアプリケーションは後者に属します。後者のアプリケーションにとっては、幅によって適用するOpenType機能を変更する、というのは技術的困難を伴います。例えばFirefoxではその判断を断念し、解釈を変更して、CJKのグリフだったら全角でも全角でなくても
`kern` の適用はしない、という判断にしたようです。これは太郎さんのご意図とは異なりますよね？ また、太郎さんのおっしゃる「`kern` の前に
`palt`
を適用」というのも困難だと思われます。OpenType機能は、その名前のアルファベット順に適用と決まっているためです。シェイピングを自身で行っていれば、いかようにもできると思いますが、それ以外のアプリケーションにとっては、シェイピングのコンポーネントを変更しない限り変更できないロジックになります。

シェイピングのコンポーネントを変更する、と考えても、「全角幅」という条件に技術的困難があります。OpenTypeのフォントには、「全角幅」は定義されていないので、これを決めないといけません。ほとんどのフォントは正方形なので、正方形フォントに限れば可能ですが、そうでないフォントをどうするか、ということが現時点では定義されていません。

残念なお話だとは思いますが、現行の仕様のままで、アプリケーションに対して太郎さんのご説明を実装をすることは、上記の点から少し難しいと思っています。太郎さんのお考え、それ以外の方のお考えを最大限組み入れ、シェイピングが別コンポーネントのアプリケーションにも実装できる方法を考えてみませんか？

On Tue, Nov 29, 2022 at 5:40 PM Taro Yamamoto <tyamamot@adobe.com> wrote:

> 石井さん
>
>
>
>    1. まずは、既存の大多数の日本語OpenTypeフォントの実装、つまり’palt’を備えているか、’palt’と’kern’
>    の両方を備えているフォントの場合について、コメントします。
>
>
>
>    - 私は実装者であり、フォントデザイナーではないので、どちらの意見にも加担するわけではないのですが、
>
>
>
> 「全角ペアにカーニングを設定したい」という意見と、「プロポーショナルのグリフのペアにカーニングを設定したい」という二つの「意見」があるとは考えません。
>
> 二つあるのは、日本語を「ベタ組」にする必要がある用途と、「ツメ組」にする必要がある用途です。
>
> そして、二つあるものが、もう一組みあるとすれば、それはおそらく、正しく‘palt’と’kern’を両方ともを実装しているアプリケーションと、
> ’palt’を実装すべきなのに’kern’
> しか実装していない（あるいはそれらを正しく実装していない）日本語テクストを扱うには不完全なアプリケーションでしょう。
>
>
>    -
>    私は、異なる考え方は複数あってもよい、ある方が自然、と思っていますので、いずれを否定するわけでも肯定するわけでもありませんが、全角グリフにカーニングを禁止、となると、それらの方々の考え方を否定することになってしまうかと思います。
>
>
>
> （ここでは、’palt’及び、’palt’と’kern’
> の関係に限定して述べます）。個別の機能の在り方に関して、その使用目的や歴史的な開発意図を無視した考え方は、不自然であり不要です。（足りない機能があれば、既存の異なる内容の仕様をやみくもに改変するのではなく、必要な機能を追加することをご検討ください）。
>
>
>
> ‘palt’という特定の機能は、そもそも歴史的には、OpenTypeフォント以前から（1990年代前半のAdobe Illustrator
> の日本語版やAldus PageMaker
> の日本語版）で用いられていた、外部ファイルにフォントごとに固有の「仮名ツメ」情報をフォントメーカーからのライセンスを受けて収納し日本語の「仮名ツメ」あるいは「ツメ組」を実現していたものを、
> OpenTypeの情報に取り込んだものであって、それ以上でも以下でもありません。さらに、それも写真植字時代の「仮名ツメ文字盤」の機能をDTP
> で使えるようにしたものであり、まさにその考え方は、写植機の字送り機構にステッピングモーターが使われ始める1970
> 年代後半にまでおそらく遡ることでしょう。それは、デフォルトで動作する日本語の「ベタ組」とは無関係であって、明示的に「ツメ組」が指定された場合にのみ動作することが想定されています。（仮に万一、ベタ組で
> ’kern’が突然デフォルトで動作したら「どうしたらベタで組めるんだ！」と利用者は抗議の声を全国であげるのではないでしょうか）。
>
>
>
> また、’kern’
> は特定のプロポーショナルなグリフのペアに対して、そのスペーシングを補正するために用意されているものであって、そもそもプロポーショナルグリフと異なりグリフの字幅とその前後のサイドベアリングがグリフのデザインごとに最適化されていないような日本語の全角のグリフのペアを対象に動作することを本来は想定してはいません。。
>
>
>
> 20年以上にわたって用いられている日本語OpenTypeフォントの実装もまた、’palt’
> を適用することで疑似的にプロポーショナルなグリフとなり、固有の字幅とサイドベアリングをもつように転化した日本語のグリフに対して、それらの特定のペアのスペーシングを補正する目的で、
> ’kern’の値が設定されています。つまり、既存の大多数の日本語OpenTypeフォントにおいて、’palt’を有効にせずに、’kern’
> だけを有効にして得られる結果は、そのフォント／書体のデザイナーが意図したものとは全く異なる不正なスペーシング結果となるのです。
>
> アプリケーションは、まずは、’palt’を正しく実装することで問題を解決するのが、’palt’と’kern’
> というものがそもそも意図している用途と利用形態に合致する最善の方法と考えます。
> ‘palt’や‘kern’とは異なる機能が必要な場合には、まずはテキストエンジン上での機能追加で対応されることを推奨します。
>
>
> *UI suggestion:* This feature would be off by default.
>
> *Feature interaction:* . . . If 'kern'
> <https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#kern> is
> activated, 'palt'
> <https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt#palt> must
> also be activated if it exists. . . .
>
>
>
> このOpenType
> の仕様に書かれていることは「ベタ組」と「ツメ組」という、異なる日本語の字送りの二つのモードのどちらにも、「ベタ組」を基本とする原則を損なうことなく選択的に対応する上で、必要な事柄なのです。
>
>
>    - 少なくとも「す。」や他のいくつかの全角ペアにカーニングを設定したフォントを作った方々がいらっしゃる、ということは、
>    . . .
>
> 「仮名文字間は全角送りで、特定の文字間を詰めるのは自然」と考える方が一定数いらっしゃる、ということを示唆しているように思われます。
>
>
>
> 全角の「す」と「。」だけを詰めるフォントを作る方法は二つが考えられます。
>
> 一つ目の方法は、’palt’を含めず、’kern’だけを持たせる方法です。
> 二つ目は、「す」と「。」の’palt’のオフセット量をゼロに設定した上で、’kern’をもたせる方法です。
> これらについて詳しくは、次の2.で述べます。
>
>
>
>    1. 次は、’palt’を持たず、’kern’だけを持つフォントの場合です。これは、例えば、欧文グリフのペアにだけ’kern’
>    を持たせる場合が典型的な例です。「す」と「。」にだけ’kern’
>    を持たせているフォントも、この場合の一例と言えるでしょう。ただし、この場合は、以前にも述べましたが、日本語フォントの場合にはカーニングの数が膨大になる可能性があるので、あくまで例外的に少ないペアだけにスペーシング調整が必要な場合に限定されると思います。また、上述のように、
>    ’kern’は元々が欧文のプロポーショナルフォントで用いられていた機能であるため、デフォルトで’kern’
>    をかけてしまうと、「ベタ組」がデフォルトで不可能となり、書体デザインが本来想定している文字のスペーシングが、そのグリフペアが出現する場合には、デフォルトで維持できなくなります。これは、既に説明した、利用者が明示的に
>    ’palt’のオプションを指定することによってはじめて、等幅グリフをプロポーショナルグリフに転化する、という機能を割愛して、一足飛びに
>    ’kern’を適用することの欠点です。また、私は’kern’
>    だけを持つ日本語フォントをこれまで見たことも使ったこともありませんので、実際にその方法で正しく動作するのかどうかは分かりません。
>    （また、もう一つ、上述の欠点を回避する方法として考えられるのは、’palt’
>    をフォントに含めながら、そこで「す」と「。」を指定しつつ、そのオフセット値をゼロに指定し、その上で’kern’
>    を設定すれば、従来どおりの方法で、’palt’と’kern
>    ‘の両方を適用していながら、結果的には「す」と「。」は全角等幅で変化なく、それに対して’kern’
>    が適用されることになる、と予想します。ただし、そういう実装を私は見たことが無いので本当に正しく動作するかどうかは分かりません）。
>
>    とはいえ、
>    *全角の「す」と「。」だけを’kern’で詰めることのできるフォントは、’palt’を持たないフォントであれば、理論上は実現の可能性があることを示唆しています。*
>
>
>
> 上の2では、’palt’を持たないフォントについても述べましたが、
> *フォントが’palt’と’kern’の両方を持っている場合には、’kern’を適用する前に必ず’palt’を適用する必要があることに変わりありません。*
> その理由は上の1で述べました。
>
>
>
> また、先にも述べましたが、’palt’を持たず、’kern’だけのフォントが有用な場合があったとしても、そのことが
> 「全角ペアにカーニングを設定したい」という意見と、「プロポーショナルのグリフのペアにカーニングを設定したい」という二つの「意見」があることを意味するとは、私は考えません。偶然、その個別フォント開発者が調整したいペアカーニングの数が少なかったから、
> ’kern’だけで済ませることができたのであって、その’kern’
> を適用してカーニングを行った瞬間に、対象となるグリフは、もはや「全角グリフ」とは呼べなくなってしまうわけなので、基本的に、グリフのペアを詰めたくなった結果カーニングを適用するという操作自体、
> ’palt’を省略するか否かに関係なく、どちらも全角グリフをプロポーショナルグリフに転化してしまう結果を将来するわけです。したがって、そのような
> ’kern’
> だけでスペーシングを最適化したいと考えることが、「プロポーショナルのグリフのペアにカーニングを設定したい」場合と異なる動機や目的をもつものとは考えられないと思います。
>
>
>
> 以上、ご検討ください。
>
>
>
> 山本太郎
>
> アドビ
>
>
>