JPH1023272A

JPH1023272A - ページプリンタにおけるデータ圧縮方法及び伸長方法

Info

Publication number: JPH1023272A
Application number: JP8172587A
Authority: JP
Inventors: Hiroshige Kawakami; 浩成川上
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 1996-07-02
Filing date: 1996-07-02
Publication date: 1998-01-23

Abstract

(57)【要約】【課題】ページプリンタのメモリ容量を節減し、低価
格化と高解像度化を可能にすると共に、イメージデータ
の圧縮処理及び圧縮コードの伸長処理の高速化を図る。【解決手段】予め、基準長となる所定ビット数のイメ
ージデータの全種類に対して、その各値をアドレスとし
て、所定のコードテーブルに基づいて各イメージデータ
を符号化したレコードデータを格納した符号化ルックア
ップテーブルと、所定ビット数のレコードデータ（圧縮
コード）の全種類に対して、その各値をアドレスとし
て、上記コードテーブルに基づいて各レコードデータを
復号化したイメージデータを格納した復号化ルックアッ
プテーブルとを作成しておく。そして、イメージデータ
に対して所定ビット数毎にその値に対応する符号化テー
ブルを参照して符号化し、圧縮コードに対しても所定ビ
ット数毎にその値に対応する復号化テーブルを参照して
復号化する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、白黒およびカラ
ーのレーザプリンタ，ＬＥＤプリンタ等のページプリン
タ（デジタル複写機のプリンタ部も含む）におけるデー
タ圧縮方法及びデータ伸長方法に関する。

【０００２】

【従来の技術】近年、レーザプリンタ等のページプリン
タの解像度は益々高くなり、最近では６００ＤＰＩが主
流になっている。今後は８００ＤＰＩや１２００ＤＰＩ
のプリンタが出現するであろうし、マルチ・リゾリュー
ション・プリンタ、すなわちエミュレーションに応じて
エンジンの解像度が変化するプリンタも増えてくるであ
ろう。

【０００３】しかし、ページプリンタ内の１ページ分の
ビットマップデータを展開するフレームバッファのメモ
リ容量は、Ａ４，６００ＤＰＩで約４ＭＢ、Ａ３，６０
０ＤＰＩでは約８ＭＢになる。このようなフレームバッ
ファのメモリ容量の増加は、製品価格に大きな影響を与
える。一方、ページプリンタの価格は逆に低価格へと推
移しているため、高解像度化に伴う価格上昇をなんらか
の手段で抑えなければならない。

【０００４】そのための２値画像データの可逆圧縮技術
には、ファクシミリ等で用いられるＭＨ（ハフマン符号
化方式：一次元圧縮法によるＧ３ファクシミリの標準符
号化方式），ＭＲ（二次元圧縮法によるＧ３ファクシミ
リではオプションの符号化方式），ＭＭＲ（ＭＲ符号化
方式の変形で、Ｇ４ファクシミリの標準符号化方式）
や、コンピュータで扱うテキストファイルやバイナリフ
ァイルに用いられる、例えばＬＺ方式の圧縮等がある。
また、最近では国際標準である算術符号化を用いたＪＢ
ＩＧ方式もある。

【０００５】

【発明が解決しようとする課題】しかしながら、これら
の２値画像データ圧縮技術は、画像あるいはファイルの
先頭から順番に逐次符号化処理を行なうので、所望の任
意ブロックだけをリアルタイムに復元することはできな
い。

【０００６】ページプリンタでは、印刷すべき文書情報
がコンピュータのＣＲＴ上で実際に作成された順番にく
るため、ある大きさのブロック単位で圧縮処理を施さな
ければならない。従って、上記圧縮技術をそのまま使用
することはできない。また、２値画像データの固定長可
逆圧縮技術は世の中に存在しない。従って、対象とする
画像データによっては、所望の容量に圧縮できない場合
がある。

【０００７】そこで、本発明者等は先に、ページプリン
タにおいて印刷すべき文書データを所定の解像度にラス
タライズし、そのラスタライズされたデータに対して所
定の大きさのユニット（複数のブロックによって構成さ
れる）単位で可変長可逆圧縮処理を施し、１ユニットが
全て白データの場合の特定コードを含む圧縮コードを圧
縮メモリに格納し、該圧縮メモリへの１ページ分あるい
はそれを複数に分割したデータの圧縮コードの格納が完
了した後、その圧縮コードを伸長してプリンタエンジン
にビデオ信号を出力する画像データの圧縮・伸長方法を
発明した。

【０００８】上記の発明によれば、ページプリンタのメ
モリ容量を節減でき、低価格化と高解像度化を共に可能
にすることができる。しかし、その場合でも、ラスタラ
イズされたイメージデータを圧縮コードへ符号化する際
に、ラスタライズされたデータを１ビットずつ“０”か
“１”かを判別してその連続するビット数をカウントし
ていたため、ｎビットの符号化にはｎ回の処理が必要で
あった。したがって、この方式ではバスアクセスの回数
が多く、圧縮符号化処理の速度を速めることが困難であ
った。また、圧縮コードを伸張処理する際にも、ｍビッ
トの符号化されたデータを１ビットずつ処理するため、
やはり処理速度を速めることが困難であった。

【０００９】この発明はこの点を改善するためになされ
たものであり、ページプリンタにおけるフレームバッフ
ァのメモリ容量を削減し、低価格な高解像度ページプリ
ンタを提供できるようにするとともに、ラスタライズさ
れたイメージデータをを圧縮コードに符号化する処理、
及びその圧縮コードを元のイメージデータに復元する伸
長処理の高速化を図ることを目的とする。

【００１０】

【課題を解決するための手段】この発明によるデータ圧
縮方法は、ページプリンタにおいて、印刷すべき文書デ
ータを所定の解像度にラスタライズし、そのラスタライ
ズされたイメージデータに対して所定の大きさのブロッ
ク単位で可変長可逆圧縮処理を施し、その圧縮コードを
圧縮メモリに格納するデータ圧縮方法であって、上記の
目的を達成するため、予め、符号化ルックアップテーブ
ルを参照する基準長となる所定ビット数のイメージデー
タの白ドットと黒ドットの全ての組み合わせに対して、
各組み合わせの値をアドレスとして、所定のコードテー
ブルに基づいて各イメージデータを圧縮できる部分まで
圧縮したレコードデータを格納した符号化ルックアップ
テーブルを作成しておく。

【００１１】そして、上記ブロック単位のイメージデー
タに対して、先頭から上記所定ビット数のデータについ
て、その白ドットと黒ドットの組み合わせによる値で上
記符号化ルックアップテーブルを参照し、そこに格納さ
れているレコードデータを圧縮コードの一部として圧縮
メモリに格納し、その後、圧縮できなかった残りのイメ
ージデータの初めから再び上記所定ビット数のデータに
ついて、その白ドットと黒ドットの組み合わせによる値
で上記符号化ルックアップテーブルを参照し、そこに格
納されているレコードデータを圧縮コードの続きの部分
として上記圧縮メモリに格納することを、上記ブロック
単位のイメージデータの終わりまで繰り返すことを特徴
とする。

【００１２】このようにすれば、ラスタライズされたデ
ータを圧縮コードに符号化する際に、１ビット毎の処理
ではなく、基準長となる所定ビット数ずつまとめて符号
化できるので、符号化処理の高速化を計れる。その符号
化ルックアップテーブルを参照する基準長となる所定ビ
ット数を可変にすることができ、この所定ビット数を大
きくすることによって、さらに高速化を計れる。

【００１３】さらに、圧縮メモリ及び非圧縮メモリとし
て使用できるメモリの記憶容量を判別し、その判別した
記憶容量に応じて基準長となる所定ビット数を決定する
ようにすれば、システムの記憶容量に応じて、最適な基
準長のビット数の符号化ルックアップテーブルを作成す
ることができ、記憶容量に応じた最大限の処理速度を実
現できる。

【００１４】また、印刷すべき文書データのイメージ，
文字，線画，グラフィックス等の種類に応じて、使用す
るコードテーブルを選択的に切り替えて符号化ルックア
ップテーブルを作成するようにすれば、文書の種類に応
じて最適なコードテーブルを選択して、圧縮効率を最高
にできる符号化ルックアップテーブルを作成できる。

【００１５】一方、この発明によるデータ伸長方法は、
ページプリンタにおいて、ラスタライズされたイメージ
データに対して所定の大きさのブロック単位で可変長可
逆圧縮処理を施して圧縮メモリに格納された圧縮コード
を伸長して元のイメージデータに復元するデータ伸長方
法であって、上記の目的を達成するため、予め、復号化
ルックアップテーブルを参照する基準長となる所定ビッ
ト数の圧縮コードの全ての異なる値をそれぞれアドレス
として、所定のコードテーブルに基づいて各圧縮コード
をそれぞれ復元できる部分まで復元したイメージデータ
を格納した復号化ルックアップテーブルを作成してお
く。

【００１６】そして、圧縮メモリに格納されている上記
ブロック単位のイメージデータが圧縮された圧縮コード
に対して、先頭から上記所定ビット数の圧縮コードにつ
いて、その値で上記復号化ルックアップテーブルを参照
し、そこに格納されているイメージデータを復元するイ
メージデータの一部として送出し、その後、復元できな
かった残りの圧縮コードの初めから再び上記所定ビット
数の圧縮コードについて、その値で上記復号化ルックア
ップテーブルを参照し、そこに格納されているイメージ
データを復元するイメージデータの続きの部分として送
出することを、上記ブロック単位の圧縮コードの終わり
まで繰り返すことを特徴とする。

【００１７】このようにすれば、符号化された圧縮コー
ドを復元化する際に、圧縮コードを１ビット毎に処理す
るのではなく、基準長となる所定ビット数ずつまとめて
復元化できるので、復元化処理の高速化を計れる。この
場合にも、復元化ルックアップテーブルを参照する基準
長となる所定ビット数を可変にすることができ、この所
定ビット数を大きくすることによって、さらに高速化を
計れる。

【００１８】さらに、圧縮メモリや非圧縮メモリ及びル
ックアップテーブルの記憶用として使用できるメモリの
記憶容量(システムのデータ記憶容量)を判別し、その判
別した記憶容量に応じて基準長となる所定ビット数を決
定するようにすれば、データ記憶容量に応じて最適な基
準長のビット数の復号化ルックアップテーブルを作成す
ることができ、データ記憶容量に応じた最大限の処理速
度を実現できる。

【００１９】また、印刷すべき文書データのイメージ，
文字，線画，グラフィックス等の種類に応じて、使用す
るコードテーブルを選択的に切り替えて復号化ルックア
ップテーブルを作成するようにすれば、文書の種類に応
じて最適なコードテーブルを選択して、圧縮効率を最高
にできる復号化ルックアップテーブルを作成できる。

【００２０】

【発明の実施の形態】以下、この発明の実施の形態を図
面に基づいて具体的に説明する。図７はこの発明による
ページプリンタを用いた画像形成システムの構成例を示
す図であり、１００はパーソナルコンピュータ、２００
がページプリンタである。通常、ユーザはパーソナルコ
ンピュータ１００のＣＲＴ画面とキーボードとＤＴＰ
（デスクトップ・パブリッシング）アプリケーションを
使って文書を作成し、その文書データをプリンタドライ
バ１０１を通してページプリンタ２００に転送して印刷
を行なう。

【００２１】プリンタドライバ１０１は、通常印刷すべ
き文書内容をページプリンタ２００がサポートするプリ
ンタ言語、例えばヒューレット・パッカード（ＨＰ）社
のＰＣＬやＡｄｏｂｅ社のポストスクリプト言語等にコ
ンバートする。前者に接続されたプリンタを一般にＰＣ
Ｌエミュレーション・プリンタ、後者に接続されたプリ
ンタをポストスクリプト・プリンタと呼ぶ。また、パー
ソナルコンピュータ１００側で全てラスタライズされた
ビットイメージを印刷するだけのダムプリンタと呼ばれ
るプリンタもある。

【００２２】ページプリンタ２００としては、レーザプ
リンタやインクジェットプリンタ、あるいはサーマルプ
リンタ等があるが、高速印刷という点でレーザプリンタ
が勝る。最近はカラーのレーザプリンタも市場に出始め
ており、それを使用することも可能である。また、解像
度は年々高まる一方で、現在は６００ＤＰＩが標準とな
っている。以下の実施例では、ページプリンタ２００を
６００ＤＰＩの白黒ポストスクリプト・レーザプリンタ
（以下単に「ページプリンタ」と称する）として説明す
るが、この発明はそれに限定されるものではない。

【００２３】図８はそのページプリンタの外観図であ
り、図９はその内部機構の概略を示す縦断面図である。
このページプリンタ２００は、給紙トレイ２を着脱可能
に備え、上部に第１排紙スタッカ３を設け、後部に第２
排紙スタッカ４を設けている。２個の排紙スタッカ３，
４への排紙は切換爪５によって切換え可能である。通常
は、排紙スタッカとして第１排紙スタッカ３が選択され
るが、封筒や葉書などのカールし易い紙を使用する場合
など、特別な場合に第２排紙スタッカ４が選択される。

【００２４】さらに、内部にはプリンタエンジンの作像
部を構成する感光体ドラム１０，帯電部１１，光書込部
１２，現像部１３，転写部１４，定着部１５と、給紙ロ
ーラ１６及びレジストローラ対１７等による給紙部と、
搬送ローラとペーパガイド板等からなる排紙用搬送部１
８と、このページプリンタ全体を制御するプリンタコン
トローラを構成するコントローラ基板１９及びプリンタ
エンジンのシーケンスコントローラを構成するエンジン
ドライバ基板２０等が設けられている。

【００２５】そして、プリンタエンジンのシーケンスコ
ントローラによりプリントシーケンスが開始されると、
給紙ローラ１６によって給紙トレイ２から給紙を始め、
その用紙の先端をレジストローラ対１７に突き当てた状
態で一時停止させる。一方、感光体ドラム１０は、図９
の矢印Ａ方向へ回転し、帯電部１１で一様に帯電された
表面に、光書込部１２によってプリンタコントローラか
らの画像データに応じて変調されたレーザビームが、ド
ラム軸方向に主走査しながら照射してて露光され、表面
に静電潜像が形成される。

【００２６】それを現像部１３でトナーによって現像
し、レジストローラ対１７によって所定のタイミングで
給送される用紙に転写部１４において転写し、定着部１
５で加熱定着したプリント紙を第２排紙スタッカ４へ送
出するか、排紙用搬送部１８を通して上部の第１排紙ス
タッカ３へ搬送する。

【００２７】図１０はコントローラ基板１９の内部ブロ
ック図である。このコントローラ基板１９は、ＣＰＵ２
０１，ＮＶＲＡＭ２０３，プログラムＲＯＭ２０４，フ
ォントＲＯＭ２０５，ＲＡＭ２０６，及び４個のインタ
フェース（以下「Ｉ／Ｆ」と略称する）２０７，２０
９，２１１，２１３と、これらを接続するバスライン２
１５によって構成されている。

【００２８】ＣＰＵ２０１は、プログラムＲＯＭ２０４
に格納されたプログラム、操作パネル２１０からのモー
ド指示、ホスト装置であるパーソナルコンピュータ（パ
ソコン）１００からのコマンド等によって、このコント
ローラ全体を制御する。また、挿着されたＩＣカード２
０２から、フォントデータやプログラム等を取り込むこ
ともできる。ＮＶＲＡＭ２０３は、操作パネル２１０か
らのモード指示の内容などを記憶しておく不揮発性メモ
リである。

【００２９】プログラムＲＯＭ２０４は、このコントロ
ーラの制御プログラムを格納している読出し専用メモリ
である。フォントＲＯＭ２０５は、文字フォントのパタ
ーンデータなどを記憶する。ＲＡＭ２０６は、ＣＰＵ２
０１のワークメモリ，入力データのインプットバッフ
ァ，プリントデータのページメモリ（フレームバッフ
ァ），ビデオバッファ，ダウンロードフォント用のメモ
リ等に使用するランダムアクセス・メモリである。

【００３０】エンジンＩ／Ｆ２０７は、実際に印刷を行
なうプリンタエンジン２０８と接続されて、コマンド及
びステータスや印字データの通信を行なうインタフェー
スである。パネルＩ／Ｆ２０９は、操作パネル２１０と
接続されて、コマンド及びステータスの通信を行なうイ
ンタフェースであり、操作パネル２１０は、使用者に現
在のプリンタの状態を表示して知らせたり、使用者がモ
ード指示を行なったりするパネル装置である。

【００３１】ホストＩ／Ｆ２１１は、ホスト装置である
パーソナルコンピュータ１００と通信を行なうインタフ
ェースであり、通常はセントロニクスＩ／ＦやＲＳ２３
２Ｃを使用する。ディスクＩ／Ｆ２１３は、ディスク装
置２１４と通信を行なうためのディスクインタフェース
である。ディスク装置２１４は、フォントデータやプロ
グラム、あるいは印字データなどの種々のデータを記憶
しておくための外部記憶装置であり、フロッピディスク
装置やハードディスク装置などである。

【００３２】次に、このページプリンタ２００によるペ
ージ印刷の動作について説明する。図１１は、図１０に
示したコントローラ基板１９及び６００ＤＰＩのプリン
タエンジン２０８による、ページ印刷の処理に係わる部
分の機能構成を示すブロック図である。そのＰＳインタ
ープリタ２１と圧縮部２２及び伸長部２５は、図１０の
ＣＰＵ２０１等による機能、圧縮メモリ２３と非圧縮メ
モリ２４はＲＡＭ２０６のメモリ領域、ビデオ出力部２
７はエンジンＩ／Ｆ２０７の機能をそれぞれ示してい
る。

【００３３】図１２は、このページプリンタにより１ペ
ージ分の印刷を行なう際の動作フロー図である。そこ
で、この図１２のフローに沿って、図１１を参照しなが
らページ印刷の動作を説明する。図７に示したパーソナ
ルコンピュータ１００内のプリンタドライバ１０１が、
印刷すべき文書データをページ毎にポストスクリプト
（以下、ＰＳと記す）ファイルに変換してページプリン
タ２００へ送る。

【００３４】ページプリンタ２００がそのＰＳファイル
を受信すると、図１１に示したＰＳインタープリタ２１
が、それをプリンタエンジン２０８の性能による印刷の
解像度と同じ６００ＤＰＩの解像度で、ある大きさのブ
ロック単位でラスタライズし、そのラスタライズしたデ
ータに対して、圧縮部２２がそのブロック単位で可変長
可逆圧縮処理を試みる。このブロック単位については追
って詳述する。

【００３５】そして圧縮できれば、その結果の圧縮コー
ドを圧縮メモリ２３へストアする。この圧縮メモリ２３
は、３００ＤＰＩで１ページ分に相当する容量を持つペ
ージメモリで、図１０に示したＲＡＭ２０６のメモリ領
域を使用する。圧縮できなかったら、ラスタライズされ
た６００ＤＰＩのデータを非圧縮メモリ２４へストアす
る。実際には、この非圧縮メモリ２４は圧縮メモリ２３
を兼用することができるので、ＲＡＭ２０６のメモリ容
量を増加させる必要はない。なお、この圧縮メモリ２３
と非圧縮メモリ２４を含むページメモリは、その１ペー
ジ分の領域をＮ個に分割した各領域に、上記圧縮コード
及び非圧縮のデータを順次格納していく。

【００３６】１ページ分の処理が終了したら、圧縮画像
の伸長及びビデオ信号出力を行なう。すなわち、圧縮メ
モリ２３へストアした圧縮コードをページの左上から順
番に伸長部２５で伸長（解凍処理ともいう）し、６００
ＤＰＩの画像データに復元して、ビデオ出力部２７内の
ビデオバッファ（フレームメモリ）にビットマップ展開
する。非圧縮メモリ２４にストアした６００ＤＰＩの非
圧縮画像データは、そのままビデオバッフアの後述する
圧縮データテーブル（ＣＤＴ）によって指定されたアド
レスに展開する。

【００３７】そして、このビデオバッファに展開された
画像データを、ビデオ出力部２７がシリアルなビデオ信
号として、プリンタエンジン２０８へ送出して印刷させ
る。このときのビデオ出力部２７内のビデオバッファ
は、図１０のＲＡＭ２０６あるいは別のメモリに確保し
た１ページ分のフレームメモリ領域を使用する。その具
体例は後述する。あるいは１ページ分のフレームメモリ
の１／Ｎの大きさのメモリ領域を使用し、１ページ分の
画像データの展開およびそれによるビデオ信号の出力を
Ｎ回に分けて行なうこともできる。

【００３８】次に、図１１及び図１２によって説明した
この発明の前提となるブロック単位の可変長可逆圧縮処
理の詳細について図１３乃至図２０を参照して説明す
る。ＰＳファイルをラスタライズするデータのブロック
単位を、図１３に示すようにｔドット(dot) のブロック
ワードＢＷとする。そして、図１３の（ａ）又は（ｂ）
に示すように、このｔドット(dot) のブロックワードＢ
Ｗが主走査方向（ａ）あるいは副走査方向（ｂ）にｕ個
分連続して１ユニット(unit)を構成している。すなわ
ち、1ユニット(unit)＝ｕ*ＢＷである。

【００３９】そして、図１０に示したＣＰＵ２０１は、
図１１のＰＳインタープリタ２１としての機能によって
ＰＳファイルをラスタライズ（描画）した際、その１ユ
ニットのデータが全て白ドットか否かを調べ、全て白の
場合には圧縮部２２を使用せずに直接圧縮メモリ２３の
ホワイトマップテーブルＷＭＴをＮＵＬＬ（2xfffffff
f）にする。黒ドットが１つでもあると、そのユニット
を構成する各ブロックワードＢＷ毎に、圧縮部２２に圧
縮処理を行なわせる。

【００４０】図１４はそのブロックワードＢＷ及びユニ
ットの具体例を示し、ＰＳファイルをラスタライズした
データに対して、６４ドット(dot) の白ドット及び／又
は黒ドットからなるブロックワードＢＷの８(line)分を
１ユニットとする。すなわち、１ユニット（unit）＝８
*ＢＷ＝８*６４(dot）とする。

【００４１】さらに、各ユニットに対して図１５に示す
ように、３２bit のホワイトマップテーブル（Ｗhite
Ｍap Ｔable：ＷＭＴ）を用意する。そして、１ユニッ
トのデータが全て白ドットなら、ＷＭＴをＮＵＬＬ（0x
ffffffff）とし、もし、黒ドットが１つ以上存在するな
ら、図１６に示す３２bitの圧縮データテーブル（Ｃomp
ression Ｄata Ｔable：ＣＤＴ）の実アドレス（ＣＤＴ
アドレス）を格納する。

【００４２】なお、ＣＤＴアドレスが示すレコードの長
さは、図１７に示すように８*ＣＤＴ＝８*３２ビット
（bit）＝３２バイト（byte）とする。ＣＤＴは１つの
ブロックワードＢＷに対応し、後述の圧縮方式を試み
て、もし圧縮可能であったら、図１６に示す圧縮データ
テーブルＣＤＴのbit２９〜bit０に、その圧縮コードを
格納する。また、もし圧縮不可能であったら、bit３１
＝１とし、bit３０〜bit０に非圧縮時のデータ格納メモ
リアドレス（Uucompression Data TableAddress：ＵＤ
Ｔアドレス）を格納する(図１８)。

【００４３】今回使用した圧縮方式は、次に示す２ステ
ップからなる。まず始めに、対象となるブロックワード
ＢＷが全部白ドットか、全部黒ドットかを調べる。も
し、そうであったらＣＤＴアドレスをそれぞれ、0x0000
0000 又は 0x7fffffffとする。もし、そうでない場合に
は、先頭ドットが白ドットか黒ドットか（図１６に示し
たＣＤＴの bit３０にて“０”か“１”で指定）に応じ
て、白ドットあるいは黒ドットのランレングスを、例え
ば図１９に示すハフマン・コードで記述する。

【００４４】例えば、図２０の（ａ）に示す６４ドット
のブロックワードＢＷは、同図（ｂ）に示す圧縮コード
に変換される。なお、最後の白ドット（ランレングス＝
１０）は、圧縮コードに含まれないが、最後の黒ドット
（ランレングス＝１９）の後ろは全て白ドットであるこ
とにより復元が可能である。また、ＣＤＴの余った領域
には、１を書き込むようにする。

【００４５】したがって、ラスタライズされたデータに
対するこの可変長可逆圧縮処理を、図１３に示したｔド
ットのブロックワードＢＷが主走査方向又は副走査方向
にｕ個並んだユニットを基本単位として行なう場合の処
理は、次の各ステツプによる。印刷すべきデータを１ペ
ージ分ずつラスタライズするために必要なページバッフ
ァを上記ユニット単位に分割するステップ。その分割し
た各ユニットのデータが全白であるかどうかをチェック
し、その結果をｍビット（図１６では３２ビット）のホ
ワイトマップテーブルに保存するステップ。

【００４６】各ユニット毎にそのデータが全白でない場
合に、ホワイトマップテーブルで指定されるアドレス領
域にｕブロック分のｎビット（図１６では３２ビット）
の圧縮データテーブル（ＣＤＴ）を用意し、ｕ個分のブ
ロック毎のデータの圧縮処理結果を格納するステップ。
各ブロック毎の圧縮処理が不可能な場合に、圧縮データ
テーブル（ＣＤＴ）で指定されるアドレス領域にｔビッ
トの非圧縮データテーブル（ＵＤＴ）を用意し、圧縮処
理が不可能なブロックのデータをそのまま格納するステ
ップ。

【００４７】次に、図１２における「ブロック単位で圧
縮処理」および「圧縮画像の伸長とビデオ信号出力の処
理」において実行されるこの発明によるデータ圧縮方法
及びデータ伸長方法について、図１乃至図６によって説
明する。図１は、ラスタライズされたイメージデータを
この発明によるデータ圧縮方法によって圧縮符号化する
際の処理の流れを示す説明図であり、図２は図１の
（ｄ）に示す符号化ルックアップテーブルを構成する１
つのテーブルのフォーマットの例を示す説明図である。

【００４８】この実施形態として、以下のビットサイズ
での例で説明する。図１の(ａ)，(ｇ)，(ｂ)，(ｄ)に示
すように、圧縮するラスタライズデータの単位：６４ビ
ット（前述の１ブロックワードＢＷ）、圧縮メモリ内の
符号化コード（ＣＤＲ）格納サイズ：３２ビット、ルッ
クアップテーブルの参照データ基準：長８ビット、符号
化ルックアップテーブルのサイズ：１６ビット×２５６
個とする。また、復元化ルックアップテーブルのサイ
ズ：３２ビット×２５６個とする。符号化ルックアップ
テーブル及び復元化ルックアップテーブルは、符号化及
び復元化処理を実行する前に予め作成しておく。

【００４９】符号化ルックアップテーブル内の１テーブ
ル（Ｔable）のフォーマットの例を図２に示す。このテ
ーブルは１６ビット構成であり、上位から８ビットのレ
コードデータ、１ビットのランコンティニュー・フラ
グ、１ビットのユーズレコード・フラグ、３ビットのレ
コードシフト数、および３ビットのイメージシフト数か
らなる。

【００５０】８ビットのレコードデータは符号化された
データ(圧縮コード)である。１ビットのランコンティニ
ュー・フラグは、基準長である８ビットの参照イメージ
データをコード化したとき、コード化可能でありながら
８ビットのレコードデータに収まらず再度判定しなけれ
ばならない部分、すなわち続きがあるかどうかを示すフ
ラグであり、続きがなければ“０”、あれば“１”であ
る（具体例を後述する）。

【００５１】１ビットのユーズレコード・フラグは、レ
コードデータとしてイメージデータを符号化した有効な
データが格納されているか否かを示すフラグで、格納さ
れていれば、このフラグは“１”である。このフラグが
“０”になるのは、参照イメージデータの８ビットが全
て白（“０”）又は黒（“１”）の場合だけである。こ
のときには、その８ビットの参照イメージデータのみで
は符号化するコードが定まらないので、この２つの場
合、すなわち参照イメージデータが“０００００００
０”でその値が「０」、“１１１１１１１１”でその値
が「２５５」のテーブルのレコードデータには意味のあ
るデータは入っていないから、ユーズレコード・フラグ
が“０”になる。

【００５２】３ビットのレコードシフト数は、レコード
データの８ビットのうち何ビットが有効かを示す。例え
ば上位３ビットのみが有効であれば、レコードシフト数
は「３：“０１１”」になる。８ビツト全てが有効であ
れば「８：“１０００”」になるはずであるが、３ビツ
トしかないので“０００”とする。レコードデータが１
ビットも有効でない（全て無効）な場合はユーズレコー
ド・フラグが“０”になるので、このレコードシフト数
は無視する。

【００５３】３ビットのイメージシフト数は、８ビット
の参照イメージデータのうち符号化してレコードデータ
として格納できた有効ビット数を示すもので、上位６ビ
ットが有効であった場合は、イメージシフト数は「６：
“１１０”」になる。これは、今回の符号化は今回参照
した８ビットイメージのうち６ビット分だけ成功し、次
の符号化は７ビット目から始められることを意味する。

【００５４】この図２に示すフォーマットのテーブル
を、８ビットのイメージデータの白ドットと黒ドットの
全ての組み合わせに対して、その各組み合せの値（便宜
上２進化１０数：０〜２５５で表わす）をアドレスとし
て、それぞれ所定のコードテーブルに基づいて、各イメ
ージデータを圧縮（符号化）できる部分まで圧縮したレ
コードデータを格納して作成し、図４に示すような符号
化ルックアップテーブルを、予め作成する。なお、この
図４では、値「４３」から「２５３」は８ビツトイメー
ジも図示を省略し、テーブルの内容は値０〜５，１２，
２６，４２，２５４，２５５のみを図示している。

【００５５】この符号化ルックアップテーブルの作成及
び後述する復号化ルックアップテーブルの作成には、図
６に示すようなランレングス圧縮・復号用の各種のコー
ドテーブルを使用することができるが、この例ではコー
ドテーブル３を使用している。

【００５６】図４において、値が０〜２５４の各８ビツ
トイメージのうち、先頭ビツトから実線で示す枠が囲ん
だ範囲まで、すなわち最後に“０”から“１”へあるい
は“１”から“０”に変わる前のビットまでが符号化可
能な部分であり、Ｗは符号化可能な白ドット（“０”）
の連続数、Ｂは符号化可能な黒ドット（“１”）の連続
数を示している。

【００５７】値が「０」の“００００００００”と値が
「２５５」の“１１１１１１１１”は、変化するところ
がないので、これだけでは符号化できない。したがっ
て、この場合は、前述のようにユーズレコード・フラグ
を“０”にし、コード化可能な続きもないのでランコン
ティニュー・フラグも“０”にする。このような８ビッ
トイメージを含むプロックに対しては、従来と同様に６
４ビットのイメージデータの先頭から“０”又は“１”
が連続する数をカウントしてランレングス圧縮すること
になる。

【００５８】値が「１」の８ビットイメージ“００００
０００１”は、白ドットが７個連続している部分が符号
化可能であり、図６のコードテーブル３によってバリュ
ー７で３ビットの‘０１１’にコード化し、テーブル１
のレコードデータ（Record）にそれを格納する。そし
て、符号化可能なそれ以上のデータはないので、ランコ
ンティニュー・フラグ（ＲＵＮ）は“０”、有効なレコ
ードデータがあるのでユーズレコード・フラグ（ＵＳ
Ｅ）は“１”、レコードデータは上位３ビットが有効な
のでレコードシフト数（ＲＳＦ）は３：“０１１”、８
ビットイメージデータのうち７ビットを符号化してレコ
ードデータとして格納できたので、イメージシフト数
（ＩＳＦ）は７：“１１１”である。

【００５９】値が「１２」の８ビットイメージ“０００
０１１００”は、白ドットが４個連続している部分が３
ビットの“０００”に、次の黒ドットが２個連続してい
る部分が４ビットの“１１００”に符号化可能であり、
その圧縮コードは合計７ビットであるから８ビットのレ
コードデータに収まるので、テーブル１２のレコードデ
ータにそれを格納する。符号化可能なそれ以上のデータ
はないので、ＲＵＮは“０”、有効なレコードデータが
あるのでＵＳＥは“１”、レコードデータは上位７ビッ
トが有効なのでＲＳＦは７：“１１１”、８ビットイメ
ージデータのうち６ビットを符号化してレコードデータ
として格納できたので、ＩＳＦは６：“１１０”であ
る。

【００６０】値が「２６」の８ビットイメージ“０００
１１０１０”は、白ドットが３個連続している部分が４
ビットの“１１０１”に、次の黒ドットが２個連続して
いる部分が４ビットの“１１００”に、次の白ドット１
個及び黒ドット１個がそれぞれ４ビットの“１１１０”
に符号化可能であるが、その圧縮コードは合計１６ビッ
トであるから８ビットのレコードデータに収まるのは、
先頭から図４に破線の枠で示す手前の５ビットまでで、
テーブル２６のレコードデータにはその圧縮コード“１
１０１”と“１１００”を格納する。

【００６１】符号化可能なそれ以上のデータがあるの
で、ＲＵＮは“１”、有効なレコードデータがあるので
ＵＳＥは“１”、レコードデータは８ビット全てが有効
なのでＲＳＦは“０００”、８ビットイメージデータの
うち５ビットを符号化してレコードデータとして格納で
きたので、ＩＳＦは５：“１０１”である。

【００６２】値が「４２」の８ビットイメージ“００１
０１０１０”の場合も、先頭から７ビット目まで符号化
可能であるが、テーブル４２の８ビットのレコードデー
タとしては初めの白ドット２個と黒ドット１個を符号化
した“１１００”と“１１１０”しか収まらないため、
ＲＵＮが“１”になる。このようにして、図４に示す値
「０〜２５５」をそれぞれアドレスとする２５６個のテ
ーブルからなる符号化ルックアップテーブルを完成す
る。

【００６３】その後、この符号化ルックアップテーブル
を使用して、ラスタライズされたイメージデータの圧縮
処理を行なうが、図１を参照してその方法を説明する。
まず、図１の（ａ）に示すラスタライズされた１ブロッ
クワード（６４ビット）のイメージデータの先頭から、
（ｂ）に示すように８ビット分のデータ“００００１１
００”をマージし、（ｄ）に示す符号化ルックアップテ
ーブル中の、その８ビット分のデータの値「１２」に該
当するテーブル１２を参照（ルックアップ）する。

【００６４】図１の（ｅ）に示すテーブル１２のレコー
ドデータには、図４に示したように、その８ビットイメ
ージの内の“００００１１”の部分を符号化したコード
“０００１１００”が最上位からレコードシフト数が示
す７ビットに格納されているので、それを圧縮メモリ内
の３２ビツトの符号化コード（ＣＤＲ）格納エリアの先
頭から７ビットに、圧縮データの最初の部分として格納
する。

【００６５】これの処理によって、６４ビットのイメー
ジデータの内の、テーブル１２のイメージシフト数に示
される６ビット分だけが符号化できたので、次の参照ス
テップでは、その分だけ進めて図１の（ｃ）に示す次の
８ビットの参照イメージデータを得る。この値が「２
６」なので、符号化ルックアップテーブルの内のテーブ
ル２６を参照（ルックアップ）する。

【００６６】図１の（ｆ）に示すテーブル２６のレコー
ドデータには、図４に示したように、その８ビットイメ
ージの内の“０００１１”の部分を符号化したコード
“１１０１１１００”が最上位からレコードシフト数が
示す８ビットに格納されているので、それを圧縮メモリ
内の符号化コード（ＣＤＲ）格納エリアの圧縮データの
続きの部分として格納する。

【００６７】このように、順次イメージデータの符号化
できたビット数だけ進めて、次の８ビットの参照イメー
ジデータを得ながら、その値が示すテーブルを参照し
て、そのレコードデータを圧縮データの続きの部分とし
てＣＤＲ格納エリアに順次格納する処理を、６４ビット
のイメージデータが終了するまで繰り返す。したがっ
て、イメージデータを基準長となる所定ビット数（上述
の例では８ビット）参照して、その中で符号化可能な複
数ビットのデータを一度に符号化できるので、データ圧
縮処理を高速化することができる。

【００６８】次に、このようにして圧縮されたデータを
元のイメージデータに復元するデータ伸長処理について
説明する。まず、そのデータ伸長処理に使用する復元化
ルックアップテーブルについて、図４及び図５によって
説明する。図４は復元化ルックアップテーブル内の１テ
ーブルのフォーマットの例を示す図である。このテーブ
ルは、３２ビット構成であり、２２ビットの復号イメー
ジデータ、１ビットのネクストインバース・フラグ、１
ビットのユーズイメージ・フラグ、３ビットのレコード
シフト数、および５ビットのイメージシフト数からな
る。

【００６９】２２ビットの復号イメージデータは、８ビ
ットの参照レコードデータを復元したものを、最大２２
ビットの復号イメージデータとして格納する。１ビツト
のネクストインバース・フラグは、今回の参照レコード
の復号の際、次のイメージデータの先頭の白黒が、今回
と比べて反転するかどうかを示すフラグである。

【００７０】１ビットのユーズイメージ・フラグは、参
照レコード（圧縮コード）の復元に対して、格納してい
る復号イメージデータを参照するかどうかのフラグで、
複号する際、レコードデータの長さが８ビットを越え、
このテーブルによる復号ができないときに“０”とな
る。このときは、８ビットのレコードデータだけでは復
号できないため、そのテーブルのイメージデータ部には
意味のあるデータは入っておらず、ユーズイメージ・フ
ラグは“０”となる。

【００７１】３ビットのレコードシフト数は、参照した
レコードデータ（圧縮コード）のうち復元できた有効ビ
ット数を示す。５ビットのイメージシフト数は、復号イ
メージデータとして格納しているイメージデータの有効
ビット数を示す。つまり、符号化の場合と同様に、参照
したレコードデータのうちレコードシフト数だけ復号に
成功し、２２ビットの復号イメージデータ部のうち最上
位からイメージシフト数分だけ有効な復号イメージデー
タが入っていて、残りは無意味なデータであることを示
す。

【００７２】図５に復号化ルックアップテーブルの具体
例を示す。この復号化ルックアップテーブルは、値が
「１」から「２５５」までの各８ビットのレコードデー
タに対する図３に示したフォーマットの２５６個のテー
ブルからなる。各８ビットのレコードデータのうち、枠
で囲んだ部分が、符号化に使用した図６に示すコードテ
ーブル３によってそれぞれ復号化可能であり、Ｗは復号
した白ドットの連続数、Ｂは復号した黒ドットの連続数
を示す。

【００７３】例えば、値が「１６」のレコードデータ
“０００１０００”は、最初の“０００”がコードテー
ブル３における“０”で始まる３ビットのコードデータ
でバリューが「４」であるから、白の４ドットに復元で
き、次の“１０００”は上位２ビットが“１０”である
４ビットのコードデータで、バリューが「８」であるか
ら、黒８ビットに復元できる。したがって、復号イメー
ジデータは“００００１１１１１１１１”となる。

【００７４】次のイメージデータの先頭の白又は黒が今
回と比べて反転することはない（次は、今回と同じく白
から始まる）ので、ネクストインバース・フラグ（ＩＮ
Ｖ）は“０”、圧縮コードの復元に際して格納している
復号イメージデータを参照できるのでユーズイメージ・
フラグ（ＵＳＥ）は“１”、レコードデータのうち復元
できた有効ビット数は７ビットなのでレコードシフト数
（ＲＳＦ）は７：“１１１”、復号イメージデータとし
て格納しているイメージデータの有効ビット数は１２ビ
ットなので、イメージシフト数（ＩＳＦ）は１２：“１
１００”である。

【００７５】値が「２４０」以上のレコードデータにな
ると、少なくとも上位４ビットが“１”になるので、図
６のコードテーブル３では９ビット以上のコードデータ
になり、８ビットでは復元できない。したがって、ユー
ズイメージ・フラグは“０”になり。レコードシフト数
は“０００”となり、イメージシフト数は無視する。こ
の場合は、この方法では復号化できないので、従来の方
法で復号化することになる。

【００７６】このような復号化ルックアップテーブルを
予め作成した後、圧縮メモリの各ＣＤＲ格納エリアから
読み出した圧縮コードのレコードデータを、図１によっ
て説明した符号化の場合と同様に、先頭から基準長であ
る８ビットずつ参照して、復号化ルックアップテーブル
内の、その８ビットのレコードデータの値に相当するテ
ーブルを参照（ルックアップ）する。そして、３２ビッ
トのテーブルデータを得て、そこに格納されている復号
イメージデータを復元するイメージデータの最初の部分
として送出し、ビデオバッファにストアさせる。

【００７７】次のステップでは、今回参照したテーブル
のレコードシフト数が示す復元できたビット数だけ進め
て、その次のビットから８ビットのレコードデータにつ
いて、上述と同様な処理を行ない、それを３２ビットの
ＣＤＲレコードデータ（圧縮コード）が終了するまで繰
り返す。それにより、圧縮コードを能率よく元のイメー
ジデータに復元して、図１１に示したビデオ出力部２７
のビデオバッファに展開することができる。

【００７８】このように、この発明によるデータ圧縮方
法及びデータ伸長方法を実施すれば、所定の大きさのイ
メージデータ（例えば６４ビット）やその圧縮コード
（例えば３２ビットのレコードデータ）の符号化及び復
元化を、上位から１ビットずつ“０”か“１”かを判別
して行なう従来の方式に比べ、複数ビットをまとめて符
号化あるいは復元化するため、命令数及びバスアクセス
回数が格段に減り、処理の高速化を計ることができる。
請求項３の発明は、上記発明に対して、Ｌookup Ｔable
を参照する基準データ（符号化の場合は、イメージデー
タ。復元の場合はレコードデータ）のビットサイズを可
変にすることである。

【００７９】また、符号化ルックアップテーブルあるい
は復号化ルックアップテーブルを参照する基準長となる
所定ビット数（参照基準データのサイズ）を可変するこ
とができ、その基準長に応じたルックアップテーブルを
作成することができる。基準長を大きくすれば、ルック
アップテーブルの参照回数が減り、一層処理速度を速め
ることができる。しかし、この基準長すなわち参照基準
データのサイズを大きくすると、当然ルックアップテー
ブルのサイズも大きくなる。参照基準データのサイズを
ｐビットとし、１個のルックアップテーブルのサイズを
ｑビットとすると、ルックアップテーブル全体サイズ
は、２のｐ乗×ｑ／８（Ｂytes）となる。

【００８０】システムのデータ記憶容量、すなわち圧縮
メモリ及び非圧縮メモリ，及びルックアップテーブルの
記憶用メモリとして使用できるメモリの容量を判別し、
その判別した記憶容量に応じて最適な参照基準データの
サイズを決定して、符号化及び復号化用のルックアップ
テーブルを作成することもできる。システムの記憶容量
が大きければ、参照基準データのサイズを大きくできる
ので、当然処理の高速化を計れる。

【００８１】さらに、符号化における圧縮率は文書の種
類（イメージ，文字，線画，グラフィックス等）によっ
て異なることが判っている。そこで、印刷すべき文書の
種類に応じて、ルックアップテーブルを作成する際に使
用する図６に示したような各種のコードテーブルから最
適なもの選ぶようにすれば、最高の圧縮効率が得られる
符号化ルックアップテーブル及び、それによって圧縮さ
れた圧縮コードを復元できる復号化ルックアップテーブ
ルを作成することができるる。

【００８２】

【発明の効果】以上説明してきたように、この発明によ
れば、ページプリンタのメモリ容量を節減でき、低価格
化と高解像度化を可能にすると共に、イメージデータの
圧縮処理及び圧縮コードの伸長（復号）処理の高速化を
図ることが出来る。

【図面の簡単な説明】

【図１】ラスタライズされたイメージデータをこの発明
によるデータ圧縮方法によって圧縮符号化する際の処理
の流れを示す説明図である。

【図２】図１における符号化ルックアップテーブルを構
成する１つのテーブルのフォーマットの例を示す説明図
である。

【図３】圧縮コードの伸張処理に使用する復号化ルック
アップテーブルを構成する１つのテーブルのフォーマッ
トの例を示す説明図である。

【図４】８ビットイメージの種類とその各値と符号化ル
ックアップテーブルの内容との関係を示す図である。

【図５】８ビツトのレコードデータ（圧縮コード）の種
類とその各値と復号化ルックアップテーブルの内容との
関係を示す図である。

【図６】符号化ルックアップテーブル及び復号化ルック
アップテーブルを作成する際に使用するコードテーブル
の異なる例を示す図である。

【図７】この発明を適用したページプリンタを用いた画
像形成システムの構成例を示す図である。

【図８】図７におけるページプリンタの一例を示す外観
図である。

【図９】同じくその内部機構の概略を示す縦断面図であ
る。

【図１０】図９におけるコントローラ基板１９の構成を
示すブロック図である。

【図１１】図７乃至図９に示したページプリンタ２００
におけるＰＳファイルの文書データを印刷するための処
理に係わる部分の機能構成を示すブロック図である。

【図１２】図１１に示した各部により１ページ分の印刷
を行なう際の動作フロー図である。

【図１３】ＰＳフアイルをラスタライズしたデータの１
ユニット（unit）の構成を示す図である。

【図１４】同じくそのブロックワードＢＷのドット数及
び１ユニットのライン数の具体例を示す図である。

【図１５】各ユニットに対するホワイトマップテーブル
（ＷＭＴ）のサイズを示す図である。

【図１６】図１５のＷＭＴに格納する圧縮データテーブ
ル（ＣＤＴ）の構成を示す図である。

【図１７】図１６に示したＣＤＴの実アドレス（ＣＤＴ
アドレス）のレコードの長さを示す図である。

【図１８】非圧縮時のデータ格納メモリアドレス（ＵＤ
Ｔアドレス）をＢＷに格納する場合の説明図である。

【図１９】白ドットあるいは黒ドットのランレングスを
記述するハフマン・コードの説明図である。

【図２０】圧縮コードの変換例を示す図である。

【符号の説明】

１０：感光体ドラム１１：帯電部１２：光書込部１３：現像部１４：転写部１５：定着部１９：コントローラ基板２０：エンジンドライバ基板２１：ホストスクリプト（ＰＳ）インタープリタ２２：圧縮部２３：圧縮メモリ２４：非圧縮メモリ２５：伸長部２７：ビデオ出力部１００：パーソナルコンピュータ１０１：プリンタドライバ２００：ページプリンタ２０１：ＣＰＵ２０６：ＲＡＭ２０８：プリンタエンジン

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成８年８月３０日

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】００５６

【補正方法】変更

【補正内容】

【００５６】図４において、値が０〜２５５の各８ビツ
トイメージのうち、先頭ビツトから実線で示す枠が囲ん
だ範囲まで、すなわち最後に“０”から“１”へあるい
は“１”から“０”に変わる前のビットまでが符号化可
能な部分であり、Ｗは符号化可能な白ドット（“０”）
の連続数、Ｂは符号化可能な黒ドット（“１”）の連続
数を示している。

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】００７２

【補正方法】変更

【補正内容】

【００７２】図５に復号化ルックアップテーブルの具体
例を示す。この復号化ルックアップテーブルは、値が
「０」から「２５５」までの各８ビットのレコードデー
タに対する図３に示したフォーマットの２５６個のテー
ブルからなる。各８ビットのレコードデータのうち、枠
で囲んだ部分が、符号化に使用した図６に示すコードテ
ーブル３によってそれぞれ復号化可能であり、Ｗは復号
した白ドットの連続数、Ｂは復号した黒ドットの連続数
を示す。

Claims

【特許請求の範囲】

【請求項１】ページプリンタにおいて、印刷すべき文
書データを所定の解像度にラスタライズし、そのラスタ
ライズされたイメージデータに対して所定の大きさのブ
ロック単位で可変長可逆圧縮処理を施し、その圧縮コー
ドを圧縮メモリに格納するデータ圧縮方法であって、予め、符号化ルックアップテーブルを参照する基準長と
なる所定ビット数のイメージデータの白ドットと黒ドッ
トの全ての組み合わせに対して、各組み合わせの値をア
ドレスとして、所定のコードテーブルに基づいて各イメ
ージデータを圧縮できる部分まで圧縮したレコードデー
タを格納した符号化ルックアップテーブルを作成してお
き、前記ブロック単位のイメージデータに対して、先頭から
前記所定ビット数のデータについて、その白ドットと黒
ドットの組み合わせによる値で前記符号化ルックアップ
テーブルを参照し、そこに格納されているレコードデー
タを前記圧縮コードの一部として圧縮メモリに格納し、その後、圧縮できなかった残りのイメージデータの初め
から再び前記所定ビット数のデータについて、その白ド
ットと黒ドットの組み合わせによる値で前記符号化ルッ
クアップテーブルを参照し、そこに格納されているレコ
ードデータを前記圧縮コードの続きの部分として前記圧
縮メモリに格納することを、前記ブロック単位のイメー
ジデータの終わりまで繰り返すことを特徴とするデータ
圧縮方法。
【請求項２】ページプリンタにおいて、ラスタライズ
されたイメージデータに対して所定の大きさのブロック
単位で可変長可逆圧縮処理を施して圧縮メモリに格納さ
れた圧縮コードを伸長して元のイメージデータに復元す
るデータ伸長方法であって、予め、復号化ルックアップテーブルを参照する基準長と
なる所定ビット数の圧縮コードの全ての異なる値をそれ
ぞれアドレスとして、所定のコードテーブルに基づいて
各圧縮コードをそれぞれ復元できる部分まで復元したイ
メージデータを格納した復号化ルックアップテーブルを
作成しておき、前記圧縮メモリに格納されている前記ブロック単位のイ
メージデータが圧縮された圧縮コードに対して、先頭か
ら前記所定ビット数の圧縮コードについて、その値で前
記復号化ルックアップテーブルを参照し、そこに格納さ
れているイメージデータを復元するイメージデータの一
部として送出し、その後、復元できなかった残りの圧縮コードの初めから
再び前記所定ビット数の圧縮コードについて、その値で
前記復号化ルックアップテーブルを参照し、そこに格納
されているイメージデータを前記復元するイメージデー
タの続きの部分として送出することを、前記ブロック単
位の圧縮コードの終わりまで繰り返すことを特徴とする
データ伸長方法。
【請求項３】前記符号化ルックアップテーブルを参照
する基準長となる所定ビット数を可変にすることを特徴
とする請求項１記載のデータ圧縮方法。
【請求項４】前記復号化ルックアップテーブルを参照
する基準長となる所定ビット数を可変にすることを特徴
とする請求項２記載のデータ伸長方法。
【請求項５】システムのデータ記憶容量を判別し、そ
の判別した記憶容量に応じて前記基準長となる所定ビッ
ト数を決定することを特徴とする請求項１又は３記載の
データ圧縮方法。
【請求項６】印刷すべき文書データのイメージ，文
字，線画，グラフィックス等の種類に応じて、使用する
コードテーブルを選択的に切り替えて前記符号化ルック
アップテーブルを作成することを特徴とする請求項１，
３，５のいずれか一項に記載のデータ圧縮方法。