JPH10500233A - 移植可能なフォントを生成使用する装置および方法 - Google Patents

Abstract

(57)【要約】 コンピュータ化されたシステムが、それぞれ関連するフォント（２１７）を有する文字（２１９）を受取る。受取られた文字−フォントの組合わせごとに、システムが前記組合わせ形状（４５３）の予め規定されたフォント記述（１２２における）をアクセスし、次いで当該形状の新たなフォント記述（１２６における）を生成する。望ましくは、文字が異なるフォントを持つ時、システムがその全てに対して新たなフォント記述を自動的に生成する。望ましくは、受取られた文字が入力テキスト（１１６）の一部であり、システムが対応する文字（２１９）のみならずこれら文字の形状を規定するのに必要な新たなフォント記述をも含む出力テキスト（１０４）を生成する。望ましくは、出力テキストは、記憶媒体（１３０）またはコンピュータ・ネットワーク（１３２）により、他のコンピュータへ転送することができる。望ましくは、新たなフォント記述は、予め規定されたフォント記述が文字−フォント形状を規定する方法とは独立的である。望ましくは、システムは、出力テキストのイメージ（１１０における）をこれを生成したコンピュータ（１０２Ａ、１０２Ｂ）上か、あるいは別のコンピュータ（１０８Ａ、１０８Ｂ）上に描写することができる。

Description

【発明の詳細な説明】 移植可能なフォントを生成使用する装置および方法 発明の分野 本発明は、コンピュータのフォント技術、即ち英数字およびテキストと共に用 いられる他のイメージの形状を表わし生成するコンピュータ技術に関する。 発明の背景 書かれた言葉の開始以来、文書の作成者は、その言葉が話されるとしたらどの ように耳に聞こえるかということだけでなく、これが読まれる時どのように目に 見えるかということにも関心があった。印刷の出現前は、書法は主な表現形式で あった。印刷によって、フォントを生成して使用する技術は、重要性において書 法に取って代わった。 フォントは、英数字の文字セットにおける各文字を表わす１セットの形状であ る。通常、各フォントにおける異なる文字の形状は、所与のフォントの文字が全 体として適切に見えるように、幾つかの形状特徴の横と縦の位置、その縦横の筆 使いの一般的幅、およびそれらがセリフを付ける（ｓｅｒｉｆｅｄ）か、ボール ド（肉太）か、あるいはイタリックかのような幾つかの特性を共有する。 一般に、フォントは、サイズとは無関係の文字の全体的形状を識別する「クー リエ（Ｃｏｕｒｉｅｒ）」、「エリアル（Ａｒｉａｌ）」、「ヘルベチカ（Ｈｅ ｌｖｅｔｉｃａ）」あるいは「タイムズ・ニュー・ローマン（Ｔｉｍｅｓ Ｎｅ ｗ Ｒｏｍａｎ）」の如き基本的なフォント名によって見分けられる。これらの 基本的フォント名は、しばしば、フォントの設計者により所有される商標権とな る。基本的なフォント名は、しばしば、当該フォントのサイズを指定するポイン ト・サイズ表示が後に付く。時に、基本フォント名とポイント・サイズとの間に 、筆使いが肉太であることを意味する「ボールド（ｂｏｌｄ）」、文字全体がよ り細くされることを意味する「細（ｎａｒｒｏｗ）」、文字が斜体であることを 意味する「イタリック」、あるいはサンセリフ（ｓａｎｓ ｓｅｒｉｆｅｄ）文 字に対して用いられその文字が斜体であることを意味する「斜め（ｏｂｌｉｑｕ ｅ） 」のような他の単語が挿入される。 フォントを変えることができることは、多くの利点を有する。これは、必要な 時にテキストを更に密に詰めるため、またテキストを更に容易に読めるようにす るためユーザに文字の大きさを変えさせる。異なるフォントの使用もまた、テキ ストの異なる部分を視覚的に弁別することを可能にする。これは、テキストの調 査および利用を容易にする。更に、テキストが他のテキストよりも視覚的に更に 快いものとなり、一部は読むのが更に容易になる。異なるフォントは、異なる美 的センスに訴える。あるものは古典的に見え、あるものは近代的に、あるものは アールヌボー（ａｒｔ ｎｏｕｖｅａｕ）調、あるものはアールデコ（ａｒｔ ｄｅｃｏ）調、あるものは手書き風、あるものはユーモラスに、あるものはショ ッキングに見える。広いバラエティのフォントから選択できることは、文書の美 的メッセージの調子を整える能力を著しく増進する。 コンピュータ世代が始まった時、大半のコンピュータはテキストを１つのフォ ントで表わすのみであった。しかし、この１０年ほどは、コンピュータ・システ ムの増加率が、テキストを幾つかの異なるフォントで表わして印刷する能力をも たらしている。このようなコンピュータの大半は、このコンピュータが取扱える 各フォントの各文字の形状に対して予め規定されたフォント記述を含むフォント 資源を有する。予め規定されたフォント記述は、指定された形態あるいは言語に おける文字の形状について記述する。 あるフォント言語は、ビデオ・ディスプレイあるいはレーザ・プリンタにおけ るピクセルへ直接翻訳することができるビット・マップ・イメージとして形状を 表わす。これは、早いという利点を有するが、異なるサイズごとに異なるセット のフォント記述を必要とするという短所を有する。 更に最近は、スケーラブル・フォント言語に対する傾向がある。これらの言語 は、形状を画定する１つ以上のアウトラインに関して文字形状を規定する。この ような各アウトラインは、出発位置への移動（ｍｏｖｅ）により、次いで一連の アウトライン線分によって画定され、この線分の各々は、次の文字の開始のため の標準的な位置への移動が続く、２次あるいは３次のベジェ曲線（Ｂｅｚｉｅｒ ｃｕｒｖｅ）または円弧のような曲線または線のいずれかである。ベジェ曲線 は、２つの曲線上の終点とそれらの間に置かれる１つまたは２つの曲線外の制御 点とにより画定される周知の種類の曲線である。２次ベジェ曲線は、唯一の曲線 外の制御点を持ち、この曲線は各終点でこの終点から前記制御点までの線に対し て接しており、この曲線の角度が前記接線により形成される角度を反映する。３ 次ベジェ曲線は、２つの曲線外の制御点への線と接しており、この曲線の終点付 近のこのような各接線の一般方向における広がりは前記終点から接線の関連する 制御点までの長さの関数である。前記線と線分とは、通常は、アウトライン分解 単位即ちＯＲＵと呼ばれる単位で１０００×１０００あるいは２０４８×２０４ ８のいずれかの分解能で画定される。これらの４つの記述は線および曲線に関し て形状を画定し、かつこの画定が高い分解能で行われるので、かかる記述は任意 の所望のサイズの視覚的なフォント・イメージを生成するために用いることがで きる。 スケーラブル・フォント技術においては、文字セットにおける各文字のアウト ライン形状を画定するフォント記述のセットは、基本的あるいは物理的なフォン トと見なすことができる。このような物理的フォントから生成された種々のサイ ズのフォントは、それらの文字と関連する個々の形状記述を持たないがこのよう な形状をスケーラブルＮＡ物理的フォント記述から指定されたサイズで生成する ので、論理的フォントと見なされる。このような名称を用いて、例えば、基本的 なフォント名称「エリアル」と関連する物理的フォントが存在することになり、 かつ物理的フォントはこれと、「エリアル１２」あるいは「エリアル２４」のよ うな名称「エリアル」の後にポイント・サイズ指定が続く任意の論理的フォント を関連付けるものである。通常は、「ボールド」、「イタリック」あるいは「細 」を含むフォント名称として個々の物理的フォントが提供されるが、対応する物 理的フォントの形状を傾斜させることによりその名称に単語「斜め」を持つフォ ントがしばしば生成され、もし対応するイタリックの物理的あるいは基本的なフ ォントが提供されなければ、「イタリック」に対して必要な場合に同じことが行 われる。 現在では、幾つかの主要なスケーラブル・フォント言語がある。これらの言語 は、米国カルフォルニァ州９４０３９、Ｍｏｕｎｔａｉｎ Ｖｉｅｗ、Ｃｈａｒ ｌｅｓｔｏｎ Ｒｏａｄ １５８５のＡｄｏｂｅ Ｓｙｓｔｅｍｓ社により開発 された「ポストスクリプト（ＰｏｓｔＳｃｒｉｐｔ）」、米国カルフォルニァ州 ９５０１４、Ｃｕｐｅｒｔｉｎｏ、Ｍａｒｉａｎｉ Ａｖｅｎｕｅ ２０５２５ のＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ社により開発された「トルータイプ（Ｔｒｕｅ Ｔｙｐｅ）」、本願の譲受人であるＢｉｔｓｔｒｅａｍ社により開発された「ス ピード（Ｓｐｅｅｄｏ）」、米国マサチューセッツ州０１８８７、Ｗｉｌｍｉｎ ｇｔｏｎ、Ｉｎｄｕｓｔｒｉａｌ Ｗａｙ ９０のＭｉｌｅｓ社のＡＧＦＡ事業 部により開発された「インテリフォント（Ｉｎｔｅｌｌｉｆｏｎｔ）」を含む。 これら言語はそれぞれ、形状を記述するために異なるコードまたはフォーマット を用い、異なる方法で形状を表わす。例えば、「トルータイプ」は曲線線分の形 状を画定するため２次ベジェ曲線を用いるが、「ポストスクリプト」および「ス ピード」は３次ベジェ曲線を用い、「インテリフォント」は円弧を用いる。 コンピュータが、あるフォントを所与の文書において指名するためには、この フォントの文字のビット・マップ化記述あるいはスケーラブル・フォント記述の みならず、各フォント言語のフォント記述が書かれる特定のコードをどのように 解釈して、これらをビット・マップ・パターンあるいは一連の移動とアウトライ ン線分へ変換するかを知るフォント・インタプリタと呼ばれるソフトウエアをも 要求する。 不都合なことに、全てのコンピュータが同じフォント記述あるいは同じフォン ト言語を解釈する能力を持つわけではない。このことは、電子文書が１つ以上の 所与のフォントを用いる第１のコンピュータで生成され、次いでこれらのフォン トを持たずあるいはこれを解釈できない第２のコンピュータへ転送されるならば 、問題を生じる。このような場合、文書が第２のコンピュータで提示されあるい は印刷される時、このコンピュータは意図されるものと異なるフォントを持つ。 このことは、文書に非常に異なる、しばしば要求されない外観を生じ得、この文 書の余白およびページ付けを破壊し得る。欄を持つテキストのような高度にフォ ーマット化されたテキストにおいては、このことはテキストをほとんど読めない ものにし得る。更に、あるフォントは他のフォントには無い特殊な文字を持ち、 あるいは他のフォントで一般に使用されるものと異なる文字コードを用い、その 結 果このようなフォントの不一致が文書の外観および構成を破壊するのみならず、 情報の喪失あるいは混乱をも生じ得る。 フォントで表わされたテキストを移植可能にする問題に対する１つの解決法は 、全てのフォントのコピーと、文書と共にその文字を適切に解釈するのに必要な フォントの解釈とを送出することである。不幸なことに、これは多くの問題があ る。第一に、どのフォントと解釈がかかる各文書と共に送る必要があるかを見出 して、これらを視認マシン上に組込むことは、労働集約的なものとなる。更にま た、これは、たとえフォントの実際の形状が長い間著作権を課されないままにな っていたとしても、フォント記述に含まれるコードと一連のアウトライン線分の 両方が多くの点で著作権の対象となり得ると見なされており、このため、法的な 許可無しに新たなマシンに組込む得ないので、法的な諸問題を生じることになる 。 この問題を取扱う多くの従前の試みがなされてきた。 第１のこれまでの試みは、文書を再生するコンピュータが文書で要求されるフ ォントをあるならば類似するフォントを用いて近似化する試みを可能にするソフ トウエアを用いることである。このようなシステムが、１つのセリフを持つフォ ントを別のものに、１つのイタリック・フォントを別のものに、どいうふうに置 換しようと試みる。不都合なことに、このような試みは、文書を再生するコンピ ュータが置換すべきフォントを近似化するフォントを持つことをやはり必要とし 、この近似化はしばしば期待を裏切るものである。 別の従来技術は、使用される各フォントにおける各文字のサイズを説明する文 書と共に情報を送るソフトウエアを用いることによって、前記の第１の試みを拡 張するものである。これは、使用するコンピュータにおける対応ソフトウエアが 、同じスペーシングを持つフォントを生じるよう逸失するフォントを近似化する ため使用するどんなフォントでも引伸すか圧縮することを可能にする。この技術 は、文書のフォーマッティングがスペーシングの相違のため混乱することを防止 するという貴重な利点を提供するが、まだ近似化に過ぎない。 別の従来技術は、フォントの記述を文書と共に埋込むかあるいは含めて、これ により他の側の者がこれを使用できるようにすることであった。このような埋込 み可能なフォントの製造者は、これらフォントをこれらが含まれる文書において のみ使用できるように設計し、これにより明白な許可を必要とすることなく作ら れる製造者のフォント記述のコピーに対するライセンスを受けた。不都合なこと に、知られる全てのこのようなシステムは、１つの言語のフォントでのみ稼働し 、これら文書が再現されるべきコンピュータがこの言語に対するインタプリタを 有することを前提とする。このため、生成された文書は、これらを再現するマシ ンが適切なフォント・インタプリタを持たなければ適正に再生できず、また仮に できても、前記インタプリタの１つの言語で書かれたフォントに対する保証され た移植性を提供できるに過ぎない。 別のこれまでの試みは、文書を生成するコンピュータのフォント・インタプリ タから文書に含まれる全ての文字−フォントの形状のビット・マップ・イメージ を記録してこれらイメージを文書コピーに埋込む文書レコーダ・アプリケーショ ンを備えることである。結果として得る移植可能な文書は、別のコンピュータに おける再生アプリケーションから視認されあるいは印刷されるように設計される 。再生側は、文書における各文字の形状をその関連する埋込みフォントから解釈 する。このプログラムは、実際に、ビット・マップ化された物理的および論理的 フォントを生成する能力を有する。即ち、ユーザが異なるサイズの同じ形状のフ ォントに対して個々のビット・マップ・イメージを格納する必要があることを欲 しなければ、システムがそれを１つのサイズで格納し、再生時にこれから異なる サイズでビット・マップ・パターンを生成しようとする。 この試みは、フォントの形状が著作権化できず、コピーされたビット・マップ ・パターンが、フォント記述において用いられる実際のコードまたは移動のシー ケンスおよびアウトライン線分からではなく、フォントの元の予め画定されたフ ォント記述の形状によって主として判定されるので、著作権問題を回避するよう に思われる。この試みはまた、文書を生成するコンピュータにより取扱われる任 意のフォントを再生することができるという前記利点を有する。この試みは、大 量のフォントを正確に生成するため大量のメモリを必要とするという短所を有す る。 発明の概要 本発明は、文字形状の記録のためのコンピュータ化された装置および方法に関 するものである。本発明のシステムは、それぞれ識別される予め画定されたフォ ントを持つ複数の文字を受取る。当該システムは、このように受取られる文字と 予め画定されたフォントごとに、文字の文字−フォント形状をその関連する予め 規定されたフォントで記述する予め規定されたフォント記述をアクセスする。次 いで、アクセスされた予め規定された各フォント記述により規定される文字−フ ォント形状から新たなフォント記述を生成し、この新たなフォント記述が関連す る文字を識別して、関連する文字−フォント形状を一連のアウトライン線分とし て記述する。 望ましくは、本発明は、予め規定されるフォント記述により記述される実際の 文字−フォント形状にのみ依存し、予め規定されるフォント記述がこれら形状を 記述する特定の方法には依存しない新たなフォント記述を開発する。望ましい実 施例において、本発明は、予め規定されるフォント記述では明白であるかあるい は明白でない形状の特徴を明白にするため、所与の予め規定されるフォント記述 によって提供される文字−フォント形状をモデル化する。例えば、望ましい実施 例において、このシステムは、予め規定される記述が規定する方法ではなく、前 記各文字−フォント形状自体の関数である当該形状のアウトラインにおける諸点 を見出すため、前記文字−フォント形状モデル化する。このような記述に依存す る諸点は、湾曲点、接線点、ＸまたはＹ極値点、および折れ点を含み得る。３つ の終端点の各々がかかる終端点の場所の記述におけるあり得る量子化エラー量だ け変化することを許しながら所与のアウトライン上で前後の線分終端点間の所与 の終端点を通るように直線を引くことが不可能ならば、望ましくは、所与の文字 −フォント形状アウトラインを規定するため予め規定されるフォント記述により 用いられる一連のアウトライン線分における所与の線分終端点が、このような記 述に依存しない折れ点であると見なされる。 望ましくは、このシステムが予め規定されるフォント記述依存点間にこのよう なフォント記述により規定される文字−フォント形状アウトラインを近似化する 。望ましくは、このシステムはまた、予め規定された記述におけるアウトライン の順序、開始点あるいはアウトラインの順序とは無関係に、このような各アウト ラインの記述に対する開始点、および標準的な規則に従う前記記述の方向を取上 げる。これにより、新たなフォント記述を予め規定された記述の形状を必要とし な い特質から解放させ、かつこのような記述を非常に均一にし、これにより再生を 容易にする。 システムが新たなフォント記述における各曲線線分の「深さ」を見出すことも また望ましい。このことは、各再生において曲線がどんなに細かく細分割されね ばならないかを示し、そのためこのような各細分をつなぐベクトルにより正確に 描画することができる。この深さは、曲線を細分へ繰返し細分割して、各細分を ベクトルによって近似化し、最も悪い適合が受入れられるまで細分について回帰 することによって計算される。最も深さ回帰レベルが曲線の深さを示す。 望ましくは、このシステムが、複数のフォントと、アウトライン記述およびビ ット・マップ記述を含むフォント記述言語との任意の１つで規定された形状から 新たなフォント記述を生成することができる。当システムがそれぞれ異なるフォ ントで規定される複数の文字を受取ると、これらの各フォントにおける文字のそ れぞれの形状に対する新たなフォント記述を自動的に生成する。当システムが複 数の異なるフォント記述言語で記述されたフォントを持つ複数の文字を受取ると 、１つのフォント記述言語で規定された文字に対する新たなフォント記述を生じ る。このシステムは、異なる物理的および論理的フォントを含む異なるフォント から予め規定されるフォント記述を受取るならば、予め規定されるフォント記述 のグループと対応するグループへ新たなフォント記述を分類する。 当システムが、１つ以上の個々の象形部（ｇｌｙｐｈ）あるいはかかる形状中 に含まれるつながらない形態と関連させられる文字フォントの形状アウトライン と共に分類することが望ましい。当システムは、どのアウトラインがこのような 各象形部の内側および外側のアウトラインであるかを判定し、象形部に対する内 側または外側のアウトラインであるかに従う標準規則に従って、その新たなフォ ント記述におけるこのような各アウトラインを画定するために用いられる一連の 線分の開始点と縦座標とを選択する。 当システムが、同じあるいは異なるフォント記述言語のどちらで画定されるか 同じあるいは異なるフォントの異なる文字における形状を突合わせ、２つ以上の 新たなフォント記述で用いられる任意の形状の１つの記述を記録することにより 記憶スペースを保管することが望ましい。このような比較が、各文字−フォント 形状無いのこのような各形状のサイズと場所とは独立することが望ましい。この ような比較は、このような形状についてのある特徴を記述する特徴点を生成し、 異なる形状の特徴点を比較し、それらの特徴点が一致するならば異なる形状の実 際のアウトラインのみを比較することによって早めることができる。このような 比較は、所与の特徴点が記憶される特徴点のどれかと一致するか否かを決定する ため所与の特徴点と比較されねばならないこのような特徴点数を少なくするため 、それらの特徴点によりかかる形状を分類することによって更に早めることがで きる。比較される形状が象形部でありかつ全ての象形部のアウトラインがこのよ うな比較を早めるように均一な規則に従って並べられることが望ましい。 また、システムが、テキストと共に用いられ得るロゴその他のイメージの如き 非文字形状から新たなフォント記述を生成することも望ましい。 本発明の一部の実施例では、当システムは、フォント化された入力テキストを 移植可能(portable)な文書を含むフォント化された出力テキストへ変換する。こ の出力テキストは、入力テキストにおける一連の文字と、これら文字に対する新 たなフォント記述と、新たなフォント記述のどれが出力テキストの各文字の形状 を表わすかの表示とを含んでいる。 当システムは、コンピュータのスクリーンまたはプリンタなどに移植可能な文 書のフォント化されたテキストのイメージを表現できることが望ましい。この能 力は、移植可能な文書を生成するコンピュータか、あるいは別のコンピュータに 置くことができる。この能力が別のコンピュータに置かれる場合は、取外し自在 な記憶媒体またはエレクトロニック・ネットワークなどによってコンピュータ間 に移植可能な文書を通信する能力が提供される。 本発明の一実施例は、大量記憶媒体に記録された先に述べた形式の移植可能文 書を含んでいる。 図面の簡単な説明 本発明の上記および他の特質については、添付図面に関して望ましい実施例の 以降の記述を読めば更に明らかになるであろう。 図１は、第１のコンピュータが複数の予め規定されたフォント記述を用いて書 かれた入力テキストを新たなフォント記述を有する移植可能文書へ変換し、第２ のコンピュータがこの移植可能文書を受取ってこれが含む新たなフォント記述を 用いてそのイメージを描写する本発明の一実施例の高レベルのブロック図、 図２は、取外し自在な大量記憶媒体上で移植可能文書が第１および第２のコン ピュータ間に通信される図１に示された実施例の一変更例の高レベルのブロック 図、 図３は、電子データ・ネットワーク上で移植可能文書が第１および第２のコン ピュータ間に通信される図１に示された実施例の一変更例の高レベルのブロック 図、 図４は、図１における第１のコンピュータの文字形状レコーダとしの使用を含 む複数の用途に対する本発明の一実施例により設計された文字形状レコーダ・ソ フトウエア・モジュールの機能的インターフェースの図、 図５は、図１に示された第２のコンピュータの文字形状プレーヤとしての使用 を含む複数の用途に対する本発明の一実施例により設計された文字形状プレーヤ ・ソフトウエア・モジュールの機能的インターフェースの図、 図６は、文書ビルダーおよび文字形状プレーヤにより実施される主要機能ステ ップを含む、図４の文字形状レコーダが使用される図１に示された第１のコンピ ュータの機能的要素の更に詳細な概略図、 図７は、図４および図６における文字形状レコーダに示されたＣｓｒＳｅｔＦ ｏｎｔＳｐｅｃｓ（）関数により実施される関数ステップの更に詳細なフローチ ャート、 図８は、図４および図６の文字形状レコーダにより生成される物理的フォント ・レコードのリスト、論理的フォント・レコードのリスト、およびレコーダがこ のような各物理的フォント・レコードと関連付けられ得る文字レコードの２進ツ リー、およびこの文字レコードとこの文字の形状の新たな記述を含む象形部プロ グラム・ストリング（ＧＰＳ）との間に作るリンクの概略図、 図９は、図４および図６における文字形状レコーダの一部であるＣｓｒＤｏＣ ｈａｒ（）関数により実施される関数ステップの更に詳細なフローチャート、 図１０は、図４および図６の文字形状レコーダにより生成される後続のデータ 構造、輪郭がいったん閉じられて置かれる階層的輪郭ツリー、このツリーの輪郭 構造の象形部要素への分割、この各象形部要素と関連して生成される象形部レコ ード、および各象形部要素の輪郭から得られる新たな形状記述を含む象形部プロ グラム・ストリング（ＧＰＳ）の概略図、 図１１および図１２は、それぞれ反曲点とＸ極値点における文字形状アレイに より受取られる曲線線分を図９のステップ３６４がどのように分割するかの図形 的表示、 図１３は、図９のステップ３６６において記述されるコーナー検出機能の更に 詳細な記述、 図１４Ａ−Ｄ、図１５Ａ−Ｃおよび図１６Ａ−Ｃは、図１３のコーナー検出ス テップを示すため用いられる図、 図１７および図１８は、図９のステップ４２２の曲線深さの分析を行うため用 いられるステップの更に詳細なフローチャート、 図１９は、図４および図６の文字形状レコーダにより生成される図１０に示さ れたタイプで、かつ関連する象形部ストリング（ＧＰＳ）により表わされる形状 が既にツリーにおける象形部レコードと関連する象形部プログラミング・ストリ ングのそれと一致するかどうかを調べるため新たな各象形部レコードに対するレ コーダにより行われる突合わせの象形部レコードの２進ツリーの概略図、 図２０は、図１、図６および図２１に示された移植可能なフォント資源に含ま れるデータ要素の概略図、 図２１は、ページ・ビルダーおよび文字形状レコーダにより行われる主要機能 ステップを含む、図５の文字形状プレーヤが用いられる図１に示された第２のコ ンピュータの機能要素の更に詳細な概略図である。 望ましい実施例の詳細な記述 図１は、移植可能なフォント化された文書を生成して再生するためのシステム １００の概要を提示する。このシステムは、移植可能文書１０４を生成できる第 １のコンピュータ１０２と、その付随するビデオ・モニター１０６とを含む。当 システムはまた、移植可能文書を再生することができる第２のコンピュータ・シ ステム１０８と、その付随するビデオ・モニター１１０と、プリンタ１１２とを 含む。 コンピュータ１０２および１０８は、プログラム命令と、データ構造と、前記 命令を実行して前記データ構造を操作するための１つ以上の処理要素を記憶する ための記憶装置を含むパーソナル・コンピュータまたはコンピュータ・ワークス テーションの如きコンピュータであることが望ましい。コンピュータの１つ以上 のプロセッサがかかる命令を実行する時、このプロセッサはこれらコンピュータ の各々に対して記述される機能要素を形成する。 第１のコンピュータ１０２は、文書ビルダー１１４を含む。この文書ビルダー は、フォント化入力テキスト１１６を受取るための手段を有する。このようなテ キストは、ディスクまたはデータ・ネットワークのような外部ソースから受取る ことができ、あるいはこのテキストは、ワード・プロセッサまたはデスクトップ ・パブリッシング・プログラムのような第１のコンピュータ上で実行するプログ ラムにおいて生成することができる。この入力テキストは、一連のフォント・ネ ームと、テキスト文字と、位置決めコードとからなっている。通常は、各テキス ト文字は、逐次先にある第１のフォント・ネームと関連付けられ、この各フォン ト・ネームは、当該フォントにおける各文字の形状を記述するコンピュータのフ ォント資源１２２における１組のコード化された予め規定されるフォント記述と 関連付けらている。 文書ビルダーは、入力テキストの連続するフォント・ネーム、テキスト文字、 および移植可能文書１０４のテキスト１１８に対する位置コードの各々と対応す るコードを置く。更に、入力テキストにおける文字およびフォント・ネームの一 義的な組合わせごとに、文書ビルダーが、対応する予め規定されたフォント記述 において記述された形状に対する新たなフォント記述を生成する。 前記文書ビルダーは、第１のコンピュータのインタプリタ１２０に、コンピュ ータのフォント資源１２２における文字フォント形状の予め規定されたフォント 記述を解釈させることによりこれを行う。フォント・インタプリタは、コード化 され予め規定されたフォント記述を文字−フォント形状のアウトラインを規定す る一連の移動、線および曲線へ変換する。このインタプリタは、これらを文書ビ ルダーへ提供する。文書ビルダーは更に、この解釈された形状の記述を第１のコ ンピュータの文字形状レコーダ（ＣＳＲ）１２４へ渡す。このＣＳＲは、解釈さ れた記述に含まれる形状をモデル化し、これが表わす形状により要求されない解 釈されたフォント記述の何らかの特質と視覚的に無関係な新たなフォント記述を 生じる能力を含む。ＣＳＲは、この新たなフォント記述を文書ビルダーへ戻し、 このビルダーがこのフォント記述を移植可能な文書テキスト１１８においてその 関連するフォントおよび文字を表わすため用いられたコードにより指示された移 植可能な文書資源１２６に置く。 第１のコンピュータ１０２と第２のコンピュータ・システム１０８とは、それ らの間に情報を通信するための装置を含んでいる。図２に示されるように、この 装置は、磁気ディスクまたは光ディスク、ＣＤまたはテープのような取外し自在 の大量記憶媒体１３０において第１のコンピュータから第２のコンピュータへ移 植可能なフォント資源を通信するための装置１２８Ａであり得る。取外し自在媒 体１３０は、単独生成コピーあるいは大量生成コピーを含み得る。図３に示され るように、これはまたネットワーク１３２上で移植可能な文書を通信することが 可能なネットワーク・インターフェース１２８Ｂでもよい。このネットワーク１ ３２は、ＬＡＮ、ＷＡＮ、テレコム接続、オンライン・サービス、インターネッ ト、および将来は、いわゆる情報ハイウエーを含み得る。 第２のコンピュータ・システム１０８もまた、ページ・ビルダー１３４と文字 形状プレイヤー（ＣＳＰ）１３６とを含む。このページ・ビルダーは、移植可能 文書からページ・イメージあるいはスクリーン・イメージのような描写されたイ メージを生成する。このビルダーは、連続フォント、文字及び位置コードを移植 可能文書１０４のテキスト１１８から読出す。これは、フォント・コードを用い て各文字と関連するフォントを決定する。これは、この位置コードを用いて、文 字を描写されたイメージで置く。各文字コードに応答して、ＣＳＰを調べてその 関連フォント・コードが与えられるとその文字に対する形状を生成する。ＣＳＰ は、フォント移植可能な文書資源１２６における文字とフォントに基いて指示さ れる新たなフォント記述からこの形状を生成する。これは、この形状をページ・ ビルダーへ送り、このビルダーがこれを描写されるイメージの適正位置に置き、 またこの描写されたイメージをビデオ・モニター１１０またはプリンタ１１２の ような出力装置へも送出する。 このように、図１に示された本発明の実施例が、第１のコンピュータのディス プレイ１０６に示される如き第１のコンピュータのフォント・インタプリタおよ び予め規定されたフォント資源で生成されるフォント化された文書を、フォント ・インタプリタおよびフォント資源を持たない第２のコンピュータに対して通信 してこれにより実質的に正確に同じ外観で視覚的に描写することを可能にするこ とが判る。また、この実施例は、第１のコンピュータの予め規定されたフォント 記述の著作権となり得る形状に依存しない特質をコピーすることなく行う。 第１のコンピュータの文字形状レコーダ１２４がこれに一連の移動、線、およ び２次と３次のベジェ曲線として記述される形状に対する新たなフォント記述を 生成することができるので、第１のコンピュータのフォント・インタプリタがこ のような一連の移動、線および曲線へ解釈できる任意のフォント記述言語から新 たなフォント記述を生成することができる。全ての主要なフォント記述言語がこ のような出力、即ちこのような形態へ容易に変換できる出力を生じることができ る関連するフォント・インタプリタを持つので、このことは、たとえ同じ文書中 に生じる場合でも、図１の実施例をこのような全てのフォント記述言語で使用で きることを意味する。 本発明のある代替的な実施例においては、文書ビルダーは、移植可能な文書資 源１２６におけるビット・マップ・フォントの表示を行うための手段を含む。こ れは、移植可能なフォント資源におけるこのようなイメージに対するフォント記 述として直接、小さなフォントに対するフォント・インタプリタ１２０から受取 るビット・マップ・パターンを記録するための手段を含む。このような実施例に おける文書ビルダーはまた、ビット・マップ・パターン上の縁部検出を実施し、 このパターンにおける各縁部における第１の点とこの縁部における各連続点間の 距離と対応する線とに対して移動命令を生成し、一連の移動および線分を先に述 べた文字形状記録プロセスへ供給するために、より大きなビット・マップが受取 られる時に使用される手段をも含む。これらの特徴により、本発明が視覚的にど んなフォントでも生成されるどんな文書でも、フォントが生成された元のフォン ト記述を持たない別のコンピュータ上に正確に再生することを可能にすることが 判る。 図１に開示された基本的概念は多くの用途を有する。その一部では、文書ビル ダー１１４および文字形状レコーダ１２４が直接、ワード・プロセッサ、描画プ ログラム、あるいはデスクトップ・パブリッシャのようなユーザ・アプリケーシ ョンへ組込まれる。他の用途では、オペレーティング・システムに組込まれる。 更に他の用途では、これはプリンタ・ドライバとしてインターフェースされるド ライバ・モジュールに置かれて、関連するコンピュータ・プラトフォームで実行 するように設計された実質的にどんな主要アプリケーションに対してもインター フェースすることができるようになる。 同様に、ある用途においては、ページ・ビルダー１３４および文字形状プレイ ヤー１３６は、はるかに大きなユーザ・アプリケーションへ組込まれる。他の用 途では、これは特殊な移植可能な文書ビューワ・アプリケーションの一部である 。また更に他の用途においては、オペレーティング・システムへ組込まれる。 移植可能文書の性格は、文書ビルダー１１４、レコーダ１２４、ページ・ビル ダー１３４、および文字形状プレイヤー１３６の使用と共に変化する。例えば、 これらのモジュールが全てはるかに大きなユーザ・アプリケーションに組込まれ る多くのシステムにおいては、移植可能文書はこのアプリケーションに対しては 通常のファイルである。文書ビルダーおよびレコーダが印刷ドライバ・モジュー ル内にあり、かつ文書ビルダーおよびプレイヤーが文書ビューワ・プログラムの 一部であるシステムにおいては、移植可能フォントの文書は、通常は最初にその フォント化されたテキストを生成したアプリケーションによって読出すことがで きない。文書ビルダー、レコーダ、ページ・ビルダーおよびプレイヤーがオペレ ーティング・システムに組込まれるシステムにおいては、このオペレーティング ・システムと互換性のある任意のアプリケーションにより生成されるファイルは 、移植可能文書１０４であり得る。 一部の実施例においては、１つのコンピュータが、文書ビルダーとレコーダの 両方、ならびにページ・ビルダーとプレイヤーとを含み、その結果コンピュータ は移植可能文書を送出と受取りの両方が可能である。 一部の実施例においては、移植可能文書は、ページ・ビルダーとプレイヤーの コードを含み、従って移植可能文書を読むコンピュータが、前にページ・ビルダ ーとレコーダのコピーを持つ必要なしに移植可能文書のテキストとフォントを見 ることができる。 図４および図５は、それぞれ文字形状レコーダ１２４と文字形状プレイヤー１ ３６の望ましい実施例を示している。この実施例においては、レコーダとプレイ ヤー１３６の両方が別個のソフトウエア・モジュールとして設計された。これら は、それらのコードを複数の異なるソフトウエア・アプリケーション、異なるコ ンピュータおよび異なるオペレーティング・システムで使用できるように、モジ ュール化された。これらは、ほとんど全ての主要なオペレーティング・システム でサポートされる共通に使用されるＣプログラミング言語で書かれた。これらは 、オペレーティング・システムに依存する任意の関数を含むものではない。また 、これらは、アプリケーション間で異なることが多い多くの機能性を含むことは ない。 一部の実施例においては、例えば、レコーダおよびプレイヤーは、Ｕｎｉｘコ ンピュータ、ＩＢＭ ＰＣ互換コンピュータおよびＡｐｐｌｅ社のマキントッシ ュ・コンピュータで走るソフトウエア・アプリケーションの一部である。このア プリケーションの各マシン依存のバージョンにおいては、これらはオペレーティ ング・システムとインターフェースして、文書とページ・ビルダーの機能を実行 し、他のタイプのコンピュータ上でアプリケーションの対応バージョンにより読 むことができる移植可能文書を生成するコードで囲まれている。これは、１つの タイプのコンピュータ上で生成されるフォント化された移植可能文書を仮想的に 正確に同じ外観で別のタイプのコンピュータ上で再生することを可能にする。 レコーダおよびプレイヤーの機能性のモジュラー化もまた、これらを図１にお いて述べたものと異なる目的のために使用することを可能にする。例えば、本発 明の一実施例においては、レコーダは、任意の入力テキストとは独立的に、予め 規定されたフォント記述のセットから新たなフォント記述のセットを生成するプ ログラムの一部として使用される。いったん生成されると、このような新たなフ ォントは、プレイヤー・モジュールを含むアプリケーションで使用することがで きる。 図４および図５において、各モジュールを用いるホスト・ソフトウエアにより 行うことができるファンクション・コールが左側に示される。これらは、図４に おける関数１５０〜１５８および図５の関数１７０〜１７８である。これらの図 面では、モジュールによりそのホスト・ソフトウエアへ逆に行われるファンクシ ョン・コールが右側に示される。これらのいわゆる「コールバック」関数は、図 ４においては番号１６０〜１６５が付され、図５においては番号１９０〜２０２ が付されている。各図の左側の関数コードは、レコーダまたはプレイヤーのモジ ュールの一部である。右側のコールバック関数のコードは、このようなモジュー ルを用いるホスト・ソフトウエアに含まれる。 図４において、関数ＣｓｒＭｏｖｅＴｏ（）、ＣｓｒＬｉｎｅＴｏ（）、Ｃｓ ｒＱｕａｄｒａｔｉｃＴｏ（）、およびＣｓｒＣｕｂｉｃＴｏ（）は、これらの 関数が文字の形状をレコーダに対して規定する移動、線および曲線を送るＥｘｅ ｃＣｈａｒ（）により呼出されるので、コールバック関数ＥｘｅｃＣｈａｒ（） からの線により指示される。 図６は、図１において第１のコンピュータ１０２に示される機能要素の更に詳 細な概略図を提示する。これは、予め規定されたフォント記述を用いる入力テキ スト１１６を移植可能文書１０４へ変換するため文書ビルダー１１４がモジュラ ー文字形状レコーダ１２４に対するホスト・プログラムとしてどのように対話す るかを示している。 文書ビルダーは、主要プログラム２０４と図４の右側に示されるコールバック 関数１６０〜１６５とを含む。 文書ビルダーの主プログラムに対して示される最初のステップは、ステップ２ １０である。これは、ＣＳＲのＣｓｒＯｐｅｎ（）関数１５０を呼出す。ステッ プ２１２では、ＣｓｒＯｐｅｎ（）が開いてプレイヤー・ソフトウエア・モジュ ール１２４を初期化して、これに作業してその初期データ構造をセットアップす るのに必要なメモリ・バッファと一時ファイルを与える。 この関数がいったん戻ると、文書ビルダーの次のステップ２１４は、これが入 力テキスト１１６における全てのコードを処理するまでループする。入力テキス トから受取った連続的な各コードに対しては、このループはその下方で意図され るべく示されるステップ２１６、２１８、２２０および２２２を実行する。 ステップ２１６は、受取られたコードが入力テキストに示されるコード２１７ の如きフォント・ネームであるか否かを調べるためテストする。もしそうであれ ば、そのサブステップ２２４、２２６、２２８および２３０が実行される。ステ ップ２２４は、受取られた完全フォント・ネームから基本的フォント・ネーム部 分を保管して、それに対してｐＦｏｎｔＩｄを指示する。ステップ２２６は、そ のサイズ、斜めであるか否か、および中ベタまたはアウトライン・フォントであ るか否かの如きフォントの属性を受取った完全フォント・ネームから計算し、そ れをＦｏｎｔＡｔｔｒｉｂｕｔｅｓと呼ばれるデータ構造に記憶する。次いで、 ステップ２２８が、ｐＦｏｎｔＩｄおよびＦｏｎｔＡｔｔｒｉｂｕｔｅｓにより ＣＳＲのＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）関数１５１を呼出す。 図７は、ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）動作の更に詳細な記述を示す。 ステップ３００において、ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）が呼出されたｐ ＦｏｎｔＩｄと同じ物理的フォント・ネームを指示するｐＦｏｎｔＩＤ値３０４ を持つ物理的フォント・レコードについて、図８の最上部に示され物理的フォン ト・リストとして知られる物理的ＦＮＤレコード３０２のリンクされたリストを 探索する。ＣＳＲが指定された物理的フォントに対してレコードを持たないこと を意味するこのような一致が見出されなければ、ステップ３０６が、ステップ３ ０８、３１０および３１２を実行することによりこのような物理的フォント・レ コードを生成する。ステップ３０８は、実際に、指定されたｐＦｏｎｔＩＤ値を 持つ新たな物理的フォント・レコードのデータ構造３０２を生成し、これを物理 的フォント・リストの終りに置く。ステップ３１０は、図６に示されたホスト文 書ビルダーのＧｅｔＦｏｎｔＩｎｆｏ（）コールバック関数１６２を呼出して、 フォント・インタプリタから物理的フォントについての情報を取得し、この情報 を新たな物理的フォント・レコードに置く。これは、フォント・インタプリタが この物理的フォント形状の移動、線および曲線を規定するＯＲＵ解を含む。これ はまた、物理的フォントのネームを含む。ステップ３１２は、「ヒント呈示（ｈ ｉｎｔｉｎｇ）」として知られるプロセスにおいて用いられる英数字の小さなサ ブセットごとに文書ビルダーのＧｅｔＣｈａｒＩＤ（）およびＥｘｅｃＣｈａｒ （）関数を呼出す。このような文字ごとに、最初にＧｅｔＣｈａｒＩＤ（）を呼 出し、これが第１のコンピュータのフォント・インタプリタにおける当該文字を 識別するために用いられる文字コードを返し、次いでこれがこの文字に対する文 字コードのＧｅｔＣｈａｒＩＤ（）戻しでＥｘｅｃＣｈａｒ（）を呼出して、こ の文字の形状を得る。 これは、標準的な横と縦の位置と、物理的フォントにおけるある文字特徴と関 連する標準的な太さの測定値を得るために行われる。これらのヒント呈示値は、 物理的フォント・レコードに記録され、最後に移植可能文書における物理的フォ ントと共に記憶される。これは、文字が描写される時文字のアウトラインの重要 な縁部の位置を変更するためこれらの値が文字形状プレイヤーにより使用できる ように行われ、使用されたピクセル・パターンの凹凸（ｇｒａｎｕｌａｒｉｔｙ ）が与えられると、更に魅力的なイメージを生じる。ヒント呈示は、コンピュー タのフォント技術において周知である。ここで注意すべき重要なことは、移植可 能文書１０４に記録されたヒント呈示情報が第１のコンピュータのフォント資源 における予め規定されたフォント記述に含まれるヒント呈示情報からではなく、 むしろフォントにおける文字特徴の実際の位置とサイズから得られることである 。 ＥｘｅｃＣｈａｒ（）１６４は、ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）および ＣｓｒＤｏＣｈａｒ（）の両方により使用される重要なコールバック関数である 。これは、通常は入力テキストにおける当該文字に対するコードである所与の文 字に対してフォント・インタプリタが使用するネームを持つＣＳＲ関数により呼 出される。これは、ｐＦｏｎｔＩＤおよびＦｏｎｔＡｔｔｒｉｂｕｔｅｓにより 示されるその時のフォントにおける文字について第１のコンピュータのフォント ・インタプリタ１２０を呼出すことにより応答する。このフォントがスケーラブ ル・フォントであるならば、ＥｘｅｃＣｈａｒ（）が、ＣｓｒＭｏｖｅＴｏ（） 、ＣｓｒＬｉｎｅＴｏ（）、ＣｓｒＱｕａｄｒａｔｉｃＴｏ（）、あるいはＣｓ ｒＣｕｂｉｃＴｏ（）をそれぞれ呼出すことにより、フォント・インタプリタか ら受取られる各移動、線、２次ベジェ曲線、あるいは３次ベジェ曲線に対して応 答して前記移動またはアウトライン線分の規定をＣＳＲへ送る。ある文書ビルダ ーでは、フォント・インタプリタがビット・マップ・パターンを返すならば、ビ ット・マップにおける縁部検出を行うことによりＥｘｅｃＣｈａｒ（）が応答し 、次い でそのポイントの１つへの初期移動で、その後この縁部について各連続点間の一 連の線が続いてＣＳＲに対して検出された各縁部を記述する。 指定されたｐＦｏｎｔＩＤと一致する物理的フォント・レコードが前に存在し たかあるいはステップ３０８、３１０および３１２により生じたばかりの如何に 拘わらず、ステップ３１４がこの物理的フォントにその時アクティブな物理的フ ォントを記録させる。 次いで、ステップ３１６が、ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）が呼出され たものと一致するＦｏｎｔＡｔｔｒｉｂｕｔｅｓ値３１９を持つ論理的フォント ・レコードに対してその時アクティブな物理的フォント・レコード３０２と関連 する論理的フォント・レコード３１８のリンクされたリストを探索する。これら の値は、文書の座標中に規定される文字形状を生じるため物理的フォントがどの ようにスケールが付されて（必要に応じて）斜めにされるかを規定するｆｏｎｔ Ｍａｔｒｉｘを含む。これはまた、文字形状が中ベタかアウトライン形態で描写 されるかされないかについての情報をも含み、アウトライン形態であるならば、 アウトラインがどのような太さであるか、またアウトラインがどんな角度で合流 するかについての情報を含んでいる。指定されたＦｏｎｔＡｔｔｒｉｂｕｔｅｓ を持つこのような前の論理的フォント・レコードが見出されなければ、ステップ ３２０がその時の物理的フォント・レコードに帰属する論理的フォント・リスト の終りに新たな論理的フォント・レコードを生成し、それに指定されたＦｏｎｔ Ａｔｔｒｉｂｕｔｅｓ値３１９を記録する。次に、ステップ３２２が、一致する ＦｏｎｔＡｔｔｒｉｂｕｔｅｓを持つ前に存在するか新たに生成された論理的フ ォントをＣＳＲのその時アクティブな論理的フォントにし、ステップ３２４が、 ｐＦｏｎＣｏｄｅにより指示されるその時アクティブな論理的フォントを一義的 に充分にするコードで文書ビルダーへ戻る。 ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）が文書ビルダーへ戻った後、ステップ２ ３０がｐＦｏｎｔＣｏｄｅにより指示されたＦｏｎｔＣｏｄｅ２１７Ａを移植可 能文書のテキスト１１８における一連のコードへ置く。これがいったん行われる と、プログラムはループ２１４の初めへ進み、入力テキストから受取る次のコー ドを処理する。 入力テキストから受取ったコードが文字を表わすコード２１９であるならば、 ステップ２１８におけるテストは満足され、ステップ２３６および２３８が行わ れる。 ステップ２３６は、当該文字に対するＣＳＲのＣｓｒＤｏＣｈａｒ（）関数１ ５２を呼出す。図９に更に詳細に示されるこの関数はＣＳＲの最も重要な部分の １つであるが、これはこの関数が文字−フォント形状記録プロセスを実際に実行 するからである。その最初のステップであるステップ３２８は、図８に示された 文字レコード３３０の２進ツリーを探索し、このツリーはＣｓｒＤｏＣｈａｒ（ ）が呼出されたものと一致するｃｈａｒＣｏｄｅ３３２を持つ文字レコードに対 するその時アクティブな物理的フォント・レコード３０２から外される。このツ リーは、その文字レコードの各々が１つはｐＮｅｘｔＵｐポインタ３４０を介し １つはｐＮｅｘｔＤｏｗｎポインタ３４２を介する２つの子供の文字レコードを 指示することができるゆえに、周知のタイプのデータ構造である２進ツリーであ る。所与のレコードより小さなｃｈａｒＣｏｄｅを持つ所与のレコードからの全 てのレコードが所与のｐＮｅｘｔＤｏｗｎポインタからくるように、またより高 いｃｈａｒＣｏｄｅを持つものからの全てのレコードがｐＮｅｘｔＵｐからくる ように、レコードがこのツリーに付加される。これにより、指定されたｃｈａｒ ＣｏｄｅがこのレコードにおけるｃｈａｒＣｏｄｅより小さいか大きければ、各 レコードにおけるｐＮｅｘｔＤｏｗｎまたはｐＮｅｘｔＵｐに追従することによ り、ツリーが迅速に探索されることを可能にする。このプロセスは、指定された ｃｈａｒＣｏｄｅと一致するレコードが見出されるか、あるいはこのような一致 する文字レコードがツリーに存在しないことを意味するゼロ・ポインタを持つｐ ＮｅｘｔＤｏｗｎまたはｐＮｅｘｔＵｐが見出されるまで追従される。 このような一致するｃｈａｒＣｏｄｅがその時の物理的フォントが関連する文 字レコードの１つに見出されるならば、ＣｓｒＤｏＣｈａｒ（）に対する前の呼 出しが既にその時のフォントにおけるその時の文字の形状を記録し、このため、 ＣｓｒＤｏＣｈａｒ（）はこれ以上することがない。この場合、ステップ３３４ は文書ビルダーへ戻る。このような一致が見出されなければ、ステップ３３６は 図９に示されるステップの残りに文字形状記録を行わせる。 文字形状記録における最初のステップであるステップ３３８は、新たな文字レ コード・データ構造３３０を生成し、ｃｈａｒＣｏｄｅが与えられればこれを適 切な位置で２進ツリーへ挿入する。ｐＲｏｏｔＣｈａｒａｃｔｅｒがゼロ値を持 つならば、ツリーは空でありこれがその時の物理的フォントに対して処理されつ つある最初の文字であることを示す。この場合、新たな文字レコードがツリーの 基部として挿入され、ｐＲｏｏｔＣｈａｒａｃｔｅｒがそれに指示させられる。 ツリーが空でなければ、新たな文字レコードがツリーの上記探索がゼロのｐＮｅ ｘｔＤｏｗｎまたはｐＮｅｘｔＵｐのポインタに遭遇した点に挿入され、このポ インタは新たなレコードに指示させられる。システムは、ツリーが不均衡である か否かを調べるため検査し、更に多くのレコードがそのレコードのあるものの片 側よりも他の側に依存する。もしそうであれば、ツリーができるだけ僅かなレベ ルを持つように均衡させるため再構成され、これにより最も迅速に探索できる。 ステップ３３８が文字ツリーに処理される文字に対する文字レコードをいった ん挿入すると、ステップ３４０が、図１０に示された文字形状アレイ３３９の初 めを含む関連するその初期データ構造をセットアップすることにより、文字形状 処理を初期設定する。文字アレイ３３９は、ポイント・ストラクト（ｐｏｉｎｔ ｓｔｒｕｃｔ）３４１の連続に文書ビルダーのＥｘｅｃＣｈａｒ（）関数１６ ４から受取るアウトライン線分を記述する点を記憶する。次に、ステップ３４２ が当該文字に対する文書ビルダーのＥｘｅｃＣｈａｒ（）関数１６４を呼出し、 これが、第１のコンピュータのフォント・インタプリタからＥｘｅｃＣｈａｒ（ ）へ供給される各移動、線、２次ベジェ曲線および３次ベジェ曲線の各々に対し て図６に示されるＣＳＲのＣｓｒＭｏｖｅＴｏ（）、ＣｓｒＬｉｎｅＴｏ（）、 ＣｓｒＱｕａｄｒａｔｉｃＴｏ（）およびＣｓｒＣｕｂｉｃＴｏ（）関数１５３ 、１５４、１５５および１５６をそれぞれ呼出すことにより応答する文字に対す る文書ビルダーのＥｘｅｃＣｈａｒ（）関数１６４を呼出す。ＥｘｅｃＣｈａｒ （）がいったん呼出されると、ＣｓｒＤｏＣｈａｒ（）はＥｘｅｃＣｈａｒ（） が戻るのを待機し、この待機中、ＣＳＲが、ＥｘｅｃＣｈａｒ（）が呼出すＣｓ ｒ Ｔｏ（）の動作による初期の文字形状記録を行う。簡単にするため、図９ および待機後のその説明では、Ｃｓｒ Ｔｏ（）関数により行われるステッ プ は、あたかもそれがＣｓｒＤｏＣｈａｒ（）関数の一部であるかのように未然ル ープ３４４とそれによるステップにより表わされる。 ＥｘｅｃＣｈａｒ（）により呼出される関数がＣｓｒＭｏｖｅＴｏ（）である と、ステップ３４６は、ステップ３４８および３５０を実行させる。ステップ３ ４８は、図９に示されるように開いた輪郭構造３４９Ａが既に存在するか否かを 調べるためテストし、もしそうであれば、このステップはステップ３５２および ３５４を実行する。開いた輪郭構造３４９Ａを用いて、ＣｓｒＤｏＣｈａｒ（） が呼出されたその時の文字−フォントの組合わせにおいて処理されるその時のア ウトラインの形状から得られるアウトライン線分を含む情報を受取る。このよう な前に開いた輪郭があるならば、ＣｓｒＭｏｖｅＴｏ（）呼出しがこれが新たな アウトラインの開始を表わすアウトラインからの離反を示す。この場合、ステッ プ３５２は、前に開いた輪郭３４９Ａにおける情報を終了してこれを閉じる。次 いで、ステップ３５２が前記の閉じた輪郭３４９を、これも図１０に示される如 き閉じた輪郭構造の階層的ツリーである輪郭ツリー３５６に置く。ステップ３５ ０に達する時までにＣｓｒＭｏｖｅＴｏ（）に対する呼出しが行われた時前に閉 じた輪郭があったか否かに拘わらず、このステップはその最初の点がＣｓｒＭｏ ｖｅＴｏ（）により示される変位により決定される新たな輪郭を開く。 ＥｘｅｃＣｈａｒ（）がＣｓｒＬｉｎｅＴｏ（）、ＣｓｒＱｕａｄｒａｔｉｃ Ｔｏ（）あるいはＣｓｒＣｕｂｉｃＴｏ（）を呼出すと、ステップ３５８が図９ において意図されたステップ３６０、３６２、３６４、３６６および３６８を実 行させる。 ステップ３６０は、輪郭が開いていなければエラーとして抜けるが、これはＣ ｓｒＬｉｎｅＴｏ（）、ＣｓｒＱｕａｄｒａｔｉｃＴｏ（）およびＣｓｒＣｕｂ ｉｃＴｏ（）が全てその時の輪郭において前に規定された点に関して線分である と規定されるゆえであり、このような開いた輪郭がなければ、システムはこれを どのように解釈するか判らないことになる。 ステップ３６２は、Ｃｓｒ Ｔｏ（）関数により連続する各アウトライン 線分と関連する点を記憶する。ＣｓｒＬｉｎｅＴｏ（）に対するＥｘｅｃＣｈａ ｒ（）による各呼出しが、アレイに対する１つの点、このアレイにおける前の点 からの線のオン・アウトラインの終点を加える。ＣｓｒＱｕａｄｒａｔｉｃＴｏ （）に対する各呼出しが、アレイに対する２つの点、第１はアレイにおける前の 点で始まる２次ベジェ曲線のオン・アウトライン終点が後に続くオフ・アウトラ イン制御点で前記曲線を加える。また、ＣｓｒＣｕｂｉｃＴｏ（）に対する各呼 出しが、３つの点、即ち、アレイにおける前の点で始まる３次ベジェ曲線のオン ・アウトラインが後に続く前記曲線の２つのオフ・アウトライン制御点をアレイ に加える。 ステップ３６４は、ＣｓｒＱｕａｄｒａｔｉｃＴｏ（）またはＣｓｒＣｕｂｉ ｃＴｏ（）に対する呼出しにより受取られる各曲線線分を微分して、この曲線が 変曲点またはＸＹ極値点（実際には、横または縦の接線を持つ点）を含むかどう かを調べる。これが何らかのこのような点を見出すならば、これはこれらの点を 文字形状アレイにおけるものとしてマークし、あるいはこの点が文字形状アレイ に既にある終点以外にあるならば、これは前記曲線をこのようなマークされた点 で細分割して、分割されない曲線を表わす１組の点を前記細分割の結果として得 る曲線の各々を表わす１組の点で置換する。 図１１は、その中間に変曲点を持つ３次ベジェ曲線４０２を示す。この曲線は 、最初からＣｓｒＣｕｂｉｃＴｏ（）から受取られる３つの点、即ち、第１の制 御点４０４と第２の制御点４０６と終点４０８で表わされる。この曲線はまた、 文字形状あるにおける前の点４１０により規定される。ステップ３６４は、この 曲線が変曲点４１２を持つことを検出する。この点が曲線の２つの終点４０８ま たは４１０の１つではないので、これは曲線を変曲点４１２でそれぞれ２つの制 御点４１５と４１６および４１７と４１８である２つの新たな曲線４１１と４１ ３に細分割する。曲線４１１は、その終点として変曲点４１２を有する。曲線４ １３は、その終点として元の曲線の終点４０８を有する。点４１５、４１６、４ １２、４１７および４１８は、元の曲線の２つの制御点４０４および４０６の代 わりに文字形状アレイに挿入される。図１２は、横方向の接触点で２つの新たな 曲線に同様に分けられる３次ベジェ曲線４０２Ａを示す。 ステップ３６６は、アレイにおける両側で規定される線または曲線の線分を持 つ文字形状アレイに何らかのオン・アウトライン点が存在するかどうかを調べる ために検査し、もし存在すれば、このような点の各々に対して、この点がコーナ ーまたは接触としてマークされるべきかを調べるために検査する。接触は、コー ナーとして示されずかつ曲線線分と線の線分との間にある点を単に拾うことによ り選択され、この場合線の線分は１つの３次ベジェ曲線がそれらの両方の形状を 近似化できそうにない充分な長さである。このような各点もまた、輪郭Ｃｏｎｔ ｏｕｒＢＢｏｘに記憶されるＸとＹの両座標に対する最大値および最小値と比較 され、かかる最大値か最小値よりもそれぞれ大きいか小さい座標を持つならば、 この最大値または最小値が座標と等しくなるように更新される。この点がＸの最 大であるならば、図１３のプロセスにより決定されるようにそれに形成される時 計方向または反時計方向のいずれかの角度方向が輪郭の実際の方向として記録さ れる。 図１３は、コーナーとしてマークされるべき点を拾って可能ならば方向をこの ようなコーナーと相関させるため使用されるプロセスを示している。このプロセ スは、ＣＳＲにより受取られる形状の記述におけるアウトライン分解ユニット（ ＯＲＵ）の量子化の結果として得ることができる明瞭なコーナーはコーナー点と して表示されないことを保証するため実行される。これは、ステップ３７０〜３ ７６を含む。 ステップ３７０は、方形３８４に対して文字形状アレイにおいてテストされる 点３８１に先行する点３８０から図１４Ｂに示される最も左と最も右のベクトル １Ｌおよび１Ｒを見出す。この方形は、１つの側面における２つのアウトライン 分解ユニット（ＯＲＵ）であり、これがテストされた点３８１の中心にある。「 左」および「右」は、アウトライン線分が低調波形状アレイにおいて受取られた 方向に関して規定される。ステップ３７２は、文字形状アレイにおけるテスト点 に続く点３８２の周囲の中心となる２つの同様なＯＲＵ方形３８６に対してテス トされる点３１８から最も左と最も右のベクトル２Ｌおよび２Ｒをそれぞれ見出 す。 ベクトル１Ｌおよび１Ｒは、このような点の各々の場所におけるあり得る量子 化誤差が与えられれば、点３８０から点３８１へのベクトルに対して可能な方向 の範囲を表わす。同様に、ベクトル２Ｌおよび２Ｒは、点３８１、３８２におい てあり得る誤差が与えられれば、点３８１から点３８２へのベクトルに対して可 能な方向の範囲を表わす。 テスト点３８１が曲線である前または後の線分が曲線である場合、点３８０ま たは３８２はそれぞれ曲線外の制御点となる。しかし、２次または３次のベジェ 曲線の終点からその最も近い制御点の線がこの曲線の終点における接線であり、 このため、終点からこの制御点への線がこの終点における隣接するアウトライン 線分となす角度を反映するので、これは問題ではない。 ステップ３７０および３７２がいったんベクトル１Ｌ、１Ｒ、２Ｌおよび２Ｒ を計算すると、テストされた点３８１がどのように表示されるべきかを調べるた めステップ３７３、３７４、３７５および３７６が一連のテストを行う。ステッ プ３７３は、ベクトル２Ｌおよび２Ｒがそれぞれ１Ｌおよび１Ｌの両方に対して ゼロより大きくかつ１８０度より小さな左方角度をなすかどうかを調べるためテ ストする。図１４の事例においては、このことは、前記ステップが両ベクトル２ Ｌおよび２Ｒが図１４Ｃに示される角度範囲３７７内に該当するかどうかを調べ るためテストすることを意味する。このテストが満たされるならば、これは点３ ８１と３８２間のあり得る全てのベクトルが、あり得る量子化誤差が与えられる ならば、このあり得る誤差が与えられるものとして、点３８０と３８１間のあり 得る全てのベクトルと左方角度をなすことを意味し、これによりステップ３７３ がテストされた点３８１を明確な左方コーナーとして表示する。 ステップ３７３のテストが満たされなければ、ベクトル２Ｌおよび２Ｒがそれ ぞれ１Ｌおよび１Ｒの双方に対してゼロ度より大きく１８０度より小さい右方角 度をなすかどうかをステップ３７４がテストする。図１４の事例において、この ことは、ベクトル２Ｌおよび２Ｒの両方が図１４Ｃに示される角度範囲３７８内 に該当するかどうかを調べるためテストすることを意味する。ステップ３７４の テストが満たされるならば、点３８１と３８２間の全てのあり得るベクトルが、 あり得る量子化誤差が与えられるものとして点３８０と３８１間の全てのあり得 るベクトルと右方角度をなすことを意味し、このため、テストされた点を明確な 右方角度として表示する。 ステップ３７３および３７４におけるテストがいずれも満たされなければ、ス テップ３７５は、２Ｌが１Ｒに対してゼロ度より大きくかつ１８０度より大きく ない右方角度をなすかどうかを調べるためテストし、またこのステップは１Ｌに 対してゼロ度より大きくかつ１８０度より大きくない左方角度をなすかどうかを 調べるためテストする。図１４の事例においては、このことは、このステップが ２Ｌと２Ｒ間のあり得る方向範囲のどの部分も図１４Ｃに示されるように、１Ｌ と１Ｒ間のあり得る方向３８１の範囲内に該当しないことを調べるためテストす ることを意味する。ステップ３７５の条件が満たされるならば、点３８１と３８ ２間のあり得るベクトルが、あり得る量子化誤差が与えられものとして、点３８ ０と３８２間のあり得るどのベクトルで直線をなし得ないことを意味し、従って ステップ３７５は、明確なコーナーとしてこの点を表示する。しかし、このステ ップは、左方または右方のいずれかの角度のコーナーとして前記点をマークする が、これはステップ３７３および３７４のテストがいずれも満たされなかったた めである。 ステップ３７３、３７４および３７５におけるテストのいずれも満たされなか ったならば、ステップ３７６は、この点をコーナーではないものとマークする。 これらのテストの図１４Ａおよび図１４Ｂに示される点のセットに適用するこ とが、図１４Ｄに示されている。同図において、２Ｌおよび２Ｒ間のあり得るベ クトル範囲が１Ｌおよび１Ｒ間のあり得るベクトル範囲の明らかに左方にある弧 の部分３７７に該当することが判る。このように、ステップ３７３のテストが満 たされ、テストされた点は明確な左の曲がりとして表示され、これはＯＲＵ量子 化の結果として鋭すぎる角度を持つ曲がりである。これは、たとえ点３８０、３ ８１および３８２の各々のＸおよびＹの値が、これらの周囲の中心の１つのＯＲ Ｕ方形３９８により示されるように、２分の１のＯＲＵの最大ＯＲＵ丸め誤差だ けいずれも方向にも変化することが許容されたとしても、各図の点線で示される ようにこれらの点を通る直線４００を引くことは不可能であろうゆえに、図１４ Ａに示される。 図１５Ａ〜図１５Ｃに示される場合においては、点３８０Ａ、３８１Ａおよび ３８２Ａ間の明確な左方角度は、それらの間に距離があるものとして、３つ全て の方形３９８Ａと接触する線４００Ａを引くことができるほどに僅かであり、こ れらの点間の明確な角度がＯＲＵ丸め誤差で生成され得ることを示す。図１５Ｃ に示されるように、２Ｌおよび２Ｒ間のあり得るベクトル方向範囲が完全に左に も右方にも存在せず、あるいは完全に１Ｌおよび１Ｒ間のあり得るベクトル方向 の範囲にあるゆえに、ステップ３７３、３７４および３７５のテストがいずれも 満たされない。この場合、ステップ３７６はテストされた点をコーナーでないも のとして表示する。 図１６Ａ〜図１６Ｃに示される場合は、明確な左方角度は明らかにコーナーで あるほど充分に鋭いが、量子化誤差は左方の曲がりではなく角度のある点線で示 されるように右方の曲がりであり得るほど充分に大きい。この場合、図１６Ｃに 示されるように、２Ｌおよび２Ｒ間のあり得るベクトル方向の範囲は、１Ｌおよ び１Ｒにより示されるあり得る方向範囲の完全に左方でも完全に右方でもなく、 このため、ステップ３７３および３７４のテストは満たされないことになる。し かし、２Ｌおよび２Ｒにより示されるあり得る方向の前記範囲は、１Ｌおよび１ Ｒにより示されるあり得る方向範囲の完全に外側にあり、このため、ステップ３ ７５のテストは満たされ、テストされた点は左方または右方のいずれかの方向の コーナーとして表示される。この場合は、文字形状レコーダがこの点を図９のス テップ３６８における区分目的のためマークされた点として用いることになるが 、このコーナーがＸ最大値であるならば、同図のステップ３６６における輪郭方 向の計算にはこれを用いない。その代わり、最後の明確な方向がもしあるならば これを輪郭の実際の方向としてＸ最大値の処理時にコーナーと関連したままに残 すことになる。 ステップ３６４および３６６がいったん行われると、ステップ３８６は、ステ ップ３６４および３６６により変曲点、ＸＹ極値点、コーナーあるいは接線とし てマークされた点の連続的対間にある文字形状アレイにおけるアウトライン線分 の部分に対してステップ４２０、４２２、４２４および４２６を実行する。 ステップ４２０は、文字形状アレイにおける１つ以上の線分をカバーするアウ トラインのこのような部分を線または３次ベジェ曲線で近似化する。この２つの マークされた点間のアウトライン部分が単純な線または３次ベジェ曲線であるな らば、この線またはベジェ曲線は近似化として用いられる。さもなければ、線ま たは曲線適合手法を用いて近似を見出す。 アウトライン部分が曲線で近似化されるならば、ステップ４２２が、近似曲線 の「深さ」を計算する。即ち、このステップは、曲線の細分割間の最悪の誤りお よびその終点間のベクトルが２分の１のＯＲＵより小さくなる前に、曲線が２つ に細分割される回数を計算する。この値は、文字形状プレイヤーが、移植可能フ ォント資源から文字形状を読出してベクトル近似化により正確に描写するため各 曲線をどれだけ細かく細分割しなければならないかを知るために、文字形状プレ イヤーによって使用される。 図１７は、この深さ分析を行う主プログラムの諸ステップを示し、図１８は反 復的細分割を実際に行う反復的サブルーチンの諸ステップを示している。この主 プログラムは、４つの主要ステップ４３０、４３２、４３４および４３６を有す る。 ステップ４３０は、曲線の終点にわたるベクトルと曲線の各制御点との間の距 離が２分の１ＯＲＵより小さいかどうかを調べる。もしそうであれば、曲線がそ の終点間のベクトルにより丸め誤差の制限内で近似化されるように細分割される 必要が全くないので、このステップは０の深さを返す。ベジェ曲線の性格により このようなベクトルが、この曲線の制御点の１つまでの最大距離よりも大きなそ の関連する３次ベジェ曲線上のどの点までの距離を決して持ち得ないから、また 前記ベクトルから前記曲線までの最大距離を見出すことよりも、前記ベクトルか ら２つの制御点までの最大距離を見出すことが数学的にはるかに簡単であるので 、ベクトルと曲線の制御点間の距離が用いられる。 ステップ４３０のテストが満たされなければ、ステップ４３２は、図１８のＲ ｅｓｕｒｓｉｖｅＳｕｂｄｉｖｉｓｉｏｎサブルーチンを呼出す。図１８に示さ れるように、このサブルーチンは、これが細分割する３次ベジェ曲線の１ｓｔＥ ｎｄ、１ｓｔＣｏｎｔｒｏｌＰｏｉｎｔ、２ｎｄＣｏｎｔｒｏｌＰｏｉｎｔおよ び２ｎｄＥｎｄに対するポインタで呼出される。またこのサブルーチンは、反復 深さによっても呼出される。このサブルーチンは、ステップ４４０、４４２、４ ４４、４４６および４４８を含む。 ステップ４４０は、サブルーチンが呼出される深さの値が、全曲線における行 われる反復によりそれまでに達していた最大深さであるその時のｍａｘＤｅｐｔ ｈ値よりも大きいかどうかを調べるためにテストする。もしそうであれば、この ステップは、ｍａｘＤｅｐｔｈの値を反復の深さに等しくセットする。次いで、 ステップ４４２は、反復が呼出されたベジェ曲線の中間点を見出して、この曲線 を前記中間点で２つの新たなベジェ曲線に分割する。次いで、ステップ４４４は 、新たな部分曲線のどれがその終点とその２つの制御点の１つとの間のベクトル からの最大距離を持つかを見出す。これがいったんなされると、ステップ４４６ が、前記の最大距離がＯＲＵの２分の１より小さいかどうかを調べるためテスト する。もしそうであれば、ステップ４４６はｄｅｅｐｅｓｔＳｕｂＣｕｒｖｅと 呼ばれる構造に１ｓｔＥｎｄおよび２ｎｄＥｎｄを格納し、従って図１７に示さ れたルーチンがどこでこの曲線が最も深い反復で終了するかを知ることができ、 このルーチンを返す。もしそうでなければ、ステップ４４８が、終点をつなぐベ クトルとその２つの制御点の１つとの間の最大距離を持つ新たに形成される部分 曲線に対するＲｅｃｕｒｓｉｖｅＳｕｂｄｉｖｉｓｉｏｎサブルーチンを呼出す 。 コンピュータ・プログラミングの当業者は知るように、このＲｅｃｕｒｓｉｖ ｅＳｕｂｒｏｕｔｉｎｅは所与のベジェ曲線を半分に分割し続け、最悪適合の半 分がＯＲＵの２分の１以内に適合させられるまで、最悪適合の半分を拾って更に この半分を半分に分割する。この時、ｍａｘＤｅｐｔｈは最も深い反復のレベル を保持し、ｄｅｅｐｅｓｔＳｕｂＣｕｒｖｅは最も深い部分曲線の終点を保持す る。次いで、最も深い反復がこれを呼出した反復へ戻り、ＲｅｃｕｒｓｉｖｅＳ ｕｂｒｏｕｔｉｎｅに対する最初の呼出しが図１７のステップ４３２へ戻るまで 、この反復がそれを呼出した反復へ戻り、、、のように反復する。 この時、ステップ４３４が、ｄｅｅｐｅｓｔＳｕｂＣｕｒｖｅに格納された最 も深い部分曲線の終点の１つが深さの計算が行われつつある全曲線の終点の１つ であるかどうかを調べるためテストする。もしそうであれば、このステップは、 この時前の反復により見出された最も深い部分曲線を含むものと反対側の全曲線 の終りを含む全曲線の半分に対してＲｅｃｕｒｓｉｖｅＳｕｂｄｉｖｉｓｉｏｎ サブルーチンを再び呼出す。これは、所与の３次ベジェ曲線の細分割とこれらの 細分割のベクトル近似化との間の微分が、全曲線の２つの終点間のどこかに対す る大域最大である１つの局所最大を持つか、あるいは一方が他方より深い反復を 要求する曲線の２つの終点の各々に見出される２つの局所最大を持つゆえに、行 われる。最初の場合、ステップ４３２におけるＲｅｃｕｒｓｉｖｅＳｕｂｒｏｕ ｔｉｎｅに対する最初の呼出しの反復は、全曲線に対する最大偏差を取得するよ うに保証される。しかし第２の場合は、第１のレベルの反復における最大偏差を 持つ全曲線の半分は、最も深い局所最大を持つ終りを有するものではなく、この ため、ステップ４３２の反復は、曲線の真の最大深さを見出し得ない。ステップ ４３４は、この第２の場合における全曲線の他の半分に対して反復を実行させて 、全曲線の両端部の深さが見出されることを保証し、従って前記ｍａｘＤｅｐｔ ｈが最も深い深さを含むことになる。 図１７および図１８に示された深さ発見アルゴリズムが、ベクトルとの適合が 最悪である各部分曲線の半分に対する反復を追跡するに過ぎないので、文字形状 レコーディングの動作を著しく早め、これにより深さ分析のため要求される計算 量が曲線の深さで指数的に増加することを防止する。 次に図９に戻って、ステップ４２２が完了した後、ステップ４２４がステップ ４２０により計算された近似化された線分を図１０に示された開いた輪郭ストラ クト３４９Ａの点アレイ３３９Ａへ挿入する。曲線上の点と輪郭の点アレイにお ける制御点とにより表わされるアウトライン線分の区切りが、受取られたアウト ライン線分の実際の区切りによるのではなく、横方向と縦方向の接線、変曲点、 フィルタされたコーナーおよび曲線とＣＳＲに対するＥｘｅｃＣｈａｒ（）呼出 しから受取られたアウトライン線分により規定される形状に見出された著しい線 との間の境界に依存することが判る。 新たに近似化されたアウトライン線分がいったん開いた輪郭３４９Ａに置かれ ると、ステップ４２６が、文字形状アレイからまだ近似化されかったかあるいは このような近似化されない線分の処理のため必要ではない線分の部分ではない全 ての点を削除する。このステップは、このような点が更なる用途がないので、メ モリを節減するためこのような削除を行う。 所与の文字−フォント形状の処理中に、ステップ３４６または３５８のいずれ かと、そのそれぞれのサブステップが、ＣＳＲに対する各ＥｘｅｃＣｈａｒ（） 呼出しごとに反復される。 ＣｓｒＭｏｖｅＴｏ（）に対する呼出しがＥｘｅｃＣｈａｒ（）から受取られ る以後の時間ごとに、これは、ＥｘｅｃＣｈａｒ（）により記述されつつある形 状における１つの輪郭あるいはアウトラインの記述の終りと、別のこのような輪 郭の初めか、あるいはこのような輪郭が更になければＥｘｅｃＣｈａｒ（）によ るこの形状の記述の完了をマークする次の文字に対する開始位置への移動かを表 示する。いずれの場合も、ＣｓｒＭｏｖｅＴｏ（）に対するこのような以後の呼 出しが受取られると、ステップ３５２が、開いた輪郭３４９Ａを完了してこれを 閉じ、ステップ３５４がその適正な場所において輪郭ツリーへ置く。 ステップ３５４は、これを下記のように階層的な輪郭ツリー３５６へ置く。 この輪郭ツリーが空であるならば、これは大域可変ｐＣｏｎｔｏｕｒＲｏｏｔ を新たな輪郭へ指示する。輪郭ツリーが空でなければ、最上レベルにおける輪郭 のリストを走査する。走査された各輪郭に対して、新たなものがこれを包囲する ならば、走査された輪郭をリストから除去して、これをｐＤａｕｇｈｔｅｒ４５ ２により指示された新たな輪郭の娘（ｄａｕｇｈｔｅｒ）リストに加える。この 新たな輪郭が走査された輪郭により包囲されるならば、走査プロセスを走査され た輪郭の子供で再開する。走査されつつあるリストの終りに達すると、新たな輪 郭をリストに加える。実際の輪郭挿入プロセスが類似（ｓｉｂｌｉｎｇ）リスト に対する一貫した順序を維持して、以下に述べる象形部が信頼できることを保証 する。この順序は、輪郭の境界ボックスであるＣｏｎｔｏｕｒＢＢｏｘにおける ｘｍｉｎ値に基く。つなぎ（ｔｉｅ）の場合は、相違が見出されるまで命令ｙｍ ｉｎ、ｘｍａｘ、あるいはｙｍａｘが用いられる。同じ境界ボックスを持つ異な る類似輪郭の場合はない。 図１０に示される事例では、登録された商標記号４５３における丸の外側のア ウトラインと関連する輪郭３４９Ｂは、輪郭ツリーの最初の、即ち最も高いレベ ルに最終的に置かれるが、これはこの全ての記号の他の輪郭を包囲するゆえであ る。前記丸の内側アウトラインと関連する輪郭３４９Ｃは、第２レベルの輪郭と なる。登録商標記号における「Ｒ」の外側アウトラインと関連する輪郭３４９Ｄ は、第３レベルの輪郭となる。また、「Ｒ」の内側アウトラインと関連する輪郭 ３４９Ｅは、第４レベルの輪郭となる。ある文字が１つのレベルの多くの輪郭を 有することを理解すべきである。例えば、形状「１／２」は全て第１のレベルの ３つの輪郭を持つが、形状「Ｂ」は第１のレベルの１つの輪郭と、前記第２のレ ベルにおけるものと独立する２つの輪郭とを持つことになる。 ＥｘｅｃＣｈａｒ（）が図９に示されるステップ４６０でＣｓｒＤｏＣｈａｒ （）へいったん戻ると、文字−フォント形状の各アウトラインは閉じられた輪郭 構造３４９に記録されねばならず、これら構造の各々はどれがどれを包囲するか を示す階層へ構成されねばならない。この時、ステップ３５０により、文字−フ ォント形状のエスケープメント（ｅｓｃａｐｅｍｅｎｔ）と関連するＥｘｅｃＣ ｈａｒ（）によって呼出された最後のＣｓｒＭｏｖｅＴｏ（）で生成された開い た輪郭が存在する。ステップ４６０は、記録されつつある形状に対するエスケー プメントを計算するためこの開いた輪郭における初期点の場所を保管し、開いた 輪郭を閉じる。 次いで、ステップ４６２が、輪郭ツリー３５６を２つのレベルのサブツリーへ 分ける。即ち、このステップは、奇数レベルの各輪郭とそのゼロ以上の娘（ｄａ ｕｇｈｔｅｒ）の輪郭とをサブツリー３５５へ分類する。例えば、図１０におい 前記丸の内側輪郭を表わす輪郭３４９Ｃとが１つのサブツリーへ分類され、前記 コード「Ｒ」の外側と内側のアウトラインを表わす輪郭３４９Ｄおよび３４９Ｅ は別のサブツリーへ分類される。これらの２つのレベルのサブツリーがそれぞれ 象形部要素、即ち、連続しない中ベタの形状と対応することになる。 輪郭ツリーがいったん象形部要素と対応するサブツリーへ分けられると、ステ ップ４６４がこのような各象形部要素に対してステップ４６６、４６８、４７０ 、４７２、４７４、４７６および４７８を実行する。 ステップ４６６は、輪郭の方向を標準化する。即ち、このステップは、各象形 部要素における最上レベル即ち外側の輪郭における一連の外側の線分が反時計方 向を持つかどうか、またこれがこのような反時計方向を持つ線分の順序を逆にし ないかどうかを知るため調べる。同様に、このステップは、象形部の第２レベル 即ち内側の輪郭の線分が時計方向を持つかどうか、またこれがこれら線分にこの 方向をとるように指令しないかどうかを知るため調べる。これは、全ての象形部 要素の内外の輪郭がＣＳＲへ送られた方向の如何に拘わらず、これら輪郭がそれ ぞれ同じ方向を持つという利点を有する。 ステップ４６８は、各輪郭に対する標準的な開始点を取上げる。各輪郭が閉じ ているので、この開始点は任意である。しかし、象形部の一致を容易にしかつ再 生性能を最適化するために、各輪郭における開始点は少数の簡単な規則に基いて 拾われる。外側輪郭に対しては、開始点は輪郭における最も低い点となるように 選択される。幾つかの等しく低い点があるならば、最も右側の点が選択される。 内側の輪郭に対しては、開始点は輪郭において最も高い点となるように選択され る。幾つかの等しく高い点があるならば、最も右側の点が選択される。あり得る 両方の開始点の指標は既に、文字の形状処理中に輪郭データ構造にセットされて いる。従って、適切な点の取上げは、単に輪郭の所望の方向に基いて２つの指標 の１つを取上げる場合となる。 ステップ４７０は、縁部と筆使いのリストを構築する。縁部リストは、横方向 と縦方向の接戦を含む形状における任意の顕著性の全ての横方向と縦方向の縁部 のリストである。筆使いは、形状における所与の横方向および縦方向の特徴の対 向側を表わすこのような縁部の対である。これらの値は、ヒント呈示において用 いられる。 ステップ４７２は、図１０に示されるように、象形部要素に対する象形部レコ ード４８２と象形部プログラム・ストリンク（ＧＰＳ）４８４とを生成する。象 形部プログラム・ストリングは、各象形部要素の関連する輪郭における一連の外 側線分を、これら一連の線分が象形部要素の関連するサブツリー３５５において これら輪郭の順序でステップ４６６および４６８において標準化された後に表わ す。形状の記述がこの形状自体により委託されない象形部の形状に対するＥｘｅ ｃＣｈａｒ（）から受取られる一連のアウトライン線分の任意の特質とは無関係 であることが判る。このＧＰＳは、ＧＰＳメモリに一連のＧＰＳの終りへ加えら れる。このメモリにおけるその場所およびサイズは、象形部レコードにおいてｇ ｌｙｐｈＰｒｏｇｒａｍＳｔｒｉｎｇＯｆｆｓｅｔ４５４およびｇｌｙｐｈＰｒ ｏｇｒａｍＳｔｒｉｎｇＳｉｚｅ４５２によってそれぞれ示される。この象形部 レコードもまた、象形部のシグネチャ（特徴点）４５６を計算する。このシグネ チャは、象形部を一義的に識別する高い確率を有するコンパクトなバイト・スト リングである。この識別は、位置およびスケール・ファクタとは独立的である。 これは、象形部の輪郭数、ステップ４７０において計算された横方向と縦方向の 縁部の数、計算された最も右側の筆使いの相対的サイズ、最も右側の筆使いの左 縁部の相対的位置、最上位の筆使いの相対的サイズ、最上位の筆使いの低い縁部 の相対的位置、外側輪郭における外側コーナーの数、外側輪郭における内側コー ナーの数、内側輪郭における外側コーナーの数、および内側輪郭における内側コ ーナーの数を含んでいる。このシグネチャにおいて、位置およびサイズは全て象 形部の境界ボックスと関連し、その結果同じ形状であるが異なるサイズの象形部 が同じシグネチャを持つことになる。 新たな象形部レコード４８２とその関連する新たなＧＰＳ４８４Ａがいったん 生成されると、ステップ４７４が、図１９に示されるように、前に記録された象 形部形状に対して作られた全ての象形部レコード４８２の２進ツリー４８１を探 索する。このステップは、同じシグネチャを持つ象形部レコードについてこのツ リーを探索する。このツリーは、各象形部レコードのシグネチャにおける総合バ イトからなる数値ＮＩＹＯＲＩ２進ツリーへ構成される。これは、一致する象形 部形状についての迅速な探索を容易にするために行われる。ツリーにおける各象 形部レコードでは、ポインタｐＮｅｘｔＤｏｗｎ４８２が、その象形部レコード がより低い値を持つシグネチャを持つツリーの下方向の分岐を指示する。ポイン タｐＮｅｘｔＵｐ４８４が、対応する象形部値がより高いシグネチャ値を持つ下 方向分岐を指示する。また、ポインタｐＮｅｘｔＥｑｕａｌ４８６は、同じシグ ネチャ値を持つものがあれば象形部レコードを指示する。等しいシグネチャ値を 持つ象形部レコード４８２Ｃのグループが、図１９に示される。 図１９に示されるように、探索が新たな象形部レコード４８２Ａと同じシグネ チャを持つ象形部レコード４８２Ｂを見出すならば、ステップ４７６がステップ ４８８および４９０を実行する。ステップ４８８は、新たな象形部レコード４８ ２Ａと同じシグネチャを持つ象形部レコード４８２Ｂにより指示されるＧＰＳ４ ８４Ｂにおける一連の点を、新たな象形部レコードの関連するＧＰＳ４８４Ａに おける点と比較する。この突合わせが行われる前に、２つの象形部形状の境界ボ ックスが同じサイズに正規化され、その結果この突合わせがスケール独立的にな る。 を可能にし、「１／２」における「１」の形状を「１」における形状と一致する ことを可能にする。図示された事例において、象形部レコード４８２Ｂと関連す るＧＰＳ４８４Ｂにおける点が新たな象形部レコードＧＰＳ４８４Ａの点と一致 しないものと仮定される。 新たな象形部レコード４８２Ａのシグネチャとそのシグネチャが一致する象形 部ツリーにおけるグループの類似の象形部レコードが存在するならば、新たな象 形部レコードの関連するＧＰＳ４８４Ａがこれら類似の象形部レコードの各々の ＧＰＳに対して比較される。図１９の事例においては、このことは、ＧＰＳ４８ ４ＡもまたＧＰＳレコード４８２Ｄと関連するＧＰＳ４８４Ｄに対して比較され ることを意味する。この事例においては、これら２つのＧＰＳが一致するものと 仮定される。 このような一致を迅速にする能力は、輪郭の順序、輪郭の方向、および各ＧＰ Ｓにおける輪郭の開始点が前記象形部の形状がＥｘｅｃＣｈａｒ（）によってＣ ＳＰへ送られた特定の方法とは独立的に標準化されるという事実によって非常に 容易にされる。このことは、異なる文字、異なるフォントあるいは更に異なるフ ォント記述言語のどれから受取られたかに従って、同じ形状を持つ象形部がほと んど常に正確に同じＧＰＳを持つことを意味し、スケーリングおよび丸めの誤差 を可能にし、これにより迅速に突合わせることができる。 図１９におけるＧＰＳ４８４Ａおよび４８４Ｄの場合のように、丸め誤差を許 容する正確な一致が見出されるならば、ステップ４９０が新たな象形部レコード のＧＰＳ４８４Ａを通常削除し、新たな象形部レコード４８２Ａにおけるｇｌｙ ｐｈＰｒｏｇｒａｍＳｔｒｉｎｇＯｆｆｓｅｔおよびｇｌｙｐｈＰｒｏｇｒａｍ ＳｔｒｉｎｇＳｉｚｅの値を一致するＧＰＳ４８４Ｄに指示する。新たな象形部 レコードＧＰＳが前に記録された一致ＧＰＳとは異なるサイズを持つならば、前 に記録された一致ＧＰＳに記述された象形部を適正なサイズへ変換するスケーリ ング情報は、新たな象形部レコードと関連させられる。新たな象形部４８４Ａに 記述されたサイズが前に記録された一致ＧＰＳ４８４Ｄに記述されたものより充 分に大きければ、これらは一致しないものとして取扱われ、象形部形状の望まし くないほど低い解像度記述が新たな象形部レコードに対して用いられることを阻 止する。 一致する象形部形状に対するテストがいったん完了すると、象形部のＧＰＳが ツリーにおける前の何物にも一致しなければ、ステップ４７８が、新たな象形部 レコード４８２Ａを適切な場所に象形部レコードの２進ツリー４８１へ挿入する 。 象形部レコード・ツリーが、任意の形状が共通にＧＰＳへの参照により規定さ れ得るされるか否かを見出すためその時処理されつつある文字−フォント形状の 全ての象形部について探索された後、ステップ４８０が、文字のＧＰＳに対して 処理されつつある文字−フォント形状に対する文字レコード３３０の図８に示さ れるｇｌｙｐｈＰｒｏｇｒａｍＳｔｒｉｎｇＯｆｆｓｅｔ４９０およびｇｌｙｐ ｈＰｒｏｇｒａｍＳｔｒｉｎｇＳｉｚｅ４９２を指示する。文字レコードの関連 する形状が１つ以上の他のＧＰＳにより規定される象形部のスケーリング、変位 あるいは組合わせによって形成されるならば、文字レコードにより指示されるＧ ＰＳが図８に示されるＧＰＳ４８４Ｄの如き複合ＧＰＳとなる。このような各複 合ＧＰＳがこのような他のＧＰＳに対する１つ以上のポインタを、文字レコード の関連する形状におけるこのような他の各ＧＰＳの関連する象形部のサイズおよ び場所を規定するのに必要なスケーリングおよび変位情報と共に含む。 これがいったん行われると、ステップ４９６は、処理されつつある文字−フォ ント形状の境界ボックスのｘまたはｙの最大または最小がフォントにより前に処 理された文字−フォント形状のこのようなｘまたはｙの最大または最小より更に 極値であるならば、その時の物理的フォントの境界ボックスのｘまたはｙの最大 または最小を更新する。 この時、ＣｓｒＤｏＣｈａｒ（）がその時呼出された文字−フォント形状の処 理が完了し、ＣｓｒＤｏＣｈａｒ（）が戻る。 次に図６に戻り、ステップ２３６におけるＣｓｒＤｏＣｈａｒ（）１５２に対 する呼出しが完了すると、ステップ２３８が、移植可能文書のテキスト１１８に おける文字に対するコード２１９Ａを置き、プログラムはループ２１４の最上部 へ進んで入力テキストか受取る次のコードを処理する。 次にテキストから受取ったコードが位置コード２２１であるならば、ステップ ２２０におけるテストが満たされ、このステップが出力テキストにおける対応す る位置決めコード２２１Ａを置き、プログラムはループ２１４の最上部へ進む。 入力テストは、図１におけるビデオ・モニター１０６に示されたロゴ２４２の 如き文字でない形状の形を表わす記述即ちコード２２３を含み得る。図６に示さ れる実施例においては、これらの記述はフォントばかりでなくページのレイアウ トおよび文字でない形状も記述する言語であるポストスクリプト（ＰｏｓｔＳｃ ｒｉｐｔ）ページ記述言語でコード化される。 文字でない形状コード２２３が入力テキストで受取られると、ステップ２２２ におけるテストが満たされ、このステップは、フォント・コードがフォントの「 形状」について受取られたかのように、またこれが前記コード２２３により記述 された文字でない形状に対する一義的な文字コードを割当てるかのように働く。 「形状」に対するｐｆｏｎｔＩＤ指示ステップ２２２は、ＦｏｎｔＡｔｔｒｉｂ ｕｔｅｓで標準値を置き、ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）を呼出し、移植 可能文書のテキストにおける「形状」フォントに対して返されたＦｏｎｔＣｏｄ ｅを置く。次いで、ステップ２２２が形状の一義的なｃｈａｒＣｏｄｅに対する ＣｓｒＤｏＣｈａｒ（）を呼出して、その形状のフォント記述を構成し、移植可 能文書のテキストにおける形状の一義的ｃｈａｒＣｏｄｅ２１９Ａを置く。 ｐＦｏｎｔＩＤが「形状」を指示するステップ２２２の動作中、ＧｅｔＦｏｎ ｔＩｎｆｏ（）が、形状がＣＳＲに対して記述されるアウトライン解像度でＣｓ ｒＳｅｔＦｏｎｔＳｐｅｃｓ（）を与え、ＧｅｔＣｈａｒＩＤ（）がゼロを返し てヒント呈示のため使用される文字が「形状」フォントには使用できないことを 表示し、ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）にＥｘｅｃＣｈａｒを呼出さない ようにさせ、ＣｓｒＤｏＣｈａｒ（）がＥｘｅｃＣｈａｒを呼出す時、これがポ ストスクリプトの形状記述により規定される移動、線および曲線を返す。 ループ２１４がいったん入力テキスト１１６における全てのコードを処理する と、ステップ２４４がＣＳＲのＣｓｒＷｒｉｔｅＲｅｓｏｕｒｃｅ関数１５７を 呼出す。ＣｓｒｗｒｉｔｅＲｅｓｏｕｒｃｅは、このような書込みが使用される オペレーティング・システムに依存するので、このデータを実際に書込むためＷ ｒｉｔｅＲｅｓｏｕｒｃｅＤａｔａ（）を呼出す。ＣｓｒＷｒｉｔｅＲｅｓｏｕ ｒｃｅは、物理的フォントレコードに含まれるデータ、およびこれらの関連する 論理的フォントと文字レコード、および象形部プログラム・ストリングに含まれ るデータを圧縮させて、主要素が図２０に示される移植可能な文書資源（ＰＦＲ ）１２６へ記録させる。同図から判るように、ＰＦＲは、論理的フォント・ディ レクトリ５００、１つ以上の論理的フォント・レコード５０２、１つ以上の物理 的フォント・レコード５０４、１つ以上の簡単な象形部プログラム・ストリング 、およびゼロ以上の複合象形部プログラム・ストリング５０８、即ち、１つ以上 の他のＧＰＳを参照して規定される図８に示されるＧＰＳ４８４Ｄの如きＧＰＳ を含んでいる。論理的フォント・ディレクトリ５００は、移植可能文書に含まれ るｆｏｎｔＣｏｄｅ２７１Ａを、ＰＲＦにおける前記ｆｏｎｔＣｏｄｅの対応す る論理的フォント・レコード５０２のアドレスおよびサイズへ変換されるように 変換する索引テーブルを含む。各論理的フォント・レコード５０２は、とりわけ 論理的フォント、およびＰＦＲにおけるその関連する物理的フォント・レコード ５０４のアドレスおよびサイズを含む。このような各物理的フォント・レコード は１つ以上の文字レコード５１０を含み、その各々が、その形状を一連の移動、 線および曲線として実際に記述する単純あるいは複合象形部プログラミング・ス トリング５０６または５０８のアドレスおよびサイズを含む。 ＣｓｒＷｒｉｔｅＲｅｓｏｕｒｃｅに対する呼出しがいったんＰＦＲを書込む と、ステップ２４６がＣｓｒＣｌｏｓｅを呼出してＣＳＲを閉じ、ルーチン２０ ４の実行が完了する。 図６に示された入力テキスト１１６の図は、図１におけるビデオ・モニター１ ０６上に示されるフォント化されたテキストの初期部分の概略図である。図６に 示された移植可能文書１０４の図は、同じフォント化テキストを表わすテキスト １１８の概略図である。これら２つのテキストを比較することにより判るように 、入力テキストにおける各フォント・ネーム２１７、各文字コード２１９、およ び各位置コード２２１は、それぞれ移植可能文書における対応するｆｏｎｔＣｏ ｄｅ２１７Ａ、ｃｈａｒＣｏｄｅ２１９Ａ、あるいは位置コード２２１Ａを有す る。 更に、入力テキストへコード化された文字でない各形状２２３は、移植可能文書 におけるｆｏｎｔＣｏｄｅ２１７ＡとｃｈａｒＣｏｄｅ２１９Ａとを有する。 図２１は、図１における第２のコンピュータ１０８に示された関数要素の更に やや詳細な概略図を提示する。この図は、ページ・ビルダー１３４およびモジュ ラー文字形状プレイヤー１３６がどのように相互に作用して移植可能文書１０４ に含まれるフォント化テキストの視覚的イメージを描写するかを示している。こ れは、第２のコンピュータが第１のコンピュータに関して先に述べたフォント・ インタプリタ１２０とフォント資源１２２と関数において類似するフォント・イ ンタプリタ１２０Ａとフォント資源１２２Ａを含む一実施例を示す。 ページ・ビルダーは、図５に示された主プログラム２５０とコールバック関数 １９０〜２０２とを含み、必要でない前記コールバック関数は図２１には示され ない。 ページ・ビルダーの主プログラムに対して示された最初のステップはステップ ２５２である。これは文字形状プレイヤ即ちＣＳＰ、ＣｓｐＯｐｅｎ（）関数１ ７１を呼出す。これは、ＣＳＰデータ構造を開いて初期設定する。 ＣｓｐＯｐｅｎ（）に対する呼出しがいったん戻ると、ステップ２５４が、文 書に関するイメージの場所およびそのサイズ、スケールおよび文書に関する場所 を含む、移植可能文書に対して生成されるべきイメージの関係を決定する。この 呼出しはこれらを用いて、イメージに対するｏｕｔｐｕｔＭａｔｒｉｘおよびｏ ｕｔｐｕｔＢｏｘを計算する。ｏｕｔｐｕｔＭａｔｒｉｘは、移植可能文書から 計算された文書座標がどのようにオフセットされ、スケールされ、あるいは生成 されるイメージの座標に関して傾斜させられるかを記述する。ｏｕｔｐｕｔＢｏ ｘは、文書の座標におけるどの場所が前記イメージに適合しないか、またこれに よりＣＳＰにより生成されることを必要とないかを規定する。 ステップ２５６は、ビット・マップ化出力あるいはアウトライン出力が要求さ れるか否かを知るためにテストする。ビット・マップ化出力は、大半のビデオ・ ディスプレイおよびレーザ・プリンタに対して使用される。これは、ピクセルの アレイからなるイメージで文字形状を表わす。アウトライン出力は、プロッタで 使用され、またフォントの生成に用いることができる。これは、イメージを一連 の移動、線あるいは曲線として表わす。 ステップ２５６がビット・マップ化出力が要求されると判定するならば、ステ ップ２５８および２６０が実行される。ステップ２５８は、ＣＳＰのＣｓｐＩｎ ｉｔＢｉｔｍａｐＣａｃｈｅ（）関数１７０を呼出す。これは、ＣｓｐＤｏＣｈ ａｒ（）に対する呼出しにより生成されたできるだけ多くの文字−フォント形状 のコピーを格納するビット・マップ・キャッシュを初期設定して、所与の文字− フォントの組合わせに対する反復される呼出しがＣｓｐＤｏＣｈａｒ（）に対し て行われる時、この形状の実際のビット・マップが通常はこれら呼出しの最初の ものに対してのみ生成されねばならないようにし、かつその後の呼出しと同時に ビット・マップが単にビット・マップ・キャッシュから受取り得るようにする。 ＣｓｐＩｎｉｔＢｉｔｍａｐＣａｃｈｅ（）に対する呼出しが返った後に、ステ ップ２６０がＣｓｐＳｅｔＯｕｔｐｕｔＳｐｅｃｓ（）関数１７５を呼出して、 ビット・マップ化されたイメージを描写するようにＣＳＰをセットする。ステッ プ２５６がアウトライン出力が用いられることを決定するならば、ステップ２６ ２がｃｓｐＳｅｔＯｕｔｐｕｔＳｐｅｃｓ（）を呼出して、アウトラインを生成 するようにＣＳＰをセットする。 いずれの場合も、ＣｓｐＳｅｔＯｕｔｐｕｔＳｐｅｃｓ（）の呼出しもまた、 ページ・ビルダーのそれを反映するようにＣＳＰのｏｕｔｐｕｔＭａｔｒｉｘと ｏｕｔｐｕｔＢｏｘデータ構造をセットする。ＣＳＰのｏｕｔｐｕｔＭａｔｒｉ ｘが、ＣＳＰにより生成される形状の座標がこれら形状に対する新たなフォント 記述に含まれるものに関してどのようにスケールされて回転させられるべきかを 決定する。ＣＳＰのｏｕｔｐｕｔＢｏｘは、明らかにＣＳＰに生成されるイメー ジの外側にある形状情報を描写しないようにする。 ステップ２６０または２６２のいずれかのＣｓｐＳｅｔＯｕｔｐｕｔＳｐｅｃ ｓ（）に対する呼出しいったん返ると、生成されるイメージにおける情報と対応 する全てのこのようなコードが処理されるまで、ステップ２６４が移植可能文書 におけるテキスト１８におけるコードを経て順序付けするループを実行する。こ のループは、ステップ２６６、２６８および２７０からなっている。 テキスト１１８から処理されつつあるその時コードがｆｏｎｔＣｏｄｅ２１７ Ａであるならば、ステップ２６６はｓｔｐ２７４、２７６および２７８を実行さ せる。 ステップ２７４は、ＣＳＰのＣｓｐＧｅｔＦｏｎｔＳｐｅｃｓ（）関数１７３ を呼出して、その時のｆｏｎｔＣｏｄｅにより表わされるフォントのフォント・ ネームを取得する。これがいったんなされると、ステップ２７６が、第２のコン ピュータのフォント・インタプリタ１２０Ａおよびフォント資源１２２Ａがこの フォントで文字のイメージを描写できるかどうかを知るため検査する。これは、 フォント・インタプリタ１０２Ａが指名されたフォントに対して用いられるフォ ント記述言語を解釈できることと、前記の指名されたフォントに対する予め規定 されたフォント記述がフォント資源１２２Ａに駐在することの両方を要求する。 このテストが満たされるならば、またフォント・インタプリタによってフォント が描写できるならば、ステップ２７６はＯｒｉｇＦｏｎｔフラッグをセットして 、指名されたフォントの予め規定されたあるいは元のフォントが使用できること を表示する。フォント・インタプリタが指名されたフォントを描写できなければ 、ステップ２７８は、ＯｒｉｇＦｏｎｔフラッグをクリヤし、ｆｏｎｔＣｏｄｅ に対するＣＳＰのＣｓｐＳｅｔＦｏｎｔ（）関数１７６を呼出す。これは、ｆｏ ｎｔＣｏｄｅをＣＳＰのその時アクティブな論理的フォントとしてセットし、こ れによりその関連する物理的フォントをＣＳＰのその時アクティブな物理的フォ ントとしてセットする。 テキスト１１８から処理されるその時のコードが位置コード２２１Ａであるな らば、ステップ２６８が新しいその時の文書位置を計算して、描写される次の形 状がイメージ形成されつつあるその時の文書と関連して置かれるべき場所を表示 する。 テキスト１１８から処理されつつあるその時のコードがｃｈａｒＣｏｄｅ２１ ９Ａであるならば、ステップ２７０は、サブセット２８０および２８２を実行さ せる。サブセット２８０は、ＯｒｉｇＦｏｎｔフラッグがセットされるかどうか を知るためテストし、もしそうであれば、このサブセットはコンピュータのフォ ント・インタプリタを呼出してその時のｃｈａｒＣｏｄｅの形状を取得して、現 装置にこのテキスト、あるいはイメージ、座標を出力し、次いでこの文字のイメ ージと関連するエスケープメント（通常は、幅）を反映するようにその時の文書 およびイメージ座標を更新する。しかし、ＯｒｉｇＦｏｎｔフラッグがセットさ れなければ、サブセット２８２のテストが満たされ、このステップが文字コード と現装置座標に対するＣＳＰのＣｓｐＤｏＣｈａｒ（）関数１７８を呼出す。Ｃ ｓｐＤｏＣｈａｒ（）は、現装置位置に文字のビット・マップ・イメージとアウ トライン記述を生成し、ページ・ビルダーの現装置位置をこの文字のエスケープ メントにより更新する。ビット・マップ出力が出力されるならば、これはこのイ メージをページ・ビルダーのＳｅｔＢｉｔｍａｐ（）コールバック関数１９３を 呼出すことにより生成する。ＣｓｐＤｏＣｈａｒ（）は、この関数を文字のビッ ト・マップ・パターンに対するポインタ、このパターンのサイズおよび現装置の 座標と共に呼出す。ＳｅｔＢｉｔｍａｐ（）は、このパターンを取得し、実際に これをイメージ・バッファに挿入する。アウトライン出力がセットされるならば 、ＣｓｐＤｏＣｈａｒ（）がページ・ビルダーのアウトライン出力コールバック 関数を呼出す。これらの関数はＶｓｔｅｍ（）１９７およびＨｓｔｅｍ（）１９ ８を含み、これらの関数が現在のフォントの標準的な縦方向および横方向の筆使 い幅についてのヒント呈示情報を受取る。これらはまた、移動、線曲線に対する 命令とＣｓｐＤｏＣｈａｒ（）からのアウトラインで第１の点まで線を引く指令 とを受取り、かつ実際にこれら命令を用いてイメージ・バッファに形状を描画す るＭｏｖｅｔｏ（）、ＬｉｎｅＴｏ（）、ＣｕｒｖｅＴｏ（）およびＣｌｏｓｅ Ｐａｔｈ（）関数をも含む。 ループ２６４がいったん生成されるイメージと関連させられるテキスト１１８ における全てのコードを処理すると、これはこのイメージを生成することになる 。この時、このループは、ステップ２８４におけるように、ＣＳＰのＣｓｐＤｏ Ｃｈａｒ（）関数１７８を呼出すことにより、ページ・ビルダー・プログラムま たはサブルーチンから抜けることができる。これは、全てのプレイヤーのデータ およびメモリ構造を閉じることになる。しかし、ページ・ビルダーが文書を対話 的に見るために使用される実施例においては、プログラムは、ステップ２５４ま で戻るようループし、提示されるべきイメージの場所、サイズ、スケールあるい は回転を変更する新たな指令を待機し、これらのパラメータのどれかの変更を表 示 する入力がユーザから受取られると直ちに新たなイメージを生成する。 以上の記述および図面が単に説明し例示するために与えられること、および請 求の範囲の解釈が限定される場合を除いて、本発明がこれに限定されるものでな いことを理解すべきである。本文の開示を知る当業者は、本発明の範囲から逸脱 することなくその修正および変更を行うことができよう。 例えば、移植可能文書を生成する本発明のある実施例では、文書形成プログラ ムが新たなフォント記述を、移植可能文書に１つ以上の文字が置かれた任意のフ ォントにおける全ての文字に対する移植可能なフォント資源に挿入する能力を有 することを理解すべきである。このプログラムは、ＣｓｒＳｅｔＦｏｎｔＳｐｅ ｃｓ（）に対する呼出しがＧｅｔＦｏｎｔＩｎｆｏ（）およびＧｅｔＦｏｎｔＩ ｄ（）を呼出して、ＣｓｒＳｅｔＦｏｎｔＳｐｅｃｓ（）が呼出されつつあるフ ォントが新たな物理的フォントであることを示す時常にこれを文字セットにおけ る各文字に対してＣｓｐＤｏＣｈａｒ（）を呼出すことにより行うことができる 。これにより、移植可能文書を受取る者がその文書に含まれる全てのフォントで 文書を編集することを可能にする。 また、本発明を多くの異なるタイプのアプリケーションで使用できることも理 解すべきである。 例えば、本発明は、フォント化された文書を所与のプリンタにより適正に印刷 できることを保証する上でプリンタ・コントローラおよびプリンタ・ドライバで 非常に有効であり得る。プリンタのコントローラまたはこれを直接駆動するコン ピュータが先に述べた汎用タイプのページ・ビルダーと文字形状プレイヤを持つ 場合、プリンタがこれに図１に示された文書１０４の如き移植可能文書の一部と して送られる如何なるフォント・セットでも印刷が可能である。ネットワーク上 の全てのプリンタがこのような能力を持つ場合、任意のこのようなプリンタへ移 植可能文書を送ることができ、かつこれが全ての所望のフォント形状で正しく印 刷されることを保証することができる。 本発明は、プレゼンテーション・ソフトウエアでの使用に非常に有効であり得 る。ページ・ビルダー送って文字形状プレイヤを含むプレゼンテーション・ソフ トウエアは、植込まれた移植可能フォント資源を用いて移植可能文書として生成 される任意のプレゼンテーションにおいてフォントを忠実に再現することができ る。このため、フォントがコンピュータの関連フォント資源に存在するかしない かについて心配することなく、このようなプレゼンテーションをこのようなプレ ゼンテーション・ソフトウエアを備えるコンピュータにおいて使用に供する。 本発明は、Ｅメール、グループウエア、コンピュータ掲示板、オンライン・サ ービス、およびいわゆる情報ハイウエーの如きネットワーク化されたアプリケー ションにおいて非常に有効であり得る。図３に示された如きシステムを用いるこ とにより、フォント化されたテキストおよび移植可能なフォント資源を含む媒体 をネットワーク上に送出して、コンピュータがどんなフォントをそのフォント資 源して有するかについて心配することなく、ページ・ビルダーおよび文字形状プ レイヤを含む受信側コンピュータにより正確に描写することを可能にする。この ことは、フォント化されたテキストがそれぞれフォント資源のあり得る異なる組 合わせによる数千あるいは数百万の異なるコンピュータから受取られた後視認さ れる用途において特に重要である。 対話型ネットワーク化アプリケーションにおいては、移植可能文書を繰返し生 成することができる。即ち、連続的な線またはスクリーンが送信されるごとに、 その文字に対して要求されるどんな新たなフォント記述でも共に送ることができ る。 本発明は、フォント資源が出版される情報に含まれる各フォントを含むかどう か心配することなく、電子的に出版される文書において使用される任意の所要フ ォントを任意のコンピュータ上に視覚的に正確に描写できることを保証するゆえ に、ＣＤ−ＲＯＭの出版の如き電子出版において非常に有効であり得る。 ネットワーク化された電子出版その他の用途においては、送信を受取る各コン ピュータが再生が可能であることを保証するため、ページ・ビルダーおよび文字 形状プレイヤに対する実際のコードを移植可能文書と共に送ることができる。 本発明は、フォント・セットを生成してこれを編集するための用途において有 効であり得る。例えば、ある実施例では、文字形状プレイヤが予め規定されたフ ォント記述を予め規定されたフォント記述における形状情報からのみ得られる新 たなフォント記述に変換するアプリケーションの一部として使用される。このよ う な用途においては、文字形状プレイヤに類似するソフトウエアがコンピュータの フォント・インタプリタの１つとして組込まれるように設計される。 本発明はまた、マルチメディア用途において非常に有効であり得る。これは、 このようなマルチメディアにおけるフォント化されたテキストを、英数字記号に よりコンパクトに表わすこと、そして任意のコンピュータにより迅速かつ正確に 再現することを可能にする。このような用途において、また描画アプリケーショ ンおよびデスクトップ・パブリッシング・アプリケーションにおいては、本発明 はカラー、３次元、透明その他の図形的効果を取扱うように修正することができ る。 当業者には理解されるように、ソフトウエアで実施されるものとして先に述べ た多くの機能をハードウエアで実施することも可能である。同様に、先に述べた 特定の機能およびモジュールへの機能性の特定の分割は全く任意であり、本発明 はこのような分割に限定されるものではない。例えば、本発明のある実施例では 、文書ビルダーおよび文字形状プレイヤは２つではなく１つのソフトウエア・モ ジュールと見なすことができる。他の実施例においては、文書ビルダーは別個の ソフトウエア・モジュールではなく、むしろワード・プロセッサ、デスクトップ ・パブリッシングあるいはプレゼンテーション・プログラムのようなより大きな ホストのアプリケーションの一部となる。他の実施例においては、文字形状レコ ーダおよびプレイヤーは、移植可能文書の生成、一覧および編集の全てを行うア プリケーションにおいて使用されるように設計されたより大きな１つのモジュー ルの一部であり得る。 本発明の文字形状レコーダの他の実施例においては、予め規定されたフォント 記述において規定された形状から新たなフォント記述を抽出するために用いられ る規則が異なり得ることを理解すべきである。例えば、ある点では、１本の曲線 のみで得られる適合は要求されるほど正確でないならば、コーナー、接線、反曲 点、あるいはＸまたはＹの極値の如き記述が独立的な点としてマークされた点間 の文字形状アレイにおけるアウトライン線分の所与の部分が１本の曲線の代わり に多数の曲線で近似化が可能である。他の場合、例えば異なる標準的な開始点ま たは輪郭方向を新たなフォント記述として用いることが可能であり、あるいは異 なるタイプの記述を湾曲したアウトライン線分に対して用いることも可能である 。 先に詳細に述べた本発明の実施例は、ポストスクリプト、トルータイプおよび スピード言語で書かれた予め規定されたフォント記述を受取ることが可能である 。本発明の他の実施例では、インテリフォントの如き他のフォント記述、あるい は将来開発される新規なフォント記述言語で書かれた予め規定されたフォント記 述を受取るように文書ビルダーまたは文字形状レコーダも設計可能であることを 理解すべきである。 例えば、インテリフォント言語は、円弧として曲線を記述する。これは、文書 ビルダーのＥｘｅｃＣｈａｒ（）関数に、これがインテリフォントのフォント・ インタプリタから受取る各円弧のアウトライン線分を対応するベジェ曲線へ変換 させることにより実施可能である。これは、ＣｓｒＡｒｃＴｏ（）関数にこのよ うな円弧を受取らせて、これをベジェ曲線へ変換させるように文字形状レコーダ 自体を修正することにより可能である。将来においてアウトライン線分を他の方 法で規定する他のフォント記述言語が開発されるならば、文字形状レコーダまた はその関連するホスト・ソフトウエアをこのような新規な記述技術を許容するよ うに変更することが可能である。 先に述べたページ・ビルダーの実施例において、このページ・ビルダーは、そ のコンピュータのプォント・インタプリタおよびフォント共振回路が所与のフォ ントを描写できるかどうかを知るためテストし、またもしそうであれば、このペ ージ・ビルダーはフォント・インタプリタによってフォントを描写させる。他の 実施例においては、ページ・ビルダーは、文字形状プレイヤを用いて移植可能文 書における全ての文字を描写する。 先に述べた本発明の実施例においては、フォント化されたテキストが対応する 出力テキストと移植可能なフォント資源からなる１つの移植可能文書へ変換され た。しかし、ある実施例においては、出力テキストおよび移植可能フォント資源 は別のファイルに置くことができ、あるいはおそらくは別の記憶場所に格納する こともできる。 これらの事例が示すように、本発明は、多くの可能な実施例を有し、その範囲 は本文に述べた詳細な記述に限定されるものはなく、むしろ請求の範囲によって 最善に規定される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ， ＵＡ，ＵＧ，ＵＺ，ＶＮ 【要約の続き】 （１０２Ａ、１０２Ｂ）上か、あるいは別のコンピュー タ（１０８Ａ、１０８Ｂ）上に描写することができる。

Claims (1)

1. 【特許請求の範囲】 １．それぞれ識別された予め規定されたフォントを有する複数の文字を受取るス テップと、 このように受取られた文字と予め規定されたフォントとの各組合わせごとに、 前記文字の関連する予め規定されたフォントにおける文字−フォント形状を記述 する予め規定されたフォント記述をアクセスするステップと、 アクセスされた各々の予め規定されたフォント記述により規定される文字−フ ォント形状から、関連する文字を識別して関連する文字−フォント形状を一連の アウトライン線分として記述する新たなフォント記述を生成するステップと を含むコンピュータ化された方法。 ２．複数の文字を受取る前記ステップが、それぞれ識別された予め規定されたフ ォントを有する一連の前記文字からなる入力テキストを受取り、 出力テキストを生成するステップを更に含み、前記出力テキストが 前記入力テキストのそれと対応する一連の文字と、 前記入力テキストと関連する各文字−フォント形状に対して生成される新た なフォント記述と、 どの新たなフォント記述が前記出力テキストにおける各文字の文字−フォン ト形状を表わすかの表示とを含む請求項１記載のコンピュータ化方法。 ３．前記出力テキストを取外し自在な大容量記憶媒体に書込むステップを更に含 む請求項２記載のコンピュータ化方法。 ４．前記出力テキストを遠隔ユーザに対してオンラインで利用可能にするステッ プを更に含む請求項２または３のいずれか１つに記載のコンピュータ化方法。 ５．前記出力テキストの視覚的表示を描写するステップを更に含み、該ステップ が、 前記視覚的表示に含まれるべき前記出力テキストにおける各文字と関連する新 たなフォント記述を識別するステップと、 識別される新たな各フォント記述を対応する文字−フォント形状に解釈するス テップと、 前記出力テキストの一連の文字における前の文字と関連する場所に隣接する前 記視覚的表示における場所に解釈された各文字−フォント形状を描写するステッ プとを含む請求項２ないし４のいずれか１つに記載のコンピュータ化方法。 ６．入力テキストを受取り、予め規定されたフォント記述をアクセスし、新たな フォント記述を生成し、出力テキストを生成する前記ステップが、第１のコンピ ュータにおいて実行され、 前記出力テキストの視覚的表示を描写する前記ステップが、第２のコンピュー タにおいて実行され、 前記第１のコンピュータにより生成された出力テキストを前記第２のコンピュ ータへ転送するステップを更に含む請求項５記載のコンピュータ化方法。 ７．前記出力テキストを転送する前記ステップが、コンピュータ・ネットワーク に前記出力テキストを表わすデータ信号を転送することを含む請求項６記載のコ ンピュータ化方法。 ８．前記描写ステップが、前記視覚的表示の印刷されたイメージを生成すること を含む請求項５ないし７のいずれか１つに記載のコンピュータ化方法。 ９．前記受取られた複数の文字の異なる文字がこれら文字で識別される異なる予 め規定されたフォントを持つことができ、かつ 予め規定されたフォント記述をアクセスして、新たなフォント記述を生成する 前記ステップが、前記異なる予め規定されたフォントの前記文字を含む前記受取 られた全ての文字に対して自動的に動作する請求項１ないし８のいずれか１つに 記載のコンピュータ化方法。 １０．前記異なる予め規定されたフォントが、異なるフォント記述言語で規定さ れた関連する予め規定されたフォント記述を持つことができ、 予め規定されたフォント記述をアクセスする前記ステップが、前記異なるフォ ント記述言語で規定された予め規定されたフォント記述をアクセスし、 新たなフォント記述を生成する前記ステップが、前記異なるフォント記述言語 から予め規定されたフォント記述を、１つのフォント記述言語で規定される前記 新たなフォント記述に解釈することを含む請求項９記載のコンピュータ化方法。 １１．予め規定されたフォント記述が１つのフォント記述言語でよく、前記フォ ント記述が別のフォント記述言語でよい請求項１ないし１０のいずれか１つに記 載のコンピュータ化方法。 １２．前記アクセスされた予め規定されたフォント記述の少なくとも１つが文字 −フォント形状をビット・マップ・パターンとして記述する請求項１ないし１１ のいずれか１つに記載のコンピュータ化方法。 １３．前記アクセスされた予め規定されたフォント記述の少なくとも所与の１つ が文字−フォント形状を一連のアウトライン線分として記述する請求項１ないし １２のいずれか１つに記載のコンピュータ化方法。 １４．前記の所与の予め規定されたフォント記述と対応する新たなフォント記述 におけるアウトライン線分の順序と区切りが、前記の所与の予め規定されたフォ ント記述により記述された実際の形状の関数ではない所与の予め規定されたフォ ント記述におけるアウトライン線分の順序と区切りに依存しない請求項１３記載 のコンピュータ化方法。 １５．複数の文字を受取る前記ステップが少なくとも１つの非文字形状を受取る ことも含み、 予め規定されたフォント記述をアクセスする前記ステップがかかる非文字形状 の予め規定されたフォント記述をアクセスすることを含み、 新たなフォント記述を生成する前記ステップがかかる非文字形状に対する新た なフォント記述を生成することを含む請求項１ないし１４のいずれか１つに記載 のコンピュータ化方法。 １６．予め規定されたフォント記述をアクセスする前記ステップが予め規定され たフォントに分類される予め規定されたフォント記述をアクセスすることを含み 、 各々が所与の予め規定されたフォントに対応し、かつ前記所与の予め規定され たフォントと関連する予め規定されたフォント記述と対応する新たなフォント記 述を有する、新たなフォントへ新たなフォント記述を分類することを含む請求項 １ないし１５のいずれか１つに記載のコンピュータ化方法。 １７．新たなフォント記述を生成しかつ新たなフォント記述を新たなフォントへ 分類する前記ステップが、 各々の新たな論理的フォントにおける各文字に対して形状が関連する新たな物 理的フォントにおける前記文字の形状から新たな論理的フォントと関連する１組 の変形によって取得できるように、各々が関連する新たな物理的フォントを有す る新たな論理的フォントのファミリへ新たなフォントを分類するステップと、 新たな物理的フォント記述が文字の形状を該形状を表わす１つ以上のアウトラ インの各々に対する一連のアウトライン線分で記述する、新たな各物理的フォン トにおける複数の文字の各々に対して新たな複数のフォント記述を生成するステ ップと、 論理的フォントが関連する物理的フォントと、前記論理的フォントにおける文 字の形状を前記物理的フォントから得るための１組の変形とを記述する各論理的 フォントに対する新たな論理的フォント記述を生成するステップと、 を含む請求項１６記載のコンピュータ化方法。 １８．アクセスされた予め規定された各フォント記述により規定される文字−フ ォント形状の幾何学的モデルを生成するモデリング・ステップを更に含み、該モ デルが前記文字−フォント形状の１つ以上のアウトラインを表わし、 新たなフォント記述を生成する前記ステップが、アクセスされた予め規定され た各フォント記述に対して生成されたモデルから新たなフォント記述を生成する ことを含み、前記新たなフォント記述が前記モデルにより表わされる形状を一連 のアウトライン線分として記述する請求項１ないし１７のいずれか１つに記載の コンピュータ化方法。 １９．前記モデリングステップが、前記形状の関連する予め規定されたフォント 記述に明確に表わされない文字−フォント形状における特徴を明確に表わし、 かかる文字−フォント形状モデルに対して生成される新たなフォント記述の一 連のアウトライン線分が部分的に前記明確に表わされた特徴によって決定される 請求項１８記載のコンピュータ化方法。 ２０．前記モデリング・ステップが、かかる文字−フォント形状のアウトライン における記述に依存しない点を識別するステップを含み、該点が、前記文字−フ ォント形状が関連する予め規定されたフォント記述により規定された方法とは独 立的にかかる各アウトライン形状の関数であり、 新たなフォント記述を生成する前記ステップが前記モデリング・ステップによ り識別される前記記述に依存しない点を用いて、前記新たなフォント記述におけ るアウトライン線分の終点を決定する請求項１８または１９のいずれか１つに記 載のコンピュータ化方法。 ２１．記述に依存しない点を識別する前記ステップが、所与の文字−フォント形 状のアウトラインにおける複数の記述に依存しない点を識別することを含み、 前記モデリング・ステップが更に、前記所与のアウトラインにおける２つの隣 接する記述に依存しない点間の前記所与のアウトラインの形状を前記２つの隣接 点で囲まれた近似化された線分で近似化することを含み、 新たなフォント記述を生成する前記ステップが、一連のアウトライン線分が前 記近似化されたアウトライン線分を含む新たなフォント記述を生成することを含 む請求項２０記載のコンピュータ化方法。 ２２．記述に依存しない点を識別する前記ステップが、各文字−フォント形状ア ウトラインが各々が隣接する１対の前記点間に位置される一連の１つ以上の前記 近似化線分により厳密に近似化されることを可能にするため、前記アウトライン における前記点を充分に識別することを含み、 前記近似化ステップが、前記文字−フォント形状アウトラインの各々における 前記の記述に依存しない点の対の各々の間の前記近似化線分の１つを生成し、 新たなフォント記述を生成する前記ステップが、完全に前記近似化されたアウ トライン線分からなる一連のアウトライン線分として所与の文字−フォント形状 を記述する新たなフォント記述を生成する 請求項２１記載のコンピュータ化方法。 ２３．前記モデリング・ステップが、記述に依存しない点として、横方向および 縦方向における極値を表わす前記文字−フォント形状アウトラインにおける点を 識別することを含み、 新たなフォント記述を生成する前記ステップは、前記文字−フォント形状モデ ルのアウトラインにおける前記極値として識別された点と対応する点における終 点を有するアウトライン線分を有する新たなフォント記述を生成することを含む 請求項２０ないし２２のいずれか１つに記載のコンピュータ化方法。 ２４．前記モデリング・ステップが、記述に依存しない点として、前記文字−フ ォ ント形状アウトラインにおける変曲点を表わすかかるアウトラインにおける点を 識別することを含み、 新たなフォント記述を生成する前記ステップが、前記文字−フォント形状モデ ルのアウトラインにおける前記変曲点として識別される点と対応する点における 終点を有するアウトライン線分を有する新たなフォント記述を生成することを含 む請求項２０ないし２３のいずれか１つに記載のコンピュータ化方法。 ２５．前記予め規定されたフォント記述が、各々が開始点と終点とを有する一連 のアウトライン線分として文字−フォント形状を記述し、１つの線分の終点が次 の開始点であり、 記述に依存しない点を識別する前記ステップが、予め規定されたフォント記述 により記述されたアウトライン線分のどの終点が前記予め規定されたフォント記 述により規定された形状のアウトラインにおけるコーナー点を表わすかを識別す ることを含み、コーナー点を識別する前記ステップが、 テストされる各終点およびそのアウトラインにおける２つの隣接する終点に対 して、前記３つの終点の各々の位置があり得る量子化誤差と対応する量だけ調整 されられるならば、前記３つの終点を通って直線を描くことができるかどうかを 知るためテストするステップと、 前記線を描くことができないと前記テストが判定するならば、テストされた終 点を記述に依存しないコーナー点として識別するステップとを含む請求項２０な いし２４のいずれか１つに記載のコンピュータ化方法。 ２６．直線を３つの終点を通って描くことができるかどうかを知るためテストす る前記ステップが、テストされる終点により囲まれたアウトライン線分の１つが ベジェ曲線である時動作する、前記テストの目的のため湾曲した前記線分の隣接 する終点として前記曲線における最も近い制御点を処理するステップを含む請求 項２５記載のコンピュータ化方法。 ２７．直線を３つの終点を通って描くことができるかどうかを知るためテストす る前記ステップが、３つの点の各々の位置が、角度を最大化しようとする方向に おける最大量子化誤差と対応する量だけかかる３つの点の各々の位置が移動され るならば、テストされる終点とその２つの隣接する終点とにより形成される凹面 形の角度があれば、該凹面形角度を１８０度と等しいかあるいはこれより大きい 角度へ変更することができるかどうかをテストすることを含む請求項２５または ２６のいずれか１つに記載のコンピュータ化方法。 ２８．前記モデリング・ステップが、全ての文字−フォント形状のモデルに対し て用いられる標準的な規則セットに従ってかかる各モデルのアウトラインを順序 付けることを含み、前記規則は前記予め規定されたフォント記述の形状に依存し ない特徴から独立的であり、 新たなフォント記述を生成する前記ステップが、前記モデリング・ステップに よる対応するアウトラインの順序付けに従って新たな各フォント記述の一連のア ウトライン線分を順序付けすることを含む請求項２０ないし２７のいずれか１つ に記載のコンピュータ化方法。 ２９．記述に依存しない点を識別する前記ステップが、各文字−フォント形状モ デルの各アウトラインの全てに課される標準的な規則セットに従って、前記各ア ウトラインに対する開始点として前記点の１つを識別することを含み、前記規則 が前記予め規定されたフォント記述の何らかの形状に依存しない特徴とは独立的 にかかる各アウトラインの形状の関数であり、 前記モデリング・ステップが、アウトラインに対して識別される開始点で始ま る、各文字の形状モデルの各アウトラインの記述に依存しない点が読出される方 向を割当てることを更に含み、前記方向が標準的な規則セットに従って割当てら れ、該規則は前記予め規定されたフォント記述の形状に依存しない特徴とは独立 的であり、 新たなフォント記述を生成する前記手段が、前記アウトラインに対して識別さ れた開始点で開始する前記モデリング・ステップにより前記アウトラインに対し て割当てされた前記方向における所与の文字形状を記述する各アウトラインに対 する一連のアウトライン線分を生成する請求項２０ないし２８のいずれか１つに 記載のコンピュータ化方法。 ３０．個々のアクセスされた予め規定されたフォント記述により記述された文字 −フォント形状が、各々が１つの外側のアウトラインとゼロ以上の内側のアウト ラインをを有する、１つ以上の個々の形状あるいは象形部からなり、 前記モデリング・ステップが、 所与の所定のフォント記述により規定されたどのアウトラインが同じ象形部 と関連させられるか、および同じ象形部と関連するどのアウトラインが外側ある いは内側のアウトラインであるかを判定するステップと、 それぞれ外側および内側のアウトラインに対する異なる標準化された規則に 従ってモデル化された各外側および内側のアウトラインにおける開始点をマーク するステップとを含み、前記規則が前記象形部の全てに対して用いられ、かつ前 記の予め規定されたフォント記述が記述する文字−フォント形状において固有で ない予め規定されたフォント記述の特質とは独立的であり、 アクセスされた予め規定された各フォント記述に対して生成された新たなフォ ント記述が、該予め規定されたフォント記述に対してモデル化された各アウトラ インの形状を、前記モデリング・ステップにより対応するモデル・アウトライン に対してマークされた開始点と対応する点で開始する一連のアウトライン線分と して記述する請求項２０ないし２９のいずれか１つに記載のコンピュータ化方法 。 ３１．前記モデリング・ステップが、 異なるモデルからのどのアウトラインが類似する形状を共有するかを判定する ため、異なるアクセスされた予め規定されたフォント記述に対して生成された文 字−フォント形状モデルのアウトラインを比較するステップと、 類似する形状を共有するようにアウトラインが前記比較ステップにより判定さ れる表示を格納するステップとを含み、 新たなフォント記述を生成する前記ステップが、 前記の共有される各形状を規定するかかる共有された形状に対する共通のＦＯ Ｓを一連のアウトライン線分として生成するステップと、 共有される形状を含む文字−フォント形状に対する新たなフォント記述に、該 共有形状に対する共通フォント記述の照合によって共有形状を規定する前記一連 のアウトライン線分を記述させるステップとを含む請求項２０ないし３０のいず れか１つに記載のコンピュータ化方法。 ３２．アウトラインを比較する前記ステップが、異なる予め規定されたフォント と関連する予め規定されたフォント記述により規定された文字−フォント形状の モデルのアウトラインを比較することができ、 共有される形状に対する共通の記述を生成する前記ステップが、前記異なる予 め規定されたフォントと関連する前記予め規定されたフォント記述により規定さ れる文字−フォント形状のモデル間に共有される形状に対する前記共通の記述を 生成することができる請求項３１記載のコンピュータ化方法。 ３３．アウトラインを比較する前記ステップが、異なるフォント記述言語で書か れた予め規定されたフォント記述により規定される文字−フォント形状のアウト ラインを比較することができ、 共有される形状に対する共通の記述を生成する前記ステップが、異なるフォン ト記述言語で書かれた前記予め規定されたフォント記述により規定される文字− フォント形状のモデル間に共有される形状に対する前記共通記述を生成すること ができる請求項３１または３２のいずれか１つに記載のコンピュータ化方法。 ３４．アウトラインを比較する前記ステップが、かかるアウトラインのサイズお よび位置とは独立的に前記比較を行い、その結果類似する形状を持つが異なるサ イズおよび位置を有する異なる文字−フォント・モデルにおけるアウトラインが 類似する形状を持つものとして取扱うことができる請求項３１ないし３３のいず れか１つに記載のコンピュータ化方法。 ３５．前記モデリング・ステップが更に、１つ以上の前記文字−フォント形状モ デルの各アウトラインの組合わせに対するシグネチャを生成することを含み、該 シグネチャは対応する予め規定されたフォント記述の形状に依存しない特徴とは 独立的であり、かつ該シグネチャが各々前記組合わせのアウトラインの形状につ いての抽象概念を表わす標準的な順序を持つ一連のデータ・ワードを含む前記文 字−フォント形状モデルの１つ以上のアウトラインの組合わせに対するシグネチ ャを生成することを含み、 アウトラインを比較する前記ステップが、異なるアウトラインの組合わせと関 連する前記シグネチャを比較すること、および前記組合わせに対するシグネチャ が一致するならば、アウトラインの異なる組合わせの実際の形状のみを比較する ことを含む請求項３１ないし３４のいずれか１つに記載のコンピュータ化方法。 ３６．シグネチャを比較する前記ステップが、 前記アウトラインの組合わせをそれらのシグネチャに基いて分類するステップ と、 所与のシグネチャが前記分類されたシグネチャのどれかと一致するかどうかを 判定するため、前記分類を用いて前記シグネチャの所与の１つに比較されるべき 前記シグネチャの数を減少するステップとを含む請求項３５記載のコンピュータ 化方法。 ３７．前記モデリング・ステップが、前記モデルの１つ以上の接触しない中ベタ の形状の各々の境界を表わす文字−フォント形状の１つ以上のアウトラインを一 緒に象形部に分類し、 アウトラインを比較する前記ステップが、異なる象形部と関連するアウトライ ンのグループを比較して、その結果１つの象形部に分類された全てのアウトライ ンが別の象形部に分類された対応する全てのアウトラインと一致する場合にのみ 一致が見出され、 類似する形状を共有するアウトラインの表示を格納する前記ステップが、文字 −形状モデルが類似するアウトライン形状を共有すると判定され、これにより類 似する象形部であるかの表示を格納し、 共通のフォント記述を生成する前記ステップが、同じアウトライン形状の分類 を共有する類似象形部に対するかかる共通の記述を生成し、 新しいフォント記述に共通にフォント記述を照合して共有される形状を規定さ せる前記ステップが、類似する象形部を含む文字−フォント形状モデルに対する 新たなフォント記述に、類似する象形部に対して共通のフォント記述を照合して 類似する象形部を規定する一連のアウトライン線分を記述させる請求項３１ない し３６のいずれか１つに記載のコンピュータ化方法。 ３８．前記モデリング・ステップが、均一な規則に従って各象形部の１つ以上の アウトラインを順序付けすることを含み、その結果前記象形部のアウトラインの 形状の比較ステップを早めることができる請求項３７記載のコンピュータ化方法 。 ３９．前記モデリング・ステップが、 各文字−フォント形状の各アウトラインを、各々が湾曲し得るかあるいは直線 であり得る１つ以上の一連のアウトライン線分としてモデル化するステップと、 前記湾曲したアウトライン線分の各々に対して、各湾曲アウトライン線分を部 分曲線の各終点間のベクトルから指定される最大距離より小さい全ての偏差であ る部分曲線へ分割するのに必要な反復的細分割の深さを表わす深さ係数を計算す るステップとを含み、該深さ計算ステップが、 前記個々の湾曲したアウトライン線分の各々において反復的細分割を実行す ることにより前記深さ係数を計算するステップを含み、細分割の所与の各反復に おいて 所与の反復が多数の部分曲線になるように実行される曲線の部分を分割し 、 所与の反復により生成される各部分曲線と、該部分曲線の終点間のベクト ル間の最大偏差が特定量より小さいかどうかを測定し、 所与の反復により生成される全ての部分曲線に対して最大偏差が前記特定 量より小さい時、前記反復プロセスのその時の分岐を停止し、 所与の反復により生成される任意の部分曲線に対する最大偏差が前記特定 量より大きい時、終点間のベクトルからの最大の偏差を持つ所与の反復により生 成される部分曲線におけるより深い反復を選択的に実行し、 前記所与の反復の反復深さのカウントを保持するステップを実行すること を含み、 当該アウトライン線分に対して実行された全ての反復的細分割の間カウント を保持するステップにより生成される反復的深さのより大きなカウントについて 前記湾曲アウトライン線分の各々に対する計算された深さ係数をバイアスするス テップを前記深さ計算ステップが含み、 新たなフォント記述を生成する前記ステップが、所与の文字−フォント形状モ デルにおける湾曲したアウトライン線分と対応するアウトライン線分が前記モデ リング・ステップにより計算された対応する深さ係数により表示される新たなフ ォント記述を生成する請求項１８ないし３８のいずれか１つに記載のコンピュー タ化方法。 ４０．請求項１ないし３９のいずれか１つの方法を実行する装置。 ４１．請求項３の方法により生成される取外し自在の大容量記憶媒体。