JPH06242765A - フォントキャッシュシステム装置 - Google Patents

Abstract

(57)【要約】 【目的】 フォントキャッシュシステム装置において、
キャッシュできるフォント数を多くすること。 【構成】 フォントキャッシュシステム装置では、フォ
ントキャッシュメモリ内に、ビットマップデータを格納
するキャッシュエリア８−２と、その格納位置を示すフ
ォント検索テーブル８−１とが形成される。フォント検
索テーブル８−１を構成するに際し、第１水準文字のよ
うに使用頻度が大の文字Ｃ₁ の文字コードに対しては、
従来と同様、個別に専用のテーブル区画欄を設ける。し
かし、第２水準文字のように使用頻度が小の文字Ｃ₂ の
文字コードに対しては個別に設けず、幾つかの文字コー
ドに対して１つのテーブル区画欄を設ける。そして、そ
れを共用させる。これにより、フォント検索テーブル
を、従来より少ないメモリ量で構成でき、それだけキャ
ッシュエリアを広くすることが出来る。すると、キャッ
シュできるフォント数が多くなり、フォントデータをよ
り一層高速に提供することが出来る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、プリンタ等へ高速にフ
ォントを提供するためのフォントキャッシュシステム装
置に関するものである。

【０００２】

【従来の技術】プリンタ等へ高速にフォントを提供する
ため、全てのフォントのアウトラインデータ（ベクトル
データ）を格納している大容量の記憶装置の他に、小容
量だが高速に読み出すことの出来るキャッシュメモリを
設け、使用頻度の高いフォントのビットマップデータを
一時的にそこへ格納し、そこから提供するようにしたフ
ォントキャッシュシステム装置が知られている。

【０００３】図７は、そのようなフォントキャッシュシ
ステム装置の構成を示す図である。図７において、１は
フォントキャッシュシステム装置、２はＣＰＵ（中央演
算処理装置）、３はアドレスバス、４はデータバス、５
はＲＯＭ（リードオンリメモリ）、６はワークＲＡＭ
（ＲＡＭ…ランダムアクセスメモリ）、７はインタフェ
ース、８はフォントキャッシュＲＡＭ、９はページメモ
リ、１０はＤＭＡコントローラ（ＤＭＡ…Direct Memor
y Access）、１１はＳＣＳＩコントローラ（ＳＣＳＩ…
スカジ。ハードディスク用のインタフェース）、１２は
ハードディスク、１３はホストコンピュータ、１４はプ
リンタエンジン、１７はインタフェースである。

【０００４】ＲＯＭ５は、ＣＰＵ２で実行する種々のプ
ログラムを格納するためのものであり、ワークＲＡＭ６
は、プログラムを実行する際の作業用メモリエリアを提
供する。全てのフォントは、ベクトルデータの形でハー
ドディスク１２に格納されている。プリンタエンジン１
４で印刷する文字等の印字情報（例、文字コード）は、
ホストコンピュータ１３よりインタフェース７を介して
与えられる。

【０００５】その文字コードに対応したフォントは、ま
ずフォントキャッシュＲＡＭ８の中を探され、有ればそ
こから読み出し、ページメモリ９に展開する。もし無け
れば、ハードディスク１２より読み出し、ベクトルデー
タを基にして所望のサイズのビットマップデータを生成
し、それをページメモリ９に展開すると共に、フォント
キャッシュＲＡＭ８に蓄える。ページメモリ９に１ペー
ジ分のフォントが展開されると、プリンタエンジン１４
のインタフェース１７を通してプリント開始コマンドを
送出し、ＤＭＡコントローラ１０を経て、プリントデー
タ（ビットマップデータ）がプリンタエンジン１４へシ
リアルに送出され、印刷が実行される。

【０００６】なお、当初、フォントキャッシュＲＡＭ８
には何も格納されていない。ハードディスク１２から読
み出される毎に、フォントキャッシュＲＡＭ８にそのフ
ォントに関するレコード（レコードの構成は、後で図９
で説明する）が記録されてゆく。

【０００７】〔フォントキャッシュＲＡＭの構成〕ま
ず、フォントキャッシュＲＡＭ８の構成について説明す
る。図８は、フォントキャッシュＲＡＭ８の全体構成を
説明する図である。図８において、８−１はフォント検
索テーブル、８−２はキャッシュエリア、８０はテーブ
ル区画欄、８１は使用レコード、８２は空きレコード、
ＣＰは新規登録ポインタである。

【０００８】フォントキャッシュＲＡＭ８には、フォン
ト検索テーブル８−１とキャッシュエリア８−２が含ま
れている。キャッシュエリア８−２には、ビットマップ
データ等のフォントに関するレコードが登録され、フォ
ント検索テーブル８−１には、そのレコードが登録され
ている場所を示す情報が記録される。

【０００９】フォント検索テーブル８−１は、フォント
のコード数と同じ数の区画に分けられており、或る１つ
のフォントコードに対して特定の１つの区画が対応付け
られている。例えば、Ａという文字を表すフォントコー
ドに対しては、テーブル区画欄８０という区画が割り当
てられている。

【００１０】そして、もしＡのフォントがキャッシュエ
リア８−２に登録されていれば、テーブル区画欄８０の
中には、その登録場所（番地）を示す情報が書き込まれ
ている。同じフォントコードのフォントが複数個登録さ
れている場合には、その内の１つの登録場所が書き込ま
れる。登録されていなければ、書き込まれていない（Nu
llとされている）。

【００１１】キャッシュエリア８−２の中で、ドットを
付してある部分は、ハードディスク１２から読み出され
たフォントに関するレコードを登録するのに使用してい
るレコード領域、つまり使用レコードの部分である。ド
ットを付してない部分は、そのようには使用されていな
いレコード領域、つまり空きレコードの部分である。横
に引いた直線は、レコードの区切りを示している。

【００１２】新規登録ポインタＣＰは、フォントに関す
るレコードを新規に登録する場合の位置を示すポインタ
であり、キャッシュエリア８−２内を一定の方向にリン
グ的に進められる。その一定の方向を、図８では上から
下へという方向にすると、最下端の次には最上端へと進
められる。

【００１３】〔レコードの構成〕図９は、使用レコード
および空きレコードの構成を説明する図である。図９
（ロ）は、空きレコード８２の構成を示している。これ
には、空いていることを表す「空きフラグ」が記され、
空きレコードのエリアのサイズを表す「空きサイズ」が
記されている。

【００１４】図９（イ）は、使用レコード８１の構成を
示している。使用レコード８１は、フォントの属性に関
する情報を記録するエリアとビットマップデータを記録
するエリアとから成っている。フォントの属性に関する
情報としては、例えば、フォント種（例、明朝体，ゴシ
ック体）、フォントコード（文字コード等）、フォント
サイズ（縦，横の長さ）、ヒット回数、同一コードＮＥ
ＸＴポインタ、同一コードＢＥＦＯＲＥポインタ等があ
る。図９（イ）では、ビットマップデータの例として、
「Ａ」が示してある。

【００１５】ヒット回数は、キャッシュエリア８−２内
を一定の方向に向かって循環しているポインタが一周し
て来る間に、何回このフォントが使用されたかを示す回
数である。

【００１６】「同一コードＮＥＸＴポインタ」、「同一
コードＢＥＦＯＲＥポインタ」は、フォントキャッシュ
ＲＡＭ８内に同一コードのフォントが複数個登録されて
いる場合、それらの内で、この使用レコード８１が使用
される前および後に使用されたレコードの所在場所を示
すポインタである。即ち、同一コードＢＥＦＯＲＥポイ
ンタは、使用レコード８１がヒットする前に、それと同
一コードでヒットしたフォントの所在場所を示す。同一
コードＮＥＸＴポインタは、使用レコード８１がヒット
した後に、それと同一コードでヒットしたフォントの所
在場所を示す。

【００１７】同一コードＮＥＸＴポインタ、同一コード
ＢＥＦＯＲＥポインタを辿って行くと、フォントキャッ
シュＲＡＭ８に登録されている同一コードのフォントを
次々と探し出すことが出来ると共に、ヒットの順番が分
かる。同一コードのフォントは、これらのポインタを介
して鎖状につながれていると見ることが出来るから、言
わば「検索チェーン」が形成される。最新にヒットした
ものが、その検索チェーンの先頭に位置することにな
る。

【００１８】〔検索チェーン〕図１０は、検索チェーン
を説明する図である。符号は図８のものに対応し、Ｒ₄
〜Ｒ₇ は、同じフォントコード（Ａという文字のフォン
トコードと仮定する）ではあるが、フォント種の違うレ
コードを表している（図中の「Ａ₁ 」，「Ａ₂」，「Ａ
₃ 」，「Ａ₄ 」は、フォント種が違うことを表してい
る）。〜は、ヒットの新しさの順位（ヒット最新性
順位）を示している。のレコードＲ₄ が、最新にヒッ
トしたレコードである。

【００１９】順位のレコードＲ₅ に注目した場合、こ
れの同一コードＮＥＸＴポインタには、この後にヒット
したレコードＲ₄ の所在場所が書き込まれ、同一コード
ＢＥＦＯＲＥポインタには、その前にヒットしたレコー
ドＲ₆ の所在場所が書き込まれている。

【００２０】〔動作〕次に、以上のように構成したフォ
ントキャッシュシステム装置の制御動作を、図１１のフ
ローチャートによって説明する。 ステップ１…ホストコンピュータ１３から印字すべき文
字コード（フォントコード）を受け取ると、フォント検
索テーブル８−１内の該文字コードに対応して定められ
ているテーブル区画欄を調べることにより、その文字コ
ードのフォントがキャッシュエリア８−２に登録されて
いるか否か調べる。もし、登録されていなければ、ステ
ップ４に進み、ハードディスク１２からアウトラインデ
ータを読み出し、その後ビットマップに変換してフォン
トキャッシュＲＡＭ８に新規登録する。

【００２１】ステップ２…登録されていた場合、そのレ
コード（使用レコード）にアクセスする。今仮に、求め
ているのは図１０（イ）のレコードＲ₆ であるとする。
また、その文字コードを「Ａ」とする。フォント検索テ
ーブル８−１内の、文字コードＡに対応して定められて
いるテーブル区画欄８０には、文字コードＡのレコード
群の内、検索チェーンの先頭（）に位置するレコード
Ｒ₄ の所在場所が書いてあるので、まずそこにアクセス
する。

【００２２】そして、アクセスしたレコードＲ₄ の図９
（イ）に示した事項（特に、属性情報）を見ることによ
り、今求めている文字のフォントのフォント種，サイズ
等と一致しているかどうか調べる。求めているものと一
致した場合、そのレコードを検索チェーンの先頭に位置
せしめる。検索チェーンの先頭に位置せしめるというこ
との意味を、図１０を参照しながら説明する。

【００２３】まず、検索チェーンの先頭（ヒット最新性
順位）とは、検索チェーンで結ばれている複数個のレ
コードの内で、次回にフォント検索テーブル８−１から
アクセスされるレコードの位置のことである。図１０の
点線矢印は、フォント検索テーブル８−１からアクセス
するレコードを指し示している。図１０（イ）では、テ
ーブル区画欄８０にはレコードＲ₄ の所在場所が書かれ
ている。

【００２４】図１１のステップ２でヒットしたレコード
が、レコードＲ₄ でなくレコードＲ₆ であるとすると、
図１０（ロ）に示すように、検索チェーンのヒット最新
性順位の位置に、レコードＲ₆ を位置せしめる。具体
的には、テーブル区画欄８０の内容を、レコードＲ₆ の
所在場所を示すように書き換える。テーブル区画欄８０
の内容は、例えば４バイト程度で表されるから、この書
き換えに要する時間は極めて短い。

【００２５】また、他のレコードのヒット最新性順位
も、レコードＲ₄ をに、レコードＲ₅ をにという具
合に変更する。そして、ヒット最新性順位の変更に伴
い、各レコード内の同一コードＮＥＸＴポインタや同一
コードＢＥＦＯＲＥポインタを、必要に応じて書き換え
る。因みに、のレコードＲ₆ の同一コードＢＥＦＯＲ
Ｅポインタは、のレコードＲ₄ の所在場所を表すよう
に書き換えられる。レコードＲ₄ ，Ｒ₅ のＮＥＸＴポイ
ンタ，ＢＥＦＯＲＥポインタも、互いにレコードＲ₄ ，
Ｒ₅ を接続するように書き換えられる。

【００２６】ステップ３…ヒットしたレコードに記して
あるヒット回数の値を、今回ヒットしたから１増加す
る。 ステップ４…求めているフォントがキャッシュエリア８
−２に存在しなかった場合（ヒットしなかった場合）、
ハードディスク１２からワークＲＡＭ６にアウトライン
データを読み出す。 ステップ５…読み出したアウトラインデータを、ビット
マップデータに変換する。

【００２７】ステップ６…変換したビットマップデータ
のデータサイズが、所定値以下か（例、２キロバイト以
下か）をチェックする。このチェックは、フォントキャ
ッシュＲＡＭ８に登録しておくかどうかを決めるための
ものである。あまりにもデータサイズが大であるもの
は、フォントキャッシュＲＡＭ８の領域を多く占めてし
まうので、登録することはしない。

【００２８】ステップ７…データサイズが所定値以下で
あれば、フォントキャッシュＲＡＭ８に登録する。 ステップ８…ヒットしたレコードのビットマップデータ
あるいは新たに展開したビットマップデータを、ページ
メモリ９に転送する。このビットマップデータが、プリ
ンタエンジン１４での印字に使用される。

【００２９】なお、このようなフォントキャッシュシス
テム装置に関する従来の文献としては、例えば、特開昭
61-63884号公報，特開昭64-88660号公報がある。

【００３０】

【発明が解決しようとする課題】

（問題点）前記した従来のフォントキャッシュシステム
装置では、フォント検索テーブル８−１に、使用頻度の
少ない第２水準文字についても第１水準文字と同様、１
つの文字コードに対して１つづつテーブル区画欄を設け
ている。しかし、フォントの高速提供のために用意され
た貴重なフォントキャッシュＲＡＭ８の一部領域が、あ
まり活用されないまま、使用頻度の少ない文字のために
占有されているのは、メモリの有効活用の観点から見て
好ましくないという問題点があった。

【００３１】（問題点の説明）図２は、従来のフォント
キャッシュシステム装置におけるフォントキャッシュＲ
ＡＭの構成を示す図（図８のフォント検索テーブル８−
１を詳細に描いたもの）であり、符号は図８のものに対
応している。００００Ｈ，０００１Ｈ等は、１６進法で
表した文字コードであり、フォント検索テーブル８−１
には、それら文字コードに対して１つづつテーブル区画
欄が設けてある。テーブル区画欄は、例えば４バイトか
ら成っている。そこには、その文字コードのフォントデ
ータが格納されているところのキャッシュエリア８−２
内の領域（つまり、使用レコード）の先頭アドレス（ポ
インタ）が書き込まれる。

【００３２】図２では、文字コード０１１０Ｈのテーブ
ル区画欄には「Ｐ」と書き込まれているが、このＰは、
文字コード０１１０Ｈのフォントデータが格納されてい
る使用レコード８１のポインタＰを表している。もし、
文字コード０００１Ｈの文字が使用されなかった場合に
は、キャッシュエリア８−２にその文字のフォントデー
タが格納されることはないから、文字コード０００１Ｈ
のテーブル区画欄には、キャッシュエリア８−２内のど
こかの領域を指すポインタは書き込まれない。

【００３３】図２で、Ｃ₁ は第１水準文字を表し、Ｃ₂
は第２水準文字を表している。従来は、両方の水準の文
字全てについてテーブル区画欄を設けているが、第２水
準文字の使用頻度は少ないので（尤も、頻度の少ない文
字を第２水準文字と決めてあるわけであるが）、それら
に対応するテーブル区画欄には、殆どポインタが書き込
まれない。従って、第２水準文字のテーブル区画欄は、
あまり活用されないままキャッシュエリア８−２内の貴
重なメモリを占有し続けており、メモリの効率的な使用
を妨げている。本発明は、このような問題点を解決する
ことを課題とするものである。

【００３４】

【課題を解決するための手段】前記課題を解決するた
め、本発明では、フォントのアウトラインデータより作
成したビットマップデータを登録するフォントキャッシ
ュメモリを有し、要求されたフォントがフォントキャッ
シュメモリにある場合はそれを取り出して使用し、無い
場合はアウトラインデータを読み出して作成したビット
マップデータを使用するフォントキャッシュシステム装
置において、フォントキャッシュメモリのフォント検索
テーブルに、使用頻度大の文字の文字コードに対しては
個別に専用のテーブル区画欄を設けるが、使用頻度小の
文字の文字コードに対しては、複数個の文字コードから
成る文字コード群の１つにつき１つのテーブル区画欄し
か設けず、これを共用することとした。

【００３５】また、上記のようにすると共に、文字コー
ド群に属する文字のフォントデータがキャッシュエリア
に登録された場合には、キャッシュエリア内に該文字コ
ード群の検索テーブル用領域を確保し、該検索テーブル
用領域に該文字コード群の各文字コードに対して個別に
専用のテーブル区画欄を設けることとしてもよい。

【００３６】

【作 用】ビットマップデータを格納するフォントキ
ャッシュメモリを利用したフォントキャッシュシステム
装置では、フォントキャッシュメモリ内に、ビットマッ
プデータを格納するキャッシュエリアと、その格納位置
を示すフォント検索テーブルとが形成されているが、本
発明では、フォント検索テーブルに使用するメモリ量を
少なくして、キャッシュエリアとして使えるメモリ量を
広くする。

【００３７】即ち、フォント検索テーブルを構成するに
際し、第１水準文字のように使用頻度が大の文字の文字
コードに対しては、従来と同様、個別に専用のテーブル
区画欄を設ける。しかし、第２水準文字のように使用頻
度が小の文字の文字コードに対しては個別に設けず、幾
つかの文字コードに対して１つのテーブル区画欄を設け
る。そして、それを共用させる。これにより、フォント
検索テーブルを、従来より少ないメモリ量で構成でき
る。

【００３８】ビットマップデータを格納する領域である
キャッシュエリアを広くすれば、キャッシュできるフォ
ント数が多くなり、フォントデータをより一層高速に提
供することが可能となる。

【００３９】

【実施例】

（第１の実施例）以下、本発明の実施例を図面に基づい
て詳細に説明する。図１は、本発明の第１の実施例にお
けるフォントキャッシュＲＡＭの構成を示す図である。
符号は、図２のものに対応している。本発明では、使用
頻度の少ない文字の文字コードに対しては、フォント検
索テーブル８−１に１つづつテーブル区画欄を設けるこ
とはせず、幾つかの文字コードを１つのグループとし、
そのグループに対して１つのテーブル区画欄を設ける。

【００４０】図１の例では、第２水準文字Ｃ₂ において
は、５０００Ｈ〜５０ＦＦＨの範囲の文字コードに対し
て１つ、５１００Ｈ〜５１ＦＦＨの範囲の文字コードに
対して１つというように、２５６個の文字コードに対し
て１つのテーブル区画欄を設けている。即ち、第２水準
文字に対しては、フォント検索テーブル８−１に使うメ
モリ量を２５６分の１にする。

【００４１】文字コード５０００Ｈ〜５０ＦＦＨの範囲
の文字のフォントが使用され、そのフォントデータがキ
ャッシュエリア８−２に格納された時には、その格納領
域８１の先頭アドレス（ポインタ）Ｑが、５０００Ｈ〜
５０ＦＦＨのテーブル区画欄に書き込まれる。この格納
されたフォントデータを後に使用する時の検索動作は、
従来と同様である。即ち、まず、フォント検索テーブル
８−１における自己の文字コードに対応するテーブル区
画欄であるところの、５０００Ｈ〜５０ＦＦＨのテーブ
ル区画欄を見る。そこに書かれているポインタＱを見
て、キャッシュエリア８−２の領域の内、アドレスＱか
ら始まる領域にアクセスして、探し求めていたフォント
データを得る。

【００４２】第１の実施例によると、使用頻度の少ない
文字の文字コードに対しては、個別にテーブル区画欄を
設けることはせず、幾つかの文字コードに対して１つと
いうことにしたので、フォントキャッシュＲＡＭ８内で
テーブル区画欄に費やすメモリ領域が少なくなる。因み
に、図１に示したように、第２水準文字については２５
６個の文字コードに対して１個のテーブル区画欄を設け
ることとした場合、１７５．３Ｋバイト削減することが
出来る。

【００４３】フォント検索テーブル８−１に費やすメモ
リ領域が少なくなった分だけ、キャッシュエリア８−２
の領域を増やすことが出来るが、そうすると、キャッシ
ュできるフォントデータの数が多くなるので、フォント
データの高速提供が、より一層促進される。なお、上例
では、第２水準文字全体を全てグループ分けしている
が、第２水準文字の中でも比較的使用頻度の大な文字コ
ードに対しては１つのテーブル区画欄を設け、残りの文
字コードをグループ分けするという具合にしてもよい。

【００４４】（第２の実施例）図３は、本発明の第２の
実施例におけるフォントキャッシュＲＡＭの構成を示す
図である。符号は図１のものに対応し、８３は検索テー
ブル用領域、８４はテーブル区画欄、８５，８６はレコ
ード領域、Ｍ，Ｒはポインタである。第１の実施例と相
違する点は、フォント検索テーブル８−１の１つのテー
ブル区画欄に対応させられた文字コード群の文字がキャ
ッシュエリア８−２に格納された時には、該テーブル区
画欄に対応させてキャッシュエリア８−２内に検索テー
ブル用領域８３を設け、そこに前記格納された文字のテ
ーブル区画欄８４を設けた点である。

【００４５】例えば、文字コード５０００Ｈ〜５０ＦＦ
Ｈの範囲の文字が初めて使用され、そのフォントデータ
がキャッシュエリア８−２のレコード領域８５に格納さ
れたとする。この時には、５０００Ｈ〜５０ＦＦＨの範
囲の文字コードに対する検索テーブル用領域８３を、キ
ャッシュエリア８−２内に確保する。確保した検索テー
ブル用領域８３のポインタをＲとすれば、このＲが、図
３に示すように、フォント検索テーブル８−１の５００
０Ｈ〜５０ＦＦＨに対応するテーブル区画欄に書き込ま
れる。確保した検索テーブル用領域８３には、１つの文
字コードにつき１つのテーブル区画欄８４を設け、そこ
にフォントデータを格納したレコード領域８５のポイン
タＳを書き込む。

【００４６】図４に、検索テーブル用領域の構成を示
す。符号は、図３のものに対応している。ここでは、文
字コードが５０００Ｈ〜５０ＦＦＨの範囲のものに対す
る検索テーブル用領域８３を示している。検索テーブル
用領域８３は、検索テーブルフラグ，検索テーブルサイ
ズ，使用テーブル数およびテーブル区画欄８４から成っ
ている。

【００４７】検索テーブルフラグは、検索テーブル用領
域８３が、フォントデータを格納するのに用いられてい
る領域ではないことを示している。そのフラグ値として
は、例えば０ＦＦＦＦＦＦＦＦＨを用いる。これは、キ
ャッシュエリア８−２内にフォントデータを次々と登録
する場合、暫く使用されていないフォントデータは削除
してしまうことが行われているが、その場合に、検索テ
ーブル用領域８３が、それらと同様の領域として扱われ
て、削除されてしまうのを防止するためである。

【００４８】検索テーブルサイズは、この検索テーブル
用領域８３のサイズを示し、使用テーブル数は、ポイン
タが書き入れられているテーブル区画欄８４の数（空で
ない数）を示している。テーブル区画欄８４は、フォン
ト検索テーブル８−１のテーブル区画欄と同じく、フォ
ントデータが格納されているメモリ領域のポインタが書
き込まれる。図４で文字コード５００１Ｈのテーブル区
画欄８４に記されている「Ｓ」は、その文字のフォント
データが格納されているレコード領域８５（図３参照）
のポインタである。

【００４９】ところで、一度使用されたものの、暫く使
用されないフォントデータはキャッシュエリア８−２か
ら削除されるが、その時、対応するテーブル区画欄８４
に書かれているポインタ（Ｓ）も削除される。検索テー
ブル用領域８３内の、どのテーブル区画欄にもポインタ
が記載されていないという状態になった時には、この検
索テーブル用領域８３自体が削除される。そして、その
領域は、フォントデータの格納用等、任意に使用され
る。

【００５０】図５は、第２の実施例のフォントキャッシ
ュシステム装置における動作を説明するフローチャート
である。 ステップ１…ホストコンピュータ（図７参照）から印字
するよう要求された文字が第１水準文字か否か調べる。 ステップ２…第２水準文字であると、フォント検索テー
ブル８−１内の該文字コードに対応するテーブル区画欄
を探す。テーブル区画欄は、５０００Ｈ〜５０ＦＦＨに
対して１個というように、２５６個の文字コードからな
るグループに対して１つしか設けられていないから、文
字コードの上位２バイト（例えば、５０００Ｈ〜５０Ｆ
ＦＨに属するものの場合には、「５０」）を手掛かり
に、対応するテーブル区画欄を探す。そして、そこに書
かれている値（図３の「Ｒ」）を読みだす。

【００５１】ステップ３…読みだした値が、キャッシュ
エリア８−２の領域を指す値かどうか調べる。フォント
データが格納されていない場合には、キャッシュエリア
８−２の領域を指さない所定値（例、ＦＦＦＦＦＦＦＦ
Ｈ）を書き込んでおくと、決めてある場合があるからで
ある。 ステップ４…キャッシュエリア８−２の領域を指す値
（Ｒ）であれば、その値を先頭アドレスとする検索テー
ブル用領域８３にアクセスする。

【００５２】ステップ５…検索テーブル用領域８３内の
テーブル区画欄の内、要求している文字コード（例、５
００１Ｈ）のテーブル区画欄８４にポインタ値が書かれ
ているか調べる。書かれていればステップ７に進み、そ
のポインタ値（Ｓ）で指示されるレコード領域８５にア
クセスする。書かれていなければ、フォントデータはキ
ャッシュされていないということであるから、ステップ
９に進み、ハードディスク１２（図７参照）よりアウト
ラインデータを読みだす。

【００５３】ステップ６…ステップ１で、要求されてい
る文字が第１水準文字である時には、フォント検索テー
ブル８−１の該当するテーブル区画欄に、ポインタ値が
記されているか調べる。 ステップ７…第１水準文字の場合でも第２水準文字の場
合でも、ポインタ値が記されている時には、それで指示
されるキャッシュエリア８−２のレコード領域にアクセ
スする。そこには、探していた文字の文字コードのフォ
ントデータが格納されている。しかし、同じ文字コード
であっても、フォントの種類（ゴシック体，明朝体等）
とか、文字のサイズとかが、今要求されているものとは
異なることがある。その場合には、図１０で説明したチ
ェーンにつながれている仲間のフォントデータに当たっ
てみて、有るかどうか探す。

【００５４】ステップ８…求めているフォントデータが
有った場合には、探し当てたレコード（図９（イ）参
照）の「ヒット回数」を＋１する。 ステップ９…求めているフォントデータが無かった場合
には、ハードディスク１２よりアウトラインデータを読
みだす。 ステップ１０…アウトラインデータを、ビットマップデ
ータに変換する。 ステップ１１…ビットマップデータのサイズが所定値以
下かチェックする。このチェックは、フォントキャッシ
ュＲＡＭ８に格納すべきか否かを決めるために行う。フ
ォントキャッシュＲＡＭ８に、出来るだけ多数の文字を
キャッシュするために、何文字分かの領域を使用するよ
うな大きなサイズの文字は、キャッシュしないようにす
るためである。

【００５５】ステップ１２…サイズが所定値以下の時に
は、フォントキャッシュＲＡＭ８に格納（登録）する。
その登録処理ルーチンについては、図６で説明する。 ステップ１３…ビットマップデータをぺージメモリ９に
転送する。その後、プリンタエンジン１４に送り、印字
を実行する。

【００５６】図６は、第２の実施例におけるビットマッ
プデータのキャッシュへの登録処理ルーチン（図５のフ
ローチャートのステップ１２）を示すフローチャートで
ある。 ステップ１…キャッシュエリア８−２内にレコード領域
（図３では８５）を確保し、そこにビットマップデータ
を格納する。 ステップ２…格納したビットマップデータの文字は、第
２水準文字なのかどうかを調べる。それは、文字コード
の値によって調べることが出来る（例、５０００Ｈ以上
か否か）。

【００５７】ステップ３…第１水準文字であったら、フ
ォント検索テーブル８−１内の該当するテーブル区画欄
に、既にポインタ値が書かれているか調べる。 ステップ４…書かれている時は、同じ文字コードの別の
フォントが、既にキャッシュエリア８−２のどこかに格
納されているということに他ならない。この時には、そ
の文字コードのフォント仲間に加える。即ち、図１０で
説明したチェーンに組み込む処置をする。具体的には、
図９（イ）で示した「同一コードＮＥＸＴポインタ」，
「同一コードＢＩＦＯＲＥポインタ」の書き換えを行
う。 ステップ５…フォント検索テーブル８−１の該当するテ
ーブル区画欄にポインタ値が書かれていない時には、前
記レコード領域（８６）のポインタ値（Ｍ）を書き込
む。

【００５８】ステップ６…ステップ２で判断した結果、
第２水準文字であった場合には、その文字の文字コード
が属する文字コード群に対応する検索テーブル用領域８
３（図３参照）が、キャッシュエリア８−２内に設けら
れているか調べる。それは、該文字コード群に割り当て
られたフォント検索テーブル８−１におけるテーブル区
画欄に、ポインタ値が書いてあるか否かによって調べる
ことが出来る。 ステップ７…検索テーブル用領域８３が設けられていれ
ば、探している文字のテーブル区画欄８４に、既にポイ
ンタ値が書かれているか調べる。

【００５９】ステップ８…既に書かれていれば、同じ文
字コードのフォントデータが既にキャッシュされている
ということであるから、ステップ４と同様の要領で、そ
のフォント仲間に加える。 ステップ９…もし、該当する文字コードを含む文字コー
ド群に対応する検索テーブル用領域８３が設けられてい
ない場合には、それを新たに設ける。 ステップ１０…検索テーブル用領域８３内の、今回ビッ
トマップデータを格納した文字の文字コードに対応する
テーブル区画欄８４に、格納したレコード領域のポイン
タ（先頭アドレス）を書き込む。

【００６０】

【発明の効果】以上述べた如く、本発明のフォントキャ
ッシュシステム装置によれば、フォントキャッシュメモ
リ内にフォント検索テーブルを構成するに際し、第１水
準文字のように使用頻度が大の文字の文字コードに対し
ては、従来と同様、個別に専用のテーブル区画欄を設け
るが、第２水準文字のように使用頻度が小の文字の文字
コードに対しては個別に設けず、幾つかの文字コードを
１つのグループとし、そのグループに対して１つのテー
ブル区画欄を設け、それを共用させるようにした。

【００６１】これにより、フォント検索テーブルを、従
来より少ないメモリ量で構成できる。その分だけ、ビッ
トマップデータを格納する領域であるキャッシュエリア
を広く取ることが出来るので、キャッシュできるフォン
ト数が多くなり、フォントデータをより一層高速に提供
することが出来る。

【図面の簡単な説明】

【図１】 本発明の第１の実施例におけるフォントキャ
ッシュＲＡＭの構成を示す図

【図２】 従来のフォントキャッシュシステム装置にお
けるフォントキャッシュＲＡＭの構成を示す図

【図３】 本発明の第２の実施例におけるフォントキャ
ッシュＲＡＭの構成を示す図

【図４】 検索テーブル用領域の構成を示す図

【図５】 第２の実施例のフォントキャッシュシステム
装置における動作を説明するフローチャート

【図６】 第２の実施例におけるビットマップデータの
キャッシュへの登録処理ルーチンを示すフローチャート

【図７】 フォントキャッシュシステム装置の構成を示
す図

【図８】 フォントキャッシュＲＡＭの全体構成を説明
する図

【図９】 使用レコードおよび空きレコードの構成を説
明する図

【図１０】 検索チェーンを説明する図

【図１１】 従来のフォントキャッシュシステム装置に
おける動作を説明するフローチャート

【符号の説明】

１…フォントキャッシュシステム装置、２…ＣＰＵ、３
…アドレスバス、４…データバス、５…ＲＯＭ、６…ワ
ークＲＡＭ、７…インタフェース、８…フォントキャッ
シュＲＡＭ、８−１…フォント検索テーブル、８−２…
キャッシュエリア、９…ページメモリ、１０…ＤＭＡコ
ントローラ、１１…ＳＣＳＩコントローラ、１２…ハー
ドディスク、１３…ホストコンピュータ、１４…プリン
タエンジン、１７…インタフェース、８０…テーブル区
画欄、８１…使用レコード、８２…空きレコード、８３
…検索テーブル用領域、８４…テーブル区画欄、８５，
８６…レコード領域、ＣＰ…新規登録ポインタ、Ｒ₁ 〜
Ｒ₆ …レコード

Claims (2)

【特許請求の範囲】
1. 【請求項１】 フォントのアウトラインデータより作成
   したビットマップデータを登録するフォントキャッシュ
   メモリを有し、要求されたフォントがフォントキャッシ
   ュメモリにある場合はそれを取り出して使用し、無い場
   合はアウトラインデータを読み出して作成したビットマ
   ップデータを使用するフォントキャッシュシステム装置
   において、フォントキャッシュメモリのフォント検索テ
   ーブルに、使用頻度大の文字の文字コードに対しては個
   別に専用のテーブル区画欄を設けるが、使用頻度小の文
   字の文字コードに対しては、複数個の文字コードから成
   る文字コード群の１つにつき１つのテーブル区画欄しか
   設けず、これを共用するようにしたことを特徴とするフ
   ォントキャッシュシステム装置。
2. 【請求項２】 フォントのアウトラインデータより作成
   したビットマップデータを登録するフォントキャッシュ
   メモリを有し、要求されたフォントがフォントキャッシ
   ュメモリにある場合はそれを取り出して使用し、無い場
   合はアウトラインデータを読み出して作成したビットマ
   ップデータを使用するフォントキャッシュシステム装置
   において、フォントキャッシュメモリのフォント検索テ
   ーブルに、使用頻度大の文字の文字コードに対しては個
   別に専用のテーブル区画欄を設けるが、使用頻度小の文
   字の文字コードに対しては、複数個の文字コードから成
   る文字コード群の１つにつき１つのテーブル区画欄しか
   設けず、これを共用すると共に、文字コード群に属する
   文字のフォントデータがキャッシュエリアに登録された
   場合には、キャッシュエリア内に該文字コード群の検索
   テーブル用領域を確保し、該検索テーブル用領域に該文
   字コード群の各文字コードに対して個別に専用のテーブ
   ル区画欄を設けたことを特徴とするフォントキャッシュ
   システム装置。