PDFのフォント環境

フォント埋め込みの重要性

DTPでPDFを使うメリットとして、アプリケーションのデータよりも安全な出力が保証されるということがよく挙げられます。実際には、PDFにも色々なデータがあり、必ずしも安全に出力できるとは限りませんが、一般的なDTPデータよりも安全であると言われる根拠の一つが、PDFにフォントを埋め込めるという点です。

DTPが始まったころから今にいたるまで、出力トラブルの多くを占めてきたのがフォントがらみの問題です。DTPの場合、データを制作する環境と出力する環境の双方に同じPostScriptフォントがなければならないということが、トラブルを生む最大の要因でした。

データを作るマシンのフォント環境、出力するマシンのフォント環境、そしてプリンタに搭載されているフォント環境が同じでなければ文字化けなどを招いてしまうというのは、考えてみればかなり不自由な仕組みです。

パソコン上のフォントデータをプリンタに送って出力できるOpenTypeフォントを使えば、プリンタ搭載のフォント環境の問題はなくなりますが、それでもデータ制作マシンと出力するマシンのフォント環境が合っていなければならないという点は変わりません。データを作る側と出力する側が異なる場所や環境であることが多いDTPでは、フォントに関連する出力トラブルは依然として大きな割合を占めているのが現状なのです。

PDFは文字データをデータに埋め込むことが出来るという点が大きな特徴です。制作側で文字そのものをデータに埋め込むことができれば、出力するマシンにそのフォントがなくても文字化けを気にすることなく出力することが可能です。つまり、PDFを作成する環境できちんと文字を埋め込むことさえできれば、環境にかかわらずどんな出力現場でもトラブルなしに出力できるというわけです。

文字化けや文字抜けは、一歩間違えると重大な印刷事故につながりかねません。そういう事故を防ぐという点で、PDFには大きなメリットがあるのです。

ただし、文字関連のトラブルを防ぐためには、PDFに文字がきちんと埋め込まれていなければなりません。言い換えると、PDFをDTPで使うには、文字が埋め込まれていることが大前提だということになります。

PDFに埋め込めるフォントの種類（フォーマット）は、OpenType、TrueType、CID（sfnt-CID）、欧文Type1フォントです。OCFフォントおよび一部のCID（Naked-CID）フォントは埋め込むことができません。また、埋め込める種類であってもフォントメーカーが埋め込みを許可していないフォントは埋め込めません。

PDFのデータ内で使われているフォントが埋め込まれているかどうかを確かめるには、AcrobatでPDFを開き、「プロパティ」の「フォント」タブをチェックします。そこに現れるフォント一覧で、フォント名の横に「埋め込み」または「埋め込みサブセット」となっていればそのフォントが埋め込まれていることを意味します。

逆に「埋め込み」という表記がなく、「実際のフォントの種類」などという記述があればそのフォントは埋め込まれておらず、環境によって異なるフォントが使われてしまうということになります。その場合は、フォントを埋め込める環境でデータを作るか、Acrobat上で文字を埋め込むといった処理が必要です（特別なツールがなくてもAcrobatのプリフライト機能でフォントを埋め込むことができる）。

フォントのエンコーディング

フォントが埋め込まれていれば、PDFの出力時にはその埋め込まれているフォントデータが使われるため文字化けは起きないはずです。ところが、フォントが埋め込まれていても文字化けが絶対に起きないというわけではありません。

支給されたPDFをInDesignなどに貼り込んで、それをさらにPDFに書き出したりするような場合、PDFに含まれるフォントのエンコーディングによってはきちんと文字が出力できないことがあります。また、画面上はきちんと表示され、出力も問題ないのにテキストをコピーすると別の文字になってしまうということもあります。

エンコーディングとは文字を定義する方式のことであり、Acrobatのフォント一覧を見ると表示されています。たとえば、「90ms-RKSJ-H」とあれば、Windowsの文字セット（90ms）を使い、シフトJISでエンコーディング（RKSJ）された横組み（H）という意味になります。

Acrobatは、主なエンコーディング（文字コード）の文字セットとフォント固有の文字番号（GIDまたはCID番号）の対照テーブル（CMap）を用意しています。これによって、確実にその文字データにアクセスし、表示・印刷することができるわけです。

文字が埋め込まれたPDFが生成される際、ドキュメントデータに文字コードではなくGIDだけが保存される場合があります。その場合、PDFビューワソフトは、このGIDでフォントデータからグリフを呼び出して表示します。一方、テキストをコピーするときは、文字コードでないGIDだと文字としての情報が抽出できないので、GIDから文字コードの情報に戻す必要があります。そのための対照テーブルがToUnicode CMapです（どのPDFにも必ずあるわけではない）。ToUnicode CMapはGIDとUnicodeの対照テーブルで、PDFのテキストをコピーする際などは、選択したテキストのGIDからToUnicode CMapを参照してUnicodeを割り出します。

文字コードとGIDが一対一の関係であればこの仕組みで問題は生じません。ところが、cmapの中には一つのGIDに対応する文字コードポイントが複数あるものがあります。

例えば、あるフォントでAという文字（コード）とBという文字が、どちらもCというGID（＝字形）に紐づけられているとします。Aを含むデータをPDFに書き出す際、AはCに変換され、この情報がPDFに保存されます。同時にToUnicode CMapが生成されますが、その際、CとAではなくCとBが紐づけされてしまうと、PDFのテキストをコピーする際にCからBへの変換が行われ、文字化けが起きてしまうわけです。

この問題は、トラブルになるようなToUnicode CMapを書いてしまう書き出しアプリケーションとフォントに原因があると言えます。

小塚書体などDTPで使われるフォントは、ほとんどAdobeJapan1に準拠しており、PDFの書き出しもInDesignやIllustratorを使うのが一般的です。こういった場合は、問題になるようなToUnicode CMapが作られる心配はほとんどないでしょう（多くのPDFビューワにAdobeJapan1で使えるToUnicode CMapが用意されている）。しかし、たとえばWebブラウザから書き出したPDFなどは、テキストをコピーした際に文字化けする可能性があります。

ちなみに、Acrobatに用意されているCMapの数や種類は言語バージョンによっても異なり、たとえば英語版だと、日本語や中国語のCMapがないことがあり得ます。「Identity-H」および「Identity-V」は通常の文字コードを使わずCID番号を文字コードとして直接指定するCMapであり、フォントが埋め込んであればどのAcrobatでも表示が可能です。この場合も、きちんと対応したToUnicode CMapがあれば文字化けせずにテキストをコピーできるわけです。

また、場合によってはエンコーディング方式が表示されないことがあります。Acrobatのフォント一覧に「カスタム」とか「ビルトイン」と表示されるケースです。

「カスタム」では、フォントの文字が文字形状データごとPDFに埋め込まれています。この場合、フォントの文字を定義しているのは一般的に使われているエンコーディングではないため、テキストをコピーしてもエディタなどに正しくペーストできないことがあります。

「ビルトイン」は、フォントの文字データやエンコーディング情報が埋め込まれるというものです。エンコーディング情報がPDFに含まれているためコピーなども可能なはずですが、場合によっては文字化けが起きます。また、Acrobatの表示と出力で結果が異なったり、アウトライン化すると文字が化けるということもあるようです。

環境に依存しない文字環境を提供するという点でメリットが大きいPDFですが、その限界もあるということは覚えておくほうがいいかもしれません。

（田村　2007.9.3初出）

（田村　2022.12.12更新）