* OpenType と shaping [14] [[OpenType Layout]] では [[shaping]] によって[[フォント]]から探索する[[文字]]や適用するべき[[機能][フォント機能]]を決定するという想定になっています。 [SRC[>>13]] [15] [[OpenType]] で扱うのは[RUBYB[低水準][low-level]]の[[機能][フォント機能]]だけで、 [[shaping]] の詳細は[[仕様書]]の[[適用範囲外]]とされています。 [SRC[>>13]] [20] [[OpenType]] は多数の[[機能][フォント機能]]を利用可能としていますが、 それら (の [[lookup]]) は同時適用もできますし、分けて適用もできます。 どの機能 (の [[lookup]]) をどのタイミングで適用するか、 その適用と適用の合間に[[グリフ]]列を入れ替える等の操作をするかは、 [[OpenType]] 仕様としては定めない (が多くの[[用字系]]ではそのような操作が必要となる)、 とされています。 [SRC[>>19]] [16] [[OpenType]] [[フォント]]ファイルに格納されるのは [[shaping]] された結果から[[グリフ]]への対応関係なので、 外部から与えられた[[Unicode文字列]]から [[shaping]] された結果への変換方法 (つまり [[shaping]] の方法) が決められないことには[[フォント]]の[[相互運用性]]は保証されないと言わざるを得ません。 つまり [[OpenType]] 仕様は[[相互運用性]]を半ば放棄しているようです。 [21] [[OpenType Layout]] では特定の[[フォント]]の[[グリフ]]固有の情報を[[機能][フォント機能]] / [[lookup]] として格納し、[[言語]]や[[用字系]]の共通の情報は[[フォント]]に入れずに実装側で持つ、 としています。 [SRC[>>19]] 妥当な設計方針でしょう。問題はそれが[[文字のレンダリング]]の実装にも[[フォント]]開発にも必須の情報なのに仕様外とされていることです。 [17] [[Windows]] は [[Uniscribe]] で [[shaping]] を実装しています。 [[Uniscribe]] は[[独占ソフトウェア]]ですが、その処理の概要は公式サイトに載っていますし、 おおむね [CITE[The Unicode Standard]] に従っているようなことが書かれています。 その情報と実在の[[フォント]]ファイル、それに [[Windows]] その他の実装から挙動を推測するしかありません。 [REFS[ - [13] [CITE@ja-jp[OpenType specification overview (OpenType 1.9) - Typography | [[Microsoft]] Docs]], [[PeterCon]], [TIME[2022-08-27T13:06:23.000Z]] - [19] [CITE@ja-jp[OpenType layout common table formats (OpenType 1.9) - Typography | [[Microsoft]] Docs]], [[PeterCon]], [TIME[2022-08-29T14:14:32.000Z]] ]REFS] * Uniscribe の処理モデル [2] [[Uniscribe]] は[[用字系]]ごとに [DFN[shaping engine]] を持っています。 [SRC[>>1, >>3]] [6] また, 特別に対応していない[[用字系]]用の [[OpenType Layout]] [[shaping engine]] も持っています。 [SRC[>>1]] [4] [[Uniscribe]] は入力の[[文字列]]を[[項目]]群, [[連なり]]群, [[クラスター]]群の3階層に分割します。 [SEE[ [[連なり]] ]] [5] [[クラスター]]は[[用字系]]によって決まる、[[文字]]群の基本的な要素です。 [SRC[>>3]] [[Unicode]] でいう[[書記素クラスター]]に近い単位と思われますが、 同じかどうかは不明。 [7] [[Uniscribe]] は[RUBYB[文字の前処理][character preprocessing]]も行います。 入力 ([[Unicode]] の[[文字列]]) は[[論理順]]になっていますが、 前処理で[[グリフ]]処理に都合の良い順序に並べ替えます。 具体的には [[Unicode]] の規定によります。 [SRC[>>3]] [EG[ [8] 例えば[[基底文字]]の左右に[[結合文字]]が表示されるような場合でも [[Unicode]] では必ず[[基底文字]]が先になりますが、 ここで左、[[基底文字]]、右の順序に並べ替えたりすることがあります。 ]EG] [11] [CODE[GSUB]] を駆使すれば文字前処理の並べ替えをしなくても[[フォント]]側で[[グリフ]]決定をすべて行うこともできるのでしょうが、 それでは[[フォント]]開発が大変になるようです。 文字前処理があるので[[フォント]]開発で複雑な条件をたくさん記述しなくてもよいのです [SRC[>>3]]。 ;; [12] そのかわり [[Uniscribe]] 相当の [[shaping]] をしていなかった古い実装で [[shaping]] 前提の[[フォント]]を使っても正しく表示されないのです。 [9] 結果得られた[[Unicode文字]]の列が [[OTLS]] に渡されます。 適宜[[機能][フォント機能]]を適用します。 [SRC[>>3]] [EG[ [10] 例えば[[アラビア文字]]の場合は[[単語]]の単位を検出して、 [[語頭形]]、[[語中形]]などを表す[[機能][フォント機能]]を各[[クラスター]]に適宜指定することになります。 ]EG] [REFS[ - [1] [CITE@ja-jp[OpenType development (LEGACY INFORMATION) - Typography | Microsoft Docs]], [[nihar]], [TIME[2022-08-27T06:22:28.000Z]] - [3] [CITE@ja-jp[OpenType glyph processing (part 1) - Typography | [[Microsoft]] Docs]], [[alib-ms]], [TIME[2022-08-27T07:59:48.000Z]] ]REFS] * 用字系との関係 [26] [[shaping]] は[[用字系]]単位で実装されるようです。 [SEE[ [[連なり]] ]] * 歴史 [58] [[タグ文字]]による指定を [[character shaping]] に影響する指定に使える可能性があるとされていました。 * メモ [18] [CITE[HarfBuzz Manual: HarfBuzz Manual]], [TIME[2022-07-31T13:57:21.000Z]], [TIME[2022-08-28T13:56:02.521Z]] [24] [CITE@en[GitHub - harfbuzz/harfbuzzjs: Providing HarfBuzz shaping library for client/server side JavaScript projects]], [TIME[2022-08-29T14:25:23.000Z]] [22] [CITE@en[GitHub - prezi/harfbuzz-js: JavaScript port of the HarfBuzz OpenType text shaping engine]], [TIME[2022-08-29T14:23:59.000Z]] [23] [CITE@en[GitHub - simoncozens/crowbar: A text shaping debugger]], [TIME[2022-08-29T14:25:01.000Z]] [25] [CITE@en[Crowbar]], [TIME[2022-07-22T22:05:22.000Z]], [TIME[2022-08-29T14:30:50.604Z]] [27] [CITE@en[GitHub - n8willis/opentype-shaping-documents: Documentation of OpenType shaping behavior]], [TIME[2023-11-06T08:53:06.000Z]]