(57)【要約】【課題】  効率的に領域を使用でき、速く処理することができるフォントデータ構造を提供すること。【解決手段】  文字イメージに対応する文字コードから、データビット幅とコード範囲を取得するコード取得テーブル２と、各コード範囲の先頭の文字コード、各コード範囲の最後の文字コード、前記先頭の文字コードに対応する開始インデックスコードからなるコード範囲テーブル３と、インデックスコードから、フォントパターンデータを得るフォントパターンテーブル５と、開始インデックスコードをフォントパターンテーブル５のインデックスコードに変換するコード変換テーブル４とを備えた。【選択図】        図１
2007052247.tif 000002
【特許請求の範囲】
【請求項１】
文字イメージに対応する文字コードから、データビット幅とコード範囲を取得するコード取得テーブルと、
各コード範囲の先頭の文字コード、各コード範囲の最後の文字コード、前記先頭の文字コードに対応する開始インデックスコードからなるコード範囲テーブルと、
インデックスコードから、フォントパターンデータを得るフォントパターンテーブルと、
前記開始インデックスコードを前記フォントパターンテーブルのインデックスコードに変換するコード変換テーブルと、
を備えたことを特徴とするフォントデータ構造。
【請求項２】
請求項１に記載のフォントデータ構造において、
前記コード取得テーブルと、前記コード範囲テーブルと、前記フォントパターンテーブルと、前記コード変換テーブルとが、一体のデータとなっている、
ことを特徴とするフォントデータ構造。
【請求項３】
前記データビット幅は、８ビットデータと１６ビットデータであり、日本語データを含む、
ことを特徴とするフォントデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文字イメージからフォントデータを効率的に取得して、表示や印刷等の出力を行うフォントデータ構造の技術分野に属する。
【背景技術】
【０００２】
従来では、フォントパターン格納エリアと別に文字コード変換テーブルを設け、文字イメージから文字コードを取得し、文字コードからフォントパターンのデータを取得するようにしている（例えば、特許文献１参照。）。
【特許文献１】特開平０９−３２５７５２号公報（第２−５頁、全図）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、従来のフォントデータ構造にあっては、特に日本語の文字コードの場合、１６ビットの文字コード変換テーブルを使用することになり、領域の大半が無駄になり、且つ検索に時間がかかってしまうという問題があった。
【０００４】
本発明は、上記問題点に着目してなされたもので、その目的とするところは、効率的に領域を使用でき、速く処理することができるフォントデータ構造を提供することにある。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、本発明では、文字イメージに対応する文字コードから、データビット幅とコード範囲を取得するコード取得テーブルと、各コード範囲の先頭の文字コード、各コード範囲の最後の文字コード、前記先頭の文字コードに対応する開始インデックスコードからなるコード範囲テーブルと、インデックスコードから、フォントパターンデータを得るフォントパターンテーブルと、前記開始インデックスコードを前記フォントパターンテーブルのインデックスコードに変換するコード変換テーブルと、を備えたことを特徴とする。
【発明の効果】
【０００６】
よって、本発明にあっては、効率的に領域を使用でき、速く処理することができる。
【発明を実施するための最良の形態】
【０００７】
以下、本発明のフォントデータ構造を実現する実施の形態を、請求項１，２，３に係る発明に対応する実施例１に基づいて説明する。
【実施例１】
【０００８】
まず、構成を説明する。
【０００９】
図１は実施例１のフォントデータ構造におけるイメージコードテーブルである。図２は実施例１のフォントデータ構造におけるコード取得テーブルである。図３は実施例１のフォントデータ構造におけるコード範囲テーブルである。図４は実施例１のフォントデータ構造におけるコード変換テーブルである。図５は実施例１のフォントデータ構造におけるフォントパターンテーブルである。
【００１０】
実施例１のフォントデータ構造１は、コード取得テーブル２、コード範囲テーブル３、コード変換テーブル４、フォントパターンテーブル５の各テーブルデータからなる。イメージコードテーブル６は、実施例１のフォントデータ構造１にないが、説明上、符号、図を示して説明する。
【００１１】
まず、イメージコードテーブル６は、実際には、フォントデータ構造１に含まないが、文字コードとイメージの関係を説明するために、図１に示す。
このように文字や記号は、おおむね図１に示すように８ビットのデータとなる。さらに、図示しないが漢字と一部の記号については、１６ビットのデータとなり、図１に示す関係のように１６ビットの文字コードで取り扱われることになる。
【００１２】
コード取得テーブル２は、文字コードが８ビットか１６ビットかを示すデータビット幅と、コード範囲、つまり、データビット幅：コード範囲からなる。
これを各文字コードに対応するように、図１同様の縦位置と横位置で参照されるテーブルデータにしている。
【００１３】
コード範囲テーブル３は、各コード範囲と、コード範囲の先頭の文字コード、コード範囲の最後の文字コード、先頭の文字コードに対応する開始インデックスコードからなる。各コード範囲ごとに１組のデータとしてテーブルデータが構成される。
【００１４】
コード変換テーブル４は、開始インデックスデータを縦位置、横位置とし、インデックスデータを参照するテーブルデータである。
【００１５】
フォントパターンテーブル５は、インデックスデータから８ビットまたは１６ビットで、フォントパターンを備えたものである。つまり、８ビットならば、０と１の組み合わせが縦横に８×８となり、その１がイメージ部分、０が背景となるようにして、文字や記号を表現したデータ群である。
【００１６】
例えば、図６に示すように、CPU１１、インターフェース１２、RAM１３、ROM１４、表示器１５という表示装置の構成を示して説明する。実際には文字は外部入力されるデータとして、RAM１３に文字コードとして、一時的に記憶される。これに対し、ROM１４には、コード取得テーブル２、コード範囲テーブル３、コード変換テーブル４、フォントパターンテーブル５を有し、CPU１１の処理により、フォントパターンデータが表示器１５に出力され、文字が表示される。
【００１７】
次に、作用を説明する。
[フォントデータについて]
ここで、フォントデータについて説明する。
図７には従来のコード変換テーブルを示す。フォントパターンテーブルは、図５を参照。
まず、文字や記号が表示や印刷等のためにデータとして扱われる場合には、文字コードデータとして取り扱われる。
文字コードデータに対応するインデックスコードは、コード変換テーブルにより変換されて、フォントパターンテーブルが参照され、所定の縦×横のデータ範囲に配置される０と１で構成されるフォントデータとして用いられる。
これによって、ゴシック体や明朝体、言語の違い等に対応した、表示や印字を行うことができるのである。
【００１８】
しかしながら、この２つのデータは、別々に管理されるため保守が煩わしいものであった。そのため、利用したい書体の文字表示のために双方のデータ存在確認が必要である。この存在確認はプラグラム側の負担となる。両者に同じ文字コード体系を示す情報が揃っていないと、その文字コード体系は利用できなかった。無理に利用すると、文字化けといわれる現象を生じることになる。
また、日本語の文字コード体系では、１６ビット幅のコード変換テーブルを利用するが、参照される領域は、全体の１０数％しかないため、記憶域の大半が無駄になってしまう（図８参照）。このように有効なコードが散在するコード変換テーブルは、その記憶領域節約のため、連続する有効なコードを範囲で処理するテーブルデータを考えることができるが、検索処理に時間がかかってしまうものであった。
また、文字列を取り扱う場合には、文字コード列を取り扱うため、その文字コード列が８ビットデータか１６ビットデータかは、それぞれ処理してみないとわからないことがあり、処理を遅くしていた。
本実施例１のフォントデータ構造は、これらの課題を解決するものである。
【００１９】
[効率的な領域の使用と処理速度の向上作用]
【００２０】
図６に示す表示装置において、文字「Ａ」を表示する場合について説明する。
文字列、つまり、イメージとしての文字「Ａ」は、データ処理上、文字コードとして取り扱われることになる。図１のイメージコードテーブル６の場合、文字「Ａ」は、縦位置と横位置から、文字コード「４１Ｈ」となる。
そのため、例えば、外部からの情報で文字「Ａ」を表示することになった場合、RAM１３に文字コード「４１Ｈ」がデータとして有ることになる。
【００２１】
実施例１では、ROM１４に一体化したフォントデータ構造１を設けるものとする。そのため、CPU１１で実行されるアプリケーションとしてのプログラムは、書体、言語に関して、従来のようにコード変換テーブルとフォントパターンデータの２つの存在と整合性の確認処理を行うことなく、いきなり一体化したフォントデータ構造１に対して、フォントパターンデータへの検索処理の開始を行う。
このように一体化したフォントデータ構造１にすることにより、取得の処理、データの保守が容易になる。
【００２２】
本実施例１においては、図２に示すように、コード取得テーブル２への参照処理を行う。文字「Ａ」＝文字コード「４１Ｈ」の場合には、図２の４ｘＨ，ｘ１Ｈの縦位置、横位置から、８：ｒ０００、つまり、８ビットデータで、コード範囲がｒ０００を得る。この最初の段階で、１６ビットデータではなく８ビットデータであることがわかっているので、１６ビットデータとしての取り扱いを行うことはない。
次にCPU１１は、実行するプログラムにおいて、図３に示すコード範囲テーブル３への参照を行う。これによりｒ０００の範囲の最初の文字コード「２０Ｈ」、範囲の最後の文字コード「７ＥＨ」、最初の文字コードに対応する開始インデックスコード「Ｉ０００」を得る。
【００２３】
ここで、検索する文字コードから範囲の最初の文字コードを減算し、その差分を開始インデックスコードに加算する演算を行う。
この場合には、４１Ｈ−２０Ｈ＋Ｉ００００＝２１Ｈ（Ｉ００３３）となる。
このコード範囲テーブル３への参照により、開始インデックスコードＩ００３３を得る。
次に、図４に示すコード変換テーブル４への参照を行う。
開始インデックスコードＩ００３３は、縦位置が「Ｉ００３ｘ」、横位置が「Ｉｘｘｘ３」であるので、コード変換テーブル４から、インデックスコード「ｆ００３３」を得る。
【００２４】
次に、図５に示すフォントパターンテーブル５への参照を行う。
ｆ００３３のインデックスコードに対応する、１と０でフォントパターンを表現したデータ群を得る。このデータ群をROM１４から読み出し、表示器１５へ出力することにより、書体、言語に応じた、文字「Ａ」が表示される。
【００２５】
次に１６ビットデータの場合について説明する。１６ビットデータの場合にも、８ビットデータの場合と同様に、８ビット分の文字コード例えば「８ＡＨ」から、コード取得テーブル２への参照処理を行う。すると、「１６：ｒ０３１」を得る。この時点で、１６ビットデータあることがわかり、RAM１３の文字コードから、「８ＡＢＦＨ」であることがわかるのである。次にコード範囲テーブル３ではｒ０３１の範囲から検索を始めるが、ｒ０３１の範囲外のため、次のｒ０３２を検索する。すると、ｒ０３２の範囲内であるので、ｒ０３２の最初の文字コード「８Ａ８０Ｈ」と、これに対応する開始インデックスコード「Ｉ１０４９」から、８ＡＢＦＨ−８Ａ８０Ｈ＋Ｉ１０４９＝０４５８Ｈ（Ｉ１１１２）を得て、コード変換テーブル４からインデックスコード「ｆ３６１７」を得る。そして、フォントパターンテーブル５からフォントパターンの１と０からなるデータ群を得るようにする。
【００２６】
このように、従来においてはテーブルデータの先頭から検索していくのに対して、本実施例１のように、絞った範囲をいきなり検索することは、非常に速い処理となる。
また、コード範囲テーブル３、コード変換テーブル４により、無駄な領域が絞られるように減少することになる。そのため無駄に領域を大きく確保することなく効率的な使用となる。
【００２７】
次に、効果を説明する。
実施例１のフォントデータ構造にあっては、下記に列挙する効果を得ることができる。
(1)文字イメージに対応する文字コードから、データビット幅とコード範囲を取得するコード取得テーブル２と、各コード範囲の先頭の文字コード、各コード範囲の最後の文字コード、前記先頭の文字コードに対応する開始インデックスコードからなるコード範囲テーブル３と、インデックスコードから、フォントパターンデータを得るフォントパターンテーブル５と、開始インデックスコードをフォントパターンテーブル５のインデックスコードに変換するコード変換テーブル４とを備えたため、効率的に領域を使用でき、速く処理することができる。
【００２８】
(2)コード取得テーブル２と、コード範囲テーブル３と、フォントパターンテーブル５と、コード変換テーブル４とが、一体のデータとなっているため、データの取り扱いや保守が容易で、さらに処理を速くすることができる。
【００２９】
(3)データビット幅は、８ビットデータと１６ビットデータであり、日本語データを含むため、８ビットと１６ビットのデータが混在する場合であっても、処理を速くすることができる。
実施例１のフォントデータ構造の効果について、付け加えて説明する。
図８に示すように、１６ビットデータの場合は特に無駄な領域を多く持つことになる。しかしながら、この未使用領域は、他の言語、書体の場合に使うことができる。コード変換テーブルとテーブルフォントテーブルがプログラムに対し別管理の場合、この領域を残し、どの言語、書体の場合でも含む大きな領域を展開し、さらにその領域を複数持つことが、複数言語、書体を同時に扱えることになる。メモリ資源やCPU能力に制限がないような場合には、従来のフォントデータ構造で充分である。
【００３０】
しかし、実際に例えば車両や家電、携帯機器などでは、メモリ資源やCPU能力に制限がある場合がほとんどであり、さらに、その場合でも充分な処理速度が求められる。本実施例１のフォントデータ構造では、メモリ資源やCPU能力に制限がある場合に、特に有利である。さらに、このような状況で多言語を処理するような場合には、さらに有利になる。一体のデータで処理が容易となり、且つ速く処理できるのである。
【００３１】
以上、本発明のフォントデータ構造を実施例１に基づき説明してきたが、具体的な構成については、これらの実施例に限られるものではなく、特許請求の範囲の各請求項に係る発明の要旨を逸脱しない限り、設計の変更や追加等は許容される。
例えば、実施例１では、表示装置について説明したが、印刷装置であってもよい。
【産業上の利用可能性】
【００３２】
文字を取り扱う装置、プログラムへの利用は容易である。
【図面の簡単な説明】
【００３３】
【図１】実施例１のフォントデータ構造におけるイメージコードテーブルである。
【図２】実施例１のフォントデータ構造におけるコード取得テーブルである。
【図３】実施例１のフォントデータ構造におけるコード範囲テーブルである。
【図４】実施例１のフォントデータ構造におけるコード変換テーブルである。
【図５】実施例１のフォントデータ構造におけるフォントパターンテーブルである。
【図６】実施例１のフォントデータ構造を用いた表示装置の構成を示すブロック図である。
【図７】従来のコード変換テーブルを示す。
【図８】従来の１６ビットデータにおけるコード変換テーブルを示す。
【符号の説明】
【００３４】
１  フォントデータ構造
２  コード取得テーブル
３  コード範囲テーブル
４  コード変換テーブル
５  フォントパターンテーブル
６  イメージコードテーブル
１１  CPU
１２  インターフェース
１３  RAM
１４  ROM
１５  表示器
【図１】
2007052247.tif 000003
【図２】
2007052247.tif 000004
【図３】
2007052247.tif 000005
【図４】
2007052247.tif 000006
【図５】
2007052247.tif 000007
【図６】
2007052247.tif 000008
【図７】
2007052247.tif 000009
【図８】
2007052247.tif 000010