JP3116354B2

JP3116354B2 - プリンタデータ管理方式

Info

Publication number: JP3116354B2
Application number: JP01255413A
Authority: JP
Inventors: 高志森川; 郁準山口
Original assignee: ミノルタ株式会社
Priority date: 1989-09-29
Filing date: 1989-09-29
Publication date: 2000-12-11
Anticipated expiration: 2015-12-11
Also published as: JPH03114856A

Description

【発明の詳細な説明】（産業上の利用分野）本発明は、プリンタにおけるデータ管理方式に関す
る。

（従来の技術）プリンタは、ホスト（ホストコンピュータなど）より
受信した文字や図形の文書を印字する。プリンタにおけ
る文字発生装置（コントローラ）は、ホストから受信し
た文字データ、グラフィックデータ、各種コマンドなど
に基づき文字データ等をドットイメージに変換してメモ
リに記憶し、そのドットイメージを印字する。

従来は、プリンタの文字発生装置は、１枚分のビット
マップメモリを有し、ホストから受信した文字データや
グラフィックデータに基づき、１枚のドットイメージを
全てビットマップメモリ上に展開する。そして、１枚分
の展開が終了すると、ドットイメージデータを印字部に
送る。それにより、ドットマップメモリ上へのドットイ
メージの展開と印字部へのデータ送出のタイミングの違
いによる問題は生じない。

この方式では、印字部へのデータ転送の際には、出力
すべき１枚分のイメージデータがすべてビットマップメ
モリに展開されている。従って、印字部へのドットイメ
ージデータの転送は、プリンタ出力と同期をとって高速
で行われ、印字部で印字が行われる。

印字部へのデータ出力を高速に行うためには、ビット
マップメモリへのイメージ展開処理時間をできるだけ短
縮しなければならない。しかし、一般にグラフィックデ
ータの処理は、データ量が多いためデータ受信に時間が
かかり、特にベクターグラフィックデータは、コンマン
ドの解析およびイメージ展開に非常に時間がかかる。

そこで、イメージ展開に専用LSIを用いることにより
高速化を図ることが考えられるが、コストは上昇する。

一方、ソフトウエアで処理する場合には、コマンドの
解析及びイメージ展開の全ての処理を印字部への出力時
に同期して行なおうとすると、高速出力は図れない。

そこで、ホストからの受信データをビットイメージへ
展開するに際して負担をできるだけ軽減するために、い
ったん中間データに編集（変換）して中間データ保持メ
モリに記憶するなどの中間処理が行われている。

（発明が解決しようとする課題）プリンタの文字発生装置におけるイメージデータの展
開方式としては、１枚分の文書を副走査方向にｎ個（ｎ
は正の整数）のバンドに分割し、データ処理はバンド単
位で行うことが考えられる。この方式では、１枚の1/n
の記憶容量のバンドメモリ（部分的ビットマップメモ
リ）を２面分備え、一方のバンドメモリにドットイメー
ジを展開しながら、同時に、他方のバンドメモリにすで
に展開されたイメージデータを印字部に出力する。これ
をｎ個のバンドに対して２個のイメージメモリについて
交互に行なうと、１枚の文書の印字が完了する。

この方式でも、バンドメモリへのドットイメージ展開
処理が印字部へのデータ出力に先行しなければならない
ため、印字部へのデータ出力速度は、バンドメモリへの
ドットイメージ展開速度により制約される。従って、ド
ットイメージ展開を高速に行うために、ホストから受信
したデータをいったん中間データに編集（変換）してお
くとよい。この中間データは、バンドメモリに展開すべ
き文字データやグラフィックデータの情報（サイズ、ソ
ースアドレスなど）からなる。

この方式の文字発生装置においては、各バンドメモリ
に対するドットイメージ展開を高速に行う必要があるた
め、展開に要する１枚分の中間データを印字の前に作成
しておく必要があり、また、各バンドメモリに対する中
間データは、できるだけ連続的にアクセスするのが望ま
しい。このため、１枚の文書内の各バンドに対して中間
データを保持するメモリエリアを確保する必要がある。

しかし、中間データ保持メモリにおいて中間データを
保持するためのメモリエリアを各バンドに対して等分に
確保する方式では、印字データの存在位置の片寄った文
書の場合、メモリの容量によっては、印字データの多い
バンドの中間データが保持しきれない一方、印字データ
の少ないまたは無いバンドに対しては必要以上の保持エ
リアが確保されているといった状況が生じうる。また、
印字データの少ないバンドに対して必要以上の保持エリ
アを確保していくことは、メモリの使用効率を低下させ
る。従って、印字データの多いバンドには大きい保持エ
リアをその都度確保する方式がデータ管理の効率化のた
めに必要である。しかし、単純に１データごとに保持エ
リアを増加させる方式では、その保持エリアの検索に処
理時間がかかり、好ましくない。

また、バンドメモリを用いて印字を行う上記の方式で
は、複数の文書を１枚のペーパーに印字するような場合
（両面印字）やジャム復帰などにおいて、複数文書の印
字に要する時間の点から、各文書間の編集に許される時
間に対しても制限を受ける場合がある。これに対し、完
全に対応するには、必要となる複数文書分（たとえば両
面複写では２頁分）のデータ編集を印字データ出力前に
行う必要がある。従って、複数文書の中間データを管理
する必要がある。

本発明の第１の目的は、プリンタにおいて１枚の文書
を複数のバンドに分割して、ホストからの印字データを
編集処理する際に、印字データからドットイメージ展開
のために変換した中間データをメモリに効率的に保持す
るプリンタデータ管理方式を提供することである。

本発明の第２の目的は、１枚の文書を複数のバンドに
分割してホストからの印字データを編集処理する際に、
複数の文書の管理が必要な場合に、中間データを容易に
管理できるプリンタデータ管理方式を提供することであ
る。

（課題を解決するための手段）本発明に係るプリンタデータ管理方式は、１枚の文書を副走査方向に複数のバンドに分割し、少
なくとも１バンド分のメモリ容量を備えたイメージメモ
リを備え、ホストからの印字データをドットイメージデ
ータとしてイメージメモリに速く展開するために印字デ
ータを中間データに編集して中間データ保持メモリに保
持し、中間データのイメージメモリへのドットイメージ
の展開及び印字部へのデータ出力をバンドごとに行うプ
リンタにおいて、中間データへの編集において各バンドごとに中間デー
タが発生すると中間データ保持メモリにおいてまずその
バンドのデータ管理上必要な最小容量の基本ブロツクに
中間データを保持し、さらに基本ブロツクの容量を越えてそのバンドの中間
データが発生すると、ある程度の容量のデータを保持可
能な拡張ブロックを中間データ保持メモリにおいてその
バンドについて確保し、その拡張ブロックに中間データ
を保持し、中間データ保持メモリにおいて使用されているブロッ
クをバンドと対応付ける中間データ管理テーブルを設け
ることを特徴とする。

本発明に係る第２のプリンタデータ管理方式は、請求
項１に記載されたプリンタデータ管理方式において、上
記の中間データ管理テーブルを複数の文書に対応づける
ための、管理すべき各文書に対応する文書管理テーブル
をさらに設けることを特徴とする。

（作用）１枚の文書を副走査方向に複数のバンドに分割し、少
なくとも１バンド分のメモリ容量を備えたイメージメモ
リを備えるプリンタは、文書の上側のバンドから順にイ
メージメモリにドットイメージを展開して印字を行わせ
る。イメージメモリにドットイメージを速く展開するた
めにホストからの印字データを中間データ保持メモリに
展開しておく。

ドットイメージに変換するための中間データを記憶す
る中間データ保持メモリにおいて、中間データを保持す
るための基本ブロックと拡張ブロックを各バンドについ
て設ける。

ここに、基本ブロックはデータ管理上必要な最小容量
（たとえば２文字）のエリアであり、拡張ブロックはあ
る程度の容量のデータ（たとえば200文字）が保持でき
るエリアを備える。各バンドにおいて、中間データはま
ず基本ブロックに保持され、基本ブロックの容量を越え
ると、拡張ブロックが割り当てられる。このように各バ
ンドに対して割り当てられる中間データ保持メモリのエ
リア（容量）は、中間データの数により変動するので、
中間データ管理テーブルにより中間データ保持メモリ内
の各バンドのデータを管理する。

複数の文書の中間データを保持する場合は、さらに中
間データ管理テーブルと複数の文書と対応させる文書管
理テーブルを設けて中間データを各文書ごとに管理す
る。

（実施例）以下、添付の図面を参照して本発明の実施例を説明す
る。

（ａ）プリンタの文字発生装置の全体構成第１図は、本発明の実施例に係るプリンタの文字発生
装置の全体構成を示す。ここで、インターフェイス部１
は、ホストコンピュータ、イメージリーダ等のホストか
らの受信データ（プロトコルデータ）を受信バッファ２
に転送する。受信バッファ２は、ホストからの受信デー
タを記憶するバッファメモリである。プロトコル解析部
３は、受信データを解析し、印字部インターフェイス制
御コマンド、印字データ等の識別を行い、それぞれ印字
インターフェース制御部４と編集制御部５へ送る。印字
部インターフェイス制御部４は、電子写真プロセスで印
字を行う印字部の印字シーケンスの制御と操作パネルの
LED表示制御を行う。編集制御部５は、受信データより
カーソル位置を計算し、文字等の情報（サイズ、ソース
アドレスなど）であるパケットデータ（中間コード）を
作り、パケットバッファ６に送る。本実施例においてプ
リンタ文字発生の制御は、編集制御部５において行われ
る。フォント制御部７は、フォントメモリ８のROMフォ
ント及びダウンロードフォントの管理を行なう。ビデオ
バッファ制御部９は、ビデオバッファ10の制御を行な
う。また、パケットバッファ６のパケットデータをもと
にビデオバッファ10にイメージを展開する。ビデオバッ
ファ10は、ドットイメージなどを記憶するバッファメモ
リである。

ホストより受信するプロトコルデータは、文字デー
タ、グラフィックデータ、ダウンロードデータ（フォン
ト）、および制御コマンドに分けられる。データの流れ
は、第２図に示すようになる。

文字データは、文字コードに対応するビットマップデ
ータの記憶アドレスと印字位置に対応する印字用紙上の
仮想アドレスとを基にパケットデータを作り、パケット
バッファ６に書き込む。

グラフィックデータには、ベクターグラフィックデー
タとラスターグラフィックデータとがある。グラフィッ
クデータは、ビデオバッファ制御部９を通して、ビデオ
バッファ10に書き込む。また、書き込んだアドレスと印
字位置のアドレスを基にパケットデータを作り、パケッ
トバッファ６に書き込む。

フォントのダウンロードデータは、ビデオバッファ制
御部９を通してビデオバッファ10に書き込む。また、書
き込んだフォントの管理データは、フォント管理テーブ
ルに登録する。

制御コマンドは、印字部を制御するためのコマンドに
ついては、印字部に送り、その他のコマンドは、その内
部パラメータをセットする。

（ｂ）中間データへの変換とデータ管理方式本実施例におけるデータ管理方式においては、６枚ま
での文書が管理できる。ホストから受信したイメージデ
ータは、後で説明するように、まず、中間データである
パケットデータに編集（変換）され、パケットデータは
パケットバッファ６に記憶される。このパケットデータ
は、通常は１枚の文書のパケットデータが記憶される
と、次にビットデータに変換してビデオバッフア10に記
憶される。このビットデータの書込と出力とは、第３図
に示すように１枚の文書を副走査方向（印字の紙送り方
向）に複数個（本実施例では５個）のバンドに分割した
ときのバンド単位で順に行う。ビデオバッファ10は、１
枚分のビットマップメモリではなく、この1/5枚分の容
量の２個のエリアを備え、この２つのエリアにおいてビ
ットデータの書込と読出とが交互に行われる。

このように１枚を５バンドに分割して、ビットデータ
の書込と読出とを行うので、印字はペーパー上部より順
次印字していく。このため、文字データやグラフィック
データを印字するために、あらかじめ通常は１枚分のデ
ータを印字位置で編集しておく必要がある。そこで、１
枚分の印字データをパケットデータに変換し、パケット
バッファ６に記憶しておく。印字がバンド単位で行われ
るのに対応して、第４図に示すように、パケットデータ
もバンド単位で記憶される。そして、実際の印字処理
は、１枚分のパケットデータへの編集が終わってから、
先頭のバンドよりパケットデータを用いて２個のバンド
バッファに交互にドットイメージを順次展開していく。

文字データとラスターグラフィックデータのパケット
データへの変換は、通常は一定の方向に連続的に行われ
る。しかし、ベクターグラフィックデータは、たとえば
直線の場合などは、複数のバンドにわたって存在しうる
ので、複数のパケットエリアに記憶されることがある。
従って、パケットデータの展開は、バンドの順に行なわ
れるとは限らない。後に説明するように、グラフィック
データは、バンド内の小単位であるセル単位で記憶され
るので、複数のバンドにわたる直線の場合ベクターグラ
フィックデータは、複数のバンドの複数のセルに対応し
てパケットデータに変換され、関連するパケットエリア
に記憶される。

パケットデータのパケットバッファ６への書込は、バ
ンドごとに設けたパケットエリアに対してなされる。１
バンド内に書かれる文字数は一定でないために、１バン
ド当りのパケットエリアの容量数を固定すると、パケッ
トバッファ６の使用効率が悪くなる。そこで、各バンド
に対して初めにデータ管理上必要な最小容量（たとえば
２文字分）だけパケットデータを登録するエリアを確保
し、これを越えて文字を書き込むときは、新たにある程
度多数の文字（たとえば200文字分）のパケットデータ
登録エリアを追加し、その後は200文字単位でパケット
登録エリアを確保していく。（最小容量を２文字分とし
たのは、データの有無の判断や、複数バンドにわたった
文字の存在の可能性などによる。）従って、パケットエ
リアは、第５図に示すように、数文字分（本実施例では
２文字分）の容量の基本パケットエリアと、多数の文字
分（本実施例では200文字分）の拡張パケットエリアと
に分けられる。基本パケットエリアP₀,P₁…,P₄はすべて
のバンドに対してあらかじめ設けられるが、拡張パケッ
トエリアP₅,P₆,…は、各バンドにおいて３文字目以降の
データがある場合に必要に応じて追加して割り当てられ
る。

１パケットは第６図に示すように、４ワードで構成す
る。ここに、ソースアドレスは、ビデオバッファ10に書
き込むデータの先頭アドレスであり、ビデオバッファア
ドレスは、書き込み先のビデオバッファ10の先頭アドレ
ス（オフセット）であり、セル幅は、書き込むデータの
幅であり、セル高さは、書き込むデータの高さであり、
フラグ１は、ビデオバッファ制御部９の制御フラグ（ソ
ース関係）である。

１パケットの管理するデータの量は、たとえば、文字
データでは１文字であり、ラスターグラフィックデータ
では、160×160ドット角のエリア（セルという）であ
る。

グラフィックデータは、セル単位でビデオバッファ10
のグラフィック保持エリアに記憶される。ここに、１セ
ルとは、第７図に示すように、ホストにより指定された
ペーパーサイズを特定サイズのｍ×ｎ個（本実施例では
４×７）の領域に分割したものであり、各セルにシリア
ル番号が付加される。

第８図のビデオバッファ10のメモリマップに示すよう
に、バンドバッファおよびグラフィック保持エリアは、
同一のビデオバッファ10上に設けられ、互いにペーパー
サイズおよびデータにより容量が変化する。従って、後
に説明する管理テーブルによりメモリを管理する。

グラフィック保持エリアは、ビデオバッファ10上のラ
ストアドレスを開始点（GR_RASD_NAD）とし、登録エリ
アを確保するごとに、保持エリア終了ポインタ（GR_RAS
_BOT）及び後述のＢテーブルの対応文書のエンド保持エ
リアを更新する。

第９図は、特定サイズに分割したセルに対するグラフ
ィック保持エリア上のリアアドレスを登録しておくアド
レステーブルを示す。セルマップ上の各セルに１対１に
対応しており、保持エリア上に登録エリアの確保されて
いないセルは“00"が入っている。

いま、第７図のセルマップにおいて、グラフィックデ
ータの１枚内の絶対座標位置により、対応するセル番号
がはじめ３であったとき、第８図に示すように、ビデオ
バッファ10上での相対アドレスを求めてセル「３」での
登録エリアが確保されてデータが書き込まれるととも
に、保持エリア終了ポインタ（GR_RAS_BOT）が更新さ
れ、これに対して第９図に示すアドレステーブルにおい
てセル「３］のリニアアドレスが登録される。また、一
度登録したセルに重ね書きを行なうには、番号に対応す
るアドレス値を求めてビデオメモリ上に書き込むアドレ
ス値を得る。

ビデオバッファ10上にグラフィック保持エリアを確保
するときに、ビデオバッファ10上に登録するセルデータ
に対して、パケットを作る。すなわち、グラフィックデ
ータのパケットデータは、セル単位で処理される。パケ
ットを作ることによりグラフィックデータをバンドメモ
リに展開するときは文字データと同じ扱いとなる。

文書、パケットデータ及びグラフィック保持エリアを
管理するために、編集制御部５において３つのテーブル
が用いられる。

第10図に示すＡテーブルは、プリンタでイメージを保
持しておく必要がある枚数分の文書管理テーブルであ
る。それぞれの文書に対し、バンド０からボトムマージ
ンのバンドまでに対応する基本パケットの番号を管理す
る後述のＢテーブルのスタートポイントとエンドポイン
ト、及びその文書について使用したグラフィック保持エ
リアのスタートポイントとエンドポイントを登録する。

第11図は、６枚の文書に対し、パケットバッファ６
（第５図参照）に記憶されるパケットデータを管理する
テーブルである。６枚の文書に対する基本パケットエリ
アを管理する基本パケット管理テーブルと、必要に応じ
て追加される拡張パケットエリアを管理する拡張パケッ
ト管理テーブルとからなる。

個々のパケット管理テーブルの構成は第12図に示すと
おりである。各バンドに対し、現在使用中の分割パケッ
トNo.（基本パケットでのみ使用）、次に使用された分
割パケットNo.,現在記憶されているパターン数、各バン
ドの文字規定、パケットの先頭アドレス及びセグメン
ト、及びパケットの次使用アドレス及びセグメントが順
次記憶される。ここで、現在使用中の分割パケットNo.
は、使用可能な分割パケットがなくなった場合には、エ
ンドコードが書き込まれる。次使用分割パケットNo.
は、そのパケットでバンドデータ終了である場合は、
“0"が書き込まれる。現在使用中の分割パケットの終了
は、1wと2wの比較一致により検出される。印字プロセス
において、ビデオバッファ制御部９に対するパケットデ
ータ出力処理時に上記の次使用分割パケットNo.によ
り、パケットの引きつぎを行なう。各バンドの最終デー
タの検出は、1wのパターン数を印字プロセスにおいてカ
ウントして行なう。

第13図に示すＣテーブルは、文書、パケット、保持エ
リアの全体的な管理テーブルであり、排出等の処理終了
の検出された文書番号及び編集処理中（パケット作成
中）の文書番号を管理するページポインタ、使用中の拡
張パケット番号を管理する開始ポインタ及び終了ポイン
タ、同じく使用中の保持エリアアドレスを管理する開始
ポインタ及び終了ポインタで構成される。従って、管理
中の文書の番号、管理中の文書によって使用されている
拡張パケットエリア及び管理中の文書により使用されて
いるグラフィックデータの保持エリアが管理される。

（ｃ）編集制御のフロー第14図は、編集制御部５を構成するCPUの概略メイン
フローを示す。このフローにおいて、パワーオン時にCP
U及び周辺回路に対して初期化を行ない（＃201）、ワー
クエリア及びパケットバッファ6,ビデオバッファ10をク
リアし（＃202）、ディップスイッチ及びデフォルト設
定に従い、初期設定（ページカウンタPG＝０）を行なう
（＃203）。次に、パケットを管理するためのエーブル
（A,B,C）を初期化する（＃204）。

各文書の初期設定として、まず、プリンタの基本的性
能により決定される最大管理文書数（本実施例では６）
の制限に対し、余裕があるかどうかを判定し（＃20
5）、不可であれば（NO）、それまでにすでに管理中の
文書の処理が終了するのを待つ。ホストからのデータの
編集開始が可能であれば（YES）、カレントページポイ
ンタ（Ｃテーブル）を更新し（＃206）、テーブルＡの
対応文書番号のパラメータ（スタートＢテーブル、エン
ドＢテーブル、スタート保持エリア）を設定する（＃20
7）。次にその時点でパケットバッファ６に未使用の拡
張パケットエリアがあるか否かを判定し（＃208）、な
ければ（NO）、空パケットエリアができるまで待つ。

第15図に示すように、ホストからの受信データは、イ
ンターフェイス部１で非同期に受信され（＃101）、受
信バッファ２に出力されている（＃102）。

第14図に戻って説明を続けると、受信バッファ２に保
持されている受信データを読み込み解析し（＃209）、
印字データであれば（＃210でYES）、グラフィックデー
タ（ベクター及びラスター）か、文字データかにより
（＃211）、各パケット作成処理を行なう（＃212、＃21
3）。

受信データが制御コマンドである場合には（＃210でN
O）、各々に対応する処理を行なう（＃214）。次に、排
紙要求であるか否かを判定し（＃215）、否であれば＃2
09に戻り、受信データの解析を続ける。

処理するデータが排紙要求であれば（＃215でYES）、
ページカウンタPGのインクリメントをし（＃216）、連
続処理判定条件（たとえば両面複写では２）に等しいか
否かを判定する（＃217）。否であれば＃205に戻り、次
の文書のデータを処理する。

連続処理判定条件に達すると、印字部に対し、起動を
かけると共に、自らもバンドバッファへのドットイメー
ジデータの展開及びデータ出力を行なうプリントコント
ロール処理を行ない（＃218）、ページカウンタPGをリ
セットする（＃219）。そして、＃205に戻り、次の文書
のデータを処理する。

第16図は、タイマー割込処理のフローを示す。この処
理は、特定時間毎に行なわれるものであり、第14図のフ
ローの＃205及び＃208で判定されるパラメータはここで
更新される。まず、エラー発生等の各種フラグの読み込
み（＃251）、その中で文書終了が検出されれば（＃252
でYES）、ビデオバッファ10上に保持されているグラフ
ィックデータをクリアし（＃253）、拡張パケットポイ
ンタ（Ｃテーブル）を更新し（＃254）、Ｂテーブルの
対応文書部を消去し（＃255）、終了ページポインタ
（Ｃテーブル）を更新する（＃256）。

第17図に、グラフィックパケットの作成処理（第14図
＃212）のフローを示す。本実施例に係る文字発生装置
は、１枚を副走査方向に特定ライン数ｎで分割し、その
ｎライン分のビットマップメモリ（バンドバッファ）を
２面有し、各バンド毎に印字すべきデータを仮編集した
パケットデータをパケットバッファ６に保持している。
パケット構成は、文字パケットと共通である（第６
図）。グラフィックデータにはベクターグラフィックデ
ータとラスターグラフィックデータがあり、ベクターグ
ラフィックデータは＜描画指示コマンド＞｛直線、円
等｝＋＜パラメータ＞｛座標、大きさ等｝の形態で、ラ
スターグラフィックデータはたとえば＜コマンド＞＋＜
データ長＞＋＜１ラインラスターデータ＞の形態でホス
トより送信されている。

よって、まず、コマンド解析処理を行なう（＃30
1）。その結果、その図形をドット展開した場合の各ド
ットの１枚の文書上の絶対座標位置を算出し（＃30
2）、その座標位置に対応するセルをセルマップより検
索し（＃303）、対応セルに対する登録エリアがバンド
バッファと同一メモリ10上に置かれた保持エリア（第８
図参照）に確保されていれば（＃304でYES）、対応セル
内の相対アドレスを算出し（＃305）、データを書き込
む（306）。登録エリアがない場合（＃304でNO）、空パ
ケット（基本パケットエリアとすでに割り当てられてい
る拡張パケットエリアにおけるメモリの空き）の有無
（＃308）及び拡張パケットエリアの有無（＃309）を検
索し、どちらも空きがなければエラー処理（＃314、第1
9図参照）を行ない、空きエリアができるまで待機す
る。拡張パケットエリアが確保できる場合には（＃309
でYES）、Ｂ及びＣテーブルを更新し、拡張パケットエ
リアを割り当てる。

登録するパケットエリアが確保できる場合は、空ビデ
オバッファ10の残量をチェックし（＃311）、空エリア
のある場合には（YES）、登録エリアを確保し（＃31
2）、セルの先頭アドレス、幅、高さ、及び展開時のア
ドレスを算出し、パケットを作成して登録し、Ｂテーブ
ルを更新する（＃313）。登録エリアが確保できない時
は（＃311でNO）、エラー処理を行なう（＃309）。

以上の処理（＃302〜＃314）を未処理の対象データに
対し繰り返す（＃307でYESの場合）。保持されたパケッ
トデータは、プリントコントロール処理時に（第14図＃
218）、各バンドの展開時にビデオバッファ制御部９を
通じてバンドバッファに展開される（第３図）。

第18図は、文字パケット作成処理（第14図＃212）の
フローを示す。本実施例に係る文字発生装置は、１枚を
副走査方向に特定ライン数ｎで分割し、そのｎライン分
のビットマップメモリ（バンドバッファ）を２面有し、
各バンド毎に印字すべきデータを仮編集したパケットデ
ータをパケットバッファ６に保持している。カーソル位
置に対して対応するバンドのパケットエリアに空があれ
ば（＃401でYES）、フォントアドレス及びビデオバッフ
ァ10に展開する場合のリニアアドレスを算出し、パケッ
トデータを作成し、パケットエリアに登録し、その管理
テーブルであるＢテーブルを更新する（＃402）。空パ
ケットがない場合には、未使用の拡張パケットエリアが
ある時（＃403でYES）、Ｂ及びＣテーブルを更新し、対
象バンドに対し、拡張パケットエリアを割り当てる（＃
404）。グラフィックパケットと同じく、空パケットが
なく、かつ、空拡張パケットエリアがない場合には、エ
ラー処理（第19図参照）を行なって（＃405）、終了す
る。

第19図は、拡張パケットエリア及びビデオバッファ10
が編集処理途中で不足した場合のエラー処理（第17図＃
314、第18図＃405）のフローを示す。プリンタがたとえ
ば１枚のペーパーに対し複数文書を印字する場合の枚数
が連続処理判定条件として、初期設定（第14図、＃20
3）において設定されている。連続判定条件は、プリン
タの構造等の条件により決定される。たとえば両面印字
の場合は２である。Ｃテーブルにおいてエラーを発生し
た現編集中の文書番号と処理終了した文書番号の差が連
続処理判定条件以下であれば（＃1101でYES）、そのペ
ーパーに対する複数文書の編集に対するメモリが絶対的
に不足しているということになり、待機のためエラー表
示を行なう（＃1103）。差が連続処理判定条件より大き
ければ、ペーパーを排出し、処理終了が更新されること
により拡張パケットバッファ及びビデオバッファ10の空
ができるのを待つ（＃1104、＃1105）。メモリの空きが
できれば、エラー表示を消す（＃1106）。

（発明の効果）本発明に係る第１のプリンタデータ管理方式では、１
枚の文書中の印字データの多いバンドに対しては、その
バンドのための中間データのデータ保持エリアがデータ
量に応じて増加するために、データ量の片寄った文書に
も対応でき、メモリを効率的に利用できる。

本発明に係る第２のプリンタデータ管理方式では、複
数枚の文書の中間データの管理を、１枚の文書の管理を
ほとんど変更せずに、容易に行なうことができる。

【図面の簡単な説明】

第１図は、プリンタの文字発生装置の全体構成図であ
る。第２図は、データの流れを示す図である。第３図は、１枚の文書を５つのバンドに分割した図であ
る。第４図は、文字、グラフィックデータのビットイメージ
への展開を示す図である。第５図は、パケットバッファのエリア構成を示す図であ
る。第６図は、パケットデータの構成を示す図である。第７図は、セルマップの図である。第８図は、ビデオメモリマップの図である。第９図は、アドレステーブルの図である。第10図は、文書管理テーブルＡの図である。第11図は、パケット管理テーブルＢの図である。第12図は、第11図に示すパケット管理テーブルにおける
各パケット管理データの図である。第13図は、全体的な管理テーブルＣの図である。第14図は、編集制御部の制御のフローチャートである。第15図は、データ受信処理のフローチャートである。第16図は、タイマー割込のフローチャートである。第17図は、グラフィックパケット作成処理のフローチャ
ートである。第18図は、文字パケット作成処理のフローチャートであ
る。第19図は、エラー処理のフローチャートである。５……編集制御部、６……パケットバッファ、 10……ビデオバッファ。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献特開昭63−81071（ＪＰ，Ａ) 特開昭60−126730（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) B41J 5/30

Claims

(57)【特許請求の範囲】

【請求項１】１枚の文書を副走査方向に複数のバンドに
分割し、少なくとも１バンド分のメモリ容量を備えたイ
メージメモリを備え、ホストからの印字データをドット
イメージデータとしてイメージメモリに速く展開するた
めに印字データを中間データに編集して中間データ保持
メモリに保持し、中間データのイメージメモリへのドッ
トイメージの展開及び印字部へのデータ出力をバンドご
とに行うプリンタにおいて、中間データへの編集において各バンドごとに中間データ
が発生すると中間データ保持メモリにおいてまずそのバ
ンドのデータ管理上必要な最小容量の基本ブロックに中
間データを保持し、さらに基本ブロックの容量を越えてそのバンドの中間デ
ータが発生すると、ある程度の容量のデータを保持可能
な拡張ブロックを中間データ保持メモリにおいてそのバ
ンドについて確保し、その拡張ブロックに中間データを
保持し、中間データ保持メモリにおいて使用されているブロック
をバンドと対応付ける中間データ管理テーブルを設ける
ことを特徴とするプリンタデータ管理方式。
【請求項２】請求項１に記載されたプリンタデータ管理
方式において、上記の中間データ管理テーブルを複数の文書に対応付け
るための、管理すべき各文書に対応する文書管理テーブ
ルをさらに設けることを特徴とするプリンタデータ管理
方式。