リガチャ は、読みやすさとテキストの美学を向上させるために、2つ以上の文字を単一の活字シンボルにグラフィックに組み合わせたものです。古典的な例としては、fi、fl、ff、ffiのペアがあります—文字fの凸出した要素が隣の文字と融合し、視覚的な競合を防ぐのです。現代のモバイル・ウェブ開発において、リガチャはFontレベルでOpenType機能を通じて制御され、iOS、Android、ブラウザでサポートされています。MDN Web Docsによると、CSSプロパティfont-variant-ligaturesを使うと、開発者は標準、任意(装飾的)、文脈決定型など様々なリガチャを有効/無効にできます。
ポイント
リガチャ は、2つ以上の文字を特別に設計された単一のGlyphに置き換える活字技術です。リガチャの主な目的は、隣接する文字間の視覚的な競合を解消し、テキストの認知を向上させることです。例えばfiのペアでは、文字fの上部の凸出部が文字iの点と競合しますが、リガチャはそれらをひとつの優雅なシンボルに融合させます。
リガチャは必須(標準)とオプショナル(装飾的)に分けられます。標準リガチャ は、大手のフォントに見られるペアです: fi, fl, ff, ffi, ffl。これらは質の高いタイポグラフィに必要とされ、フォントでデフォルトで有効になっています。OpenType仕様によると、標準リガチャは'liga'タグでコード化され、あらゆるプロフェッショナルフォントに存在する必要があります。
視覚的効果: リガチャがない場合、fiのペアは不要な競合を伴う2つの単独の文字として見えます。リガチャがある場合、協調したシンボルとして見えます。この違いは、特に大きなサイズ(見出し、ロゴ)や繰り返しペアが多いテキスト(例えば、ドイツ語のhäufigen Buchstabenkombinationen)で注目されます。
OpenTypeフォントはいくつかのタイプのリガチャをサポートしており、それぞれに独自のタグと目的があります。標準 (tag 'liga') は、フォントでデフォルトで有効な必須リガチャです。読みやすさを向上させ、理由なく無効にすべきではありません。fi, fl, ff, ffi, fflのペイアや、タイプフェース固有のその他のペアを含みます。
任意リガチャ (tag 'dlig') は、デザイナーの判断でオプショナルで有効にできる装飾的なリガチャです。読みやすさに必要ではなく、テキストのスタイリングに使用されます: ct, st, sp, Th, Quなど。任意リガチャは、GaramondやAdobe Caslonのような歴史的またはカリグラフィックな性格のフォントによく見られます。警告: 任意リガチャを使い過ぎると、読みやすさが悪化します。特にディスレクシアのあるユーザーに対して注意が必要です。
文脈決定リガチャ (tag 'clig') は、文字の周囲の文脈に依存するリガチャです。文字が単語の先頭または終わりにある場合、特定の句読点の後など、特定の条件下でのみ適用されます。文脈決定リガチャは高度なOpenType機能で、すべてのフォントがサポートしているわけではありません。歴史リガチャ (tag 'hlig') は、古い印刷書籍のスタイルを模倣した過時のリガチャです (long s, &)。歴史的またはスタイル化されたテキストでのみ使用され、めったに使われることはありません。
| リガチャの種類 | OpenTypeタグ | 例 | デフォルト |
|---|---|---|---|
| 標準 | liga | fi, fl, ff, ffi | 有効 |
| 任意 | dlig | ct, st, sp, Th | 無効 |
| 文脈決定 | clig | 位置に依存 | 有効 |
| 歴史 | hlig | long s, ct (history) | 無効 |
れきな種類: 数学タイプセッティング用のリガチャ(数学記号用のタグ'dlig')や頭文字リガチャ(ドロップキャプス)もありますが、これらはインターフェイスのタイポグラフィでは使用されず、専門フォントでのみサポートされています。
リガチャはデジタルタイポグラフィよりも遠かに古く、15世紀の金属活字の時代から存在しています。初期の印刷工ヨハンネス・グーテンベルクは、42行聖書の行を節約するためにリガチャを使用しました。各活字は物理的な金属ブロックであり、2つの文字を1つに組み合わせることで鉢を節約し、組版を簡素化しました。標準リガチャのfi, fl, ffi, fflは、この時代の遺産です。
写真組版(20世紀)では、リガチャは実用的な機能を失いましたが、質の高いタイポグラフィの美学的要素として残りました。フォントデザイナーたちは、リガチャが専門性と細部への注意の印となったことから、タイプフェースに続けてリガチャを含めるようになりました。デジタルフォントの時代(PostScript, TrueType)では、リガチャはプログラムによる置換で単独のGlyphとして実装されました。
OpenType (1996) は革命的でした: GSUB(Glyph Substitution Table)機構を導入し、ユーザーが介入しなくても文字の連続をリガチャに自動的に置換するようになりました。GSUBは文脈決定置換、条件、フォールバック変体をサポートしています。これにより、フォントはタグを通じて有効/無効にできる数百のリガチャを持つことができるようになりました。現代のフォント — SF Pro、Roboto、Inter — は、iOS、Android、macOS、Windows、ウェブどのプラットフォームでもOpenTypeリガチャをサポートしています。
iOSでは、UIFontDescriptorを使用してfeatureSettings属性でリガチャを制御できます。この属性は、それぞれがひとつのOpenType機能を記述する辞書の配列を受け取ります。ディスクリプタを通じてリガチャを制御するのが、フォントの他のOpenType機能に影響を与えずに個々のタイプのリガチャを管理できる唯一の方法です。
let descriptor = UIFontDescriptor.preferredFontDescriptor(
withTextStyle: .body
)
// 任意リガチャを有効にする
let ligatureDescriptor = descriptor.addingAttributes([
.featureSettings: [
[
UIFontDescriptor.FeatureIdentifier: kLigaturesType,
UIFontDescriptor.TypeIdentifier: kCommonLigaturesOnSelector
]
]
])
let font = UIFont(
descriptor: ligatureDescriptor,
size: 17
)
NSAttributedString もligature属性 (NSNumber) をサポートしています。値0はすべてのリガチャを無効にし、1は標準を有効にし(デフォルト)、2はすべてを有効にします(任意も含む)。ただし、NSAttributedStringのligature属性はリガチャのタイプを細かく制御できず、全体的な有効/無効のみです。選択的な制御には、featureSettingsを使用したUIFontDescriptorを使ってください。
SwiftUI には、リガチャ用の直接の修飾子はありません。SwiftUIでリガチャを制御するには、UIFontDescriptorを通じて必要な設定のUIFontを作成し、Font(descriptor:size:)を使用して適用します。または、AttributedString (iOS 15+)を使用し、AppKit/UIKitビューでNSMutableAttributedStringに.ligature属性を設定します。
// AttributedStringを使用したカスタムリガチャ付きSwiftUI
var attributedText: AttributedString {
var text = AttributedString(
"Effective typography with ligatures"
)
// テキスト全体のすべてのリガチャを有効にする
text.ligature = .all
return text
}
var body: some View {
Text(attributedText)
}
ウェブでは、CSSプロパティfont-variant-ligaturesでリガチャを制御します。このプロパティは、common-ligatures(標準有効)、no-common-ligatures(標準無効)、discretionary-ligatures、no-discretionary-ligatures、contextual、no-contextualのキーワードを取ります。このプロパティは2015年以降のすべての現代ブラウザでサポートされています。デフォルトでは、ブラウザは標準リガチャと文脈決定リガチャを有効にします。
/* Disable all ligatures for monospace */
code, pre {
font-variant-ligatures: none;
}
/* Enable discretionary ligatures for headings */
.title-fancy {
font-variant-ligatures:
common-ligatures
discretionary-ligatures
contextual;
}
Android には、リガチャを制御するための直接のAPIはありません。AndroidではリガチャはFontレベルとMinikinレンダリングエンジン(Android 10+)で制御されます。フォントがOpenType GSUBテーブルを含む場合、リガチャは自動で適用されます。Androidでリガチャを無効にするには、Typeface.Builderで作成したカスタムTypefaceか、テキストのプリプロセッシング(表示前の文字置換)を使います。制限: Android 10未満では、いくつかのTTFフォントでリガチャが正しく動作しない可能性があります。
低レベル制御: すべてのプラットフォームで、OpenType機能にfont-feature-settingsパラメータを使用したCSS @font-faceを使えます。この方法では、リガチャを含むすべてのOpenTypeタグにアクセスできます。例: font-feature-settings: 'liga' 1, 'dlig' 1。ただし、font-feature-settingsは低レベルな構文であり、MDNはより高レベルな代替としてfont-variant-ligaturesを推奨しています。
特殊なクラスのリガチャ — プログラミングリガチャ — は、演算子やコード記号をより読みやすいGlyphに組み合わせます。Fira Code、JetBrains Mono、Cascadia Codeのようなプログラミングフォントは、一般的な演算子に対する任意リガチャを含みます: != (≠になる)、>= (≥になる)、-> (矢印になる)、=> (太い矢印になる)、=== (三重等号になる)。
プログラミングリガチャは、デベロッパーコミュニティで論争のあるトピックです。支持者は、リガチャがコード読みを加速すると主張します。なぜなら演算子が単一の概念として認知されるからです。研究 (Kera et al., PLATEAU 2020) によると、リガチャはコードの読み速度に影響しないが、67%のデベロッパーが主観的に好んでいることがわかりました。反対者は、リガチャがコードを歪めると指摘します: エディタでは!=が≠と表示されるが、テキストファイルでは2つの文字として保存されるため、コラボレーション時に混乱する可能性があります。
技術的な実装: プログラミングリガチャは、任意のOpenTypeリガチャ(タグ'dlig')です。デフォルトでは無効で、コードエディタでフォント設定を通じて有効にします。このようなフォントを使用するデベロッパーは、エディタを設定して任意リガチャを有効にする必要があります。ターミナル(iTerm2, Windows Terminal)でも、フォント設定を通じてリガチャをサポートしています。互換性: すべてのエディタやターミナルがOpenTypeリガチャをサポートしているわけではありません。フォントを選ぶ前に、使用しているツールとの互換性を確認してください。
// 例: JetBrains Monoの演算子リガチャ
val isEqual = a != b // != は≠とレンダリングされる
val arrow = x -> x + 1 // -> は→とレンダリングされる
val range = 1 .. 10 // .. は範囲としてレンダリングされる
人気のフォント プログラミングリガチャ付き: Fira Code(2015年最初の解放的なリガチャ付きフォント)、JetBrains Mono(2020年、コード読みに最適化)、Cascadia Code(2019年、Microsoft製)、Iosevka(モジュラーリガチャシステムのカスタマイズ可能フォント)。各フォントには独自のリガチャセットがあります — 50から150+の置換。推奨: Fira CodeまたはJetBrains Monoから始めてください — エディタやIDEでのサポートが最も良いです。
よくある質問
NSAttributedStringでattribute ligature = 0を設定するか、kCommonLigaturesOffSelectorを使用してUIFontDescriptorを使用します。SwiftUIでは、.ligature = .disabledを使用してAttributedStringを作成します。
リガチャ は2つの文字を新しいGlyphで置き換え、形を変えます。ケールニング は文字間のスペースを調整しますが、形は変えません。リガチャはグラフィックな結合であり、ケールニングは空間的な調整です。
はい、Android 10 (API 29) 以降でサポートしています。Minikinレンダリングは、OpenType GSUBテーブルを完全にサポートしています。これより古いバージョンでは、サポートはデバイスメーカーやフォントエンジンのバージョンに依存します。
本文には、標準リガチャ (fi, fl, ff) で十分です — 読みやすさが向上し、ユーザーには見えません。任意リガチャは、見出しや装飾的なテキストでのみ使用してください。長いテキストでは読みやすさが低下するからです。
エディタがOpenType 'dlig' タグをサポートし、任意リガチャをレンダリングできる必要があります。VS Code、IntelliJ IDEA、Sublime Textはサポートしています。古いターミナルやエディタ (nano, GUIのなvim) はサポートしていません。エディタの設定でfont-ligaturesを有効にしてください。
まとめ
ターンキー方式のモバイルアプリケーションを開発します
IT Sectrは2017年からスタートアップや企業向けにiOS・Androidアプリケーションを開発しています。私たちがご相談に乗り、最適なソリューションをご提案します。