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 を割り当てているフォントもあります。
kern 表 (OpenType)[17]
kern 表はフォント中のグリフの文字間のスペース付けを制御するものです。
>>16
[8]
OpenType フォントに KERN 表と GPOS のカーニングの両方を入れることもできます。
>>7
[19]
CFF outline の OpenType フォントでは
kern は使うことができません。
GPOS を使わなければなりません。
>>16
[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
kern (OpenType)[69]
OpenType のフォント機能
kern
は、
Kerning
です。
>>68
[70] 横書き文配置 (横組) において、 グリフの組合せの間の間隔の量を調整してグリフの間の間隔付けを見かけ上一貫させるために使います。 よく設計された書体は全体として一貫したグリフ間の間隔付けを有するものではありますが、 グリフの組合せによっては可読性の改善のために調整が必要になります。 >>68
... もできます。 >>68
[75]
kern は縦書き文配置 (縦組)
での利用は想定していません。
縦組では vkrn を使います。
>>68
[77]
kern は利用者が上書き可能な意図した間隔付けの調整にのみ使うべきです。
利用者の制御下になく必須の間隔付けの調整には dist
を使うべきです。
>>68
[80]
kern は、
グリフ metrics が可変幅に調整される機能が適用できる場合を除き、
固定幅グリフに kerning
調整を適用するべきではありません。
新しいフォントでは、
既定の状態で固定幅 metrics であり可変幅になるよう調整されたグリフの
kerning は、 kern ではなく apkn によるべきです。
>>68
[89]
kern は、
固定長 metrics
となる機能:
chws, fwid, halt, hwid, qwid, twid, tnum
と組み合わせるべきではありません。
文章の連なりにおいてこれらが有効とされたとき、
kern は無効とするべきです。
>>68
[91]
kern は pkna, pwid と併用でき、
それらが文章の連なりにおいて有効とされたとき、
既定でまたは利用者の好みにより
kern も有効とできます。 >>68
[83]
ほとんどの横書き文配置では
kern
を既定の状態で有効にするべきです。
>>68
[85]
ただし CJK 文の場合、
文章の連なりが palt を実装するフォントで書式付けされている場合、
palt
機能も有効である場合を除き、
kern
は palt lookup で覆われるグリフに対して既定の状態で有効にするべきではありません。
なぜならば、
palt で覆われるグリフは既定の状態で固定幅 metrics
を持つのであり、 kerning 調整を適用するのは不適切であるからです。
>>68
[87]
応用は、既定の状態で有効にする対象外となるべきグリフを特定するために
palt lookup の coverage 表を走査することができます。
あるいはそのかわりに、 Unicode文字の East_Asian_Width
が Wide か Fullwidth であれば palt
を実装するフォントにおいて既定の状態で固定幅の metrics
を持つものとみなしても構いません。
>>68
[88]
しかしながら、フォントが palt と apkn
の両方を実装する場合には、
kern をすべての横書き文に適用できます。
>>68
[93]
仕様書のこの部分の規定は非常にわかりにくく、冗長な反面、表現に一貫性がないなど文意が必ずしも判然としないところがありますが、
要するに固定幅フォントに対して kern がどう適用されるべきかについて、
古い実装やフォントが混乱した状態だったのでしょう。
[94]
それに対して新たに apkn を追加したり、仕様書に規定を追加したりと手当てしたものの、
既存の実装の挙動を正確に記述するでもなく、新しい実装に対する要件を完璧に規定するでもない、
中途半端で曖昧な文言にしてしまったということだと思われます。
[95]
適用するでもない palt を lookup するというのは他にないおかしな操作です。
その代替として提示される Unicode文字の情報を使うというのはもっとおかしな操作です。
正気とは思えませんが、そういう実装がどこかにあるのでしょう。
(EAW が曖昧幅の文字はどうなるのかとか、
cmap から直接ではなくフォント機能による GSUB を経由したグリフでおかしくならないのかとか、
気になることはいろいろあります。)
[92]
いずれの事由にせよ
kern が文章の連なりに対して既定で適用されるときは、
利用者がこれを無効にすることもできるべきです。
>>68
[86]
kern
は文書のマーク付け,
利用者の制御,
その他応用依存の方法でグリフの連なりに対して適用するかどうか指定させられます。
>>68
[84]
応用は、利用者に kern
の有効・無効に加えて更に特定の手動の調整を行わせる手段を提供できます。
>>68
[79]
GPOS lookupType 2, 8 が推奨されています。
2 のとき、2つ目のグリフの配置調整は行わないことが推奨されます
(0 に設定するべきです)。
>>68
[76] 2つ超のグリフの連なりに対して lookup を適用することもできます。 >>68
[81] その他の GSUB, GPOS が禁止されているわけではありません。
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
chws とは関係なくそのアルゴリズムが処理してくれ、
そうではない従来からの実装は通常のフォント機能と同じように chws
を利用者の指定により使える、ということのようです。
(とはいえ高度なアルゴリズムであろうとどのフォントがどのような文字幅でどのグリフに除去可能な空白があるかまで一々把握しているとは思えないので、
結局 chws を一部分に適用するという実装になるのかもしれませんが。)[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)[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のルカー書体はどれもカーニングが入ってません)。
CFFが導入されたのと同時にGPOSが導入されたので、 それ以前から存在したもののGPOSと重複するkernは利用しないことに決めた、ということなのでしょう。