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 を割り当てているフォントもあります。
apkn 機能 (OpenType)[42]
フォント機能
apkn
は、
Kerning for Alternate Proportional Widths
とされています。
>>41
[43]
既定では固定の前進幅を持つグリフが
palt
によって可変幅に調整されているときの字間調整を行うものです。
>>41
[44]
そのようなグリフは kern によって字間調整しないことが強く推奨されます。
apkn
によってのみ字間調整されるべきです。
>>41
[46] CJK フォントが主対象ですが、それ以外でも使えます。 >>41
[45]
palt が有効なときだけ
apkn
を有効にできるべきです。
palt
を有効にすると
apkn
も自動的に有効にしても構いませんが、
palt
だけを有効にする手段も用意するべきです。
palt
を無効にすると、
apkn
も無効にするべきです。
>>41
[64]
GPOS lookupType 2
が主に想定されています。
lookupType 1
も想定されているようです。
>>41
他の GSUB や GPOS も禁止されているわけではありません。
chws 機能 (OpenType)[47]
フォント機能
chws
は
Contextual Half-width Spacing
とされています。
>>41
[48] JLREQ あるいは同様の CJK 文章配置仕様書で既定のグリフが全角である文字の半角形を期待するもので説明されているように、 既定では全角幅のグリフを文脈的に再度間隔調整し、 より洗練された文章配置に近似させるよう半角水平幅に合わせます。 >>41
が参照されています。また、 CLREQ, KLREQ が参照されています (が具体的な箇所は参照されていません)。 >>41
[63] 韓文だと一応この辺りが該当するのでしょうが、あまり詳しい説明はありません:
[54]
FULLWIDTH RIGHT PARENTHESIS
の後に
IDEOGRAPHIC COMMA
が続くときに、
前者の右側半角が空白であるとき
chws
によってこれを除去できます。
>>41
[49]
halt とは違って間隔再調整は文脈的です。
>>41
[50]
chws は単一間隔揃えを崩さずに (UI や端末アプリのような場面で)
句読点や記号のグリフをより良く合わせるべく呼び出せます。
>>41
[55]
CLREQ, JLREQ, KLREQ で説明されるような CJK 文の高度な
layout
に対応する layout engine の場合には、
chws は使うべきではありません。
そのような応用は利用者が chws を制御できるようにしないのが適当かもしれません。
>>41
[56]
そうでない応用では CJK 文の横組時に常に
chws に対応するべきです。
既定で有効にするべきです。
>>41
[57]
水平グリフ幅機能
fwid, halt, hwid, palt, pkna, pwid, qwid, twid, pnum, tnum
と互いに排他的であり、
chws を適用するなら無効にするべきです。
>>41
[58]
chws を文章の連なりに適用するときは
apkn, kern は無効にするべきです。
>>41
[65]
GPOS lookupType は 2 や 8
が推奨されています。
>>41
他の GSUB や GPOS が禁止されているわけではありません。
[66]
GPOS lookupType 2
では1つ目のグリフに調整を適用し、
2つ目には適用しないことが推奨されます。
そうすると2つ目のグリフはそれを1つ目のグリフとして再探索されることになります。
>>41
cpsp 機能 (OpenType)dist 機能 (OpenType)kern 表 (OpenType)[17]
kern 表はフォント中のグリフの文字間のスペース付けを制御するものです。
>>16
[8]
OpenType フォントに KERN 表と GPOS のカーニングの両方を入れることもできます。
>>7
[19]
CFF outline の OpenType フォントでは
kern は使うことができません。
GPOS を使わなければなりません。
>>16
CFF が導入されたのと同時に
GPOS が導入されたので、
それ以前から存在したものの GPOS と重複する
kern は利用しないことに決めた、ということなのでしょう。[9] 応用はどちらでも好きな方を使えます。 >>7
しかし GPOS の方が新しく高機能で、そちらが好ましいようです。
[18] OpenType 仕様書は、対象の組と値を返すだけで、 システムレベルでは対応していない >>16 と述べています。 Microsoft の仕様書なので、 Windows の実装ではそうだという意味でしょう。
[10] KERN 表の方は応用の対応が進めば実質的に廃止なもの
>>7 という扱いになっています。
[11]
後方互換性のため GPOS が使えればそちらを、なくて
kern があればそちらを、と実装するのがいいのでしょう。
[15]
OpenType は TrueType 由来の kern 表を規定しています。
他の章で KERN 表を参照していますが >>7、
どこでも規定されていません。
[12]
現在の実装状況からすればフォント側は GPOS にだけ入れておけば十分とも思われます。
[21]
kern 表には部分表を何個か含めることが出来ます。
各部分表による調整は追加されていきます。
>>16
[22] 従って部分表の順序は重要ではないとされます。 ただし最小値は他の部分表の効果を制限すべく普通は最後に置くべきだとされます。 >>16
[33]
部分表の coverage
の第3ビット
override
により、
それまで蓄積されてきた指定が上書きされます。
>>16
[23] 分かったようで分からない規定です。 順序は重要ではないといいながらも、 最小値が最後にあるべきだということやリセットができるということは、 やはり最初から順に処理されるものだということでいいのでしょうか。 部分表が加算的であるとはどういうことでしょう。 カーニング値 (スペース調整量) が同じグリフの組に対して複数回指定できるということでしょうか。 その時は調整量が加算されていくのでしょうか。それとも後の方で上書きされるのでしょうか。 あるいは同じグリフの組への適用は想定していなくて、 異なるグリフの組への調整をすべて拾っていくという意味なのでしょうか。
[24]
OpenType
では部分表は、
format 0
と
format 2
があります。
>>16
[25]
Windows は部分表
format 0
にだけ対応しています。
>>16
[26] 部分表では左グリフと右グリフの組に対して値を設定できます。 >>16
[29] グリフの組は左と右で指定されます。これは文字通り物理順と考えて良いのでしょうか。
[31]
部分表の coverage
の第0ビット
horizontal
により、
水平方向 (1) か垂直方向 (0) かを指定できます。
>>16
やや不明瞭ですが、
横書き用か縦書き用かの区別と思われます。
[34]
部分表の coverage
の第2ビット
cross-stream
により、
垂直方向の指定 (1) かそうでないか (0)
を指定できます。
ここでいう垂直とは、
横書きなら正値で上向きに kern、負値で下向きに kern され、
縦書きなら正値で右向きに kern、負値で左向きに kern されます。
>>16
[31]
部分表の coverage
の第1ビット
minimum
により、
カーニング値 (0)
または最小値 (1)
のどちらであるかが決まります。
>>16
[27] カーニング値は、文字間スペース付けを調整します。 >>16
[28] 最小値は、 kerning と tracking の組合せにより scaler が適用する調整の量を制限します。 >>16
[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」の「。'」の間のアキをどうするのか気になる。
chwsとは関係なくそのアルゴリズムが処理してくれ、 そうではない従来からの実装は通常のフォント機能と同じようにchwsを利用者の指定により使える、ということのようです。 (とはいえ高度なアルゴリズムであろうとどのフォントがどのような文字幅でどのグリフに除去可能な空白があるかまで一々把握しているとは思えないので、 結局chwsを一部分に適用するという実装になるのかもしれませんが。)