フォントの動向
今回はPAGE98のコンファレンス「フォント」のセッションから，セイコーエプソンの鈴木氏のお話を抜粋する。その内容は，多少旧聞に属するがフォントの動向であり，6月号の本欄の続編と考えていただくとよいだろう。近い将来において実現可能なフォントの機能や，Unicodeの実装にあたっての問題など，フォントに関するより具体的な側面を開発者の立場から見たものである。なお，この記事はセッションの一部として話されたものをまとめたもので，文責はあくまでも編集にある。
OpenType
フォントフォーマットとしては，マイクロソフトとアップルによるTrueTypeフォントと，アドビのType1フォントの2つが広く使われている。OpenTypeは，この両フォントのデータにそれぞれヘッダをつけて，OpenTypeというひとつのフォントとして扱うというものである。同じフォントヘッダをつけるため，OSやアプリケーションからは1つのフォントとして認識されるというのがOpenTypeの特徴である。実際には，TrueTypeとType1のフォントデータはそれぞれ従来通りのフォーマットなので，ラスタライザはそれぞれ必要である。実際，WindowsはいずれType1のラスタライザを搭載するという話もあり，それが実現すれば2種類のフォントをWindows上で同じように扱えることになる。もしフォントベンダーが対応すれば，イメージセッタのPSフォントをWindows上でハンドリングできる。そうなればWindows DTPの状況も大きく変わる可能性がある。一方，PostScript側からいうと，PSプリンタでTrueTypeフォントが印字可能になる。つまり，Type1ラスタライザにOpenTypeのフォントヘッダを解釈する部分を設けて，TrueTypeラスタライザを入れればTrueTypeフォントも出力できるようになる。要するにアプリケーション上でTrueTypeとType1をシームレスに使える環境になるわけで，ユーザにとっては，プラットフォームを問わず気に入ったフォントを自由に使えることになる。しかし，ユーザの選択肢は増えるが，逆にフォント自体が淘汰されることも起こりうるだろう。特にTrueTypeフォントの場合，ヒント情報の付け方をフォントベンダが任意に選択できるため，品質をめぐってフォントメーカの競争が激しくなるという側面も出てくると思われる。
フォントの機能の拡張
OpenTypeと並行して，TrueTypeフォントやType1フォント自体の機能も増えてきている。第1に，複数の書体を1つのFontFileにするTrueType Collectionがある。Windowsの日本語フォントにはFixed PitchとProportional Pitchの2つのフォントがあるが，これはFixed PitchとProportionalの2つのヘッダを持っているだけで，実際のフォントデータは1つである。画面上では異なる書体として表示するが実体は1つである。将来は，たとえば漢字部分は一つのフォントを使い，仮名部分のフォントを複数にして，それぞれを別の書体名にすることもできるようになる。第2にフォント置き換え機能がある。書体全部ではなく，1つあるいは複数の文字だけを置き換えることができる。これをGSUB（Glyph Substitution）と呼んでいる。例えば，横書きと縦書きで平仮名だけ適切な書体に入れ換えたり，ある文字だけを旧字体や異体字に入れ換えることもTrueTypeの機能として用意される。さらに，縦書きプロポーショナルやグレースケールフォントがサポートされるし，文字セットとしては補助漢字がWindowsに標準搭載される予定もある。
第3に日本語のフォント置き換えに関することがある。フォント置き換えとは，例えば，○○明朝というあるフォントがないとき，そのOSにある××明朝に置き換えて表示するというものである。その場合，どのフォントに置き換えるかは，フォントデータに付いているフォント属性値を見て判断するわけだが，日本語フォントについては，そのフォント属性値を共通化しようということをJfonts協議会が提案している。
Unicodeの実装に関して
Unicodeは基本的には文字を2バイトで扱うから，アプリケーションがUnicodeに対応していれば，たとえそれが英語のアプリケーションであっても日本語の表示をすることができる。もちろんFEPは別に必要だが，いったん作った日本語のドキュメントなら英語のアプリケーション上でも表示できる。また，文字コードセットが同じなので，日本語の文書を作って，それをたとえばアメリカへ送って表示／印刷することができる。その場合，フォントの技術としてはフォントデータをドキュメントにつけたPortable Fontで送る（後述）。こうしたメリットがある一方，Unicodeには文字コードを決める段階でもともと内在している課題がある。それはある日本語の漢字と中国語の漢字を同じ字としてよいのかというUnificationに関する問題である，また，同じ日本語でも旧字体や異体字をどう扱うかという問題もある。TrueTypeフォントでは上述のGSUB機能を使えば旧字体や異体字に置き換えることはできるが，これはフォントレベルのソリューションであってそれ以上のことは決まっていない。さらに根本的と思える問題は，Unicodeの約20,000字の漢字をサポートすると，それだけフォントデータが多くなって実装のためのコストが増大するし，開発コストも膨大になるだろうということである。
ポータブルフォント
今までの通信ではテキストデータだけを送っていたのに対し，フォントデータも一緒にくっつけて送ってしまおうというのがポータブルフォントの考え方である。相手先にフォントがなくても，送る側のフォントデータをそのまま送るので，送る側が意図した通りに表示できる。ラテン文字のフォントについては，1書体まるごと圧縮することですでに実現しつつある。アグフアゲバルトのマイクロタイプ・エクスプレスやビットストリーム社のTrueDocなどがそれである。PDFのフォントエンベッドもこうした技術に基づいている。しかし，漢字を含むフォントは字数も多いし，1書体まるごと圧縮するのは限界がある。そこで，その文書で使っている文字だけを送ることが考えられる。こうしたポータブルフォントあるいはポータブルドキュメントは，文書にフォントデータがくっついてやりとりされるわけで，当然ライセンスの問題がクローズアップされるだろう。また，トラフィックも大きくなるから，ハードウェアのデータ転送能力も問題になると思われる。
以上のように，フォントに関しては技術的にはいろいろな機能や環境が整いつつある。しかし，地球的な規模でデータが動くことも実際問題として考えなければならない時代である。現在の方法ではすでにいろいろな面で限界が感じられており，文字やフォントを扱う際の難しさもまだすぐには解決されないだろう。一方で日本語特有の問題もある。異体字の扱い，組版ルールの問題，あるいは日本語自体の持つ特異性の問題も依然として残っている。技術的な機能向上は引き続き続けられるだろうが，技術力だけでは解決できない問題もあるだろう。
このような問題については，ユーザによって要求のレベルが違うということもあるので，さらに突っ込んだ議論をしていく必要がある。
（テキスト＆グラフィックス研究会）
（出典：プリンティングインフォメーション 1998年8月号より）
(C)Japan Association of Graphic Arts Technology