font-kerning (CSS)

[2] CSS Fonts Module Level 4, , https://drafts.csswg.org/css-fonts/#font-kerning-prop

[6] OpenType との対応関係は、 horizontal typographic mode と sideways typesetting においては kern, upright typesetting においては vkrn とされています。 >>2

kern, vkrn 機能 (OpenType)

[3] GPOS 機能フォント機能: kern (横書き用), vkrn (縦書き用)

[5] 似たものとして chws というのがあって、 そちらは全角幅でデザインされてるグリフを半角に変更します。 全角文字が全部全角になってる等幅フォント的なものがベースになってる前提で、 カーニングと同じような結果になります。 kern と chws に同じ lookup を割り当てているフォントもあります。

[37] 関連: 結合文字

kern 表 (OpenType)

[17] kern 表OpenType表はフォント中のグリフの文字間のスペース付けinter-character spacingを制御するものです。 >>16

[8] OpenType フォントに KERN 表と GPOS のカーニングの両方を入れることもできます。 >>7

[19] CFF outline の OpenType フォントでは kern は使うことができません。 GPOS を使わなければなりませんmust。 >>16

[20] データ構造的には使えないことはないのですが、 CFF が導入されたのと同時に GPOS が導入されたので、 それ以前から存在したものの GPOS と重複する kern は利用しないことに決めた、ということなのでしょう。

[9] 応用はどちらでも好きな方を使えます。 >>7 しかし GPOS の方が新しく高機能で、そちらが好ましいようです。

[18] OpenType 仕様書は、対象の組と値を返すだけで、 システムレベルでは対応していない >>16 と述べています。 Microsoft の仕様書なので、 Windows の実装ではそうだという意味でしょう。

[10] KERN 表の方は応用の対応が進めば実質的に廃止obsoleteなもの >>7 という扱いになっています。

[11] 後方互換性のため GPOS が使えればそちらを、なくて kern があればそちらを、と実装するのがいいのでしょう。

[15] OpenType は TrueType 由来の kern 表OpenType表を規定しています。 他の章で KERN 表OpenType表を参照していますが >>7、 どこでも規定されていません。

[12] 現在の実装状況からすればフォント側は GPOS にだけ入れておけば十分とも思われます。

[21] kern 表OpenType表には部分表を何個か含めることが出来ます。 各部分表による調整は追加されていきますadjustments are additive。 >>16

[22] 従って部分表の順序は重要ではないとされます。 ただし最小値は他の部分表の効果を制限すべく普通は最後に置くべき[shouldだとされます。 >>16

[33] 部分表の coverage の第3ビット override により、 それまで蓄積accumulatedされてきた指定が上書きされます。 >>16

[23] 分かったようで分からない規定です。 順序は重要ではないといいながらも、 最小値が最後にあるべきだということやリセットができるということは、 やはり最初から順に処理されるものだということでいいのでしょうか。 部分表が加算的であるとはどういうことでしょう。 カーニング値 (スペース調整量) が同じグリフの組に対して複数回指定できるということでしょうか。 その時は調整量が加算されていくのでしょうか。それとも後の方で上書きされるのでしょうか。 あるいは同じグリフの組への適用は想定していなくて、 異なるグリフの組への調整をすべて拾っていくという意味なのでしょうか。

[24] OpenType では部分表は、 format 0 と format 2 があります。 >>16

[25] Windows は部分表 format 0 にだけ対応しています。 >>16

[26] 部分表では左グリフと右グリフの組に対して値を設定できます。 >>16

[29] グリフの組は左と右で指定されます。これは文字通り物理順と考えて良いのでしょうか。

[30] GPOS は左、右という言葉を使わず、 論理順だと明記されています。

[31] 部分表の coverage の第0ビット horizontal により、 水平方向 (1) か垂直方向 (0) かを指定できます。 >>16 やや不明瞭ですが、 横書きhorizontal text用か縦書きvertical text用かの区別と思われます。

[32] しかし縦書きで左、右は意味がわかりません。 やはり論理順と解するべきなのでしょうか?

[34] 部分表の coverage の第2ビット cross-stream により、 垂直perpendicular方向の指定 (1) かそうでないか (0) を指定できます。 ここでいう垂直とは、 横書きなら正値で上向きに kern、負値で下向きに kern され、 縦書きなら正値で右向きに kern、負値で左向きに kern されます。 >>16

[35] この状況でいう kern がどういう操作か不明瞭ですが、 一方 (どっち?) のグリフを指定された方向に移動させるということでいいのでしょうか?

[31] 部分表の coverage の第1ビット minimum により、 カーニング値kerning value (0) または最小値minimum value (1) のどちらであるかが決まります。 >>16

[27] カーニング値は、文字間スペース付けを調整します。 >>16

[28] 最小値は、 kerning と tracking の組合せにより scaler が適用する調整の量を制限します。 >>16

[14] グリフ位置決定も参照。

フォント機能 kern (OpenType)

[69] OpenType のフォント機能 kern は、 Kerning です。 >>68

[70] 横書き文配置horizontal text layout (横組) において、 グリフの組合せの間の間隔spaceの量amountを調整してグリフの間の間隔付けspacingを見かけ上optically一貫consistentさせるために使います。 よく設計された書体well-designed typefaceは全体としてoverall一貫したグリフ間の間隔付けinter-glyph spacingを有するものではありますが、 グリフの組合せによっては可読性legibilityの改善のために調整adjustmentが必要になります。 >>68

[78] 「To」の o を左にずらして配置するために kern を使うことができます。 >>68

[71] kern では水平方向horizontal directionの標準的な調整standard adjustment の他に、

... もできます。 >>68

[75] kern は縦書き文配置vertical text layout (縦組) での利用は想定していません。 縦組では vkrn を使います。 >>68

[77] kern は利用者userが上書きoverridden可能canな意図した間隔付けの調整intended spacing adjustmentsにのみ使うべきです。 利用者の制御user control下になく必須の間隔付けの調整required spacing adjustmentsには dist を使うべきshouldです。 >>68

[80] kern は、 グリフ metrics が可変幅proportionalに調整される機能が適用できる場合を除き、 固定幅グリフfixed-width glyphsに kerning 調整を適用するべきではありませんshould not。 新しいフォントnew fontでは、 既定の状態で固定幅default fixed-width metrics であり可変幅proportional widthsになるよう調整されたグリフの kerning は、 kern ではなく apkn によるべきですshould。 >>68

[89] kern は、 固定長fixed-width metrics となる機能: chws, fwid, halt, hwid, qwid, twid, tnum と組み合わせるべきではありませんshould not。 文章の連なりtext runにおいてこれらが有効とされたとき、 kern は無効とするべきですshould。 >>68

[90] これが著者に対する要件なのか文字のレンダリングの実装に対する要件なのかよくわかりません。

[91] kern は pkna, pwid と併用でき、 それらが文章の連なりtext runにおいて有効とされたとき、 既定でまたは利用者の好みpreferenceにより kern も有効とできますmay。 >>68

[83] ほとんどmostの横書き文配置では kern を既定の状態で有効active by defaultにするべきshouldです。 >>68

[85] ただし CJK 文textの場合、 文章の連なりtext runが palt を実装するフォントで書式付けformattedされている場合、 palt 機能も有効である場合を除き、 kern は palt lookup で覆われるcoveredグリフに対して既定の状態で有効にするべきではありませんshould not。 なぜならば、 palt で覆われるグリフは既定の状態で固定幅fixed-width metrics を持つのであり、 kerning 調整を適用するのは不適切であるからです。 >>68

[87] 応用は、既定の状態で有効にする対象外となるべきグリフを特定するために palt lookup の coverage 表を走査することができます。 あるいはそのかわりに、 Unicode文字の East_Asian_Width が Wide か Fullwidth であれば palt を実装するフォントにおいて既定の状態で固定幅fixed-widthの metrics を持つものとみなしても構いませんmay be assumed。 >>68

[88] しかしながら、フォントが palt と apkn の両方を実装する場合には、 kern をすべての横書き文horizontal textに適用できます。 >>68

[93] 仕様書のこの部分の規定は非常にわかりにくく、冗長な反面、表現に一貫性がないなど文意が必ずしも判然としないところがありますが、 要するに固定幅フォントに対して kern がどう適用されるべきかについて、 古い実装やフォントが混乱した状態だったのでしょう。

[94] それに対して新たに apkn を追加したり、仕様書に規定を追加したりと手当てしたものの、 既存の実装の挙動を正確に記述するでもなく、新しい実装に対する要件を完璧に規定するでもない、 中途半端で曖昧な文言にしてしまったということだと思われます。

[95] 適用するでもない palt を lookup するというのは他にないおかしな操作です。 その代替として提示される Unicode文字の情報を使うというのはもっとおかしな操作です。 正気とは思えませんが、そういう実装がどこかにあるのでしょう。 (EAW が曖昧幅の文字はどうなるのかとか、 cmap から直接ではなくフォント機能による GSUB を経由したグリフでおかしくならないのかとか、 気になることはいろいろあります。)

[92] いずれの事由にせよ kern が文章の連なりtext runに対して既定で適用されるときは、 利用者がこれを無効にすることもできるべきですshould。 >>68

[86] kern は文書のマーク付け, 利用者の制御, その他応用依存の方法でグリフの連なりに対して適用するかどうか指定させられます。 >>68

[84] 応用は、利用者に kern の有効・無効に加えて更に特定の手動の調整を行わせる手段を提供できます。 >>68

[79] GPOS lookupType 2, 8 が推奨recommendedされています。 2 のとき、2つ目のグリフの配置調整は行わないことが推奨recommendedされます (0 に設定するべきですshould)。 >>68

[82] 2 の仕様では、こうすることでグリフ列の前から順のすべての組合せに調整を適用できます。 2つ目のグリフの配置が調整されると、2つ目のグリフとその次のグリフの組合せでの調整が行われません。

[76] 2つ超のグリフの連なりに対して lookup を適用することもできます。 >>68

[81] その他の GSUB, GPOS が禁止されているわけではありません。

apkn 機能 (OpenType)

[42] フォント機能 apkn は、 Kerning for Alternate Proportional Widths とされています。 >>41

[43] 既定では固定fixedの前進幅を持つグリフが palt によって可変幅proportional widthに調整されているときの字間調整kerning adjustmentを行うものです。 >>41

[44] そのようなグリフは kern によって字間調整kernedしないことが強く推奨strongly recommendedされます。 apkn によってのみ字間調整kernedされるべきですshould。 >>41

[46] CJK フォントが主対象ですが、それ以外でも使えます。 >>41

[45] palt が有効なときだけ apkn を有効にできるべきですshould。 palt を有効にすると apkn も自動的に有効にしても構いませんmayが、 palt だけを有効にする手段も用意するべきshouldです。 palt を無効にすると、 apkn も無効にするべきですshould。 >>41

[64] GPOS lookupType 2 が主に想定されています。 lookupType 1 も想定されているようです。 >>41 他の GSUB や GPOS も禁止されているわけではありません。

chws 機能 (OpenType)

[47] フォント機能 chws は Contextual Half-width Spacing とされています。 >>41

[48] JLREQ あるいは同様の CJK 文章配置text-layout仕様書で既定のグリフが全角full-widthである文字の半角形half-width formsを期待するもので説明されているように、 既定では全角幅full-em widthsのグリフを文脈的に再度間隔調整contextually re-spacesし、 より洗練された文章配置text layoutに近似approximateさせるよう半角水平幅half-em horizontal widthsに合わせfitting them ontoます。 >>41

[51] JLREQ では特に

が参照されています。また、 CLREQ, KLREQ が参照されています (が具体的な箇所は参照されていません)。 >>41

[61] 中文だとこの辺りが該当するのでしょう:

[63] 韓文だと一応この辺りが該当するのでしょうが、あまり詳しい説明はありません:

[54] FULLWIDTH RIGHT PARENTHESIS の後に IDEOGRAPHIC COMMA が続くときに、 前者の右側半角が空白であるとき chws によってこれを除去できます。 >>41

[49] halt とは違って間隔再調整re-spacingは文脈的contextualです。 >>41

[50] chws は単一間隔揃えmonospaced alignmentを崩さずに (UI や端末アプリのような場面で) 句読点punctuationや記号symbolのグリフをより良く合わせるfitべく呼び出せます。 >>41

[55] CLREQ, JLREQ, KLREQ で説明されるような CJK 文textの高度advancedな layout に対応する layout engine の場合には、 chws は使うべきではありませんshould。 そのような応用は利用者が chws を制御できるようにしないのが適当かもしれませんmay。 >>41

[56] そうでない応用では CJK 文textの横組horizontal layout時に常に chws に対応するべきですshould。 既定で有効にするべきですshould。 >>41

[59] 文脈的に云々というのでいわゆる complex script の仕組みのように高度なアルゴリズムがグリフ列の一部に適宜このフォント機能を適用するのかと思いきや、 どうもそうではなさそうです。 高度なアルゴリズムを実装しているなら chws とは関係なくそのアルゴリズムが処理してくれ、 そうではない従来からの実装は通常のフォント機能と同じように chws を利用者の指定により使える、ということのようです。 (とはいえ高度なアルゴリズムであろうとどのフォントがどのような文字幅でどのグリフに除去可能な空白があるかまで一々把握しているとは思えないので、 結局 chws を一部分に適用するという実装になるのかもしれませんが。)

[57] 水平グリフ幅機能フォント機能 fwid, halt, hwid, palt, pkna, pwid, qwid, twid, pnum, tnum と互いに排他的であり、 chws を適用するなら無効にするべきですshould。 >>41

[58] chws を文章の連なりtext runに適用するときは apkn, kern は無効にするべきですshould。 >>41

[65] GPOS lookupType は 2 や 8 が推奨recommendedされています。 >>41 他の GSUB や GPOS が禁止されているわけではありません。

[66] GPOS lookupType 2 では1つ目のグリフに調整を適用し、 2つ目には適用しないことが推奨recommendedされます。 そうすると2つ目のグリフはそれを1つ目のグリフとして再探索されることになります。 >>41

cpsp 機能 (OpenType)

cpsp

dist 機能 (OpenType)

dist

関連

[4] text-rendering

歴史

[38] The Typekit Blog | Kerning on the Web, , https://blog.typekit.com/2014/02/05/kerning-on-the-web/

メモ

[39] 字形分析して和文オプティカルカーニングを行うJavaScriptライブラリの開発 - Qiita ( ()) http://qiita.com/data9824/items/b8d79a5b2ced3e9f3868

[40] 記号の前後の空白を詰める調整と説明されてることが多いですが、 逆にグリフ間隔を広げて近接しすぎないように調整してるフォントもあります。

[13] 原則と応用 - JAGAT, , https://www.jagat.or.jp/past_archives/content/view/3235.html

括弧や句読点の前後のアキは、やや空き過ぎに見えて詰めたくなる場合もあるが、行の調整処理などを考慮し、前後のアキを詰めることは一般には行わない。 ただし、パーレンと山括弧(()と〈〉)については、活字組版の時代から、その前後を二分アキとしないでベタ組にすることが一部の出版社で行われていた。

これに対し、見出しに括弧と句読点を配置する場合、文字サイズも大きくなり、これらの前後の二分アキが目立つこともある。そこで、括弧や句読点の前後の二分アキを、四分アキ又はベタ組とする方法が行われている。 四分アキとする方法は一部の出版社の一部の出版物で行われており、ベタ組とする方法もそれなりに行われている。 私は、ベタ組は詰め過ぎと思うので、四分アキにする方法をとっている。柱(ページの欄外に掲げる見出し)や目次でも同様に行っている。

[36] 「モーニング娘。'23」の「。'」の間のアキをどうするのか気になる。

[67] Toshi Omagari | Klaket, https://tosche.net/jp/fonts/klaket

ルカー体は特に学ぶのが難しい文字ではないのですが、傾斜するベースラインがタイポグラフィでは再現が難しいので、デジタル書体の選択肢はほとんどありません。OpenType機能を使えば傾斜の再現自体は難しくないのですが、厄介なのはカーニングです。カーニングといえば通常は二つの文字の間を調整する作業ですが、ルカー体などでは文字の位置が後続の文字によって上下し、それによってアキ量も変わるため、あるペアのカーニング量を決めるには続く文字の内容まで確認しなければいけません。うまくルールを単純化しなければ、天文学的にカーニングのパターンが増えることになります。幸運なことに前述のカマルさんから解決策を教えていただきました。精度があまり高くはありませんが総当たりする必要もなく、カーニングが無いよりは遥かにマシです(既存のOpenTypeのルカー書体はどれもカーニングが入ってません)。