Acrobat 4.0Jでは、フォント置換に対応できていない
書体が存在する?

 以前、KozMin-Regularと、KazMin-BoldがArialMTに置換されてしまい、文字化けが発生したということを『今日の一言』で書かせていただいたのであるが、どうも事は複雑そうである。少し厄介な問題と判断したので、ここに書かせていただくことにした。
特に、(PDFにて)データを入稿される方々に、読んでいただけると幸いである。

厄介なのは、以下の書体である

  • リュウミンL-KL(OCF)
  • 中ゴシックBBB(OCF)

●最初に結論

 最初に結論を書かせていただくが、この2つの書体は、私の環境の場合は、Acrobat 4.0Jにてフォントをエンベット(OCFはエンベット不可能)せずにPDF変換を行い、Acrobat Reader 4.0JにてPDFを開くと、同じ書体(OCF)がインストールされている環境であっても文字が置換される。
(同じアウトラインフォントを使用することの可能である、漢字Talk7.1.2にバンドルされていた、細明朝体と、中ゴシックも同様)
 又、上記の書体のCID形式がPDFに使用されていたとしても、PDFを開く側のシステムにOCF形式のリュウミンL-KL、中ゴシックBBBがインストールされていると、リュウミンL-KL、中ゴシックBBB以外の書体に置換されてしまう。
 
リュウミンL-KL(OCF)と中ゴシックBBB(OCF)の2書体は、PDFを開く側のシステムにOCF形式ではなく、CID形式の書体がインストールされていないと、正常に表示されないということである。

 縦軸=PDF変換時の書体 ◆横軸=PDFを開く側のシステム内書体

 ○=フォントが置換されず正常に表示
 −=テストを行っていない

OCF CID
(LWFN)
CID
(SFNT)
同書体無
リュウミンL-KL
(OCF)
他書体へ置換
(CID)
OSAKA
ArialMT
他書体へ置換
(CID)
OSAKA
ArialMT
中ゴシックBBB
(OCF)
他書体へ置換
(CID)
OSAKA
ArialMT
他書体へ置換
(CID)
OSAKA
ArialMT
リュウミンL-KL
(LWFN)
他書体へ置換
(CID)
OSAKA
ArialMT
中ゴシックBBB
(LWFN)
他書体へ置換
(CID)
OSAKA
ArialMT
リュウミンL-KL
(CID)
他書体へ置換
(CID)
OSAKA
ArialMT
中ゴシックBBB
(CID)
他書体へ置換
(CID)
OSAKA
ArialMT
リュウミンU-KL
(OCF)
存在しない 他書体へ置換
(CID)
OSAKA
ArialMT
ヒラギノ明朝体3
(OCF)
存在しない 存在しない 他書体へ置換
(CID)
OSAKA
ArialMT
ヒラギノ角ゴ2
(OCF)
存在しない 存在しない 他書体へ置換
(CID)
OSAKA
ArialMT
平成明朝 W3
(CID)エンベッド
存在しない

●リュウミンL-KLと中ゴシックBBBの歴史

まず最初に頭に入れておいてほしいのが、上記の2書体は、

  • CID(LWFN)
  • OCF
  • CID(SFNT)

と複数の形式が存在しており、いずれもPostScriptフォント(Type0)と呼ばれているものである。
 SFNT形式とは、いわゆるGX対応フォントである。LWFN形式とは、他の欧文フォントと同じ形式であり(Type1)日本語フォントの形式としては、特殊の部類に入ると思う。このLWFN形式のフォントは、Adobe Type Manager 3.8Jにバンドルされていた書体であり、実は、ATMに完全に対応している書体である(この言葉には深い意味があるがおわかりであろうか)。

●詳細説明

 私が行ったテストでは、CID(SFNT)、OCF、CID(LWFN)それぞれの書体をシステムに交互に入れ替え、Illustrator8.0.1Jにて、PDFに変換。どのようなフォント置換が行われるかをテストした。
 又、Acrobat Distiller 4.0でもPDF変換を行い同様のテストを行った。

 上記の形式で、置換が発生するのは、モリサワ書体では最も普及していると思われる、OCF形式である。
 CID(SFNT)と、CID(LWFN)をPDFを開く側のシステムにインストールしていれば、PDFを作成した側がOCFであっても、置換されることは無いようである。

 Acrobat 4.0Jの場合は、OCF形式のフォントを使用してPDFに変換し、そのPDFに使用されているOCF形式のフォントがPDFを開く側のシステムに存在しない場合は、ArialMT(1バイト欧文)に置換される(欧文フォントであるので文字は化ける)場合が多いようである。しかし、私の環境で行った場合、HiraginoKaku-W2の場合は、OSAKAに置換され、何とか読むことは可能であった。
 実は、ArialMTに置換されるか、OSAKAに置換されるかは、開いてみないと分からない状態であるとしか言えない。PDFを開くと以前はOSAKAに置換されたはずのものが、次ぎに開く時には、ArialMTに置換されたりすることがある。
 どなたか、この仕組みを知っている方がおられたらメールにて知らせて下さるとありがたい。

 PDFに使用されている、OCF形式の同じ書体が開く側のシステムにインストールされていない場合は以下のような置換処理が行われるようである。

  • 開く側にCID形式のフォントが1書体入っている場合は、全ての(OCF)書体が、その1書体に置換されるようである。
  • CID形式のフォントが1書体もインストールされていない場合は、OSAKAかArialMTに置換されるようである。
  • 当然、PDFに使用されている書体(OCF)がシステムにインストールされていれば、その書体で表示されるが、リュウミンL-KL(OCF)、中ゴシックBBB(OCF)は、例外である。

●IllustratorPDFと、DistillerPDFの違いにおいて気付いたこと

 llustrator8.0.1Jで直にPDF変換を行うと、日本語フォントの1バイト部分が表示されないという現象にも遭遇した。(Distillerでは発生しない)しかし、Acrobat Reader 4.0Jから『和文フォントをダウンロード』のチェックを入れずPS出力機から出力を行った結果、その出力機にフォントがインストールされていれば、正常に出力が行えるようである。
 QuarkXPressを代表するレイアウトソフトでは、システムにフォントがインストールされていない状態で出力を行うと、字送りの狂いが発生し、実質的には出力は不可能であるが、PDFの場合は、当然かもしれないが、字送りの狂いなどは、発生しない。

●最後に

 リュウミンL-KL(OCF)、中ゴシックBBB(OCF)の問題は、“●リュウミンL-KLと中ゴシックBBBの歴史”で書いたように、この2書体は、少々歴史が複雑であり、特殊な存在であると私自信は判断している。
 しかし、上記の2書体だけの問題ではないかもしれない。PSフォントは、一応Adobeの仕様書に準じて設計されているはずであるが、FONTWORKSPlus書体のように独自に外字が扱えるようにしている書体も存在するし、OCFであるのに、字体(字形)切替機能に対応している書体も存在する。カスタマイズが可能なのである。
 又、オープンな環境では、各々のシステムの構築状況により、発生することもあるが発生しないこともある。
 すくなくとも、私の環境では、上記のようなことが発生している。
これは、情報として受け止めてほしい。そして、各自確認を行い、Acrobat 4.0Jをうまく使いこなしてほしい。

 また、何か状況が変化次第、このサイトに情報として発信するつもりである。

(990821)


Copyrignt (c) 1999 NOBUO KONDOU, All rights reserved.