JPH0272975A - フォントファイル管理方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野） 本光明は、入力したイメージデータとフォントファイル
を合成加工して出力するイメージ処理装置のフォントフ
ァイル管理方法に関する。

〔従来の技術〕

従来、この種の装置では、第５図に示すように、ＣＰＵ
　１０は画像入力部１１から入力したイメージデータを
、イメージメモリ１２のイメージ領域に蓄積すると共に
、ハードディスク等の補助記憶装置１３から読み取った
フォントファイルを、イメージメモリ１２のフォント領
域の所定アドレス空間にシーケンシャルにロードして蓄
積する。そして、上記イメージメモリ１２にＮ８！ｉさ
れたイメージとフォントをメモリ内で合成・加工し、画
像出力部１４によって出力させていた。

（Ｒ明が解決しようとする課題〕 ところが、上記装置では、第６図（ａ）、（ｂ）、（Ｃ
）に示すように、複数のファイルをオーブンにしたり、
クローズにしたりする際、第６図（Ｃ）に示すように、
イメージメモリの歯抜けが生じてメモリの使用効率を低
下させる欠点があった。また、第６図（ｄ）に示すよう
に、歯抜けによって生じた空き領域をなくすためにファ
イル３を下請めする際には、上記ファイルを１ワードづ
つ空き領域に転送しなければならないので、オーバーヘ
ッド時間を発生させるという問題点があった。

本発明は、上記問題点に２みなされたもので、イメージ
メモリの歯抜けを防止してメモリの使用効率を向上させ
ることができるフォントファイル管理方法を提供するこ
とを目的とする。

［課題を解決するための手段および作用］本発明では、
イメージデータとフォントファイルをイメージメモリ内
に展間して合成処理するイメージ処理装置に、鮪記フ４
ントファイルを所定バンク単位に分割し、前記分割され
た論理バンク内のフォントをイメージメモリ内の空き物
理バンクに展開する工程と、前記論理バンクのうち少な
くとも１つの特定論理バンク（先頭の論理バンク）に、
当該フォントファイルを展開した物理バンクを管理する
管理テーブルを格納する工程とを具える。

〔作用〕 各論理バンクごとのフォントをイメージメモリ内に展開
する際、フォントの使用バンク数を判定し、使用バンク
分のイメージメモリのフォント領域（物理バンク）を確
保し、管理テーブルに各物理バンク番号を記憶し、上記
管理テーブルを先頭論理バンクに展開して作成する。従
って、各フォントファイルは、上記管理テーブルに基づ
き管理することができ、イメージメモリの歯抜けを防止
することができる。

〔実施例〕

本発明の実施例を第１図乃至第４図の図面に基づき詳細
に説明する。

第１図は、本発明に係るイメージメモリ内の構成を示す
ブロック図である。図において、ＣＰＵ２２は、ホスト
コンピュータシステム２０との通信をホストインターフ
ェース２１を介して行い、ホスト命令を解釈し、高速な
デバイスであるハードディスク２３、イメージリーダ２
５、プリンター２７等とのハンドリングを各コントロー
ラ２４．２６．２８を介して行う。なお、イメージリー
ダ２５よって原稿等から読み取られたイメージデータは
、バッフ１メモリ３５に一旦記憶された後、後述するイ
メージメモリ２９に格納される。また、イメージメモリ
２９からバッファメモリ３６に記憶されたデータは、プ
リンター２７によってプリントアウトされる。

イメージメモリ２９は、イメージデータとフォントファ
イルを格納している。上記イメージメモリ２９のデータ
の読み／出ぎは、メモリコントローラ３０によって制御
されている。ここで用いられるフォントファイルの一例
を第２図に示す。フォントファイルは、４０９６ワード
を一単位とする分割された複数のバンク（０〜ｎ）から
構成され、０パンク目には各バンクの物理バンク番号を
示すフォントファイルの１３１テーブル、１バンク目に
はフォントコードを示すフォントコードテーブル、２バ
ンク目には上位アドレステーブル、３バンク目には下位
アドレステーブル及び４〜ｎバンク目にはフォントデー
タが配置されている。第３図は、上記０バンク目の管理
テーブルの一例を示す図で、下位アドレスＬＡ　（００
０〜ｎ）は、フォントファイルの各論理バンク番号に対
応しており、上位アドレスＵＡ（３）は、上記フォント
ファイルを最初に格納するイメージメモリの物理バンク
番号に対応している。なお、管理テーブルの下位アドレ
スＬＡ（ｎ＋１〜ＦＦＦ＞にはデータが入っていないも
のとする。また、イメージメモリは、上位１２ビツトを
バンク番号（０〜４０９５）、下位１２ピツトをバンク
内アドレス（０〜４０９５）として、４０９６Ｘ４０９
６（ワード）の空間に分割されている。なお、１ワード
は、１６ピツトで構成されている。

上位及び下位アドレスレジスタ３１．３２は、それぞれ
１２ビツト構成で、ＣＰＵバスとイメージバスとの間で
イメージメモリ２９に格納されたバンクのアドレスを順
次指定する。メモリの上位アドレス及び下位アドレスが
セットされると、上記メモリコントローラ３０は、ライ
ト時にはデータを１６ビツト楢成のライトレジスタ３３
に出き込み、上記セットされたアドレスに応じて上記ラ
イトレジスタ３３のデータをメモリ内に古き込む。

また、リード時には上記セットされたアドレスに応じて
メモリ内のデータを読み出し、１６ビツト構成のリード
レジスタ３４に格納している。また、上記メモリコント
ローラ３０は下位アドレスレジスタ３２のインクリメン
ト／デクリメントも制御している。

次に上記装置におけるフォントファイルの展開動作につ
いて第４図のフローチャートに基づき詳細に説明する。

ハードディスク２３からイメージメモリ２９への上記フ
ォントファイルの展開にｌｆｆ１して、ファイル名、例
えば″ｎａｍｅ“の入力があるとくステップ１０１）、
ＣＰＵ２２は、上記ハードディスク２３に格納されてい
るファイルの中からファイル゛’ｎａｍｅ”をオーブン
にする（ステップ１０２　）。

次に、ＣＰＵ２２は、上記ファイル”　ｎ　ａ　ｍ　ｅ
　”のヘッダーのリードを行い（ステップ１０３）、上
記ファイル゛’　ｎ　ａ　ｍ　ｅ　”の使用バンク数を
ヘッダーより判定する（ステップ１０４）。上記ファイ
ル゛’ｎａｍｅ”の使用バンク数はｎ＋１なので、ＣＰ
Ｕ２２は、ｎ＋１個分のバンクをイメージメモリ中の記
憶領域に確保し、管理テーブルを作成する（ステップ１
０５）。この時、物理バンクは、低いバンク番号のもの
から取られて確保されるが、第３図に示すように、物理
バンク番号は３．７．１０．１４、・・・　２７のよう
に番号の途中が跳んでも横わない。

次に、ＣＰＵ２２は、フ１イル”　ｎ　ａ　ｍ　ｅ　”
　ＩＩ）０からｎまでの論理バンクを、確保したイメー
ジメモリの物理バンク中にロードしていくが、まず、論
理バンクのバンク番号ｉを初期値Ｏとしくステップ１０
６）、論理バンクＯのデータをハードディスク２３から
イメージメモリ２９へ１バンク分展開する（ステップ１
０７）。これにより、上記論理バンク○のデータは、イ
メージメモリの物理バンク３に出き込まれる。続いて、
ＣＰＵ２２は、バンク番号１ｔｆｉｎバンク目かどうか
判断する（ステップ１０８）。

ここで、バンク番号がｎバンク目でない場合には、論理
バンクのバンク番号ｉに１を加えて（ステップ１０９）
、次のバンクのデータをイメージメモリ２９へ１バンク
分展開する。このように以後の論理バンクのデータをイ
メージメモリの物理バンク７．１０．１４、・・・　２
７に展開し、ステップ１０８で論理バンクのバンク番号
がｎバンク目になった場合には、論理バンクＯに論理バ
ンク番号から物理バンク番号への変換テーブルを肉き込
む（ステップ１１０）。このｉｔ　３１バンク０は、各
物理バンクのバンク番号を示すフォントファイルの管理
テーブルとなる。この例では、ｉ番目の論理バンクのデ
ータを出き込んだ、物理バンクのバンク番号の入ってい
るアドレスｒＭ　［ＵＡ。

ＬＡ］は、ＩＭ［３，ｉ］となる。そして、上記論理バ
ンクＯに変換テーブルの出き込みが終了すると、″ｎ　
ａ　ｍ　ｅ　”のファイルをクローズして（ステップ１
１１）、上記動作を終了する。

従って、本発明では、所定バンク単位に分υＪしたフォ
ントファイルを、イメージメモリ内の空き領域である物
理バンクに展開し、上記物理バンクの管理を管理テーブ
ルによって行うことができるので、イメージメモリ内の
歯抜けを防止することができる。

なお、実施例では、管理テーブルは、論理バンク番号か
ら物理バンク番号への変換テーブルによって構成したが
、本発明はこれのみに限らず、上記変換テーブルの他に
例えばサムチエツク用のテーブル等を含めることも可能
である。また、実施例では、フォント数が４０９６文字
以内の場合について説明したが、本発明では、上記フォ
ント数が４０９６文字を越える場合にも応用でき、この
場合には、４０９６文字毎にフォントコード／上位アド
レス／下位アドレステーブルのセットを１つ、すなわち
３バンクづつ増加させればよい。

〔発明の効果］ 以上説明したように、本光明では、所定領域単位に分割
したフォントファイルを、イメージメモリ内の空き領域
に展開し、当該フォントファイルを展開したイメージメ
モリ内の領域を情理テーブルによって管理するようにし
たので、イメージメモリの歯抜けを防止してメモリの使
用効率を向上さゼることかできる。

トコンピュータシステム、２５・・・イメージリーダ、
２７・・・プリンター、３０・・・メモリコントローラ
、３１・・・上位アドレスレジスタ、３２・・・下位ア
ドレスレジスタ、３３・・・ライトレジスタ、３４・・
・り一ドレジスタ。

４、図面のＩｔ！Ｉｌｌな説明 第１図は本発明に係るイメージ！２！を浬装置の構成を
示すブロック図、第２図は本発明に係るフォントファイ
ルとイメージメモリの一実施例を示す概念図、第３図は
同じく管理テーブルの一実施例を示す概念図、第４図は
フォントファイルの展開動作を説明するためのフローチ
セートを示す図、第５図は従来のイメージ処理装置の概
略構成を示すブロック図、第６図は従来のイメージメモ
リのフ１イル格納状態を示す概念図である。

１０．２２・・・ＣＰＵ、１２．２９・・・イメージメ
モリ、１３．２３・・・ハードディスク、２０・・・ホ
ス第３図 （Ｇ） （ｂ） （Ｃ） 第６図 （ｄ）

Claims (1)

1. 【特許請求の範囲】 イメージデータとフォントファイルをイメージメモリ内
   に展開して合成処理するイメージ処理装置において、 前記フォントファイルを所定領域単位に分割し、前記イ
   メージメモリ内の空き領域に展開する工程と、 前記分割した領域のうち少なくとも１つの特定領域に、
   当該フォントファイルを展開した前記イメージメモリ内
   の領域を管理する管理テーブルを格納する工程と を具え、該管理テーブルに基づき各フォントファイルの
   管理を行うことを特徴とするフォントファイル管理方法
   。