翻訳後にフォントが崩れる理由

OpenL Team 7/24/2026
翻訳後にフォントが崩れる理由

TABLE OF CONTENTS

翻訳された文書は、正しい単語が入っていても見た目が崩れることがあります。文字の欠落、予期しないフォント変更、分離した文字、文章のはみ出しは、通常それぞれ別の問題なので、原因に応じた対処が必要です。

短い答え

元の書体が対象言語を表示できない場合、またはファイルを開くシステムに書体がなく、書き出したPDFにも埋め込まれていない場合、翻訳後にフォントが崩れて見えます。スクリプトによっては、単純なフォント置換では提供できない字形処理とレイアウト対応も必要です。また、フォントは正しく動作していても、翻訳文が原文より多くの領域を使うことがあります。

見えている症状から、考えられる原因を特定します。

見えるもの考えられる原因最初に試す修正
空の四角やボックスフォントに必要な字形がない対象スクリプトに対応するフォントへ変更する
異なる書体元のフォントがない、または埋め込めないフォントをインストール、置換、または埋め込む
崩れたアラビア語やインド系文字アプリ、フォント、書き出し処理に適切な字形処理がないスクリプトに対応するソフトウェアでファイルを開く
切れたり重なったりする文章翻訳文により多くの空間が必要テキスト枠のサイズを変更するかレイアウトを調整する
あるPCでは正常だが別のPCでは崩れるファイルがローカルにインストールされたフォントに依存しているフォントを埋め込むか、広く利用できる代替フォントを使う

フォントはすべての文字を含むわけではない

Unicodeは各文字に番号を割り当てますが、Unicode自体はフォントではありません。Unicode Consortiumの説明では、フォントがその文字番号を目に見える字形へ対応付けます。書体にその文字の字形がなければ、アプリケーションには描画できるものがありません。

そのため、ラテン文字だけの表示フォントを使った英語文書をアラビア語、ヒンディー語、タイ語、中国語などへ翻訳すると、四角に変わることがあります。小規模なカスタムフォントが基本的な英語文字しか含まない場合、アクセント付きラテン文字も表示できないことがあります。

最も確実な修正は、対象の書記体系を確実にカバーする書体を選ぶことです。GoogleのNotoコレクション は1,000以上の言語と150以上の書記体系をカバーしており、ブランドフォントが必要な文字に対応していない場合の出発点になります。すべての言語に1つのフォントを使う必要はありません。文書化したフォントマップの方が適切なこともあります。

コンテンツフォント戦略の例
ラテン、ギリシャ、キリルカバレッジが完全なら互換性のある1つのファミリーを使う
アラビア語またはヘブライ語スクリプト向けに設計されたファミリーを選び、右から左のレイアウトをテストする
中国語、日本語、韓国語正しい地域向けファミリーを選び、句読点と改行を確認する
デーヴァナーガリー、タイ語などの複雑なスクリプト最終アプリケーションで結合文字と字形処理を確認する

フォントの置換は文書を変える

文書はフォント名を指定していても、ファイル内にフォントデータを持っているとは限りません。その書体がないPCで開くと、ソフトウェアは代替フォントを選びます。置換後のフォントは元より幅広く、狭く、高く、または見た目が大きく異なる場合があります。

PDFへの埋め込みはこのリスクを減らします。Adobeの説明では、埋め込みフォントはPDF内に含まれるため、別のシステムで表示または印刷しても置換されません。PDFにはフォント全体、または文書で使われた文字だけのサブセットが含まれます。埋め込みはフォントベンダーのライセンスによって制限されることがあります。

完成したPDFではサブセット化が効率的ですが、後でファイルを編集すると問題になることがあります。英語の原文から作ったサブセットに、翻訳に必要な新しい文字が含まれていない可能性があるためです。編集可能な作業では、元のDOCX、PPTX、デザインファイルを保管し、最終PDFをマスターとして扱うのではなく、翻訳後に新しいPDFを書き出してください。

PDFの書式がすでに壊れている場合は、書式を失わずにPDFを翻訳するガイドの確認項目を使ってください。

スクリプトによっては字形以上のものが必要

フォントに正しい文字があることは必要ですが、十分とは限りません。アラビア文字は単語内の位置に応じて形が変わります。多くのインド系スクリプトは子音、母音、記号を結合して字形クラスターを作ります。伝統的モンゴル文字は位置ごとの形と縦書きレイアウトを使います。

Unicode Consortiumは、フォントはテキスト描画システムの一要素にすぎないと説明しています。アプリケーションとその字形エンジンも、フォントの規則を正しく解釈しなければなりません。これにより、現代的なブラウザでは正しく見える文が、古いソフトウェアで書き出すと分離したり位置がずれたりする、というよくある失敗を説明できます。

この場合は次のようにします。

  1. 短いサンプルを現在のブラウザまたはワープロに貼り付けます。そこで正しく表示されるなら、元のアプリケーションまたは書き出し処理が原因である可能性が高いです。
  2. そのスクリプトに対応することが分かっているフォントを試します。
  3. 段落の方向と言語設定を確認します。
  4. 複雑なスクリプトに対応した最新のソフトウェアから再度書き出します。
  5. 編集可能な原稿だけを信用せず、最終PDFを確認します。

文字の拡張はフォントの問題に見える

翻訳によって文字数と文字幅の両方が変わります。W3Cは、英語と中国語は特にコンパクトな原文言語なので、そこからの翻訳は長くなることが多いと説明しています。短いラベルは段落全体より大きく膨らむことがあり、書記体系によってはより多くの縦方向の空間も必要です。

すべての字形が正しくても、結果はフォントの失敗に見えることがあります。単語が余分な行に折り返され、見出しが画像とぶつかり、表の行が伸び、ソフトウェアが読めない大きさまで文字を自動縮小するためです。

フォントを小さくする前に、入れ物を調整します。

  1. テキスト枠の幅や高さを広げます。
  2. 見出しと表の行で折り返しを許可します。
  3. 原文言語から引き継いだ手動改行を削除します。
  4. 段落間隔と行の高さを調整します。
  5. 安全にレイアウトを変更できない場合に限り、文字サイズを小さくします。

スライド固有の確認については、PPTX翻訳QAチェックリストを参照してください。InDesignユーザーは、IDML翻訳ガイドのフォントとオーバーフローの確認項目も利用できます。

実践的な修復ワークフロー

1. 症状を特定する

すぐにすべてのフォントを置き換えないでください。問題が字形の欠落、置換、字形処理、オーバーフローのどれなのかを判断します。フォントを一括変更すると、元の原因を隠し、新しいレイアウト問題を作ることがあります。

2. 編集可能な原稿に戻る

利用できる場合は、DOCX、PPTX、スプレッドシート、デザインファイルを使います。原稿ファイルは、平坦化されたPDFよりも段落、表、テキスト枠を確実に保ちます。

3. フォントマップを作る

対象スクリプトとウェイトごとに承認済みフォントを記録します。標準、太字、斜体、記号を個別に確認してください。ファミリーが標準書体ではスクリプトに対応していても、すべてのスタイルで対応しているとは限りません。

4. ファイルを平坦化せずに翻訳する

文書の文章をプレーンテキストボックスへコピーすると、スタイルとレイアウトを制御する構造の多くが失われます。形式が対応している場合は、代わりに元ファイルを文書翻訳サービスへアップロードします。OpenL Doc Translator はその選択肢の1つです。どのツールでも、出力にはフォントとレイアウトの確認が必要です。

5. フォントを埋め込んで書き出す

ライセンスが許す場合は、最終PDFに必要なフォントを埋め込みます。AcrobatではDocument Propertiesを開き、Fontsタブでフォントが埋め込まれているか、サブセット化されているかを確認できます。

6. 納品ファイルをテストする

原文フォントがインストールされていない端末で結果を開きます。通常の倍率ですべてのページを確認し、対象言語の文章を検索して、PDFからサンプル文をコピーします。見た目だけでは、基礎となる文章が利用可能だとは証明できません。

納品前の確認項目

  • 空の四角、箇条書き記号、置換文字がない。
  • アラビア語、インド系文字、その他の字形処理が必要なスクリプトが正しくつながり、配置されている。
  • 太字、斜体、上付き文字、記号が正しく表示される。
  • 見出し、表、キャプション、脚注がはみ出していない。
  • ライセンスが許す範囲で、PDFにフォントが埋め込まれている。
  • 検索、選択、コピー&ペーストが機能する。
  • 2台目の端末でも文書が正しく表示される。

重要なのは、フォントのカバレッジ、フォントの利用可能性、スクリプトの描画、レイアウトを別々に確認することです。どの層が失敗したかを特定できれば、修復は通常簡単です。

Sources