JPH06167962A - フォントデータの圧縮方法及び装置 - Google Patents

Abstract

(57)【要約】 【目的】 フォントデータを高効率に圧縮できるフォン
トデータの圧縮方法及び装置を提供することを目的とす
る。 【構成】 ビットマップフォントデータの０又は１のデ
ータのいずれかを増加させるようにフォントデータを変
換し、その変換されたフォントデータにおける増加され
たデータの連続する長さと、増加されないデータを増加
されたデータの数が０としてをコード化する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ビットマップ形式で表
されるフォントデータを圧縮するフォントデータの圧縮
方法及び装置に関するものである。

【０００２】

【従来の技術】複数のドットにより文字或いは図形を構
成するフォントデータを備えたプリンタ装置や表示装置
では、その装置の性能に合わせたデータサイズのフォン
トデータを備えている。例えば１８０ｄｐｉ（ドット／
インチ）の解像度を有するプリンタ装置では、横幅１０
ＣＰＩ（文字／インチ）で、縦幅１０ポイントの文字を
印字するためには、縦２４ドット、横２４ドットのフォ
ントデータが必要になり、この１文字当たりのフォント
データのバイト数は７２バイトになる。又、３６０ｄｐ
ｉのプリンタ装置で同様なデータを印字するためには、
縦４８ドット、横４８ドットのフォントデータが必要に
なり、この場合の１文字当たりのデータ数は２８８バイ
トとなる。

【０００３】このようなフォントデータは、前述した表
示装置やプリンタ装置の解像度に合わせたドット形式で
装置内部のＲＯＭ等に記憶されており、上位装置からの
表示指令信号或いは印字指令信号等によって、文字コー
ドに対応して順次読出され、ビットマップに展開された
後、表示或いはプリントされる。

【０００４】

【発明が解決しようとする課題】このようなフォントデ
ータは、文字の種類及び文字数によりその容量が変化
し、特に漢字のように多くの書体を有し、１つの書体毎
に約８０００文字程度のフォントデータを必要とする文
字の場合にはそのデータ量は膨大なものとなる。更に、
前述した表示装置やプリンタ装置の解像度の増加にとも
ない、１つの文字当たりのフォントデータ量が増大して
いる。これによりフォントデータを記憶するためにより
多くのメモリ（記憶素子）が必要となり、製品コストの
増大、製品の大型化を招く虞がある。

【０００５】本発明は上記従来例に鑑みてなされたもの
で、フォントデータを高効率に圧縮できるフォントデー
タの圧縮方法及び装置を提供することを目的とする。

【０００６】

【課題を解決するための手段】上記目的を達成するため
に本発明のフォントデータの圧縮装置は以下の様な構成
を備える。即ち、ビットマップフォントデータを圧縮す
るフォントデータの圧縮装置であって、ビットマップフ
ォントデータの０又は１のデータのいずれかを増加させ
るようにフォントデータを変換する変換手段と、その変
換されたフォントデータにおける増加されたデータの連
続する長さと、増加されないデータを増加されたデータ
の数が０としてをコード化する符号化手段とを有する。

【０００７】上記目的を達成するために本発明のフォン
トデータの圧縮方法は以下の様な工程を備える。即ち、
ビットマップフォントデータを圧縮するフォントデータ
の圧縮方法であって、ビットマップフォントデータの０
又は１のデータのいずれかを増加させるようにフォント
データを変換する変換工程と、その変換されたフォント
データにおける増加されたデータの連続する長さと、増
加されないデータを増加されたデータの数が０としてを
コード化する工程とを有する。

【０００８】

【作用】以上の構成において、ビットマップフォントデ
ータの０又は１のデータのいずれかを増加させるように
フォントデータを変換し、その変換されたフォントデー
タにおける増加されたデータの連続する長さと、増加さ
れないデータを増加されたデータの数が０としてをコー
ド化する。

【０００９】

【実施例】以下、添付図面を参照して本発明の好適な実
施例を詳細に説明する。尚、本発明は複数の機器から構
成されるシステムに適用しても、１つの機器からなる装
置に適用しても良い。また、本発明はシステム或は装置
に、本発明を実施するプログラムを供給することによっ
て達成される場合にも適用できることは言うまでもな
い。

【００１０】図１は本実施例のフォント圧縮方法により
フォントデータを圧縮できるプリンタ装置の概略構成を
示すブロック図である。尚、この装置は、例えば日本語
ワードプロセッサであっても良いし、ワークステーショ
ン或いはコンピュータシステムであっても良い。

【００１１】図１において、１０２はプリンタ装置全体
を制御するためのＣＰＵで、圧縮フォントを伸長する機
能をも兼ね備えている。１０１は、ＣＰＵ１０２による
各種制御処理の実行時に使用されるワークメモリで、圧
縮されたフォントデータを伸長するために、圧縮された
フォントデータを一時的に記憶したり、伸長されたフォ
ントデータを一時的に保存する。１０３はＲＯＭで、Ｃ
ＰＵ１０２の制御プログラムや各種データを記憶してお
り、更には本実施例の圧縮方法によって圧縮された圧縮
フォントデータをも記憶している。１０４はデータ受信
部で、ホストコンピュータ等の上位装置から送られてく
るデータを受信する。１０５はビットマップメモリで、
印字機構部２０７により印字されるビットマップデータ
が格納されている。このビットマップメモリ１０５に
は、圧縮されたフォントデータを伸長したイメージデー
タもビットマップデータとして展開され、このイメージ
データに基づいて印字機構部２０７による被記録媒体へ
の印刷が行われる。１０６は印字制御部で、印字機構部
２０７のモータの制御及び記録ヘッドの駆動制御などを
行っている。

【００１２】図２は本実施例のフォント圧縮方法により
フォントデータを圧縮できる他の装置の一例である表示
装置の概略構成を示すブロック図である。

【００１３】図２において、２０２は表示装置の全体を
制御するためのＣＰＵで、圧縮フォントを伸長する機能
をも備えている。２０１はＣＰＵ２０２のワークエリア
として使用され、各種データを一時的に保存することが
できる。更にこのワークメモリ２０１には、伸長される
圧縮されたフォントデータが一時的に格納され、この伸
長処理中は、この中で全てのデータが変換される。２０
３はＣＰＵ２０２の制御プログラムや各種データを記憶
しているＲＯＭで、本実施例の圧縮方法によって圧縮さ
れたフォントデータをも記憶している。２０４はデータ
受信部で、ホストコンピュータ等の上位装置からのデー
タを受信する。２０５は表示メモリで、表示部２０７に
表示される表示用データを格納している。この表示用メ
モリ２０５には、フォントデータを伸長したイメージデ
ータがビットマップ展開され、表示部２０７の画面上に
表示される。２０６は表示制御部で、表示部２０７にお
ける表示を制御するために必要な輝度の制御及び表示位
置の制御等を行ている。

【００１４】このようなプリンタ装置或いは表示装置に
搭載される本実施例のフォントデータは、図３に示すよ
うなデータ構成で、ＲＯＭ１０３（２０３）に記憶され
ている。図３はＲＯＭ１０３（２０３）に記憶されてい
るデータ構成を説明するための図である。

【００１５】図３において、３０１はＣＰＵ１０２（２
０２）の制御プログラムが記憶されているエリアであ
り、これら装置はこの制御プログラムに従って制御され
る。３０２は装置の制御に必要なデータが格納されてい
る各種テーブルを示している。３０３はフォントデータ
が記憶されているエリアを示し、このフォントデータ
は、圧縮されたフォントデータ部と、その圧縮されたフ
ォントデータ数及びフォントデータの伸長に必要な各種
データを記憶しているデータテーブル３０４とを備えて
いる。尚、このＲＯＭ１０３（２０３）は、データの容
量、ＲＯＭの容量等により、複数のＲＯＭで構成されて
いても良いことはもちろんである。

【００１６】本実施例では、フォントデータを圧縮する
のに際し、まずドットで表されたフォントデータの白ド
ットを増大させ、その後にそのフォントデータを圧縮し
ている。以下、この圧縮処理について説明する。

【００１７】図５〜図７は、本実施例におけるフォント
データの白ドットの数を増大させるための処理を示す図
である。

【００１８】まず、元のドット形式のフォントデータ
（生フォント）に対して、図７に示すように、ｍ×ｎド
ットのフォントを考えた場合、そのフォントデータを厚
さが１ドットのパターン７０１で囲む。これにより、
（ｍ＋２）×（ｎ＋２）のパターンが形成される。次
に、こうして形成された（ｍ＋２）×（ｎ＋２）のパタ
ーンを、２×２のマトリクスパターン５０１を用いて順
次走査し、各ドットを白から黒、或いは黒から白に変換
する。

【００１９】図５及び図６は、このドット変換処理を説
明するための図である。図５及び図６のドットマトリク
ス５０１において、各ドットをａ，ｂ，ｃ，ｄで表し、
ドットｄに位置しているドットを対象ドット５１０とす
る。これらドットａ〜ｃの値に対応して予測される対象
ドットｄの値が図６に示されている。そして、これら予
測値に対応するドットパターンが図５の５０２〜５０９
で示されている。

【００２０】ここで、前述の図７のドットパターンに対
し、図５のマトリクス５０１を順次当てはめていき、そ
の２×２のドットパターンが図５のパターン５０２〜５
０９のいずれかと一致する場合には、その位置している
マトリクス５０１のドットｄ（５１０）に対応するフォ
ントデータのドットを白（０）に変換する。一方、パタ
ーン５０２〜５０９のいずれとも一致しなかった場合に
は、そのドット５１０に体おするフォントデータのドッ
トを黒（１）に変換する。

【００２１】図４は、このようにして文字“Ｈ”のドッ
トパターンを変換した例を示す図である。

【００２２】ここでは、フォントデータ４０１の周りを
厚さが１ドットのパターン７０１で囲み、そのフォント
データに前述のマトリクス５０１を順次当てはめてい
き、１行の処理が終了すると次行の１番先頭（付加され
たパターン７０１を含めた１番上のデータ）に戻って最
終のドットまで同様の処理を行い、フォントデータ４０
１の各ドットの値を決定する。こうして変換されたドッ
トデータが４０２で示されている。このドットデータ４
０２をみると、元のフォントデータ４０１に比べて、白
ドットの数が増えているのが分かる。そして、４０３は
このドットデータ４０２に基づいて、図８に示す規則に
基づいてコード化した例を示している。

【００２３】図８（Ａ）において、データ数は白ドット
の連続する長さ（データ数）を示し、各データ数に対応
して図のようにオペランドが定められている。いま例え
ば、白データが“２５”ドット連続し、その後に黒ドッ
トがある場合には、そのオペランドは“００１”とな
り、そのデータ部は（２５−２４＝１）より“００００
１”となる。図８（Ｂ）はオペランド部とデータ部とで
構成されるコードのデータフォーマットを示しており、
これにより、この時のコードは“００１００００１”と
なる。

【００２４】また 、黒ドットが４ドット連続する場合
は白ドット数が“０”が３ドット連続している状態で表
される。即ち、白ドットのデータ数“０”はオペランド
“１”、データ部“０００”で表される。これにより、
４ドットの連続する黒ドットは“１０００１０００１０
００”で表される。この場合、残りの１ドットは、前回
のデータがある場合は不要となるが、データが無い場合
には必要となる。ここでは、白のデータについてコード
化して、必ずデータの最後尾には黒データがあるという
条件の元にコード化されている。従って、処理データが
一番最後の時は、最後の黒ドットがあると判断して、処
理を終了する。尚、伸長時には最後の黒は所定データ数
を越えているため表現されない。

【００２５】再び、図４のコードデータ４０３を説明す
ると、ここでは変換されたドットデータ４０２は、垂直
方向に走査されてコード化されており、まず最初の黒ド
ット４１０までには“７４”個の白ドットがあるため、
図８よりオペランドが“０００１”、データ部が（７４
−５６＝１８）“０１００１０”となり、コード“００
０１０１００１０”（４１１）で表される。次に、黒ド
ットが連続しているため、そのコードは前述のようにし
て“１０００”（４１２）と符号化され、次に１６個の
白ドットが連続しているため、“０１１０００”（４１
３）と符号化される。コード４１４は次に連続する黒ド
ット４２０の存在を示し、次のコード４１５はドット４
２０よりドット４３０までの白ドット数“２９”を符号
化したコード“００１００１０１”である。以下、同様
にしてドットパターン４０２を符号化すると、元々５７
６ビットで表されたドットパターンが、４０３に示すよ
うに合計１４１ビットのコードで表現される。

【００２６】次に図９のフローチャートを参照して本実
施例のフォントデータの圧縮処理を説明する。この処理
を実行する制御プロはＲＯＭ１０３（２０３）に記憶さ
れている。

【００２７】まずステップＳ１は、１文字分のフォント
データをＲＯＭ１０３（２０３）より読出してワークメ
モリ１０１のワークエリアに書込む。次にステップＳ２
に進み、ワークメモリ１０１に格納されているフォント
データを、２×２ドットのドットマトリクス５０１単位
で、フォントデータの左端からサーチし、前述の図５に
示すパターン５０２〜５０９と一致するパターンが存在
するかをみる。一致するパターンが存在する時は、その
マトリクス５０１のドット５１０に対応する位置のドッ
トを白ドットに変換する前述した予測関数に基づく処理
を行う。ステップＳ１〜ステップＳ３で、元のフォント
データの全てのドットに対してこの処理を実行する。こ
れにより、例えば図４の４０２で示すドットパターンが
得られる。

【００２８】次にステップＳ４に進み、白データのみで
フォトパターンを表現するために、ステップＳ１〜Ｓ３
で作成されたドットパターンを順次走査し、黒ドットを
検出するまでの白ドットの数を計数する。黒ドットを検
出すると、前述の図８に示すコード化方式に従って、そ
こまでの白ドットの数をコード化する。ステップＳ４〜
ステップＳ６では、変換されたドットパターンの全てに
対して同様の処理を行い、全データをコード化する。

【００２９】こうしてコード化が終了するとステップＳ
７に進み、その圧縮されたフォントデータを、ワークメ
モリ１０１或いは他のメモリ等に書込む。そしてステッ
プＳ８に進み、圧縮されたフォントデータに文字コード
を対応付けてフォントテーブルを作成する。このような
処理を行うことによって、“５７６”ビットの元のフォ
ントデータが、例えば図４のコード４０３で示すように
“１４１”ビットに圧縮されて記憶される。 （第２実施例）図１０は本発明の第２実施例の圧縮方法
を説明するための図である。この第２実施例は、前述の
第１実施例では予測関数を使用して白ドットの数を増大
させていたのに対し、この第２実施例では、フォントデ
ータの上下左右方向に対して排他的論理和を施すことに
より実現している。

【００３０】図１０において、７１０は第１実施例と同
様に２４ドット×２４ドットで構成される文字“Ｈ”の
フォントデータを表している。７１１は後述する処理に
より白ドットの数を増大させて結果を示し、７１２はそ
れをコード化した結果を示している。

【００３１】図１１はこの排他的論理和による白ドット
の数を増大させる処理を説明するための図で、図１１
（Ａ）では、まずフォントデータの縦方向のデータに対
して左右の列データ同士の排他的論理和を取り、その結
果を右側のデータ列にセットする。データの処理は全て
列単位で行い、計算処理後のデータ列も列単位でセット
する。この場合には、一番左端の列のデータは処理され
ずに、元のフォントデータが残ることになる。この処理
をフォントデータ横幅分繰返して処理を終える。次に図
１１（Ｂ）に示すように、フォントデータの行方向のデ
ータ同士の排他的論理和を取り、その結果を下側の行に
セットする処理を各行に対して順次実行する。これによ
り、一番上の行のデータは処理されずに、元のフォント
データが残ることになる。尚、フォントデータが２４×
２４のフォントデータであれば、横方向及び縦方向の処
理回数はいずれも２４回となる。

【００３２】こうして処理された結果が図１０の７１１
で示され、それを前述の第１実施例と同様にしてコード
化した結果が７１２で示されている。

【００３３】次に、この第２実施例の圧縮処理を図１２
のフローチャートを参照して説明する。この処理を実行
する制御プログラムは、ＲＯＭ１０３（２０３）に記憶
されている。

【００３４】ステップＳ１１では、第１実施例のステッ
プＳ１と同様に、元のフォントデータをワークメモリ１
０１（２０１）に読込む。次にステップＳ１２に進み、
このフォントデータの行同士の排他的論理和を取り、そ
の結果を下側の行にセットするようにしてワークメモリ
１０１（２０１）に書込む。ステップＳ１３では、行方
向の全てのデータ処理が終了したかどうかを調べ、行方
向の処理が終了するとステップＳ１４に進み、今度はフ
ォントデータの列データの同士の排他的論理和を取っ
て、その結果が右側の列データとなるようにワークメモ
リ１０１（２０１）に書込む。ステップＳ１５では、列
方向の全データに対する処理が終了したかを判断する。
こうして白ドットの数が増加されたドットパターンが作
成されると、ステップＳ１６〜ステップＳ２０におい
て、前述のステップＳ４〜ステップＳ８と同様にしてコ
ード化されてメモリに格納される。

【００３５】このフローチャートで表された処理によ
り、例えば図１０に示すコードデータ７１２が得られ
る。この場合は、元のフォントデータが５７９ビットで
あったのが、１７１ビットのコードデータに圧縮されて
いる。

【００３６】この第２実施例では、前述の第１実施例と
異なった方法で、フォントデータ中の白ドットを増加さ
せてフォントデータをコード化したが、白ドットを増加
させる方法としては、これ以外にもいかなる方法を使用
しても良い。このように本実施例によれば、白ドットの
数を増大させて白ドットを点在させることにより、フォ
ントデータの圧縮率を向上するものである。

【００３７】次に本発明の第３実施例を説明する。図１
３は第３実施例の処理を示すフローチャートで、この処
理を実行する制御プログラムは、前述のＲＯＭ１０３
（２０３）に記憶されている。

【００３８】まずステップＳ３１で、ＲＯＭ１０３（２
０３）よりフォントデータを読込み、ワークメモリ１０
１（２０１）のワークエリアに格納する。次にステップ
Ｓ３２に進み、前述の第２実施例で使用した排他的論理
和の演算をフォントデータの隣接ドットに対して順次横
方向に行い、ステップＳ３３で処理が終了したかどうか
を判断する。ステップＳ３４でも同様に、前述の第２実
施例で使用した排他的論理和を、縦方向に隣接するドッ
ト同士に実施し、ステップＳ３５でその処理が終了した
かどうかを判断する。

【００３９】こうしてステップＳ３６に進み、前述の上
下・左右方向に排他的論理和を取って白ドットを増加さ
せたドットパターンに対して、行方向に左側より、上下
方向には上側から順番に黒ドットを検索する。こうして
黒ドットを発見すると、その黒ドットに隣接している黒
ドットがあるかどうかを判断する。その結果、ステップ
Ｓ３８では、図１４〜図１６に示すように、ドットのＸ
方向（横方向）１４０、Ｙ方向（縦方向）１４１、次の
黒データの存在する方向を示すデータ１４２からなる３
種類のデータで表現する。次の黒データの方向を示すデ
ータは、隣接データが連続して存在する場合には図１４
で示されている内容が連続して記述される。

【００４０】例えば図１５に示すように、現在位置指定
されているドット１５０と、次に黒データ１５１とが図
のような位置関係にある時は、次のデータの方向を示す
データは１５２で示すように、方向データ１４２の右方
向を示すビットのみが“１”となって示される。また、
方向が「右斜め上」、「右斜め下」、「左斜め上」、
「左斜め下」の場合には、例えば方向が「右斜め上」の
時には、データ１４２の「右」と「上」に対応する複数
のビットがオンになることにより指定される。又
「左」、「右」、「上」、「下」のいずれかの場合に
は、次のデータの方向データ１４２のいずれか１ビット
だけがオン（１）になる。更に、次のデータの方向デー
タ１４２のビットが全て“０”の場合には、連続するデ
ータが無いことを示している。

【００４１】この第３実施例により、図４或いは図１０
の文字“Ｈ”をコード化した結果が図１６に示されてい
る。尚、この場合も、コード化のアルゴリズムは前述の
実施例の場合と同様である。これにより、例えば５７６
ビットのフォントデータが、２８８ビットのコードに圧
縮される。

【００４２】尚、前述の実施例では、フォントデータの
白ドットを増加させるために、ドットパターンに縦横方
向の排他的論理和を用いたが、前述の第１実施例で使用
した予測関数、或いはその他の方法を用いて白ドットを
増加させてもよい。

【００４３】又、白ドットを増加させる方法としては、
前述した実施例の方法に限らず、種々の方法が適用でき
る。又本実施例では、白ドットの数を増加させたが、黒
ドットの数を増加させても良い。

【００４４】本実施例は２つの白ドットを増加させる方
法（予測関数法、上下左右の排他的論理和）について記
載したが、その方法はいかなる方法であっても良い。ま
た文字種等によっては、白ドットの数を増加させること
なく、白及び黒ドット単独で表現することもできる。

【００４５】又コード化の手法についても、第３実施例
で示すように、フォントデータの中の黒又は白データに
着目して圧縮する手法を施すものであれば、どのような
コード化処理を採用しても良い。

【００４６】以上説明したように本実施例によれば、黒
又は白、単独のデータでフォントデータをコード化して
圧縮することにより圧縮率が向上し、フォントデータを
搭載する装置の記憶素子の容量を減少させることができ
る。

【００４７】又、本実施例のフォント圧縮方法によれ
ば、伸長処理を簡素化できる。

【００４８】

【発明の効果】以上説明したように本発明によれば、フ
ォントデータを高効率に圧縮できる効果がある。

【図面の簡単な説明】

【図１】本実施例のフォントデータの圧縮及び伸長処理
を実行できるプリンタ装置の概略構成を示すブロック図
である。

【図２】本実施例のフォントデータの圧縮及び伸長処理
を実行できる表示装置の概略構成を示すブロック図であ
る。

【図３】本実施例の装置のＲＯＭのデータ構成を示す図
である。

【図４】本発明の第１実施例による文字パターンの白ド
ット数の増加及びコード化の具体例を示す図である。

【図５】本発明の第１実施例における予測関数値に対応
するドットパターンを説明するための図である。

【図６】本発明の第１実施例における予測関数値を示す
図である。

【図７】本発明の第１実施例におけるフォントデータの
切り出しを説明するための図である。

【図８】本発明の実施例におけるフォントデータのコー
ド化を説明するための図である。

【図９】本発明の第１実施例におけるフォントデータの
白ドット数の増大及びコード化処理を示すフローチャー
トである。

【図１０】本発明の第２実施例による文字パターンの白
ドット数の増加及びコード化の具体例を示す図である。

【図１１】本発明の第２実施例におけるフォントデータ
の白ドット数を増大する処理を説明するための図であ
る。

【図１２】本発明の第２実施例におけるフォントデータ
の白ドット数の増大及びコード化処理を示すフローチャ
ートである。

【図１３】本発明の第３実施例におけるフォントデータ
の白ドット数の増大及びコード化処理を示すフローチャ
ートである。

【図１４】本発明の第３実施例における黒ドットの位置
を示すデータを説明するための図である。

【図１５】第３実施例における次の黒データを示すデー
タ説明するための図である。

【図１６】本発明の第３実施例により図４或いは図１０
の文字フォントを圧縮した結果を示す図である。

【符号の説明】

１０１，２０１ ワークメモリ １０２，２０２ ＣＰＵ １０３，２０３ ＲＯＭ １０４，２０４ データ受信部 １０５ ビットマップメモリ １０６ 印字制御部 １０７ 印字機構部 ２０５ 表示用メモリ ２０６ 表示制御部 ２０７ 表示部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁵ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｇ０６Ｆ 15/20 ５６２ Ｎ 9288−5Ｌ

Claims (5)

【特許請求の範囲】
1. 【請求項１】 ビットマップフォントデータを圧縮する
   フォントデータの圧縮方法であって、 ビットマップフォントデータの０又は１のデータのいず
   れかを増加させるようにフォントデータを変換する変換
   工程と、 その変換されたフォントデータにおける増加されたデー
   タの連続する長さと、増加されないデータを増加された
   データの数が０としてをコード化する工程と、を有する
   ことを特徴とするフォントデータの圧縮方法。
2. 【請求項２】 前記変換工程は、予測関数に基づいてフ
   ォントデータの０又は１のデータのいずれかを増大させ
   ることを特徴とする請求項１に記載のフォントデータの
   圧縮方法。
3. 【請求項３】 前記変換工程は、フォントデータの行又
   は列同士の排他的論理和によりフォントデータの０又は
   １のデータのいずれかを増大させることを特徴とする請
   求項１に記載のフォントデータの圧縮方法。
4. 【請求項４】 前記変換工程は、フォントデータの行又
   は列方向に隣接するドット同士の排他的論理和によりフ
   ォントデータの０又は１のデータのいずれかを増大させ
   ることを特徴とする請求項１に記載のフォントデータの
   圧縮方法。
5. 【請求項５】 ビットマップフォントデータを圧縮する
   フォントデータの圧縮装置であって、 ビットマップフォントデータの０又は１のデータのいず
   れかを増加させるようにフォントデータを変換する変換
   手段と、 その変換されたフォントデータにおける増加されたデー
   タの連続する長さと、増加されないデータを増加された
   データの数が０としてをコード化する符号化手段と、を
   有することを特徴とするフォントデータの圧縮装置。