JP3285995B2 - 書体データ管理方法及び装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は書体データ管理方法及び
装置、例えばパーソナルコンピュータ、ワードプロセッ
サやデスクトップパブリッシング装置等で使用される各
種書体のデータファイルを管理する書体データ管理方法
及び装置に関するものである。

【０００２】

【従来の技術】従来、文字処理システムにおいて管理さ
れる書体データは、管理の容易さなどの理由から、一つ
のファイル中に書体単位で全文字のデータを格納してい
た。

【０００３】

【発明が解決しようとする課題】前述の従来方法による
書体データ管理方法では、以下に示す問題が有る。

【０００４】あらかじめ書体データの全てがファイル中
に格納されており、インストールの対象はあくまでも書
体単位での選択しかなかった。このため一般的に使用さ
れることがあまりない書体データまでも同時にインスト
ールされてしまい、ディスクメモリを圧迫する結果とな
っていた。

【０００５】

【課題を解決するための手段】本発明はかかる従来技術
に鑑み成されたものであり、柔軟性のある書体データ管
理方法及び装置を提供しようとするものである。

【０００６】この課題を解決するため、例えば本発明の
書体データ管理方法は以下の工程を備える。すなわち、
要求された文字に関するデータを書体データファイルか
ら取り出すための書体データ管理方法において、複数の
部分コード空間に分割された文字コード空間における、
前記各部分コード空間毎に独立した書体データファイル
を管理し、アプリケーションからの文字取得要求を文字
コードと共に認識する認識ステップと、前記認識ステッ
プに連動して、前記認識ステップにて認識した文字コー
ドが前記複数の部分コード空間に分割された文字コード
空間の何れかの部分コード空間に含まれるかを特定する
特定ステップと、前記特定ステップにて特定された部分
コード空間のアクセス頻度を更新する更新ステップと、
前記更新ステップにて更新されたアクセス頻度をファイ
ルとして保存する保存ステップと、システム起動時に前
記ファイルより取得されるアクセス頻度に従い、文字取
得要求に対して検索される個々の書体データファイルの
検索順序を変更する変更ステップとを有することを特徴
とする。

【０００７】

【０００８】

【実施例】以下、図面を参照し、本願発明について詳細
に説明する。

【０００９】まず、パーソナルコンピュータ等の文字デ
ータを扱うシステムが、文字の表示或は印字を行う際
に、書体データを獲得するまでの動きを簡単に説明す
る。

【００１０】図１はこれら上記のシステムが動作するた
めの基本的な構成を示すブロック図である。

【００１１】図１において、１０１はＣＰＵ、即ち中央
処理装置であり、上記システム全体の起動及び演算処理
等を行うものである。１０２は読み出し専用メモリ（Ｒ
ＯＭ）であり、システム起動プログラム（ブートプログ
ラム）及び文字パターン・データ等の記憶領域である。
１０３はランダムアクセスメモリ（ＲＡＭ）であって、
システムプログラム、各種アプリケーションプログラム
や、文字パターン発生のためのドライバプログラム等が
ロードされると共に、各種データの一時的に記憶に用い
られる。後述するフローチャートに係るプログラムも勿
論、このＲＡＭ１０３にロードされて実行される。１０
４はキーボード制御部（ＫＢＣ）であり、１０５のキー
ボード（ＫＢ）よりキー入力データを受け取り、ＣＰＵ
１０１へ伝達する。１０６はディスプレイ装置（ＣＲ
Ｔ）１０７の制御を行うＣＲＴ制御部（ＣＲＴＣ）であ
る。１０９はフロッピーディスク装置（ＦＤ）やハード
ディスク装置（ＨＤ）等の外部記憶装置であって、これ
らにシステムプログラムやアプリケーションプログラム
をはじめとする各種プログラムやフォントデータが格納
されている。プログラムの実行時には、これら外部記憶
装置１０９に記憶されたプログラムがＲＡＭ１０３にロ
ードされてＣＰＵ１０１により実行されることになる。
１１０はプリンタ制御部（ＰＲＴＣ）であり、１１１は
ＰＲＴＣ１１０の制御の下で、送出されてきたデータに
基づく可視画像を記録紙上に形成するプリンタ（ＰＲ
Ｔ）である。１１２はシステムバスであり、上述の構成
要素間のデータの通路となるべきものである。

【００１２】図２はＲＡＭ１０３のメモリマップを示し
た図である。２０１はシステムがロードされるシステム
領域であり、２０２は文字展開処理部がロードされる領
域であり、２０３は文字展開処理部がビットパターンデ
ータを格納する領域である。２０４は文字展開処理時に
おいて、１０９の外部記憶装置上に格納されているベク
トルパターンデータを参照するために読み込む領域であ
る。２０５は前記システムが動作するための管理情報テ
ーブルを生成するための領域である。２０６は書体ベク
トルデータのキャッシュ領域である。

【００１３】図３は前記文字データを扱うシステムの構
成を表す図である。

【００１４】図３において、３０１，３０２，３０３
は、図１における外部記憶領域１０９に記憶されている
様々な書体データを表している。外部記憶装置１０９に
記憶される書体データの種類及びその数は実質的に制限
はない。

【００１５】３０４はシステム制御部を示し、図２にお
ける２０１，２０４，２０５が含まれる。３０５，３０
６は文字展開処理部、即ちラスタライザを示し、その文
字展開処理機能をソフトウェアのみで実現されていても
良く、ハードウェアによって実現されていても良く、ハ
ードウェアとソフトウェアの双方を用いても構わない。
また前記システム中に含まれるラスタライザの数は、少
なくとも１つ含まれていればその他の制限はない。３０
７はシステムに対して文字取得要求を発行するアプリケ
ーション部（例えばワードプロセッサ等のプログラム）
を表す。

【００１６】図３において、アプリケーション部３０７
は文字取得要求を発する。文字取得要求は、取得する文
字を確定するために、文字と１対１に対応した文字コー
ドと書体情報を用いて行う。要求された文字データを取
得するためにシステム制御部３０４は書体データ３０
１，３０２，３０３から必要なデータを獲得する。獲得
したデータがアウトラインフォントを構成する輪郭ベク
トルデータであれば、ラスタライザ３０５，３０６にデ
ータを転送する。また、獲得したデータがビットパター
ンデータであればそのままアプリケーション部３０７へ
それを転送する。ラスタライザ３０５，３０６では、受
け取った輪郭ベクトルデータをビットパターンへ展開
し、それをシステム制御部３０４へ送り返す。システム
制御部は３０４がラスタライザ３０５，３０６より受け
取ったビットパターンデータをアプリケーション部３０
７へ送り返す。

【００１７】次に、以上の説明を踏まえ、参考例１につ
いて詳細に説明する。

【００１８】本参考例１は書体データファイル分割し、
必要な部分のみをインストールすることで書体データの
獲得を可能とすることを目的としており、その分割方法
について、図４を用いて簡単に説明する。

【００１９】図４は分割ファイルの構成を簡単に表した
ものである。尚、説明を簡単にするため、書体Ａは文字
コード０〜６００で１つの書体を構成するものとする。

【００２０】この書体Ａを０〜１００のＡ１、１０１〜
１９９のＡ２、２００〜５００のＡ３、５０１〜６００
の４つの部分に分割したものとする。この書体Ａにおい
て、Ａ３部分は、一般的に使用されることのないデータ
であり、かつ最もディスクメモリを必要とする部分であ
る。

【００２１】これらの分割された書体情報を書体インス
トール時に示し、インストールすべき部分をユーザの手
（キーボード）によって選択させる。選択された結果、
必要とされる部分のみのインストールを行い、図５Ａに
示されるインストールされた結果の書体の内訳を記述し
た書体情報ファイル５００を外部記憶装置１０９上に作
成する。尚、図５Ｂにインストールされた書体ファイル
の結果状況を示す。

【００２２】システム立ち上げ時に、書体情報ファイル
５００より情報を読み取り、その書体情報ファイル内か
らインストールされた書体の内訳を示す情報を取り出
し、図６に示すような書体管理情報テーブルを書体情報
管理領域２０５上に作成する。

【００２３】書体管理情報テーブル作成の流れを図７を
用いて説明する。尚、同図は本システムに電源が投入さ
れた場合の初期処理中における書体に関する処理であ
り、そお処理手順は外部記憶装置１０９に格納されてい
る。

【００２４】先ず、ステップＳ７０２で書体情報ファイ
ルをオープンし、次のステップＳ７０３で、そのオープ
ンした書体情報ファイルより書体名の情報の獲得を行
い、書体名の情報を書体管理情報テーブルへ書き込む。

【００２５】ステップＳ７０４においては、書体情報フ
ァイルよりファイル名の獲得を行い、ファイル名の情報
を書体管理情報テーブルへ書き込む。そして、ステップ
Ｓ７０５においては、先に獲得した書体のファイル名を
元に、アクセス可能状態とするためのそのファイルオー
プン処理を行う。ステップＳ７０６においては、ステッ
プＳ７０５においてアクセス可能となった書体ファイル
より、そのファイルに格納されている書体データの開始
コード、終了コードに関する情報を読み取り、書体管理
情報テーブルへ書き込む。

【００２６】処理がステップＳ７０７においては、書体
情報ファイル内の記述に同一書体のファイルがまだ存在
するかを調べ、存在する場合にはステップＳ７０４に戻
り、次のファイル名の獲得とテーブルの更新処理を行
う。

【００２７】また、ステップＳ７０７で同一書体のファ
イルが存在しないと判断した場合には、ステップＳ７０
８へ進み、書体管理ファイル内に未処理の書体が存在す
るかを調べ、存在する場合はＳ７０３に戻って次の書体
に対する処理を行う。また、全ての書体に対するテーブ
ルの作成が完了したと判断したら、ステップＳ７０９に
進んで、先のステップＳ７０２においてオープン処理を
行った書体情報ファイルをクローズし、本処理を終え
る。

【００２８】以上の処理によって、書体情報管理領域２
０５には例えば図６に示すような書体管理情報テーブル
が作成されることになる。

【００２９】次に、図６の書体管理情報テーブルを用い
て、必要とする書体データを獲得するまでの流れを、図
８のフローチャートに従って説明する。

【００３０】ステップＳ８０１において、文字データ所
得処理を開始する。

【００３１】ステップＳ８０２においては、図３におけ
るＡＰ部３０７より取得する文字に関する情報（文字コ
ード，書体情報）を取得する。次のステップＳ８０３に
おいては、図６の書体管理情報テーブルの先頭の書体検
索し（初期段階ではポインタはテーブル中の先頭書体を
指し示している）、対応する書体であるかチェックを行
う。存在する場合はステップＳ８０４へ、存在しない場
合はステップＳ８０５へ進む。

【００３２】対応する書体でないと判断し、処理がステ
ップＳ８０５に進むと、他の書体が存在するかどうかを
判断し、他の書体があればそこにポインタを進める。

【００３３】また、対応する書体が捜し出せ、処理がス
テップＳ８０４に進むと、書体管理情報テーブル上に要
求された文字コードがその管理されている範囲内にある
かどうか、換言すればその文字コードが管理されている
かどうかを判断する。この時点でのポインタは図６の先
頭位置に置かれているので、要求された文字コードが
“０”から“１００”の範囲内であるかどうかを判断す
ることになる。

【００３４】さて、存在しないと判断された場合には、
ステップＳ８０６に進み、テーブル内の注目行の次の行
に同じ書体のファイルが管理されているかどうかを判断
する。もしあれば、ポインタを１つ進め、ステップＳ８
０４に戻る。また、次のファイルが存在しないと判断し
た場合には、文字無し処理を行う。

【００３５】一方、要求された書体の文字コードが管理
されていると判断した場合には、ステップＳ８０７に進
み、書体管理情報テーブル内の注目行からファイル名を
獲得し、ステップＳ８０８において、その獲得したファ
イル名を元に、そのファイルから書体データを獲得し、
終了処理Ｓ８１０へ進む。

【００３６】以上説明したように本参考例１によれば、
必要な書体の必要な文字コード範囲のみをシステムにイ
ンストールできるので、外部記憶装置１０９のメモリ消
費量を抑えることができると共に、不要な部分の管理は
行わないので処理速度を上げることも可能になる。

【００３７】＜実施例の説明＞ 上記参考例１では、例えば書体管理情報テーブルが図６
に示すようになっている場合、アプリケーション部から
書体Ａの文字コード“５０１”の文字所得要求があった
ときには、図８におけるステップＳ８０４、ステップＳ
８０６を３回ループすることになる。文字コード“５０
１”から“６００”までに対する文字所得要求の頻度が
全体の要求に対してさほど高くない場合には問題がない
が、その頻度が他の文字コードに対して多い場合には処
理速度の低下は避けられない。

【００３８】そこで本実施例では、文字所得要求の発生
頻度を計数し、次回の起動時の書体管理情報テーブル作
成に反映させるものである。

【００３９】尚、本実施例におけるシステム構成も図１
に示すものとする。これは後述する参考例２以降につい
ても同様である。また、本実施例では、書体データを外
部記憶装置１０９にインストールする場合に、図４に示
した全ての範囲の書体データＡ１〜Ａ４を指定した場合
を説明する。また、図８のフローチャートに係るプログ
ラムは当然のことながら外部記憶装置１０９に記憶され
ているものである。この点も後述する各参考例について
も同様である。

【００４０】図９は実施例において作成された書体管理
テーブルの初期状態を示している。参考例１の図６との
違いは、同一書体における個々のコード範囲のアクセス
回数を記憶保持する欄が設けられた点である。書体管理
情報テーブル自身を作成する手順は参考例１と同様であ
るので、ここでの説明は省略し、文字データ所得処理を
図１０に従って説明する。

【００４１】図１０のフローチャートと参考例１におけ
る図８との相違点は、ステップＳ８０７がステップＳ８
０７’となり、ステップＳ８１１が追加された点であ
る。

【００４２】図示において、書体管理テーブルはアプリ
ケーション部から文字データ所得要求があって、要求さ
れた文字データが管理テーブルで管理されている場合、
処理はステップＳ８０４からステップＳ８０７’に進む
のは同じである。ステップＳ８０７に処理が進むと、書
体管理情報テーブルからファイル名を獲得すると共に、
書体管理情報テーブルの該当するアクセス欄の数値を
“１”インクメントする。そして、ステップＳ８０８に
おいて、その獲得したファイル名を元に、そのファイル
から書体データを獲得し、終了処理Ｓ８１１へ進む。

【００４３】この結果、例えば書体管理情報テーブルは
図１１に示すようになる。

【００４４】ステップＳ８１１では、書体管理ファイル
内に記憶されている順序を、その時点での管理テーブル
内のアクセス回数で並べ変える処理を行い、本処理を終
える。

【００４５】例えば、書体管理情報テーブルが図１１に
示す状態にあった場合、書体Ａに関してはファイルのア
クセス回数がＡ４＞Ａ３＞Ａ２＞Ａ１であるので、書体
情報ファイルの中身は図１２に示すようにその順序が変
更される。

【００４６】装置起動時には、書体情報ファイルに記憶
された順序に従ってテーブルを作成するから、次回の起
動時の書体管理情報テーブルは図１３に示すようにな
る。すなわち、書体ＡにおけるファイルＡ４が一番最初
に位置することになり、文字データ所所得要求に対する
アクセス速度の向上が望める。

【００４７】尚、実施例では、文字データ所得要求が発
生する度に、書体情報ファイルを更新したが、システム
の電源断処理時に行うことで、処理速度をより高速化す
ることが可能になる。

【００４８】また、システム電源断処理において、各書
体を構成している部分ファイル（Ａ１〜Ａ４）のアクセ
ス回数も適当なファイルとして保存し、次回のシステム
起動時にそのファイルからアクセス回数を所得し、それ
でもってテーブル内の順序を決定するようにしても良
い。

【００４９】以上説明した様に本実施例によれば、アク
セス回数の多い文字コード範囲ほど優先して書体情報管
理テーブルの先頭に配置するので、文字パターン発生に
かかる全体のコストパフォーマンスを高めることが可能
になる。

【００５０】＜参考例２の説明＞ 次に参考例２を説明する。本参考例２では、複数の書体
のうちユーザが指定したコード範囲を他の書体で置き換
えるものである。

【００５１】図１４は本参考例２における分割ファイル
の構成を示している。先の参考例１における図４のそれ
と異なる点は複数の書体が分割されていることである。
尚、図示において、Ａ１〜Ａ３、Ｂ１〜Ｂ３及びＣ２は
それぞれファイル名を示している。

【００５２】本参考例２では、例えば書体Ａにおける文
字コード“１０１”〜“１９９”の範囲は書体Ｃのそれ
を従属させ、例えばアプリケーションから書体Ａの文字
コード１０１の文字データの要求が来たら、ファイルＣ
２（実は書体Ｃ）からデータを取り出し、処理するもの
である。

【００５３】これによれば、例えば、アルファベット、
数字、平かな、カタカナ、漢字等が１つの“書体名”を
使いながら、上記文字の種別毎に所望とする書体のパタ
ーンを発生することが可能になる。また、場合によって
は、例えば書体Ａ全体がアウトラインフォントで、書体
Ｃがドットパターンである場合には、特定の部分を高速
に処理することが可能にもなる。

【００５４】さて、本参考例２における書体情報ファイ
ルの内容例を図１５に示す。この書体情報ファイルの作
成は、ユーザが自由に作成しても良く、システムが自動
的に作成しても良い。或いは、上記参考例１で示したよ
うに、書体データを本システムにインストールする段階
で、ユーザに取捨選択させてもよい。

【００５５】図１５に示すように、書体ＡのファイルＡ
２の部分を書体Ｃの該当する部分に従属させるのであれ
ば、書体ＡにおけるファイルＡ２は外部記憶装置１０９
にインストールすることが不要になるので、外部記憶装
置１０９のメモリ消費量を抑えることもできる。更に、
ユーザが自分自身の書体を登録する場合にも、文字コー
ドのどの範囲をどの書体で使用するかを決定しさえすれ
ばよいので、実質的にユーザ書体で消費されるメモリ量
はその従属関係を示した書体情報ファイルのみになる。
尚、図１５に示すように、各書体はそれが従属している
のか否かを示す情報が付加されており、１つの書体では
文字コード範囲毎にそれが従属しているのか、その範囲
に従属するものがあればその書体は何かを示す情報が付
加されている。

【００５６】さて、図１５に示すような書体情報ファイ
ルがある場合に、本システムが起動すると、図１６に示
すような書体管理情報テーブルがＲＡＭ１０３の書体情
報管理領域上に作成される。

【００５７】この書体管理情報テーブルの作成に係る処
理を図１７のフローチャートに従って説明する。

【００５８】ステップＳ７５１において本処理が開始さ
れると、書体管理情報テーブルを作成するために書体情
報管理領域２０５に或程度の領域を確保する。そして、
ステップＳ７５２に進んで、外部記憶装置１０９に保存
されている書体情報ファイルをオープンし、次のステッ
プＳ７５３でそのオープンした書体情報ファイルから書
体情報を獲得する。

【００５９】ステップＳ７５４に処理が進むと、注目し
ている書体が従属書体かどうかを判断する、従属処理で
ある場合には、ステップＳ７５３に戻り、従属書体では
ないと判断したら、ステップＳ７５５に進む。

【００６０】ステップＳ７５５に処理が進むということ
は、１つの書体に対するテーブル作成開始を意味する。
従って、ここでは、その書体名を書体情報管理テーブル
に書き込み、以下に説明する処理でその書体に対する文
字コード範囲毎の従属関係を明確にしたテーブルを構築
していく。

【００６１】ステップＳ７５６では、オープンしている
書体情報ファイルから次の情報、すなわち、注目してい
る書体中のコード範囲に対する従属情報を取り出す。そ
して、ステップＳ７５７では、取りだした文字コード範
囲は従属されるのか否か、換言すれば、取りだした情報
中に従属情報があるかどうかを判断する。

【００６２】従属情報がなければ、ステップＳ７５８に
進み、注目している書体に固有のファイル名を、注目し
ているコード範囲に対応するよう書体情報管理テーブル
に書き込む。

【００６３】また、従属情報があれば、ステップＳ７５
９に進んで、その従属する書体の対応するファイル名を
取り出し、それを書体情報管理テーブルに書き込む。

【００６４】いずれの場合でも、処理はステップＳ７６
０に進み、ステップＳ７５８或いは７５９で獲得された
ファイル名を基に、そのファイルをオープンしアクセス
可能にする。そして、次のステップＳ７６１において、
アクセス可能となって書体ファイルより、そのファイル
に格納されている書体データの開始コード及び終了コー
ドに関する情報を読み取り、それを書体情報管理テーブ
ルに書き込む。

【００６５】ステップＳ７６２に処理が進むと、１つの
書体に対する処理が終了したかどうかを判断し、終了し
ていないと判断したらステップＳ７５６に戻って上記処
理を行う。

【００６６】また、１つの書体に対する全コード範囲に
対する処理が終了したと判断した場合には、ステップＳ
７６３に進み、次に処理すべき書体があるかどうかを判
断する。処理すべき書体が残っていたら、処理はステッ
プＳ７５３に戻り、処理すべき書体が無かったらステッ
プＳ７６４に進む。

【００６７】ステップＳ７６４に処理が進んだ場合に
は、オープンしている書体情報ファイルをクローズし、
ステップＳ７６５で本処理を終了する。

【００６８】以上の結果、例えば図１５に示すような書
体情報ファイルがあった場合には、図１６に示すような
書体情報管理テーブルが作成されることになる。

【００６９】尚、こうして作成された書体情報管理テー
ブルを使用して書体データを獲得するときの処理は、先
に説明した参考例１と同様である。すなわち、アプリケ
ーション部から書体Ａの文字コード“１０１”の書体デ
ータ獲得要求があったら、そのテーブルを調べ、書体Ａ
に対する文字コード“１０１”はファイル名Ｃ２である
ことが検出されるので、そのファイルＣ２から対応する
書体データを取り出し、文字パターンを発生する。この
書体データがアウトラインデータである場合には、ラス
タライザ３０５に一旦渡してドットパターンを発生さ
せ、それをアプリケーションに渡すことになる。

【００７０】以上説明したように本参考例２によれば、
或る１つの書体の所望とするコード範囲を別の書体のデ
ータを置き換えることにより、例えば英文や日本語の混
じり合った文章を作成する場合等においては、いちいち
書体を切り替えなくともそれぞれにユーザの意志が反映
された書体での文字入力が行えるようになる。

【００７１】しかも、インストール時に、或いは任意の
時間に、他の書体のデータを従属するよう指示されたコ
ード範囲にもともとあった書体データは実質的に不要に
なり、その部分をインストール対象から外したり、削除
することが可能になるので、外部記憶装置１０９のメモ
リ消費量を抑えることが可能になる。

【００７２】＜参考例３の説明＞参考例３ を以下に説明する。通常、システムに書体デー
タをインストールする場合、１つの書体全体を１つの論
理記憶デバイスに記憶することが必須である。本参考例
３は、１つの所定の記憶先を論理的に異なるデバイスに
記憶することを可能にする。これによって、例えば各論
理デバイスが１書体全部を記憶するだけの空き容量を有
さない、或いは、各論理デバイスに或る程度の空きよう
量を設けたいというような要求に応えるものである。

【００７３】尚、ここで言う、論理記憶デバイスとは、
物理的装置をも含む概念であり、例えば１つの物理的な
記憶装置を論理的に複数の論理的な装置として区切られ
た場合、或いは同じ物理的装置であってもパスが異なる
ものをも含む概念である。

【００７４】本参考例３における書体情報ファイルの例
を図１８に示す。尚、図示では説明を簡単にするため
に、１つの書体に対してのみ示した。図示において、Ａ
１〜Ａ４は上記参考例１、実施例、参考例２で説明した
ようにコード範囲に対応する書体Ａのファイル名であ
る。

【００７５】図示について簡単に説明すると、書体Ａに
対する或るコード範囲の書体データは、ファイルＡ１と
して論理ドライブＡに記憶されていることを示してい
る。

【００７６】さて、本参考例３では、かかる書体情報テ
ーブルをシステム起動時に取り出し、その中に記述され
たデータに基づいて図１９に示すような書体情報管理テ
ーブルを作成する。

【００７７】参考例３における書体情報ファイル及びそ
れに基づいて作成される書体情報管理テーブルのフォー
マットは、参考例１の図５Ａ及び図６に示したフォーマ
ットに対して記憶先のドライブ名が記載されている点の
みが異なる。当業者であれば、先に説明した参考例１の
かかる処理内容及び図１８に示した書体情報ファイルの
構造に間がみれば容易に推察されるであろう。従って、
ここではその説明は省略する。

【００７８】ただし、本参考例３では、インストールす
る時点で書体データを構成する個々のコード範囲のファ
イルの記憶先を指示するものとして説明したが、勿論、
一旦全てを同一記憶ドライブに記憶させ、その後、、必
要に応じて適当なコード範囲の書体データを別な記憶装
置（例えばより高速な外部記憶装置）に移動させてもよ
い。

【００７９】以上説明したように本参考例３によれば、
１つの書体データが１つの論理デバイスの同じ位置にあ
る必要はなく、所望とするデバイスに記憶できるので、
外部記憶装置を有効に活用することが可能になる。

【００８０】＜参考例４の説明＞ 次に参考例４を説明する。例えば、ある特定範囲の文字
のデザインを使用する場合であっても、そのデザインの
書体の全範囲の書体データを記憶する必要があるため、
外部記憶装置等のメモリ消費量は無視できない。本参考
例４では、かかる課題を一掃する。

【００８１】図２０は分割ファイルの構成を簡単に示し
ている。図示において、書体Ａは、文字コード０〜５０
０で１つの文字書体全体を構成していることを示してお
り、０〜１００のＡ１、１０１〜１９９のＡ２、２００
〜５００のＡ３の３つ部分的なコード範囲として管理し
ている。書体Ａ’は書体Ａと同じもので、対応するキャ
ラクタセットが異なり、キャラクタセットの切り替え時
に変更しなければならない文字データ部分のみを持ち、
含まれる文字コードは１０１〜１９９のＡ２と同一であ
る。つまり、書体として、Ａ’はＡと同じであるが、使
用する文字コードは１０１〜１９９のみである。

【００８２】

【００８３】上記書体管理を行うため、本参考例４にお
ける書体情報ファイルは図２１に示すように、書体ファ
イルとキャラクタセットの関連が記述されている。

【００８４】システム起動時におけるＲＡＭ１０３中の
書体管理情報領域２０５に構築される書体管理情報テー
ブルの作成手順は、図７に示される手順で行われるの
で、ここでの説明は割愛する。この結果、図２２に示さ
れる書体管理情報テーブルが構築される。テーブル中、
Ａ１、Ａ２、Ａ３及びＡ２’はそれぞれ書体データＡ，
Ａ’を構築するデータのファイル名称である。

【００８５】尚、このようにして作成された書体管理情
報テーブルを用いて文字データ所得の流れも、図８に示
した手順で行われるが、説明すれば以下の通りである。

【００８６】先ず、ステップＳ８０１において、文字デ
ータ所得処理を開始する。

【００８７】ステップＳ８０２においては、図３におけ
るＡＰ部３０７より取得する文字に関する情報（文字コ
ード，書体情報、キャラクタセット）を取得する。次の
ステップＳ８０３においては、図６の書体管理情報テー
ブルを検索し、対応する書体及びキャラクタセットが存
在するかチェックを行う。存在する場合はステップＳ８
０４へ、存在しない場合はステップＳ８０５へ進む。

【００８８】ステップＳ８０５では、図２２に示される
書体管理情報テーブル上に別の書体がまだ存在するかど
うかを判断する。存在する場合にはステップＳ８０３に
進み、、テーブル中の別の書体に対するチェックを行
う。

【００８９】また、要求された書体がテーブル中に存在
すると判断し、ステップＳ８０４に進むと、注目書体中
の注目キャラクタセットの開始コード及び終了コード内
に、要求されたコードが含まれているかどうかを判断す
る。尚、コード範囲は、存在しないファイルに関して
は、開始コード及び終了コードともに“−１”が格納さ
れているものとしているので、そのコードの文字データ
が管理されているかどうかは容易に判断できる。

【００９０】さて、ステップＳ８０４において、要求さ
れた文字コードが注目しているキャラクタセットの範囲
外にあると判断された場合には、ステップＳ８０６に進
んで、同一書体に未だチェックしていないキャラクタセ
ットがあるかどうかを判断する。もしあればステップＳ
８０４に戻り、再び要求コードに対応するキャラクタセ
ットが存在するかどうかを判断する。また、ない場合に
は、ステップＳ８０９に進んで、文字無し処理を行う。

【００９１】一方、要求された文字の書体とその文字コ
ードを管理しているキャラクタセットが存在すると判断
した場合には、ステップＳ８０７に進み、書体管理情報
テーブルからファイル名を獲得し、ステップＳ８０６で
そのファイル名のファイルから該当する文字データを所
得する。そして、ステップＳ８１０に進んで、処理を終
了する。

【００９２】以上説明したように本参考例４によれば、
同じ書体であっても異なるキャラクタセットの文字が指
定された場合であっても、使用する文字のみを含むコー
ド範囲の書体データを有するだけで良く、全文字コード
に対応するデータは不要になり、外部記憶装置の記憶領
域を有効に活用することができる。

【００９３】＜参考例５の説明＞ 上記参考例４では、例えば書体Ａと同じ書体Ａ’を使い
ながらも、異なるキャラクタセットを使用する場合に、
その使用する文字コード範囲の書体データのみを外部記
憶装置に記憶させることで、メモリの有効利用を図るも
のであった。

【００９４】本参考例５では、異なる書体を記憶し、一
方の書体中の特定のコード範囲の書体データとして、他
方の書体の同じ範囲の書体データを活用する例である。
この結果、共通して使用する部分の書体データを重複し
て持つ必要を無くし、メモリの効率的使用を可能とする
ものである。

【００９５】図２３は本参考例５における分割ファイル
の構成を簡単に示している。図示において、書体Ａは、
文字コード０〜５００で１つの文字書体全体を構成して
いることを示しており、０〜１００のＡ１、１０１〜１
９９のＡ２、２００〜５００のＡ３の３つ部分的なコー
ド範囲として管理している。

【００９６】また、書体Ｂも書体Ａと同様、全文字コー
ド空間を３つ分割されて管理されており、このうち、文
字コード０〜１００と、２００〜５００は書体Ｂ特有の
書体データを使用し、コード１０１〜１９９については
書体Ａのものを使用する。

【００９７】上記書体管理を行うため、本参考例４にお
ける書体情報ファイルは図２４に示すように、書体の種
類とその書体を構築する分割書体データファイル名で構
成されている。

【００９８】システム起動時におけるＲＡＭ１０３中の
書体管理情報領域２０５に構築される書体管理情報テー
ブルの作成手順は、図７に示される手順で行われるの
で、ここでの説明は割愛するが、いずれにしても図２５
に示される書体管理情報テーブルがＲＡＭ１０３中の書
体情報管理領域２０５中に構築される。

【００９９】文字データ所得処理も、図８に示したフロ
ーチャートに従えば良い。すなわち、ＡＰ部から文字デ
ータ所得要求があった場合には、その要求のなかで指定
された書体データに基づいて書体情報管理テーブルのど
の書体が選択されたのかを判断し、次にその書体中の指
定された文字コードを管理しているファイル名を所得
し、その後、そのファイルから対応する文字データを所
得する。

【０１００】＜参考例６の説明＞ これまで、書体データを判別する場合、書体を表す書体
名或いは書体番号、叉は、書体名及び書体番号、また
は、必要によるスタイル情報、幅情報、ウエート情報を
別々に用いて判別していたため、その判別処理は複雑に
ならざるを得ず、時間がかかるという問題があった。

【０１０１】そこで、本参考例６では、かかる判別を簡
単にしかも高速に行うことを可能にする例を説明する。

【０１０２】図２６は、本参考例６におけるスタイル幅
ウエート情報のフォーマットを示している。図示の如
く、スタイル情報として４ビット（値として０〜１
５）、幅情報として４ビット、ウエート情報として８ビ
ット（０〜２５５）が割り当てられている。スタイル情
報としては、“０”はregular、“１”はitalic、…と
して定義した。また、幅情報としては、extra condenc
e, condence, regular, expand, extra expandに４，
６，８，１０，１２を対応させている。そして、ウエー
ト情報としては、特細、極細、細、中細、中、中太、
太、極太、特太に、６０，７０，８０，９０，１００，
１１０，１２０，１３０，１４０を対応させた。

【０１０３】さて、本参考例におけるインストール手順
（外部記憶装置１０９のフロッピーディスクからハード
ディスクへのインストール）を図２７のフローチャート
に従って説明する。

【０１０４】先ず、ステップＳ３０１において、インス
トールする書体データとインストールに必要なデータ
（インストールデータファイル）が格納されているメデ
ィアを設定するよう要求し、そのメディアの指定をユー
ザに行わせる。

【０１０５】次に、ステップＳ３０２に進んで、インス
トールする書体データが格納されているインストールデ
ータファイルから書体名情報、書体番号、スタイルウエ
ート情報を読出す。

【０１０６】ステップＳ３０３では、インストール先に
既にインストールされている書体情報ファイル内の書体
データを読み込む。このとき、読み込むべき書体情報フ
ァイルがインストール先に存在しないとステップＳ３０
４で判断したら、その書体ファイルの作成を行う（ステ
ップＳ３０５）。

【０１０７】次に、処理はステップＳ３０６に進んで、
インストール先の書体情報ファイルの内容とインストー
ルしようとしている書体情報とを比較する。比較処理の
優先順位は、第１に書体番号、第２にスタイル幅ウエー
ト情報、第３の書体名とする。以上の項目が全て同じ場
合には無条件で同じ書体である。また、第１番目の項目
と第２番目の項目の内容が同じである場合、書体の文字
データが同じである為、書体の内容が重ならないように
する処理と、書体名を含めてユニークに処理するかをこ
の処理で確定する（例えば、ユーザに指示するようにす
る）。

【０１０８】さて、処理がステップＳ３０７に進むと、
本インストール処理によりインストールしようとしてい
る書体データは更新か新規追加であるかを判断する。更
新処理とは、先に説明したように３つの項目が全て同じ
場合である。

【０１０９】更新処理であると判断した場合には、ステ
ップＳ３０９に進んで、既にインストールされている書
体データに上書きするため、書体情報ファイルに記述さ
れている同じ書体の存在位置に上書きする。このとき、
ユーザによってインストール先が別個に指示されていれ
ば、その指示された位置に書き込む処理を行う。

【０１１０】また、新規書体インストールであると判断
した場合には、ステップＳ３０８に進んで、書体名、書
体番号、スタイル幅ウエート情報、タグファイル名、書
体情報全てをインストールする。

【０１１１】そして最後に本処理を終了し、呼び出し元
に戻る。

【０１１２】図２８はインストールメディアの内容と、
その中のインストールデータファイルの中身を示してい
る。

【０１１３】インストールデータファイルには、インス
トールに必要な情報が記述されている。書体ファイルに
は、書体情報が格納されている。タグファイルには、書
体ファイルの情報より書体を作成するためのデータが格
納されている。従って、１つの書体データから複数のタ
グファイルを用いてタグファイル分の書体が存在すると
考えられる。

【０１１４】図２９は、本参考例における書体情報ファ
イルの内容の一例を示している。“NAME”はディスクリ
プション名、書体情報（主書体番号、副書体番号、スタ
イル幅ウエート情報）である。“DEFTAG”はタグファイ
ル名、タグファイルに存在する書体名である。また、
“FILE”は書体ディスクのインストール先と書体ファイ
ルのファイル名である。

【０１１５】図３０はタグファイルの内容例を示してい
る。このファイルには、タグファイルのサイズ、書体番
号、スタイル幅ウエート情報、ディスクリプション名、
書体メトリクス情報に、フェィス名を格納する。この中
の書体番号、スタイルウェート情報より書体データへの
関連ずけを行う。

【０１１６】図３１は、書体ファイルの内容を示してい
る。このファイルには、書体構成情報（ファイルサイ
ズ）、書体データ（書体開始コード、文字数）、書体番
号、スタイル幅ウェート情報が格納される。

【０１１７】以上の如く本参考例６によれば、インスト
ール後は、書体情報のスタイル情報、幅情報、ウェート
情報を合わせたスタイル幅ウェートを書体を表す情報と
して持つことで、書体名、書体番号等を比較するよりも
簡単に高速に書体の判別が可能になる。

【０１１８】＜参考例７の説明＞参考例７ を説明する。本参考例７では、フォント関連の
ファイル名の最適化を行わせる原理を説明する。例とし
て、本参考例におけるシステム（或いはＯＳ）が管理す
るファイル名は８文字（８バイト）、拡張子が３文字
（３バイト）である例を説明する。

【０１１９】図３２は本参考例７における書体物理ファ
イルのファイル名称に用いる文字構造を示している。

【０１２０】図示において、は図３４に示す書体識別
用の２文字が位置し、には図３６で示されるスタイル
幅情報（０〜９）を表す１個の数字が位置する。には
図３７に示されるウェイト情報を表す数字が位置し、
には図３８で示されるサイズ・サポート領域情報であ
る。はファイル識別情報であり、参考例では文字列
“ＪＦＤ”を用いる。

【０１２１】また、図３３は、書体データの書体論理デ
ータファイルのファイル名の構造を示している。は書
体管理情報であり、任意の３文字を用いて表す。は本
ファイルのリリースの順番を示しており、図３５により
当てはめる。は図３７に示すウェイト情報である。
はメトリクス情報識別情報であある。本項目は本ファイ
ルのリリースの順番を示す。また、プリンタフォントと
同一な情報を持つ場合は、“Ｐ”で表す。はファイル
識別情報であり、この場合は“ＦＯＮ”を使用する。

【０１２２】以下、図３４から図３８について更に詳し
く説明する。

【０１２３】図３４は物理書体の識別情報である。ＭＩ
は明朝体、ＧＯはゴシック体、ＲＧは丸ゴシック体、Ｋ
Ａは楷書体、ＫＹは教科書体を表す。図３５におけるＭ
ＩＮは明朝体、ＧＯＴはゴシック体、ＲＧＯは丸ゴシッ
ク体、ＫＡＩは楷書体、ＫＹＯは教科書体をそれぞれ表
している。

【０１２４】図３６はスタイル幅情報を示している。ス
タイルとしては、regularとitalicの２種類があり、幅
情報としてはextra condence, condence, regular, exp
and,extra expandがある。この組み合わせによって、例
えば図示の如く、regularとextra condenceの場合に
“１”を割り当てた。同様に、regularとcondenceに
“１”、regularとregularに“２”、regularとexpand
に“３”、regularとextraexpandに４を割り当てた。ま
た、italicrとextra condenceの場合に“５”を割り当
て、italicとcondenceに“６”、italicとregularに
“７”、italicとexpandに“８”、italicとextra expa
ndに“９”を割り当てた。

【０１２５】図３７はウェイト情報を示し、参考例で
は、特細、極細、細、中細、中、中太、太、極太、特太
に、数字１〜９を割り当てた。

【０１２６】図３８は参考例におけるサイズ・サポート
領域情報である。本データの上位８ビットを用いてサイ
ズデータを１６進数で表す（文字でいうと“１”から
“Ｆ”）。尚、アウトラインデータ等のスケーラブル書
体データである場合には数字“０”を用いる。また、下
位８ビットに各領域を割り当て、対応する領域である場
合にはそのビットを“１”にする。参考例ではビット７
を非漢字領域、ビット６を第１水準領域、ビット５を第
２水準領域、ビット４を旧ＪＩＳ領域、ビット３をかな
領域、ビット２を応分領域、ビット１を外字領域、そし
てビット０を特殊領域とした。

【０１２７】以上によりファイル名称を決定する。以
下、書体情報とその書体情報による決定例を示す。

【０１２８】書体情報｛１．書体名：明朝体、２．スタ
イル名：regular、３．文字幅情報：condence、４．文
字ウェイト情報：中、５．文字サイズ：１００ドット、
６．サポート領域、第１水準、７．メトリクス情報識別
情報：プリンタフォントと同一なメトリクス情報である
ため“Ｐ”、８拡張子によるファイル分類：ＪＦＤ（書
体物理データファイル）とＦＯＮ（書体論理データファ
イル）、９：書体管理環境名称：ＦｏｎｔＭａｎａｇｉ
ｎｇ｝により決定する。

【０１２９】この場合、書体物理データファイルの名称
を決定するためには、図３２で示されるは“ＪＦＤ”
になる。は図３４によって“ＭＩ”になる。または
図３６により“１”、は図３７により“５”になる。
サイズ１００は１６進数で表すと、６４Ｈであり、図３
８に従ってビット６のみを立てるから下位８ビットは４
０Ｈ、従って、は“６４４０”になる。

【０１３０】つまり、ファイル名“ＭＩ１５６４４０．
ＪＦＤ”である。

【０１３１】次に、書体論理データファイルの場合に
は、拡張子は“ＦＯＮ”、はＦｏｎｔＭａｎａｇｅ
ｒを表すことに統一するので、“ＦＯ＿、は図３５よ
り“ＭＩＮ”、は図３７により“５”、は“Ｐ”で
ある。

【０１３２】従って、この書体論理データファイルの名
称は“ＦＭ＿ＭＩＮ５Ｐ．ＦＯＮ”である。

【０１３３】以上説明したように本参考例７によれば、
書体ファイル名称にファイルに格納されているデータを
示す情報を表示したことにより、書体ファイルに格納さ
れている情報が解り易くすることができる。

【０１３４】＜参考例８の説明＞参考例８ について説明する。

【０１３５】通常、文字パターン発生には、先に説明し
たようにビットマップパターンを予め記憶しておき、そ
れを所得するビットマップフォント方式と、アウトライ
ンデータに基づいて文字の輪郭を形成し、その内部を埋
めることで文字パターンを得るアウトラインフォント方
式がある。

【０１３６】前者は、比較的小さい文字（ドット構成の
小さい文字）に対して有効な方式であり、文字が潰れる
ことなく、且つ、生成するにしても基本となる文字パタ
ーンに対して間引きすれば済むので、高速に処理するこ
とが可能である。後者は、ラスタライザによって輪郭を
描画し、その内部を埋める処理が必要なため、速度は落
ちるが、大きい文字（最終的なドット構成の大きい文
字）の品位を高めることができる。

【０１３７】ところが、比較的小さい文字を発生するの
に適したビットマップフォント方式では、比較的高い確
率で要求される文字パターンも、低い確率の文字パター
ンも、基本となる文字パターンから一律な処理でもって
行っており、まだ改善の余地が残っている。

【０１３８】本参考例８では、ビットマップフォントに
よる発生方式を更に改善させるものである。

【０１３９】さて、本参考例８では、２０×２０のドッ
トのビットマップフォントがリソースされ、それから４
×４〜２０×２０の文字パターンを発生する例について
説明する。

【０１４０】図３９は参考例におけるビットマップフォ
ントによる文字パターン発生処理の手順を示したフロー
チャートである。

【０１４１】先ず、ステップＳ１で、要求された文字の
コードおよび文字のサイズを所得する。そして、ステッ
プＳ２においては、その要求された文字コードの文字パ
ターン（２０×２０ドット）をＲＯＭ１０２或いは外部
記憶装置１０９より取り出し、ＲＡＭ１０３中の所定エ
リアに展開する。

【０１４２】ステップＳ３では、１回の処理でデフォル
メせずに縮小可能な縦方向のライン数の算出する。要求
された文字サイズが先に獲得した文字サイズ（２０×２
０）の半分以下の場合には、文字パターンの半分まで、
それ以外の場合には、（縮小前の文字サイズ＋２）／５
により求める。この式は、２０×２０ドット以下の文字
パターンに限定した場合、１回の縮小するライン数を４
ライン以下にすることにより、デフォルメ（偏り）を防
止することを主眼にした式である。

【０１４３】ステップＳ４に処理が進むと、実際の縮小
処理を行う。ここでは、ステップＳ３で求められたライ
ン分の縮小処理を行う。このとき、縮小処理を行う位置
は、文字パターンの幅／（縮小ライン数＋１）により求
められた等分割位置である。ここで縮小ライン数＝２の
ときは、分母が奇数になるため、正しく等分割できずデ
フォルメする可能性がある（図４０参照）。従って２回
目の縮小時に前記縮小位置の計算より発生した残りの分
だけ位置をずらす補正処理を行う。これを示したのが図
４１である。また、縮小ライン数＝４の場合も、分母が
奇数となるが、縮小前の文字パターンが２０×２０ドッ
ト以下の場合は問題にならないため特に処理は行わな
い。算出された縦方向のラインでは、その右隣のライン
と重ね合わせ（論理和）処理する、案源すれば縮小する
ラインの位置とその右隣のラインの２ラインで１ライン
のドットパターンを生成する。

【０１４４】ステップＳ５では、縮小した結果が、要求
されたサイズになったか判定し、全縮小ライン数とステ
ップＳ４で縮小したライン数の差分により判定する。判
定の結果、要求されたサイズに満たない場合には、ステ
ップＳ３に戻り、縮小処理を繰り返すことになる。ま
た、要求された文字パターンの作成が完了した場合に
は、ステップＳ６で要求元に発生した文字パターンを出
力する。

【０１４５】尚、上記説明で、１回の縮小処理における
縮小するライン数を４以下に抑えるという意味は、例え
ば、２０×２０の基本サイズから１２×１２のパターン
を発生する場合（最終的には８ライン（＝２０−１２）
が縮小される）、第１回目において、８ライン全部を縮
小するのではなく、第１回目で４ライン分を縮小し、そ
の後で更に４ライン分を縮小することを意味する。因
に、先に説明したように２ライン分縮小する場合、すな
わち、１８ラインの文字パターンを発生する場合には、
その縮小ライン数が４以下であるので問題はないことに
なる。但し、先に説明した補正処理は行う。

【０１４６】また、本参考例８では、横方向に縮小する
例を説明したが、縦縦方向への縮小も全く同様に処理す
ることができ、更には縦横共に処理することもできるの
で、上記内容で本発明が限定されるものではない。

【０１４７】また、使用するビットマップは２０×２０
に限定されるものではなく、各々のサイズにおいて縮小
する際に効率良く処理が行えるならば、特に１つに限定
されるものではない。

【０１４８】また、予め２０×２０、１６×１６、１３
×１３、１０×１０等の「（縮小前の文字サイズ＋２）
／５」の１回の処理で所得し得る最小サイズの複数ビッ
トマップフォントを用意し、ステップＳ３〜Ｓ５のルー
プ数を減らし、且つ、品位の向上に役立てても良い。

【０１４９】以上説明したように本参考例８によれば、
要求された文字パターンのサイズが本文作成等で最も使
用される可能性の高いサイズ（４×４〜２０×２０）の
みビットマップフォントを使用し、縮小を行う位置等の
計算を限定されたサイズに最も有効となるように単純化
することにより、パフォーマンスの良い文字パターン縮
小が行える。

【０１５０】＜参考例９の説明＞ 本参考例９の実施例について説明する。

【０１５１】上記参考例（例えば参考例７）では、ファ
イル名をそのファイルが有すデータを反映させた。従っ
て、書体を提供する側が、過去に供給した名称とは異な
る名称を新たに提供する場合には異なるファイル名を付
けるように管理すれば良い。但し、システムのユーザが
書体を作成できるようにした場合、供給側ではそのユー
ザが使用しているファイル名までは管理できない。従っ
て、同じ情報を有する書体が作成される場合があり、一
旦同じ情報を含む書体を削除した後に作成した書体の複
写を行ったり、同じ情報の該当する書体情報を変更した
後に複写を行わねばならない。

【０１５２】本参考例９では、かかる問題を解決する。

【０１５３】図４２は、参考例における書体情報ファイ
ルに付けられるファイル名の一例を示している。図示の
如く、本参考例９においては、ファイル名の部分に８文
字（８バイト）と、拡張子に３文字（３バイト）を使用
している。本参考例では、“ＦＧ＿ＵＳ”は固定のもの
とし、その後に示した□には書体番号と同じ値が付けら
れる。但し、ファイル名の付け方はこれに限るものでは
ない。

【０１５４】図４３は書体情報ファイルの内部構造を示
している。この書体情報ファイル内には図示の符号１４
で示される書体名、符号１５で示される書体番号が格納
されている。また、この他には例えば、作成日時やバー
ジョン等の情報も格納されている。

【０１５５】図４４は外部記憶装置１０９に記憶されて
いる書体の格納先を管理する書体格納情報ファイルの構
造を示しており、記憶されている全書体についての情報
が入っている。この書体格納情報ファイルには、符号１
６で示される書体１の登録番号、符号１７の書体１の書
体情報ファイル名、１８の書体１の書体名、１９の書体
１の書体番号である。同様に書体２、… 書体ｎそれぞ
れに対しても同様な情報が格納されている。

【０１５６】図４５のフローチャートに基づいて本参考
例９における書体管理手順を説明する。

【０１５７】先ず、ステップＳ５０１において、複写元
の書体情報ファイル（ユーザが作成した書体データを管
理している書体情報ファイル、４３参照）から書体情報
を所得する。次にステップＳ５０２に進んで、システム
の管理下におかれている書体の格納情報ファイル（図４
４参照）から格納されている書体に関する書体情報を所
得する。

【０１５８】ステップＳ５０３においては、先のステッ
プＳ５０１、Ｓ５０２で所得した情報から、同じ書体名
の書体が格納されているかどうかを判断する。同じ書体
名の書体が既に書体格納情報ファイル内に格納されてい
ると判断した場合にはステップＳ５０４に、その書体名
の書体がシステムに登録されていないと判断した場合に
はステップＳ５０７に進む。

【０１５９】ここで同じ書体名がシステムに登録されて
いないと判断され、ステップＳ５０７に進むと、ユーザ
が作成した書体の書体番号と同じ書体番号がシステムに
登録されているかどうかを判断する。ここでも、同じ書
体がないと判断したら、処理はステップＳ５１２、Ｓ５
１３に進み、システムに登録されている書体情報を記憶
している書体格納情報ファイルに、ユーザが作成した書
体情報ファイルの内容を複写（追加）し、その書体格納
情報ファイルを更新する。

【０１６０】一方、ステップＳ５０３で、同じ書体名の
書体が既に登録されていると判断した場合には、ステッ
プＳ５０４に進んで、それれが同じ書体番号であるかど
うかを判断する。

【０１６１】同じ書体番号である、すなわち、書体名及
び書体番号の両方とも既にシステムに登録されていると
判断した場合には、ステップＳ５０５、Ｓ５０６に進ん
で、書体格納情報ファイル内の該当する位置にユーザが
作成した書体情報ファイルの内容で上書きし、書体格納
情報ファイルを更新する。

【０１６２】ステップＳ５０７で“ＹＥＳ”であると判
断した場合、すなわち、同じ書体名ではないが、同じ書
体番号であると判断した場合には、ステップＳ５０８に
進んで、新たに登録しようとしている書体の使用されて
いない書体番号を検出し、ステップＳ５０９に進む。

【０１６３】ステップＳ５０４の判断が“ＮＯ”、つま
り、同じ書体名が存在するが、書体番号が異なると判断
した場合にもステップＳ５０９に処理が進む。この場合
には、書体番号が重複することはないことになる。

【０１６４】いずれにせよ、ステップＳ５０９に処理が
くるということは、書体名が同じで、書体番号が異なる
場合である。ユーザ側から見て書体名が重要で、同じ書
体名が複数あると混乱の素になる。そこで、ステップＳ
５０９、Ｓ５１０、Ｓ５１１では、登録しようとしてい
る書体名のファイルを変更（例えば書体名に“USR”を
付加する等）し、その変更された書体名を書体格納情報
ファイルに追加し、且つ、その書体番号で登録すること
で、書体格納情報ファイルを更新する。

【０１６５】上記例では、書体名をキー情報として書体
の登録状態を判別し書体番号を書体情報ファイルのファ
イル名と対応させ、書体番号を変更して複写を行うこと
より、同じ書体情報が含まれる書体を管理することが可
能になる。また、本発明はユーザに書体を作成できるよ
うなツールを提供し、前記ツールによる作成された書体
を使用するとき等に多大な効果を発揮する。

【０１６６】尚、上記参考例では、書体名をキーにして
書体情報を検索し、書体番号を変更するようにしたが、
書体番号をキーにして検索し、書体名を変更するように
しても良く、検索に用いるキー情報及び変更する書体情
報はこの限りではない。

【０１６７】以上説明した様に本参考例９によれば、書
体情報と書体情報ファイルのファイル名を対応させ、同
じ書体情報が含まれる書体が検出されたときには、書体
情報を変更して複写（登録）を行うようにしたことによ
り、同じ書体情報が含まれた場合であっても書体を管理
することが可能になる。

【０１６８】また、ユーザが書体を作成できるような場
合に、同じ情報を有する書体が作成された場合でも、一
旦同じ情報を含む書体を削除した後に作成した書体を複
写を行ったり、同じ情報に該当する書体情報を変更した
後に複写を行ったりする作業の軽減を図ることが可能に
なる。

【０１６９】上記参考例１、実施例、参考例２〜参考例
９に限らず、本発明は、複数の機器から構成されるシス
テムに適用しても、１つの機器から成る装置に適用して
も良い。また、本発明はシステム或は装置にプログラム
を供給することによって達成される場合にも適用できる
ことは言うまでもない。

【０１７０】

【発明の効果】以上説明したように本発明によれば、柔
軟性のある書体データの管理方法を提供することが可能
になる。

【０１７１】

【図面の簡単な説明】

【図１】実施例におけるシステム構成図である。

【図２】実施例におけるＲＡＭのメモリマップである。

【図３】文字処理装置の構成例を示す図である。

【図４】参考例１における分割ファイルの構成例を表す
図である。

【図５Ａ】参考例１における書体情報ファイルの内容の
一例を示す図である。

【図５Ｂ】参考例１におけるインストール後の書体ファ
イルの構成例を示す図である。

【図６】参考例１における書体管理情報テーブルの内容
例を示す図である。

【図７】参考例１における書体管理情報テーブル作成処
理の手順を示すフローチャートである。

【図８】参考例１における文字データ取得処理の流れを
示すフローチャートである。

【図９】実施例における書体管理情報テーブルの初期状
態例を示す図である。

【図１０】実施例における文字データ所得処理の流れを
示すフローチャートである。

【図１１】実施例における書体管理情報テーブルの中間
的な状態例を示す図である。

【図１２】実施例で更新された書体情報ファイルの内容
例を示す図である。

【図１３】実施例における更新された書体情報ファイル
の内容で起動した場合の書体管理情報テーブルの状態例
を示す図である。

【図１４】参考例２における分割書体ファイルの構成例
を示す図である。

【図１５】参考例２における書体情報ファイルの内容例
を示す図である。

【図１６】参考例２における書体管理情報テーブルの内
容例を示す図である。

【図１７】参考例２における書体管理情報テーブルの作
成処理の流れを示すフローチャートである。

【図１８】参考例３における書体情報ファイルの内容例
を示す図である。

【図１９】参考例３における書体管理情報テーブルの内
容例を示す図である。

【図２０】参考例４における分割ファイルの構成例を示
す図である。

【図２１】参考例４における書体ファイルの内容例を示
す図である。

【図２２】参考例４における書体管理情報テーブルの内
容例を示す図である。

【図２３】参考例５における分割書体ファイルの構例成
を示す図である。

【図２４】参考例５における書体情報ファイルの内容例
を示す図である。

【図２５】参考例５における書体管理情報テーブルの内
容例を示す図である。

【図２６】参考例６におけるスタイル幅ウエート情報の
フォーマットを示す図である。

【図２７】参考例６における書体インストール手順を示
すフローチャートである。

【図２８】参考例６におけるインストールメディアの内
容と、その中のインストールデータファイルの中身を示
す図である。

【図２９】参考例６における書体情報ファイルの内容例
を示す図である。

【図３０】参考例６におけるタグファイルの内容例を示
す図である。

【図３１】参考例６における書体ファイルの内容例を示
す図である。

【図３２】参考例７における書体物理ファイルのファイ
ル名称に用いる文字構造を示す図である。

【図３３】参考例７における書体データの書体論理デー
タファイルのファイル名の構造を示している。

【図３４】参考例７における物理書体の識別情報を表す
各種文字列を示す図である。

【図３５】参考例７における書体論理データファイルの
識別情報を表す各種文字列を示す図である。

【図３６】参考例７におけるスタイル幅情報の意味内容
を示す図である。

【図３７】参考例７におけるウェイト情報の意味内容を
示す図である。

【図３８】参考例７におけるサイズ・サポート領域の関
係を示す図である。

【図３９】参考例８における縮小文字パターン生成にか
かる処理内容を示すフローチャートである。

【図４０】参考例８における縮小処理の問題点を示す図
である。

【図４１】参考例８における補正後の縮小処理を示す図
である。

【図４２】参考例９における書体情報ファイルの名称の
フォーマットを示す図である。

【図４３】参考例９における書体情報ファイルの内部構
造を示す図である。

【図４４】参考例９における書体格納情報ファイルの構
造を示す図である。

【図４５】参考例９における書体登録の処理手順を示す
フローチャートである。

【符号の説明】

１０１ ＣＰＵ １０２ ＲＯＭ １０３ ＲＡＭ １０４ キーボード制御部（ＫＢＣ） １０５ キーボード（ＫＢ） １０６ 表示装置制御部（ＣＲＴＣ） １０７ 表示装置 １０８ ＤＫＣ １０９ 外部記憶装置 １１０ プリンタ制御部 １１１ プリンタ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 山口 裕成 東京都大田区下丸子３丁目30番２号 キ ヤノン株式会社内 (72)発明者 柏木 正樹 東京都大田区下丸子３丁目30番２号 キ ヤノン株式会社内 (72)発明者 石黒 健二 東京都大田区下丸子３丁目30番２号 キ ヤノン株式会社内 (72)発明者 長田 守 東京都大田区下丸子３丁目30番２号 キ ヤノン株式会社内 (72)発明者 松木 浩 東京都大田区下丸子３丁目30番２号 キ ヤノン株式会社内 (56)参考文献 特開 昭64−37588（ＪＰ，Ａ) 特開 昭61−29936（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G09G 5/22 G06T 11/20

Claims (4)

(57)【特許請求の範囲】
1. 【請求項１】 要求された文字に関するデータを書体デ
   ータファイルから取り出すための書体データ管理方法に
   おいて、 複数の部分コード空間に分割された文字コード空間にお
   ける、前記各部分コード空間毎に独立した書体データフ
   ァイルを管理し、 アプリケーションからの文字取得要求を文字コードと共
   に認識する認識ステップと、 前記認識ステップに連動して、前記認識ステップにて認
   識した文字コードが前記複数の部分コード空間に分割さ
   れた文字コード空間の何れかの部分コード空間に含まれ
   るかを特定する特定ステップと、 前記特定ステップにて特定された部分コード空間のアク
   セス頻度を更新する更新ステップと、 前記更新ステップにて更新されたアクセス頻度をファイ
   ルとして保存する保存ステップと、 システム起動時に前記ファイルより取得されるアクセス
   頻度に従い、文字取得要求に対して検索される個々の書
   体データファイルの検索順序を変更する変更ステップ
   と、 を有することを特徴とする書体データ管理方法。
2. 【請求項２】 前記部分的書体データファイルは、ファ
   イル名称によって管理されることを特徴とする請求項１
   に記載の書体データ管理方法。
3. 【請求項３】 要求された文字に関するデータを書体デ
   ータファイルから取り出すための書体データ管理装置に
   おいて、 複数の部分コード空間に分割された文字コード空間にお
   ける、前記各部分コード空間毎に独立した書体データフ
   ァイルを管理する管理手段と、 アプリケーションからの文字取得要求を文字コードと共
   に認識する認識手段と、 前記認識手段の認識に連動して、前記認識ステップにて
   認識した文字コードが前記複数の部分コード空間に分割
   された文字コード空間の何れかの部分コード空間に含ま
   れるかを特定する特定手段と、 前記特定手段にて特定された部分コード空間のアクセス
   頻度を更新する更新手段と、 前記更新手段によって更新されたアクセス頻度をファイ
   ルとして保存する保存手段と、 システム起動時に前記ファイルより取得されるアクセス
   頻度に従い、文字取得要求に対して検索される個々の書
   体データファイルの検索順序を変更する変更手段と、 を有することを特徴とする書体データ管理装置。
4. 【請求項４】 前記部分的書体データファイルは、ファ
   イル名称によって管理されることを特徴とする請求項３
   に記載の書体データ管理装置。