Unicodeについては，日本ではJIS規格などとの整合性，あるいはCJK統合漢字というやり方が論議の的になった。Unicodeがいろいろな課題を抱えているのは事実だが，現実の技術動向がUnicodeベースで進んでいることも否定できない。Unicodeの利用の一例として，複数のスクリプトに対応し，多くのグリフをもつmegafontというアプローチがある。

今回はビジネス分野における需要が大きいと思われる表示用のmegafontについて，アグフア・モノタイプのケーススタディを紹介する。これは第18回Unicode Conferenceでの報告をテキスト＆グラフィックス研究会のミーティングで改めて取り上げたものである。お話は日本アグフア・ゲバルト（株）の澁谷謙司氏にお願いしたが，本稿では元の英文のレポートも参照した。

megafontとは

定義的にいえば，多くのグリフをもち，複数のスクリプト（ここでは，ある言語の文字および文字を並べるための規則などを含めた文章表現の体系というような意味で使っている）を実現するフォントということになる。翔泳社『Unicode標準入門』で「大規模Unicodeフォント」と訳されている概念にほぼ相当する。ただ，大規模とはいっても日常的に数MBのフォントをいくつも使っている日本のフォント事情とは異なる。フォントファイルの容量や文字数より，複数のスクリプトを扱うという点に注目すべきだろう。

例えば本社がヨーロッパにあって東アジアやアラブ圏に支社をもつ企業が各拠点間でビジネス文書をやりとりするというのは日常の業務に属するだろう。あるいはインターネットで海外のサイトにアクセスする場合を考えてもよい。この場合，画面表示やプリンタ出力などの用を満たすためには，必要なスクリプトをもつフォントが一つあればよい。それにはUnicodeをベースとしたフォントで対応できるだろうというのがmegafontの考え方である。

megafontには大きく分けて2つのアプローチがある。単一のフォントファイルに必要なすべての情報を入れてしまうオールインワンタイプと，スクリプトごとに分けた複数のフォントファイルを仮想的に一つのフォントとして扱うモジュラータイプである。 オールインワンタイプは，必要な情報が一カ所に収まるので管理は楽だが，ファイルサイズが巨大になってしまう。一方，モジュラータイプは，スクリプト単位の管理はしやすいが，まとめて一つのフォントとして扱うための外部の仕組みが必要になる。

さまざまな問題

Unicodeベースといっても，Unicodeのコードポイントにただどんどんグリフを割り当てていけばよいというわけではない。言語によっては一つのグリフが別の複合型のグリフの構成要素となる場合もあり，それがUnicodeの異なる領域にあったりすると，それらの関係をきちんと保持して管理するのはそう簡単ではない。

書体デザインの問題もある。例えばラテンアルファベットのサンセリフとかモノスペースなどの概念は他のスクリプトには通用しない。そもそも，文字を直立させるのが世界のスクリプトの基準だというわけでもないのである。そうすると，無理にでもフォント全体として統一したデザインにするのか，あるいは全体の統一性は犠牲にして，それぞれのスクリプトに最も適したデザインを考えるのかという問題が出てくるだろう。

そもそも，今のフォント技術はラテン系のアルファベットによるスクリプトを中心に発達してきたから，ラテン系のタイポグラフィにはない性質をもつスクリプトの処理には向いていないという側面がある。発音を表わす記号が基本キャラクタの上下に付いたり，文脈によって文字の形が変化したりするような言語にきちんと対応するには，従来のラテン中心のあり方を変える必要がある。

ケーススタディ

以下はアグフア・モノタイプにおけるmegafont作成の事例である。

1） OpenTypeの機能を利用したフォント

オールインワンタイプ。このケースはUnicode2.1で定義されたすべてのコードポイントにグリフを割り当て，アラビア語やデバナガリなどの複雑なスクリプトへの対応，およびCJK統合漢字の分離に対応した。現在，MS Office2000に搭載されている。
これはクライアントから「Unicodeを完全にカバーするフォントがほしい」と要求されたものだ。さまざまなスクリプトのグリフやリガチャの置き換えなどOpenTypeのショーケース的なフォントになった。CJK統合漢字の分離も重要だ。UnicodeのCJK統合漢字はそれなりに利便性はあるだろうが，現実問題として，少なくとも繁体字，簡体字，日本の漢字，韓国の漢字のためにキャラクタ数より多いグリフを提供しなければならない。
このフォントは現在も改良を重ねているが，現時点では50370のグリフを含む23263740バイトの単一ファイルのフォントである。

2）Unicodeキャラクタのみのサポート

オールインワンタイプ。Unicodeはサポートするが，OpenTypeの機能を使った置き換えはしない。Unicodeのすべてのコードポイントにグリフを割り当てるという点はケース1と同じだが，容量をできるだけ小さくし，なおかつCJK統合漢字に対応することを目標とした。
CJK統合漢字については，単一フォントではグリフの置き換えができないので，4つに分離したフォントのインスタンスを提供することにした。つまりUnicodeのCJK以外の領域では4つのグリフをすべて同じにし，CJKの範囲のみ，ローカルコードページに沿ってそれぞれのグリフを使う。
このフォントもまた改良中で，Unicodeのアップデートにも対応し，現在はUnicode3.0をサポートしている。

3）モジュラー・タイプのUnicodeサポート

第3のケースはローカルコードページをベースに，Unicodeのサブセットをカバーしてグリフを提供するモジュールタイプのアプローチである。いくつかのスクリプトではウェイトとスタイルまで踏み込み，サポートの柔軟性を試みた。
このケースでクライアントが望んだのは，後からスクリプトを追加できることである。つまり，最初からすべてを一つのパッケージとして提供するのではなく，必要に応じて順次付加していくのである。例えば最初はラテン，ギリシア，キリルのみとし，繁体字が必要になったときは，繁体字のフォントファイルを付け足すだけでよいようにする。

＊

いくつか断り書きが必要である。本稿でいうmegafontは，例えば日本の高品位の印刷物などは全く想定していない。目的が違うのである。また，このレポート自体がラテン系のスクリプトを出発点とした視点であることは言うをまたないだろう。それから，本稿は概要説明が主目的なので，わかりやすさを優先したため用語の使い方や訳し方は厳密ではないこともお断りしておく。 ただ，現実的なUnicodeの使い方を考えるなら，まずはこのような汎用的なビジネス分野での利用から始めて，段階的に，あるいは分野別に，必要に応じてより高度な適用に進むという発展型もあってよいのではないだろうか。（テキスト＆グラフィックス研究会）

■出展：JAGATinfo 2001年9月号より

2001/09/10 00:00:00