FlowingDev

フォントの正体：文字を描画する小さなソフトウェアをこじ開ける

TTFやWOFF2からバリアブルフォントの軸までデジタルフォントの解剖学を学び、グリフ、カーニング、メタデータがWebのタイポグラフィをどう形作るかを解き明かそう。

ツールを試す: フォントインスペクター & グリフビューアー

一言でいうと

デジタルフォントは単なる小さな画像の集まりじゃない。ベクター数学、著作権に関する難解な法律用語、そして隠された置換ルールの詰まった、複雑で実行可能なソフトウェア・パッケージなんだ。

解決する問題

よく考えてみると、文字ってめちゃくちゃ主観的な概念だ。コンピューターが 0x41 というバイト列に遭遇したとき、それが「A」という文字を意味することは分かる。でも、「A」ってどんな見た目なんだろう？セリフ（飾り）はある？太い？斜体になってる？

デジタルスクリーンの時代になる前、タイポグラフィは物理的なものだった。印刷業者は鉛のブロックを並べていたんだ。デジタル時代が到来すると、ピクセルにどうやってこの形を描画するかを伝える方法が必要になった。最初はビットマップフォント（文字通りのピクセルのグリッド）を使ったけれど、拡大しようとした途端にギザギザの階段みたいになってしまった。

1980年代後半から90年代初頭にかけて、AppleとMicrosoftはタッグを組み、AdobeのプロプライエタリなPostScript (Type 1)フォーマットに対抗してTrueType (TTF)を作り上げた。これが「フォント戦争」の始まりだ。最終的に彼らが合意した解決策は、両方のアプローチを融合させたフォーマットであるOpenType (OTF)だった。その後、これらのファイルをWebで扱いやすくするために圧縮したのがWOFFとWOFF2だ。

今日の開発者にとっての問題は、フォントがブラックボックスのように振る舞うことだ。CSSに font-family: 'Inter'; と書いたとしても、実は何も見えていない。このファイルにキリル文字は本当に含まれているのか？ライセンス的に商用アプリへの埋め込みは許可されているのか？モダンなバリアブルフォントの軸（axis）をサポートしているのか、それともCSSで無理やり太字をでっち上げているだけなのか？これらの疑問に答えるには、フォントファイルそのものの中を覗き込み、メタデータを解凍し、内部のジオメトリを検査するレントゲン装置が必要になる。

裏側の仕組み

モダンなフォントファイル（TTFであれOTFであれWOFF2であれ）は、本質的には高度に最適化されたバイナリのリレーショナルデータベースだ。SFNTというコンテナフォーマットの上に構築されていて、データを明確な「テーブル」に整理し、それぞれを4文字のタグで識別している。

OpenTypeフォントの解剖学

フォントインスペクターがファイルをパースするとき、セントラルディレクトリを読み込んで以下のような特定のテーブルを探し出す：

タグ 名前 役割
cmap キャラクターからグリフへのマッピング 翻訳者。Unicodeの値（「A」なら U+0041）を特定の内部グリフIDにマッピングする。
glyf グリフデータ TrueTypeフォントで使われる実際のベクターアウトライン（2次ベジェ曲線）。
CFF Compact Font Format PostScriptベースのOpenTypeフォントで使われるベクターアウトライン（3次ベジェ曲線）。
name ネーミングテーブル メタデータ：フォントファミリー、デザイナー、著作権表記、ライセンスのURLなど。
kern カーニング 特定の文字ペアの字間ルール（例：大文字の「T」の下に小文字の「o」を潜り込ませるなど）。
GSUB グリフ置換 「f」と「i」を1つの「fi」リガチャ（合字）にするような、高度なタイポグラフィルール。

キャラクター vs グリフ

まず理解すべき最も基本的な概念は、**キャラクター（文字）とグリフ（字形）**の分離だ。

  • キャラクターは意味的な概念（Unicode）だ。「小文字のgという概念」を意味する。
  • グリフは描画されたものだ。フォント内に保存された具体的なベクター形状のことを指す。

1つのキャラクターが複数のグリフ（普通の「g」とお洒落なスワッシュ付きの「g」など）にマッピングされることもある。逆に、複数のキャラクターが1つのグリフにマッピングされることもある（fとiというキャラクターが、1つのリガチャグリフfiに置き換えられる場合など）。cmapテーブルとGSUBテーブルが、このめちゃくちゃ複雑なルーティングを処理している。

バリアブルフォント (Variable Fonts)

歴史的に、Regular、Bold、Italicの書体を使いたい場合は、3つの別々のファイルを読み込む必要があった。2016年にOpenTypeの拡張として導入されたバリアブルフォントは、この常識を覆した。

バリアブルフォントは静的なアウトラインの代わりに、マスターアウトラインと数学的なデルタ（差分）のセットを（fvarテーブルとgvarテーブルに）保存する。このデルタが、さまざまな**軸（axes）**に沿った補間のための「デザインスペース」を定義するんだ。

標準的な5つの軸は以下の通り：

  • wght: ウェイト (Thin から Black まで)
  • wdth: 字幅 (Condensed から Expanded まで)
  • ital: イタリック (On または Off)
  • slnt: スラント (文字の傾斜角度)
  • opsz: オプティカルサイズ (フォントの表示サイズに合わせて形状を微調整する)

CSSでバリアブルフォントの軸にマッピングする場合はこんな感じになる：

/* ウェイトを430に、スラント（傾き）を少しだけ設定する */
h1 {
  font-family: 'MyVariableFont', sans-serif;
  font-variation-settings: 'wght' 430, 'slnt' -5;
}

Web圧縮 (WOFF2)

WOFF2 (Web Open Font Format 2) は根本的に新しいフォントタイプというわけじゃない。TTFやOTFファイルを包む単なる圧縮ラッパーだ。Brotli圧縮アルゴリズムを使っていて、特にSFNTのテーブル構造を理解するように最適化されているため、オリジナルのWOFFと比べてファイルサイズが約30%小さくなる。ブラウザがWOFF2をダウンロードすると、グラフィックエンジンに渡す前に、メモリ上でこっそりと標準のOpenTypeフォントに解凍しているんだ。

現場のリアルな話

見えないキリル文字のサボタージュ

あるフロントエンド開発者が、流行りのオープンソース書体を使ってグローバルなマーケティングサイトを構築するタスクを任された。英語とスペイン語ではすべてがピクセルパーフェクトに見えた。しかし、ローカリゼーションチームがCMSにロシア語のコンテンツを入力した途端、美しいサンセリフ体は突然、スタイルのない醜いTimes New Romanのフォールバックに先祖返りしてしまった。

その開発者は、フォントが「モダン」だから主要言語はすべてサポートしていると思い込んでいたんだ。cmapテーブルを調べてみると、残酷な真実が判明した。そのフォントにはASCIIと基本的なラテン文字のグリフしか含まれていなかった。キリル文字のUnicodeブロックは完全に空っぽだったのだ。ここから得られる教訓は？自分の目でグリフのカバレッジを確認せずに、フォントの言語サポートを盲信してはいけないということだ。

3メガバイトの大失態

あるデザインエージェンシーが、カスタムブランドフォントの9種類の異なるウェイト（HairlineからUltraBlackまで）を使った野心的なWebプロジェクトを引き継いだ。開発者は真面目に9つの .ttf ファイルすべてをCSSで読み込んだ。その結果、タイポグラフィだけで3MBという壊滅的なペイロードが発生し、モバイルネットワークでのレンダリングに大遅延を引き起こしてしまった。

フォントファミリーのソースを調べた開発者は、同じ書体の単一のバリアブルフォント版（.woff2）を発見した。9つの静的ファイルを1つのバリアブルフォントに差し替えることで、ペイロードを120KBにまで減らすことができた。パフォーマンスが爆上がりしただけでなく、ホバー状態での wght 軸のアニメーションもスムーズにできるようになった。

脅迫状のような法律用語

あるスタートアップが新しいiOSアプリのローンチを急いでいた。UIデザイナーは、プライマリボタンに使うために適当なタイポグラフィのブログから「無料」のフォントを拾ってきていた。App Storeへの申請の2日前、シニアエンジニアがフォントのメタデータを調べてみることにした。

nameテーブルの中には、5,000ドルの商用ライセンスなしでコンパイルされたモバイルアプリにフォントを埋め込むことを明確に禁じる文字列が、はっきりと書かれていた。この埋もれていたEULA（エンドユーザー使用許諾契約）に気づいたことで、スタートアップは著作権訴訟やアプリの強制削除の危機から救われた。フォントはソフトウェアであり、そのバイナリの内部に法的な荷物を抱え込んでいるんだ。

よくある間違いと罠

  • 太字と斜体の偽装 (Faux-bold / Faux-italic): CSSで font-weight: bold; や font-style: italic; を適用しているのに、実際にBoldやItalicのフォントファイルを読み込んでいない場合、ブラウザはRegularフォントを合成的ににじませたり歪めたりする。この「なんちゃってボールド（faux-bolding）」は、デザイナーが丁寧に作り上げたベクター形状を台無しにしてしまい、見た目も最悪だ。
  • ライセンスの無視: .ttf ファイルがダウンロードできたからといって、それをWebで配信したりアプリにバンドルしたりする権利があるとは限らない。必ずメタデータを読もう。
  • 肥大化したサブセットの配信: 人気のあるフォントの多くには、絶対に配信しないような言語のための数千ものグリフが含まれている。英語のキャラクターしか必要ないのに400KBのフォントファイルを配信するのは、帯域幅の壮大な無駄遣いだ。フォントを検査してその肥大化具合を確認し、サブセット化ツールを使って使わないグリフを取り除くべきだ。
  • OpenType機能がデフォルトで有効だと決めつける: 多くのフォントには、美しいリガチャ（合字）、代替文字スタイル、あるいは等幅数字（すべての数字が全く同じ幅になっていて、料金表に最適）が含まれている。しかし、これらはしばしば liga や tnum のようなOpenTypeタグの背後に隠されている。フォントを調べてそれらの存在を知らなければ、CSSの font-feature-settings を使ってアクティブにすることはできない。

なぜ知っておくべきなのか

タイポグラフィはWebの絶対的なコアだ。一般的なWebサイトのデザインの最大90%は単なるテキストで構成されている。開発者がフォントを「テキストを飾る魔法の粉」のように扱っていては、パフォーマンスの問題やレイアウトのバグを引き起こすだけだ。

Webのパフォーマンスを最適化する際には、必ずフォントのインスペクト（検査）について考える必要がある。巨大なフォントファイルは、Cumulative Layout Shift (CLS) や、あの忌まわしい Flash of Unstyled Text (FOUT) の原因になる。裏側を覗き込むことで、フォントが適切に圧縮されているか（WOFF2）、サブセット化できるか、あるいは完全にバリアブルフォントに置き換えられるかを確認できる。さらに、国際化（i18n）に足を踏み入れるときはいつでも、対象とする言語が実際にレンダリングされることを保証するために、フォントのグリフテーブルを監査できなければならない。

フォントの内部ロジックをマスターすれば、ただ font-family と打ち込むだけの人から、ブラウザが画面上の最も重要なコンテンツをどのように描画するかを深く理解している人へと、自分をレベルアップさせることができるんだ。

さらに深掘りする

理論はOK。さあ手を動かそう — 100%ブラウザ内で。

ツールを試す: フォントインスペクター & グリフビューアー