* [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]] [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]] - [16] [CITE@ja-jp[[[kern]] - Kerning (OpenType 1.9) - Typography | Microsoft Docs]], [[PeterCon]], [TIME[2022-09-09T11:37:39.000Z]] ]REFS] * フォント機能 [CODE[kern]] (OpenType) [69] [[OpenType]] の[[フォント機能]] [DFN[[CODE[kern]]]] は、 Kerning です。 [SRC[>>68]] [70] [RUBYB[[[横書き]]文配置][horizontal text layout]] ([[横組]]) において、 [[グリフ]]の組合せの間の[RUBYB[[[間隔]]][space]]の[RUBYB[量][amount]]を調整して[[グリフ]]の間の[RUBYB[間隔付け][spacing]]を[RUBYB[見かけ上][optically]][RUBYB[一貫][consistent]]させるために使います。 [RUBYB[よく設計された書体][well-designed typeface]]は[RUBYB[全体として][overall]]一貫した[RUBYB[[[グリフ]]間の間隔付け][inter-glyph spacing]]を有するものではありますが、 [[グリフ]]の組合せによっては[RUBYB[可読性][legibility]]の改善のために[RUBYB[調整][adjustment]]が必要になります。 [SRC[>>68]] [EG[ [78] 「To」の [CH[o]] を左にずらして配置するために [CODE[kern]] を使うことができます。 [SRC[>>68]] ]EG] [71] [CODE[kern]] では[RUBYB[水平方向][horizontal direction]]の[RUBYB[標準的な調整][standard adjustment]] の他に、 - [72] 「[[cross-stream]]」 な [[kerning]] を Y [RUBYB[文方向][text direction]] にも行ったり、 - [73] [[前進]]調整と別にグリフ[[配置]]を調整したり、 - [74] [[装置表]]を介して size 依存の [[kerning]] データを[RUBYB[供給][supply]]したり、 ... もできます。 [SRC[>>68]] -*-*- [75] [CODE[kern]] は[RUBYB[[[縦書き]]文配置][vertical text layout]] ([[縦組]]) での利用は想定していません。 [[縦組]]では [CODE[vkrn]] を使います。 [SRC[>>68]] [77] [CODE[kern]] は[RUBYB[[[利用者]]][user]]が[RUBYB[上書き][overridden]][RUBYB[可能][can]]な[RUBYB[意図した間隔付けの調整][intended spacing adjustments]]にのみ使うべきです。 [RUBYB[[[利用者]]の制御][user control]]下になく[RUBYB[必須の間隔付けの調整][required spacing adjustments]]には [CODE[dist]] を使う[RUBYB[べき][should]]です。 [SRC[>>68]] [80] [CODE[kern]] は、 [[グリフ]] [[metrics]] が[RUBYB[[[可変幅]]][proportional]]に調整される[[機能]]が適用できる場合を除き、 [RUBYB[[[固定幅]]グリフ][fixed-width glyphs]]に [[kerning]] 調整を適用する[RUBYB[べきではありません][should not]]。 [RUBYB[新しい[[フォント]]][new font]]では、 [RUBYB[既定の状態で固定幅][default fixed-width]] [[metrics]] であり[RUBYB[[[可変幅]]][proportional widths]]になるよう調整された[[グリフ]]の [[kerning]] は、 [CODE[kern]] ではなく [CODE[apkn]] による[RUBYB[べきです][should]]。 [SRC[>>68]] [89] [CODE[kern]] は、 [RUBYB[固定長][fixed-width]] [[metrics]] となる[[機能]]: [CODE[chws]], [CODE[fwid]], [CODE[halt]], [CODE[hwid]], [CODE[qwid]], [CODE[twid]], [CODE[tnum]] と組み合わせる[RUBYB[べきではありません][should not]]。 [RUBYB[文章の[[連なり]]][text run]]においてこれらが有効とされたとき、 [CODE[kern]] は無効とする[RUBYB[べきです][should]]。 [SRC[>>68]] ;; [90] これが[[著者]]に対する要件なのか[[文字のレンダリング]]の実装に対する要件なのかよくわかりません。 [91] [CODE[kern]] は [CODE[pkna]], [CODE[pwid]] と併用でき、 それらが[RUBYB[文章の[[連なり]]][text run]]において有効とされたとき、 既定でまたは[[利用者]]の[RUBYB[好み][preference]]により [CODE[kern]] も有効と[RUBYB[できます][may]]。 [SRC[>>68]] -*-*- [83] [RUBYB[ほとんど][most]]の[[横書き文配置]]では [CODE[kern]] を[RUBYB[既定の状態で有効][active by default]]にする[RUBYB[べき][should]]です。 [SRC[>>68]] [85] ただし CJK [RUBYB[文][text]]の場合、 [RUBYB[文章の[[連なり]]][text run]]が [CODE[palt]] を実装する[[フォント]]で[RUBYB[書式付け][formatted]]されている場合、 [CODE[palt]] [[機能]]も有効である場合を除き、 [CODE[kern]] は [CODE[palt]] [[lookup]] で[RUBYB[覆われる][covered]][[グリフ]]に対して既定の状態で有効にする[RUBYB[べきではありません][should not]]。 なぜならば、 [CODE[palt]] で覆われる[[グリフ]]は既定の状態で[RUBYB[[[固定幅]]][fixed-width]] [[metrics]] を持つのであり、 [[kerning]] 調整を適用するのは不適切であるからです。 [SRC[>>68]] [87] [[応用]]は、既定の状態で有効にする対象外となるべき[[グリフ]]を特定するために [CODE[palt]] [[lookup]] の [[coverage]] [[表]]を走査することができます。 あるいはそのかわりに、 [[Unicode文字]]の [F[[COD[East_Asian_Width]]]] が [CODE[Wide]] か [CODE[Fullwidth]] であれば [CODE[palt]] を実装する[[フォント]]において既定の状態で[RUBYB[固定幅][fixed-width]]の [[metrics]] を持つものと[RUBYB[みなしても構いません][may be assumed]]。 [SRC[>>68]] [88] しかしながら、[[フォント]]が [CODE[palt]] と [CODE[apkn]] の両方を実装する場合には、 [CODE[kern]] をすべての[RUBYB[[[横書き]]文][horizontal text]]に適用できます。 [SRC[>>68]] [NOTE[ [93] 仕様書のこの部分の規定は非常にわかりにくく、冗長な反面、表現に一貫性がないなど文意が必ずしも判然としないところがありますが、 要するに[[固定幅フォント]]に対して [CODE[kern]] がどう適用されるべきかについて、 古い実装や[[フォント]]が混乱した状態だったのでしょう。 [94] それに対して新たに [CODE[apkn]] を追加したり、仕様書に規定を追加したりと手当てしたものの、 既存の実装の挙動を正確に記述するでもなく、新しい実装に対する要件を完璧に規定するでもない、 中途半端で曖昧な文言にしてしまったということだと思われます。 [95] 適用するでもない [CODE[palt]] を [[lookup]] するというのは他にないおかしな操作です。 その代替として提示される [[Unicode文字]]の情報を使うというのはもっとおかしな操作です。 正気とは思えませんが、そういう実装がどこかにあるのでしょう。 ([[EAW]] が[[曖昧幅]]の[[文字]]はどうなるのかとか、 [CODE[cmap]] から直接ではなく[[フォント機能]]による [CODE[GSUB]] を経由した[[グリフ]]でおかしくならないのかとか、 気になることはいろいろあります。) ]NOTE] [92] いずれの事由にせよ [CODE[kern]] が[RUBYB[文章の[[連なり]]][text run]]に対して既定で適用されるときは、 [[利用者]]がこれを無効にすることもできる[RUBYB[べきです][should]]。 [SRC[>>68]] [86] [CODE[kern]] は[[文書]]の[[マーク付け]], [[利用者]]の制御, その他[[応用]]依存の方法で[[グリフ]]の[[連なり]]に対して適用するかどうか指定させられます。 [SRC[>>68]] [84] [[応用]]は、[[利用者]]に [CODE[kern]] の有効・無効に加えて更に特定の手動の調整を行わせる手段を提供できます。 [SRC[>>68]] -*-*- [79] [CODE[GPOS]] [F[[CODE[lookupType]]]] [N[2]], [N[8]] が[RUBYB[推奨][recommended]]されています。 [N[2]] のとき、2つ目の[[グリフ]]の[[配置]]調整は行わないことが[RUBYB[推奨][recommended]]されます ([N[0]] に設定する[RUBYB[べきです][should]])。 [SRC[>>68]] ;; [82] [N[2]] の仕様では、こうすることで[[グリフ]]列の前から順のすべての組合せに調整を適用できます。 2つ目の[[グリフ]]の[[配置]]が調整されると、2つ目の[[グリフ]]とその次の[[グリフ]]の組合せでの調整が行われません。 [76] 2つ[[超]]の[[グリフ]]の[[連なり]]に対して [[lookup]] を適用することもできます。 [SRC[>>68]] [81] その他の [CODE[GSUB]], [CODE[GPOS]] が禁止されているわけではありません。 [REFS[ - [68] [CITE@en-us[Registered features, k-o ([[OpenType]] 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:31.000Z]], [TIME[2025-12-26T13:09:31.070Z]] ]REFS] * [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]] ]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]] - [53] [CSECTION[B. 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]] [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]] [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]] ]] * 関連 [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]] * メモ [39] [CITE[字形分析して和文オプティカルカーニングを行うJavaScriptライブラリの開発 - [[Qiita]]]] ( ([TIME[2017-05-19 14:28:04 +09:00]])) [40] [[記号]]の前後の[[空白]]を詰める調整と説明されてることが多いですが、 逆に[[グリフ]]間隔を広げて近接しすぎないように調整してる[[フォント]]もあります。 [13] [CITE[原則と応用 - JAGAT]], [TIME[2020-03-27T05:47:03.000Z]], [TIME[2022-08-31T14:13:44.929Z]] > 括弧や句読点の前後のアキは、やや空き過ぎに見えて詰めたくなる場合もあるが、行の調整処理などを考慮し、前後のアキを詰めることは一般には行わない。 ただし、パーレンと山括弧(()と〈〉)については、活字組版の時代から、その前後を二分アキとしないでベタ組にすることが一部の出版社で行われていた。 > これに対し、見出しに括弧と句読点を配置する場合、文字サイズも大きくなり、これらの前後の二分アキが目立つこともある。そこで、括弧や句読点の前後の二分アキを、四分アキ又はベタ組とする方法が行われている。 四分アキとする方法は一部の出版社の一部の出版物で行われており、ベタ組とする方法もそれなりに行われている。 私は、ベタ組は詰め過ぎと思うので、四分アキにする方法をとっている。柱(ページの欄外に掲げる見出し)や目次でも同様に行っている。 [36] 「モーニング娘。'23」の「。'」の間のアキをどうするのか気になる。 [67] [CITE@en-GB[Toshi Omagari | Klaket]], [TIME[2025-06-27T13:20:21.000Z]] >ルカー体は特に学ぶのが難しい文字ではないのですが、傾斜するベースラインがタイポグラフィでは再現が難しいので、デジタル書体の選択肢はほとんどありません。OpenType機能を使えば傾斜の再現自体は難しくないのですが、厄介なのはカーニングです。カーニングといえば通常は二つの文字の間を調整する作業ですが、ルカー体などでは文字の位置が後続の文字によって上下し、それによってアキ量も変わるため、あるペアのカーニング量を決めるには続く文字の内容まで確認しなければいけません。うまくルールを単純化しなければ、天文学的にカーニングのパターンが増えることになります。幸運なことに前述のカマルさんから解決策を教えていただきました。精度があまり高くはありませんが総当たりする必要もなく、カーニングが無いよりは遥かにマシです(既存のOpenTypeのルカー書体はどれもカーニングが入ってません)。