kern

kern

font-kerning (CSS)

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

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

kern, vkrn 機能 (OpenType)

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

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

[37] 関連: 結合文字

kern 表 (OpenType)

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

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

[19] CFF outlineOpenType フォントでは 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] OpenTypeTrueType 由来の kern を規定しています。 他の章で KERN を参照していますが >>7、 どこでも規定されていません。

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

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

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

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

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

[24] OpenType では部分表は、 format 0format 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] 最小値は、 kerningtracking の組合せにより scaler が適用する調整の量を制限します。 >>16

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

関連

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