(57)【特許請求の範囲】
【請求項１】
フォントに含まれるグリフを表すピクセル・データを提供する装置であって、
該装置は、フォント・データを記憶し、複数の項目群を有するメモリ手段、およびプロセッサ手段を備え、
前記メモリ手段は、
一連のデータ・ブロックを有する第１の項目群と、
データ圧縮形のグリフを含むデータ・ブロックを文字コードが識別することを可能にする第２の項目群と、
前記データ・ブロックのデータ伸長形のグリフのアドレスが識別されることを可能にする第３の項目群とを有しており、
前記データ・ブロックのそれぞれは、データ圧縮形の複数のグリフを含み、該複数のグリフは、それぞれのデータ圧縮形のグリフが同じ伸長手順を用いて伸長されるように共通属性を呈しており、異なるデータ・ブロックは異なる共通属性を呈し、
前記プロセッサ手段は、文字コードを含む信号ストリームに応答して、前記第２の項目群を使用して、該文字コードに対応するグリフを含むデータ・ブロックを前記メモリ手段からアクセスし、該グリフのすべての伸長済みピクセル・データ表現が該プロセッサ手段に利用可能となるように、該文字コードに対応しないグリフも含めて、該データ・ブロックのデータ圧縮形のすべてのグリフに前記同じ伸長手順を受けさせ、前記第３の項目群を使用して、前記文字コードに対応するデータ伸長形のグリフを識別する、
フォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項２】
前記メモリ手段は複数の伸長手順を記憶し、それぞれのデータ・ブロックは、該データ・ブロックのデータ圧縮形のグリフに用いられる、該伸長手順のうちの１つを示す識別子を有する、請求項１に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項３】
前記共通属性は、データ・ブロック内の少なくともいくつかのグリフが、英数字を作成するために組み合わせられることを示す、請求項１に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項４】
前記メモリ手段は、前記記憶されたフォント・データが圧縮形であることを示す項目を有する、請求項１に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項５】
前記項目は、データ・ブロックのすべての伸長済みグリフの最大ピクセル・データ・サイズを収容するのに必要な最大メモリ量を示すパラメータ値である、請求項４に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項６】
前記メモリ手段における前記パラメータ値の存在が、前記記憶されたフォント・データが伸長形であることを示す前記項目である、請求項５に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項７】
前記メモリ手段および前記プロセッサ手段は、プリンタの一部である、請求項１に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項８】
データ・ブロックの伸長済みピクセル・データを記憶するキャッシュ手段をさらに備え、
前記メモリ手段のそれぞれのデータ・ブロックは、該データ・ブロックの伸長済みピクセル・データを該キャッシュ手段に記憶すべきかどうかに関するインジケータを含む、請求項１に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【請求項９】
前記インジケータは、さらに、前記伸長済みピクセル・データがいつ前記キャッシュ手段から取り除かれるべきかを制御する、前記伸長済みピクセル・データのためのパラメータを示す、請求項８に記載のフォントに含まれるグリフを表すピクセル・データを提供する装置。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、アウトライン・フォント表現を使用するデータ処理システムに関し、詳細には、圧縮済みフォントを含むプリンタ・システムと、フォント記憶容量要求を低減する圧縮済みフォントの伸長の手順とに関する。
【０００２】
【従来の技術】
多数のフォントは、アウトライン形で記憶され、プリンタによってアクセスされると、フォント文字の完全なストローク表現を示すように「充填つぶされる」。TrueTypeは、ある種のコンピュータ・アウトライン・フォント・データの表現を定義する業界規格である。TrueTypeフォーマットを使用して大きなフォント（たとえば、漢字）を表すとき、メモリ要件は２メガバイトないし５メガバイトを超えることがある。そのようなフォントは読取り専用メモリ（ＲＯＭ）に記憶されることが多いので、大規模で拡張可能なＲＯＭが必要とされる。フォントは、ディスク・ドライブ上（たとえば、コンピュータ・オペレーティング・システム中）に記憶することも、あるいはランダム・アクセス・メモリ（ＲＡＭ）（たとえば、コンピュータのメイン・メモリに維持されるフォント）に記憶することもできる。
【０００３】
フォント記憶メモリ容量の低減は常に課題とされているが、これと並行して、以前に定義された業界フォント規格（たとえば、TrueType）との互換性を維持する必要もある。図１に、TrueTypeアウトライン・フォント・データを使用するようになされたデータ処理システム（たとえば、レーザ・プリンタ）が示されている。システム１０は、バス・システム１４を介してレーザ・プリント・エンジン１６に接続されたマイクロプロセッサ１２を含む。バス・システム１４は、TrueTypeフォント・テーブル１９（以下で図２に関して説明する）を含むＲＯＭ１８にも接続されている。ランダム・アクセス・メモリ（ＲＡＭ）２０も、プリント・バッファ２２と同様に、バス・システム１４に接続されている。プリント・バッファ２２はＲＡＭ２０の一部であってもよい。
【０００４】
入出力文字２４は、文字コードを含むホスト・コンピュータからのメッセージ・ストリームを受け取るようになされている。各文字コードは、文字または文字の一部を表し、ピクセル・データ形で構成されたときにプリント・バッファ２２に記憶できる、データであるグリフ（glyph: 装飾記号）を指定する。文字が複数のグリフから成る場合、１つのグリフは、完全な文字を作成するための追加グリフを指定する。そのようなピクセル・データがプリント・エンジン１６に提供されると、グリフを複製する媒体シート上へのインク付着が可能になる。
【０００５】
システム１０が、文字コードとプリント・コマンドを共に含むメッセージ・ストリームをホスト・コンピュータから受け取ると、文字コードが、自動的に記憶され、次いでフォント・テーブル１９を参照することによってグリフ・データに変換される。グリフ・データは、ピクセル形でプリント・バッファ２２に記憶され、次いでプリント・エンジン１６に提供される。
【０００６】
図２は、図１中のＲＯＭ１８に記憶された状態のTrueTypeフォント・テーブル１９を示す。TrueTypeフォント・テーブル１９は、文献「TrueType Font Files Version 1.00」（マイクロソフト社（Microsoft Corporation）、ワシントン州レッドモンド）で定義されている。TrueTypeフォント・テーブル１９は、ヘッダ３０と、ディレクトリ部分３４中の項目を形成するタグ行３２で始まる。タグ行３２は、テーブルを識別するタグ（すなわち、「名前」）と、エラー訂正のためのチェックサムと、テーブルの長さを定義する長さフィールドと、ディレクトリ部分３４の後でテーブルが始まる点を示すオフセット値とを含む。
【０００７】
各TrueTypeフォント・テーブル１９は、多数のテーブルを含む。そのうちの３つのサブテーブルは、ＣＭＡＰテーブル３６、ＬＯＣＡテーブル３８、およびＧＬＹＰＨテーブル４０である。ＣＭＡＰテーブル３６は、受け取られた文字コードに従ってアドレスされ、関連するグリフ・インデックス値を返す。各グリフ・インデックス値は、ＬＯＣＡテーブル３８へのアドレスとして働き、オフセット値と関連付けられる。ＬＯＣＡテーブル３８は、受け取られたグリフ・インデックス値に応答して、受け取られた文字コードによって識別されるグリフのピクセル・データ形があるグリフ・テーブル４０内のアドレス・オフセットを識別するオフセット値を返す。グリフ・テーブル４０は、標準TrueTypeフォント・テーブルでは、ＲＯＭ１８の約９０％を占有し、上記のように、２メガバイトないし５メガバイト程度になることもある。
【０００８】
グリフは、グリフ・テーブル４０からアクセスされた後、図１中のＲＡＭ２０に記憶されている「充填」手順４２を使用して処理される。充填手順４２によって、プリント・バッファ２２中のピクセル・データが、完全に充填された文字を表すように、アウトライン・グリフ・データを完全に「充填する」ことができる。この段階で、プリント・バッファ２２中のグリフは、プリント・エンジン１６による印刷の準備ができている。グリフ・テーブル４０から得たグリフ・データに文字の一部しか含まれていない場合、次の手順を使用して、完全な文字に達するようにグリフどうしを関連付ける。
【０００９】
【発明が解決しようとする課題】
したがって、本発明の一目的は、フォント・データを圧縮形で記憶することによってフォント記憶容量を最小限に抑えるデータ処理システムを提供することである。
【００１０】
本発明の他の目的は、既存のフォント規格と互換性のある圧縮形フォント記憶域を含むデータ処理システムを提供することである。
【００１１】
本発明の他の目的は、圧縮フォント記憶域を含むデータ処理システムを提供し、さらに、記憶されている個別のグリフに対して最も効率のよい伸長動作を実行できるようにする伸長手順を提供することである。
【００１２】
【課題を解決するための手段】
データ処理システムは、フォント・グリフのピクセル・データ表現を提供し、フォント・データを複数の項目群として記録するメモリを含む。第１の項目群は、それぞれ、データ圧縮形の複数のグリフを含む、一連のデータ・ブロックから成る。データ・ブロック中の複数のグリフは、それらが一緒に伸長されることを示す共通属性を示す。プロセッサは、文字コードを含む信号ストリームに応答して、受け取られた文字コードに対応するグリフを含むデータ・ブロックにメモリからアクセスする。プロセッサは、データ・ブロックから得たデータ圧縮形のグリフをすべて、複数の伸長手順のうちの１つに従わせる。このように、データ・ブロック中の伸長済みピクセル・データ表現のグリフはすべて、伸長動作の結果として、プロセッサによって使用することができる。ある種の状況では、伸長済みグリフ・フォント・データが、伸長後、続いて使用できるようにキャッシュに記憶される。
【００１３】
【実施例】
本発明の詳細を説明する前に、図１に示したシステムが、以下で説明する予定の必要な変更をおこなったフォント・テーブルおよび圧縮済みグリフ・ブロックをメモリに記憶する限り、本発明を実行できることを理解されたい。システム１０はプリンタとして示されているが、当業者には、本発明が、ホスト・プロセッサ、マイクロプロセッサを含むプリンタ、またはそれら２つの組合せによって使用できるように構成できることが理解されよう。いずれの場合も、図３および図４に示したデータ構造を、そのようなデータ構造を使用できるようにする手順と組み合わせて含めることによって、フォント・メモリを大幅に節約することができる。
【００１４】
図３に移ると、フォント・テーブル５０は、図２に示した従来技術のTrueTypeフォント・テーブル１９に類似しているが、圧縮済みグリフ・データを含められるように改訂されている。ヘッダ部分３０およびディレクトリ３４（タグ行３２を含む）は、図２に示したものと実質的に同じである。タグ行３２中の長さ値およびオフセット値は、縮小フォント・テーブルに従って修正される。ＣＭＡＰテーブル３６も、図２に示したものと実質的に同じであり、受け取られた文字コードをグリフ・インデックス値に変換する。ＣＭＡＰテーブル３６からアクセスされる各グリフ・インデックス値によって、ＬＯＣＡテーブル５２中の関連するオフセット値をアドレスすることができる。しかし、この場合、ＬＯＣＡテーブル５２によって返されるオフセット値は、グリフ・テーブル５４に記憶されている圧縮済みグリフ・ブロックのオフセット・リスト部分の最初のアドレスを指す。図３に示した空テーブルおよびサブテーブルが必ずしも隣接して記憶されるわけではないことを理解されたい。これらのテーブルは、ディレクトリ３４から得たオフセット・データを使用してアクセスされる。
【００１５】
引き続き、さらにフォント・テーブル５０を説明する前に、典型的な圧縮済みグリフ・ブロック６０を図４に関して説明しておく。各圧縮済みグリフ・ブロックは、複数の圧縮済みグリフ・データ・セグメントを含む部分６２を含む。圧縮済みグリフ・ブロック６０の部分６２には１つの圧縮済みグリフ・データ・セグメントが含まれているが、一般には、複数の圧縮済みグリフ・データ・セグメントが部分６２に含められうる。単一の伸長手順を使用して、データを伸長してもとのピクセル・アウトライン・データ状態に戻せるように、部分６２に含められるすべてのグリフは同じ圧縮手順を使用して圧縮される。部分６２内に含められるすべてのグリフは、どれか１つのグリフが要求されたときに部分６２中のすべてのグリフを伸長することが論理的であるようにする共用属性によって特徴付けられる。たとえば、部分６２中の圧縮済みグリフ・データは、完全な英数字を形成するために組み合わせなければならない複数のグリフで構成することができる。さらに、部分６２中の圧縮済みグリフ・データは、使用頻度に基づいてグループ分けすることもできる。したがって、第１の圧縮済みグリフ・ブロック６０は最も頻繁に使用されるグリフを含み、第２の圧縮済みグリフ・ブロック６０はそれほど頻繁に使用されないグリフを含み、以下、同様である。
【００１６】
圧縮済みグリフ・ブロック６０は、複数のオフセット値６６、６８、７０などを記憶する次の部分６４を含む。値６６は、伸長されてメモリに置かれた後、部分６２に圧縮形で含まれる第１のグリフ中のピクセルの最初のオフセット・アドレスを示す（第１の伸長済みグリフは常に０オフセットである）。したがって、７２で示したように、第１の伸長済みグリフはアドレス０ないし１１０を占有し、第２の伸長済みグリフはアドレス１１１ないし２５０を占有し、第３の伸長済みグリフはアドレス２５１ないし３７０を占有し、以下、同様である。したがって、部分６４に含められるオフセット値によって、マイクロプロセッサ１２は、各グリフ・ピクセル表現が伸長されてメモリに置かれた後、そのグリフ・ピクセル表現を識別して見つけることができる。
【００１７】
圧縮済みグリフ・ブロック６０（図４）は、「Hidx」バイト（ここで、Hidxは「Ｈｕｆｆインデックス」の頭字語である）と呼ばれる次のセクション７４を含む。Hidxバイト７４の２ビットは、ブロック６０から得た伸長済みグリフ・ピクセル・データの「キャッシング」状況を識別するために使用され、４ビットは、圧縮済みグリフ・ブロック６０中の圧縮済みグリフ・データ・セグメントの伸長時に使用すべき伸長手順を識別するために使用される。ある種の状況では、グリフ・データ・セグメントが圧縮状態ではなく、このことは、すべてゼロ状態を示す前述の４ビットによって示される。
【００１８】
上記で示したように、圧縮済みグリフ・ブロック６０の部分６２中の圧縮済みグリフ・データ・セグメントはすべて、同じ伸長手順を使用して伸長される。したがって、部分６２に含められるグリフは、共通の圧縮手順を使用して前記グリフを圧縮できるようにする類似の特性を示すように選択されることが好ましい。これによって、部分６２に含められる圧縮済みグリフ・データ・セグメントを、特殊な調整を施された伸長手順によって効率的に伸長することができる。
【００１９】
調整された伸長手順を実行するように伸長ルーチンを導くデータは、フォント・テーブル５０中の伸長テーブル部分７６（図３参照）に記憶される。Hidxバイト７４の４ビットは、圧縮済みグリフ・ブロック６０の部分６２中の圧縮済みグリフ・データ・セグメントを伸長するために伸長手順によってどのデータを使用すべきかを識別する。たとえば、部分７６中の各伸長手順は、Ｌｅｍｐｅｌ−Ｚｉｖ辞書（一般に使用されている圧縮／伸長手順）のサブセットを含むことができ、部分６２に含まれる特定のグリフに特定的に関連する辞書項目しか含まない。また、部分７６には、他の位置に記憶されたＬｅｍｐｅｌ−Ｚｉｖデータにアクセスできるようにするオフセット・データおよび長さデータしか含められない。
【００２０】
上記で示したように、Hidxバイト７４は、部分６２から伸長されるグリフに関するキャッシュ状況を識別する追加２ビットを含む。３つのキャッシング状況が好ましいが、当業者には他のものも明らかになろう。第１に、伸長済みグリフ・データを使用直後に廃棄することができる（すなわち、キャッシングなし）。第２に、伸長済みグリフ・データがある短い間隔内に使用されず、かつそのデータを廃棄するのが最もよいことが分かっているとき、このデータをその間隔中だけ記憶することができる。第３に、伸長済みグリフ・データが半永久的に記憶されるほど（あるいは、システムが、パワー・ダウンされ、あるいはその他の方法でそのデータを廃棄するよう命令されるまで）頻繁に、このデータを使用することができる。
【００２１】
部分６２内に含められる圧縮済みグリフ・データの量と、そのようなデータにアクセスしてそれを伸長するために必要とされる伸長時間の間にトレードオフがある。部分６２中に含められる圧縮済みグリフ・データの量が多ければ多いほど、圧縮が効率的になり、メモリの節約が大きくなる。しかし、部分６２に含められる圧縮済みグリフ・データが多ければ多いほど、そのデータに必要とされる時間が長くなる。さらに、以前にキャッシュされた圧縮済みグリフ・データによって、ある種の矛盾が相殺される。それにもかかわらず、当業者には、処理時間の節約とメモリに関して按配すべきであることが認識されよう。この按配は、ユーザまたはシステム設計者によって決定される。
【００２２】
圧縮済みグリフ・ブロック６０の各部分６２は同じ長さである必要はない。たとえば、より高速の伸長および再取出しができるように、最も一般的に使用されるグリフをより小さな部分６２に含めることができる。それほど頻繁に使用されないグリフは、それほど頻繁に呼び出されず、追加処理時間もそれほど長くないので、より大きな部分６２に含めることができる。
【００２３】
図３のフォント・テーブル５０に戻ると、このテーブルの最後の部分は「ＣＴＴＦテーブル」と呼ばれ、フォント・テーブル５０中にこれが存在することは、グリフ・テーブル５４に圧縮済みグリフ・ブロック６０が含まれることを使用側システムに示す。ＣＴＴＦテーブル７８はさらに、圧縮済みグリフ・ブロック６０の部分６２から得た最大の伸長済みグリフ・データに必要とされるメモリの量を示す値を含む。これによって、システムは、圧縮済みグリフ・ブロック６０中の圧縮済みグリフ・データ部分６２から得た伸長済みグリフをすべて収容するのに十分なメモリを伸長の前に割り振っておくことができる。ＣＴＴＦテーブル７８は、各圧縮済みグリフ・ブロック６０ごとに個別の値を含む。この値は、各ブロックの伸長済みグリフ・データ部分６２ごとに割り振るべきメモリの量を示す。
【００２４】
次に、図３および図４に示したフォント・テーブルをＲＯＭ１８が含むときの図１のデータ処理システムの動作を説明する。最初、システム１０は、複数の文字コードを含むデータ・ストリームをホスト・プロセッサから受け取る。受け取られた文字コードは、ＣＭＡＰテーブル３６中のグリフ・インデックス値にアクセスするためにマイクロプロセッサ１２によって使用される。当業者には、ディレクトリ３４が、ＣＭＡＰテーブル３６（およびその他のテーブル）にアクセスできるように前記テーブルの最初のアドレスを判定するためにマイクロプロセッサ１２によって使用されることが認識されよう。
【００２５】
次いで、ＣＭＡＰテーブル３６から返されるグリフ・インデックスを使用して、圧縮済みグリフ・ブロック中のオフセット・リスト内を指す、ＬＯＣＡテーブル５２に含まれるオフセット値がアクセスされる。返されるオフセット値は、受け取られた文字コードに対応するグリフを含む圧縮済みグリフ・ブロック６０の最初のビット位置を示すグリフ・テーブル５４内のアドレスを提供する。
【００２６】
しかし、システムは、グリフ・テーブル５４から得た圧縮済みグリフ・ブロック６０にアクセスする前に、所望のグリフがすでに伸長され、すでにＲＡＭ２０中のキャッシュ領域４４にキャッシュされているかどうかを調べるための検査を行う。そうでない場合、圧縮済みグリフ・ブロックがアクセスされ、ＲＡＭ２０に記憶される。
【００２７】
システムは、Hidxバイト値およびＣＴＴＦテーブルを読み取って、伸長済みグリフ・ピクセル・データに割り振るべきメモリのサイズと、部分７６からアクセスすべき特定の伸長手順を判定する。伸長手順がアクセスされた後、圧縮済みグリフ・データ・セグメントの部分６２が伸長手順に従い、伸長済みグリフがＲＡＭ２０に記憶される。
【００２８】
圧縮済みグリフ・ブロック６０の部分６４が、伸長後、圧縮済みグリフ・ブロック中の各グリフごとのオフセット値のリストを含むことが想起されよう。システムは、オフセット値を使用して、所望の１つの伸長済みグリフにアクセスできるようにする。選択された伸長済みグリフがアドレスされて使用された後、システムは、Hidxバイトから得たキャッシュ状況ビットを検査して、伸長済みグリフを廃棄し、あるいはキャッシュ領域４４に一時的または半永久的にキャッシュする。
【００２９】
前記説明は本発明を例示したものに過ぎないことを理解されたい。当業者によって、本発明から逸脱せずに、様々な修正を構想することができる。以下に、実施態様のいくつかをしめす。
【００３０】
（実施態様１）
フォントに含まれるグリフを表すピクセル・データを提供するための装置において、第１の項目群（５４）が一連のデータ・ブロック（６０）から成り、該データ・ブロック（６０）がデータ圧縮形の複数のグリフを含み、該データ・ブロック（６０）から得た複数のグリフが一括伸長されることを示す共通属性を有する、複数の前記項目群を含むフォント・データを記憶するためのメモリ手段（１８）と、
文字コードを含む信号ストリームに応答して、前記文字コードに対応する前記データ圧縮形のグリフを前記メモリ手段（１８）から取り出し、前記データ圧縮形のグリフを一括伸長手順に従わせるためのプロセッサ手段（１２）とを備えることを特徴とする装置。
【００３１】
（実施態様２）
各前記データ・ブロック（６０）が、前記データ圧縮形のグリフの伸長後のピクセル・データが前記メモリ手段（１８）で占める位置を識別する複数のアドレス値（６６、６８、７０）を含むことを特徴とする実施態様１に記載の装置。
（実施態様３）
前記共通属性が、前記データ・ブロック（６０）中の前記データ圧縮形のグリフのそれぞれが共通の伸長手順を使用して伸長されるようなものである実施態様１に記載の装置。
（実施態様４）
前記メモリ手段（１８）が、調整された伸長手順を実施するために複数の伸長データ（７６）を記憶し、各前記データ・ブロック（６０）がその中の前記データ圧縮形のグリフと共に使用すべき１つの前記伸長データを示す識別子を含むことを特徴とする実施態様３に記載の装置。
【００３２】
（実施態様５）
前記共通属性が、少なくとも前記データ・ブロック（６０）中の前記データ圧縮形のグリフを英数字を形成するために組み合わすことを含むものであることを特徴とする実施態様１に記載の装置。
（実施態様６）
前記メモリ手段が、前記フォント・データが圧縮形であることを示す項目（７８）を含むことを特徴とする実施態様１に記載の装置。
【００３３】
（実施態様７）
前記項目（７８）が、前記データ・ブロック（６０）から得たすべての伸長済みグリフの最大ピクセル・データ・サイズを収容するのに必要とされる最大メモリ量を示すパラメータ値であることを特徴とする実施態様６に記載の装置。
（実施態様８）
前記メモリ手段中における前記パラメータ値の存在が、前記記憶されているフォント・データが伸長形であることを示す前記項目（７８）であることを特徴とする実施態様７に記載の装置。
（実施態様９）
前記メモリ手段（１８）と前記プロセッサ手段（１２）がプリンタ（１０）の一部を構成することを特徴とする実施態様１に記載の装置。
【００３４】
（実施態様１０）
さらに、前記データ・ブロック（６０）から得た伸長済みピクセル・データを記憶するためのキャッシュ手段（４４）を備え、前記メモリ手段（１８）中の各前記データ・ブロック（６０）が、前記伸長済みピクセル・データを前記キャッシュ手段（４４）に記憶すべきかどうかに関するインディケータ（７４）を含むことを特徴とする実施態様１に記載の装置。
（実施態様１１）
前記インディケータ（７４）がさらに、前記伸長済みピクセル・データをいつ前記キャッシュ手段（４４）から削除すべきかを制御する前記伸長済みピクセル・データ用のパラメータを含む実施態様１０に記載の装置。
【００３５】
【発明の効果】
以上詳述種したように、データ圧縮形のグリフが伸長手順によって区別されてデータ・ブロックを構成し、それらが一括伸長できるようにされているから、フォント・メモリの容量を少なくできる。また、伸長後のピクセル・パターンをキャッシュに格納することもできるので、低価格で高速な装置を提供できる。
【図面の簡単な説明】
【図１】アウトライン・フォント・データを記憶するためのメモリを含む従来技術のデータ処理システムのブロック図である。
【図２】従来技術の業界規格で指定されたTrueTypeフォント・テーブル・データ構造の概略表現図である。
【図３】本発明の動作で使用されるＲＯＭフォント・テーブルの概略図である。
【図４】本発明で使用される圧縮済みグリフ・ブロック・データ構造の概略表現図である。
【符号の説明】
１０  システム
３０  ヘッダ部分
３４  ディレクトリ
３６  ＣＭＡＰテーブル
５０  フォント・テーブル
５２  ＬＯＣＡテーブル
５４  グリフ・テーブル
６０  グリフ・ブロック
６２  部分
６６  オフセット値
７４  Hidxバイト
７６  伸長テーブル部分
【図１】
0003672608.tif 000002
【図２】
0003672608.tif 000003
【図３】
0003672608.tif 000004
【図４】
0003672608.tif 000005