やな推測だな

てことで前回エントリの続き。

InDesignとIllustratorの合成フォント機能の挙動から、もしかしたら、なんて推測をはじき出しました。
まあ、裏は取れたんだけど、こういう時の推測が当たってしまうのはある意味嫌なもんです。まったくもって汎用性がないのがアレ。

てことで、とあることをすると、こんな風に、InDesign CS2以前やIllustratorの合成フォント機能でも、Pr6フォントベースでの処理が行えます。
これを行えるというべきかどうか、っていうのは別として。

Adobe CS以降・合成フォント(1)
Adobe CS以降・合成フォント(2)



実は前回、こんな推測をしてました。

合成フォント機能は外部のCMapファイルを使って字形情報の処理をしている。

これは至極単純で、フォントに内包されたCMapを無視して出力されていることから推測したものです。で、思いっきりそれが当たってしまっていたという。

これの確認は非常に単純です。CMapの記述を直接触ればOK。
今回弄ったのは「C:\Program Files\Common Files\Adobe\Fonts\Reqrd\Cmaps」(Windows)にある、「UniJIS-UTF16-H」というファイル。これをエディタで直接開いて、以下の部分を書き換えたのが上記の結果。

Adobe CS以降・合成フォント(3)
Adobe CS以降・合成フォント(4)

上の範囲選択箇所が修正前、下が修正後(※編集便宜上、修正後のファイル名は一時的に変えてます)
今回触っているのは出力例からしてわかる通り「逢」の字形です。Unicodeでいうと「9022」に該当。
JIS90で出力されるCharacter IDは「1133」だったため、これをJIS2004の「8266」に変更することで、InDesign CS3以外のアプリケーションでもJIS 2004と同じ字形で出力することができます。



もっとも、JIS90版Adobe-Japanでも全部同じになるという欠点があるけれども。

この処理を利用すると、合成フォント機能を利用して任意の字形を出力することができるという利点があります。
もっとも、逆を返せば「その環境で作成したファイルは外部には絶対出せない」「合成フォントで利用されているUnicodeのコードエリアブロックを把握していないと駄目」(合成フォントはUnicodeのエリアで処理されているため)「CMapの書き換えをする行為自体が自己責任」という、メリット以上のデメリットを伴うという問題点があったりして。



ちなみに今回、一度書き換えたものを利用して合成フォント機能を使ったら、合成フォントで作成したフォントそのものがフォントリストに出てこなかったという問題に見舞われました。
バックアップ取ってなかったからえらい目に遭った。

このエントリーを含むはてなブックマーク はてなブックマーク - やな推測だな

コメント

>>無さん
ご指摘ありがとうございます。
貼りこむときに同じのにしてしまってたようですので差し替えました。

ミス?

「以下の部分を書き換えたのが上記の結果」として掲げた二枚、同じリンク先の同じjpgファイルではありませんか。「上の範囲選択箇所が修正前、下が修正後」とあるけれど、差異が無いみたいなので。

うわあ、

まるでOCFプリンタフォントでExt字形を出力するような荒技だ(^^;)
けど、すべてを外部のCMapに依存させてしまえば、仕様の違うフォントなんか出す必要なかったんじゃないのか?っていう気がしてきます。
非公開コメント

最近の記事

はてブ数順傾向

プロフィール

あさうす

  • Author:あさうす
  • DTP業界を中心に主観だらけの毒を吐いてます。後ろ盾なし、保証なし。あくまでも独断と偏見に満ちているだけで、何かの圧力とかはありません。たぶん。いやないです。信じてください。

    なお、名無しコメント&煽り、勝手にトラックバックやリンクなどはご自由に。spam認定したもの以外は削除しません。ただしFC2の都合でTBは弾かれるかもしれません。

    当blogは、Firefoxを推奨します。

    何かお問い合わせございましたら [assause@gmail.com] までどうぞ。

月別アーカイブ