TopPage
中本氏はアドビのアプリケーションの日本語化に携わっておられ，ここ1年ほどは主にAcrobat ReaderとPDFWriterのプロジェクトに参加している。
お話は，PDFの概要と文字コードの扱い，およびフォント管理の3点である。Acrobatの特徴はドキュメントに使われているフォントを，違うプラットフォームでも正しく表示／印刷できることだが，それを日本語でどのように実現しているのか，またプラットフォーム間での文字コードの違いをどう解決しているのか，および異体字の処理についてなどが主な項目である。フォント管理については，フォントの置換のアルゴリズムと，フォントをドキュメントに埋め込むエンベディングについて説明していただいた。以下はその要約である。
英語版がサポートするプラットフォームはMac，Windows16ビット，32ビット，UNIX，OS/2である。また，プロジェクタの中にフォーマットしたAcrobatを入れてしまうAcrobatプレイヤーというシステムもある。日本語版はいろいろな問題があって，Mac（漢字Talk），Windows95／NT，Windows32ビットだけがリリース予定である。その他のプラットフォームについては次期バージョンでの対応を検討中である。
もう1つの特徴はページ間に依存性がないことである。つまり，そのページに使われているフォントやさまざまなハイパーリンクのオブジェクトなどがすべてページ内にデータとして記述されているので，あるページを取り出して新しいPDFを作っても，それは完全なPDFになる。差し替え，入れ替え，置換，削除などがページ単位で可能で，間違ったページの差し替えなどが容易にできる。
/F0 24 Tf＜82A0＞Tj ・・・・・・ 6 0 obj ＜＜ /Type/Font/Subtype/Type0 /Name /F0 /BaseFont/HeiseiMin-W3-90ms-RKSJ-V,Bold /DescendantFonts [ 1 0 0 R ] /Encoding/90ms-RKSJ-V ＞＞endobj ・・・・・・ 1 0 0 obj ＜＜ /Type/Font/Subtype/CIDFontType0 /BaseFont/HeiseiMin-W3,Bold /FontDescriptor 7 0 R /CIDSystemInfo ＜＜ /Registry(Adobe) /Ordering(Japan1) /Supplement 2 ＞＞PDFWriterから出力したひらがなの「あ」という文字だが，1行目に「F0 24 Tf＜82A0＞Tj」とある。「Tf」というのはPostScriptの「FindFont」，つまりフォントを使うというオペレータと思っていただいてよい。「Tj」はPostScriptでいうと「show」，すなわちテキストを出力するというオペレータである。PDFWriterではシフトJISをそのまま使っており，「82A0」はシフトJISの「あ」である。 PostScriptでは通常Tfの前にフォント名が直接書いてあるが，Acrobatは直接の指定はできないのでフォントオブジェクトを指定する。3行目以下が具体的なフォントオブジェクトの記述である。この場合はフォントは平成明朝W3で，Windowsで作っているので「90ms-RKSJ-V,Bold」と書いてある。この5行目の「/BaseFont」以下の情報が，フォント置き換えのときに使われるヒントになる情報で，フォントディスクリプタである。注意していただきたいのは8行目のEncodingである。「/Encoding/90ms-RKSJ-V」とあるが，このEncodingキーワードによって，もとのフォントがどういう並びだったかを覚えるようになっている。この場合はもとはWindowsで作ってあるから，Windows上で表示する時は同じフォントを使えばよいが，Macに持っていく場合はMacの文字並びに応じて並べ替える。 最終行に「＜＜Registry(Adobe)/Ordering(Japan1)/Supplement 2＞＞」とあるが，これはプラットフォームに依存しないキャラクターセットを規定している。つまり，このドキュメントはアドビのCIDフォントのSupplement 2のレベルまでの文字しか含んでいないという意味である。
第1はPostScriptファイルをDistillerによって変換する方法である。Distillerは実際にはPostScriptのインタープリタである。通常だとアプリケーションやドライバから出力されたPostScriptファイルを印刷するわけだが，PostScripファイルをDistillerに入力すると，PostScriptコードを解釈し，印刷の1つ1つのグラフィックスコマンドをPDFに変換してもう1度書き出すのである。PostScriptを直接サポートしているアプリケーションを使った場合，まずファイルに保存してからDistillerを立ち上げ，そのファイルを開いて書き出すという手順になる。ただ，それでは手間がかかるので，AcrobatではDistiller Assistantという仮想プリンタドライバを使って，アプリケーションから自動的にPDFを生成するようになっている。PageMakerや，次のバージョンのIllustratorではプラグインでこのプロセスを自動化している。PageMakerやIllustrator，FrameMakerなどはハイパーリンクなども直接この段階でPDFファイルに書き込んでしまう機能を持っているので，ドキュメントを作るときにリンクを指定してPDFに書き出せば，そのままインターネットにアップロードできる。
第2の方法は，PDFWriterというWindows／Mac用のプリンタドライバを使う方法である。WindowsはGDI，MacはQuickDrawのコマンドを直接PDFに変換する。PDFWriterを使用すれば，Windows／Macのプリンタに出力できるアプリケーションであればすべてPDFファイルを作成できる。さらにいくつかのアプリケーションはPDFWriterの特別のコマンドをサポートしていて，ハイパーリンクやブックマークを作ることができる。
Distiller AssistantとPDFWriterは同じような機能を持っているがそれぞれ特徴がある。ドキュメントがEPSを使用している場合は，Distiller Assistantを使わないと，EPSの内容がPDFに変換されない。EPSを使っていない場合はどちらでもかまわない。また，Distiller AssistantはバックグラウンドでDistillerが起動するので，それなりに時間がかかる。すばやく簡単に変換したい場合はPDFWriterを使えばよい。
第3の方法は，Acrobat SDKを使用する方法である。Acrobat SDKは現在アメリカのアドビから出ている。これはサブスクリプションベースで低価格で提供している。SDKを使うと，Distiller及びPDFWriterのAPIセット，あるいは直接PDFを生成できるライブラリが提供される。日本語対応のライブラリも今年前半にアドビから提供される予定である。詳しくは，ADA（アドビ・ディベロッパーズ・アソシエーション）からCD-ROMが手に入るが，それにはアドビのアメリカのWebページをみれば申し込み方法がわかると思う。
最初はUnicodeにしようという考えがあったが，Unicodeは異体字の問題などいろいろな理由があってうまくいかない。結局，複数のエンコーディングをサポートすることになった。基本的にはCIDエンコーディングである。CIDは16ビット，65,536種類までグリフを持てるエンコーディングである。CIDに変換可能なエンコーディングであれば，すべてのエンコーディングをサポートする。83pv，90pv，90ms，Ext，Add，EUC，JIS，Unicodeが現在サポートしているエンコーディングだが，それ以外でもコードを変更せずにリソースを追加すれば自動的にサポートされるようになっている。ただし，欧字は日本語版でもPDFDocEncodingを使用している。
また，一部Unicodeにしているところがある。ハイパーリンクやファイル名，URL，ブックマークなどは印刷されない文字コードなので，ポータビリティや互換性の方を優先したものである。例えば，Acrobatのドキュメントには注釈をつけることができるが，これは印刷されない。このようなテキストは内部的にはすべてUnicodeで扱われている。
CIDはベンダごとにRegistryを持ち，LocaleごとにOrderingを持っている。具体的には，例えばAdobe-Japan-，あるいはAdobe-CNS-とかAdobe-Korean-となっていて，1つのLocaleについては各ベンダーでCIDのOrderingが固定する。日本語のCIDのOrderingに関しては，アドビの中にはAdobe-Japan-しかない。グリフの追加の場合には後ろの方に足すことになる。したがって，CIDで記述されたものはAcrobat Readerがサポートする限り，決して内容が違う文字で表示されることはないと思う。
「@」という文字の変換を例に説明する。Macで@というデータを含むPDFファイルを作成してWindowsで見ると普通にテキストを持っていくと文字化けしてしまうが，Distillerは次のような変換を行う。
90pv-RKSJ-H = ＜82a0 8540＞ CID = 843,7555 90ms-RKSJ-H = ＜82a0 8740＞Macのホストエンコーディングは90pvで，その@という文字のコードは8540である。これをCIDに変換すると「7555」となる。これは受信の場合だが，このような形でPDFに格納される。厳密には違う場合もあるが，大体は同じである。Windowsで見るときは，PDF中のデータを表示するときに90ms，つまりWindowsのホストエンコーディングに再変換して表示する。すると8740となって正しく@が表示される。
検索は，両方とも同じ「あ」で検索できる。検索するときは，ホストのエンコーディングとのインターフェースがあるので，CIDコードからホストに一番近いもの，この場合だとWindowsのシフトJISに丸められるため，両方とも同じ「あ」として検索できる。同様に，異体字が将来拡張されても，ホストのコードで同じコードポイントにマッピングされるのであれば検索は可能である。ただし，標準の検索では異体字を入力する方法がないので，両者を区別して検索するには，プラグインを作成して直接PDFの内部構造にアクセスすることになる。ただし，これはアドビからは標準では提供されない。
最大で16種類くらいのフォントを区別するが，基本的なアルゴリズムとしては，まず同じ種類の書体を選ぶ。それがない場合はより近いものを選ぶ。例えば楷書がなければ教科書を選び，教科書がなければ明朝を選ぶという具合である。その次に，一番ウエイトが近いものを選ぶ。このとき，Acrobat Readerはそのフォントが実際にどういう太さで表示されるかわからないため，TrueTypeのOS2テーブルに入っているPANOSEの属性値を信じることになる。
WindowsやOS/2ではPANOSE属性が必須になっているが，Macではオプションなので必ずしもあるとは限らない。Acrobat Readerは現在存在している主なPostScript及びTrueTypeの日本語フォントについて300種類ほどのデータベースを持っている。それらについてはPANOSEのテーブルがなくても自動的に内部のテーブルから引っ張ってきて比較することになっている。ただ，今後出るフォントに関してはわからない。今後新しくフォントを開発される場合は，ぜひこのPANOSEテーブルをフォントの中に持っていただきたい。これがないと明朝だと思い込んでしまって，Acrobatからそれを知る方法はない。TrueType協議会に問い合わせればPANOSEの属性の資料が入手できるはずである。
置換は，CIDフォントもしくはTrueTypeフォントを使用して文字の置き換えを行う。ただし，アウトラインが見えるものに限る。エンクリプションがかかっているものは使用できない。
日本語フォントの置き換えはフォントの中の全角部分だけについて行われる。これは，全角で固定幅であれば置き換えても文字が重なったりしないという特徴を利用したものである。半角部分は，スペースから127までは欧文と同じようにMultiple Masterフォントを使う。プラットフォームごとの文字コレクションが違って足りない部分は，Acrobat Readerにバンドルされているサブセットフォントを使用する。サブセットフォントは平成明朝と平成角ゴシックのごく小さいサブセットを使っているので，そのどちらかに丸められてしまうことになる。
以上は画面表示の話だが，プリンタの場合は画面とは全く関係なく単純な置換を行う。つまり，プリンタはホストほどフォントの種類が多くないので，フォントがなければゴシックか角ゴ，丸ゴ，明朝のどれかに丸めてしまうのである。従って確実に同じフォントで印刷することを望むなら，そのターゲットプリンタのフォントをあらかじめ調べておかねばならない。ただ，これはPostScriptの場合であり，時間がかかってもいいのであれば，GDIやQuickDrawでホストのフォントをビットマップとして使って，もとのドキュメントにより近いイメージを印刷できる可能性がある。
制限事項として，WindowsのMS Pというプロポーショナル日本語フォントは，日本語のマルチプルマスターフォントがないため置換ができないということがある。Windowsのプロポーショナル日本語フォントを使った場合，全角部分はもとと同じフォントがない限りレイアウトは保証されない。現状では，全角部分固定幅は日本語フォントを使い，半角部分はTimesやHelveticaを使うというような方法でPDFを作成する方がよいだろう。
さらに，フルセットでエンベディングするか，サブセットをエンベディングするか選択することができる。使用する文字種が少なければサブセットエンベディングを選べばよい。 Type-3もエンベディング可能である。ロゴなどをType-3フォントで作成してPDFの中に埋め込めば，どこへ持っていっても表示印刷が可能だ。
残念ながら，日本語フォントは現在のバージョンではエンベディングをサポートしていない。技術的にはできるはずだが，今回はリリース優先で，エンベディングは次期以降のバージョンになる。ただし，その場合もエンベディングを禁止する属性が入っていないフォントのみが対象となる。
MacではAdobe Type Composerにより外字フォントを作成できるというメカニズムを提供している。これはType-1フォントなので，Distillerでエンベディング可能である。したがって，Adobe Type Composerを使えるMacでは，いわゆるユーザ外字をPDFの中に埋め込むことが可能となる。
CID以前にATMによって提供されていたOCFというコンポジットフォントがあるが，残念ながらこれは置換用には使用できない。例えば，MacのATMフォントのリュウミンライトを使っているとする。Macなら別のMacにリュウミンライトがあれば利用できるが，Windowsのリュウミンライトを使ったPDFをMacに持っていってもエンコーディングが違うため，Mac上でリュウミンライトを使って表示することはできない。なぜなら，PDFは内部的にCIDを使っており，AcrobatはCIDフォントを直接ラスタライズするわけだが，OCFフォントはCIDコードアクセスを許していないため，Acrobatからそれを呼び出すことができないのである。したがって，CIDもしくはTrueTypeフォントの違う種類のものを2つ以上用意していただきたいということである。
また，Acrobat Readerは既に知られているエンコーディングしか対応できない。具体的には，シフトJISではExt，Add，83pv，90pv，90ms，EUCである。これらのエンコーディングはコードの変更なしに対応可能だが，それ以外の場合はリソースにCIDからシフトJIS，シフトJISからCIDに双方向変換するテーブルを足す必要がある。これは個別対応だが，CIDのドキュメントがあれば簡単にできると思う。
それから，フォントのPANOSEの値を知っている必要がある。現在Acrobatのデータベースに入っているフォント及びフォント自身にPANOSEの値を持っているフォントは置換用に使用可能だが，持っていないものは使うのが難しい。PDFを書き出すときにもPDFWriterやDistillerはフォントからPANOSEの値を取り出してPDFに埋め込むが，PANOSEの値がないとそれができないので，どんなフォントに置換されるかわからなくなってしまう。
データベースについては，不具合があれば随時更新をするが，とても全部のフォントはカバーできない。フォントベンダの方は，できればフォントをリリースする際にテーブルにPANOSEの値を書いていただきたい。
以上が中本氏のお話である。お話からもわかるように，今度のAcrobat日本語版によっていきなり自由自在に日本語のフォントを使ってPDFファイルを作り，配布できるようになるというわけではない。そもそも日本語フォントの扱いはアドビだけでどうこうできるものではないのである。今は発売直前で関心も高まっているが，むしろ発売後の動きの方が重要だと思われる。フォントベンダーやソフトウェア会社などの動向にも注意していきたい。
（テキスト＆グラフィックス研究会）
