少し前から、ga cityというWebサイトに「未来が見えるDTP進化論」というタイトルで記事を書いている。ga cityというのは、東洋インキ製造とサカタインクスがシステムインテグレーションを共同で行うために設立された会社である。システムインテグレーションなどいうとわかりにくいが、要するに印刷会社にハードもソフトも含めて効率的・合理的なワークフローの提案とサポートを行う会社であると理解すればよい。
　両者とも社内に「インク」とあるように、印刷インクを販売しているわけだが、実際には印刷会社向けに、さまざまな資材や機材を提供している。
　最近は、印刷の業務用資材の業界も再編が進み、東洋インキ製造とサカタインクスの共同で設立されたga cityという会社もその流れの中にあるのかもしれない。ライバルともいえる両社の結びつきは、ライバルであることを捨て、互いに補完しあい、総合的な販売力を強化していくことを目指しているのだろう。販売力提案力の強化を目指して、先頃両国に、大規模なショールームがオープンした。

　さて、ga cityでの連載記事を「未来が見えるDTP進化論」という大仰なタイトルにしたのは、これからのDTPの羅針盤になれればと多少思ったりしているのだ。「DTPは死んだ」といわれることもあるが、けっこうしぶとく生き残っていくのではないかと思うのである。
　もちろん、しぶとく生き残るには、姿を変えなくてはならず、生存環境も変わっていくだろうが、DTPそのもののパイは、小さくなるにしてもなくなることはないだろう。そのためには、やはりこれから先のことを多少は考えて行く必要があるのではないかと思うのである。
　「未来が見えるDTP進化論」では、アプリケーションレベルでの課題をテーマにして、これからどうなるのかということを整理していきたいと考えているのである。身近な話題から、どこまで未来を見通せるのかということを考えつつ書いている。もっとも、断片的にはすでにいろいろ書いていたりするので、それのあたりを整理しつつまとめていく予定である。

　そのなかの第四回目で、「フォントフォーマットの改変はどこまで続く」というタイトルの記事を書いた。なかなかOCFの呪縛から逃れられないDTPにあって、今後のことを考えると、CMapに対応していないOCFは捨てるしかないというようなことを書いた。
　これからもフォントフォーマットは変わっていくことは間違いない。ユニコードもバージョンがどんどん進んでいきそうだし、採用字形が増えれば、フォントも変わるし、フォントフォーマットも改訂せざるを得なくなるからだ。
　ただし、CMapに対応していれば、フォントフォーマットが変わってしまっても、文字の互換性の問題はかなりの部分で解消されるのではないかと考えた。いずれ、アプリケーションレベルでのCMap対応が必要であり、DTPアプリケーションはCMap対応になっていくに違いない。アプリケーションがCMapを指定したり、切り替えたりできるようになると、フォントフォーマットが変わっていっても、トラブルは少なくなる。単純な文字化けみたいな話はなくなるのである。

　現在のDTPアプリケーションでは、CMap対応とされているものはないが、実は唯一（たぶん）、InDesignのみがCMapに対応しているようである。たとえば、Jeditで編集フォントにOSAKAを指定して、丸付き数字の「1」などの外字を入力する。これはシフトJISの「8540」なので、コピーペーストしてIllustratorに貼り込み、PostScript CIDフォントを割り当てると、丸付き数字の「1」は見事に文字化けする。
　しかし、同じようにMac OS X環境下のInDesignに、Jeditなどのエディタなどで入力したテキストをコピー＆ペーストして、CIDフォントを割り当てても、外字は化けないのである。つまり、InDesignはTrueTypeのシフトJISの文字コードをそのまま利用しないわけだ。TrueTypeの「90pv」をCIDフォントの「83pv」に当てはめると、外字は化けることになる。文字が正しく表示されるということは、CMapを利用しているとしか考えられない。
　しかし、今度はJeditの編集フォントにCIDフォントを指定し、CIDフォントを指定したテキストボックスにペーストすると、なんと外字が化けるのである。CIDフォント同士なのに、外字は再現されないのだ。
　InDesignはテキストをコピー＆ペーストするときに、どうやらそのままの文字コードで貼り込まず、テキストの文字コードをOSのデフォルトエンコーディングとして認識していると考えられる。つまりMacintoshの場合は「90pv」である。コピー＆ペーストしたテキストに文字コードが記載されていることはないだろうから、Macintoshのアプリケーションからコピーしたテキストは、TrueTypeの文字コードとして受け取るのである。
　ただし、InDesignでは内部的にはユニコードで処理しているので、どのようなテキストであっても、TrueTypeの「90pv」として認識し、それをユニコードにCMapを使って変換していると考えると納得がいく。

　アプリケーションがCMapを利用するというのは、テキストをペーストするときに、ペーストする文字のエンコーディングを個別に指定できることだと私は考えている。テキストをペーストしようとするとダイアログが現れて、ペーストするテキストの文字コードを指定できるようにするわけだ。Jeditの編集フォントでTrueTypeを使っていれば「90pv」を、編集フォントでPostScriptフォントを使っていれば「83pv」を、もしWindowsのテキストファイルであれば「90ms」をという具合に使い分ければいいのである。それができればテキスト貼り込みでの文字化けはほとんどなくなるのではないかと思うのだ。
　さらに、テキストボックスを選択して、変換元のエンコーディングと変換先のエンコーディングを指定するとエンコーディングが変換される仕組みがあっても面白いかもしれない。文字コードを誤って処理してしまったテキストも、この機能があれば、オリジナルに戻すことができる。
　アプリケーションがCMapを使うというのは、CMapをダイレクトに指定できることである。CMapを指定できれば、どのようなテキストファイルであっても、オリジナルを維持したまま貼り込むことができるのだ。
　いまでも、テキストを配置するときに、読み込みオプションを指定すると、複数の文字コードを選択できるが、あの選択肢を増やして、海外の文字コード対応するだけでなく、CMapに対応するというやり方に変更すればいいのである。

　画像ファイルにはICCプロファイルを埋め込むことができるようになっていて、プロファイルを埋め込むことで、オリジナルのカラーが判断できるようになっている。残念ながらテキストファイルには、文字のエンコーディングを埋め込むことはできない。使用しているOSで判断するしかないことになる。
　しかし、テキストファイルを貼り込むときに「埋め込まれたプロファイル不一致」のように、デフォルトのCMapを使うか、指定したCMapを使うか選択できればよい。
　さらに、ヒラギノのように文字数が拡張されている場合は、アプリケーションごとのCMapがあっても面白いかもしれない。たとえばテキストエディットでユニコードのない拡張字形を利用しても、その字形を再現できるCMapファイルを作成し、InDesignに貼り込むときに、そのCMapを指定することで、拡張字形が再現されるような仕組みである。クリップボードでヒラギノのバリアントタグが読めるのかということはすぐには解決しないことかもしれないが、方法がないわけではないと思う。
　単純にいって、テキストエディットで入力した拡張字形を、コピー＆ペーストしたいだけなのだが、そのためにはCMapの仕組みを利用できないのかと、思うわけである。
　いまのところCMapは完全に裏方に徹している。しかし、OpenTypeの普及が進むと、フォントフォーマットの混在環境はさらに進むと考えられる。その結果、PDFの利用が進むにしても、PDFが利用しているCMapによる文字コード切り替え機能をアプリケーションが利用しない手はないのではないか。
　InDesignやIllustratorの次のバージョンには、ぜひそういう機能を望みたいものである。CIDも世の中に登場して早七年がたつ。そろそろそういう応用技が使われてきてもいいのではないだろうか。

◆ga cityのWebページ
http://www.ga-city.co.jp/index.html