アドビの日本語フォント開発 30年の歩み 前編 #フォントの日 #Typekit

連載

＃フォントの日

アドビが開発したPostScriptページ記述言語の処理系を搭載した、最初の日本語PostScriptプリンターが世に出たのは1989年のことです。そのプリンターに搭載されていた日本語フォントは、OCF（Original Composite Font）と呼ばれる独自の形式のものでした。それは、PostScriptプリンター用の欧文フォントの形式として採用されていたType 1フォントフォーマットを階層的に組み合わせた、複合フォントをベースにしながら独自のファイル構成によって、日本語が必要とする、何千もの漢字を含む文字集合（およびグリフ≒字体あるいは具体的な文字の形の種別の集合）に対応したものでした。それに先立つ1987年に、アドビは株式会社モリサワと日本語フォントのライセンス及びフォント作成技術に関する契約を結んでいました。そのプリンターには、モリサワの書体デザインを実装したOCFフォントが搭載されたのです。

日本語フォントを搭載した各種の日本語PostScriptプリンターやイメージセッターが登場して以降、1990年代に入ると、さらにフォントメーカー各社がさまざまな日本語フォントのリリースをはじめました。Adobe Illustratorや、旧Aldus Page Makerなどのアプリケーションソフトウェアがリリースされたことにも助けられ、日本においてもDTP（DeskTop Publishing）の普及が進みました。また、コンピュータの画面上でType 1とOCFフォントの表示を可能にするAdobe Type Manager（ATM）の日本語版もリリースされました。

しかし、日本におけるDTPの普及浸透を加速する上で解決しなければならない課題がいくつか残っていました。一つ目の課題は、利用できるフォントの数を増やすことで、多様な書体が使えるようにする必要がありました。専用システムとは異なり、自由に異なるメーカー製のフォントを選択して利用できるようにするためには、フォントの市場が形成される必要がありました。幸いにも、先に述べたモリサワを含め、いくつかの重要な日本のフォントメーカーが、DTPの将来における可能性とフォントの市場の形成の必然性を、認識しはじめていました。

二つ目の課題は、フォントが搭載すべきグリフ（≒字体あるいは具体的な文字の形の種別）の集合にありました。当時の日本語フォントに収録されていたグリフには、JIS X 0208が定めた、第一水準と第二水準に対応するグリフ、OSに依存するグリフ、PostScriptプリンターを製造販売するメーカーが必要とする追加のグリフなどが含まれていました。しかし、伝統的な日本の出版業界が必要とする漢字の異体字や記号類は含まれておらず、DTPの普及を本格的な出版をも含めた領域に拡大するには、フォントに含まれる字体や記号を増やし出版業界が必要とするものに合わせる必要がありました。

アドビは、これら二つの課題に対する抜本的な対策として、まず、大規模なグリフの集合を取り扱う日本語フォント用に、CIDフォントという新しい複合フォントの形式を開発し、フォントのファイル構成を簡素化するだけでなく、その仕様を公開しました。これによって、アドビ以外のフォントメーカーが PostScriptプリンターやATMで利用できる日本語PostScriptフォントを開発して販売することが、以前よりも容易になりました。さらに、CIDフォントの普及を図るとともに、アプリケーションソフトウェアの日本語版に組み入れて積極的に利用しました。

もう一つの対策は日本語用のグリフ集合を明示的に定義することでした。従来は外字フォントなどの形で提供せざるをえなかった、いわゆる外字グリフの内、どのグリフを新しいグリフ集合に加えるべきかについて、フォントメーカー各社に意見を求めました。それをもとに、従来のグリフ集合を拡張して、日本の出版や印刷業界で必要とされるグリフをできる限り多くフォントに収録した「Adobe-Japan1-4 文字コレクション」を策定して、その仕様を公開したのです。

それ以後も、アドビはこの日本語用のグリフ集合Adobe-Japan1の保守と拡張を継続して行ってきました。現在、Adobe-Japan1-6文字コレクションが最大規模の日本語用のグリフ集合となっています。この日本語グリフ集合及びそのサブセットに準拠して、さまざまな日本語フォントがフォントメーカー各社によって数多く作られ、特に高品位なフォントを必要とする出版や印刷に関わるグラフィックデザイナーやクリエイティブプロフェッショナルによって今日まで利用されてきました。

また、アドビは、異なるOSに対応するグリフを包含することで、OSに依存しないフォントを実現しました。このことは、アドビが開発した、AcrobatとPDF（Portable Document Format）が電子文書の交換を実現する際に、オリジナルの文書で用いられているフォントをPDFに埋め込まずに、代替フォントを用いる場合にも有効でした。

アドビは1992年に、長年にわたって毎日新聞社で書体デザインに従事し、モリサワにおいても書体デザインを指揮した経験のある小塚昌彦氏を日本語タイプディレクターとするグループを東京に設立し、オリジナルの日本語書体開発に着手しました。日本語書体のデザインのための専用のソフトウェアツールの開発も行いました。また、新しいツールを使って漢字や仮名や記号類などをデザインし、それをチェックし、さらには日本語フォントを組み上げるための作業工程も新たに考案する必要がありました。日本語フォントの大規模なグリフ集合をいかに効率的に作るかが最大の課題でしたが、ストローク（画線）のエレメントを組み合わせる手法と、補間の手法をツールに取り入れることで、漢字のデザインの効率化に成功しただけでなく、作業工程の合理化を図りました。

小塚明朝と小塚ゴシックの見本例（ウェイトはRとM）

1997年に小塚明朝、2001年に小塚ゴシックという2つのアドビ初の日本語書体ファミリーをリリースしました。小塚昌彦氏がデザインした小塚明朝は、比較的大きめにデザインされた文字と、直線的な画線の処理によって、明るい表情が得られ、実用的な文書制作に適した、現代的な明朝体です。小塚ゴシックも、小塚明朝との形態上の一貫性と連関を重視したデザインとなっていて、同様に明るい表情を持つゴシック書体です。

アドビはオリジナルの日本語書体を開発することによって、日本のDTPを率先する役割と立場をより堅固にしました。それだけではありません。前述のように、自らのフォントを保有することで、日本で必要とされるグリフ集合を保守し必要な拡張に対処できる能力をもつことができたのです。

アドビとMicrosoftは2000年にOpenTypeという新しいフォントフォーマットについて合意し、共同で仕様の策定を行いました。アドビは日本語、欧文フォントのOpenTypeへの移行を進めました。これは、各種OSがUnicodeに対応していくのと同時に進行し、国際的な利用環境におけるデジタルフォントの利便性の向上に貢献することができました。

さて、三つ目の課題は、伝統的な日本語組版に対応したアプリケーションソフトウェアがきわめて少数しかなかったことでした。米国製のソフトウェアを日本語対応できるようにローカライズした製品の中には、日本語組版の本質的な要件を良く理解せずに作られたものもあり、複雑な日本語組版に上手く対処することができなかったのです。本格的な書籍の組版や雑誌、広告、商業印刷物の制作に利用できるページレイアウトソフトウェアを、日本のDTPは必要としていました。アドビは2001年にInDesignの日本語版を開発することで、その課題の解決に着手しました。InDesignの日本語組版機能を充実させたことで、日本の出版や印刷の分野でプロフェッショナルによるInDesignの利用が徐々に拡大しました。これによって、DTPの普及を図る上での課題が取り除かれていきました。

InDesignの日本語版には、日本語フォントに付属する標準の仮名文字や欧文を、外部の別のフォントで組み替える合成フォントの機能が搭載されました。日本語文書の70%近くが音節文字の仮名文字であると言われています。仮名文字だけを収録した小さなフォントを既存の漢字を含む日本語フォントと組み合わせることで、組版結果の表情を多様に変化させることが可能になりました。また、欧文の文字のデザインを好みのものに切り替えることもできるようになりました。合成フォント以前にも、アドビは同様の機能をもつツール、ATC（Adobe Type Composer）を開発していました。「鴨野かな」のファミリーはATCの利用を想定して作られたものでした。

このInDesignの合成フォントの機能で利用できる仮名フォントとして、アドビは2003年に「りょうText」、「りょうDisplay」、「りょうゴシック」のファミリーを開発します。これらの書体は、現在アドビの日本語タイポグラフィチームのチーフタイプデザイナーである西塚涼子がデザインしたもので、比較的大きな字面を持つ現代的なデザイン傾向を推し進めた小塚明朝や小塚ゴシックとは対照的に、字面の大きさやデザイン上の特徴もより伝統的で保守的な性格をもつ仮名のグリフとなっています。柔和な表情を持ちながら、スピード感をもあわせ持つデザインです。さらに、これらの仮名フォントに小塚明朝の漢字グリフを付け加えた「りょうText PlusN」、「りょうDisplay PlusN」、「りょうゴシック PlusN」のファミリーを2007年に開発しました。

OpenTypeフォントは、TrueTypeフォントのファイル形式をもとにして、その内に、Type 1形式のグリフ手続きと完全に互換性のあるCFF（Compact Font Format）と、TrueTypeのグリフ手続きとのどちらでも収容することができる形式です。さらに、グリフを他のグリフに置き替えて、異体字の選択、複数のグリフを自動的に合字に変換する、個々の文字の字幅などのメトリクスを標準のものから他のメトリクスに切り替える等々の豊富なタイポグラフィックな機能を提供します。OSやアプリケーションソフトウェアのOpenTypeへの対応は、2000年代の初めのWindows 2000及びWindows XP、MacOS Xに始まり、以後改善を繰り返してきました。これによって、OpenTypeフォントを利用できる環境が整備されていったのです。その後、西塚涼子が藤原定家の書風にもとづいてデザインした、「かづらき」は、日本語の印刷用書体としては極めて珍しく、それぞれの文字が固有の字幅を持ってデザインされた純粋なプロポーショナル書体でした。「かづらき」のデザインは、藤原定家の独特の書風を、印刷やwebページのデザインにも利用できる現代の書体デザインに転化させたもので、大胆な単純化と自由奔放な躍動感のある形状を特徴としています。「かづらき」は、デザイナーの西塚涼子が藤原定家の書風を再解釈するという困難な仕事に取り組んだ価値ある成果と言えるでしょう。「かづらき」は2010年のTDC（Type Directors Club）の入選作の一つに選ばれました。「かづらき」は後に拡張され、「かづらき SP2N」となっています。

かづらきの組見本

固有の文字コードが与えられる一つの文字（符号化文字）が、どのような具体的な形で、表示されたり、印刷されたりするか、つまり、グリフがどのような範囲の形のバリエーションを取り得るかは、漢字については、現在広く用いられている国際符号化文字集合の規格であるISO/ IEC 10646のAnnes Sで規定されています。

一つの符号化文字を表現することのできるグリフが複数ある場合には、どのグリフが用いられても、同じ一つの文字とみなされてしまうため、文字コードだけを用いて、それらのグリフの差異を区別したり指定したりすることはできません。そのようなグリフの差異を区別する必要が生じる場合はさまざまです。例えば、特定の人名や地名、屋号や商号などに用いられるグリフが人々に親しまれて、広く出版や広告などで必要とされたり、あるいは過去の写本や書籍や文書で用いられたグリフを再現する必要のある学術書の出版で必要となったりします。出版の分野では、従来より、同じ文字でありながら、異なるグリフのバリエーショ ンを揃えておく必要がありました。

標準の文字コードだけを含むプレインテキストで、このようなグリフのバリエーションを区別する方法として、Ideographic Variation Sequence（IVS）が考案され、ISO/IEC 10646で標準化されています。それは、二つの標準的な文字コード（漢字の文字コードとグリフのバリエーションを指定するVariation Selectorという文字コード）の列を利用します。

アドビの日本語フォントの多くは、どのような文字の形を含むかを決めるにあたって、Adobe-Japan1文字コレクションというグリフの集合を参照してきました。Adobe-Japan1文字コレクションには、従来の文字コードでは指定できないグリフも含まれています。そのため、IVSを用いて、それらのAdobe-Japan1文字コレクションに含まれるグリフを指定できるように、ISO/IEC 10646にもとづきThe Unicode Consortiumが策定した、Unicode Technical Standard #37 Unicode Ideographic Variation Database（IVD）のコレクションの一つとして、Adobe-Japan1文字コレクションを2007年末に登録しました。ここで定められたIVSに対応するFormat14の ‘cmap’ テーブルを持つフォントでは、IVS によってグリフを指定することが可能になります。これによって、グリフの差異をプレインテキストで指定することが、日本語フォントを利用する環境において可能となりました。

現在、国際的に標準的な文字コード体系として広く用いられているISO/IEC 10646は、Unicodeという名前でも知られていますが、その中にはCJK互換漢字と名付けられた文字が含まれています。これらの文字は、既存の国内文字コード規格との互換性のために追加された文字です。CJK互換漢字には、文字コードが与えられ、既存のCJK統合漢字とグリフの形状が類似するため同じ文字とみなされるような一部の異体字も含まれているため、CJK互換漢字に与えられた文字コードを用いることでそのグリフの形の差異を区別することができるようになりました。しかし、CJK互換漢字は特殊な閉じた環境で用いる場合を除き、本来意図されていたグリフの形の差異の再現が、Unicode正規化によって妨げられることが正規化処理の一つ問題点として長く議論されてきました。Unicode正規化は、等しいとみなすことのできる複数の文字を統一した表現形式に変換することで、文字列の検索や照合や並べ替えなどの情報処理をやりやすくするための手続きです。

例えば、下の画像で示したCJK統合漢字の「免 ※文字コードはU+514Dの異体字（U+FA32）」は、CJK互換漢字として定められていますが、 このCJK互換漢字が正規化されるとCJK統合漢字の「免（U+514D）」に変換されてしまいます。この問題に対処するため、Unicode 6.3で、いくつかのStandardized Variation Sequence（SVS＝標準化されたVariation Sequence）が互換漢字とは別に追加されました。このSVSもまた、OpenTypeフォントのFormat 14の ‘cmap’ サブテーブルに含まれます。日本語フォントでは、対応するグリフ集合によっても異なりますが、典型的な場合で57から100近くの数のSVSが必要となります。法務省が定める人名用漢字が57のSVSを含んでいるため、57のSVSが最低限必要となるのです。「免」の異体字（U+FA32）の場合、CJK統合漢字の文字コードU+514Dの直後にVSのU+FE00を置くことで、CJK互換漢字が表現する異体字の形を指定し再現できるようになりました。

https://blogs.adobe.com/creativestation/files/2018/04/MenCharacter200.png

「免」の異体字（U+FA32）

後編へつづく

英語版はコチラ