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

石井さん


  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’だけでスペーシングを最適化したいと考えることが、「プロポーショナルのグリフのペアにカーニングを設定したい」場合と異なる動機や目的をもつものとは考えられないと思います。

以上、ご検討ください。

山本太郎
アドビ