Edit

Page

Page title:

Page body:

* [CODE[font-kerning]] (CSS)

[2] [CITE@en[CSS Fonts Module Level 4]], [TIME[2022-08-21T12:18:41.000Z]], [TIME[2022-08-24T06:28:28.574Z]] <https://drafts.csswg.org/css-fonts/#font-kerning-prop>

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

* [CODE[kern]], [CODE[vkrn]] 機能 (OpenType)

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

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

[37] 
関連: [[結合文字]]

* [CODE[apkn]] 機能 (OpenType)

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

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

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

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

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

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

[REFS[

- [41] 
[CITE@en-us[Registered features, a-e (OpenType 1.9.1) - Typography | [[Microsoft Learn]]]], [[PeterCon]], [TIME[2024-07-07T00:58:54.000Z]], [TIME[2024-12-04T11:09:39.132Z]] <https://learn.microsoft.com/en-us/typography/opentype/spec/features_ae>

]REFS]

* [CODE[chws]] 機能 (OpenType)

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

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

[51] 
[[JLREQ]]
では特に

- [52] [CSECTION[3.1.4 Positioning of Consecutive Opening Brackets, Closing Brackets, Commas, Full Stops and Middle Dots]]
<https://www.w3.org/TR/jlreq/?lang=en#positioning_of_consecutive_opening_brackets_closing_brackets_comma_full_stops_and_middle_dots>
- [53] [CSECTION[B. Spacing between Characters]]
<https://www.w3.org/TR/jlreq/?lang=en#spacing_between_characters>

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

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

- [60] 
[CITE@en[Requirements for Chinese Text Layout - 中文排版需求]], [TIME[2024-11-05T18:58:34.000Z]], [TIME[2024-12-05T04:56:07.189Z]] <https://www.w3.org/International/clreq/#punctuation_width_adjustment>

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

- [62] 
[CITE@en[Requirements for Hangul Text Layout and Typography - 한국어 텍스트 레이아웃 및 타이포그래피를 위한 요구사항]], [TIME[2024-11-14T10:20:20.000Z]], [TIME[2024-12-05T05:03:16.432Z]] <https://w3c.github.io/klreq/#fonts-letterfaceposn>

[EG[

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

]EG]

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

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

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

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

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

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

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

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

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

* [CODE[cpsp]] 機能 (OpenType)

[SEE[ [[cpsp]] ]]

* [CODE[dist]] 機能 (OpenType)

[SEE[ [[dist]] ]]

* [CODE[kern]] 表 (OpenType)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[REFS[
- [7] 
[CITE@ja-jp[OpenType glyph processing (part 2) - Typography | [[Microsoft]] Docs]], [[alib-ms]], [TIME[2022-08-27T12:28:07.000Z]] <https://docs.microsoft.com/ja-jp/typography/develop/processing-part2#gpos-table>
-
[16] 
[CITE@ja-jp[[[kern]] - Kerning (OpenType 1.9) - Typography | Microsoft Docs]], [[PeterCon]], [TIME[2022-09-09T11:37:39.000Z]] <https://docs.microsoft.com/ja-jp/typography/opentype/spec/kern>
]REFS]

* 関連

[4] [CODE[text-rendering]]

* 歴史

[38] [CITE@en-GB[The Typekit Blog | Kerning on the Web]], [TIME[2020-07-28T21:34:28.000Z]], [TIME[2023-11-11T07:25:39.764Z]] <https://blog.typekit.com/2014/02/05/kerning-on-the-web/>

* メモ

[39] 
[CITE[字形分析して和文オプティカルカーニングを行うJavaScriptライブラリの開発 - [[Qiita]]]]
( ([TIME[2017-05-19 14:28:04 +09:00]]))
<http://qiita.com/data9824/items/b8d79a5b2ced3e9f3868>

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

[13] [CITE[原則と応用 - JAGAT]], [TIME[2020-03-27T05:47:03.000Z]], [TIME[2022-08-31T14:13:44.929Z]] <https://www.jagat.or.jp/past_archives/content/view/3235.html>

> 括弧や句読点の前後のアキは、やや空き過ぎに見えて詰めたくなる場合もあるが、行の調整処理などを考慮し、前後のアキを詰めることは一般には行わない。
ただし、パーレンと山括弧(()と〈〉)については、活字組版の時代から、その前後を二分アキとしないでベタ組にすることが一部の出版社で行われていた。
>
これに対し、見出しに括弧と句読点を配置する場合、文字サイズも大きくなり、これらの前後の二分アキが目立つこともある。そこで、括弧や句読点の前後の二分アキを、四分アキ又はベタ組とする方法が行われている。
四分アキとする方法は一部の出版社の一部の出版物で行われており、ベタ組とする方法もそれなりに行われている。
私は、ベタ組は詰め過ぎと思うので、四分アキにする方法をとっている。柱(ページの欄外に掲げる見出し)や目次でも同様に行っている。

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

[67] [CITE@en-GB[Toshi Omagari | Klaket]], [TIME[2025-06-27T13:20:21.000Z]] <https://tosche.net/jp/fonts/klaket>

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

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)