JP2004240125A

JP2004240125A - Font compressor, font expander, font compression method, and font expansion program

Info

Publication number: JP2004240125A
Application number: JP2003028674A
Authority: JP
Inventors: Takashi Kurumisawa; 孝胡桃澤; Masanori Ishida; 正紀石田
Original assignee: Seiko Epson Corp
Current assignee: Seiko Epson Corp
Priority date: 2003-02-05
Filing date: 2003-02-05
Publication date: 2004-08-26

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently compress bit map font used in a cellular phone, PDA, etc., by each of fonts. <P>SOLUTION: The font compressor is equipped with a dividing means which divides the bit map fonts to be compressed to a plurality of lines in a vertical or horizontal direction, a line command determining means which determines the line commands corresponding to pixel data arrangements constituting the lines obtained by the division with respect to the lines and a compressed font data forming means which expresses the pixel data arrangements constituting the respective lines by the compressed font data including the command data indicating the line commands determined relating to the lines. The bit map fonts can be compressed in font units by expressing the bit map fonts with the line commands by each of the lines. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、ビットマップフォントの圧縮方法に関する。
【０００２】
【背景技術】
携帯電話やＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）などの装置では文字などの表示にビットマップフォントが使用される。ビットマップフォントは、予め用意された画素の配列パターンにより文字や記号などを表示するものである。ベクトルデータの集合として文字や記号などを表示するアウトラインフォントと異なり、ビットマップフォントは単純な画素の配列パターンであるため、１文字当たりのデータ量が小さい。そのため、表示エリアの画素数が比較的少ない携帯電話やＰＤＡなどにおいては、ビットマップフォントが使用される。
【０００３】
携帯電話やＰＤＡなどの携帯型端末装置では、フォントデータを記憶するＲＯＭなどの容量に制限があるため、フォントデータを圧縮して記憶することが望ましい。この観点から、複数の文字フォントデータ間の差分を利用して、フォントデータを圧縮する手法が提案されている（例えば特許文献１参照）。また、入力データを構成する複数の文字列中の出現頻度に着目して、入力データを効率的に圧縮する手法も提案されている（例えば特許文献２参照）。
【０００４】
【特許文献１】
特開平９−１６１４８号公報
【特許文献２】
特開平８−２２３０５４号公報
【０００５】
【発明が解決しようとする課題】
上記の圧縮手法は、複数の文字フォント間の差分などを利用してデータ圧縮を行うため、フォント１文字単位での圧縮ができない。従って、携帯型端末装置などにおいて、ある特定の１文字の表示が必要となった場合でも、その文字以外の伸張処理を実行しなければならないことになる。しかし、携帯型端末装置などは、搭載しているＣＰＵの能力にも制限があるため、できる限り余計な伸張処理を行うことは避けたい。即ち、携帯型端末装置などにおいては、１文字毎にフォントデータを圧縮して記憶しておき、必要なフォントデータのみを効率的に伸張処理して表示できることが望ましい。
【０００６】
本発明は、以上の点に鑑みてなされたものであり、携帯電話やＰＤＡなどで使用するビットマップフォントデータを１文字毎に効率的に圧縮することを課題とする。
【０００７】
【課題を解決するための手段】
本発明の１つの観点では、フォント圧縮装置は、圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割手段と、分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定手段と、各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成手段と、を備える。
【０００８】
上記のフォント圧縮装置によれば、圧縮の対象となるビットマップフォントを縦又は横のライン毎に分割し、各ライン毎に圧縮処理を行う。具体的には、ライン毎の画素データ配列を表現するラインコマンドを決定し、ラインコマンドに対応するコマンドデータにより当該ラインを表現する。これにより、画素データ配列をデータ量の小さいコマンドデータで表現することができ、フォントデータの圧縮が可能となる。
【０００９】
上記のフォント圧縮装置の一態様は、前記圧縮の対象となるビットマップフォントを、前記縦又は横方向に一様にシフトさせるシフト手段を備える。圧縮の対象となるビットマップフォントを縦又は横方向にシフトさせることにより、ラインコマンドによりさらに効率的にデータを圧縮することができるように画素データ配列を変化させることができる。
【００１０】
上記のフォント圧縮装置の他の一態様は、前記圧縮の対象となるビットマップフォントを、上下又は左右方向に反転し、若しくは所定の角度だけ回転させる手段を備える。シフトの代わりに、ビットマップフォント全体を反転又は回転することによっても、画素データ配列を変化させ、ラインコマンドによる圧縮率をさらに向上させることができる。
【００１１】
上記のフォント圧縮装置の他の一態様では、前記圧縮フォントデータは、前記ラインコマンド毎に生成され、当該ラインを構成する画素データ配列を示す引数データを含むことができる。よって、ラインコマンドにより当該ラインの画素データ配列の特徴を特定し、引数データにより具体的な画素データ配列を表現することができる。
【００１２】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドは、対象となるラインの画素データ配列をランレングス符号化して表現するためのランレングスラインコマンドを含むことができる。また、前記ランレングスラインコマンドは、白画素から開始するラインに対応する白ランレングスラインコマンドと、黒画素から開始するラインに対応する黒ランレングスラインコマンドとを含むことができる。
【００１３】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドは、対象となるラインの画素データ配列をそのまま引数データとするオリジナルコマンドを含むことができる。これにより、ランレングス符号化により得られる圧縮データがオリジナルデータよりも大きくなる場合には、当該ラインについてはオリジナルデータをそのまま引数データとして、フォント全体のデータ量を小さくすることができる。
【００１４】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドは、対象となるラインの画素データ配列が１つ前のラインの画素データ配列と完全同一であることを示すコピーコマンドを含むことができる。これにより、同一の画素データ配列を有するラインが並んでいる場合に、重複した圧縮データの記述を省略し、圧縮率をより向上させることができる。
【００１５】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドを示すコマンドデータは、圧縮の対象となるビットマップフォント中における当該ラインコマンドの使用回数に応じてハフマン符号化することができる。これにより、頻繁に使用するラインコマンドには短いコマンドデータを用い、あまり使用しないラインコマンドには長いコマンドデータを用いて、ラインコマンド部分のデータ量を小さくすることができる。
【００１６】
上記のフォント圧縮装置の他の一態様では、前記圧縮フォントデータは、前記シフト手段によるシフト量、前記ラインコマンドの種類及び前記複数のラインに対応するラインコマンド列を含むコマンド記述部と、前記複数のラインについて各ラインを構成する画素データ配列を示す引数データを含む圧縮データ部と、により構成することができる。
【００１７】
本発明の他の観点では、上記のフォント圧縮装置により生成された圧縮フォントデータを記憶する記憶部と、前記ラインコマンド及び対応する引数データに基づいて、前記複数のラインを構成する画素データ配列を生成する手段と、生成された複数のラインについての画素データ配列を前記シフト量に従ってシフトすることにより、前記圧縮の対象となるビットマップフォントを再現する手段と、を備えるフォント伸張装置を提供することができる。このフォント伸張装置によれば、上述のフォント圧縮装置による圧縮処理で決定されたシフト量、ラインコマンドなどを利用して、効率的にフォントデータを伸張することができる。
【００１８】
本発明の他の観点では、圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割工程と、分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定工程と、各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成工程と、を有するフォント圧縮方法を提供することができる。このフォント圧縮方法を実行することにより、上述のフォント圧縮装置と同様のフォント圧縮処理が可能となる。
【００１９】
本発明の他の観点では、コンピュータ上で実行されることにより、圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割手段、分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定手段、各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成手段として前記コンピュータを機能させるフォント圧縮プログラムを提供することができる。このフォント圧縮プログラムをコンピュータ上で実行することにより、上記のフォント圧縮装置を実現することができる。
【００２０】
【発明の実施の形態】
以下、図面を参照して本発明の好適な実施の形態について説明する。
【００２１】
［携帯端末装置の構成］
図１に、本発明の実施形態にかかるビットマップフォントの圧縮方法を適用した携帯端末装置の概略構成を示す。図１において、携帯端末装置１０は、例えば携帯電話やＰＤＡなど、画像表示エリアが比較的小さい端末装置である。携帯端末装置１０は、表示部１２と、処理フォントメモリ１４と、ＣＰＵ１６と、入力部１８と、プログラムＲＯＭ２０と、フォントＲＯＭ２２と、ＲＡＭ２４とを備える。一方、本発明によるフォント圧縮方法によるフォント圧縮データは、フォント圧縮装置５により生成される。フォント圧縮装置５は、コンピュータなどの端末装置であり、フォント圧縮プログラムを実行することにより圧縮フォントデータを生成する。実際には、フォント圧縮装置５は、携帯端末装置１０の製造元などに存在し、生成した圧縮フォントデータをフォントＲＯＭに格納した状態で携帯端末装置１０を製造、販売などする場合が多い。但し、フォント圧縮装置５が生成した圧縮フォントデータのみを流通することも可能である。
【００２２】
表示部２２は、例えばＬＣＤ（ＬｉｑｕｉｄＣｒｙｓｔａｌＤｉｓｐｌａｙ：液晶表示装置）などの軽量、薄型の表示装置とすることができ、表示エリア内にビットマップフォントにより構成される文字を表示する。
【００２３】
入力部１８は、携帯電話であれば各種の操作ボタンなど、ＰＤＡであればタッチペンなどによる接触を検出するタブレットなどにより構成することができ、ユーザが各種の指示、選択を行う際に使用される。入力部１８に対して入力された指示、選択などは、電気信号に変換されてＣＰＵ１６へ送られる。
【００２４】
プログラムＲＯＭ２０は、携帯端末装置１０の各種機能を実行するための各種プログラムを記憶し、特に本実施形態ではビットマップフォントの伸張プログラム（以下、「フォント伸張プログラム」と呼ぶ。）、ビットマップフォントの拡大・縮小プログラム（以下、「フォント拡大・縮小プログラム」とも呼ぶ。）、及び、ビットマップフォントを利用した文字の表示プログラムなどを記憶している。
【００２５】
フォントＲＯＭ２２は、ビットマップフォントの元データ（「字母データ」とも呼ぶ。）を、圧縮フォントデータとして記憶する。圧縮フォントデータは、携帯端末装置１０の外部のフォント圧縮装置５により生成され、フォントＲＯＭに記憶される。本実施形態では、サイズが１２、１６、２０、２４、２８及び３２ドットの字母データをそれぞれ圧縮し、圧縮フォントデータとして保存している。
【００２６】
なお、ビットマップフォント字母データは、例えば１６×１６ドットなどの、縦横比が等しいフォント（「正方フォント」とも呼ぶ。）とすることが一般的である。各字母データに対応する圧縮フォントデータは、圧縮前のフォントデータから後述のフォント圧縮処理により生成され、フォントＲＯＭ２２に記憶されている。
【００２７】
ＲＡＭ２４は、フォント伸張プログラムに従って、ビットマップフォントの圧縮フォントデータを伸張処理する際に作業用メモリとして使用される。一方、処理フォントメモリ１４は、フォント伸張プログラムによる伸張処理により作成された上記の各サイズの字母データを一時的に記憶するメモリである。処理フォントメモリ１４は、通常、ＲＡＭやフラッシュメモリなどにより構成することができ、携帯端末装置１０が電源オフされるまで記憶内容を保持する。
【００２８】
また、ＲＡＭ２４は、フォント伸張プログラムにより得られた字母データを、フォント拡大・縮小プログラムにより所定のサイズに拡大・縮小する際にも作業用メモリとして使用される。
【００２９】
ＣＰＵ１６は、プログラムＲＯＭ２０内に記憶されている各種プログラムを実行することにより、携帯端末装置１０の各種機能を実行する。特に、本実施形態では、プログラムＲＯＭ２０内に記憶されているフォント伸張プログラムを読み出して実行することにより、圧縮フォントデータから字母データを生成し、さらに必要に応じてフォント拡大・縮小プログラムを実行して字母データから所望のサイズの処理フォントを生成する。そして、文字表示プログラムを実行することにより、文字を表示部１２上に表示させる。なお、ＣＰＵ１６は、これら以外に各種のプログラムを実行することにより携帯端末装置１０の各種機能を実現するが、それらは本発明とは直接の関連を有しないので、説明を省略する。
【００３０】
本実施形態では、サイズが１２、１６、２０、２４、２８及び３０ドットの字母データをそれぞれ圧縮フォントデータとしてフォントＲＯＭ２２に記憶しておき、これに対して必要に応じてフォント伸張処理とフォント拡大・縮小処理を実行することにより、携帯端末装置１０上に１０〜２１ドットまでの任意のサイズのフォントを表示可能とする。例えば、表示すべきフォントのサイズが予め用意された字母データのサイズと一致する場合（つまり、１２、１６、２０、２４又は３０ドットである場合）には、対応する圧縮フォントデータを伸張処理することにより必要なサイズのフォントデータが得られる。一方、字母データのサイズと異なるサイズのフォントが必要とされる場合には、上記の字母データのうち近いサイズのものに対してフォント拡大・縮小処理を実行して必要なサイズのフォントデータを生成する。例えば、１３ドットのフォントデータが必要とされる場合は、フォント伸張処理により圧縮フォントデータから１２ドットの字母データを生成し、それをフォント拡大処理により１３ドットに変換する。また、１５ドットのフォントデータが必要とされる場合は、フォント伸張処理により圧縮フォントデータから１６ドットの字母データを生成し、フォント縮小処理により１５ドットのフォントデータを生成する。なお、携帯端末装置１０上で必要とされるフォントデータのサイズは、利用者の指定や利用者が使用するプログラムの要求などに応じて決定されることになる。
【００３１】
なお、本実施形態では、基本的にはフォント圧縮処理により得られたフォントデータを圧縮フォントデータと呼ぶ。後述のように、フォント圧縮処理において本発明による圧縮手法を適用した方が却って１フォントあたりのデータ量が増加してしまう場合もあり、その場合には当該フォントは本発明によるフォント圧縮手法を適用しない、即ち未圧縮のままフォントＲＯＭ２２に格納されることとなるが、本実施形態では、説明の便宜上、そのような未圧縮のままフォントＲＯＭ２２に格納されているフォントデータも含めて圧縮フォントデータということがある。
【００３２】
［フォント圧縮方法］
次に、本発明のフォント圧縮処理により得られた圧縮フォントデータについて説明する。前述のように、本実施形態では、サイズが１２、１６、２０、２４、２８及び３０の字母データに対応する圧縮フォントデータがそれぞれ用意される。例えば１２ドットの字母データに対応する圧縮フォントデータは、縦横が１２ドット×１２ドットのビットマップフォントに対して本発明の圧縮方法を適用して得られたデータである。ｎ×ｎドットのビットマップフォントは、縦横ｎドットの正方形に配列された各ドットが黒（「１」）又は白（「０」）のいずれかにセットされたデータの集合として構成される。
【００３３】
本実施形態のフォントデータ圧縮方法の基本的な原理及び特徴を以下に説明する。
【００３４】
（１）基本原理
まず、本実施形態のフォントデータ圧縮方法は、圧縮の対象となるビットマップフォントを横方向の複数のラインに分割し、ライン毎のデータ（すなわち、黒のドットと白のドットの配列）をラインコマンドにより表現する。ラインコマンドとは、ビットマップフォントの１ライン（横方向の一行）のデータ内容を表現するために用意されるコマンドである。各ラインのデータ内容を表現するラインコマンド及びそのラインコマンドの引数データの合計が元のデータのビット数より小さくなるようにラインコマンドを設定すれば、全体として１ライン分のデータ量を圧縮することができる。
【００３５】
（２）ラインコマンド
ラインコマンドにおいては、ランレングス圧縮を行う。即ち、１ライン中に含まれる黒ドットの連続（黒線分）と白ドットの連続（白線分）をそれぞれの長さで表現することによりデータ量を圧縮する。ここで、ランレングスコマンドとしては、黒ドットから開始する１ラインを表現するための「黒ランレングスコマンド」と、白ドットから開始する１ラインを表現するための「白ランレングスコマンド」の２種類を用意する。各ラインのデータ内容は黒ドットと白ドットの繰り返しであるので、ある１ラインが黒ドットで始まるか白ドットで始まるかを規定しておき、あとはそのライン内に繰り返し現れる黒線分と白線分の長さをそのランレングスコマンドの引数データとして示せば、そのラインのデータ内容を全て表現できることになる。単純な例として、全部で１０ドットからなる１ラインが、
「黒」「黒」「黒」「白」「白」「白」「白」「黒」「黒」「黒」
というデータ内容である場合、このラインは、▲１▼黒ドットで開始すること、▲２▼各線分の長さが「３」、「４」、「３」であること、の２つの条件により表現することができる。このように、黒ランレングスコマンド及び白ランレングスコマンドを利用すれば、黒ランレングスコマンドと白ランレングスコマンドのいずれであるか、及び、各線分の長さを示す引数データにより１ラインを表現することができる。この場合、黒ドットで開始することを示すコマンドとして黒ランレングスコマンドが使用され、その後の線分の長さを示すデータが当該ラインコマンドの引数データとして使用される。即ち、１ラインをラインコマンドで表現する場合、ラインコマンドはそのラインのデータ配列の種類を特定する役割を有し、引数データは実際のデータ配列を示す役割を有する。
【００３６】
なお、ランレングスコマンドにおいて、黒又は白の線分の長さは２進数で表わされ、短い線分ほど少ないビット数で表現することができる。例えば１ラインが３２ドットである場合、ランレングスコマンドの引数データは、１０進数で１〜３２であり、これを２進数の「１」〜「１１１１１」に対応付ける。これにより黒又は白の線分の長さは、２進数で以下のビット数で表現できる。
【００３７】
線分の長さ（１０進数）引数データ（２進数）ビット数
１ドット「１」１ｂｉｔ
２〜３ドット「１０〜１１」２ｂｉｔ
４〜７ドット「１００〜１１１」３ｂｉｔ
８〜１５ドット「１０００〜１１１１」４ｂｉｔ
１６〜３２ドット「１００００〜１１１１１」５ｂｉｔ
また、本実施形態では、ラインコマンドとして、「オリジナルコマンド」を定義する。オリジナルコマンドとは、そのラインのデータが、圧縮の対象となる１ラインの白黒のデータ（以下、「オリジナルデータ」と呼ぶ。）そのままであることを示す（即ち、圧縮処理をしていない）コマンドである。ある１ラインをランレングス処理により表現した場合に、そのラインのドット数や白黒の配列パターンによっては、オリジナルデータよりビット数が大きくなってしまう場合もあるので、その場合にはオリジナルデータをそのまま圧縮せずに使用するものである。
【００３８】
さらに、本実施形態では、ラインコマンドとして、「コピーコマンド」を定義する。コピーコマンドとは、そのラインのデータ内容が１つ前のラインと完全同一であることを示す。これにより、１つの前のラインと同一のラインは、コピーコマンドのみで表現でき、引数データが不要となるのでデータ量をより圧縮できる。
【００３９】
以上より、本実施形態で使用するラインコマンドは以下の４種類となる。
【００４０】
・オリジナルコマンド：
引数データはオリジナルのデータであることを表す。（圧縮されていない）
・コピーコマンド：
引数データは１つ前のラインと完全同一であることを表す。
【００４１】
・黒ランレングスコマンド：
引数データは黒開始でその長さが白黒順番に記述されていることを表す。
【００４２】
・白ランレングスコマンド：
引数データは白開始でその長さが白黒順番に記述されていることを表す。
【００４３】
（３）面コマンド（シフトコマンド）
さらに、本実施形態のフォント圧縮方法では、圧縮対象となるビットマップフォント全体に面コマンドを適用する。面コマンドの代表的な例は「シフトコマンド」である。シフトコマンドとは、ランレングスコマンドにより表現されるデータ量が小さくなるように、圧縮対象となるビットマップフォントのドットを全てのラインについて一様に横方向にシフトするコマンドである（図６を参照）。ランレングス圧縮の場合、白又は黒のデータが長く連続するほうが、白と黒が頻繁に繰り返す場合よりも圧縮効率が増加する。よって、圧縮対象となるビットマップフォント全体を適切なドット数だけシフトして白や黒のドットがより長く連続するようにすれば、ランレングスコマンドにより表現されるデータ量が小さくなり、全体としての圧縮率が向上する。
【００４４】
なお、シフトコマンドは横方向のみでなく、縦方向に適用することもできるし、縦横両方向のシフトコマンドを同時に適用することも可能である。また、面コマンドとしては、シフトコマンドのほかに、処理対象となるビットマップフォント全体を左右又は上下に反転させる反転コマンドや、ビットマップフォントの中央を回転中心として所定角度（例えば９０度、１８０度など）だけ回転させる回転コマンドなどを適用して、ランレングスコマンドにより表現されるデータ量を減少させることもできる。上記のシフトコマンド、反転コマンド、回転コマンドなどは、ライン単位のラインコマンドと異なりフォント全体に対して一様に適用されるという意味で、面コマンドと呼んでいる。
【００４５】
［圧縮データ構造］
次に、本実施形態のフォント圧縮方法により得られる圧縮フォントデータのデータ構造について説明する。
【００４６】
図２（ａ）に圧縮フォントデータのデータ構造を模式的に示す。圧縮フォントデータ７０は、コマンド記述部７２と、圧縮データ部７４により構成される。本実施形態のフォント圧縮方法では、前述のように圧縮の対象となるビットマップフォントを横方向の複数のラインに分割し、各ラインのデータをライン毎に所定のラインコマンドで表現する。コマンド記述部７２は、圧縮の対象となるビットマップフォント（字母データ）をラインコマンドで記述する際のルールなどを規定する情報を含む。
【００４７】
コマンド記述部７２のデータ構造例を図２（ｂ）に示す。図示のように、コマンド記述部７２は、「シフト数」、「コマンドタイプ」、「コマンド組み合わせＩＤ」、及び「コマンド列」を含んで構成される。「シフト数」は、前述のシフトコマンドによりフォント全体をシフトするドット数を示す。図６にシフトコマンドによるビットマップフォントのシフト例を示している。図６（ａ）は漢字の「乙」という文字のシフト前の状態を示し、図６（ｂ）はシフトコマンドにより７ドット分のシフトを行った後の状態を示す。シフト数は、圧縮の対象となるフォントの１ラインのドット数（即ち横幅）の１／２以下の数とし、シフト方向を指定するビットを付加することにより最小のビット数で表現することができる。
【００４８】
「コマンドタイプ」は、ラインコマンドのタイプを示し、具体的には、その圧縮フォントデータで使用されているラインコマンドが固定長コマンドであるか、可変長コマンドであるかを示す。例えば、コマンドタイプは、固定長コマンドの場合「０」、可変長コマンドの場合「１」と設定することができ、１ビットで表現される。固定長コマンドの場合、ラインコマンドのコマンドデータ長は全て固定長となる。なお、後述のように、可変長コマンドの場合、ラインコマンド毎にコマンドデータ長が異なるように規定される。実際には、各ラインコマンドの使用頻度に基づいてハフマン符号化を適用し、使用頻度の高いラインコマンドほどコマンドデータ長が短く、使用頻度の低いラインコマンドほどコマンドデータ長が長くなるように規定する。
【００４９】
「コマンド組み合わせＩＤ」は、その圧縮フォントデータに使用されているラインコマンドの組み合わせと、各コマンドのコマンドデータ長との関係を規定している。コマンド組み合わせＩＤの例を図３に示す。図３（ａ）はコマンドタイプが固定長コマンドである場合のコマンド組み合わせＩＤの例を示す。コマンドタイプが固定長コマンドの場合、コマンド組み合わせＩＤは、「０ｘ００」と「０ｘ０１」の２種類のいずれかとなり、１ビットで表現される。コマンド組み合わせＩＤが「０ｘ００」の場合は、ラインコマンドはコピーコマンドとオリジナルコマンドの２種類のみであるので、コマンド長は１ビットで表現できる。一方、コマンド組み合わせＩＤが「０ｘ０１」の場合は、ラインコマンドはオリジナルコマンド、コピーコマンド、黒ランレングスコマンド及び白ランレングスコマンドの４種類を使用するので、各ラインコマンドのコマンド長は２ビット必要となる。いずれの場合でも、コマンドタイプが固定長コマンドであるので、各ラインコマンドのコマンドデータ長は等しい。
【００５０】
図３（ｂ）はコマンドタイプが可変長コマンドである場合のコマンド組み合わせＩＤの例を示す。コマンドタイプが可変長コマンドである場合、各ラインコマンドは組み合わせＩＤに応じて、図４に示すようにハフマン符号化される。即ち、圧縮の対象となるビットマップフォントを構成する複数のラインのデータ内容を分析した上で、最も使用頻度の高いラインコマンドに短いコマンドデータ（０ｂ）が割り当てられ、使用頻度が低下する順に長いコマンドデータ（１０ｂ、１１０ｂ、１１１ｂ）が割り当てられるようなコマンド組み合わせＩＤがビットマップフォント毎に設定される。
【００５１】
図２（ｂ）に戻り、「コマンド列」は実際のビットマップフォントの各ライン毎に設定されたラインコマンドの列であり、図３に示すように、圧縮の対象となるビットマップフォントのライン数分のラインコマンドがコマンド列に含められる。
【００５２】
一方、図２（ａ）に示す圧縮データ部７４には、黒又は白ランレングスコマンドの引数データが圧縮データとして記述される。具体的には、圧縮データ（即ち引数データ）は、圧縮対象となるビットマップフォントの各ラインに含まれる線分（黒線分及び白線分）の長さを示すデータの連続により構成されている。当該ビットマップフォントの１ライン分のドット数（横ドット数、例えば３２ビット）ごとに圧縮データを区切ることにより、各ラインのランレングスデータ、即ち黒線分と白線分の配列が得られる。但し、オリジナルコマンドに対応するラインを構成するデータは元のビットマップフォントのオリジナルデータそのものとなる。また、コピーコマンドに対応するラインには対応する引数データ（圧縮データ）は存在しない。これらは、フォント伸張処理において、コマンド記述部７２内のコマンド列を参照して各ラインがどのラインコマンドにより表現されているかを分析することにより、区別することができる。
【００５３】
［圧縮データ例］
次に、上述のフォント圧縮方法により生成された圧縮フォントデータの具体例を説明する。以下に説明するのは、図６に示す漢字「乙」の圧縮フォントデータの例であり、字母データとしてのサイズ（即ち、圧縮前のサイズ）は３２ドット×３２ドットである。この文字の場合、最も圧縮率のよいコマンド記述部の設定としては、シフト数は「７」であり、コマンドタイプは可変長コマンドであり、コマンド組み合わせＩＤは「０ｘ０Ｂ」である。なお、これらの設定値は、フォント圧縮処理において、シフト数やコマンド組み合わせＩＤを変更しつつフォント全体の圧縮率を算出して比較する処理を繰り返すことにより決定されるが、その詳細については後述する。
【００５４】
文字「乙」の圧縮フォントデータ７０（図２（ａ）参照）において、そのコマンド記述部７２の内容は図２（ｂ）の最下行に示すようになる。即ち、シフト数＝７、コマンドタイプは可変長コマンド、コマンド組み合わせＩＤ＝０ｘ０Ｂであり、コマンド列の内容は図５に示すようになる。また、コマンド列中の各ラインコマンドに対応するコマンドデータ（ラインコマンドに対応するデータ）、そのデータ内容（引数データにより示されるドット配列）、及び各ラインの総ビット数を図７に示す。実際の圧縮フォントデータ７０の構成としては、コマンド記述部７２内のコマンド列が図５に示すものとなり、圧縮データ部７４には図７に示すデータ内容に対応する引数データ（２進数のランレングス符号）が含まれることになる。
【００５５】
また、コマンド記述部７２内のコマンド列は図５に示すものであると述べたが、実際には、各ラインコマンドは、コマンド組み合わせＩＤに基づいて決定され、図４に示すコマンドデータとなして記述されている。本例ではコマンド組み合わせＩＤ＝０ｘ０Ｂであるので、図４に示すように、白ランレングスコマンド［ＣＭＤ＿ＣＰＳ＿Ｗ］は「０ｂ」、黒ランレングスコマンド［ＣＭＤ＿ＣＰＳ＿Ｂ］は「１０ｂ」、オリジナルコマンド［ＣＭＤ＿ＯＲＧ］は「１１０ｂ」、コピーコマンド［ＣＭＤ＿ＣＰＹ］は「１１１ｂ」で表現されることになる。図７には、各ラインコマンドに対応するコマンドデータ例を示している。
【００５６】
本例では、圧縮の対象となるビットマップフォントは図６（ａ）に示す「乙」という文字であり、縦横３２ドットのサイズである。これを、シフト数７だけシフトすると、ビットマップフォントは図６（ｂ）に示すようになる。図６（ｂ）において、ビットマップフォントの横方向に３２個のライン（第０ライン〜第３１ラインと呼ぶことにする）が存在する。第０ライン〜第３１ラインまでの各ラインのデータ内容（白ドットと黒ドットの配列）をラインコマンド及び引数データで表現したものが図７に示されている。図７においてラインコマンドの左側に示されている数値（００〜３１）がライン数（第０ライン〜第３１ライン）に対応している。
【００５７】
図６（ｂ）からわかるように、第０ラインは全て白ドットであるので、第０ラインは白ランレングスコマンド（［ＣＭＤ＿ＣＰＳ＿Ｗ］）で表現され、対応するデータ内容（引数データ）は、白ドットが３２個連続する線分である（「白３２」と示してある）。また、長さ３２を示すランレングス符号は５ビットであるので、データ内容の括弧内に「５」が示されている。この結果、第０ラインのデータ内容（引数データ）の総ビット数は５ビットとなる。
【００５８】
図６（ｂ）において、第１ライン及び第２ラインは第０ラインと同じく白ドットのみが３２個続く構成である。よって、第１ライン及び第２ラインのラインコマンドはコピーコマンド（［ＣＭＤ＿ＣＰＹ］）であり、引数データは存在しないためライン毎の総ビット数はいずれの０ビットである。
【００５９】
第３ラインは、黒ドットが１８個、白ドットが１１個、黒ドットが３個という配列で構成されている。よって、第３ラインのラインコマンドは黒ランレングスコマンド（［ＣＭＤ＿ＣＰＳ＿Ｂ］）であり、その引数データとして「１８」、「１１」、「３」のハフマン符号が含まれている。それら符号のビット数はそれぞれ、５ビット、４ビット、２ビットであるので、第４ラインの総ビット数は１１ビットとなる。
【００６０】
このようにして、図６（ｂ）に示すシフト後のビットマップフォントの各ライン毎にデータ構成を分析してラインコマンド及び引数データが割り当てられている。本例は縦横３２ドットのビットマップフォントの例であるので、元のビットマップフォントをそのままデータ化すれば、１ラインは３２ドット分の白黒のデータ、即ち３２ビットのデータが必要となるが、ラインコマンドと引数データの組み合わせにより表現すれば、図７に示すように、１ラインを表現するのに要するビット数をかなり小さくすることができる。なお、（１ラインを表現するために要するビット数）＝（ラインコマンド自体のビット数＋引数データのビット数）、ということになるが、ラインコマンド自体は長いものでも３ビット程度であり、しかも前述のようにハフマン符号を使用しているので、引数データがよほど長くないかぎり、オリジナルデータに比べて圧縮効果が得られることになる。
【００６１】
なお、本例では、１ラインが３２ドットであり、どのラインでもランレングスコマンドにより圧縮効果が得られるので、図７に示すコマンド列中にオリジナルコマンド（［ＣＭＤ＿ＯＲＧ］）は登場していない。しかし、圧縮の対象となるビットマップフォントのサイズが例えば１０ドット×１０ドットなどと比較的小さく、１ライン中の白ドットと黒ドットの変化が激しい場合には、ランレングス符号化により得られた引数データの合計ビット数が、元の１ラインを白黒のデータ列（オリジナルデータ）として表現した場合のビット数（この場合１０ビット）より大きくなってしまうことがある。そのような場合には、当該ラインについてはオリジナルコマンドを使用し、引数データとしてオリジナルデータを持てばよい。
【００６２】
［フォント圧縮処理］
次に、圧縮フォントデータを生成するためのフォント圧縮処理について、図８を参照して説明する。図８は、フォント圧縮処理のフローチャートである。
【００６３】
フォント圧縮処理は、圧縮の対象となるフォント毎に実行され、当該フォントについて最も高い圧縮率を得ることができるコマンド記述部の設定、即ち、シフト数、コマンドタイプ、コマンド組み合わせＩＤなどを試行錯誤により決定する。そして、決定されたコマンド記述部の設定に従って、圧縮対象となるビットマップフォントをライン毎にラインコマンドで表現し、引数データを決定してフォントデータを圧縮し、圧縮フォントデータを得る。なお、フォント圧縮処理は、フォント圧縮プログラムを利用して、図１に示したフォント圧縮装置５により実行される。
【００６４】
図８を参照すると、まず、テンポラリーデータ長に圧縮前のビットマップフォントのフォントサイズを保存する（ステップＳ１）。テンポラリーデータ長とは、フォント圧縮処理中にデータ長を一時的に保存するための変数であり、上述のシフト数などを変更しつつ圧縮フォントデータのデータ長を算出する作業を繰り返す間に、それまでの作業で得られた最も小さいデータ長を常に記憶している変数である。
【００６５】
次に、フォント圧縮処理は、各ラインにラインコマンドを割り当てる（ステップＳ２）。本発明の圧縮方法では、前述の４種類のラインコマンドの全てを使用するか、オリジナルコマンドとコピーコマンドのみを使用するかなど、使用するラインコマンドの選択方法によって、１ラインを表現するデータ長（＝コマンド記述部＋データ圧縮部）が変化し、圧縮率が変化する。よって、ステップＳ２では、どのラインコマンドを使用するかを設定する。この設定を繰り返し変えながらデータ圧縮率を比較することにより最適なコマンド記述部の設定が得られることになる。
【００６６】
なお、ラインコマンドとして黒ランレングスコマンドと白ランレングスコマンドのデータ圧縮の効率を考えたとき、ランレングス符号化により得られる圧縮データ長がオリジナルデータ長と比較して１又は２以下しか圧縮されない場合は、ラインコマンドのデータ長を加えると、むしろランレングス符号化した方がオリジナルデータよりもデータ長が長くなってしまう場合もある。この点を考慮して、最初にコマンドの割り当てを行う場合は、暫定的なラインコマンドとして、先にあげた４種類のラインコマンドに以下のコマンドを追加する。これにより、ラインコマンド自体のデータ長を考慮してデータ長の評価を行うことができる。
【００６７】
・白ランレングスマイナス１コマンド：引数データ部が１縮まる。
【００６８】
・白ランレングスマイナス２コマンド：引数データ部が２縮まる。
【００６９】
・黒ランレングスマイナス１コマンド：引数データ部が１縮まる。
【００７０】
・黒ランレングスマイナス２コマンド：引数データ部が２縮まる。
【００７１】
そして、圧縮対象となるビットマップフォントの各ラインに、以下のようにラインコマンドを割り当てる（但し、コマンド記述部の長さは考慮しない。）
▲１▼直前のラインと同じラインの場合はコピーコマンドを使用する。
【００７２】
▲２▼ランレングスコマンドによる引数データ長がオリジナルデータ長より大きくなる場合は、オリジナルコマンドを使用する。
【００７３】
▲３▼ランレングスコマンドによる引数データ長が１ドット縮まる場合はランレングスマイナス１コマンドを使用する。
【００７４】
▲４▼ランレングスコマンドによる引数データ長が２ドット縮まる場合はランレングスマイナス２コマンドを使用する。
【００７５】
▲５▼ランレングスコマンドによる引数データ長が３ドット以上縮まる場合はランレングスコマンドを使用する。
【００７６】
なお、▲３▼〜▲５▼は、黒スタート、白スタートでもコマンドは異なる。
【００７７】
こうして、各ラインにラインコマンドを割り当てる。そして、そのように割り当てたラインコマンドに基づいて、コマンド記述部＋圧縮データ部の長さが最小となるコマンド記述部を設定し、そのときの圧縮後のデータ長（「圧縮データ長」と呼ぶ）を算出する（ステップＳ３）。次に、フォント圧縮処理は、そうして得られた圧縮データ長がテンポラリーデータ長より小さいか否かを判定する（ステップＳ４）。圧縮データ長が小さければ（ステップＳ４；ｙｅｓ）、そのときのコマンド記述部の設定が、それまでで最も高い圧縮率をもたらすことになるので、その圧縮データ長をテンポラリーデータ長として保存し、コマンド記述部の設定（シフト数を含む）を内部メモリなどに一時的に保存する（ステップＳ５）。これにより、それまでの処理において、最も高い圧縮率を提供する設定が記憶されたことになる。
【００７８】
一方、ステップＳ４で圧縮データ長がテンポラリーデータ長より小さくない場合（ステップＳ４；ｎｏ）、そのときのコマンド記述部の設定は最も高い圧縮率を提供するものではないので、処理はステップＳ６へ進み、当該ビットマップフォントの最大シフト量分のシフトが既に行われたかを判定し、行われていなければ、ステップＳ７でフォントを１つシフトし、ステップＳ２へ戻る。これにより、ビットマップフォントを１ドット分シフト（図６のシフト処理参照）した状態で、再度ラインコマンドを割り当て、コマンド記述部を決定して圧縮データ長を算出し、テンポラリーデータ長と比較するという一連の処理を繰り返す（ステップＳ２〜Ｓ５）。こうして、ステップＳ６の判定結果がｙｅｓとなるまで、即ち、当該ビットマップフォントについて適用可能な最大シフト数までシフト処理を完了するまでステップＳ２からＳ７を繰り返し、シフト処理が全て完了した時点で、処理はステップＳ８へ進む。処理がステップＳ８へ進んだ段階で、シフト数などのコマンド記述部の設定を様々に変更した結果最も高い圧縮率を提供するコマンド記述部の設定が内部メモリなどに記憶された状態となっている。
【００７９】
ステップＳ８では、そのときのテンポラリーデータ長（最も高い圧縮率で圧縮した場合のデータ長を示している）が圧縮対象のビットマップフォントのデータサイズより小さいか否かを判定する。小さい場合には、そのときに保存されているコマンド記述部の設定に従って圧縮対象となるビットマップフォントを、保存したシフト数分左にシフトし（ステップＳ９）、保存したコマンド記述部の設定に従ってシフト後の各ラインをラインコマンドで表現して圧縮する（ステップＳ１０）。最後に、圧縮後のフォントデータのヘッダ部分に、圧縮処理がなされていることを示す圧縮フラグを設定し（ステップＳ１１）、処理を終了する。
【００８０】
一方、ステップＳ８でテンポラリーデータ長が元のビットマップフォントのデータサイズより大きい場合は、圧縮しない方がデータ量が小さいわけであるから、圧縮処理を行わず、当該ビットマップフォントのデータのヘッダ部分に、未圧縮であることを示すフラグを設定して（ステップＳ１２）、処理を終了する。
【００８１】
以上のように、本実施形態のフォント圧縮処理では、対象となるビットマップフォントに対して、使用するラインコマンドの種類やシフト数などを順に変更しつつ圧縮後のデータ長を算出して最も高い圧縮率が得られるコマンド記述部の設定を求め、それに従って圧縮を行う。よって、対象となるフォント毎に独立して、最大の圧縮率でデータ圧縮を行うことができる。
【００８２】
［フォント伸張処理］
次に、フォント伸張処理について図９を参照して説明する。図９はフォント伸張処理のフローチャートである。なお、フォント伸張処理は、図１に示すプログラムＲＯＭ２０内に記憶されているフォント伸張プログラムをＣＰＵ１６が実行することにより行われる。
【００８３】
フォント伸張処理は、まず、表示すべき圧縮フォントデータをフォントＲＯＭ２２から読み出し（ステップＳ２０）、当該圧縮フォントデータのヘッダ部分の圧縮フラグが立っている（＝「１」である）か否かを判定する（ステップＳ２１）。圧縮フラグが立っている場合、その圧縮フォントデータのコマンド記述部の設定に従って、各ライン毎にデータを伸張してビットマップフォントを得る（ステップＳ２１）。さらに、伸張されたビットマップフォントをシフト数に応じて右シフトして、圧縮処理前のビットマップフォントを再生する（ステップＳ２３）。
【００８４】
一方、ステップＳ２０でヘッダ部分のフラグが立っていない場合は、その圧縮フォントデータは実は圧縮されていないので、伸張処理を行う必要はなく、処理は終了する。
【００８５】
［変形例］
上記の実施形態では、ビットマップフォントを横方向の複数のラインに分割してライン毎にラインコマンドを使用して圧縮を行っているが、その代わりに縦方向のラインに分割し、縦方向に同様にラインコマンドを適用して圧縮を行うことも可能である。
【００８６】
以上説明したように、本発明のフォント圧縮方法によれば、フォント毎に最も高い圧縮率が得られるようにコマンド記述部の設定（シフト数、ラインコマンドの種類など）を決定し、その設定に従って圧縮フォントデータを生成する。圧縮フォントデータの生成処理自体は時間を要するが、これは携帯端末装置の製造元などが予め実行する処理であり、利用者が使用する携帯端末装置側で実行されるわけではないので問題はない。逆に、伸張処理は上述のようにコマンド記述部の設定に従ってデータを復元する単純な処理であるので、ＣＰＵなどの能力のあまり高くない携帯端末装置においても十分実行することができる。
【００８７】
また、圧縮フォントデータの作成時には、それを使用する携帯端末装置の処理能力などを考慮して、圧縮方法を最適化することができる。即ち、ターゲットとなる携帯端末装置が高い圧縮率を要求する場合にはシフトコマンド、回転コマンド、反転コマンドなどの面コマンドを適用して高い圧縮率を実現することができるし、ターゲットとなる携帯端末装置が圧縮率よりも表示時の処理速度を要求する場合には面コマンドを適用しないこととしてもよい。そして、そのように圧縮方法を変化させた場合でも、フォント伸張処理においては単純にコマンド記述部の設定に従って伸張処理を行えばよい。
【００８８】
また、こうして各サイズのビットマップフォントを圧縮して記憶できるので、伸張した後の字母データをさらに拡大・縮小処理することで、任意のサイズのフォントを容易に生成することが可能である。
【００８９】
また、本発明のフォント圧縮方法は、１つのフォント毎に独立して圧縮を行うので、文字の部首やつくりなど部分ごとにデータを共有化して差分データを持つなどの従来の手法と異なり、必要なフォントの形状をそのまま保存することができ、美しいフォントを得ることができる。さらに、１文字のビットマップフォントを構成するドット配列をラインコマンドを利用して圧縮するので、漢字だけでなく、ハングル文字、中国公用文字、アラビア文字などの多種の文字にも対応可能である。
【図面の簡単な説明】
【図１】本発明の圧縮フォントデータを表示する携帯端末装置の概略構成を示す。
【図２】圧縮フォントデータのデータ構造を示す。
【図３】圧縮フォントデータ中のコマンド組み合わせＩＤ及びコマンド例を示す。
【図４】圧縮フォントデータ中のコマンド組み合わせＩＤの例を示す。
【図５】圧縮フォントデータ中のコマンド列の例を示す。
【図６】圧縮対象となるフォント例及びシフト例を示す。
【図７】図６に示すフォント例のコマンド列及びコマンドデータ例を示す。
【図８】フォント圧縮処理のフローチャートである。
【図９】フォント伸張処理のフローチャートである。
【符号の説明】
５フォント圧縮装置
１０携帯端末装置
１２表示部
１４処理フォントメモリ
１６ＣＰＵ
１８入力部
２０プログラムＲＯＭ
２２フォントＲＯＭ
２４ＲＡＭ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a bitmap font compression method.
[0002]
[Background Art]
In a device such as a mobile phone and a PDA (Personal Digital Assistant), a bitmap font is used for displaying characters and the like. The bitmap font displays characters, symbols, and the like according to a pixel arrangement pattern prepared in advance. Unlike an outline font that displays characters, symbols, and the like as a set of vector data, a bitmap font is a simple pixel array pattern and therefore has a small amount of data per character. Therefore, a bitmap font is used in a mobile phone, a PDA, or the like, in which the number of pixels in the display area is relatively small.
[0003]
In a portable terminal device such as a mobile phone or a PDA, the capacity of a ROM or the like for storing font data is limited, so it is desirable to compress and store font data. From this viewpoint, a method of compressing font data using a difference between a plurality of character font data has been proposed (for example, see Patent Document 1). Also, a technique has been proposed in which input data is efficiently compressed by focusing on the frequency of appearance in a plurality of character strings constituting the input data (for example, see Patent Document 2).
[0004]
[Patent Document 1]
JP-A-9-16148
[Patent Document 2]
JP-A-8-223504
[0005]
[Problems to be solved by the invention]
In the above-described compression method, data compression is performed by using a difference between a plurality of character fonts, and therefore, compression cannot be performed in units of one character of a font. Therefore, even when it is necessary to display a specific one character in a portable terminal device or the like, it is necessary to execute a decompression process for another character. However, in a portable terminal device or the like, there is a limitation on the capability of a CPU mounted on the portable terminal device, and therefore, it is desirable to avoid performing unnecessary extension processing as much as possible. That is, in a portable terminal device or the like, it is desirable that font data is compressed and stored for each character, and only necessary font data can be efficiently expanded and displayed.
[0006]
The present invention has been made in view of the above points, and has as its object to efficiently compress bitmap font data used in a mobile phone, a PDA, or the like for each character.
[0007]
[Means for Solving the Problems]
According to one aspect of the present invention, a font compression apparatus includes a dividing unit that divides a bitmap font to be compressed into a plurality of vertical or horizontal lines, and for each line obtained by the division, And a line command determining means for determining a line command corresponding to the pixel data array constituting the pixel data array, and the pixel data array constituting each line is expressed by compressed font data including command data indicating the line command determined for the line. Compressed font data generating means.
[0008]
According to the above-described font compression apparatus, a bitmap font to be compressed is divided into vertical or horizontal lines, and compression processing is performed for each line. Specifically, a line command expressing a pixel data array for each line is determined, and the line is expressed by command data corresponding to the line command. As a result, the pixel data array can be represented by command data having a small data amount, and font data can be compressed.
[0009]
One aspect of the above-described font compression apparatus includes a shift unit that uniformly shifts the bitmap font to be compressed in the vertical or horizontal direction. By shifting the bitmap font to be compressed in the vertical or horizontal direction, the pixel data array can be changed so that data can be more efficiently compressed by a line command.
[0010]
Another aspect of the above-described font compression apparatus includes means for inverting the bitmap font to be compressed in a vertical or horizontal direction, or rotating the bitmap font by a predetermined angle. By inverting or rotating the entire bitmap font instead of shifting, the pixel data array can be changed, and the compression ratio by the line command can be further improved.
[0011]
In another aspect of the above-described font compression apparatus, the compressed font data may be generated for each of the line commands, and may include argument data indicating a pixel data array constituting the line. Therefore, the characteristics of the pixel data array of the line can be specified by the line command, and the specific pixel data array can be expressed by the argument data.
[0012]
In another aspect of the above-described font compression apparatus, the line command may include a run-length line command for expressing a pixel data array of a target line by run-length encoding. Further, the run length line command may include a white run length line command corresponding to a line starting from a white pixel and a black run length line command corresponding to a line starting from a black pixel.
[0013]
In another aspect of the above-described font compression apparatus, the line command may include an original command in which a pixel data array of a target line is directly used as argument data. As a result, when the compressed data obtained by the run-length encoding is larger than the original data, the data amount of the entire font can be reduced with the original data of the line as the argument data.
[0014]
In another aspect of the above-described font compression apparatus, the line command may include a copy command indicating that the pixel data array of the target line is completely the same as the pixel data array of the previous line. . Accordingly, when lines having the same pixel data arrangement are arranged, overlapping description of compressed data can be omitted, and the compression ratio can be further improved.
[0015]
In another aspect of the above-described font compression apparatus, the command data indicating the line command can be Huffman-coded according to the number of times the line command is used in the bitmap font to be compressed. As a result, short command data is used for frequently used line commands, and long command data is used for less frequently used line commands, so that the data amount of the line command portion can be reduced.
[0016]
In another aspect of the above-described font compression apparatus, the compressed font data includes a command description unit including a shift amount by the shift unit, a type of the line command, and a line command sequence corresponding to the plurality of lines, And a compressed data portion including argument data indicating a pixel data array constituting each line.
[0017]
According to another aspect of the present invention, a storage unit that stores compressed font data generated by the above-described font compression apparatus, and a pixel data array that configures the plurality of lines based on the line command and the corresponding argument data. Provided is a font decompression device including: a generating unit; and a unit that reproduces a bitmap font to be compressed by shifting a pixel data array of a plurality of generated lines according to the shift amount. Can be. According to this font decompression device, font data can be decompressed efficiently using the shift amount, line command, and the like determined in the compression processing by the above-described font compression device.
[0018]
In another aspect of the present invention, a dividing step of dividing a bitmap font to be compressed into a plurality of vertical or horizontal lines, and, for each line obtained by the division, pixel data constituting the line A line command determining step of determining a line command corresponding to the arrangement, and a compressed font data generating step of expressing a pixel data array constituting each line by compressed font data including command data indicating the line command determined for the line And a font compression method having the following. By executing this font compression method, the same font compression processing as that of the above-described font compression apparatus can be performed.
[0019]
According to another aspect of the present invention, by executing on a computer, a dividing unit that divides a bitmap font to be compressed into a plurality of lines in a vertical direction or a horizontal direction. A line command determining means for determining a line command corresponding to a pixel data array constituting the line, and a pixel data array constituting each line is determined by compressed font data including command data indicating the line command determined for the line. It is possible to provide a font compression program that causes the computer to function as compressed font data generating means for expression. By executing the font compression program on a computer, the above-described font compression apparatus can be realized.
[0020]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings.
[0021]
[Configuration of mobile terminal device]
FIG. 1 shows a schematic configuration of a portable terminal device to which a bitmap font compression method according to an embodiment of the present invention is applied. In FIG. 1, a mobile terminal device 10 is a terminal device having a relatively small image display area, such as a mobile phone or a PDA. The mobile terminal device 10 includes a display unit 12, a processing font memory 14, a CPU 16, an input unit 18, a program ROM 20, a font ROM 22, and a RAM 24. On the other hand, the font compression data by the font compression method according to the present invention is generated by the font compression device 5. The font compression device 5 is a terminal device such as a computer, and generates compressed font data by executing a font compression program. Actually, the font compression device 5 exists at the manufacturer of the mobile terminal device 10 or the like, and often manufactures and sells the mobile terminal device 10 with the generated compressed font data stored in the font ROM. However, only the compressed font data generated by the font compression device 5 can be distributed.
[0022]
The display unit 22 can be a lightweight and thin display device such as an LCD (Liquid Crystal Display), and displays characters composed of a bitmap font in a display area.
[0023]
The input unit 18 can be composed of various operation buttons for a mobile phone, a tablet for detecting contact with a touch pen or the like for a PDA, and is used when the user performs various instructions and selections. . Instructions, selections, and the like input to the input unit 18 are converted into electric signals and sent to the CPU 16.
[0024]
The program ROM 20 stores various programs for executing various functions of the mobile terminal device 10, and in particular, in the present embodiment, a bitmap font decompression program (hereinafter, referred to as a “font decompression program”) and a bitmap font decompression program. It stores an enlargement / reduction program (hereinafter also referred to as a “font enlargement / reduction program”), a character display program using a bitmap font, and the like.
[0025]
The font ROM 22 stores the original data of the bitmap font (also called “character data”) as compressed font data. The compressed font data is generated by the font compression device 5 external to the portable terminal device 10 and stored in the font ROM. In the present embodiment, character data having sizes of 12, 16, 20, 24, 28, and 32 dots are respectively compressed and stored as compressed font data.
[0026]
Note that the bitmap font character data is generally a font having an equal aspect ratio (also referred to as a “square font”), for example, 16 × 16 dots. Compressed font data corresponding to each character base data is generated from font data before compression by a font compression process described later, and is stored in the font ROM 22.
[0027]
The RAM 24 is used as a work memory when the compressed font data of the bitmap font is expanded according to the font expansion program. On the other hand, the processing font memory 14 is a memory for temporarily storing the character data of each size created by the decompression process by the font decompression program. The processing font memory 14 can be generally configured by a RAM, a flash memory, or the like, and retains stored contents until the power of the portable terminal device 10 is turned off.
[0028]
The RAM 24 is also used as a working memory when the character base data obtained by the font expansion program is enlarged / reduced to a predetermined size by the font enlargement / reduction program.
[0029]
The CPU 16 executes various functions of the mobile terminal device 10 by executing various programs stored in the program ROM 20. In particular, in the present embodiment, the font expansion program stored in the program ROM 20 is read and executed to generate character matrix data from the compressed font data, and to execute the font enlargement / reduction program as needed. A processing font of a desired size is generated from the character data. Then, by executing the character display program, the characters are displayed on the display unit 12. Note that the CPU 16 realizes various functions of the mobile terminal device 10 by executing various programs other than the above, but since these have no direct relation to the present invention, description thereof will be omitted.
[0030]
In the present embodiment, character data having sizes of 12, 16, 20, 24, 28, and 30 dots are stored in the font ROM 22 as compressed font data, respectively. By executing the reduction process, it is possible to display a font of any size from 10 to 21 dots on the mobile terminal device 10. For example, when the size of the font to be displayed matches the size of the character data prepared in advance (that is, when the size is 12, 16, 20, 24, or 30 dots), the corresponding compressed font data is expanded. Thereby, font data of a required size can be obtained. On the other hand, when a font having a size different from the size of the character data is required, font enlargement / reduction processing is performed on a character having a size similar to the above character data to generate font data of a required size. I do. For example, when 13-dot font data is required, 12-dot character data is generated from compressed font data by font decompression processing, and converted to 13 dots by font expansion processing. If 15-dot font data is required, 16-dot character data is generated from the compressed font data by font expansion processing, and 15-dot font data is generated by font reduction processing. The size of the font data required on the mobile terminal device 10 is determined according to the specification of the user, the request of the program used by the user, and the like.
[0031]
In the present embodiment, basically, font data obtained by the font compression processing is referred to as compressed font data. As described later, in the font compression processing, the data amount per font may be increased by applying the compression method according to the present invention. In such a case, the font compression method according to the present invention is applied to the font. No, that is, the font data is stored in the font ROM 22 uncompressed. However, in the present embodiment, for convenience of explanation, the font data including the font data stored in the font ROM 22 uncompressed is referred to as compressed font data. Sometimes.
[0032]
[Font compression method]
Next, compressed font data obtained by the font compression processing of the present invention will be described. As described above, in the present embodiment, compressed font data corresponding to character base data having sizes of 12, 16, 20, 24, 28, and 30 are respectively prepared. For example, the compressed font data corresponding to the character data of 12 dots is data obtained by applying the compression method of the present invention to a bitmap font of 12 dots in length and 12 dots in width. The nxn dot bitmap font is configured as a set of data in which dots arranged in a square of n dots vertically and horizontally are set to either black ("1") or white ("0").
[0033]
The basic principle and features of the font data compression method according to the present embodiment will be described below.
[0034]
(1) Basic principle
First, in the font data compression method according to the present embodiment, a bitmap font to be compressed is divided into a plurality of horizontal lines, and data for each line (that is, an array of black dots and white dots) is converted to a line. Expressed by command. The line command is a command prepared for expressing the data content of one line (one horizontal line) of the bitmap font. If the line command is set so that the sum of the line command expressing the data content of each line and the argument data of the line command is smaller than the number of bits of the original data, the data amount of one line as a whole can be compressed. Can be.
[0035]
(2) Line command
In line commands, run-length compression is performed. That is, the amount of data is compressed by expressing the continuation of black dots (black line segments) and the continuation of white dots (white line segments) included in one line by their respective lengths. Here, there are two types of run-length commands: a “black run-length command” for expressing one line starting from a black dot, and a “white run-length command” for expressing one line starting from a white dot. Prepare Since the data content of each line is a repetition of a black dot and a white dot, it is specified whether a certain line starts with a black dot or a white dot, and then a black line segment and a white line that repeatedly appear in the line If the length of the minute is indicated as the argument data of the run length command, all the data contents of the line can be expressed. As a simple example, one line consisting of 10 dots in total
"Black""black""black""white""white""white""white""black""black""black"
In this case, this line has two conditions: (1) start with a black dot, and (2) each line segment has a length of "3", "4", and "3". Can be expressed. As described above, if the black run-length command and the white run-length command are used, one line is represented by argument data indicating whether the command is a black run-length command or a white run-length command, and the length of each line segment. be able to. In this case, a black run-length command is used as a command indicating that a start is made with a black dot, and data indicating the length of a subsequent line segment is used as argument data of the line command. That is, when one line is expressed by a line command, the line command has a role of specifying the type of data array of the line, and the argument data has a role of indicating the actual data array.
[0036]
In the run length command, the length of a black or white line segment is represented by a binary number, and a shorter line segment can be represented by a smaller number of bits. For example, if one line is 32 dots, the argument data of the run length command is 1 to 32 in decimal, and this is associated with the binary numbers “1” to “11111”. Thus, the length of the black or white line segment can be represented by the following number of bits in a binary number.
[0037]
Length of line segment (decimal number) Argument data (binary number) Number of bits
1 dot "1" 1 bit
2-3 dots "10-11" 2bit
4-7 dots "100-111" 3 bits
8 to 15 dots "1000 to 1111" 4 bits
16 to 32 dots "10000 to 11111" 5 bits
In the present embodiment, an “original command” is defined as a line command. The original command indicates that the data of the line is one-line black and white data to be compressed (hereinafter, referred to as “original data”) as it is (that is, a command that has not been subjected to compression processing). It is. When a certain line is represented by the run-length processing, the number of bits may be larger than the original data depending on the number of dots of the line and the black and white arrangement pattern. In such a case, the original data is directly compressed. It is used without.
[0038]
Further, in the present embodiment, a “copy command” is defined as a line command. The copy command indicates that the data content of the line is completely the same as the immediately preceding line. As a result, the same line as the one previous line can be expressed only by the copy command, and the argument amount becomes unnecessary, so that the data amount can be further reduced.
[0039]
As described above, the following four types of line commands are used in the present embodiment.
[0040]
・ Original command:
The argument data indicates that it is original data. (Not compressed)
-Copy command:
The argument data indicates that it is exactly the same as the previous line.
[0041]
・ Black run length command:
The argument data indicates that the length is described in black and white order at the start of black.
[0042]
・ White run length command:
The argument data indicates that its length is described in black and white order starting with white.
[0043]
(3) Surface command (shift command)
Further, in the font compression method according to the present embodiment, a plane command is applied to the entire bitmap font to be compressed. A typical example of the plane command is a “shift command”. The shift command is a command for uniformly shifting the dots of the bitmap font to be compressed in the horizontal direction for all lines so that the data amount represented by the run-length command is reduced (see FIG. 6). ). In the case of run-length compression, compression efficiency increases when white or black data continues for a longer time than when white and black frequently repeat. Therefore, if the entire bitmap font to be compressed is shifted by an appropriate number of dots so that white and black dots continue longer, the amount of data expressed by the run-length command becomes smaller, and the overall The compression ratio is improved.
[0044]
Note that the shift command can be applied not only in the horizontal direction but also in the vertical direction, and the shift command in both the vertical and horizontal directions can be applied simultaneously. As the surface command, in addition to the shift command, an inversion command for inverting the entire bitmap font to be processed left or right, or a predetermined angle (for example, 90 degrees, 180 degrees) with the center of the bitmap font as the rotation center. ) Can be applied to reduce the amount of data represented by the run-length command. The shift command, inversion command, rotation command, and the like are called plane commands in the sense that they are applied uniformly to the entire font, unlike line commands in line units.
[0045]
[Compressed data structure]
Next, the data structure of the compressed font data obtained by the font compression method of the present embodiment will be described.
[0046]
FIG. 2A schematically shows the data structure of the compressed font data. The compressed font data 70 includes a command description section 72 and a compressed data section 74. In the font compression method according to the present embodiment, the bitmap font to be compressed is divided into a plurality of horizontal lines as described above, and the data of each line is expressed by a predetermined line command for each line. The command description section 72 includes information that defines a rule or the like when a bitmap font (character data) to be compressed is described by a line command.
[0047]
FIG. 2B shows an example of the data structure of the command description section 72. As illustrated, the command description section 72 is configured to include “number of shifts”, “command type”, “command combination ID”, and “command string”. "Shift number" indicates the number of dots by which the entire font is shifted by the above-mentioned shift command. FIG. 6 shows an example of shifting a bitmap font by a shift command. FIG. 6A shows a state before the shift of the kanji character "Otsu", and FIG. 6B shows a state after shifting by 7 dots by the shift command. The number of shifts can be expressed by the minimum number of bits by adding a bit specifying the shift direction to a number equal to or less than half the number of dots (that is, the width) of one line of the font to be compressed. .
[0048]
“Command type” indicates the type of the line command, and specifically indicates whether the line command used in the compressed font data is a fixed-length command or a variable-length command. For example, the command type can be set to “0” for a fixed-length command and “1” for a variable-length command, and is represented by one bit. In the case of the fixed length command, the command data length of the line command is all fixed length. Note that, as described later, in the case of a variable length command, the command data length is defined to be different for each line command. Actually, Huffman coding is applied based on the frequency of use of each line command, and it is defined that the command data length is shorter for the more frequently used line commands and longer for the less frequently used line commands. .
[0049]
The “command combination ID” defines the relationship between the combination of line commands used for the compressed font data and the command data length of each command. FIG. 3 shows an example of the command combination ID. FIG. 3A shows an example of a command combination ID when the command type is a fixed-length command. When the command type is a fixed-length command, the command combination ID is one of two types, “0x00” and “0x01”, and is represented by one bit. When the command combination ID is “0x00”, since there are only two types of line commands, a copy command and an original command, the command length can be represented by 1 bit. On the other hand, if the command combination ID is “0x01”, the line command uses four types of original command, copy command, black run length command, and white run length command, so that the command length of each line command requires 2 bits. Become. In any case, since the command type is a fixed length command, the command data length of each line command is equal.
[0050]
FIG. 3B shows an example of a command combination ID when the command type is a variable length command. When the command type is a variable length command, each line command is Huffman encoded as shown in FIG. 4 according to the combination ID. That is, after analyzing the data contents of a plurality of lines constituting the bitmap font to be compressed, the shortest command data (0b) is assigned to the most frequently used line command, and the longest is used in the order of decreasing use frequency. A command combination ID to which command data (10b, 110b, 111b) is assigned is set for each bitmap font.
[0051]
Returning to FIG. 2B, the “command sequence” is a sequence of line commands set for each line of the actual bitmap font, and as shown in FIG. Several line commands are included in the command sequence.
[0052]
On the other hand, in the compressed data section 74 shown in FIG. 2A, argument data of a black or white run length command is described as compressed data. Specifically, the compressed data (that is, the argument data) is configured by a series of data indicating the lengths of line segments (black line segments and white line segments) included in each line of the bitmap font to be compressed. . By dividing the compressed data by the number of dots (the number of horizontal dots, for example, 32 bits) of one line of the bitmap font, run-length data of each line, that is, an array of black lines and white lines is obtained. However, the data constituting the line corresponding to the original command is the original data of the original bitmap font. Further, there is no corresponding argument data (compressed data) in the line corresponding to the copy command. These can be distinguished from each other by analyzing which line command represents each line with reference to the command sequence in the command description section 72 in the font decompression process.
[0053]
[Example of compressed data]
Next, a specific example of the compressed font data generated by the above-described font compression method will be described. Described below is an example of the compressed font data of the kanji “Otsu” shown in FIG. 6, and the size as the character base data (that is, the size before compression) is 32 dots × 32 dots. In the case of this character, as the setting of the command description portion having the best compression ratio, the shift number is “7”, the command type is a variable length command, and the command combination ID is “0x0B”. Note that these set values are determined by repeating the process of calculating and comparing the compression ratio of the entire font while changing the shift number and the command combination ID in the font compression process, the details of which will be described later. .
[0054]
In the compressed font data 70 of the character “Otsu” (see FIG. 2A), the contents of the command description section 72 are as shown in the bottom line of FIG. 2B. That is, the number of shifts is 7, the command type is a variable length command, the command combination ID is 0x0B, and the contents of the command sequence are as shown in FIG. FIG. 7 shows the command data (data corresponding to the line command) corresponding to each line command in the command sequence, the data content (dot array indicated by the argument data), and the total bit number of each line. As a configuration of the actual compressed font data 70, the command sequence in the command description section 72 is as shown in FIG. 5, and the compressed data section 74 has argument data (binary run length) corresponding to the data contents shown in FIG. Sign).
[0055]
Although the command sequence in the command description section 72 is described as shown in FIG. 5, in practice, each line command is determined based on the command combination ID, and becomes the command data shown in FIG. It has been described. In this example, since the command combination ID is 0x0B, as shown in FIG. 4, the white run length command [CMD_CPS_W] is “0b”, the black run length command [CMD_CPS_B] is “10b”, and the original command [CMD_ORG] is “0b”. 110b ", and the copy command [CMD_CPY] is represented by" 111b ". FIG. 7 shows an example of command data corresponding to each line command.
[0056]
In this example, the bitmap font to be compressed is the character "Otsu" shown in FIG. 6A, and has a size of 32 dots vertically and horizontally. When this is shifted by the shift number 7, the bitmap font becomes as shown in FIG. In FIG. 6B, there are 32 lines (referred to as the 0th to 31st lines) in the horizontal direction of the bitmap font. FIG. 7 shows data contents (array of white dots and black dots) of each line from the 0th line to the 31st line expressed by a line command and argument data. Numerical values (00 to 31) shown on the left side of the line command in FIG. 7 correspond to the number of lines (0th to 31st lines).
[0057]
As can be seen from FIG. 6B, since the 0th line is all white dots, the 0th line is expressed by a white run length command ([CMD_CPS_W]), and the corresponding data content (argument data) is white dots. Are 32 continuous line segments (shown as “white 32”). Also, since the run-length code indicating the length 32 is 5 bits, “5” is shown in parentheses of the data content. As a result, the total bit number of the data content (argument data) of the 0th line is 5 bits.
[0058]
In FIG. 6B, the first line and the second line have a configuration in which only 32 white dots continue as in the 0th line. Therefore, the line command of the first line and the second line is a copy command ([CMD_CPY]), and since there is no argument data, the total number of bits for each line is 0 bit.
[0059]
The third line has an arrangement of 18 black dots, 11 white dots, and 3 black dots. Therefore, the line command of the third line is a black run length command ([CMD_CPS_B]), and includes Huffman codes of “18”, “11”, and “3” as its argument data. Since the bit numbers of these codes are 5 bits, 4 bits, and 2 bits, respectively, the total bit number of the fourth line is 11 bits.
[0060]
In this way, the data configuration is analyzed for each line of the bitmap font after the shift shown in FIG. 6B, and the line command and the argument data are assigned. Since this example is an example of a bitmap font of 32 dots vertically and horizontally, if the original bitmap font is converted into data as it is, one line requires black and white data of 32 dots, that is, 32-bit data. When expressed by a combination of a line command and argument data, the number of bits required to express one line can be considerably reduced as shown in FIG. It should be noted that (the number of bits required to represent one line) = (the number of bits of the line command itself + the number of bits of the argument data), but the line command itself is about 3 bits even if it is long. Since the Huffman code is used as described above, a compression effect can be obtained as compared with the original data unless the argument data is very long.
[0061]
In this example, one line is 32 dots, and a compression effect can be obtained by a run-length command on any line. Therefore, the original command ([CMD_ORG]) does not appear in the command sequence shown in FIG. However, when the size of the bitmap font to be compressed is relatively small, for example, 10 dots × 10 dots, and the change of white dots and black dots in one line is drastic, it is obtained by run-length encoding. The total number of bits of the argument data may be larger than the number of bits (10 bits in this case) when the original one line is represented as a black and white data string (original data). In such a case, the original command may be used for the line and the original data may be provided as the argument data.
[0062]
[Font compression processing]
Next, font compression processing for generating compressed font data will be described with reference to FIG. FIG. 8 is a flowchart of the font compression process.
[0063]
The font compression process is executed for each font to be compressed, and the setting of the command description portion that can obtain the highest compression ratio for the font, that is, the number of shifts, the command type, the command combination ID, and the like are determined by trial and error. decide. Then, according to the determined setting of the command description section, the bitmap font to be compressed is expressed by a line command for each line, the argument data is determined, and the font data is compressed to obtain compressed font data. The font compression processing is executed by the font compression device 5 shown in FIG. 1 using a font compression program.
[0064]
Referring to FIG. 8, first, the font size of the bitmap font before compression is stored in the temporary data length (step S1). The temporary data length is a variable for temporarily storing the data length during the font compression process, and during the process of calculating the data length of the compressed font data while changing the shift number and the like described above, the temporary data length is a variable. This is a variable that always stores the shortest data length obtained in the above operations.
[0065]
Next, in the font compression processing, a line command is assigned to each line (step S2). According to the compression method of the present invention, the data length expressing one line (depending on the selection method of the line command to be used, such as whether to use all of the above four types of line commands or only the original command and the copy command) = Command description section + data compression section), and the compression ratio changes. Therefore, in step S2, which line command is used is set. By comparing the data compression rates while repeatedly changing this setting, the optimum setting of the command description section can be obtained.
[0066]
When considering the efficiency of data compression of the black run length command and the white run length command as the line command, when the compressed data length obtained by the run length encoding is compressed by 1 or 2 or less compared to the original data length In some cases, if the data length of the line command is added, the data length may be longer in run-length coding than in the original data. In consideration of this point, when assigning commands first, the following commands are added to the above four types of line commands as provisional line commands. Thus, the data length can be evaluated in consideration of the data length of the line command itself.
[0067]
-White run length minus 1 command: The argument data part is reduced by one.
[0068]
-White run length minus 2 command: The argument data section is reduced by 2.
[0069]
Black run length minus 1 command: The argument data section is reduced by 1.
[0070]
Black run length minus 2 command: The argument data section is reduced by 2.
[0071]
Then, a line command is assigned to each line of the bitmap font to be compressed as follows (however, the length of the command description portion is not considered).
{Circle around (1)} In the case of the same line as the previous line, a copy command is used.
[0072]
{Circle around (2)} When the argument data length by the run length command becomes larger than the original data length, the original command is used.
[0073]
{Circle around (3)} When the argument data length by the run length command is reduced by one dot, use the run length minus one command.
[0074]
{Circle around (4)} When the length of the argument data by the run length command is reduced by 2 dots, use the run length minus 2 command.
[0075]
{Circle around (5)} When the argument data length by the run length command is reduced by 3 dots or more, the run length command is used.
[0076]
In (3) to (5), the commands are different between the black start and the white start.
[0077]
Thus, a line command is assigned to each line. Then, based on the line command assigned in this way, a command description portion that minimizes the length of the command description portion + the compressed data portion is set, and the data length after compression at that time (referred to as “compressed data length”). ) Is calculated (step S3). Next, in the font compression processing, it is determined whether or not the obtained compressed data length is smaller than the temporary data length (step S4). If the compressed data length is small (step S4; yes), the setting of the command description portion at that time will result in the highest compression rate so far, and the compressed data length is stored as the temporary data length, and the command The setting of the description section (including the number of shifts) is temporarily stored in an internal memory or the like (step S5). As a result, the setting providing the highest compression ratio in the processing up to that point is stored.
[0078]
On the other hand, if the compressed data length is not smaller than the temporary data length in step S4 (step S4; no), the process proceeds to step S6 because the setting of the command description portion at that time does not provide the highest compression ratio. It is determined whether the bitmap font has been shifted by the maximum shift amount. If not, the font is shifted by one in step S7, and the process returns to step S2. In this way, with the bitmap font shifted by one dot (see the shift processing in FIG. 6), a line command is assigned again, the command description part is determined, the compressed data length is calculated, and compared with the temporary data length. A series of processing is repeated (steps S2 to S5). In this manner, steps S2 to S7 are repeated until the result of the determination in step S6 becomes "yes", that is, until the shift processing is completed up to the maximum shift number applicable to the bitmap font. Goes to step S8. At the stage when the process proceeds to step S8, the setting of the command description portion that provides the highest compression ratio as a result of variously changing the setting of the command description portion such as the number of shifts is stored in the internal memory or the like. .
[0079]
In step S8, it is determined whether the temporary data length at that time (indicating the data length when compressed at the highest compression ratio) is smaller than the data size of the bitmap font to be compressed. If it is smaller, the bitmap font to be compressed is shifted to the left by the saved number of shifts according to the setting of the command description section stored at that time (step S9), and shifted according to the setting of the saved command description section. Each subsequent line is expressed by a line command and compressed (step S10). Finally, a compression flag indicating that compression processing has been performed is set in the header portion of the compressed font data (step S11), and the processing ends.
[0080]
On the other hand, if the temporary data length is larger than the data size of the original bitmap font in step S8, the compression process is not performed and the header portion of the data of the bitmap font is not compressed because the data amount is smaller without compression. Then, a flag indicating that the data is not compressed is set (step S12), and the process ends.
[0081]
As described above, in the font compression processing of the present embodiment, the data length after compression is calculated for the target bitmap font while sequentially changing the type of line command to be used, the number of shifts, and the like. The setting of the command description part for obtaining the compression ratio is obtained, and compression is performed according to the setting. Therefore, data compression can be performed at the maximum compression rate independently for each target font.
[0082]
[Font expansion processing]
Next, font expansion processing will be described with reference to FIG. FIG. 9 is a flowchart of the font decompression process. The font expansion process is performed by the CPU 16 executing a font expansion program stored in the program ROM 20 shown in FIG.
[0083]
In the font decompression process, first, the compressed font data to be displayed is read from the font ROM 22 (step S20), and it is determined whether or not the compression flag in the header portion of the compressed font data is on (= “1”). (Step S21). If the compression flag is set, the data is expanded for each line to obtain a bitmap font in accordance with the setting of the command description section of the compressed font data (step S21). Further, the decompressed bitmap font is shifted to the right in accordance with the shift number, and the bitmap font before the compression processing is reproduced (step S23).
[0084]
On the other hand, if the flag of the header portion is not set in step S20, the compressed font data is not actually compressed, so there is no need to perform the decompression process, and the process ends.
[0085]
[Modification]
In the above embodiment, the bitmap font is divided into a plurality of lines in the horizontal direction, and compression is performed using a line command for each line. Similarly, compression can be performed by applying a line command.
[0086]
As described above, according to the font compression method of the present invention, the setting (the number of shifts, the type of line command, etc.) of the command description section is determined so that the highest compression ratio can be obtained for each font, and according to the setting. Generate compressed font data. Although the process of generating the compressed font data itself takes time, this is a process that is executed in advance by the manufacturer of the portable terminal device, and is not a problem because the process is not executed by the portable terminal device used by the user. Conversely, since the decompression process is a simple process of restoring data in accordance with the setting of the command description section as described above, the decompression process can be sufficiently executed even in a portable terminal device such as a CPU having a relatively low capacity.
[0087]
Also, when creating the compressed font data, the compression method can be optimized in consideration of the processing capability of the portable terminal device that uses it. That is, when the target portable terminal device requires a high compression rate, a high compression rate can be realized by applying a surface command such as a shift command, a rotation command, and a reverse command. If the apparatus requires a processing speed at the time of display rather than the compression ratio, the plane command may not be applied. Even when the compression method is changed in such a manner, in the font decompression process, the decompression process may be performed simply according to the setting of the command description part.
[0088]
Further, since the bitmap fonts of each size can be compressed and stored in this way, fonts of any size can be easily generated by further expanding / reducing the expanded character data.
[0089]
In addition, the font compression method of the present invention performs compression independently for each font, so that it differs from the conventional method of sharing data for each part such as a radical of a character and making a difference and having difference data. The required font shape can be stored as it is, and a beautiful font can be obtained. Furthermore, since the dot array constituting one character bitmap font is compressed using a line command, it is possible to handle not only Chinese characters but also various characters such as Hangul characters, Chinese official characters, and Arabic characters.
[Brief description of the drawings]
FIG. 1 shows a schematic configuration of a portable terminal device for displaying compressed font data of the present invention.
FIG. 2 shows a data structure of compressed font data.
FIG. 3 shows a command combination ID and a command example in compressed font data.
FIG. 4 shows an example of a command combination ID in compressed font data.
FIG. 5 shows an example of a command string in compressed font data.
FIG. 6 shows an example of a font to be compressed and an example of a shift.
7 shows a command sequence and command data example of the font example shown in FIG. 6;
FIG. 8 is a flowchart of a font compression process.
FIG. 9 is a flowchart of a font expansion process.
[Explanation of symbols]
5 Font compression device
10 Mobile terminal device
12 Display
14. Processing font memory
16 CPU
18 Input section
20 Program ROM
22 Font ROM
24 RAM

Claims

Dividing means for dividing a bitmap font to be compressed into a plurality of vertical or horizontal lines,
For each line obtained by the division, a line command determining means for determining a line command corresponding to a pixel data array constituting the line,
A compressed font data generating unit for expressing a pixel data array constituting each line by compressed font data including command data indicating a line command determined for the line;

2. The font compression apparatus according to claim 1, further comprising a shift unit that shifts the bitmap font to be compressed uniformly in the vertical or horizontal direction.

2. The font compression apparatus according to claim 1, further comprising means for inverting the bitmap font to be compressed in a vertical or horizontal direction or rotating the bitmap font by a predetermined angle.

4. The font compression apparatus according to claim 1, wherein the compressed font data is generated for each of the line commands and includes argument data indicating a pixel data array forming the line. 5.

5. The font compression apparatus according to claim 1, wherein the line command includes a run-length line command for expressing a pixel data array of a target line by run-length encoding. .

6. The run length line command according to claim 5, wherein the run length line command includes a white run length line command corresponding to a line starting from a white pixel and a black run length line command corresponding to a line starting from a black pixel. Font compression device.

The font compression apparatus according to claim 4, wherein the line command includes an original command in which a pixel data array of a target line is directly used as argument data.

5. The line command according to claim 1, wherein the line command includes a copy command indicating that the pixel data array of the target line is completely the same as the pixel data array of the previous line. A font compression device according to claim 1.

4. The method according to claim 1, wherein the command data indicating the line command is Huffman-coded according to the number of times the line command is used in a bitmap font to be compressed. A font compression device as described.

The compressed font data includes a command description portion including a shift amount by the shift unit, a type of the line command, and a line command sequence corresponding to the plurality of lines, and a pixel data array configuring each line for the plurality of lines. 3. A font compression apparatus according to claim 2, comprising: a compressed data section including argument data shown.

A storage unit that stores compressed font data generated by the font compression device according to claim 10.
Means for generating a pixel data array constituting the plurality of lines based on the line command and corresponding argument data;
Means for reproducing the bitmap font to be compressed by shifting the pixel data array of the generated plurality of lines according to the shift amount.

A dividing step of dividing the bitmap font to be compressed into a plurality of vertical or horizontal lines,
For each line obtained by division, a line command determining step of determining a line command corresponding to a pixel data array constituting the line,
A compressed font data generating step of expressing a pixel data array constituting each line by compressed font data including command data indicating a line command determined for the line.

By running on a computer,
Dividing means for dividing a bitmap font to be compressed into a plurality of vertical or horizontal lines,
For each line obtained by the division, a line command determining means for determining a line command corresponding to a pixel data array constituting the line,
A font compression program for causing the computer to function as compressed font data generation means for expressing a pixel data array constituting each line by compressed font data including command data indicating a line command determined for the line.