JPH05313640A - キャッシュメモリへのフォントデータ格納方式 - Google Patents

Abstract

(57)【要約】 【目的】 キャッシュメモリのメモリ容量を無駄に消費
することのない、キャッシュメモリへのフォントデータ
格納方式を提供すること。 【構成】 格納したいとしている最大サイズのフォント
を基にキャッシュメモリを分割したフォントデータブロ
ック（１）を、更に幾つかのフォントデータサブブロッ
ク（２）に分割する。そして、フォントをキャッシュメ
モリに格納するに当たっては、そのフォントのサイズを
考慮し、フォントデータサブブロックを所要数使用して
格納する。これにより、無駄に消費されるメモリが少な
くなる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、文字フォントのビット
マップデータを一時的に格納しておくフォントキャッシ
ュメモリに関するものである。

【０００２】

【従来の技術】ホストコンピュータから文字信号を受
け、その文字をビットマップデータの形でページバッフ
ァに展開し、それを表示装置に表示したり、印字装置で
プリントアウトする装置がある。そのような装置におい
ては、使用頻度の高いフォントのビットマップデータ
を、一時的に格納しておくフォントキャッシュメモリを
具えたものがある。

【０００３】図３は、前記のような装置の一例としての
プリンタの構成を示す図である。図３において、１０は
プリンタ制御部、１１はアウトラインフォントデータ格
納部、１２は解釈部、１３はキャッシュメモリ制御部、
１４はキャッシュメモリ、１５は中間バッファ、１６は
描画部、１７はページバッファ、１８はコントロールパ
ネル、１９は画像記録部である。画像記録部１９は、こ
の場合プリンタである。

【０００４】印字しようとする文字の信号が、ホストコ
ンピュータ等から解釈部１２へ送られて来る。文字の信
号とは、例えばどういう文字かを表す文字コードとか、
文字の大きさ（文字の高さ，幅）等に関する信号であ
る。解釈部１２は、その信号を解釈して、まず、その文
字がキャッシュメモリ１４に有るか探し、有ればそこか
ら取り出して、ページバッファ１７に送る。

【０００５】もし無ければ、アウトラインフォントデー
タ格納部１１から、その文字のアウトラインフォントデ
ータを取り出し、描画部１６でビットマップデータのフ
ォントに描画し、それをページバッファ１７に送る。同
時に、キャッシュメモリ１４にも送って格納し、次に使
用する時のために備える。

【０００６】ページバッファ１７に１ページ分の文字が
展開されれば、そのページ分のデータが画像記録部１９
へ送られ、印刷される。なお、中間バッファ１５は、解
釈部１２からの信号を、タイミング調整等のために一時
的に格納するためのものである。また、コントロールパ
ネル１８は、操作者が種々の指令をするためのものであ
る。

【０００７】ところで、キャッシュメモリ１４は、フォ
ントのビットマップデータを格納するわけであるが、１
つのフォントを格納するための区画（これを、「フォン
トデータブロック」という）の大きさは、予め定めてお
く。フォントデータブロックの大きさは、キャッシュメ
モリ１４にキャッシュしようと思っている最大サイズの
文字を、コントロールパネル１８から指定しておくこと
によって定められる。

【０００８】例えば、最大１２ポイントまでの文字をキ
ャッシュしたいというのであれば、コントロールパネル
１８より、「１２ポイント」と入力する。文字ポイント
数が指定されれば、フォントデータブロック１の大き
さ、つまりデータ量は、次のようにして決定される。 フォントデータブロック１のデータ量＝（Ｄ＋７）÷８
×Ｄ 但し、Ｄはドット数であり、指定されたポイント数Ｐと
表示時（または印刷時）の解像度Ｋとより Ｄ＝Ｐ×Ｋ÷７２ で求められる。

【０００９】図２は、従来のフォントデータ格納方式を
説明する図である。１はフォントデータブロック、１−
１はデータ格納方向を示す線、１−２は所要メモリ容量
を示す線である（１−１，１−２の線は、従来の問題点
を説明するためのものであるので、ここでは格別注意す
る必要はない）。

【００１０】図２（イ）は、Ａという文字のビットマッ
プデータを表している。このＡは、フォントデータブロ
ック１全体をフルに使ったサイズの文字である。図２
（ロ），（ハ）のＫ，Ｈは、その半分程度のサイズの文
字である。従来は、文字のサイズにかかわらず、１つの
文字は、１つのフォントデータブロック１に格納されて
いた。

【００１１】

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

（問題点）しかしながら、前記した従来のキャッシュメ
モリへのフォントデータ格納方式では、格納するフォン
トのサイズにかかわらず、１つのフォントに対しては１
つのフォントデータブロックを使って格納するので、メ
モリを無駄に消費するという問題点があった。

【００１２】（問題点の説明）図２において、フォント
データブロック１にフォントデータを格納する場合、デ
ータ格納方向を示す線１−１の方向に、１ドットづつの
データが順次格納される。その結果、ＡとかＫとかＨ等
のフォントが格納されることになる。

【００１３】図２（イ）の場合は、Ａという文字のサイ
ズが大きく、フォントデータブロック１をフルに使わな
ければ格納できない。しかし、図２（ロ）や（ハ）のよ
うに、フォントデータブロック１のサイズに比べて小さ
なサイズのフォント（Ｋ，Ｈ）を格納する場合、フォン
トデータブロック１をフルに使わなくとも、格納でき
る。即ち、ＫなりＨなりの全容を構成するドットが格納
された後の位置を表す線１−２までのメモリで、Ｋなり
Ｈなりのフォントデータは、格納できてしまう。つま
り、線１−２は、このサイズのＫなりＨなりを格納する
際の、所要メモリ容量を表す線ということになる。

【００１４】従って、所要メモリ容量を示す線１−２よ
り下方にある部分のメモリは、実質的には使われずじま
いになっており、結局、この部分は無駄に消費されてい
ることになる。本発明は、以上のような問題点を解決す
ることを課題とするものである。

【００１５】

【課題を解決するための手段】前記課題を解決するた
め、本発明のキャッシュメモリへのフォントデータ格納
方式では、指定された最大文字サイズにより定まるデー
タサイズのフォントデータブロックにキャッシュメモリ
を分割し、該フォントデータブロックを更に複数個のフ
ォントデータサブブロックに分割し、該フォントデータ
サブブロックを単位にしてフォントデータを格納するこ
ととした。

【００１６】

【作 用】格納したいとしている最大サイズのフォン
トを基にキャッシュメモリを分割したフォントデータブ
ロックを、更に幾つかのフォントデータサブブロックに
分割する。そして、フォントをキャッシュメモリに格納
するに当たっては、そのフォントのサイズを考慮して、
フォントデータサブブロックを所要数使用して格納す
る。これにより、無駄に消費されるメモリを少なくする
ことが可能となる。

【００１７】

【実施例】以下、本発明の実施例を図面に基づいて詳細
に説明する。図１は、本発明のフォントデータ格納方式
を説明する図である。符号は、図２のものに対応し、２
はフォントデータサブブロックである。

【００１８】本発明では、キャッシュメモリにキャッシ
ュしようとしている最大サイズの文字ポイント数より定
めたフォントデータブロック１を、更に幾つかに分割し
て、フォントデータサブブロック２とする。そして、フ
ォントを格納するに際しては、フォントデータサブブロ
ック２を単位として格納する。

【００１９】即ち、１つのフォントデータサブブロック
２で格納し得るサイズのフォントの場合は、１つのフォ
ントデータサブブロック２を使用して格納する。フォン
トのサイズが大きく、１つのフォントデータサブブロッ
ク２では格納し得ない場合には、必要な数のフォントデ
ータサブブロック２を使用して格納する。

【００２０】図１では、フォントデータブロック１を２
分割したものを、フォントデータサブブロック２とした
例を示している。もっと細かく分割することも可能であ
る（例えば、４分割，８分割等）。図１（イ）のＡは、
サイズが大きくて１つのフォントデータサブブロック２
では格納できないので、連続する２つのフォントデータ
サブブロック２を使用して格納されている。

【００２１】図１（ロ）では、Ｋ，Ｈのサイズが小さ
く、それぞれ１つのフォントデータサブブロック２で格
納し得るサイズなので、１つのフォントデータサブブロ
ック２に格納されている。従って、図２と同じＡ，Ｋ，
Ｈのフォントを格納する場合、本発明では、フォントデ
ータブロック１が２つで済み、従来３つ必要としていた
のに比べて、１個節約できる。即ち、無駄に消費される
メモリが、少なくなる。

【００２２】本発明のキャッシュメモリへのフォントデ
ータ格納方式も、それを実行するためのハード的な構成
は、図３に示されるものと同様である。ただ、キャッシ
ュメモリ制御部１３で行われる格納動作が、従来と異な
ることになる。

【００２３】図４は、本発明の動作を説明するフローチ
ャートである。 ステップ１…まず、ビットマップフォントのデータサイ
ズを求める。即ち、ホストコンピュータから、図３の解
釈部１２に送られて来る文字の信号より、その文字サイ
ズがどのようなサイズ（高さ，幅）なのかを求める。こ
れにより、この文字を格納するのには、メモリ容量にし
て何バイト必要なのかが分かる。

【００２４】ステップ２…その文字のサイズが、キャッ
シュメモリに格納できる最大サイズ以下かどうかチェッ
クする。なお、最大サイズとは、図１のフォントデータ
ブロック１のサイズのことである。これは、従来技術の
項で説明したように、格納しようとしている最大文字の
ポイント数を、図３のコントロールパネル１８から指定
することによって算出される。

【００２５】もし、最大サイズより大であれば、これ
は、もはやキャッシュメモリには関係ない問題であるか
ら、エンドに進む。そのような文字は、図３のアウトラ
インフォントデータ格納部１１より、対応するアウトラ
インフォントデータを取り出し、描画部１６で描画した
後、ページバッファ１７に送られて使用に供されるが、
キャッシュメモリに格納されることなく、消去される。

【００２６】ステップ３…最大サイズ以下であれば、フ
ォントデータサブブロック２を幾つ使用すれば格納でき
るサイズかを算出する。図１の例は、フォントデータサ
ブブロック２は、フォントデータブロック１を２分割し
たものであるから、この例における算出結果は、１個
か、それとも２個である。

【００２７】ステップ４…図１（ロ）のように、１つの
フォントデータサブブロック２で収容できる文字を格納
する場合は、どの空きフォントデータサブブロック２を
使用しても差支えない。しかし、図１（イ）のように、
２個のフォントデータサブブロック２を用いなければ収
容できない文字を格納する場合は、連続した空きフォン
トデータサブブロック２が必要である。つまり、格納に
適する条件（ここでは「連続している」という条件）
で、所要数の空きフォントデータサブブロック２がある
かどうかを探す必要がある。空いているものが有れば、
それに格納すべく、ステップ７に進む。

【００２８】ステップ５…空きブロックが無かった場合
には、どれかのブロックの内容を削除して、そこへ格納
せざるを得ない。そのために、まず削除するブロック
を、一定のやり方に則って探す。このようなことは、キ
ャッシュメモリを管理する上での処理の１つである「あ
ふれ処理」と言われるものに属する。

【００２９】内容を削除するブロックの決め方には、種
々のものがある。その内の１つに、参照された（前回ヒ
ットした）のが最も古いものから順に削除するというや
り方（ＬＲＵアルゴリズム、ＬＲＵ：Least Recently U
sed １番昔に使った）がある。

【００３０】図５は、キャッシュメモリの管理を説明す
る図である。符号は図１のものに対応し、１４はキャッ
シュメモリ、２０はフォントデータブロック管理テーブ
ルである。キャッシュメモリ１４は、まずフォントデー
タブロック１に分けられ、その中を幾つかの（この場
合、２つの）フォントデータサブブロック２に分けられ
る。

【００３１】フォントデータブロック管理テーブル２０
は、キャッシュメモリ１４の使用状況を管理する上での
情報を格納しているテーブルである。このテーブルの
「ＬＲＵ最終ブロック」という欄には、最も昔に参照し
た（ヒットした）フォントデータブロック１を指し示す
ポインタが記されている（図５で、「ＬＲＵ最終ブロッ
ク」から出ている矢印で示されるフォントデータブロッ
クが、ポインタで指し示されるフォントデータブロック
を意味している）。従って、ＬＲＵアルゴリズムに則っ
てあふれ処理をする場合には、このポインタで指示され
るフォントデータブロック１が削除され、ここに新しい
フォントデータが格納されることになる。

【００３２】ステップ６…削除すべきだとして探し出し
たフォントデータブロック１の情報を、全て削除する。
即ち、フォントデータブロック１を構成している全ての
フォントデータサブブロック２の情報を削除する。

【００３３】ステップ７…そのフォントデータブロック
１内のフォントデータサブブロック２に、今度新しく格
納しようとしているビットマップフォントデータを、格
納する。格納しようとしているフォントのサイズが、１
つのフォントデータサブブロック２で済むサイズならば
１つを使い、複数のフォントデータサブブロック２を使
わなければならないサイズならば複数使う（図１の場合
では、２個）。これで、キャッシュ動作は完了する。以
上が、本発明のキャッシュメモリへのフォントデータ格
納方式の動作である。

【００３４】なお、フォントデータブロックを幾つのフ
ォントデータサブブロックに分割するかは、適宜決定で
きることである。ただ、細かく分割するほど、無駄に消
費されるメモリは少なくなるが、どのフォントデータサ
ブブロックは使用済みでどのフォントデータサブブロッ
クは空きであるというようなフォントデータサブブロッ
クの管理は面倒になる。従って、分割数は、これらのメ
リット，デメリットを総合的に勘案して決められる。

【００３５】

【発明の効果】以上述べた如く、本発明のキャッシュメ
モリへのフォントデータ格納方式によれば、格納したい
としている最大サイズのフォントを基にキャッシュメモ
リを分割したフォントデータブロックを、更に幾つかの
フォントデータサブブロックに分割する。そして、フォ
ントをキャッシュメモリに格納するに当たっては、フォ
ントのサイズを考慮して、所要数のフォントデータサブ
ブロックを使用して格納することとしたので、無駄に消
費されるメモリが少なくなった。

【図面の簡単な説明】

【図１】 本発明のフォントデータ格納方式を説明する
図

【図２】 従来のフォントデータ格納方式を説明する図

【図３】 キャッシュメモリを具えたプリンタの構成を
示す図

【図４】 本発明の動作を説明するフローチャート

【図５】 キャッシュメモリの管理を説明する図

【符号の説明】

１…フォントデータブロック、２…フォントデータサブ
ブロック、１−１…データ格納方向を示す線、１−２…
所要メモリ容量を示す線、１０…プリンタ制御部、１１
…アウトラインフォントデータ格納部、１２…解釈部、
１３…キャッシュメモリ制御部、１４…キャッシュメモ
リ、１５…中間バッファ、１６…描画部、１７…ページ
バッファ、１８…コントロールパネル、１９…画像記録
部、２０…フォントデータブロック管理テーブル

Claims (1)

【特許請求の範囲】
1. 【請求項１】 指定された最大文字サイズにより定まる
   データサイズのフォントデータブロックにキャッシュメ
   モリを分割し、該フォントデータブロックを更に複数個
   のフォントデータサブブロックに分割し、該フォントデ
   ータサブブロックを単位にしてフォントデータを格納す
   ることを特徴とするキャッシュメモリへのフォントデー
   タ格納方式。