Study Room 2.0J No.48について

Windows版のIllustrator9/10ではこの問題は起きない様です。
YUJIさん同様のファイルを作ってPDF保存をしてみると、
Windows版ではOTFのエンコードは『90ms』になっています。
このような文字化けはおきません。
Mac版では『90pv』ですよね。
cmapファイルの中身をみてみると、シフトJISの8740以降は
この（文字化けした）グリフ（CID番号でわかる）が使われる様に記述されていますね。
もともと『90pv』はOsakaとかTrueType用だったんじゃないですかね。

私もMacのIllustrator9でYUJIさん同様のファイルを作って試してみましたけど、私のところでは文字化けしませんでした（？）
Illustrator10は使っていないので確認できませんが、Illustrator10の場合だけ起こる現象でしょうか

私の所では、9.0.2と10.0.1ともに文字化けしました。
う～ん、うちの環境に問題があるのかな～
もうちょっと、色々試してみます。
ありがとうございました。

こんにちは。
この件はここの517で私が書き込んでますように、私の環境では起こります。

カランドさん、ありがとうございます。
その後、別のマシンでも試してみましたが、やはり化けますね～

ひとつだけわかったことがあるので追記します（MacのOSは9.1）
小塚OTFとヒラギノOTFをシステムのフォントフォルダに入れていると文字化けしないみたいです。
システムのフォントフォルダからはずして、Illustratorのフォントフォルダまたはシステムのアプリケーションサポートのなかのフォントフォルダに入れて試したら私のところでも文字化けしました。

おおお～、その通りです。
システムのフォントフォルダにフォントを入れて試したらパッチリでした(^_^)
ありがとうございました。

日頃はATMDX4.5.2で外部管理していたので気がつかなかった(^_^;)
確かにアプリケーションサポートに入れるとダメですね…うーむ。

>小塚OTFとヒラギノOTFをシステムのフォントフォルダに入れていると
>文字化けしないみたいです。


その場合の埋め込みフォントのエンコーディングは何でしょうか？
（Illustrator-->PDF保存の場合です）

chizuさん、こりゃ大発見ですよ。
本日はここで２つ問題の解決法が見つかりました。
感謝、感謝！！

>その場合の埋め込みフォントのエンコーディングは何でしょうか？
>（Illustrator-->PDF保存の場合です）

83pv-RKSJ-H です。

釈迦に説法になってしまうかもしれませんが……(^^ゞ

『90ms』はwinのTT,PSフォントで標準の文字セット。
『90pv』はMacのTTで使われている文字セット。
『83pv』はMac、PSフォントの文字セット。
（例外もありますし、CIDフォントの場合、スーツケースをいじるとこれらの文字セットにすることも可能です）

この3つの文字セットの大きな違いはs-JIS【8540】～【889F】です（他にも漢字の字形の違いはありますが、字体切り替えのアレです）。そのため、今回のように参照している文字セットの違いで、いわゆる文字化けが起こっていると思われます。

エキストラさんが一番最初に文字化けは起こらないと書かれていますが『90ms』と『83pv』はs-JIS【8540】～【879E】（内s-JIS【877E】の一文字だけ非互換）は互換があるからだと思われます。実際には文字セットが違うわけですから、互換性はないです(^_^;)
しかし、クールタイプ監視下に置くと、なんでイラレでOTFは90pvを参照するんだろう？？

まぁどちらにしてもwinで『90ms』、Macで『83pv』または『90pv』になるということは、完全にOTFの互換性というものが引き出されてない証拠ですね。
イラレ8に字形パレット＆OTFサポートしてくれれば、もう文句なしなんだけど(爆)

自己レス(^_^;)

＞これらの文字セットにすることも可能です）

どの文字セットにでもすることが可能です、がいいかも(^_^;)

＞しかし、クールタイプ監視下に置くと、なんでイラレでOTFは90pvを参照するんだろう？？

もしかして、イラレはOTFとして認識出来ないから、TTとして認識しているのかな。システム＆ATM環境に置けば、ATMがOTFとして認識してくれるから、という理屈なのかしら。うーむ。

>83pv-RKSJ-H です。

つまり、PSフォントなんかと同じエンコーディングってことですね。
余談ですが、MacOS X10.2で、イラレ10がインストールされている
マシンをさわる機会があったので、ちょっとヒラギノOTFを使ってやってみた。
文字化けします。『90pv』になっちゃいます。
ヒラギノは、もちろんいわゆる『システム』のフォントフォルダ
にはいってます。

て、ゆーか、入力した文字がそのグリフで埋め込みされないのが
Mac版イラレの問題だなー。
InDesignやPhotoshopはPDF書き出しは『Identity-H』でエンコードしますね。
ま、最近はMacあまり使っていないのでアレですが...。

「90ms」「83pv」「90pv」の文字セットのいずれかになるのはIllustratorがUnicodeに対応していないからではないかと思います。Illustratorは10でOpenTypeには対応したとはいえ、シフト JISにしかアクセスできないからです。

かなり前の、Illustrator8.0のものですけど、こういうものもありました。
直接の関係はないけど、ちょっと似てます
アドビテクニカルソリューションデータベース
文書番号215420「PDF保存するとエンコーディングが変ってしまう」
文書番号215824「Illustrator 8.0.x で Acrobat PDF 形式で保存した PDF ファイルを開くと丸数字が違う文字に変わってしまう」

Illustratorだけで使用する場合はフォントをIllustratorやアプリケーションサポートのフォントフォルダに入れていても問題ありませんし、Illustratorで再度開く場合も問題なしですね。でもIllustrator形式（9／10）で他のアプリケーションに配置する場合やIllustrator PDFの場合は問題ありだから、Acrobat PDF Plug-insが間違って変換しているのでしょうが、どういうことなんでしょう？？

エキストラさんの
>MacOS X10.2で、イラレ10がインストールされている
>マシンをさわる機会があったので、ちょっとヒラギノOTFを使ってやってみた。
>文字化けします。『90pv』になっちゃいます。
ということは、やはりカタコリさんのおっしゃっているように「システム＆ATM環境」の場合だとAcrobat PDF Plug-inは正しく認識する、「CoolTypeEngineの管轄」だと間違えているんですよね。MacOS X10.2は「ATM環境」ではないから。

ひとりごとみたいですみません。このことについて詳しい方が見られていましたらフォローをお願いいたします。
「このこと」とは、「CoolTypeEngineの管轄」だと間違える理由です

というか、別におこってるわけじゃありませんけど（笑）、気になりますね

＞（他にも漢字の字形の違いはありますが、字体切り替えのアレです）

いやいや、なに書いてんだオレ(^_^;)　JIS83とJIS90での改訂の字体違いです。↑の字体切り替えは旧字やJIS78だ……疲れているときに書き込みするもんじゃないな(笑)

表示もEPSも大丈夫ということは、やはりPDFか。うーむむ。ATM外して、システムに入れて試してみようかな。でも、イラレが完全OTFサポートしてない限りはしょうがないかな(笑)