はじめに−「東風問題」の概要と影響−

　先日、いわゆる「渡邊フォント」をはじめとする多くの日本語フリー・フォントの母胎となったビットマップ・フォントが、実は既存製品のコピーであったことが判明した。これが日本国の現行法の枠組のなかで、はたして「著作権侵害」に該当するか否かは微妙であるようだが、「渡邊フォント」を参考に作成されている「東風フォント」の配布は、知的所有に関わる道義上の問題を重視するという判断のもと、自主的に中止されるに到った。この一次配布者の決断を尊重し、これまで「東風フォント」を同梱していた、私の配布するGNU GhostScript 7.05 Packageも、「東風フォント」の同梱をとりやめ、その代替としてひとまず、この問題を回避できると思われる「和田研フォント」のCID版を同梱することとした。

この問題の詳細についてはひとまず、問題発見者であり、東風フォントCID版の配布者でもあった狩野宏樹氏ご自身による解説を参照されたい。

　しかし、和田研フォントは作成年次も古く、個々の字体の品位そのものや、縦組用約物等の字体の欠落等、実用上の問題を抱えており、実用に堪え得る品質を備えたフリーの日本語フォントが当面存在しなくなるという事態は、とりわけフリーUnix系OS環境に及ぼす影響に甚大なものがある。だがここでは、その全容について考察する準備はないので、さしあたりGSパッケージでの使用に関する問題に絞って、その影響と、問題の現在とり得る回避法について書き留めておきたい。

【追記】
現在、GhostscriptパッケージはESP GS 7.07.1ベースのものとなり、明朝として内田明氏によるXANO明朝TrueTypeFont、ゴシックとして東風代替TrueTypeFontを同梱している。このため明朝に関しては、品位の問題は軽減されているが、使える文字数については東風CID版のAdobeJapan 1-4には及ばないところであるため、以下に述べる問題回避法は、現時点においてもなお一定の必要性があるものである。

１　GS経由での印刷に関して

　GhostScriptはソフトウェア的にPostScriptファイルを解釈・変換する、いわゆるソフトウェアRIPの一種であり、PSプリンタに搭載されているRIPの肩代わりをするものである。よってPSプリンタに搭載されたプリンタ・フォントに相当するフォントを、GS側で用意しておく必要がある。このうち、欧文フォントについては、GhostScriptのソースとともに、必要なフォントがフリーで入手可能だが、和文フォントはその限りではない。そして現在のGSはMacOSXに標準添付されているOpenTypeフォントや、リソースフォークを有するMac特有のフォントを処理できないので、別途NakedCID、あるいはWindowsフォーマットのTrueTypeフォントを用意しておく必要がある。

　ただし、MacOSXでアプリケーション上からプリントセンターを経由して印刷する場合、はじめからフォントそのものが埋め込まれてPDF化されたデータが送り出されるので、通常はGS用和文フォントは必要とされない。ところが、Acrobat ReaderをはじめとするAdobeのソフトでは、PSプリンタ（および、それをエミュレートしているGS）に対しては、プリンタ側のフォントを利用することを想定して、フォントが埋め込まれていないデータが送り込まれるため、GS用の和文フォントが必要になることとなる。そしてこの場合、プリンタには和文フォント部分をGSが和田研フォントの字形からラスタライズしたデータが送られるので、字形・一部の文字の欠落といった上記の問題が発生することになる。

　この問題を回避するには、アプリケーションからGSに向けて送り込まれる中間データに、はじめからフォントが埋め込まれた状態にしてやればよい。そこで以下、Adobe Reader 6.0を例にして、その方法を紹介する。この場合、印刷時に表示される「プリント」パネルの左下側の「詳細設定…」ボタンをクリックすることで現れる「詳細設定」パネルの「２バイトフォントのダウンロード」チェックボックスにチェックを入れておけば、Adobe Readerが代替表示のために用いている和文フォント（通常はヒラギノ、アジア言語パックをインストールしている場合には明朝は小塚OTF）を埋め込んだデータが送り出されることになる。この方法によれば、OSXでGSをプリンタドライバとして使用する場合、Adobe系のアプリケーションも含めて原則的にはGS用和文フォントは不要となり、フォントの問題に煩わされることはなくなる。

　しかし残念ながら、現状ではAdobe系アプリからGSを経由する場合、縦組（V系CMapで定義されたもの）としてフォントが埋め込まれたデータでは、著しく縦方向の軸線が乱れるという問題が生じてしまう。そこで次善の策として、「詳細設定」パネルの「画像として印刷」チェックボックスにチェックを入れておくと、PDFの各ページが文字部分を含め、文字通りひとまとまりの画像としてラスタライズされてGSに送り込まれるので、和文フォントの問題を回避可能である。ただしこの場合、データが画像である故巨大になってしまい、その分印刷に時間がかかるのと、画像化される故に通常より印刷品位がやや低下する可能性があるという副作用が避けられない。もっとも、「縦組PDF」の問題は、pTeXで作成したDVIファイルを自らdvipdfmx等でPDF変換する等、ごく限られたケースでしか発生しないだろうから、そういった場合ははじめからフォントを埋め込んだPDFにしておき、OSX標準のプレビュー.appで印刷するようにすればよい。

２　pTeXでのEPS処理に関して

　一方、GSでの処理における和文フォントへの依存を容易に断ち切ることができないのが、LaTeXでgraphicx.sty等を利用してEPSを挿入する場合である。DVIファイルとEPSファイルとを組み合わせて表示するのは各種DVIwareの役割だが、多くのDVIwareは自前のPS/EPS解釈機能をもたず、GSを呼び出してEPSを自身が処理可能なファイル形式に変換させるという方法をとっている。その代表は、GSでEPSをTIFFに変換させて表示するMxdviと、PDFに変換させて親PDFに取り込むdvipdfmxであろう。この場合、和文フォントが埋め込まれていない（あるいは、フォントのアウトラインが取られていない）EPSの処理に際しては、和文部分にはGS用フォントが用いられるのが避けられないため、どうしてもその品位が問題になってしまう。よって最も適切な回避方法は、はじめからフォントを埋め込むなりアウトラインを取得するなりしたEPSを作成しておくことだろう。

　だがweb上で入手したファイルを処理しなければならないなどの理由で、それが不可能である場合、Mxdviでは自身で高品位のGS用フォントを用意する以外、回避法は考えられない。これに対しdvipdfmxの場合、このドキュメントの初版では、PDFを生成した後に、中丸氏の公開されている、PDFに埋め込まれた和文フォントを除去する処理を行う、“replacejfonts”というPerlスクリプトに通すという、やや搦め手になるが手堅い方法を紹介した。しかし、その後の調査によって、より直接的に、GNU Ghostscript 7.0x系列自身に、和文フォントを埋め込んでいないPDFを生成させる方法があることが判明した。それはSourceForgeのGSプロジェクト・ページに、GS-CJK プロジェクトの一員であるsuzuki toshiya氏により、2002年12月13日付でポストされていたパッチをあてるというものである。もともと、GNU GS 7.0x系列では、フォントの非埋込機能自体はサポートされていたが、和文フォントに関してはその機能がきちんと働いておらず、このパッチによってその問題が解決する。パッチの内容は具体的には、pdfwrite機能に関わるソースである“gdevpdff.c”への数行の追加、および、この変更に即しての設定ファイル“gs_cidfn.ps”への十数行の追加というものである。このパッチを適用してバイナリを構築したうえで、pdfwriteデバイスを利用する際に通常呼び出されるシェル・スクリプト“ps2pdfwr”や、dvipdfmxが利用する設定ファイル“dvipdfmx.cfg”等のなかのgsコマンドライン記述に、“$OPTIONS -c '.setpdfwrite << /NeverEmbed [/Ryumin-Light /GothicBBB-Medium] >> setdistillerparams'”のように、非埋込にしたいフォント名を記述しておけばよい。そうすれば、たとえばCIDFnmap中で“/Ryumin-Light /WadaMin-Regular ;”のような代替設定がされている場合、作成されるPDFは、和文フォントの部分が“Ryumin-Light”であり、かつ、フォントが埋め込まれていないものになる。なお、次期MacOSX,Pantherでは、OS自身にPSを解釈してPDF化する機能が加わるそうなので、DVIwareによるEPS処理に関しても、GS依存から脱却できる可能性が期待できることを書き添えておく。

【追記】
現在は、suzuki toshiya氏によるパッチをさらに改良し、TrueTypeFontの扱いも可能とした山田泰司氏によるパッチが利用可能となっており、本GSパッケージでも、こちらを適用させていただいている。なお、PantherのPS→PDF変換機能は現状では、欧文以外のフォントを扱えぬ不十分なものであるため、EPS処理におけるGS依存からの脱却は、当面は難しそうである。

補足　GPL Ghostscript 8.15の使用による回避

2004年11月1日よりパッケージ配布を開始した GPL Ghostscript 8.15 では、ヒラギノOpenTypeフォントを直接扱えるようになったため、上記のAdobe系アプリケーションによる非埋込フォント印刷問題、Mxdvi/dvipdfmx等におけるEPSフォント問題は、基本的にすべて回避できるようになった。ただし、ヒラギノOpenTypeによるレンダリング/フォント埋込は、処理に時間がかかってしまうため、非力なマシンを用いている場合には、あまり現実的な解ではないという問題がある。また、上述のpdfwriteにおける非埋込処理については、GNU/ESP 7.xx系列と振る舞いが異なり、Ryuminフォント名のPSファイルからは常にRyuminフォント名を継承した非埋込PDFが作成され、しかも多くの場合、OSX 10.3以降のプレビュー.appにおいても、明朝代替表示が不適切に行われ、ゴシックになってしまうことが多い。よって20041101版以降のパッケージでは、ESP 7.07.1パッケージとGPL 8.15パッケージとを同時にインストールしておき、所定の方法によって切替・共存使用が可能なものとした。また、pdfwriteにおける埋込/非埋込の切替は、いずれのパッケージの場合もAppleScriptアプリケーションによって、容易にできるようにしておいた。