|
問題なのは使用フォントが無い環境で「細明朝体」「中ゴシック体」の置き換えフォントがシステムに存在するせいだ。
これが存在すると、フォントが無い場合に明朝系は「細明朝体」、ゴシック系は「中ゴシック体」で置き換えられてしまう。
さらに面倒なのはこのドキュメントを作成した元のフォント環境でこのドキュメントを開いた場合、修正部分がL-リュウミンL-KLに置き換えられさらに、文字のセンターがズレてしまう。
そしてこうなると置き換えられたフォントは元のフォントには戻ってくれないのだ。
これは非常に危険である。自分の作業環境のフォント整備は重要だし神経を使っていると思うが、たまたま急な修正で借りたマシンのフォント環境不備でこれに遭遇するととんだトラブルとなりかねない。
ただ、ドキュメントを開いた時点で不足フォントの警告が出るので、開く前に「細明朝体」「中ゴシック体」がインストールされていないか確認してほしい。当然存在すれば外してから作業をするわけだが、DTPで使用するマシンであればそのマシンの持ち主にこの危険性を是非教えておいてほしい。
はじめに今回テストしたOS環境がOS9であり、問題を発見した環境がOS8.1である事を事前に報告しておく。OS8.1でPSフォントのみの環境ではL-リュウミンL-KLに置き換えられた部分の文字のセンターシフトが起きたが、今回テストしたOS9ではセンターシフトは起きなかった。「細明朝体」をオンにして初めて同じ現象が再現されたのだ。
たぶんOS9でフォント環境に大きな変更がなされている事が要因だと思うが、いずれにしても「細明朝体」はかなりの曲者である事は確かである。 |
今回のトラブルは、実際にあったトラブルを元に実験したものである。オペレーターはリュウミンR-KLで本文を縦組みで組み、急な修正が入ったために普段DTPで使用しないマシンを借りて修正してそのままフィルム出力へ廻したが、文字のセンターがズレてしまい原因不明で私の所へ持ち込まれたのがこのケースである。
調べて行くうち、問題の箇所が全てL-リュウミンL-KLになっているのでおかしいと思ったが、とりあえずそれらを全てリュウミンR-KLに置き換えて再出力へ廻しておき、修正したマシンのフォント環境を調べてみるとリュウミンファミリーがインストールされておらず、「細明朝体」で代用している事が判明。
ここで置き換わったフォントは全てL-リュウミンL-KLになってしまい、文字のセンターがずれたまま直らなくなってしまったのだ。 |
|
今回のトラブルの後、実際にどうなるのか非常に興味があったのでドキュメントを作成して実験してみた。
本文をリュウミンR-KLとM-中ゴシックBBBで縦組みにし、リュウミンファミリーを外し「細明朝体」をオンにした環境で修正を試みたみた。当然ドキュメントを開く際にはリュウミンR-KL不足フォントの警告が出るが、これを無視してオープン。そのまま修正を行ったが、この時点では修正個所のフォントは表示されず不明のままである。
ところが一度これを保存して新たに開き直すと修正部分が「細明朝体」になっているのである。この時点で修正個所は元のリュウミンR-KLではなくなってしまうのだ。
次にリュウミンファミリーをオンにして「細明朝体」をオフにした状態で開いてみると、修正個所は見事にL-リュウミンL-KLに置き換わっている。ただし文字センターのシフトは見あたらない。（たぶん OS 9 環境ではセンターシフトが起きないが、OS 7 or 8 環境ではセンターがシフトしたまま処理されてしまうのだと考える。）
そしてそのドキュメントを保存せずに「細明朝体」をオンにすると、修正個所のセンターシフトが発生して見事に問題の現象が再現するのである。当然修正個所のフォントは問題の「細明朝体」に戻ってしまっている。
|
 |
| この状態でプリンタで出力してみても画面と同じようにセンターがシフトした状態で出力されてしまい、フォントはL-リュウミンL-KLに置き換えられたまま。リュウミンR-KLとは明らかにに文字の太さが異なってしまうのだ。 |
いかかでしょう、「細明朝体」の恐怖！ご理解いただけたでしょうか。
DTP環境では「細明朝体」「中ゴシック体」を外しておくように言われているが、システム標準でインストールされてしまうので実際に残したまま作業しているケースもけっこうあるように思う。特に管理者の存在しないマシンでは、「データのチェックさえ出来ればそれで良し！」といった使い方をしている場合が多いのでなおさらである。
こんなマシンを借りて修正し、トラブルを起こしても結果は修正した人間の不注意だと私は考える。なぜならば、業務用アプリケーションは何か不都合がある場合にはかなりの確率で「警告」を出すはずだから、プロならそれに気付いてしかるべきだと思うからだ。
今回はOSの違いでだと思うが、完全に同じ現象を再現出来なかった。しかし「細明朝体」を残したままDTP作業を行うと場合によっては思わぬトラブルを引き起こす恐れがある事は間違いはずだ。DTPを生業としている皆様は、是非とも自分のマシンから「細明朝体」「中ゴシック体」を削除しておいてほしいと考える。
こんな私の実験が、少しでも同じDTPに携わる皆様へのお役に立てれば幸いです。
今後New CIDフォントとOCFフォントが混在する環境での制作物が氾濫すると思われるが、完全にシフトが完了するまでの過渡期にはこれと似たような問題が発生するのではないかと内心ヒヤヒヤしている。
出来ればNew CIDとOCFフォントの混在は避け、OCFオンリーかNew CIDオンリーで制作してもらいたいと考える。というのは、文字の並びを決めるのは今回のケースでもお解りの通りプリンタフォントではなくシステムフォントだからなのだ。今回システムフォントが「細明朝体」に置き換わったばかりに文字のセンターがズレて出力されてしまった。同じようにNew
CIDで作成され、OCFのシステムフォント環境で出力してしまった場合には問題が起こる事も十分考えられる。
IllustratorはCIDを優先させてしまうので、混在使用には十分気を使う必要がある。レイアウトソフトでOCFを使って組み版をしても、素材を作ったIllustratorでは自動的にNew CIDが使用されてしまうのだ。そのままEPSにしてしまえばOCF環境で再保存しない限り問題は無いが、修正する場合にはNew CID環境で修正しないと問題が発生する事も十分考えられる。是非十分理解した上でフォント環境を整備しておいていただきたい。 |
|
