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

On Tue, Apr 18, 2023 at 1:35 PM Atsushi Shimono (W3C Team) <atsushi@w3.org>
wrote:

> shimonoです
> コメントありがとうございます。
> "実装としては"フォントごとにon/offではなくグリフ単位で付随情報（という単語が正しいかはわかり
> ませんが、palt/kernなどの他テーブルの意味のつもりです）を集約してグリフ（と前後の関係も見なが
> ら）個別に適用条件を参照して整約している、という理解をいたしました。
>

ん～、ちょっと理解をした内容をきちんと理解した自信がなく...笑 補足しておきます。

シェイプエンジンには、おおまかに以下の入力があります。

   - フォント
   - Uicode文字列
   - スクリプト
   - オンにするfeatureのリスト

まず、文字列を、cmapを使って、グリフIDのリストに直します。シェイプエンジンの中では、入り口以外、ほぼグリフIDだけで動作します。

次に、featureのリストから、パイプラインを作ります。kernとpaltがオンならこの2つですが、他にも指定されたfeatureとか、デフォルトオンのfeature（clocとかcaltとかligaとかですね）がパイプラインに積まれます。このパイプラインに

   - グリフID
   - グリフごとの位置とメトリックス

の配列を渡すと、GSUBならグリフIDの置き換え、GPOSなら位置とメトリックスが修正されたものが出力されて、この結果がアプリケーションに返ります。

パイプラインは最適化されることが多く、例えばグリフIDを5回に渡って置換するのであれば、5回分のパイプラインを事前計算した1つのパイプラインを作っておけば、速くなるため、最適化しているエンジンは多いと思います。このため、既存のテーブルの組み合わせで新しい機能を入れるのは簡単（簡単というよりも、シェイプエンジンへの変更は必要ないことが多い）ですが、テーブルの種類の追加や変更は、複雑な作業になることが多いです。

あ、、、言葉足らずでした。
> この図などで、すでにScript/Languageという概念があると思っていたのですが、村田さんのメールで
>
> https://lists.w3.org/Archives/Public/public-i18n-japanese/2023AprJun/0043.html

> > 入れると規定が一気に難しくなる(Unicodeのコードポイントやgrapheme clusterの話なのかOFF上にグ
> > リフがCJK全角であるという概念を定義するのか）ので入れたくありません。
> というのがあり、scriptという概念がすでにあるなら追加定義はそこまで大きいものでもないのではない
> か？と疑問に思ってました。
>

シェイプエンジンでやる前提で考えれば、スクリプトがインプットにあるので、おっしゃるとおり、CJKの判定は簡単です。ただこれもちょっとトリックがあって、記号類が対象になっているとちょっと厄介です。

シェイプエンジンの入力にスクリプトが必要なため、アプリケーションは、元文字列をスクリプトによって分割してから、シェイプエンジンに渡します。ここのロジックは、前に書いたように標準化されていませんが、殆どの場合、
UAX#24 <http://unicode.org/reports/tr24/>に沿っていると思われます。UAX#24のデータファイル
<https://www.unicode.org/Public/UNIDATA/Scripts.txt>
でCommon、Unknown、Inheritになっている部分は、UAX#24でも未定義なのです。「前後の文字によりヒューリスティック」とだけ定義
<http://unicode.org/reports/tr24/#Common>
されています。このヒューリスティックは、各社それぞれなので、互換性があまり取れていません。

例えば、中黒を考えると、前の文字のスクリプトを使う、というロジックを使った場合、「あ・」の中黒はkanaですが、「pen・」の中黒はlatnです。前と後ろを両方見るヒューリスティックもありますし、閉じカッコは対応する開きカッコと対応させるヒューリスティックもあり、シェイプエンジンやフォントから見ると、どのスクリプトで入ってくるかわかりません。わからないので、フォント製作者は、記号を含む日本語機能をLatinやGreekにも入れる必要があるのですね。

まとめると、今後、Adobeさんから教えてもらうロジック次第ですが、シェイプエンジンでやる前提で考えれば、その対象文字にCommon/Unknown/Inheritが含まれないなら、CJK判定は簡単になります。スクリプト判定が標準化されていない問題は、現実としては残りますが、仕様範疇外になるからです。含まれるとしたら、、、ちょっとどうしたらいいかすぐにはわからないので、そうと分かってから考える感じです。

シェイプエンジンでやるとすると、全角判定のほうが難しいかもしれないです。アプリケーションのほうが上位の情報を持っているので。CSSのように、特定文字をピックして、ヒューリスティックでやるんでしょうかね。
以前に私がフォントの中だけで全角判定した時
<https://github.com/kojiishi/east_asian_spacing/blob/main/east_asian_spacing/config.py#L41>
には、7文字ピックアップしてヒューリスティックしましたが、fonts.google.comにある50個くらいのフォント
<https://fonts.google.com/?subset=japanese&noto.script=Jpan>
だけでもうまくいかないフォントがあって、フォントごとの設定を入れた記憶があります。これも、きちんと仕様化しましょう、という合意が取れたら、深く考える必要があると思っています。