(57)【要約】【課題】  フォントデータの圧縮効率を上げつつ、展開の処理に負担がかかり過ぎないようにすること。【解決手段】  複数のフォントデータを、それぞれ複数の圧縮方法のうちの一つの圧縮方法を用いて圧縮させてフォント実データ４１ｃとしてフォントファイル４１に記憶させ、オフセットデータ４１ｂに、各フォントデータの圧縮方法が何であるかを判別するための情報を記憶させる。圧縮されたフォントデータを展開する際には、オフセットデータ４１ｂに記憶された圧縮方法が参照され、その圧縮方法に対応した展開方法で展開処理が行われる。【選択図】      図９
2008122637.tif 000002
【特許請求の範囲】
【請求項１】
複数のビットマップデータを、それぞれ複数の圧縮方法のうちの一つの圧縮方法を用いて圧縮させて記憶した圧縮データ記憶手段と、
前記圧縮されたビットマップデータの各々の圧縮方法を示す判別子を記憶した判別子記憶手段と、
この判別子記憶手段に記憶された判別子を参照して、対応する圧縮されたビットマップデータの圧縮方法を判別する判別子参照手段と、
この判別子参照手段によって判別された圧縮方法に対応した展開処理を、前記圧縮データ記憶手段に記憶されている複数の圧縮されたビットマップデータそれぞれに施す展開処理手段と、
この展開処理手段によって展開処理を施されたビットマップデータを表示する表示手段と、を有することを特徴とする電子装置。
【請求項２】
前記ビットマップデータは白黒を示す二値のデータであり、
前記圧縮方法は、前記ビットマップデータの連続する白又は黒のデータについて、１ビットで白又は黒を示し、この１ビットに隣接した所定数のビットで前記白又は黒の連続数を示すことを特徴とする請求項１記載の電子装置。
【請求項３】
前記ビットマップデータは、フォントデータであることを特徴とする請求項１乃至２記載の電子装置。
【請求項４】
コンピュータを、
複数のビットマップデータを、それぞれ複数の圧縮方法のうちの一つの圧縮方法を用いて圧縮させて記憶した圧縮データ記憶手段、
前記圧縮されたビットマップデータの各々の圧縮方法を示す判別子を記憶した判別子記憶手段、
この判別子記憶手段に記憶された判別子を参照して、対応する圧縮されたビットマップデータの圧縮方法を判別する判別子参照手段、
この判別子参照手段によって判別された圧縮方法に対応した展開処理を、圧縮されたビットマップデータに施す展開処理手段、
この展開処理手段によって展開処理を施されたビットマップデータを表示する表示手段、として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、圧縮されたビットマップデータを展開して表示する機能を備えた電子装置に関する。
【背景技術】
【０００２】
電子辞書や携帯電話やＰＤＡ等の携帯端末は、表示領域、記憶領域、処理速度等に制限がある。そのため、文字等の表示に用いるフォントには、ビットマップフォントが通常使用される。ビットマップフォントは、画素の組み合わせで文字を表現したフォントであり、文字の輪郭を関数曲線で表現したアウトラインフォントとは異なる。ビットマップフォントは少ない画素数ではデータ量が小さくなり、描画速度もアウトラインフォントより高速なので、電子辞書や携帯電話やＰＤＡ等の携帯端末において、特に適している。以下、フォントデータと記載した場合はビットマップフォントのデータを指すこととする。
【０００３】
フォントデータを圧縮することで、記憶領域の節約をすることが試みられている。フォントデータの白のドットと黒のドットをそれぞれ二進数における０と１で表現した場合、０又は１が連続で出現する箇所がある。その箇所において、４ビットの最上位１ビットを０か１かの判別に使用し、残り３ビットでその連続数を表す、４ビット圧縮という手法がある。これにより最も圧縮率が高くなるのは、８ビット同じビットが連続したときで、４ビットに圧縮できる。同様にして、８ビットの最上位１ビットを０か１かの判別に使用し、残り７ビットでその連続数を表す、８ビット圧縮がある。これにより最も圧縮率が高くなるのは、１２８ビット（＝１６バイト）同じビットが連続したときで、８ビットに圧縮できる。
【０００４】
これまで、フォントデータを圧縮する際には、４ビット圧縮や８ビット圧縮等の圧縮方法のいずれか１種類を用いてすべてのフォントについて圧縮することが行われてきた。また、フォントデータ内のラインごとに、圧縮効率が上がるようにランレングス符号化やハフマン符号化などを使い分けて圧縮する方法が考えられている（例えば特許文献１参照）。
【０００５】
【特許文献１】特開２００４−２４０１２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、圧縮方法１種類だけを用いて全体を圧縮した場合、圧縮効率をあげるためには圧縮方法そのものを見直す必要があり、技術的に難しいという問題があった。また、特許文献１のような方法では圧縮効率は上がるが、圧縮されたデータを展開する際に複数の展開処理が必要なため、時間がかかってしまうという問題があった。
【０００７】
本発明は、以上の問題を解決するためになされたものであり、フォントデータの圧縮効率を上げつつ、展開の処理に負担がかかり過ぎないようにすることを目的とする。
【課題を解決するための手段】
【０００８】
すなわち、本発明の請求項１に係る電子装置は、複数のビットマップデータを、それぞれ複数の圧縮方法のうちの一つの圧縮方法を用いて圧縮させて記憶した圧縮データ記憶手段と、前記圧縮されたビットマップデータの各々の圧縮方法を示す判別子を記憶した判別子記憶手段と、この判別子記憶手段に記憶された判別子を参照して、対応する圧縮されたビットマップデータの圧縮方法を判別する判別子参照手段と、この判別子参照手段によって判別された圧縮方法に対応した展開処理を、圧縮されたビットマップデータに施す展開処理手段と、この展開処理手段によって展開処理を施されたビットマップデータを表示する表示手段と、を有することを特徴とする。
【０００９】
本発明の請求項２に係る電子装置は、請求項１に係る電子装置において、前記ビットマップデータは白黒を示す二値のデータであり、前記圧縮方法は、前記ビットマップデータの連続する白又は黒のデータについて、１ビットで白又は黒を示し、この１ビットに隣接した所定数のビットで前記白又は黒の連続数を示すことを特徴とする。
【００１０】
本発明の請求項３に係る電子装置は、請求項１又は請求項２に係る電子装置において、前記ビットマップデータは、フォントデータであることを特徴とする。
【発明の効果】
【００１１】
本発明に係る電子装置は、それぞれのビットマップデータを適した圧縮方法で圧縮して記憶しているので圧縮効率を上げることができ、圧縮されたビットマップデータの各々の圧縮方法を判別子として記憶し、この判別子を参照して展開方法を決定することができるので、展開処理における負担がかかり過ぎることがない。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を実施形態に基づいて詳細に説明する。
【００１３】
図１は、本発明を適用した携帯端末装置の構成を示すブロック図である。図１に示すように、携帯端末装置１０は、入力部２０と、ＣＰＵ３０と、ＲＯＭ４０と、ＲＡＭ５０と、表示部６０とを備える。ＲＯＭ４０は、フォントファイル４１と、展開プログラム４２と、その他各種プログラムとを備える。
【００１４】
入力部２０は、電子辞書においては文字キーや各種機能キー等を備えたキーボード、携帯電話においては文字入力にも使用できる数字ボタンと各種機能ボタン、ＰＤＡにおいてはタッチペン等による接触を検知するタブレット等により構成される。ユーザーが入力部２０を介して入力した情報は、電気信号に変換されてＣＰＵ３０へ出力される。
【００１５】
表示部６０は、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）等により構成され、ＣＰＵ３０から入力される電気信号に基づいて、ビットマップフォント等を表示させる。
【００１６】
ＲＡＭ５０は、入力部２０からの入力情報や、フォントファイル４１を展開プログラム４２に従って展開する際に発生するデータなどの一時的な記憶領域として、ＣＰＵ３０を介して使用される。
【００１７】
ＲＯＭ４０に備えられたフォントファイル４１は、フォントサイズごとに別ファイルとして記憶されている。フォントファイル４１は、図２に示したようにファイルヘッダー４１ａと、オフセットデータ４１ｂと、フォント実データ４１ｃとから構成されている。
【００１８】
ファイルヘッダー４１ａには、ファイルに含まれる文字のコード範囲やフォントサイズ等の情報が記憶されている。オフセットデータ４１ｂには、図３に示したように、フォント実データの位置が３２ビットの固定長で記憶されている。実際には、各フォント実データへの位置情報としては３２ビットも使う必要はないので、本発明では、このうち最上位２ビットを利用して、各フォント実データの圧縮方法を記憶し、残り３０ビットでフォント実データの位置情報を記憶している。圧縮方法についての詳細は後述するが、例えばここでは、無圧縮を００、４ビット圧縮を０１、８ビット圧縮を１０として記憶する。フォント実データ４１ｃは、各ビットマップフォントをそれぞれの圧縮方法で圧縮したものを記憶している。なお、オフセットデータ４１ｂのデータ長をここでは３２ビットとしたが、フォント実データの位置情報を表せる固定長の情報量であれば良い。
【００１９】
ＲＯＭ４０に備えられた展開プログラム４２は、フォントファイル４１に記憶された圧縮されたビットマップフォントを展開するためのプログラムである。各種の圧縮方法に対応した展開プログラムをそれぞれ備えている。
【００２０】
ＣＰＵ３０は、携帯端末装置全体の制御を司るものであり、ＲＯＭ４０内に備えられた展開プログラム４２によるフォントファイル４１の展開処理を実行する。なお、ＣＰＵ３０は、ＲＯＭ４０内に備えられたその他各種プログラムを実行するが、本発明とは直接の関連はないので、説明を省略する。
【００２１】
ここで、フォントファイル４１に記憶された、圧縮されたビットマップフォントの圧縮方法について述べる。
【００２２】
まず、４ビット圧縮についての説明をする。４ビット圧縮では、４ビットの最上位１ビットで連続するビットが０か１かを表し、残り３ビットでその連続数を表現する。３ビットは、「０００」のときに１個を表すとし、「００１」で２個、「０１０」で３個というように、「３ビットが表す数＋１」個の値を表すとする。
【００２３】
元データが、図４のような６バイトのデータで与えられたとする。ここで、例えば２進数表現で１バイトのデータ、「００００００００」を４ビット圧縮する場合、最上位の１ビットは「０」。下位３ビットでその連続数を表現するが、ここでは８個０が連続しているので７の２進数表現「１１１」となり、合わせて「０１１１」となる。同様にして、元データが「１１１１１１１１」であれば、最上位が「１」、続いて「１１１」となり、合わせて「１１１１」となる。全体を４ビット圧縮すると、６バイトの元データが３バイトまで圧縮される。
【００２４】
次に、８ビット圧縮についての説明をする。８ビット圧縮は、４ビット圧縮において連続数を表していた３ビットを７ビットまで拡張したもので、１２８個までの連続数を表現できる。元データが、図５のような１６バイトのデータで与えられたとする。このデータは１６バイト＝１２８ビット０が続いたものなので、これを８ビット圧縮すると最上位が「０」、下位７ビットが「１１１１１１１」となり、合わせて「０１１１１１１１」となる。すなわち、１６バイトのデータが１バイトに圧縮されている。
【００２５】
図４と図５の説明では、４ビット圧縮、８ビット圧縮がそれぞれ最大の圧縮率となる例を示した。図６には、元データとして実際のフォントデータに出現するデータの一部を用い、この元データをそれぞれ４ビット圧縮、８ビット圧縮したものを示した。これを見ると、元データの先頭１７ビットは「０」が連続しており、４ビット圧縮すると元データの先頭１６ビットが「０１１１  ０１１１」と、８ビットに圧縮される。しかし、元データの１７ビット目の「０」は１つと見なされ、４ビット圧縮すると「００００」と４ビットに拡張されてしまう。８ビット圧縮の場合も同様に、元データの「１１１」が「１０００００１０」と、３ビットから８ビットに拡張されている。このように、連続するデータが少ない場合には、圧縮されない場合もある。図６の例では、４ビット圧縮したものが最も圧縮効率が良いことが分かる。
【００２６】
図７は漢字の「亜」をビットマップフォントで表現したときのデータで、無圧縮のまま、４ビット圧縮したもの、８ビット圧縮したもの、のそれぞれを１６進数で表現したものを示している。これを見ると、４ビット圧縮したものが最も圧縮効率が良いことが分かる。
【００２７】
図８は漢字の「一」をビットマップフォントで表現したときのデータで、図７と同様に、無圧縮のまま、４ビット圧縮したもの、８ビット圧縮したもの、のそれぞれを１６進数で表現したものを示している。これを見ると、８ビット圧縮したものが最も圧縮効率が良いことが分かる。
【００２８】
このように、フォントデータそれぞれで圧縮効率の良い圧縮方法は異なる。従って、複数の圧縮方法を用いて、それぞれのフォントデータを最も圧縮効率の良い圧縮方法で圧縮すれば、全体の圧縮効率を高めることができる。例えばここでは、「亜」は４ビット圧縮、「一」は８ビット圧縮され、フォントファイル４１内にフォント実データ４１ｃとして保存される。例としては示していないが、４ビット圧縮や８ビット圧縮をするよりも、無圧縮のままの方がデータ量の小さいフォントデータもある。そのようなフォントデータは、無圧縮のまま保存される。
【００２９】
図９は、圧縮されたフォントデータを展開するときの処理をフローチャートで示したものである。ＣＰＵ３０によって、あるフォントのサイズとコードが指定されると、先頭のフォントファイルにアクセスされ（ステップＳ１）ファイルヘッダーが読み出され（ステップＳ２）、参照したいフォントのサイズが該当するサイズか否かが判定される（ステップＳ３）。該当するサイズでないと判定された場合、次のフォントファイルがアクセスされ（ステップＳ４）、ステップＳ２の処理に戻る。
【００３０】
ステップＳ３で該当するサイズであると判定された場合、該当するコードのオフセットデータ位置を取得する為の処理が行われる。オフセットデータは固定長なので、何番目のオフセットデータであるかが与えられれば、オフセットデータ位置が求まる。参照したいフォントのコードと、ファイルヘッダーに記憶されたコード範囲から、参照したいフォントが何番目かが求まるので、該当するコードのオフセットデータ位置が取得される（ステップＳ５）。このオフセットデータ位置からデータを読み出し（ステップＳ６）、オフセットデータの上位２ビットを調べる（ステップＳ７）。この２ビットが００であった場合、オフセットデータに対応するフォント実データは無圧縮であるので、展開処理が施されずにそのまま出力される（ステップＳ８）。この２ビットが０１であった場合は４ビット展開、１０であった場合は８ビット展開が、それぞれオフセットデータに対応するフォント実データに処理されて出力される（ステップＳ９、ステップＳ１０）。
【００３１】
以上のように、オフセットデータ４１ｂの上位２ビットに記憶された圧縮方法を参照することで展開方法が判断される。従って、新たな圧縮方法、例えばゼロ圧縮（０をバイト単位で圧縮する方法）やハフマン圧縮等を追加したい場合、オフセットデータの上位２ビットにその圧縮方法に対応した展開をすることを割り振ればよい。
【００３２】
図８には、ゼロ圧縮を用いた場合のデータも記載した。ゼロ圧縮とは、１バイトの０すなわち１６進数で「００」が続く場合に、１バイトでその連続数を表して圧縮する方法である。例えば、図８のゼロ圧縮のデータを見ると、最初の２バイトは「００７７」となっているが、これは１６進数で「００」が「７７」個連続している、すなわち、０が１１９バイト連続していることを表している。このように、ゼロ圧縮は０のデータが連続するデータには特に有効で、この例のように漢字の「一」においては８ビット圧縮よりも高い圧縮率となっている。従って、この場合にはゼロ圧縮も用いれば、フォントデータ全体をより良く圧縮できることが分かる。
【００３３】
また、５種類以上の展開方法を用いたければ、必要に応じてオフセットデータの上位３ビット以上を用いることも可能である。このように、本発明によればそれまでのデータ構造を大きく変えることなく新たな圧縮方法を持たせることができる。
【００３４】
なお、本実施例ではフォントデータについて述べたが、本発明はビットマップ形式で表されるものであればフォントデータに限らず適用可能で、例えば画像のビットマップデータ等にも適用できる。
【００３５】
また、大きなビットマップデータに適用した場合、必要に応じて複数のブロックに分割し、ブロックごとに最適な圧縮方法を適用すれば、より効率の良い圧縮ができる。
【００３６】
また、本実施例では白黒のビットマップデータについて述べたが、カラーのビットマップデータについても、圧縮方法を変更することで対応できる。
【００３７】
また、本実施例では発明を適用する電子装置として携帯端末装置を例に挙げたが、それ以外でも、例えば電子ジャーや電子ポット等の家庭用電気器具や、電光掲示板等、ドット数の少ない表示装置を備えた電子装置全般において適用可能である。
【図面の簡単な説明】
【００３８】
【図１】本発明の実施の形態に係る携帯端末装置の構成を示すブロック図。
【図２】フォントファイル４１のデータ構造を示した図。
【図３】オフセットデータ４１ｂのデータ構造を示した図。
【図４】４ビット圧縮について説明する為の図。
【図５】８ビット圧縮について説明する為の図。
【図６】４ビット圧縮と８ビット圧縮について説明する為の図。
【図７】フォント「亜」の各種圧縮方法によるデータ量を示した図。
【図８】フォント「一」の各種圧縮方法によるデータ量を示した図。
【図９】圧縮されたフォントの展開処理の流れを示したフローチャート。
【符号の説明】
【００３９】
１０  携帯端末装置
２０  入力部
３０  ＣＰＵ
４０  ＲＯＭ
４１  フォントファイル
４１ａ  ファイルヘッダー
４１ｂ  オフセットデータ
４１ｃ  フォント実データ
４２  展開プログラム
５０  ＲＡＭ
６０  表示部
【図１】
2008122637.tif 000003
【図２】
2008122637.tif 000004
【図３】
2008122637.tif 000005
【図４】
2008122637.tif 000006
【図５】
2008122637.tif 000007
【図６】
2008122637.tif 000008
【図７】
2008122637.tif 000009
【図８】
2008122637.tif 000010
【図９】
2008122637.tif 000011