フォントとPDFへの埋め込みについて (続き)

 前々回、前回と調べてきたNoto Sans JPフォントを埋め込むと正常なPDFが生成されない件について、少し進展がありましたので調べた内容を書いていきたいと思います。

簡単にまとめてしまうとNoto Sans JPフォントが (仕様として正しいかどうかまでは確認できませんでしたが) 多少気持ち悪い作りになっていたため、PDF生成ソフトウエアがうまく処理できなかったことが原因だろうという結論となりました。

Noto Sans JPフォントはOTFフォント (CFF形式) で作られていて、OTFフォントはざっくり言うとTrueTypeフォントの字形データの代わりにCFF形式のCIDフォントデータを使用したものになります。

フォントとPDFへの埋め込みについて (続き)

 前回調べたNoto Sans JPの文字化けに関して、cmapを確認してみました。

このフォントには以下の5種類のcmapテーブルが実装されていました。

• Platform 0 / Encoding 3 (Unicode BMP only)
• Platform 0 / Encoding 4 (Unicode full repertoire)
• Platform 0 / Encoding 5 (Unicode Variation Sequeces)
• Platform 3 / Encoding 1 (Windows Unicode BMP)
• Platform 3 / Encoding 10 (Windows Unicode full repertoire)

簡単にまとめると16ビットのUnicodeからCIDを引くcmapと32ビットのUnicodeからCIDを引くcmap、そして異体字セレクタ (別字形を選択するためのコード) を含むUnicodeからCIDを引くcmapの3種類が登録されています。

これらのcmapの内容を確認したところ、すべて前回調べたToUnicode cmapに登録されているCID値が設定されており、Microsoft Print to PDFの出力が (文字化けするけど) 正しい値を指定していることがわかりました。

cmapには問題がなさそうなので、次はCFFテーブル (フォントデータ本体) を調べてみようと考えています。

フォントとPDFへの埋め込みについて

 最近、PDFへのフォント埋め込みで気になることがあったので、フォントについて少し調べてみました。