985.txt

* [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[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」の「。'」の間のアキをどうするのか気になる。