合字 (リガチャ) とは、2 つ以上の文字を結合して 1 つのグリフ (字形) として表示するタイポグラフィの技法です。ラテン文字では fi、fl、ff、ffi などが代表的なリガチャで、活版印刷の時代から文字同士の物理的な衝突を避け、美しい組版を実現する手段として用いられてきました。現代のデジタルフォントでもこの伝統は受け継がれており、OpenType フォントの機能として広く実装されています。

リガチャの仕組みは、フォントファイル内の GSUB (Glyph Substitution) テーブルに定義されています。テキストレンダリングエンジンが特定の文字の並びを検出すると、個別のグリフの代わりに結合されたグリフを描画します。たとえば「f」と「i」が隣接すると、f のアセンダー部分と i のドットが干渉するため、専用のリガチャグリフに置き換えることで視覚的な調和を保ちます。

置き換えを起動する機能は 1 種類ではありません。OpenType の機能タグでは、fi や ffi のような標準的なリガチャが liga、文脈に応じて適用する標準リガチャが clig、書体デザイナーが用意した装飾的なリガチャが dlig、古い組版様式のリガチャが hlig、そして書記体系上必須の結合が rlig に割り当てられています。いずれも実装上は GSUB のルックアップタイプ 4 (リガチャ置換) で、複数グリフの並びを 1 グリフへ写します。「合字はフォントの liga 機能である」と一括りにすると、後述するプログラミングフォントのように別の機能で実装された合字を取りこぼします。

近年、プログラミングフォントにおけるコーディングリガチャが注目を集めています。Fira Code、JetBrains Mono、Cascadia Code などのフォントでは、!= を ≠、=> を ⇒、<= を ≤ のように表示します。これにより演算子の視認性が向上し、コードの可読性が高まります。ただし、コーディングリガチャはあくまで表示上の変換であり、ソースコード自体は元の文字列のまま保存されます。

実務で戸惑いやすいのは、コーディングリガチャが liga ではなく calt (文脈依存字形) を使って実装されている点です。Fira Code は公式の導入手順で font-feature-settings: "calt" や font-variant-ligatures: contextual による有効化を案内しています。そのため no-common-ligatures だけを指定しても矢印や比較演算子の合字は消えず、切りたい場合は no-contextual を併記するか none を指定する必要があります。エディタ側に合字のオン・オフ設定がある場合は、CSS ではなくそちらが優先されます。

CSS では font-variant-ligatures プロパティでリガチャの有効・無効を制御できます。値は 4 系統に分かれ、common-ligatures / no-common-ligatures が liga と clig、discretionary-ligatures が dlig、historical-ligatures が hlig、contextual が calt に対応します。ここで押さえておきたいのは既定値の挙動です。初期値である normal では一般的なリガチャと文脈依存字形が有効、装飾的なリガチャと古典的なリガチャは無効になります。つまりリガチャを持つフォントを指定すれば fi や ffi は何も書かなくても適用され、CSS を書く必要が出てくるのは「装飾的なリガチャを足したいとき」か「リガチャを止めたいとき」です。none を指定すると 4 系統すべてを無効化します。

よくある誤解として、リガチャとカーニングを混同するケースがあります。カーニングは文字間の距離を調整する技法であるのに対し、リガチャは複数の文字を 1 つのグリフに置き換える技法です。両者は組版の美しさを追求する点で共通しますが、仕組みは根本的に異なります。また、アラビア文字のように文字の接続が書記体系の基本ルールに組み込まれている場合、リガチャは装飾ではなく必須の機能です。ラーム (lam) にアリフ (alef) が続くと必ず結合形になる例が代表的で、OpenType ではこれを rlig (Required Ligatures) として登録し、シリア文字も同様に扱います。仕様はこの機能の制御を一般にユーザーへ公開すべきではないとしており、見た目の好みで切る対象ではありません。

文字数カウントの観点では、リガチャは表示上 1 つのグリフとして描画されますが、内部的には元の複数文字として扱われます。たとえば fi リガチャは見た目は 1 文字ですが、文字数としては 2 文字とカウントされます。テキストエディタでカーソルを移動する際も、リガチャの内部で 1 文字ずつ移動できるのが一般的です。フォントを変えても文字数が変わらないのは、この置き換えが描画の段階でしか起きないからです。

ただし例外があります。Unicode には合字そのものを 1 つの文字として収録した符号位置があり、たとえば fi (U+FB01 LATIN SMALL LIGATURE FI) や ffl (U+FB04) は、フォントの機能とは無関係に 1 文字として数えられます。古い PDF やワープロ文書からコピーした文章に紛れ込むことがあり、見た目は同じでも f と i を並べた 2 文字とは別物です。この差は正規化で表面化します。互換正規化 (NFKC) を通すと U+FB01 は f と i の 2 文字へ展開され、U+FB04 は 3 文字へ増えます。一方で合成正規化 (NFC) では変化しないため、NFC 前提のシステムでは 1 文字のまま残ります。文字数が想定と合わないときは、まず入力文字列にこれらの符号位置が混ざっていないか、どの正規化を通しているかを確認してください。なお ß や Œ は成り立ちは合字ですが独立した文字として扱われ、NFKC でも分解されません。