(57)【要約】【課題】ビットマップデータの表示時間を短縮するとともに、フォントテーブルの容量を削減する。【解決手段】ビットマップデータの開始アドレスを与えるポインタテーブルとして、文字コードの先頭００００ｈから最終のＦＦＦＦｈまでの全てのレコードを有するテーブル１０を用いる。各レコードにはビットマップデータの開始アドレスを格納する。これにより、文字コードから対応するレコードに直接アクセスして開始アドレスを取得する。また、ポインタテーブルとして、使用されない文字コード領域を削除した第１ポインタテーブル１２と、削除前と削除後の各領域のアドレス位置関係を規定する第２ポインタテーブルとを併用してフォントテーブルの容量を削減する。【選択図】図５
2007101605.tif 000002
【特許請求の範囲】
【請求項１】
所与の符号化文字集合に含まれる全ての文字コードに対応するビットマップデータの開始アドレスを格納する初期ポインタテーブルと、
表示すべき文字コードが入力されると、前記初期ポインタテーブルを参照して入力文字コードに対応するビットマップデータの開始アドレスを取得して文字を表示装置に表示するプロセッサと、
を有するフォント管理装置であって、
前記初期ポインタテーブルは、全文字コードの先頭から最後までに対応するレコードを有し、各レコードは固定長で各文字コードのビットマップデータの開始アドレスを格納し、
前記プロセッサは、入力された文字コードから前記ポインタテーブルの対応レコードに直接アクセスして前記開始アドレスを取得することを特徴とするフォント管理装置。
【請求項２】
所与の符号化文字集合に含まれる全ての文字コードに対応するビットマップデータの開始アドレスを格納するポインタテーブルと、
表示すべき文字コードが入力されると、前記ポインタテーブルを参照して入力文字コードに対応するビットマップデータの開始アドレスを取得して文字を表示装置に表示するプロセッサと、
を有するフォント管理装置であって、
前記ポインタテーブルは、第１ポインタテーブルと第２ポインタテーブルを含み、
前記第１ポインタテーブルは、
全文字コードの先頭から最後までに対応した各文字コードのビットマップデータの開始アドレスを格納する固定長レコードを有する初期ポインタテーブルからビットマップデータが存在しない文字コードの領域の少なくとも一部を削除して構成され、
前記第２ポインタテーブルは、
削除せずに残存した文字コードの領域の前記第１ポインタテーブルにおける位置と前記初期ポインタテーブルにおける位置との関係を格納するものであり、
前記プロセッサは、前記第２ポインタテーブルにアクセスして入力された文字コードの第１ポインタテーブルにおけるアドレスを取得し、取得したアドレスを用いて前記第１ポインタテーブルの対応レコードに直接アクセスして前記開始アドレスを取得することを特徴とするフォント管理装置。
【請求項３】
請求項２記載の装置において、
前記第１ポインタテーブルは、前記初期ポインタテーブルの前記ビットマップデータが存在しない文字コードの領域のサイズがしきい値以上である場合にのみ削除して構成されることを特徴とするフォント管理装置。
【請求項４】
請求項２記載の装置において、
前記第１ポインタテーブルは、前記初期ポインタテーブルの前記ビットマップデータが存在しない文字コードの領域が複数存在する場合に、削除すべき領域数として前記第１ポインタテーブル及び前記第２ポインタテーブルの合計容量が許容メモリ容量以下となる最小領域数に設定されてなることを特徴とするフォント管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はフォント管理装置に関し、特に入力された文字コードに対応するフォントをメモリから読み出す技術に関する。
【背景技術】
【０００２】
携帯電話やデジタルカメラ等の携帯機器の高機能化及び市場の拡大に伴い、多種多様な文字を携帯機器の表示装置に表示する必要性が高まっている。各文字には文字コードが割り当てられ、文字コードにはＪＩＳ漢字コードやユニコード等各種のコードが存在するが、複数言語に対応するためにすべての文字に２バイトのコードを割り振ったユニコードを用いる場合が多い。
【０００３】
文字を表示装置に表示する際には、ビットマップデータの開始アドレスと文字コードとを１：１に対応させたテーブルを用意しておき、入力された文字コードをキーとしてこの文字コードに対応する開始アドレスをこのテーブルから検索し、検索して得られた開始アドレスからビットマップデータデータを読み出して表示すればよい。
【０００４】
図１０に、従来の検索テーブルの一例を示す。文字コードは１６進法で表され、テーブルの各レコードには文字コードとそれに対応するビットマップデータの開始アドレスが対になって格納される。上位装置から文字コードが入力されると、プロセッサはこのテーブルの先頭から順次検索してその文字コードに対応する開始アドレスを読み出す。
【０００５】
なお、下記の特許文献には、検索テーブルを文字コードのコード系に合わせて分割することが開示されている。
【０００６】
【特許文献１】特開平５−２６５４２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、図１０に示すような文字コードをキーとして検索する構成では、入力された文字コードの開始アドレスを得るために該テーブルの先頭から順次検索する必要があり、最終的に入力された文字を表示装置に表示するまでに時間を要する問題があった。もちろん、サポートする文字コードの範囲が狭い場合にはこのような方式でも問題は生じないが、複数言語をサポートする場合には文字コードの範囲が膨大なものとなるため検索速度が極端に低下してしまう。デジタルカメラの画面に一度に大量の文字を表示する場合等には１つの文字の描画に要する検索時間は少しでも短くする必要があり、このような検索速度の低下は好ましくない。さらに、携帯機器の用途を考慮すると、テーブルを格納するメモリ容量をできるだけ少なくしてシステムリソースを有効に活用することも要求される。
【０００８】
本発明は、フォントの検索時間を短縮できるとともに、システムリソースを有効に活用してコストを低減できる装置を提供することにある。
【課題を解決するための手段】
【０００９】
本発明は、所与の符号化文字集合に含まれる全ての文字コードに対応するビットマップデータの開始アドレスを格納する初期ポインタテーブルと、表示すべき文字コードが入力されると、前記初期ポインタテーブルを参照して入力文字コードに対応するビットマップデータの開始アドレスを取得して文字を表示装置に表示するプロセッサとを有するフォント管理装置であって、前記初期ポインタテーブルは、全文字コードの先頭から最後までに対応するレコードを有し、各レコードは固定長で各文字コードのビットマップデータの開始アドレスを格納し、前記プロセッサは、入力された文字コードから前記ポインタテーブルの対応レコードに直接アクセスして前記開始アドレスを取得することを特徴とする。
【００１０】
また、本発明は、所与の符号化文字集合に含まれる全ての文字コードに対応するビットマップデータの開始アドレスを格納するポインタテーブルと、表示すべき文字コードが入力されると、前記ポインタテーブルを参照して入力文字コードに対応するビットマップデータの開始アドレスを取得して文字を表示装置に表示するプロセッサとを有するフォント管理装置であって、前記ポインタテーブルは、第１ポインタテーブルと第２ポインタテーブルを含み、前記第１ポインタテーブルは、全文字コードの先頭から最後までに対応した各文字コードのビットマップデータの開始アドレスを格納する固定長レコードを有する初期ポインタテーブルからビットマップデータが存在しない文字コードの領域の少なくとも一部を削除して構成され、前記第２ポインタテーブルは、削除せずに残存した文字コードの領域の前記第１ポインタテーブルにおける位置と前記初期ポインタテーブルにおける位置との関係を格納するものであり、前記プロセッサは、前記第２ポインタテーブルにアクセスして入力された文字コードの第１ポインタテーブルにおけるアドレスを取得し、取得したアドレスを用いて前記第１ポインタテーブルの対応レコードに直接アクセスして前記開始アドレスを取得することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、所与の符号化文字集合に含まれる全ての文字コードに対応するビットマップデータの開始アドレスを格納したレコードを有する初期ポインタテーブルにおいて、数字である所与の文字コードに対して単純な計算処理を行うことにより直接的に、該文字コードのビットマップデータ開始アドレスを格納するレコードへアクセスできる。このため、文字コードをキーとしてテーブルを検索するという従来技術においては必須である多大な時間を要する工程を行うことなく、極めて短時間で所望のビットマップ開始アドレスを取得できる。また、ポインタテーブルとして、ビットマップデータが存在しない文字コードの領域を上記の初期ポインタテーブルから削除した第１ポインタテーブルと、アドレスの位置関係を格納する第２ポインタテーブルとを併用することで、ポインタテーブル全体の容量を削減してシステムリソースを有効活用できる。
【発明を実施するための最良の形態】
【００１２】
以下、図面に基づき本発明の実施形態について説明する。
【００１３】
＜第１実施形態＞
図１に、本実施形態におけるフォント管理装置１の構成ブロック図を示す。フォント管理装置は、デジタルカメラ等の携帯情報端末に搭載される。フォント管理装置１は、上位装置からの文字コードを入力するプロセッサ２、及びプロセッサ２によりアクセスされ、文字コードのビットマップデータ１１上のビットマップデータの開始アドレスを格納するポインタテーブル１０を含む。テーブル１０はデジタルカメラ等のＲＯＭに記憶される。プロセッサ２はテーブル１０にアクセスして入力した文字コードに対応する開始アドレスを取得し、この先頭アドレスからビットマップデータを読み出して表示装置３に表示する。表示装置３はデジタルカメラのＬＣＤ画面等である。テーブル１０はビットマップデータの開始アドレスを与えるものであり、ポインタテーブル１０として機能する。
【００１４】
図２に、図１におけるポインタテーブル１０の概念図を示す。ポインタテーブル１０は複数のレコードから構成され、ビットマップデータの有無にかかわらず、２バイトの文字コード（例えばユニコード）の先頭００００ｈから最終ＦＦＦＦｈまでに対応する全てのレコードにビットマップデータの開始アドレスが格納される。例えば文字コード００３１ｈの開始アドレスは０２Ｅ３００００ｈであり、文字コード００３３ｈは０２Ｅ３００４０ｈである。レコードに「０」が格納されている場合は、その文字コードに対応するビットマップデータが存在しないことを示す。なお、図では文字コードに対応させてビットマップデータの開始アドレスが示されているが、実際にはポインタテーブル１０の各レコードには文字コードは含まれず、ビットマップデータの開始アドレスのみが格納される。
【００１５】
図３に、ポインタテーブル１０の実際の構成を示す。ハッチングで示す文字コード領域は開始アドレスが格納されている領域である。各レコードは４バイト固定長（プラットフォームに依存するが本実施形態では４バイト）であるため、このポインタテーブル１０の先頭アドレスに、入力された文字コードに１レコード分のサイズを乗じた値を足すことで、ポインタテーブル１０の先頭アドレスから順次検索することなく目的のレコードを直接検索することができ、当該目的のレコードに格納されているビットマップデータの開始アドレスを取得できる。シーケンシャルに検索する必要がないので、複数言語であって文字コード範囲が広くても検索時間を格段に短くすることができる。
【００１６】
図４に、本実施形態の文字表示処理フローチャートを示す。まず、上位装置その他の外部装置から表示すべき文字コードを入力すると（Ｓ１０１）、プロセッサ２は文字コードとレコード長（４バイト）から目的とするポインタテーブル１０上のアドレスを算出する（Ｓ１０２）。そして、ポインタテーブル１０の該当アドレスのレコードに直接アクセスしてそのレコードに格納されているビットマップデータの開始アドレスを読み出す（Ｓ１０３）。開始アドレスを取得した後、プロセッサ２はこの開始アドレスからビットマップデータを読み出して（Ｓ１０４）、表示装置３に表示する（Ｓ１０５）。
【００１７】
このように、本実施形態では、入力された文字コードからポインタテーブルの該当レコードを直接検索してビットマップデータの先頭アドレスを取得できるので、複数言語の場合でも迅速に所望の文字を表示することができる。
【００１８】
＜第２実施形態＞
第１実施形態のポインタテーブル１０では、検索時間を短縮できるものの、００００ｈ〜ＦＦＦＦｈの全ての文字コードにレコードを割り当てるため、文字コードに対応する文字が定義されていない領域や、実際には使用されない文字の領域（例えば、日本市場に対応したデジタルカメラではアラビア文字等は使用されない文字である）も含まれてしまい（図３におけるハッチングが施されていない領域）、ポインタテーブル１０を格納するＲＯＭの容量が増大してしまう。そこで、本実施形態では、システムリソースを有効活用すべく、ポインタテーブル１０を初期ポインタテーブルとし、この初期ポインタテーブルから第１ポインタテーブル及び第２ポインタテーブルの２つのテーブルを作成して、初期ポインタテーブルの代わりにこれら２つのポインタテーブルを併用してビットマップデータの開始アドレスを検索する。
【００１９】
図５及び図６に、本実施形態のポインタテーブル１２（第１ポインタテーブル）及びポインタテーブル１４（第２ポインタテーブル）を示す。なお、図５では、比較のため第１実施形態のポインタテーブル１０も併せて示す。図３に示すポインタテーブル１０では、００００ｈ〜００２０ｈの文字コード領域、０２ＥＡｈ〜０５７３ｈの文字コード領域、及び９Ｅ１Ｆｈ〜９Ｅ２Ｅｈの文字コード領域は実際には使用しない無駄な領域となっている。そこで、ポインタテーブルを格納するＲＯＭの容量を削減するために、これらの無駄な領域の少なくとも一部を削減して新たなポインタテーブル１２を作成する。図５において、００００ｈ〜００２０ｈの文字コード領域及び０２ＥＡｈ〜０５７３ｈの文字コード領域を削除して（あるいはこれらの領域をスキップして）新たなポインタテーブル１２が得られる。無駄な領域を削除あるいはスキップした分だけポインタテーブルの容量が小さくなる。なお、９Ｅ１Ｆｈ〜９Ｅ２Ｅｈの領域は削除あるいはスキップしていない。その理由については後述する。
【００２０】
また、図６に示すポインタテーブル１４は、ポインタテーブル１２でアクセス可能な領域のアドレスの対応関係を示す。図６において、「ＯＲＩＧＩＮＡＬ」の欄は削除していない文字コード領域のポインタテーブル１０における開始位置（ＳＴＡＲＴ）と終了位置（ＥＮＤ）を示す。また、「ＭＯＤＩＦＩＥＤ」の欄は削除していない各領域の、ポインタテーブル１２における開始位置を示す。具体的には、削除していない最初の領域は元々の初期ポインタテーブル１０では００２１ｈ〜０２Ｅ９ｈの文字コード範囲であり、これはポインタテーブル１２では００００から始まる。同様に削除していない２番目の領域は元々の初期ポインタテーブル１０では０５７４ｈ〜ＦＦＦＦｈの文字コード範囲であり、これはポインタテーブル１２では０２ＣＡｈから始まる。ポインタテーブル１４の各レコードは６バイトであり、例えば最初のレコードには００２１０２Ｅ９００００ｈが格納され、最初の００２１ｈが「ＯＲＩＧＩＮＡＬ」の「ＳＴＡＲＴ」、次の０２Ｅ９ｈが「ＯＲＩＧＩＮＡＬ」の「ＥＮＤ」、最後の００００が「ＭＯＤＩＦＩＥＤ」の「ＳＴＡＲＴ」を表す。ポインタテーブル１４は、使用されない文字領域の少なくとも一部を削除し、その後に残存した領域の初期ポインタテーブル１０におけるアドレス位置とポインタテーブル１２におけるアドレス位置との関係を規定するテーブルである。
【００２１】
このようなテーブル構成において、表示すべき文字の文字コードが与えられると、プロセッサ２はまず図６に示すポインタテーブル１４を参照する。例えば、文字コードが０５８４ｈであるとする。この文字コードは図６のポインタテーブル１４の２番目のレコードの「ＯＲＩＧＩＮＡＬ」の「ＳＴＡＲＴ」欄にある文字コード０５７４ｈよりも大きく「ＥＮＤ」欄にある文字コードＦＦＦＦｈよりも小さいので、該文字コードはこの文字コード領域に属することがわかる。さらに、該当レコードの「ＳＴＡＲＴ」欄の０５７４ｈを差し引くことにより、該文字コードはこの領域の１７番目の位置に存在することがわかる。ところが、実際のポインタテーブル１２は、ポインタテーブル１０から使用しない領域の少なくとも一部を削除したテーブルであるので、次にこのポインタテーブル１２における実際の位置を求める。それには、「ＭＯＤＩＦＩＥＤ」欄の「ＳＴＡＲＴ」を参照すれば、対応する領域が実際にはポインタテーブル１２において０２ＣＡｈから始まることがわかるので、これに上記の１７番目というオフセットを加えると、最終的に目的の文字コードの開始アドレスはポインタテーブル１２において０２ＤＡｈで指定されるレコードに格納されていることが容易にわかる。以上のようにして、２つのポインタテーブル１２，１４を併用してビットマップデータの開始アドレスを取得できる。
【００２２】
なお、ポインタテーブル１０において、文字が定義されていない領域や使用しない領域として３つの領域を示しているが、これは説明の便宜上であり、実際にはこのような無駄な領域は数多く散在している。そのような領域を全て削除するものとすると、図６に示したポインタテーブル１４のデータ量が増大し、ポインタテーブル１２によるＲＯＭ容量削減の効果が減殺されてしまうとともに、検索時間も増大してしまうことになる。したがって、文字が定義されていない領域や使用しない領域の全てを削除するのではなく、あるしきい値を設定し、使用しない領域のサイズがこのしきい値未満の場合には削除することなくそのままポインタテーブル１２に残存させることが好適である。
【００２３】
以下、使用しない領域を削除する際の基準となるしきい値の設定方法について説明する。
【００２４】
図３に示されたポインタテーブル１０のうち、使用されていない文字コード領域を削除するということは、図６のポインタテーブル１４にレコードが１件（６バイト）追加されることを意味する。つまり、全体の容量を削減するためには、削除するデータ量は、６バイト以上でなければならないことになる。ポイントテーブル１０のレコードは４バイトであるから、削除できる最小レコード件数は２件（８バイト）ということになる。
【００２５】
一方、削除する件数と、フォントの検索速度とは反比例の関係にある。つまり、一つの領域を削除する毎にフォントの検索速度は低下してしまう。その理由は、上記のとおりプロセッサ２はまずポインタテーブル１４を検索し、次いでポインタテーブル１２を検索するが、ポインタテーブル１０から削除する件数が増大するほどポインタテーブル１４のレコード数が増大し、検索時間はポインタテーブル１４のレコード数に比例して増大してしまうからである。したがって、本実施形態において、検索速度の向上とシステムリソースの有効活用を両立させるためには、削除する件数はシステムリソースを最大限活用できる最小の数に設定することが必要となる。
【００２６】
図７に、使用していない領域を空白領域（図３におけるハッチングの施していない領域）とした場合の空白サイズとそのサイズがいくつ存在するかを示す空白領域数の一例、及びこの場合の空白サイズと空白領域数を乗じた数を１レコードのバイト数（４バイト）で乗じた合計サイズを示す。この例では、空白サイズが小さいものほど多く散在するものとし、空白サイズが１（レコード１件分）の領域は１，５００個、空白サイズが１，５０１（レコード１、５０１件分）の領域は３個、空白サイズが３，２６７（レコード３，２６７件分）の領域は１個存在するとしている。検索速度の低下を最小限に抑制するためには、サイズの大きな空白から優先的に削除しなければならない。
【００２７】
図８に、図７の空白パターンにおいて、削除する件数を種々変化させたときのポインタテーブル１２，１４の合計容量を示す。なお、使用できるリソースのサイズは２００ＫＢとする。
【００２８】
全くスキップしない（削除しない）と仮定すると、ポインタテーブル１２の１つのレコードは４バイトであるから、ポインタテーブル１２の容量は６５，５３６件×４バイト＝２６２，１４４バイトとなる。ポインタテーブル１４の容量はスキップしないため１件のレコードのみが存在することになるので１件×６バイト＝６バイトである。よって、ポインタテーブル１２とポインタテーブル１４の合計容量は２６２，１５０バイトとなり、システムリソースのサイズである２００ＫＢを超えてしまう。
【００２９】
３２６７件以上の空白をスキップすると仮定すると、合計サイズは図７に示すように１３，０６８バイトであるため、ポインタテーブル１２の容量は２６２，１４４バイト−１３，０６８バイト＝２４９，０７６バイトとなり、空白領域数は１であるのでポインタテーブル１４のレコード数は２件となってその容量は２件×６バイト＝１２バイトとなる。よって、合計容量は２４９，０８８バイトとなり、依然としてシステムリソースのサイズである２００ＫＢを超えてしまう。したがって、より小さいサイズの空白領域も削除する必要がある。
【００３０】
１５０１件以上の空白をスキップすると仮定すると、合計サイズは図７に示すように１８，０１２バイトであるため、ポインタテーブル１２の容量は２２４，７０８バイト（１８２３以上の空白をスキップすると仮定した場合のポインタテーブル１２の容量）−１８，０１２バイト＝２０６，６９６バイトであり、ポインタテーブル１４の容量を計算するまでもなく依然としてシステムリソースのサイズである２００ＫＢを超えてしまう。したがって、さらに小さいサイズの空白領域も削除する必要があることがわかる。
【００３１】
一方、１２８５件以上の空白をスキップすると仮定すると、合計サイズは１０，２８０バイトであるため、ポインタテーブル１２の容量は２０６，６９６バイト−１０，２８０バイト＝１９６，４１６バイトとなり、空白領域数は合計９であるのでポインタテーブル１４のレコード数は１０件となってその容量は１０件×６バイト＝６０バイトとなる。よって、ポインタテーブル１２とポインタテーブル１４の合計容量は１９６，４１６バイトとなり、システムリソースのサイズである２００ＫＢ以内に収まる。
【００３２】
以上より、図７に示すような空白領域の存在パターンでは、１２８５件の空白領域まで削除できることになる。２３１件の空白領域まで削除すると、合計容量をより削減することは可能であるが、上記のとおり検索時間が増大してしまうため最適しきい値は１，２８５に設定される。
【００３３】
図９に、ポインタテーブル１０からポインタテーブル１２，１４を作成する処理フローチャートを示す。まず、ポインタテーブル１０においてまだスキップされていない最も大きい空白をスキップし（Ｓ２０１）、ポインタテーブル１０からスキップした分のレコードを削除して（Ｓ２０２）ポインタテーブル１２を作成する。次に、ポインタテーブル１４にスキップ空白数分のレコードを追加する（Ｓ２０３）。以上のようにしてポインタテーブル１２及びポインタテーブル１４を仮作成した後、ポインタテーブル１２とポインタテーブル１４の合計容量がリソースサイズより小さいか否かを判定する（Ｓ２０４）。リソースサイズを超えている場合には（Ｓ２０４でＮＯ）、再びＳ２０１のステップに戻ってまだスキップされていない最も大きい空白をスキップする。以上の処理をポインタテーブル１２とポインタテーブル１４の合計容量がリソースの容量より小さくなるまで繰り返し実行し、合計容量がリソースの容量よりも小さくなった時点（Ｓ２０４でＹＥＳ）のポインタテーブル１２、１４を最終的なポインタテーブルと確定する。
【図面の簡単な説明】
【００３４】
【図１】実施形態の構成ブロック図である。
【図２】実施形態のポインタテーブルの概念図である。
【図３】実施形態のポインタテーブルの構成説明図である。
【図４】実施形態のフォント表示処理フローチャートである。
【図５】他の実施形態のポインタテーブル（第１ポインタテーブル）の構成説明図である。
【図６】他の実施形態のポインタテーブル（第２ポインタテーブル）の構成説明図である。
【図７】ポインタテーブルにおける不使用領域の存在パターンを示す説明図である。
【図８】スキップする空白領域を変化させた場合のポインタテーブルの合計容量を示す説明図である。
【図９】他の実施形態の第１ポインタテーブルと第２ポインタテーブルの作成処理フローチャートである。
【図１０】従来のポインタテーブルの構成説明図である。
【符号の説明】
【００３５】
１  フォント管理装置、２  プロセッサ、３  表示装置、１０  ポインタテーブル、１２  ポインタテーブル（第１ポインタテーブル）、１４  ポインタテーブル（第２ポインタテーブル）。
【図１】
2007101605.tif 000003
【図２】
2007101605.tif 000004
【図３】
2007101605.tif 000005
【図４】
2007101605.tif 000006
【図５】
2007101605.tif 000007
【図６】
2007101605.tif 000008
【図７】
2007101605.tif 000009
【図８】
2007101605.tif 000010
【図９】
2007101605.tif 000011
【図１０】
2007101605.tif 000012