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

Ishii-san,


  *   読んでいて、二点ほど前提が異なる点があるかもしれないと思いました。一つは、私が「カーニング」と言った時には、「特定文字間の詰めを調整する」機能全般を指しており、太郎さんは OpenType `kern` を指していらっしゃるのかな、と感じました。

‘kern’について述べているのは、’palt’と’kern’を用いて特定グリフ間のスペーシングを調整する実装が多くあるために、その定義や解釈を変更できないからです。20年以上にわたって、アドビだけでなく、他のフォントメーカーからリリースされてきたCFFベースの日本語OpenTypeフォントの実装の多くが、’palt’と’kern’によって、「特定グリフペア間のスペーシング」の自動調整を行ってきました。その定義と解釈を変更することはできません。新しい機能が必要であれば、新しい要素を追加する必要があります。


  *   前にも書いたように、実装をどのようにするべきなのかは、私は現時点で明確な方向性は決めておりません。`chws` や `locl` でもカーニングと同様のオペレーションを行うこともあるように、一部のカーニングを別の機能で行う、というのも候補になると思っています。

新しい実装方法の提案は、それはそれとして議論する必要なことがあると考えますが、既存の実装に深刻な影響を与える定義や解釈の変更は不可能です。また、アプリケーション側で、既存のフォントの実装とその動作に影響を与えることなく、類似の機能を独自に実装することは、それでそれで可能かもしれません。


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

それは誤解では。「ベタ組み」であっても、どんなスペーシング調整であろうと、必要ならやればいいのですし、可能です。実際、JIS X 4051が定めるような前後関係に依存した（context-dependentな）日本語特有のスペーシングは、行われて当然です。しかし、その前提となっているのは、漢字と仮名は全角であり（この全角ボディの形自体がコンデンストであったり矩形になる場合は複雑になるのでここでは割愛しますが、フォント内のボディの寸法情報を用いることで対応可能でしょう）、約物類は（フォント内では全角字幅で実装され）組版時には半角として取り扱うということです。この前提が崩れてしまうと、どんなスペーシングを適用するにしても、「ベタ組み」さえ、不可能になってしまいます。また「す」と「。」を-50/1000 em詰めたい、としたとき、それを実現できるのは、「す」と「。」が全角字幅をフォント内のグリフはもっている、ということが既知であるためです。そして、それが既知であることは、フォントがデフォルトの状態では（つまり何らアプリケーションがスペーシングを適用しない場合には）「す」も「。」も全角の字幅をもっていなければならないのです。それによって、アプリケーションは正しく、前後関係に依存して、連続する約物や括弧類を詰めてスペーシングすることができるのです。私はあくまで、フォント側のデフォルトの字幅は改変されてはならないということであって、「ベタ組み」であろうとなかろうと、アプリケーション側はどのようにでもグリフのスペーシングをすることは可能です。

前回書きましたが、別に’palt’を使わずに、「す」と「。」を’kern’で直接詰めるようなフォントは禁止されていませんし、可能でしょう。しかし、デフォルトで詰めるべきではないでしょう。それは、利用者が「す」と「。」とが詰まっていない、至極自然な日本語フォントの配列を行うことを不可能にしてしまうからです。また、同じく前回書きましたが、’palt’と’kern’を使っても、「す」と「。」のペアだけを詰めることは可能でしょう(‘palt’のオフセット値をゼロにすれば)。この場合には、明示的に’kern’を使いたいときに両方をONにすればよいのです。


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

「特定の文字間を詰めたい、という希望がフォントベンダーさんからある」なら、上の２つの方法を用いて、どちらが現在のアプリケーションで有効になるかを調べれば済むだけではないのでしょうか？　前回のメールでもこの2つの方法については述べました。’palt’ + ‘kern’の定義や解釈を変更する必要なく、実現できているのでは？　なぜ、それが上手くいかないのでしょうか？　誰も、却下なんかしていません。’kern’を有効にする場合に’palt’も有効にする必要があるのは、’palt’がある場合だけでしょう？　‘palt’がないフォントなら’kern’だけ有効にできるはずです。’palt’があるのに’kern’だけを用いる用途は、’palt’の用途・目的の範囲外です。しかし、’palt’が無い場合には、’kern’だけを持つことは可能です。


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

既存の実装の安定した動作を保証するためには、変えてはならない定義や解釈や慣行は、変えてはなりません。特に字幅とスペーシングに影響を与える要素は、行長・行数・ページ数に影響を与えるため、印刷事故を防ぐために、不必要な変更は極力避ける必要があります。（機能や要素の追加はもちろんOKですが）。


  *   また、太郎さんのおっしゃる「`kern` の前に `palt` を適用」というのも困難だと思われます。

この順番は、タイポグラフィックな動作を説明するのに自然な順番なのでそうしているだけです。どちらにしても仮想ボディの移動量の総和は変わらないので、’kern’が先でも正しく実装可能では。念のため、仕様に’kern’と’palt’の相互関係が明示的に記述されているのですから。


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

今後、日本語フォントにおけるボディの概念を全角や半角以外に一般化することは可能と考えますが、そのことによって、’palt’と’kern’の現在の定義や解釈が変わるとは思いません。なぜなら、’palt’も’kern’も仮想ボディ（または仮想の疑似的なプロポーショナルボディ）の各辺からの相対的なオフセット量を定めているだけだからです。ボディの形状の変化にも対応可能と考えます。

山本太郎