(57)【要約】【課題】携帯電話やＰＤＡなどで使用するビットマップフォントをフォント毎に効率的に圧縮する。【解決手段】フォント圧縮装置は、圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割手段と、分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定手段と、各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成手段と、を備える。ビットマップフォントをライン毎にラインコマンドで表現することにより、フォント単位で圧縮することができる。【選択図】      図１
2004240125.tif 000002
【特許請求の範囲】
【請求項１】
圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割手段と、
分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定手段と、
各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成手段と、を備えることを特徴とするフォント圧縮装置。
【請求項２】
前記圧縮の対象となるビットマップフォントを、前記縦又は横方向に一様にシフトさせるシフト手段を備えることを特徴とする請求項１に記載のフォント圧縮装置。
【請求項３】
前記圧縮の対象となるビットマップフォントを、上下又は左右方向に反転し、若しくは所定の角度だけ回転させる手段を備えることを特徴とする請求項１に記載のフォント圧縮装置。
【請求項４】
前記圧縮フォントデータは、前記ラインコマンド毎に生成され、当該ラインを構成する画素データ配列を示す引数データを含むことを特徴とする請求項１乃至３のいずれか一項に記載のフォント圧縮装置。
【請求項５】
前記ラインコマンドは、対象となるラインの画素データ配列をランレングス符号化して表現するためのランレングスラインコマンドを含むことを特徴とする請求項１乃至４のいずれか一項に記載のフォント圧縮装置。
【請求項６】
前記ランレングスラインコマンドは、白画素から開始するラインに対応する白ランレングスラインコマンドと、黒画素から開始するラインに対応する黒ランレングスラインコマンドとを含むことを特徴とする請求項５に記載のフォント圧縮装置。
【請求項７】
前記ラインコマンドは、対象となるラインの画素データ配列をそのまま引数データとするオリジナルコマンドを含むことを特徴とする請求項４に記載のフォント圧縮装置。
【請求項８】
前記ラインコマンドは、対象となるラインの画素データ配列が１つ前のラインの画素データ配列と完全同一であることを示すコピーコマンドを含むことを特徴とする請求項１乃至４のいずれか一項に記載のフォント圧縮装置。
【請求項９】
前記ラインコマンドを示すコマンドデータは、圧縮の対象となるビットマップフォント中における当該ラインコマンドの使用回数に応じてハフマン符号化されていることを特徴とする請求項１乃至３のいずれか一項に記載のフォント圧縮装置。
【請求項１０】
前記圧縮フォントデータは、前記シフト手段によるシフト量、前記ラインコマンドの種類及び前記複数のラインに対応するラインコマンド列を含むコマンド記述部と、前記複数のラインについて各ラインを構成する画素データ配列を示す引数データを含む圧縮データ部と、により構成されることを特徴とする請求項２に記載のフォント圧縮装置。
【請求項１１】
請求項１０に記載のフォント圧縮装置により生成された圧縮フォントデータを記憶する記憶部と、
前記ラインコマンド及び対応する引数データに基づいて、前記複数のラインを構成する画素データ配列を生成する手段と、
生成された複数のラインについての画素データ配列を前記シフト量に従ってシフトすることにより、前記圧縮の対象となるビットマップフォントを再現する手段と、を備えることを特徴とするフォント伸張装置。
【請求項１２】
圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割工程と、
分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定工程と、
各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成工程と、を有することを特徴とするフォント圧縮方法。
【請求項１３】
コンピュータ上で実行されることにより、
圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割手段、
分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定手段、
各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成手段として前記コンピュータを機能させることを特徴とするフォント圧縮プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ビットマップフォントの圧縮方法に関する。
【０００２】
【背景技術】
携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などの装置では文字などの表示にビットマップフォントが使用される。ビットマップフォントは、予め用意された画素の配列パターンにより文字や記号などを表示するものである。ベクトルデータの集合として文字や記号などを表示するアウトラインフォントと異なり、ビットマップフォントは単純な画素の配列パターンであるため、１文字当たりのデータ量が小さい。そのため、表示エリアの画素数が比較的少ない携帯電話やＰＤＡなどにおいては、ビットマップフォントが使用される。
【０００３】
携帯電話やＰＤＡなどの携帯型端末装置では、フォントデータを記憶するＲＯＭなどの容量に制限があるため、フォントデータを圧縮して記憶することが望ましい。この観点から、複数の文字フォントデータ間の差分を利用して、フォントデータを圧縮する手法が提案されている（例えば特許文献１参照）。また、入力データを構成する複数の文字列中の出現頻度に着目して、入力データを効率的に圧縮する手法も提案されている（例えば特許文献２参照）。
【０００４】
【特許文献１】
特開平９−１６１４８号公報
【特許文献２】
特開平８−２２３０５４号公報
【０００５】
【発明が解決しようとする課題】
上記の圧縮手法は、複数の文字フォント間の差分などを利用してデータ圧縮を行うため、フォント１文字単位での圧縮ができない。従って、携帯型端末装置などにおいて、ある特定の１文字の表示が必要となった場合でも、その文字以外の伸張処理を実行しなければならないことになる。しかし、携帯型端末装置などは、搭載しているＣＰＵの能力にも制限があるため、できる限り余計な伸張処理を行うことは避けたい。即ち、携帯型端末装置などにおいては、１文字毎にフォントデータを圧縮して記憶しておき、必要なフォントデータのみを効率的に伸張処理して表示できることが望ましい。
【０００６】
本発明は、以上の点に鑑みてなされたものであり、携帯電話やＰＤＡなどで使用するビットマップフォントデータを１文字毎に効率的に圧縮することを課題とする。
【０００７】
【課題を解決するための手段】
本発明の１つの観点では、フォント圧縮装置は、圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割手段と、分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定手段と、各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成手段と、を備える。
【０００８】
上記のフォント圧縮装置によれば、圧縮の対象となるビットマップフォントを縦又は横のライン毎に分割し、各ライン毎に圧縮処理を行う。具体的には、ライン毎の画素データ配列を表現するラインコマンドを決定し、ラインコマンドに対応するコマンドデータにより当該ラインを表現する。これにより、画素データ配列をデータ量の小さいコマンドデータで表現することができ、フォントデータの圧縮が可能となる。
【０００９】
上記のフォント圧縮装置の一態様は、前記圧縮の対象となるビットマップフォントを、前記縦又は横方向に一様にシフトさせるシフト手段を備える。圧縮の対象となるビットマップフォントを縦又は横方向にシフトさせることにより、ラインコマンドによりさらに効率的にデータを圧縮することができるように画素データ配列を変化させることができる。
【００１０】
上記のフォント圧縮装置の他の一態様は、前記圧縮の対象となるビットマップフォントを、上下又は左右方向に反転し、若しくは所定の角度だけ回転させる手段を備える。シフトの代わりに、ビットマップフォント全体を反転又は回転することによっても、画素データ配列を変化させ、ラインコマンドによる圧縮率をさらに向上させることができる。
【００１１】
上記のフォント圧縮装置の他の一態様では、前記圧縮フォントデータは、前記ラインコマンド毎に生成され、当該ラインを構成する画素データ配列を示す引数データを含むことができる。よって、ラインコマンドにより当該ラインの画素データ配列の特徴を特定し、引数データにより具体的な画素データ配列を表現することができる。
【００１２】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドは、対象となるラインの画素データ配列をランレングス符号化して表現するためのランレングスラインコマンドを含むことができる。また、前記ランレングスラインコマンドは、白画素から開始するラインに対応する白ランレングスラインコマンドと、黒画素から開始するラインに対応する黒ランレングスラインコマンドとを含むことができる。
【００１３】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドは、対象となるラインの画素データ配列をそのまま引数データとするオリジナルコマンドを含むことができる。これにより、ランレングス符号化により得られる圧縮データがオリジナルデータよりも大きくなる場合には、当該ラインについてはオリジナルデータをそのまま引数データとして、フォント全体のデータ量を小さくすることができる。
【００１４】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドは、対象となるラインの画素データ配列が１つ前のラインの画素データ配列と完全同一であることを示すコピーコマンドを含むことができる。これにより、同一の画素データ配列を有するラインが並んでいる場合に、重複した圧縮データの記述を省略し、圧縮率をより向上させることができる。
【００１５】
上記のフォント圧縮装置の他の一態様では、前記ラインコマンドを示すコマンドデータは、圧縮の対象となるビットマップフォント中における当該ラインコマンドの使用回数に応じてハフマン符号化することができる。これにより、頻繁に使用するラインコマンドには短いコマンドデータを用い、あまり使用しないラインコマンドには長いコマンドデータを用いて、ラインコマンド部分のデータ量を小さくすることができる。
【００１６】
上記のフォント圧縮装置の他の一態様では、前記圧縮フォントデータは、前記シフト手段によるシフト量、前記ラインコマンドの種類及び前記複数のラインに対応するラインコマンド列を含むコマンド記述部と、前記複数のラインについて各ラインを構成する画素データ配列を示す引数データを含む圧縮データ部と、により構成することができる。
【００１７】
本発明の他の観点では、上記のフォント圧縮装置により生成された圧縮フォントデータを記憶する記憶部と、前記ラインコマンド及び対応する引数データに基づいて、前記複数のラインを構成する画素データ配列を生成する手段と、生成された複数のラインについての画素データ配列を前記シフト量に従ってシフトすることにより、前記圧縮の対象となるビットマップフォントを再現する手段と、を備えるフォント伸張装置を提供することができる。このフォント伸張装置によれば、上述のフォント圧縮装置による圧縮処理で決定されたシフト量、ラインコマンドなどを利用して、効率的にフォントデータを伸張することができる。
【００１８】
本発明の他の観点では、圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割工程と、分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定工程と、各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成工程と、を有するフォント圧縮方法を提供することができる。このフォント圧縮方法を実行することにより、上述のフォント圧縮装置と同様のフォント圧縮処理が可能となる。
【００１９】
本発明の他の観点では、コンピュータ上で実行されることにより、圧縮の対象となるビットマップフォントを縦又は横方向の複数のラインに分割する分割手段、分割により得られた各ラインに対して、当該ラインを構成する画素データ配列に対応するラインコマンドを決定するラインコマンド決定手段、各ラインを構成する画素データ配列を、当該ラインについて決定されたラインコマンドを示すコマンドデータを含む圧縮フォントデータにより表現する圧縮フォントデータ生成手段として前記コンピュータを機能させるフォント圧縮プログラムを提供することができる。このフォント圧縮プログラムをコンピュータ上で実行することにより、上記のフォント圧縮装置を実現することができる。
【００２０】
【発明の実施の形態】
以下、図面を参照して本発明の好適な実施の形態について説明する。
【００２１】
［携帯端末装置の構成］
図１に、本発明の実施形態にかかるビットマップフォントの圧縮方法を適用した携帯端末装置の概略構成を示す。図１において、携帯端末装置１０は、例えば携帯電話やＰＤＡなど、画像表示エリアが比較的小さい端末装置である。携帯端末装置１０は、表示部１２と、処理フォントメモリ１４と、ＣＰＵ１６と、入力部１８と、プログラムＲＯＭ２０と、フォントＲＯＭ２２と、ＲＡＭ２４とを備える。一方、本発明によるフォント圧縮方法によるフォント圧縮データは、フォント圧縮装置５により生成される。フォント圧縮装置５は、コンピュータなどの端末装置であり、フォント圧縮プログラムを実行することにより圧縮フォントデータを生成する。実際には、フォント圧縮装置５は、携帯端末装置１０の製造元などに存在し、生成した圧縮フォントデータをフォントＲＯＭに格納した状態で携帯端末装置１０を製造、販売などする場合が多い。但し、フォント圧縮装置５が生成した圧縮フォントデータのみを流通することも可能である。
【００２２】
表示部２２は、例えばＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ：液晶表示装置）などの軽量、薄型の表示装置とすることができ、表示エリア内にビットマップフォントにより構成される文字を表示する。
【００２３】
入力部１８は、携帯電話であれば各種の操作ボタンなど、ＰＤＡであればタッチペンなどによる接触を検出するタブレットなどにより構成することができ、ユーザが各種の指示、選択を行う際に使用される。入力部１８に対して入力された指示、選択などは、電気信号に変換されてＣＰＵ１６へ送られる。
【００２４】
プログラムＲＯＭ２０は、携帯端末装置１０の各種機能を実行するための各種プログラムを記憶し、特に本実施形態ではビットマップフォントの伸張プログラム（以下、「フォント伸張プログラム」と呼ぶ。）、ビットマップフォントの拡大・縮小プログラム（以下、「フォント拡大・縮小プログラム」とも呼ぶ。）、及び、ビットマップフォントを利用した文字の表示プログラムなどを記憶している。
【００２５】
フォントＲＯＭ２２は、ビットマップフォントの元データ（「字母データ」とも呼ぶ。）を、圧縮フォントデータとして記憶する。圧縮フォントデータは、携帯端末装置１０の外部のフォント圧縮装置５により生成され、フォントＲＯＭに記憶される。本実施形態では、サイズが１２、１６、２０、２４、２８及び３２ドットの字母データをそれぞれ圧縮し、圧縮フォントデータとして保存している。
【００２６】
なお、ビットマップフォント字母データは、例えば１６×１６ドットなどの、縦横比が等しいフォント（「正方フォント」とも呼ぶ。）とすることが一般的である。各字母データに対応する圧縮フォントデータは、圧縮前のフォントデータから後述のフォント圧縮処理により生成され、フォントＲＯＭ２２に記憶されている。
【００２７】
ＲＡＭ２４は、フォント伸張プログラムに従って、ビットマップフォントの圧縮フォントデータを伸張処理する際に作業用メモリとして使用される。一方、処理フォントメモリ１４は、フォント伸張プログラムによる伸張処理により作成された上記の各サイズの字母データを一時的に記憶するメモリである。処理フォントメモリ１４は、通常、ＲＡＭやフラッシュメモリなどにより構成することができ、携帯端末装置１０が電源オフされるまで記憶内容を保持する。
【００２８】
また、ＲＡＭ２４は、フォント伸張プログラムにより得られた字母データを、フォント拡大・縮小プログラムにより所定のサイズに拡大・縮小する際にも作業用メモリとして使用される。
【００２９】
ＣＰＵ１６は、プログラムＲＯＭ２０内に記憶されている各種プログラムを実行することにより、携帯端末装置１０の各種機能を実行する。特に、本実施形態では、プログラムＲＯＭ２０内に記憶されているフォント伸張プログラムを読み出して実行することにより、圧縮フォントデータから字母データを生成し、さらに必要に応じてフォント拡大・縮小プログラムを実行して字母データから所望のサイズの処理フォントを生成する。そして、文字表示プログラムを実行することにより、文字を表示部１２上に表示させる。なお、ＣＰＵ１６は、これら以外に各種のプログラムを実行することにより携帯端末装置１０の各種機能を実現するが、それらは本発明とは直接の関連を有しないので、説明を省略する。
【００３０】
本実施形態では、サイズが１２、１６、２０、２４、２８及び３０ドットの字母データをそれぞれ圧縮フォントデータとしてフォントＲＯＭ２２に記憶しておき、これに対して必要に応じてフォント伸張処理とフォント拡大・縮小処理を実行することにより、携帯端末装置１０上に１０〜２１ドットまでの任意のサイズのフォントを表示可能とする。例えば、表示すべきフォントのサイズが予め用意された字母データのサイズと一致する場合（つまり、１２、１６、２０、２４又は３０ドットである場合）には、対応する圧縮フォントデータを伸張処理することにより必要なサイズのフォントデータが得られる。一方、字母データのサイズと異なるサイズのフォントが必要とされる場合には、上記の字母データのうち近いサイズのものに対してフォント拡大・縮小処理を実行して必要なサイズのフォントデータを生成する。例えば、１３ドットのフォントデータが必要とされる場合は、フォント伸張処理により圧縮フォントデータから１２ドットの字母データを生成し、それをフォント拡大処理により１３ドットに変換する。また、１５ドットのフォントデータが必要とされる場合は、フォント伸張処理により圧縮フォントデータから１６ドットの字母データを生成し、フォント縮小処理により１５ドットのフォントデータを生成する。なお、携帯端末装置１０上で必要とされるフォントデータのサイズは、利用者の指定や利用者が使用するプログラムの要求などに応じて決定されることになる。
【００３１】
なお、本実施形態では、基本的にはフォント圧縮処理により得られたフォントデータを圧縮フォントデータと呼ぶ。後述のように、フォント圧縮処理において本発明による圧縮手法を適用した方が却って１フォントあたりのデータ量が増加してしまう場合もあり、その場合には当該フォントは本発明によるフォント圧縮手法を適用しない、即ち未圧縮のままフォントＲＯＭ２２に格納されることとなるが、本実施形態では、説明の便宜上、そのような未圧縮のままフォントＲＯＭ２２に格納されているフォントデータも含めて圧縮フォントデータということがある。
【００３２】
［フォント圧縮方法］
次に、本発明のフォント圧縮処理により得られた圧縮フォントデータについて説明する。前述のように、本実施形態では、サイズが１２、１６、２０、２４、２８及び３０の字母データに対応する圧縮フォントデータがそれぞれ用意される。例えば１２ドットの字母データに対応する圧縮フォントデータは、縦横が１２ドット×１２ドットのビットマップフォントに対して本発明の圧縮方法を適用して得られたデータである。ｎ×ｎドットのビットマップフォントは、縦横ｎドットの正方形に配列された各ドットが黒（「１」）又は白（「０」）のいずれかにセットされたデータの集合として構成される。
【００３３】
本実施形態のフォントデータ圧縮方法の基本的な原理及び特徴を以下に説明する。
【００３４】
（１）基本原理
まず、本実施形態のフォントデータ圧縮方法は、圧縮の対象となるビットマップフォントを横方向の複数のラインに分割し、ライン毎のデータ（すなわち、黒のドットと白のドットの配列）をラインコマンドにより表現する。ラインコマンドとは、ビットマップフォントの１ライン（横方向の一行）のデータ内容を表現するために用意されるコマンドである。各ラインのデータ内容を表現するラインコマンド及びそのラインコマンドの引数データの合計が元のデータのビット数より小さくなるようにラインコマンドを設定すれば、全体として１ライン分のデータ量を圧縮することができる。
【００３５】
（２）ラインコマンド
ラインコマンドにおいては、ランレングス圧縮を行う。即ち、１ライン中に含まれる黒ドットの連続（黒線分）と白ドットの連続（白線分）をそれぞれの長さで表現することによりデータ量を圧縮する。ここで、ランレングスコマンドとしては、黒ドットから開始する１ラインを表現するための「黒ランレングスコマンド」と、白ドットから開始する１ラインを表現するための「白ランレングスコマンド」の２種類を用意する。各ラインのデータ内容は黒ドットと白ドットの繰り返しであるので、ある１ラインが黒ドットで始まるか白ドットで始まるかを規定しておき、あとはそのライン内に繰り返し現れる黒線分と白線分の長さをそのランレングスコマンドの引数データとして示せば、そのラインのデータ内容を全て表現できることになる。単純な例として、全部で１０ドットからなる１ラインが、
「黒」「黒」「黒」「白」「白」「白」「白」「黒」「黒」「黒」
というデータ内容である場合、このラインは、▲１▼黒ドットで開始すること、▲２▼各線分の長さが「３」、「４」、「３」であること、の２つの条件により表現することができる。このように、黒ランレングスコマンド及び白ランレングスコマンドを利用すれば、黒ランレングスコマンドと白ランレングスコマンドのいずれであるか、及び、各線分の長さを示す引数データにより１ラインを表現することができる。この場合、黒ドットで開始することを示すコマンドとして黒ランレングスコマンドが使用され、その後の線分の長さを示すデータが当該ラインコマンドの引数データとして使用される。即ち、１ラインをラインコマンドで表現する場合、ラインコマンドはそのラインのデータ配列の種類を特定する役割を有し、引数データは実際のデータ配列を示す役割を有する。
【００３６】
なお、ランレングスコマンドにおいて、黒又は白の線分の長さは２進数で表わされ、短い線分ほど少ないビット数で表現することができる。例えば１ラインが３２ドットである場合、ランレングスコマンドの引数データは、１０進数で１〜３２であり、これを２進数の「１」〜「１１１１１」に対応付ける。これにより黒又は白の線分の長さは、２進数で以下のビット数で表現できる。
【００３７】
線分の長さ（１０進数）  引数データ（２進数）  ビット数
１ドット                  「１」                １ｂｉｔ
２〜３ドット            「１０〜１１」              ２ｂｉｔ
４〜７ドット            「１００〜１１１」            ３ｂｉｔ
８〜１５ドット          「１０００〜１１１１」          ４ｂｉｔ
１６〜３２ドット        「１００００〜１１１１１」        ５ｂｉｔ
また、本実施形態では、ラインコマンドとして、「オリジナルコマンド」を定義する。オリジナルコマンドとは、そのラインのデータが、圧縮の対象となる１ラインの白黒のデータ（以下、「オリジナルデータ」と呼ぶ。）そのままであることを示す（即ち、圧縮処理をしていない）コマンドである。ある１ラインをランレングス処理により表現した場合に、そのラインのドット数や白黒の配列パターンによっては、オリジナルデータよりビット数が大きくなってしまう場合もあるので、その場合にはオリジナルデータをそのまま圧縮せずに使用するものである。
【００３８】
さらに、本実施形態では、ラインコマンドとして、「コピーコマンド」を定義する。コピーコマンドとは、そのラインのデータ内容が１つ前のラインと完全同一であることを示す。これにより、１つの前のラインと同一のラインは、コピーコマンドのみで表現でき、引数データが不要となるのでデータ量をより圧縮できる。
【００３９】
以上より、本実施形態で使用するラインコマンドは以下の４種類となる。
【００４０】
・オリジナルコマンド：
引数データはオリジナルのデータであることを表す。（圧縮されていない）
・コピーコマンド：
引数データは１つ前のラインと完全同一であることを表す。
【００４１】
・黒ランレングスコマンド：
引数データは黒開始でその長さが白黒順番に記述されていることを表す。
【００４２】
・白ランレングスコマンド：
引数データは白開始でその長さが白黒順番に記述されていることを表す。
【００４３】
（３）面コマンド（シフトコマンド）
さらに、本実施形態のフォント圧縮方法では、圧縮対象となるビットマップフォント全体に面コマンドを適用する。面コマンドの代表的な例は「シフトコマンド」である。シフトコマンドとは、ランレングスコマンドにより表現されるデータ量が小さくなるように、圧縮対象となるビットマップフォントのドットを全てのラインについて一様に横方向にシフトするコマンドである（図６を参照）。ランレングス圧縮の場合、白又は黒のデータが長く連続するほうが、白と黒が頻繁に繰り返す場合よりも圧縮効率が増加する。よって、圧縮対象となるビットマップフォント全体を適切なドット数だけシフトして白や黒のドットがより長く連続するようにすれば、ランレングスコマンドにより表現されるデータ量が小さくなり、全体としての圧縮率が向上する。
【００４４】
なお、シフトコマンドは横方向のみでなく、縦方向に適用することもできるし、縦横両方向のシフトコマンドを同時に適用することも可能である。また、面コマンドとしては、シフトコマンドのほかに、処理対象となるビットマップフォント全体を左右又は上下に反転させる反転コマンドや、ビットマップフォントの中央を回転中心として所定角度（例えば９０度、１８０度など）だけ回転させる回転コマンドなどを適用して、ランレングスコマンドにより表現されるデータ量を減少させることもできる。上記のシフトコマンド、反転コマンド、回転コマンドなどは、ライン単位のラインコマンドと異なりフォント全体に対して一様に適用されるという意味で、面コマンドと呼んでいる。
【００４５】
［圧縮データ構造］
次に、本実施形態のフォント圧縮方法により得られる圧縮フォントデータのデータ構造について説明する。
【００４６】
図２（ａ）に圧縮フォントデータのデータ構造を模式的に示す。圧縮フォントデータ７０は、コマンド記述部７２と、圧縮データ部７４により構成される。本実施形態のフォント圧縮方法では、前述のように圧縮の対象となるビットマップフォントを横方向の複数のラインに分割し、各ラインのデータをライン毎に所定のラインコマンドで表現する。コマンド記述部７２は、圧縮の対象となるビットマップフォント（字母データ）をラインコマンドで記述する際のルールなどを規定する情報を含む。
【００４７】
コマンド記述部７２のデータ構造例を図２（ｂ）に示す。図示のように、コマンド記述部７２は、「シフト数」、「コマンドタイプ」、「コマンド組み合わせＩＤ」、及び「コマンド列」を含んで構成される。「シフト数」は、前述のシフトコマンドによりフォント全体をシフトするドット数を示す。図６にシフトコマンドによるビットマップフォントのシフト例を示している。図６（ａ）は漢字の「乙」という文字のシフト前の状態を示し、図６（ｂ）はシフトコマンドにより７ドット分のシフトを行った後の状態を示す。シフト数は、圧縮の対象となるフォントの１ラインのドット数（即ち横幅）の１／２以下の数とし、シフト方向を指定するビットを付加することにより最小のビット数で表現することができる。
【００４８】
「コマンドタイプ」は、ラインコマンドのタイプを示し、具体的には、その圧縮フォントデータで使用されているラインコマンドが固定長コマンドであるか、可変長コマンドであるかを示す。例えば、コマンドタイプは、固定長コマンドの場合「０」、可変長コマンドの場合「１」と設定することができ、１ビットで表現される。固定長コマンドの場合、ラインコマンドのコマンドデータ長は全て固定長となる。なお、後述のように、可変長コマンドの場合、ラインコマンド毎にコマンドデータ長が異なるように規定される。実際には、各ラインコマンドの使用頻度に基づいてハフマン符号化を適用し、使用頻度の高いラインコマンドほどコマンドデータ長が短く、使用頻度の低いラインコマンドほどコマンドデータ長が長くなるように規定する。
【００４９】
「コマンド組み合わせＩＤ」は、その圧縮フォントデータに使用されているラインコマンドの組み合わせと、各コマンドのコマンドデータ長との関係を規定している。コマンド組み合わせＩＤの例を図３に示す。図３（ａ）はコマンドタイプが固定長コマンドである場合のコマンド組み合わせＩＤの例を示す。コマンドタイプが固定長コマンドの場合、コマンド組み合わせＩＤは、「０ｘ００」と「０ｘ０１」の２種類のいずれかとなり、１ビットで表現される。コマンド組み合わせＩＤが「０ｘ００」の場合は、ラインコマンドはコピーコマンドとオリジナルコマンドの２種類のみであるので、コマンド長は１ビットで表現できる。一方、コマンド組み合わせＩＤが「０ｘ０１」の場合は、ラインコマンドはオリジナルコマンド、コピーコマンド、黒ランレングスコマンド及び白ランレングスコマンドの４種類を使用するので、各ラインコマンドのコマンド長は２ビット必要となる。いずれの場合でも、コマンドタイプが固定長コマンドであるので、各ラインコマンドのコマンドデータ長は等しい。
【００５０】
図３（ｂ）はコマンドタイプが可変長コマンドである場合のコマンド組み合わせＩＤの例を示す。コマンドタイプが可変長コマンドである場合、各ラインコマンドは組み合わせＩＤに応じて、図４に示すようにハフマン符号化される。即ち、圧縮の対象となるビットマップフォントを構成する複数のラインのデータ内容を分析した上で、最も使用頻度の高いラインコマンドに短いコマンドデータ（０ｂ）が割り当てられ、使用頻度が低下する順に長いコマンドデータ（１０ｂ、１１０ｂ、１１１ｂ）が割り当てられるようなコマンド組み合わせＩＤがビットマップフォント毎に設定される。
【００５１】
図２（ｂ）に戻り、「コマンド列」は実際のビットマップフォントの各ライン毎に設定されたラインコマンドの列であり、図３に示すように、圧縮の対象となるビットマップフォントのライン数分のラインコマンドがコマンド列に含められる。
【００５２】
一方、図２（ａ）に示す圧縮データ部７４には、黒又は白ランレングスコマンドの引数データが圧縮データとして記述される。具体的には、圧縮データ（即ち引数データ）は、圧縮対象となるビットマップフォントの各ラインに含まれる線分（黒線分及び白線分）の長さを示すデータの連続により構成されている。当該ビットマップフォントの１ライン分のドット数（横ドット数、例えば３２ビット）ごとに圧縮データを区切ることにより、各ラインのランレングスデータ、即ち黒線分と白線分の配列が得られる。但し、オリジナルコマンドに対応するラインを構成するデータは元のビットマップフォントのオリジナルデータそのものとなる。また、コピーコマンドに対応するラインには対応する引数データ（圧縮データ）は存在しない。これらは、フォント伸張処理において、コマンド記述部７２内のコマンド列を参照して各ラインがどのラインコマンドにより表現されているかを分析することにより、区別することができる。
【００５３】
［圧縮データ例］
次に、上述のフォント圧縮方法により生成された圧縮フォントデータの具体例を説明する。以下に説明するのは、図６に示す漢字「乙」の圧縮フォントデータの例であり、字母データとしてのサイズ（即ち、圧縮前のサイズ）は３２ドット×３２ドットである。この文字の場合、最も圧縮率のよいコマンド記述部の設定としては、シフト数は「７」であり、コマンドタイプは可変長コマンドであり、コマンド組み合わせＩＤは「０ｘ０Ｂ」である。なお、これらの設定値は、フォント圧縮処理において、シフト数やコマンド組み合わせＩＤを変更しつつフォント全体の圧縮率を算出して比較する処理を繰り返すことにより決定されるが、その詳細については後述する。
【００５４】
文字「乙」の圧縮フォントデータ７０（図２（ａ）参照）において、そのコマンド記述部７２の内容は図２（ｂ）の最下行に示すようになる。即ち、シフト数＝７、コマンドタイプは可変長コマンド、コマンド組み合わせＩＤ＝０ｘ０Ｂであり、コマンド列の内容は図５に示すようになる。また、コマンド列中の各ラインコマンドに対応するコマンドデータ（ラインコマンドに対応するデータ）、そのデータ内容（引数データにより示されるドット配列）、及び各ラインの総ビット数を図７に示す。実際の圧縮フォントデータ７０の構成としては、コマンド記述部７２内のコマンド列が図５に示すものとなり、圧縮データ部７４には図７に示すデータ内容に対応する引数データ（２進数のランレングス符号）が含まれることになる。
【００５５】
また、コマンド記述部７２内のコマンド列は図５に示すものであると述べたが、実際には、各ラインコマンドは、コマンド組み合わせＩＤに基づいて決定され、図４に示すコマンドデータとなして記述されている。本例ではコマンド組み合わせＩＤ＝０ｘ０Ｂであるので、図４に示すように、白ランレングスコマンド［ＣＭＤ＿ＣＰＳ＿Ｗ］は「０ｂ」、黒ランレングスコマンド［ＣＭＤ＿ＣＰＳ＿Ｂ］は「１０ｂ」、オリジナルコマンド［ＣＭＤ＿ＯＲＧ］は「１１０ｂ」、コピーコマンド［ＣＭＤ＿ＣＰＹ］は「１１１ｂ」で表現されることになる。図７には、各ラインコマンドに対応するコマンドデータ例を示している。
【００５６】
本例では、圧縮の対象となるビットマップフォントは図６（ａ）に示す「乙」という文字であり、縦横３２ドットのサイズである。これを、シフト数７だけシフトすると、ビットマップフォントは図６（ｂ）に示すようになる。図６（ｂ）において、ビットマップフォントの横方向に３２個のライン（第０ライン〜第３１ラインと呼ぶことにする）が存在する。第０ライン〜第３１ラインまでの各ラインのデータ内容（白ドットと黒ドットの配列）をラインコマンド及び引数データで表現したものが図７に示されている。図７においてラインコマンドの左側に示されている数値（００〜３１）がライン数（第０ライン〜第３１ライン）に対応している。
【００５７】
図６（ｂ）からわかるように、第０ラインは全て白ドットであるので、第０ラインは白ランレングスコマンド（［ＣＭＤ＿ＣＰＳ＿Ｗ］）で表現され、対応するデータ内容（引数データ）は、白ドットが３２個連続する線分である（「白３２」と示してある）。また、長さ３２を示すランレングス符号は５ビットであるので、データ内容の括弧内に「５」が示されている。この結果、第０ラインのデータ内容（引数データ）の総ビット数は５ビットとなる。
【００５８】
図６（ｂ）において、第１ライン及び第２ラインは第０ラインと同じく白ドットのみが３２個続く構成である。よって、第１ライン及び第２ラインのラインコマンドはコピーコマンド（［ＣＭＤ＿ＣＰＹ  ］）であり、引数データは存在しないためライン毎の総ビット数はいずれの０ビットである。
【００５９】
第３ラインは、黒ドットが１８個、白ドットが１１個、黒ドットが３個という配列で構成されている。よって、第３ラインのラインコマンドは黒ランレングスコマンド（［ＣＭＤ＿ＣＰＳ＿Ｂ］）であり、その引数データとして「１８」、「１１」、「３」のハフマン符号が含まれている。それら符号のビット数はそれぞれ、５ビット、４ビット、２ビットであるので、第４ラインの総ビット数は１１ビットとなる。
【００６０】
このようにして、図６（ｂ）に示すシフト後のビットマップフォントの各ライン毎にデータ構成を分析してラインコマンド及び引数データが割り当てられている。本例は縦横３２ドットのビットマップフォントの例であるので、元のビットマップフォントをそのままデータ化すれば、１ラインは３２ドット分の白黒のデータ、即ち３２ビットのデータが必要となるが、ラインコマンドと引数データの組み合わせにより表現すれば、図７に示すように、１ラインを表現するのに要するビット数をかなり小さくすることができる。なお、（１ラインを表現するために要するビット数）＝（ラインコマンド自体のビット数＋引数データのビット数）、ということになるが、ラインコマンド自体は長いものでも３ビット程度であり、しかも前述のようにハフマン符号を使用しているので、引数データがよほど長くないかぎり、オリジナルデータに比べて圧縮効果が得られることになる。
【００６１】
なお、本例では、１ラインが３２ドットであり、どのラインでもランレングスコマンドにより圧縮効果が得られるので、図７に示すコマンド列中にオリジナルコマンド（［ＣＭＤ＿ＯＲＧ  ］）は登場していない。しかし、圧縮の対象となるビットマップフォントのサイズが例えば１０ドット×１０ドットなどと比較的小さく、１ライン中の白ドットと黒ドットの変化が激しい場合には、ランレングス符号化により得られた引数データの合計ビット数が、元の１ラインを白黒のデータ列（オリジナルデータ）として表現した場合のビット数（この場合１０ビット）より大きくなってしまうことがある。そのような場合には、当該ラインについてはオリジナルコマンドを使用し、引数データとしてオリジナルデータを持てばよい。
【００６２】
［フォント圧縮処理］
次に、圧縮フォントデータを生成するためのフォント圧縮処理について、図８を参照して説明する。図８は、フォント圧縮処理のフローチャートである。
【００６３】
フォント圧縮処理は、圧縮の対象となるフォント毎に実行され、当該フォントについて最も高い圧縮率を得ることができるコマンド記述部の設定、即ち、シフト数、コマンドタイプ、コマンド組み合わせＩＤなどを試行錯誤により決定する。そして、決定されたコマンド記述部の設定に従って、圧縮対象となるビットマップフォントをライン毎にラインコマンドで表現し、引数データを決定してフォントデータを圧縮し、圧縮フォントデータを得る。なお、フォント圧縮処理は、フォント圧縮プログラムを利用して、図１に示したフォント圧縮装置５により実行される。
【００６４】
図８を参照すると、まず、テンポラリーデータ長に圧縮前のビットマップフォントのフォントサイズを保存する（ステップＳ１）。テンポラリーデータ長とは、フォント圧縮処理中にデータ長を一時的に保存するための変数であり、上述のシフト数などを変更しつつ圧縮フォントデータのデータ長を算出する作業を繰り返す間に、それまでの作業で得られた最も小さいデータ長を常に記憶している変数である。
【００６５】
次に、フォント圧縮処理は、各ラインにラインコマンドを割り当てる（ステップＳ２）。本発明の圧縮方法では、前述の４種類のラインコマンドの全てを使用するか、オリジナルコマンドとコピーコマンドのみを使用するかなど、使用するラインコマンドの選択方法によって、１ラインを表現するデータ長（＝コマンド記述部＋データ圧縮部）が変化し、圧縮率が変化する。よって、ステップＳ２では、どのラインコマンドを使用するかを設定する。この設定を繰り返し変えながらデータ圧縮率を比較することにより最適なコマンド記述部の設定が得られることになる。
【００６６】
なお、ラインコマンドとして黒ランレングスコマンドと白ランレングスコマンドのデータ圧縮の効率を考えたとき、ランレングス符号化により得られる圧縮データ長がオリジナルデータ長と比較して１又は２以下しか圧縮されない場合は、ラインコマンドのデータ長を加えると、むしろランレングス符号化した方がオリジナルデータよりもデータ長が長くなってしまう場合もある。この点を考慮して、最初にコマンドの割り当てを行う場合は、暫定的なラインコマンドとして、先にあげた４種類のラインコマンドに以下のコマンドを追加する。これにより、ラインコマンド自体のデータ長を考慮してデータ長の評価を行うことができる。
【００６７】
・白ランレングスマイナス１コマンド：引数データ部が１縮まる。
【００６８】
・白ランレングスマイナス２コマンド：引数データ部が２縮まる。
【００６９】
・黒ランレングスマイナス１コマンド：引数データ部が１縮まる。
【００７０】
・黒ランレングスマイナス２コマンド：引数データ部が２縮まる。
【００７１】
そして、圧縮対象となるビットマップフォントの各ラインに、以下のようにラインコマンドを割り当てる（但し、コマンド記述部の長さは考慮しない。）
▲１▼直前のラインと同じラインの場合はコピーコマンドを使用する。
【００７２】
▲２▼ランレングスコマンドによる引数データ長がオリジナルデータ長より大きくなる場合は、オリジナルコマンドを使用する。
【００７３】
▲３▼ランレングスコマンドによる引数データ長が１ドット縮まる場合はランレングスマイナス１コマンドを使用する。
【００７４】
▲４▼ランレングスコマンドによる引数データ長が２ドット縮まる場合はランレングスマイナス２コマンドを使用する。
【００７５】
▲５▼ランレングスコマンドによる引数データ長が３ドット以上縮まる場合はランレングスコマンドを使用する。
【００７６】
なお、▲３▼〜▲５▼は、黒スタート、白スタートでもコマンドは異なる。
【００７７】
こうして、各ラインにラインコマンドを割り当てる。そして、そのように割り当てたラインコマンドに基づいて、コマンド記述部＋圧縮データ部の長さが最小となるコマンド記述部を設定し、そのときの圧縮後のデータ長（「圧縮データ長」と呼ぶ）を算出する（ステップＳ３）。次に、フォント圧縮処理は、そうして得られた圧縮データ長がテンポラリーデータ長より小さいか否かを判定する（ステップＳ４）。圧縮データ長が小さければ（ステップＳ４；ｙｅｓ）、そのときのコマンド記述部の設定が、それまでで最も高い圧縮率をもたらすことになるので、その圧縮データ長をテンポラリーデータ長として保存し、コマンド記述部の設定（シフト数を含む）を内部メモリなどに一時的に保存する（ステップＳ５）。これにより、それまでの処理において、最も高い圧縮率を提供する設定が記憶されたことになる。
【００７８】
一方、ステップＳ４で圧縮データ長がテンポラリーデータ長より小さくない場合（ステップＳ４；ｎｏ）、そのときのコマンド記述部の設定は最も高い圧縮率を提供するものではないので、処理はステップＳ６へ進み、当該ビットマップフォントの最大シフト量分のシフトが既に行われたかを判定し、行われていなければ、ステップＳ７でフォントを１つシフトし、ステップＳ２へ戻る。これにより、ビットマップフォントを１ドット分シフト（図６のシフト処理参照）した状態で、再度ラインコマンドを割り当て、コマンド記述部を決定して圧縮データ長を算出し、テンポラリーデータ長と比較するという一連の処理を繰り返す（ステップＳ２〜Ｓ５）。こうして、ステップＳ６の判定結果がｙｅｓとなるまで、即ち、当該ビットマップフォントについて適用可能な最大シフト数までシフト処理を完了するまでステップＳ２からＳ７を繰り返し、シフト処理が全て完了した時点で、処理はステップＳ８へ進む。処理がステップＳ８へ進んだ段階で、シフト数などのコマンド記述部の設定を様々に変更した結果最も高い圧縮率を提供するコマンド記述部の設定が内部メモリなどに記憶された状態となっている。
【００７９】
ステップＳ８では、そのときのテンポラリーデータ長（最も高い圧縮率で圧縮した場合のデータ長を示している）が圧縮対象のビットマップフォントのデータサイズより小さいか否かを判定する。小さい場合には、そのときに保存されているコマンド記述部の設定に従って圧縮対象となるビットマップフォントを、保存したシフト数分左にシフトし（ステップＳ９）、保存したコマンド記述部の設定に従ってシフト後の各ラインをラインコマンドで表現して圧縮する（ステップＳ１０）。最後に、圧縮後のフォントデータのヘッダ部分に、圧縮処理がなされていることを示す圧縮フラグを設定し（ステップＳ１１）、処理を終了する。
【００８０】
一方、ステップＳ８でテンポラリーデータ長が元のビットマップフォントのデータサイズより大きい場合は、圧縮しない方がデータ量が小さいわけであるから、圧縮処理を行わず、当該ビットマップフォントのデータのヘッダ部分に、未圧縮であることを示すフラグを設定して（ステップＳ１２）、処理を終了する。
【００８１】
以上のように、本実施形態のフォント圧縮処理では、対象となるビットマップフォントに対して、使用するラインコマンドの種類やシフト数などを順に変更しつつ圧縮後のデータ長を算出して最も高い圧縮率が得られるコマンド記述部の設定を求め、それに従って圧縮を行う。よって、対象となるフォント毎に独立して、最大の圧縮率でデータ圧縮を行うことができる。
【００８２】
［フォント伸張処理］
次に、フォント伸張処理について図９を参照して説明する。図９はフォント伸張処理のフローチャートである。なお、フォント伸張処理は、図１に示すプログラムＲＯＭ２０内に記憶されているフォント伸張プログラムをＣＰＵ１６が実行することにより行われる。
【００８３】
フォント伸張処理は、まず、表示すべき圧縮フォントデータをフォントＲＯＭ２２から読み出し（ステップＳ２０）、当該圧縮フォントデータのヘッダ部分の圧縮フラグが立っている（＝「１」である）か否かを判定する（ステップＳ２１）。圧縮フラグが立っている場合、その圧縮フォントデータのコマンド記述部の設定に従って、各ライン毎にデータを伸張してビットマップフォントを得る（ステップＳ２１）。さらに、伸張されたビットマップフォントをシフト数に応じて右シフトして、圧縮処理前のビットマップフォントを再生する（ステップＳ２３）。
【００８４】
一方、ステップＳ２０でヘッダ部分のフラグが立っていない場合は、その圧縮フォントデータは実は圧縮されていないので、伸張処理を行う必要はなく、処理は終了する。
【００８５】
［変形例］
上記の実施形態では、ビットマップフォントを横方向の複数のラインに分割してライン毎にラインコマンドを使用して圧縮を行っているが、その代わりに縦方向のラインに分割し、縦方向に同様にラインコマンドを適用して圧縮を行うことも可能である。
【００８６】
以上説明したように、本発明のフォント圧縮方法によれば、フォント毎に最も高い圧縮率が得られるようにコマンド記述部の設定（シフト数、ラインコマンドの種類など）を決定し、その設定に従って圧縮フォントデータを生成する。圧縮フォントデータの生成処理自体は時間を要するが、これは携帯端末装置の製造元などが予め実行する処理であり、利用者が使用する携帯端末装置側で実行されるわけではないので問題はない。逆に、伸張処理は上述のようにコマンド記述部の設定に従ってデータを復元する単純な処理であるので、ＣＰＵなどの能力のあまり高くない携帯端末装置においても十分実行することができる。
【００８７】
また、圧縮フォントデータの作成時には、それを使用する携帯端末装置の処理能力などを考慮して、圧縮方法を最適化することができる。即ち、ターゲットとなる携帯端末装置が高い圧縮率を要求する場合にはシフトコマンド、回転コマンド、反転コマンドなどの面コマンドを適用して高い圧縮率を実現することができるし、ターゲットとなる携帯端末装置が圧縮率よりも表示時の処理速度を要求する場合には面コマンドを適用しないこととしてもよい。そして、そのように圧縮方法を変化させた場合でも、フォント伸張処理においては単純にコマンド記述部の設定に従って伸張処理を行えばよい。
【００８８】
また、こうして各サイズのビットマップフォントを圧縮して記憶できるので、伸張した後の字母データをさらに拡大・縮小処理することで、任意のサイズのフォントを容易に生成することが可能である。
【００８９】
また、本発明のフォント圧縮方法は、１つのフォント毎に独立して圧縮を行うので、文字の部首やつくりなど部分ごとにデータを共有化して差分データを持つなどの従来の手法と異なり、必要なフォントの形状をそのまま保存することができ、美しいフォントを得ることができる。さらに、１文字のビットマップフォントを構成するドット配列をラインコマンドを利用して圧縮するので、漢字だけでなく、ハングル文字、中国公用文字、アラビア文字などの多種の文字にも対応可能である。
【図面の簡単な説明】
【図１】本発明の圧縮フォントデータを表示する携帯端末装置の概略構成を示す。
【図２】圧縮フォントデータのデータ構造を示す。
【図３】圧縮フォントデータ中のコマンド組み合わせＩＤ及びコマンド例を示す。
【図４】圧縮フォントデータ中のコマンド組み合わせＩＤの例を示す。
【図５】圧縮フォントデータ中のコマンド列の例を示す。
【図６】圧縮対象となるフォント例及びシフト例を示す。
【図７】図６に示すフォント例のコマンド列及びコマンドデータ例を示す。
【図８】フォント圧縮処理のフローチャートである。
【図９】フォント伸張処理のフローチャートである。
【符号の説明】
５  フォント圧縮装置
１０  携帯端末装置
１２  表示部
１４  処理フォントメモリ
１６  ＣＰＵ
１８  入力部
２０  プログラムＲＯＭ
２２  フォントＲＯＭ
２４  ＲＡＭ
【図１】
2004240125.tif 000003
【図２】
2004240125.tif 000004
【図３】
2004240125.tif 000005
【図４】
2004240125.tif 000006
【図５】
2004240125.tif 000007
【図６】
2004240125.tif 000008
【図７】
2004240125.tif 000009
【図８】
2004240125.tif 000010
【図９】
2004240125.tif 000011