(57)【特許請求の範囲】
【請求項１】
要求された文字に関するデータを書体データファイルから取り出すための書体データ管理方法において、
第１書体における、各々が連続するコードからなる部分コード空間のうち、何れの部分コード空間に対応する書体データファイルを、第２書体と共通に使用するようにする書体管理情報を保持し、
第１書体におけるコードを含む文字要求があった場合に、前記書体管理情報に基づき前記何れの部分コード空間の範囲に対応していれば、前記共通に使用する書体データファイルから書体データを獲得する
ことを特徴とする書体データ管理方法。
【請求項２】
前記何れかの部分コード空間に対応する書体データファイルはドットパターンのデータからなり、前記何れの部分コード空間以外の部分コード空間に対応する書体データファイルはアウトラインフォントのデータからなることを特徴とする請求項１に記載の書体データ管理方法。
【請求項３】
前記共通に使用する書体データファイルを前記第１書体に従属させるようにする登録制御手段を有することを特徴とする請求項１又は２に記載の書体データ管理方法。
【請求項４】
前記部分コード空間に対応した書体データファイルは、ファイル名称によって管理されることを特徴とする請求項１乃至３の何れか１項に記載の書体データ管理方法。
【請求項５】
前記何れの部分コードは、何れかのキャラクタセットに対応することを特徴とする請求項１乃至４の何れか１項に記載の書体データ管理方法。
【請求項６】
前記書体は漢字を含む書体であることを特徴とする請求項１乃至５の何れか１項に記載の書体データ管理方法。
【請求項７】
要求された文字に関するデータを書体データファイルから取り出すための書体データ管理方法において、
第１書体の書体データファイルにおける連続するコードからなる何れの部分コード空間に対して、第２書体の前記何れの部分コード空間の書体データを使用させる書体管理情報を保持し、
前記第１書体におけるコードを含む文字要求があった場合に、文字要求があったコードと前記書体管理情報とに基づき前記何れの部分コード空間の範囲に含まれるコードと識別されれば、前記第２書体の書体データファイルから前記何れの連続する部分コード空間の書体データを獲得する
ことを特徴とする書体データ管理方法。
【請求項８】
要求された文字に関するデータを書体データファイルから取り出すための書体データ管理装置において、
第１書体における、各々が連続するコードからなる部分コード空間のうち、何れの部分コード空間に対応する書体データファイルを、第２書体と共通に使用するようにする書体管理情報を保持する保持手段と、
第１書体におけるコードを含む文字要求があった場合に、前記書体管理情報に基づき前記何れの部分コード空間の範囲に対応していれば、前記共通に使用する書体データファイルから書体データを獲得する獲得手段と
を備えることを特徴とする書体データ管理装置。
【請求項９】
前記何れかの部分コード空間に対応する書体データファイルはドットパターンのデータからなり、前記何れの部分コード空間以外の部分コード空間に対応する書体データファイルはアウトラインフォントのデータからなることを特徴とする請求項８に記載の書体データ管理装置。
【請求項１０】
前記共通に使用する書体データファイルを前記第１書体に従属させるようにする登録制御手段を有することを特徴とする請求項８又は９に記載の書体データ管理装置。
【請求項１１】
前記部分コード空間に対応した書体データファイルは、ファイル名称によって管理されることを特徴とする請求項８乃至１０の何れか１項に記載の書体データ管理装置。
【請求項１２】
前記何れの部分コードは、何れかのキャラクタセットに対応することを特徴とする請求項８乃至１１の何れか１項に記載の書体データ管理装置。
【請求項１３】
前記書体は漢字を含む書体であることを特徴とする請求項８乃至１２の何れか１項に記載の書体データ管理装置。
【請求項１４】
要求された文字に関するデータを書体データファイルから取り出すための書体データ管理装置において、
第１書体の書体データファイルにおける連続するコードからなる何れの部分コード空間に対して、第２書体の前記何れの部分コード空間の書体データを使用させる書体管理情報を保持する保持手段と、
前記第１書体におけるコードを含む文字要求があった場合に、文字要求があったコードと前記書体管理情報とに基づき前記何れの部分コード空間の範囲に含まれるコードと識別されれば、前記第２書体の書体データファイルから前記何れの部分コード空間の書体データを獲得する手段と
を備えることを特徴とする書体データ管理装置。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は書体データ管理方法及び装置、例えばパーソナルコンピュータ、ワードプロセッサやデスクトップパブリッシング装置等で使用される各種書体のデータファイルを管理する書体データ管理方法及び装置に関するものである。
【０００２】
【従来の技術】
従来、文字処理システムにおいて管理される書体データは、管理の容易さなどの理由から、一つのファイル中に書体単位で全文字のデータを格納していた。
【０００３】
【発明が解決しようとする課題】
前述の従来方法による書体データ管理方法では、以下に示す問題が有る。
【０００４】
あらかじめ書体データの全てがファイル中に格納されており、例えば、インストールの対象はあくまでも書体単位での選択しかなかった。このため一般的に使用されることがあまりない書体データまでも同時にインストールされてしまい、ディスクメモリを圧迫する結果となっていた。
【０００５】
【課題を解決するための手段】
本発明はかかる従来技術に鑑み成されたものであり、柔軟性のある書体データの管理方法及び装置を提供しようとするものである。
【０００６】
このため、例えば本発明の１つの書体データ管理方法は以下に示す行程を備える。
【０００７】
要求された文字に関するデータを書体データファイルから取り出すための書体データ管理方法において、
第１書体における、各々が連続するコードからなる部分コード空間のうち、何れの部分コード空間に対応する書体データファイルを、第２書体と共通に使用するようにする書体管理情報を保持し、
第１書体におけるコードを含む文字要求があった場合に、前記書体管理情報に基づき前記何れの部分コード空間の範囲に対応していれば、前記共通に使用する書体データファイルから書体データを獲得することを特徴とする。
【０００８】
【発明の実施の形態】
以下、図面を参照し、本願発明について詳細に説明する。
【０００９】
まず、パーソナルコンピュータ等の文字データを扱うシステムが、文字の表示或は印字を行う際に、書体データを獲得するまでの動きを簡単に説明する。
【００１０】
図１はこれら上記のシステムが動作するための基本的な構成を示すブロック図である。
【００１１】
図１において、１０１はＣＰＵ、即ち中央処理装置であり、上記システム全体の起動及び演算処理等を行うものである。１０２は読み出し専用メモリ（ＲＯＭ）であり、システム起動プログラム（ブートプログラム）及び文字パターン・データ等の記憶領域である。１０３はランダムアクセスメモリ（ＲＡＭ）であって、システムプログラム、各種アプリケーションプログラムや、文字パターン発生のためのドライバプログラム等がロードされると共に、各種データの一時的に記憶に用いられる。後述するフローチャートに係るプログラムも勿論、このＲＡＭ１０３にロードされて実行される。１０４はキーボード制御部（ＫＢＣ）であり、１０５のキーボード（ＫＢ）よりキー入力データを受け取り、ＣＰＵ１０１へ伝達する。１０６はディスプレイ装置（ＣＲＴ）１０７の制御を行うＣＲＴ制御部（ＣＲＴＣ）である。１０９はフロッピーディスク装置（ＦＤ）やハードディスク装置（ＨＤ）等の外部記憶装置であって、これらにシステムプログラムやアプリケーションプログラムをはじめとする各種プログラムやフォントデータが格納されている。プログラムの実行時には、これら外部記憶装置１０９に記憶されたプログラムがＲＡＭ１０３にロードされてＣＰＵ１０１により実行されることになる。１１０はプリンタ制御部（ＰＲＴＣ）であり、１１１はＰＲＴＣ１１０の制御の下で、送出されてきたデータに基づく可視画像を記録紙上に形成するプリンタ（ＰＲＴ）である。１１２はシステムバスであり、上述の構成要素間のデータの通路となるべきものである。
【００１２】
図２はＲＡＭ１０３のメモリマップを示した図である。２０１はシステムがロードされるシステム領域であり、２０２は文字展開処理部がロードされる領域であり、２０３は文字展開処理部がビットパターンデータを格納する領域である。２０４は文字展開処理時において、１０９の外部記憶装置上に格納されているベクトルパターンデータを参照するために読み込む領域である。２０５は前記システムが動作するための管理情報テーブルを生成するための領域である。２０６は書体ベクトルデータのキャッシュ領域である。
【００１３】
図３は前記文字データを扱うシステムの構成を表す図である。
【００１４】
図３において、３０１，３０２，３０３は、図１における外部記憶領域１０９に記憶されている様々な書体データを表している。外部記憶装置１０９に記憶される書体データの種類及びその数は実質的に制限はない。
【００１５】
３０４はシステム制御部を示し、図２における２０１，２０４，２０５が含まれる。３０５，３０６は文字展開処理部、即ちラスタライザを示し、その文字展開処理機能をソフトウェアのみで実現されていても良く、ハードウェアによって実現されていても良く、ハードウェアとソフトウェアの双方を用いても構わない。また前記システム中に含まれるラスタライザの数は、少なくとも１つ含まれていればその他の制限はない。３０７はシステムに対して文字取得要求を発行するアプリケーション部（例えばワードプロセッサ等のプログラム）を表す。
【００１６】
図３において、アプリケーション部３０７は文字取得要求を発する。文字取得要求は、取得する文字を確定するために、文字と１対１に対応した文字コードと書体情報を用いて行う。要求された文字データを取得するためにシステム制御部３０４は書体データ３０１，３０２，３０３から必要なデータを獲得する。獲得したデータがアウトラインフォントを構成する輪郭ベクトルデータであれば、ラスタライザ３０５，３０６にデータを転送する。また、獲得したデータがビットパターンデータであればそのままアプリケーション部３０７へそれを転送する。ラスタライザ３０５，３０６では、受け取った輪郭ベクトルデータをビットパターンへ展開し、それをシステム制御部３０４へ送り返す。システム制御部は３０４がラスタライザ３０５，３０６より受け取ったビットパターンデータをアプリケーション部３０７へ送り返す。
【００１７】
次に、以上の説明を踏まえ、実施形態について詳細に説明する。
【００１８】
本実施形態は書体データファイル分割し、必要な部分のみをインストールすることで書体データの獲得を可能とすることを目的としており、その分割方法について、図４を用いて簡単に説明する。
【００１９】
図４は分割ファイルの構成を簡単に表したものである。尚、説明を簡単にするため、書体Ａは文字コード０〜６００で１つの書体を構成するものとする。
【００２０】
この書体Ａを０〜１００のＡ１、１０１〜１９９のＡ２、２００〜５００のＡ３、５０１〜６００の４つの部分に分割したものとする。この書体Ａにおいて、Ａ３部分は、一般的に使用されることのないデータであり、かつ最もディスクメモリを必要とする部分である。
【００２１】
これらの分割された書体情報を書体インストール時に示し、インストールすべき部分をユーザの手（キーボード）によって選択させる。選択された結果、必要とされる部分のみのインストールを行い、図５Ａに示されるインストールされた結果の書体の内訳を記述した書体情報ファイル５００を外部記憶装置１０９上に作成する。尚、図５Ｂにインストールされた書体ファイルの結果状況を示す。
【００２２】
システム立ち上げ時に、書体情報ファイル５００より情報を読み取り、その書体情報ファイル内からインストールされた書体の内訳を示す情報を取り出し、図６に示すような書体管理情報テーブルを書体情報管理領域２０５上に作成する。
【００２３】
書体管理情報テーブル作成の流れを図７を用いて説明する。尚、同図は本システムに電源が投入された場合の初期処理中における書体に関する処理であり、そお処理手順は外部記憶装置１０９に格納されている。
【００２４】
先ず、ステップＳ７０２で書体情報ファイルをオープンし、次のステップＳ７０３で、そのオープンした書体情報ファイルより書体名の情報の獲得を行い、書体名の情報を書体管理情報テーブルへ書き込む。
【００２５】
ステップＳ７０４においては、書体情報ファイルよりファイル名の獲得を行い、ファイル名の情報を書体管理情報テーブルへ書き込む。そして、ステップＳ７０５においては、先に獲得した書体のファイル名を元に、アクセス可能状態とするためのそのファイルオープン処理を行う。ステップＳ７０６においては、ステップＳ７０５においてアクセス可能となった書体ファイルより、そのファイルに格納されている書体データの開始コード、終了コードに関する情報を読み取り、書体管理情報テーブルへ書き込む。
【００２６】
処理がステップＳ７０７においては、書体情報ファイル内の記述に同一書体のファイルがまだ存在するかを調べ、存在する場合にはステップＳ７０４に戻り、次のファイル名の獲得とテーブルの更新処理を行う。
【００２７】
また、ステップＳ７０７で同一書体のファイルが存在しないと判断した場合には、ステップＳ７０８へ進み、書体管理ファイル内に未処理の書体が存在するかを調べ、存在する場合はＳ７０３に戻って次の書体に対する処理を行う。また、全ての書体に対するテーブルの作成が完了したと判断したら、ステップＳ７０９に進んで、先のステップＳ７０２においてオープン処理を行った書体情報ファイルをクローズし、本処理を終える。
【００２８】
以上の処理によって、書体情報管理領域２０５には例えば図６に示すような書体管理情報テーブルが作成されることになる。
【００２９】
次に、図６の書体管理情報テーブルを用いて、必要とする書体データを獲得するまでの流れを、図８のフローチャートに従って説明する。
【００３０】
ステップＳ８０１において、文字データ取得処理を開始する。
【００３１】
ステップＳ８０２においては、図３におけるＡＰ部３０７より取得する文字に関する情報（文字コード，書体情報）を取得する。次のステップＳ８０３においては、図６の書体管理情報テーブルの先頭の書体検索し（初期段階ではポインタはテーブル中の先頭書体を指し示している）、対応する書体であるかチェックを行う。存在する場合はステップＳ８０４へ、存在しない場合はステップＳ８０５へ進む。
【００３２】
対応する書体でないと判断し、処理がステップＳ８０５に進むと、他の書体が存在するかどうかを判断し、他の書体があればそこにポインタを進める。
【００３３】
また、対応する書体が捜し出せ、処理がステップＳ８０４に進むと、書体管理情報テーブル上に要求された文字コードがその管理されている範囲内にあるかどうか、換言すればその文字コードが管理されているかどうかを判断する。この時点でのポインタは図６の先頭位置に置かれているので、要求された文字コードが“０”から“１００”の範囲内であるかどうかを判断することになる。
【００３４】
さて、存在しないと判断された場合には、ステップＳ８０６に進み、テーブル内の注目行の次の行に同じ書体のファイルが管理されているかどうかを判断する。もしあれば、ポインタを１つ進め、ステップＳ８０４に戻る。また、次のファイルが存在しないと判断した場合には、文字無し処理を行う。
【００３５】
一方、要求された書体の文字コードが管理されていると判断した場合には、ステップＳ８０７に進み、書体管理情報テーブル内の注目行からファイル名を獲得し、ステップＳ８０８において、その獲得したファイル名を元に、そのファイルから書体データを獲得し、終了処理Ｓ８１０へ進む。
【００３６】
以上説明したように本実施形態によれば、必要な書体の必要な文字コード範囲のみをシステムにインストールできるので、外部記憶装置１０９のメモリ消費量を抑えることができると共に、不要な部分の管理は行わないので処理速度を上げることも可能になる。
【００３７】
＜第２の実施形態の説明＞
上記実施形態（第１の実施形態）では、例えば書体管理情報テーブルが図６に示すようになっている場合、アプリケーション部から書体Ａの文字コード“５０１”の文字取得要求があったときには、図８におけるステップＳ８０４、ステップＳ８０６を３回ループすることになる。文字コード“５０１”から“６００”までに対する文字取得要求の頻度が全体の要求に対してさほど高くない場合には問題がないが、その頻度が他の文字コードに対して多い場合には処理速度の低下は避けられない。
【００３８】
そこで本第２の実施形態では、文字取得要求の発生頻度を計数し、次回の起動時の書体管理情報テーブル作成に反映させるものである。
【００３９】
尚、本第２の実施形態におけるシステム構成も図１に示すものとする。これは後述する第３の実施形態以降についても同様である。また、本第２の実施形態では、書体データを外部記憶装置１０９にインストールする場合に、図４に示した全ての範囲の書体データＡ１〜Ａ４を指定した場合を説明する。また、図８のフローチャートに係るプログラムは当然のことながら外部記憶装置１０９に記憶されているものである。この点も後述する各実施形態についても同様である。
【００４０】
図９は第２の実施形態において作成された書体管理テーブルの初期状態を示している。第１の実施形態の図６との違いは、同一書体における個々のコード範囲のアクセス回数を記憶保持する欄が設けられた点である。書体管理情報テーブル自身を作成する手順は第１の実施形態と同様であるので、ここでの説明は省略し、文字データ取得処理を図１０に従って説明する。
【００４１】
図１０のフローチャートと第１の実施形態における図８との相違点は、ステップＳ８０７がステップＳ８０７’となり、ステップＳ８１１が追加された点である。
【００４２】
図示において、書体管理テーブルはアプリケーション部から文字データ取得要求があって、要求された文字データが管理テーブルで管理されている場合、処理はステップＳ８０４からステップＳ８０７’に進むのは同じである。ステップＳ８０７に処理が進むと、書体管理情報テーブルからファイル名を獲得すると共に、書体管理情報テーブルの該当するアクセス欄の数値を“１”インクメントする。そして、ステップＳ８０８において、その獲得したファイル名を元に、そのファイルから書体データを獲得し、終了処理Ｓ８１１へ進む。
【００４３】
この結果、例えば書体管理情報テーブルは図１１に示すようになる。
【００４４】
ステップＳ８１１では、書体管理ファイル内に記憶されている順序を、その時点での管理テーブル内のアクセス回数で並べ変える処理を行い、本処理を終える。
【００４５】
例えば、書体管理情報テーブルが図１１に示す状態にあった場合、書体Ａに関してはファイルのアクセス回数がＡ４＞Ａ３＞Ａ２＞Ａ１であるので、書体情報ファイルの中身は図１２に示すようにその順序が変更される。
【００４６】
装置起動時には、書体情報ファイルに記憶された順序に従ってテーブルを作成するから、次回の起動時の書体管理情報テーブルは図１３に示すようになる。すなわち、書体ＡにおけるファイルＡ４が一番最初に位置することになり、文字データ所取得要求に対するアクセス速度の向上が望める。
【００４７】
尚、第２の実施形態では、文字データ取得要求が発生する度に、書体情報ファイルを更新したが、システムの電源断処理時に行うことで、処理速度をより高速化することが可能になる。
【００４８】
また、システム電源断処理において、各書体を構成している部分ファイル（Ａ１〜Ａ４）のアクセス回数も適当なファイルとして保存し、次回のシステム起動時にそのファイルからアクセス回数を取得し、それでもってテーブル内の順序を決定するようにしても良い。
【００４９】
以上説明した様に本第２の実施形態によれば、アクセス回数の多い文字コード範囲ほど優先して書体情報管理テーブルの先頭に配置するので、文字パターン発生にかかる全体のコストパフォーマンスを高めることが可能になる。
【００５０】
＜第３の実施形態の説明＞
次に第３の実施形態を説明する。本第３の実施形態では、複数の書体のうちユーザが指定したコード範囲を他の書体で置き換えるものである。
【００５１】
図１４は本第３の実施形態における分割ファイルの構成を示している。先の第１の実施形態における図４のそれと異なる点は複数の書体が分割されていることである。尚、図示において、Ａ１〜Ａ３、Ｂ１〜Ｂ３及びＣ２はそれぞれファイル名を示している。
【００５２】
本第３の実施形態では、例えば書体Ａにおける文字コード“１０１”〜“１９９”の範囲は書体Ｃのそれを従属させ、例えばアプリケーションから書体Ａの文字コード１０１の文字データの要求が来たら、ファイルＣ２（実は書体Ｃ）からデータを取り出し、処理するものである。
【００５３】
これによれば、例えば、アルファベット、数字、平かな、カタカナ、漢字等が１つの“書体名”を使いながら、上記文字の種別毎に所望とする書体のパターンを発生することが可能になる。また、場合によっては、例えば書体Ａ全体がアウトラインフォントで、書体Ｃがドットパターンである場合には、特定の部分を高速に処理することが可能にもなる。
【００５４】
さて、本第３の実施形態における書体情報ファイルの内容例を図１５に示す。この書体情報ファイルの作成は、ユーザが自由に作成しても良く、システムが自動的に作成しても良い。或いは、上記第１の実施形態で示したように、書体データを本システムにインストールする段階で、ユーザに取捨選択させてもよい。
【００５５】
図１５に示すように、書体ＡのファイルＡ２の部分を書体Ｃの該当する部分に従属させるのであれば、書体ＡにおけるファイルＡ２は外部記憶装置１０９にインストールすることが不要になるので、外部記憶装置１０９のメモリ消費量を抑えることもできる。更に、ユーザが自分自身の書体を登録する場合にも、文字コードのどの範囲をどの書体で使用するかを決定しさえすればよいので、実質的にユーザ書体で消費されるメモリ量はその従属関係を示した書体情報ファイルのみになる。尚、図１５に示すように、各書体はそれが従属しているのか否かを示す情報が付加されており、１つの書体では文字コード範囲毎にそれが従属しているのか、その範囲に従属するものがあればその書体は何かを示す情報が付加されている。
【００５６】
さて、図１５に示すような書体情報ファイルがある場合に、本システムが起動すると、図１６に示すような書体管理情報テーブルがＲＡＭ１０３の書体情報管理領域上に作成される。
【００５７】
この書体管理情報テーブルの作成に係る処理を図１７のフローチャートに従って説明する。
【００５８】
ステップＳ７５１において本処理が開始されると、書体管理情報テーブルを作成するために書体情報管理領域２０５に或程度の領域を確保する。そして、ステップＳ７５２に進んで、外部記憶装置１０９に保存されている書体情報ファイルをオープンし、次のステップＳ７５３でそのオープンした書体情報ファイルから書体情報を獲得する。
【００５９】
ステップＳ７５４に処理が進むと、注目している書体が従属書体かどうかを判断する、従属処理である場合には、ステップＳ７５３に戻り、従属書体ではないと判断したら、ステップＳ７５５に進む。
【００６０】
ステップＳ７５５に処理が進むということは、１つの書体に対するテーブル作成開始を意味する。従って、ここでは、その書体名を書体情報管理テーブルに書き込み、以下に説明する処理でその書体に対する文字コード範囲毎の従属関係を明確にしたテーブルを構築していく。
【００６１】
ステップＳ７５６では、オープンしている書体情報ファイルから次の情報、すなわち、注目している書体中のコード範囲に対する従属情報を取り出す。そして、ステップＳ７５７では、取りだした文字コード範囲は従属されるのか否か、換言すれば、取りだした情報中に従属情報があるかどうかを判断する。
【００６２】
従属情報がなければ、ステップＳ７５８に進み、注目している書体に固有のファイル名を、注目しているコード範囲に対応するよう書体情報管理テーブルに書き込む。
【００６３】
また、従属情報があれば、ステップＳ７５９に進んで、その従属する書体の対応するファイル名を取り出し、それを書体情報管理テーブルに書き込む。
【００６４】
いずれの場合でも、処理はステップＳ７６０に進み、ステップＳ７５８或いは７５９で獲得されたファイル名を基に、そのファイルをオープンしアクセス可能にする。そして、次のステップＳ７６１において、アクセス可能となって書体ファイルより、そのファイルに格納されている書体データの開始コード及び終了コードに関する情報を読み取り、それを書体情報管理テーブルに書き込む。
【００６５】
ステップＳ７６２に処理が進むと、１つの書体に対する処理が終了したかどうかを判断し、終了していないと判断したらステップＳ７５６に戻って上記処理を行う。
【００６６】
また、１つの書体に対する全コード範囲に対する処理が終了したと判断した場合には、ステップＳ７６３に進み、次に処理すべき書体があるかどうかを判断する。処理すべき書体が残っていたら、処理はステップＳ７５３に戻り、処理すべき書体が無かったらステップＳ７６４に進む。
【００６７】
ステップＳ７６４に処理が進んだ場合には、オープンしている書体情報ファイルをクローズし、ステップＳ７６５で本処理を終了する。
【００６８】
以上の結果、例えば図１５に示すような書体情報ファイルがあった場合には、図１６に示すような書体情報管理テーブルが作成されることになる。
【００６９】
尚、こうして作成された書体情報管理テーブルを使用して書体データを獲得するときの処理は、先に説明した第１の実施形態と同様である。すなわち、アプリケーション部から書体Ａの文字コード“１０１”の書体データ獲得要求があったら、そのテーブルを調べ、書体Ａに対する文字コード“１０１”はファイル名Ｃ２であることが検出されるので、そのファイルＣ２から対応する書体データを取り出し、文字パターンを発生する。この書体データがアウトラインデータである場合には、ラスタライザ３０５に一旦渡してドットパターンを発生させ、それをアプリケーションに渡すことになる。
【００７０】
以上説明したように本第３の実施形態によれば、或る１つの書体の所望とするコード範囲を別の書体のデータを置き換えることにより、例えば英文や日本語の混じり合った文章を作成する場合等においては、いちいち書体を切り替えなくともそれぞれにユーザの意志が反映された書体での文字入力が行えるようになる。
【００７１】
しかも、インストール時に、或いは任意の時間に、他の書体のデータを従属するよう指示されたコード範囲にもともとあった書体データは実質的に不要になり、その部分をインストール対象から外したり、削除することが可能になるので、外部記憶装置１０９のメモリ消費量を抑えることが可能になる。
【００７２】
＜第４の実施形態の説明＞
第４の実施形態を以下に説明する。通常、システムに書体データをインストールする場合、１つの書体全体を１つの論理記憶デバイスに記憶することが必須である。本第４の実施形態は、１つの所定の記憶先を論理的に異なるデバイスに記憶することを可能にする。これによって、例えば各論理デバイスが１書体全部を記憶するだけの空き容量を有さない、或いは、各論理デバイスに或る程度の空きよう量を設けたいというような要求に応えるものである。
【００７３】
尚、ここで言う、論理記憶デバイスとは、物理的装置をも含む概念であり、例えば１つの物理的な記憶装置を論理的に複数の論理的な装置として区切られた場合、或いは同じ物理的装置であってもパスが異なるものをも含む概念である。
【００７４】
本第４の実施形態における書体情報ファイルの例を図１８に示す。尚、図示では説明を簡単にするために、１つの書体に対してのみ示した。図示において、Ａ１〜Ａ４は上記第１〜第３の実施形態で説明したようにコード範囲に対応する書体Ａのファイル名である。
【００７５】
図示について簡単に説明すると、書体Ａに対する或るコード範囲の書体データは、ファイルＡ１として論理ドライブＡに記憶されていることを示している。
【００７６】
さて、本第４の実施形態では、かかる書体情報テーブルをシステム起動時に取り出し、その中に記述されたデータに基づいて図１９に示すような書体情報管理テーブルを作成する。
【００７７】
第４の実施形態における書体情報ファイル及びそれに基づいて作成される書体情報管理テーブルのフォーマットは、第１の実施形態の図５Ａ及び図６に示したフォーマットに対して記憶先のドライブ名が記載されている点のみが異なる。当業者であれば、先に説明した第１の実施形態のかかる処理内容及び図１８に示した書体情報ファイルの構造に間がみれば容易に推察されるであろう。従って、ここではその説明は省略する。
【００７８】
ただし、本第４の実施形態では、インストールする時点で書体データを構成する個々のコード範囲のファイルの記憶先を指示するものとして説明したが、勿論、一旦全てを同一記憶ドライブに記憶させ、その後、、必要に応じて適当なコード範囲の書体データを別な記憶装置（例えばより高速な外部記憶装置）に移動させてもよい。
【００７９】
以上説明したように本第４の実施形態によれば、１つの書体データが１つの論理デバイスの同じ位置にある必要はなく、所望とするデバイスに記憶できるので、外部記憶装置を有効に活用することが可能になる。
【００８０】
＜第５の実施形態の説明＞
次に第５の実施形態を説明する。例えば、ある特定範囲の文字のデザインを使用する場合であっても、そのデザインの書体の全範囲の書体データを記憶する必要があるため、外部記憶装置等のメモリ消費量は無視できない。本第５の実施形態では、かかる課題を一掃する。
【００８１】
図２０は分割ファイルの構成を簡単に示している。図示において、書体Ａは、文字コード０〜５００で１つの文字書体全体を構成していることを示しており、０〜１００のＡ１、１０１〜１９９のＡ２、２００〜５００のＡ３の３つ部分的なコード範囲として管理している。書体Ａ’は書体Ａと同じもので、対応するキャラクタセットが異なり、キャラクタセットの切り替え時に変更しなければならない文字データ部分のみを持ち、含まれる文字コードは１０１〜１９９のＡ２と同一である。つまり、書体として、Ａ’はＡと同じであるが、使用する文字コードは１０１〜１９９のみである。
【００８２】
尚、キャラクタセットとは、同じコード範囲（空間）において、例えば平かなとカタカナ、英語のアルファベットとロシア語のアルファベットといった具合に文字表現を言う。
【００８３】
上記書体管理を行うため、本第５の実施形態における書体情報ファイルは図２１に示すように、書体ファイルとキャラクタセットの関連が記述されている。
【００８４】
システム起動時におけるＲＡＭ１０３中の書体管理情報領域２０５に構築される書体管理情報テーブルの作成手順は、図７に示される手順で行われるので、ここでの説明は割愛する。この結果、図２２に示される書体管理情報テーブルが構築される。テーブル中、Ａ１、Ａ２、Ａ３及びＡ２’はそれぞれ書体データＡ，Ａ’を構築するデータのファイル名称である。
【００８５】
尚、このようにして作成された書体管理情報テーブルを用いて文字データ取得の流れも、図８に示した手順で行われるが、説明すれば以下の通りである。
【００８６】
先ず、ステップＳ８０１において、文字データ取得処理を開始する。
【００８７】
ステップＳ８０２においては、図３におけるＡＰ部３０７より取得する文字に関する情報（文字コード，書体情報、キャラクタセット）を取得する。次のステップＳ８０３においては、図６の書体管理情報テーブルを検索し、対応する書体及びキャラクタセットが存在するかチェックを行う。存在する場合はステップＳ８０４へ、存在しない場合はステップＳ８０５へ進む。
【００８８】
ステップＳ８０５では、図２２に示される書体管理情報テーブル上に別の書体がまだ存在するかどうかを判断する。存在する場合にはステップＳ８０３に進み、、テーブル中の別の書体に対するチェックを行う。
【００８９】
また、要求された書体がテーブル中に存在すると判断し、ステップＳ８０４に進むと、注目書体中の注目キャラクタセットの開始コード及び終了コード内に、要求されたコードが含まれているかどうかを判断する。尚、コード範囲は、存在しないファイルに関しては、開始コード及び終了コードともに“−１”が格納されているものとしているので、そのコードの文字データが管理されているかどうかは容易に判断できる。
【００９０】
さて、ステップＳ８０４において、要求された文字コードが注目しているキャラクタセットの範囲外にあると判断された場合には、ステップＳ８０６に進んで、同一書体に未だチェックしていないキャラクタセットがあるかどうかを判断する。もしあればステップＳ８０４に戻り、再び要求コードに対応するキャラクタセットが存在するかどうかを判断する。また、ない場合には、ステップＳ８０９に進んで、文字無し処理を行う。
【００９１】
一方、要求された文字の書体とその文字コードを管理しているキャラクタセットが存在すると判断した場合には、ステップＳ８０７に進み、書体管理情報テーブルからファイル名を獲得し、ステップＳ８０６でそのファイル名のファイルから該当する文字データを取得する。そして、ステップＳ８１０に進んで、処理を終了する。
【００９２】
以上説明したように本第５の実施形態によれば、同じ書体であっても異なるキャラクタセットの文字が指定された場合であっても、使用する文字のみを含むコード範囲の書体データを有するだけで良く、全文字コードに対応するデータは不要になり、外部記憶装置の記憶領域を有効に活用することができる。
【００９３】
＜第６の実施形態の説明＞
上記第５の実施形態では、例えば書体Ａと同じ書体Ａ’を使いながらも、異なるキャラクタセットを使用する場合に、その使用する文字コード範囲の書体データのみを外部記憶装置に記憶させることで、メモリの有効利用を図るものであった。
【００９４】
本第６の実施形態では、異なる書体を記憶し、一方の書体中の特定のコード範囲の書体データとして、他方の書体の同じ範囲の書体データを活用する例である。この結果、共通して使用する部分の書体データを重複して持つ必要を無くし、メモリの効率的使用を可能とするものである。
【００９５】
図２３は本第６の実施形態における分割ファイルの構成を簡単に示している。図示において、書体Ａは、文字コード０〜５００で１つの文字書体全体を構成していることを示しており、０〜１００のＡ１、１０１〜１９９のＡ２、２００〜５００のＡ３の３つ部分的なコード範囲として管理している。
【００９６】
また、書体Ｂも書体Ａと同様、全文字コード空間を３つ分割されて管理されており、このうち、文字コード０〜１００と、２００〜５００は書体Ｂ特有の書体データを使用し、コード１０１〜１９９については書体Ａのものを使用する。
【００９７】
上記書体管理を行うため、本第５の実施形態における書体情報ファイルは図２４に示すように、書体の種類とその書体を構築する分割書体データファイル名で構成されている。
【００９８】
システム起動時におけるＲＡＭ１０３中の書体管理情報領域２０５に構築される書体管理情報テーブルの作成手順は、図７に示される手順で行われるので、ここでの説明は割愛するが、いずれにしても図２５に示される書体管理情報テーブルがＲＡＭ１０３中の書体情報管理領域２０５中に構築される。
【００９９】
文字データ取得処理も、図８に示したフローチャートに従えば良い。すなわち、ＡＰ部から文字データ取得要求があった場合には、その要求のなかで指定された書体データに基づいて書体情報管理テーブルのどの書体が選択されたのかを判断し、次にその書体中の指定された文字コードを管理しているファイル名を取得し、その後、そのファイルから対応する文字データを取得する。
【０１００】
＜第７の実施形態の説明＞
これまで、書体データを判別する場合、書体を表す書体名或いは書体番号、叉は、書体名及び書体番号、または、必要によるスタイル情報、幅情報、ウエート情報を別々に用いて判別していたため、その判別処理は複雑にならざるを得ず、時間がかかるという問題があった。
【０１０１】
そこで、本第７の実施形態では、かかる判別を簡単にしかも高速に行うことを可能にする例を説明する。
【０１０２】
図２６は、本第７の実施形態におけるスタイル幅ウエート情報のフォーマットを示している。図示の如く、スタイル情報として４ビット（値として０〜１５）、幅情報として４ビット、ウエート情報として８ビット（０〜２５５）が割り当てられている。スタイル情報としては、“０”はregular、“１”はitalic、…として定義した。また、幅情報としては、extra condence, condence, regular, expand, extra expandに４，６，８，１０，１２を対応させている。そして、ウエート情報としては、特細、極細、細、中細、中、中太、太、極太、特太に、６０，７０，８０，９０，１００，１１０，１２０，１３０，１４０を対応させた。
【０１０３】
さて、本実施形態におけるインストール手順（外部記憶装置１０９のフロッピーディスクからハードディスクへのインストール）を図２７のフローチャートに従って説明する。
【０１０４】
先ず、ステップＳ３０１において、インストールする書体データとインストールに必要なデータ（インストールデータファイル）が格納されているメディアを設定するよう要求し、そのメディアの指定をユーザに行わせる。
【０１０５】
次に、ステップＳ３０２に進んで、インストールする書体データが格納されているインストールデータファイルから書体名情報、書体番号、スタイルウエート情報を読出す。
【０１０６】
ステップＳ３０３では、インストール先に既にインストールされている書体情報ファイル内の書体データを読み込む。このとき、読み込むべき書体情報ファイルがインストール先に存在しないとステップＳ３０４で判断したら、その書体ファイルの作成を行う（ステップＳ３０５）。
【０１０７】
次に、処理はステップＳ３０６に進んで、インストール先の書体情報ファイルの内容とインストールしようとしている書体情報とを比較する。比較処理の優先順位は、第１に書体番号、第２にスタイル幅ウエート情報、第３の書体名とする。以上の項目が全て同じ場合には無条件で同じ書体である。また、第１番目の項目と第２番目の項目の内容が同じである場合、書体の文字データが同じである為、書体の内容が重ならないようにする処理と、書体名を含めてユニークに処理するかをこの処理で確定する（例えば、ユーザに指示するようにする）。
【０１０８】
さて、処理がステップＳ３０７に進むと、本インストール処理によりインストールしようとしている書体データは更新か新規追加であるかを判断する。更新処理とは、先に説明したように３つの項目が全て同じ場合である。
【０１０９】
更新処理であると判断した場合には、ステップＳ３０９に進んで、既にインストールされている書体データに上書きするため、書体情報ファイルに記述されている同じ書体の存在位置に上書きする。このとき、ユーザによってインストール先が別個に指示されていれば、その指示された位置に書き込む処理を行う。
【０１１０】
また、新規書体インストールであると判断した場合には、ステップＳ３０８に進んで、書体名、書体番号、スタイル幅ウエート情報、タグファイル名、書体情報全てをインストールする。
【０１１１】
そして最後に本処理を終了し、呼び出し元に戻る。
【０１１２】
図２８はインストールメディアの内容と、その中のインストールデータファイルの中身を示している。
【０１１３】
インストールデータファイルには、インストールに必要な情報が記述されている。書体ファイルには、書体情報が格納されている。タグファイルには、書体ファイルの情報より書体を作成するためのデータが格納されている。従って、１つの書体データから複数のタグファイルを用いてタグファイル分の書体が存在すると考えられる。
【０１１４】
図２９は、本実施形態における書体情報ファイルの内容の一例を示している。“NAME”はディスクリプション名、書体情報（主書体番号、副書体番号、スタイル幅ウエート情報）である。“DEFTAG”はタグファイル名、タグファイルに存在する書体名である。また、“FILE”は書体ディスクのインストール先と書体ファイルのファイル名である。
【０１１５】
図３０はタグファイルの内容例を示している。このファイルには、タグファイルのサイズ、書体番号、スタイル幅ウエート情報、ディスクリプション名、書体メトリクス情報に、フェィス名を格納する。この中の書体番号、スタイルウェート情報より書体データへの関連ずけを行う。
【０１１６】
図３１は、書体ファイルの内容を示している。このファイルには、書体構成情報（ファイルサイズ）、書体データ（書体開始コード、文字数）、書体番号、スタイル幅ウェート情報が格納される。
【０１１７】
以上の如く本第７の実施形態によれば、インストール後は、書体情報のスタイル情報、幅情報、ウェート情報を合わせたスタイル幅ウェートを書体を表す情報として持つことで、書体名、書体番号等を比較するよりも簡単に高速に書体の判別が可能になる。
【０１１８】
＜第８の実施形態の説明＞
第８の実施形態を説明する。本第８の実施形態では、フォント関連のファイル名の最適化を行わせる原理を説明する。例として、本実施形態におけるシステム（或いはＯＳ）が管理するファイル名は８文字（８バイト）、拡張子が３文字（３バイト）である例を説明する。
【０１１９】
図３２は本第８の実施形態における書体物理ファイルのファイル名称に用いる文字構造を示している。
【０１２０】
図示において、▲１▼は図３４に示す書体識別用の２文字が位置し、▲２▼には図３６で示されるスタイル幅情報（０〜９）を表す１個の数字が位置する。▲３▼には図３７に示されるウェイト情報を表す数字が位置し、▲４▼には図３８で示されるサイズ・サポート領域情報である。▲５▼はファイル識別情報であり、実施形態では文字列“ＪＦＤ”を用いる。
【０１２１】
また、図３３は、書体データの書体論理データファイルのファイル名の構造を示している。▲６▼は書体管理情報であり、任意の３文字を用いて表す。▲１▼は本ファイルのリリースの順番を示しており、図３５により当てはめる。▲３▼は図３７に示すウェイト情報である。▲８▼はメトリクス情報識別情報であある。本項目は本ファイルのリリースの順番を示す。また、プリンタフォントと同一な情報を持つ場合は、“Ｐ”で表す。▲５▼はファイル識別情報であり、この場合は“ＦＯＮ”を使用する。
【０１２２】
以下、図３４から図３８について更に詳しく説明する。
【０１２３】
図３４は物理書体の識別情報である。ＭＩは明朝体、ＧＯはゴシック体、ＲＧは丸ゴシック体、ＫＡは楷書体、ＫＹは教科書体を表す。図３５におけるＭＩＮは明朝体、ＧＯＴはゴシック体、ＲＧＯは丸ゴシック体、ＫＡＩは楷書体、ＫＹＯは教科書体をそれぞれ表している。
【０１２４】
図３６はスタイル幅情報を示している。スタイルとしては、regularとitalicの２種類があり、幅情報としてはextra condence, condence, regular, expand,extra expandがある。この組み合わせによって、例えば図示の如く、regularとextra condenceの場合に“１”を割り当てた。同様に、regularとcondenceに“１”、regularとregularに“２”、regularとexpandに“３”、regularとextraexpandに４を割り当てた。また、italicrとextra condenceの場合に“５”を割り当て、italicとcondenceに“６”、italicとregularに“７”、italicとexpandに“８”、italicとextra expandに“９”を割り当てた。
【０１２５】
図３７はウェイト情報を示し、実施形態では、特細、極細、細、中細、中、中太、太、極太、特太に、数字１〜９を割り当てた。
【０１２６】
図３８は実施形態におけるサイズ・サポート領域情報である。本データの上位８ビットを用いてサイズデータを１６進数で表す（文字でいうと“１”から“Ｆ”）。尚、アウトラインデータ等のスケーラブル書体データである場合には数字“０”を用いる。また、下位８ビットに各領域を割り当て、対応する領域である場合にはそのビットを“１”にする。実施形態ではビット７を非漢字領域、ビット６を第１水準領域、ビット５を第２水準領域、ビット４を旧ＪＩＳ領域、ビット３をかな領域、ビット２を応分領域、ビット１を外字領域、そしてビット０を特殊領域とした。
【０１２７】
以上によりファイル名称を決定する。以下、書体情報とその書体情報による決定例を示す。
【０１２８】
書体情報｛１．書体名：明朝体、２．スタイル名：regular、３．文字幅情報：condence、４．文字ウェイト情報：中、５．文字サイズ：１００ドット、６．サポート領域、第１水準、７．メトリクス情報識別情報：プリンタフォントと同一なメトリクス情報であるため“Ｐ”、８拡張子によるファイル分類：ＪＦＤ（書体物理データファイル）とＦＯＮ（書体論理データファイル）、９：書体管理環境名称：ＦｏｎｔＭａｎａｇｉｎｇ｝により決定する。
【０１２９】
この場合、書体物理データファイルの名称を決定するためには、図３２で示される▲５▼は“ＪＦＤ”になる。▲１▼は図３４によって“ＭＩ”になる。また▲２▼は図３６により“１”、▲３▼は図３７により“５”になる。サイズ１００は１６進数で表すと、６４Ｈであり、図３８に従ってビット６のみを立てるから下位８ビットは４０Ｈ、従って、▲４▼は“６４４０”になる。
【０１３０】
つまり、ファイル名“ＭＩ１５６４４０．ＪＦＤ”である。
【０１３１】
次に、書体論理データファイルの場合には、拡張子▲５▼は“ＦＯＮ”、▲６▼はＦｏｎｔＭａｎａｇｅｒを表すことに統一するので、“ＦＯ＿、▲１▼は図３５より“ＭＩＮ”、▲３▼は図３７により“５”、▲８▼は“Ｐ”である。
【０１３２】
従って、この書体論理データファイルの名称は“ＦＭ＿ＭＩＮ５Ｐ．ＦＯＮ”である。
【０１３３】
以上説明したように本第８の実施形態によれば、書体ファイル名称にファイルに格納されているデータを示す情報を表示したことにより、書体ファイルに格納されている情報が解り易くすることができる。
【０１３４】
＜第９実施形態の説明＞
第９実施形態について説明する。
【０１３５】
通常、文字パターン発生には、先に説明したようにビットマップパターンを予め記憶しておき、それを取得するビットマップフォント方式と、アウトラインデータに基づいて文字の輪郭を形成し、その内部を埋めることで文字パターンを得るアウトラインフォント方式がある。
【０１３６】
前者は、比較的小さい文字（ドット構成の小さい文字）に対して有効な方式であり、文字が潰れることなく、且つ、生成するにしても基本となる文字パターンに対して間引きすれば済むので、高速に処理することが可能である。後者は、ラスタライザによって輪郭を描画し、その内部を埋める処理が必要なため、速度は落ちるが、大きい文字（最終的なドット構成の大きい文字）の品位を高めることができる。
【０１３７】
ところが、比較的小さい文字を発生するのに適したビットマップフォント方式では、比較的高い確率で要求される文字パターンも、低い確率の文字パターンも、基本となる文字パターンから一律な処理でもって行っており、まだ改善の余地が残っている。
【０１３８】
本第９の実施形態では、ビットマップフォントによる発生方式を更に改善させるものである。
【０１３９】
さて、本第９の実施形態では、２０×２０のドットのビットマップフォントがリソースされ、それから４×４〜２０×２０の文字パターンを発生する例について説明する。
【０１４０】
図３９は実施形態におけるビットマップフォントによる文字パターン発生処理の手順を示したフローチャートである。
【０１４１】
先ず、ステップＳ１で、要求された文字のコードおよび文字のサイズを取得する。そして、ステップＳ２においては、その要求された文字コードの文字パターン（２０×２０ドット）をＲＯＭ１０２或いは外部記憶装置１０９より取り出し、ＲＡＭ１０３中の所定エリアに展開する。
【０１４２】
ステップＳ３では、１回の処理でデフォルメせずに縮小可能な縦方向のライン数の算出する。要求された文字サイズが先に獲得した文字サイズ（２０×２０）の半分以下の場合には、文字パターンの半分まで、それ以外の場合には、（縮小前の文字サイズ＋２）／５により求める。この式は、２０×２０ドット以下の文字パターンに限定した場合、１回の縮小するライン数を４ライン以下にすることにより、デフォルメ（偏り）を防止することを主眼にした式である。
【０１４３】
ステップＳ４に処理が進むと、実際の縮小処理を行う。ここでは、ステップＳ３で求められたライン分の縮小処理を行う。このとき、縮小処理を行う位置は、文字パターンの幅／（縮小ライン数＋１）により求められた等分割位置である。ここで縮小ライン数＝２のときは、分母が奇数になるため、正しく等分割できずデフォルメする可能性がある（図４０参照）。従って２回目の縮小時に前記縮小位置の計算より発生した残りの分だけ位置をずらす補正処理を行う。これを示したのが図４１である。また、縮小ライン数＝４の場合も、分母が奇数となるが、縮小前の文字パターンが２０×２０ドット以下の場合は問題にならないため特に処理は行わない。算出された縦方向のラインでは、その右隣のラインと重ね合わせ（論理和）処理する、換言すれば縮小するラインの位置とその右隣のラインの２ラインで１ラインのドットパターンを生成する。
【０１４４】
ステップＳ５では、縮小した結果が、要求されたサイズになったか判定し、全縮小ライン数とステップＳ４で縮小したライン数の差分により判定する。判定の結果、要求されたサイズに満たない場合には、ステップＳ３に戻り、縮小処理を繰り返すことになる。また、要求された文字パターンの作成が完了した場合には、ステップＳ６で要求元に発生した文字パターンを出力する。
【０１４５】
尚、上記説明で、１回の縮小処理における縮小するライン数を４以下に抑えるという意味は、例えば、２０×２０の基本サイズから１２×１２のパターンを発生する場合（最終的には８ライン（＝２０−１２）が縮小される）、第１回目において、８ライン全部を縮小するのではなく、第１回目で４ライン分を縮小し、その後で更に４ライン分を縮小することを意味する。因に、先に説明したように２ライン分縮小する場合、すなわち、１８ラインの文字パターンを発生する場合には、その縮小ライン数が４以下であるので問題はないことになる。但し、先に説明した補正処理は行う。
【０１４６】
また、本第９の実施形態では、横方向に縮小する例を説明したが、縦縦方向への縮小も全く同様に処理することができ、更には縦横共に処理することもできるので、上記内容で本発明が限定されるものではない。
【０１４７】
また、使用するビットマップは２０×２０に限定されるものではなく、各々のサイズにおいて縮小する際に効率良く処理が行えるならば、特に１つに限定されるものではない。
【０１４８】
また、予め２０×２０、１６×１６、１３×１３、１０×１０等の「（縮小前の文字サイズ＋２）／５」の１回の処理で取得し得る最小サイズの複数ビットマップフォントを用意し、ステップＳ３〜Ｓ５のループ数を減らし、且つ、品位の向上に役立てても良い。
【０１４９】
以上説明したように本第９の実施形態によれば、要求された文字パターンのサイズが本文作成等で最も使用される可能性の高いサイズ（４×４〜２０×２０）のみビットマップフォントを使用し、縮小を行う位置等の計算を限定されたサイズに最も有効となるように単純化することにより、パフォーマンスの良い文字パターン縮小が行える。
【０１５０】
＜第１０の実施形態の説明＞
本第１０の実施形態について説明する。
【０１５１】
上記実施形態（例えば第８の実施形態）では、ファイル名をそのファイルが有すデータを反映させた。従って、書体を提供する側が、過去に供給した名称とは異なる名称を新たに提供する場合には異なるファイル名を付けるように管理すれば良い。但し、システムのユーザが書体を作成できるようにした場合、供給側ではそのユーザが使用しているファイル名までは管理できない。従って、同じ情報を有する書体が作成される場合があり、一旦同じ情報を含む書体を削除した後に作成した書体の複写を行ったり、同じ情報の該当する書体情報を変更した後に複写を行わねばならない。
【０１５２】
本第１０の実施形態では、かかる問題を解決する。
【０１５３】
図４２は、実施形態における書体情報ファイルに付けられるファイル名の一例を示している。図示の如く、本第１０の実施形態においては、ファイル名の部分に８文字（８バイト）と、拡張子に３文字（３バイト）を使用している。本実施形態では、“ＦＧ＿ＵＳ”は固定のものとし、その後に示した□には書体番号と同じ値が付けられる。但し、ファイル名の付け方はこれに限るものではない。
【０１５４】
図４３は書体情報ファイルの内部構造を示している。この書体情報ファイル内には図示の符号１４で示される書体名、符号１５で示される書体番号が格納されている。また、この他には例えば、作成日時やバージョン等の情報も格納されている。
【０１５５】
図４４は外部記憶装置１０９に記憶されている書体の格納先を管理する書体格納情報ファイルの構造を示しており、記憶されている全書体についての情報が入っている。この書体格納情報ファイルには、符号１６で示される書体１の登録番号、符号１７の書体１の書体情報ファイル名、１８の書体１の書体名、１９の書体１の書体番号である。同様に書体２、… 書体ｎそれぞれに対しても同様な情報が格納されている。
【０１５６】
図４５のフローチャートに基づいて本第１０の実施形態における書体管理手順を説明する。
【０１５７】
先ず、ステップＳ５０１において、複写元の書体情報ファイル（ユーザが作成した書体データを管理している書体情報ファイル、４３参照）から書体情報を取得する。次にステップＳ５０２に進んで、システムの管理下におかれている書体の格納情報ファイル（図４４参照）から格納されている書体に関する書体情報を取得する。
【０１５８】
ステップＳ５０３においては、先のステップＳ５０１、Ｓ５０２で取得した情報から、同じ書体名の書体が格納されているかどうかを判断する。同じ書体名の書体が既に書体格納情報ファイル内に格納されていると判断した場合にはステップＳ５０４に、その書体名の書体がシステムに登録されていないと判断した場合にはステップＳ５０７に進む。
【０１５９】
ここで同じ書体名がシステムに登録されていないと判断され、ステップＳ５０７に進むと、ユーザが作成した書体の書体番号と同じ書体番号がシステムに登録されているかどうかを判断する。ここでも、同じ書体がないと判断したら、処理はステップＳ５１２、Ｓ５１３に進み、システムに登録されている書体情報を記憶している書体格納情報ファイルに、ユーザが作成した書体情報ファイルの内容を複写（追加）し、その書体格納情報ファイルを更新する。
【０１６０】
一方、ステップＳ５０３で、同じ書体名の書体が既に登録されていると判断した場合には、ステップＳ５０４に進んで、それれが同じ書体番号であるかどうかを判断する。
【０１６１】
同じ書体番号である、すなわち、書体名及び書体番号の両方とも既にシステムに登録されていると判断した場合には、ステップＳ５０５、Ｓ５０６に進んで、書体格納情報ファイル内の該当する位置にユーザが作成した書体情報ファイルの内容で上書きし、書体格納情報ファイルを更新する。
【０１６２】
ステップＳ５０７で“ＹＥＳ”であると判断した場合、すなわち、同じ書体名ではないが、同じ書体番号であると判断した場合には、ステップＳ５０８に進んで、新たに登録しようとしている書体の使用されていない書体番号を検出し、ステップＳ５０９に進む。
【０１６３】
ステップＳ５０４の判断が“ＮＯ”、つまり、同じ書体名が存在するが、書体番号が異なると判断した場合にもステップＳ５０９に処理が進む。この場合には、書体番号が重複することはないことになる。
【０１６４】
いずれにせよ、ステップＳ５０９に処理がくるということは、書体名が同じで、書体番号が異なる場合である。ユーザ側から見て書体名が重要で、同じ書体名が複数あると混乱の素になる。そこで、ステップＳ５０９、Ｓ５１０、Ｓ５１１では、登録しようとしている書体名のファイルを変更（例えば書体名に“USR”を付加する等）し、その変更された書体名を書体格納情報ファイルに追加し、且つ、その書体番号で登録することで、書体格納情報ファイルを更新する。
【０１６５】
上記例では、書体名をキー情報として書体の登録状態を判別し書体番号を書体情報ファイルのファイル名と対応させ、書体番号を変更して複写を行うことより、同じ書体情報が含まれる書体を管理することが可能になる。また、本発明はユーザに書体を作成できるようなツールを提供し、前記ツールによる作成された書体を使用するとき等に多大な効果を発揮する。
【０１６６】
尚、上記実施形態では、書体名をキーにして書体情報を検索し、書体番号を変更するようにしたが、書体番号をキーにして検索し、書体名を変更するようにしても良く、検索に用いるキー情報及び変更する書体情報はこの限りではない。
【０１６７】
以上説明した様に本第１０の実施形態によれば、書体情報と書体情報ファイルのファイル名を対応させ、同じ書体情報が含まれる書体が検出されたときには、書体情報を変更して複写（登録）を行うようにしたことにより、同じ書体情報が含まれた場合であっても書体を管理することが可能になる。
【０１６８】
また、ユーザが書体を作成できるような場合に、同じ情報を有する書体が作成された場合でも、一旦同じ情報を含む書体を削除した後に作成した書体を複写を行ったり、同じ情報に該当する書体情報を変更した後に複写を行ったりする作業の軽減を図ることが可能になる。
【０１６９】
上記第１〜第１０の実施形態に限らず、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器から成る装置に適用しても良い。また、本発明はシステム或は装置にプログラムを供給することによって達成される場合にも適用できることは言うまでもない。
【０１７０】
【発明の効果】
以上説明したように本発明によれば、柔軟性のある書体データの管理方法を提供することが可能になる。
【図面の簡単な説明】
【図１】実施形態におけるシステム構成図である。
【図２】実施形態におけるＲＡＭのメモリマップである。
【図３】文字処理装置の構成例を示す図である。
【図４】第１の実施形態における分割ファイルの構成例を表す図である。
【図５Ａ】第１の実施形態における書体情報ファイルの内容の一例を示す図である。
【図５Ｂ】第１の実施形態におけるインストール後の書体ファイルの構成例を示す図である。
【図６】第１の実施形態における書体管理情報テーブルの内容例を示す図である。
【図７】第１の実施形態における書体管理情報テーブル作成処理の手順を示すフローチャートである。
【図８】第１の実施形態における文字データ取得処理の流れを示すフローチャートである。
【図９】第２の実施形態における書体管理情報テーブルの初期状態例を示す図である。
【図１０】第２の実施形態における文字データ取得処理の流れを示すフローチャートである。
【図１１】第２の実施形態における書体管理情報テーブルの中間的な状態例を示す図である。
【図１２】第２の実施形態で更新された書体情報ファイルの内容例を示す図である。
【図１３】第２の実施形態における更新された書体情報ファイルの内容で起動した場合の書体管理情報テーブルの状態例を示す図である。
【図１４】第３の実施形態における分割書体ファイルの構成例を示す図である。
【図１５】第３の実施形態における書体情報ファイルの内容例を示す図である。
【図１６】第３の実施形態における書体管理情報テーブルの内容例を示す図である。
【図１７】第３の実施形態における書体管理情報テーブルの作成処理の流れを示すフローチャートである。
【図１８】第４の実施形態における書体情報ファイルの内容例を示す図である。
【図１９】第４の実施形態における書体管理情報テーブルの内容例を示す図である。
【図２０】第５の実施形態における分割ファイルの構成例を示す図である。
【図２１】第５の実施形態における書体ファイルの内容例を示す図である。
【図２２】第５の実施形態における書体管理情報テーブルの内容例を示す図である。
【図２３】第６の実施形態における分割書体ファイルの構例成を示す図である。
【図２４】第６の実施形態における書体情報ファイルの内容例を示す図である。
【図２５】第６の実施形態における書体管理情報テーブルの内容例を示す図である。
【図２６】第７の実施形態におけるスタイル幅ウエート情報のフォーマットを示す図である。
【図２７】第７の実施形態における書体インストール手順を示すフローチャートである。
【図２８】第７の実施形態におけるインストールメディアの内容と、その中のインストールデータファイルの中身を示す図である。
【図２９】第７の実施形態における書体情報ファイルの内容例を示す図である。
【図３０】第７の実施形態におけるタグファイルの内容例を示す図である。
【図３１】第７の実施形態における書体ファイルの内容例を示す図である。
【図３２】第８の実施形態における書体物理ファイルのファイル名称に用いる文字構造を示す図である。
【図３３】第８の実施形態における書体データの書体論理データファイルのファイル名の構造を示している
【図３４】第８の実施形態における物理書体の識別情報を表す各種文字列を示す図である。
【図３５】第８の実施形態における書体論理データファイルの識別情報を表す各種文字列を示す図である。
【図３６】第８の実施形態におけるスタイル幅情報の意味内容を示す図である。
【図３７】第８の実施形態におけるウェイト情報の意味内容を示す図である。
【図３８】第８の実施形態におけるサイズ・サポート領域の関係を示す図である。
【図３９】第９の実施形態における縮小文字パターン生成にかかる処理内容を示すフローチャートである。
【図４０】第９の実施形態における縮小処理の問題点を示す図である。
【図４１】第９の実施形態における補正後の縮小処理を示す図である。
【図４２】第１０の実施形態における書体情報ファイルの名称のフォーマットを示す図である。
【図４３】第１０の実施形態における書体情報ファイルの内部構造を示す図である。
【図４４】第１０の実施形態における書体格納情報ファイルの構造を示す図である。
【図４５】第１０の実施形態における書体登録の処理手順を示すフローチャートである。
【符号の説明】
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ キーボード制御部（ＫＢＣ）
１０５ キーボード（ＫＢ）
１０６ 表示装置制御部（ＣＲＴＣ）
１０７ 表示装置
１０８ ＤＫＣ
１０９ 外部記憶装置
１１０ プリンタ制御部
１１１ プリンタ
【図１】
0003715917.tif 000002
【図２】
0003715917.tif 000003
【図３】
0003715917.tif 000004
【図４】
0003715917.tif 000005
【図５Ａ】
0003715917.tif 000006
【図５Ｂ】
0003715917.tif 000007
【図６】
0003715917.tif 000008
【図７】
0003715917.tif 000009
【図８】
0003715917.tif 000010
【図９】
0003715917.tif 000011
【図１０】
0003715917.tif 000012
【図１１】
0003715917.tif 000013
【図１２】
0003715917.tif 000014
【図１３】
0003715917.tif 000015
【図１４】
0003715917.tif 000016
【図１５】
0003715917.tif 000017
【図１６】
0003715917.tif 000018
【図１７】
0003715917.tif 000019
【図１８】
0003715917.tif 000020
【図１９】
0003715917.tif 000021
【図２０】
0003715917.tif 000022
【図２１】
0003715917.tif 000023
【図２２】
0003715917.tif 000024
【図２３】
0003715917.tif 000025
【図２４】
0003715917.tif 000026
【図２５】
0003715917.tif 000027
【図２６】
0003715917.tif 000028
【図２７】
0003715917.tif 000029
【図２８】
0003715917.tif 000030
【図２９】
0003715917.tif 000031
【図３０】
0003715917.tif 000032
【図３１】
0003715917.tif 000033
【図３２】
0003715917.tif 000034
【図３３】
0003715917.tif 000035
【図３４】
0003715917.tif 000036
【図３５】
0003715917.tif 000037
【図３６】
0003715917.tif 000038
【図３７】
0003715917.tif 000039
【図３８】
0003715917.tif 000040
【図３９】
0003715917.tif 000041
【図４０】
0003715917.tif 000042
【図４１】
0003715917.tif 000043
【図４２】
0003715917.tif 000044
【図４３】
0003715917.tif 000045
【図４４】
0003715917.tif 000046
【図４５】
0003715917.tif 000047