2008/01/14
やな推測だな
てことで前回エントリの続き。
InDesignとIllustratorの合成フォント機能の挙動から、もしかしたら、なんて推測をはじき出しました。
まあ、裏は取れたんだけど、こういう時の推測が当たってしまうのはある意味嫌なもんです。まったくもって汎用性がないのがアレ。
てことで、とあることをすると、こんな風に、InDesign CS2以前やIllustratorの合成フォント機能でも、Pr6フォントベースでの処理が行えます。
これを行えるというべきかどうか、っていうのは別として。
これを行えるというべきかどうか、っていうのは別として。
実は前回、こんな推測をしてました。
合成フォント機能は外部のCMapファイルを使って字形情報の処理をしている。
これは至極単純で、フォントに内包されたCMapを無視して出力されていることから推測したものです。で、思いっきりそれが当たってしまっていたという。
これの確認は非常に単純です。CMapの記述を直接触ればOK。
今回弄ったのは「C:\Program Files\Common Files\Adobe\Fonts\Reqrd\Cmaps」（Windows）にある、「UniJIS-UTF16-H」というファイル。これをエディタで直接開いて、以下の部分を書き換えたのが上記の結果。
上の範囲選択箇所が修正前、下が修正後（※編集便宜上、修正後のファイル名は一時的に変えてます）。
今回触っているのは出力例からしてわかる通り「逢」の字形です。Unicodeでいうと「9022」に該当。
JIS90で出力されるCharacter IDは「1133」だったため、これをJIS2004の「8266」に変更することで、InDesign CS3以外のアプリケーションでもJIS 2004と同じ字形で出力することができます。
もっとも、JIS90版Adobe-Japanでも全部同じになるという欠点があるけれども。
この処理を利用すると、合成フォント機能を利用して任意の字形を出力することができるという利点があります。
もっとも、逆を返せば「その環境で作成したファイルは外部には絶対出せない」「合成フォントで利用されているUnicodeのコードエリアブロックを把握していないと駄目」（合成フォントはUnicodeのエリアで処理されているため）「CMapの書き換えをする行為自体が自己責任」という、メリット以上のデメリットを伴うという問題点があったりして。
ちなみに今回、一度書き換えたものを利用して合成フォント機能を使ったら、合成フォントで作成したフォントそのものがフォントリストに出てこなかったという問題に見舞われました。
バックアップ取ってなかったからえらい目に遭った。
コメント
ご指摘ありがとうございます。
貼りこむときに同じのにしてしまってたようですので差し替えました。
2008/01/22 08:50 by あさうす URL 編集
ミス？
2008/01/21 16:13 by 無 URL 編集
うわあ、
けど、すべてを外部のCMapに依存させてしまえば、仕様の違うフォントなんか出す必要なかったんじゃないのか？っていう気がしてきます。
2008/01/14 12:40 by n-yuji URL 編集