【再考中】なぜ？印刷時に文字化けして出力されるのか

非ポストスクリプトプリンターを利用していると
比較的発生する事が多い「印刷時の文字化け」についての自分メモ

かなりマニアック…笑なので、ビギナーには向かない内容です（あしからず）

「見た目の文字で検索出来ない」PDFについては以前書きました通りで
PDFlib FontReporter【文字を検索出来ないPDF】
https://force4u.cocolog-nifty.com/skywalker/2010/08/pdflib-fontrepo.html

作成したアプリケーション
と
使用したフォント
と
PDF化する方法

の
組み合わせで、どうしても検索出来ないPDFは出来てしまいます。
これと同じ事が
プリント時に発生するわけですが
基本的には「プリンタードライバー」の組み込みに依存します。
そのため
利用されているプリンタドライバが対応していない場合
印刷時の文字バケを回避できないPDFがあります。
そのため、Acrobatでは

「画像として印刷」が用意されているわけです

説明用文章（書きかけ）
----------------------------

フォント『OSAKA』『新ゴ』『Source Han Sans JP』を使って説明します。
各フォントで「美しい日本語」をPSにプリントします。

アプリケーションはJEDIT

出来上がったPSファイル

この時点で、すでに「フォントの送り」方法が異なります。

----------------------------

まずはOSAKA

以前書いたLINK通りで
OSAKAはPSに添付されている字形とだけ紐付きます

FontReporterの画面

MorxTesterの画面

OSAKAでプリントしたPSは文字コードともGIDとも紐づかない
そのため見た目の文字通りは検索出来ない仕上がりになります。
ですが
OSAKA内部には、文字の名前としてSJISコードを持っていたりします。

----------------------------

続いて
優等生新ゴ

新ゴは
文字コードとGIDの両方を送っています
文字を検索可能なPSです（文字コードがあるから）

FontReporterの画面

MorxTesterの画面

優等生です。

----------------------------

最後に
Source Han Sans JP

CIDだけと紐づきます
このタイプは多くの非ポストスクリプトプリンターで文字バケます

FontReporterの画面

MorxTesterの画面

MorxTesterではCIDは確認出来ないので
OTMaster Lightの出番です
https://force4u.cocolog-nifty.com/skywalker/2014/12/sourcehansans-5.html

OTMaster Lightの画面

一般的なポストスクリプトプリンターの場合
cMapを積んでいるので文字バケしないが
多くの非ポストスクリプトプリンターの場合
このCIDだけ送られるプリントデータで文字形を正しく反映出来ないわけです。

-----------------

商用印刷用データの場合、今回の事例は気にする事はありまり必要ありませんが
画面表示用やユーザーが印刷する事を想定している場合
制作時から、この「CIDを送るフォントとアプリ」の組み合わせには留意が必要です。

制作開始してから早い段階で以下の確認を

１：PDF化した時に文字化けせずに出力可能か
１−１：ポストスクリプトプリンタで確認
１−２：非ポストスクリプトプリンタで確認

２：PDF化した時に文字を検索可能か
２−１：イラストレーターPDFやインデザインPDFでの文字検索
２−２：PS吐いてからのディスティラーPDFでの文字検索

出来上がってから「文字が検索出来ないんだけど」…なんて言われたら…
お〜怖い

まずは、PDFになった場合
「フォント」と「制作アプリケーション」の組み合わせで

「文字が検索出来ない」組み合わせがある事

「印刷時に文字化けする」組み合わせがある事

この２点を知っておきましょう

-----

MorxTesterは以下から
https://developer.apple.com/fonts/

こちらのAcrobatコミュニティフォーラム (Japan) > ディスカッションの記事に反応
https://forums.adobe.com/thread/1705112