フォントもローカライズの問題 — グリフカバレッジ・フォールバック・豆腐文字

翻訳が一字一句正しくても、画面上では失敗することがあります。テキスト描画は2段階のプロセスで、文字列そのものが正しいことに加えて、それを描くフォントが文字列中のすべての文字に対応するグリフを実際に持っている必要があります。翻訳の確認を丁寧に行っているチームでも、この2段階目をまるごと見落とすことがあります。ラテン文字だけのプロジェクトではこの工程が失敗することがまずないため、意識する機会自体がないからです。この前提は、別の文字体系が加わった瞬間に崩れます。

グリフカバレッジと豆腐文字

フォントファイルは汎用のテキストレンダラーではなく、特定のコードポイントに対応づけられた固定のグリフ集合です。典型的なラテン文字用のUIフォントは、大文字小文字のアルファベット、数字、記号、いくつかのアクセント付き文字を含めて数百文字程度をカバーしています。これはかな・漢字にはまったく足りません。かな・漢字はまったく別の、はるかに大きな文字レパートリーだからです。

対応するグリフを持たないコードポイントの描画を求められたとき、フォントは黙って読み飛ばすことができません。多くの描画システムはフォント側の代替グリフ、俗に「豆腐文字」と呼ばれる中抜きの四角に置き換えます。フォントによっては別の「未定義グリフ」の輪郭が使われることもあります。いずれにせよ、テキストデータそのものは完全に正しいにもかかわらず、プレイヤーには翻訳された単語であるはずの場所に明らかに壊れた文字が見えます。

CJKフォントが大きい理由

フォントのファイルサイズは、主に定義しているグリフの数と、それぞれが持つ輪郭データの量で決まります。日本語のテキストだけでも、かなの音節文字に加えて数千種類の異なる漢字が日常的に使われ、実用的なカバレッジを目指すフォントはそのかなりの割合を含める必要があります。数百グリフのラテン文字用フォントと、数千グリフのCJKフォントとでは、この理由だけでサイズの桁が違ってきます。これは非効率ではなく、単純にレパートリーの差です。

フォールバックチェーン

現実的な解決策は「すべてをカバーする1本のフォント」(そんなものはほとんど存在しません)ではなく、フォールバックチェーンです。プライマリのフォントに加えて、それがグリフを持たないコードポイントに遭遇するたびに、描画システムが順番に試す1つ以上の代替フォントを用意します。これにより、UIは英語やラテン文字言語向けにデザインされたフォントをそのまま使いつつ、必要な文字だけCJKフォントにフォールバックできます。ラテン文字の商品名と日本語の説明文が1行に混在するようなケースも含めてです。

フォールバックはプラットフォームごと、描画経路ごとに設定する必要があります。エディタのプレビューで機能しているチェーンが、そのままビルド後のゲームに適用されるとは限りません。実行時のテキストシステムが独自に、別途設定されたフォールバックリストを持っていることがあるためです。

漢字統合 — 同じコードポイントでも期待されるグリフ形状は違う

UnicodeのCJK統合漢字ブロックは、中国語・日本語・韓国語で歴史的な起源を共有する文字に、あえて同じコードポイントを割り当てています。それらの言語の間で、慣用的に印刷される字形が字画のスタイルなどでわずかに異なる場合でもです。その差は、ある言語のネイティブ話者が、もう一方の言語で標準的な字形を見せられたときに「おかしい」とすぐ気づく程度のものです。

つまり、同じ文字データであっても、対象言語によって期待される描画結果が異なり得るということです。これがフォントの選択を「文字体系」単位ではなく「言語」単位で結びつけなければならない理由です。この2言語のうち、意図しないほうの言語向けに調整されたフォント(あるいはそのデフォルトのシェーピング)を使うと、技術的には正しい文字データが、ネイティブ話者から見て明らかに他言語っぽい字形で描画されてしまいます。

出荷前に確認すべき2点

見落としやすく、確認コストは低い2点です。

• 組み込みに関するライセンス条項 — フォントが無償で閲覧・使用できることと、配布するアプリケーションやゲームにそのフォントを組み込むことを許可するライセンスであることとは別問題です。ビルドにフォントを同梱する前に、組み込みおよび再配布に関する条項を具体的に確認してください。
• 翻訳レビューだけでなく、言語ごとの目視確認を行う — 文字列がすべての翻訳チェックを通過しても、実際にその言語で画面表示を確認していなければ、豆腐文字や誤った字形、句読点の欠落に誰も気づかないまま出荷されてしまいます。