MacOS8.6とフォントの問題（その2）
―OCFビットマップフォントも正常に表示された―
前回のこのコラムで、MacOS8.6でOCFビットマップフォントが縦組みで文字化けすると書いたが、たくさんの人に情報をいただいき、いろいろと試した結果、これを正常に表示することが可能になった。右は前回問題にしたものと同じサンプルだが、リュウミンR-KLのビットマップが正常に表示されている。もちろん拡大しても大丈夫だ。
前回はビットマップがガタガタだったし縦組みの約物が文字化けしていた。その後、縦組み横組みにかかわらず、丸数字などの記号類も文字化けすることがわかった。
記号類は別として、縦組みの約物についてはフォントメーカーもアナウンスしていたことなので、まだ問題が解決できていないものと思っていたが、「自分のところでは正常に表示されている」という情報をいただいた。ならば私のところでも同じはずと思い、いろいろと試すなどしてこのところすっかりハマッてしまった。そこで、以下に解決に至った経過のエッセンスを紹介しようと思う。
■「丸漢コンパチ縦書サポート」をインストールする
MacOS8.5以降のシステムは丸漢ファイルをサポートしなくなった。そのためシステムインストール時に入るフォントにも、各フォントに対応する丸漢ファイルは含まれていない。その代わりに「丸漢コンパチビリティ」という丸漢ファイルが加わっている。
アップルの解説によると、これまでのシステムでは文字種がない文字を表示する場合に「Osaka」の丸漢フォントから借りてきていたが、8.5以降はその役割を「丸漢コンパチビリティ」がするのだという。だからこれは、「一言でいってしまうと昔の Osaka の丸漢ファイルです」と、同解説では述べている。
ところがこの「丸漢コンパチビリティ」は縦組みの約物の文字種を持っていないという。それが縦組みで約物が文字化けする原因だ。そこに縦組みの約物を追加するのが「丸漢コンパチ縦書サポート」で、これによって基本的に縦組み表示は解決する。エヌフォー・メディア研究所からダウンロードできる（同社製品ユーザー以外は使用料3,000円が必要。9/4追記）。
この情報を教えていただき、喜び勇んでさっそくダウンロードしてインストールしたが、Illustrator5.0、同8.0での約物は解決したものの、なぜかQuarkXPress3.3ではまったく解決しなかった。
■「Font Manager Updater」をインストールする
アップルから最近ダウンロード可能になったファイルに「Font Manager Updater」がある。MacOS8.6のFont Managerは「破損 FOND リソース」「誤った文字の高さ」という問題を引き起こす場合があるそうだが、これが起こらないように修正するファイルだという。私もさっそくダウンロードしてインストールした。しかし、やはり変化はなかった。
丸数字や（株）などの記号類がTrueTypeフォントの文字コード（つまり括弧曜日など）で表示されること、試しに「丸漢コンパチビリティ」「丸漢コンパチ縦書サポート」を外してみると、ビットマップフォントの全文字が文字化けしてしまったあたり、結局オリジナルのビットマップを使えていないわけで、ビットマップデータが壊れたような印象があった。
フォントスーツケースを「ResEdit」で開くと、確かに「FOND リソース」なるものも含まれている。これが破損したのなら、「Font Manager Updater」に付属の「Font First Aid」での検証でひっかかるはずだが、なぜかひっかからない。そればかりか、エラーになってしまった。「Disk First Aid」で修復したり、P-RAMクリア、デスクトップ再構築なども試したが、いっこうに変化がない。
しかし、いくつかのフォントスーツケースを「ResEdit」で開こうとすると、「ダメージを受けている」とのメッセージが出た。「Font Manager Updater」は、破損したファイルを修正するものではなくて破損しないようにするものだから、これを入れる前にインストールしていたフォントがすでに壊れていれば効果はないことになる。
そこで、正常に表示されるビブロス外字フォント以外のモリサワ、ニス、創英、ダイナフォントをまるごと入れ替えることにした。すると、意外なことが明らかになった。
■意外な犯人
まず、該当のフォントを全て外して再起動する。この段階でまず表示を確かめる。すると残っているフォント、つまりシステムインストール時に入るフォントでの表示は正常だった。ま、これは当然で、ここで問題が起こっては困る。
続いてモリサワの「リュウミン」をいくつかインストール。再起動後に表示を確かめると、おお！ 正常に表示されているではないか。もちろん丸数字などの記号類も正常。何より、見た目のビットマップそのものがいつもの通りで正常だ。よっしゃ！ と喜んで、順次フォントをインストールした。
この段階では、やはり「Font Manager Updater」インストール前にすでにフォントが壊れていて、今回はこれが効いているから破損しないのだろうと思っていた。もちろん「丸漢コンパチ縦書サポート」のおかげでもあることは明らかだ。
ところが、最後にダイナフォントをインストールして表示を確かめたら、前と同じ文字化け状態に戻ってしまった。すぐにダイナフォントを外すと正常に戻る。するとダイナフォントが犯人だったのか？
ここで気になったのはこのフォントのインストーラだ。MacOS8.5以降では、フォント関係ファイルをシステムフォルダに重ねてインストールすると、フォントスーツケースとPSフォントファイルだけがフォントフォルダに入り、丸漢ファイルはシステムフォルダの第一階層に入っている。だから丸漢ファイルは手動でフォントフォルダに入れなければならない。
ダイナフォントのインストーラは、これを全部フォントフォルダにインストールする。手間が省けてよいと思っていたが、どうやらこの時に不具合が発生したのではないかと予想した。
そこでインストーラを使わず、手動でシステムフォルダに重ねてフォントをインストール、丸漢をフォントフォルダに移動するという手続きを踏んだら、思った通り、全てのフォントがまったく正常に表示されたのだ。
こうして数日間の試行錯誤の末、私の環境でのMacOS8.6におけるOCFビットマップフォントの文字化けの直接の原因は、ダイナフォントのインストーラだったことが判明した。もっともこれは私の環境でのことで、これがどこでも同じかどうか、あるいはインストーラの不具合なのか、などは不明だ。ダイナラブ・ジャパンのWebページでも、このケースはアナウンスされていない。
■MacOS8.6でのビットマップフォントの扱いの三つのポイント
こうして、私のMacOS8.6もフォントまわりはまったく大丈夫になった（たぶん）。ようやく落ち着いて仕事に取り組めそうだ。情報や助言をいただいたみなさんに、心から感謝したい。
そこで、MacOS8.6でOCFビットマップフォントを正常に扱うポイントをまとめると、
1）「丸漢コンパチ縦書サポート」が縦組みの約物を表示するために必須
2）トラブルを未然に防ぐためにも「Font Manager Updater」を入れておくのが安全
3）フォントのインストール時に要注意
ということになろうか。そのほかにフォントメーカーがあげているそれぞれの注意点を踏まえれば、MacOS8.6のフォントまわりはDTPでも大きな問題はないと言えそうだ。
なお、これによって文字パレットの表示も正常になったが、前回書いたATOK11での変換候補パレットの文字化けは、問題が別でなのでやはりそのままだ。
また、システムインストールで入る「細明朝体」「中ゴシック体」も実は問題ありで、QuakXPress3.3では正常だが、Illustrator8.0の縦組みで丸数字などの記号類が文字化けする。この二つはDTPではかなりお尋ね者的存在だから、使わないにこしたことはないだろう。