JP3473287B2 - フォント管理装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ページ記述言語
（以下、ＰＤＬという。）によって記述されたＰＤＬデ
ータを入力として画像出力を行うＰＤＬ処理出力装置に
おいて、フォントの記憶処理を管理するフォント管理装
置に関する。

【０００２】

【従来の技術】ＰＤＬは、画像出力装置の解像度、カラ
ーの表現能力、処理方式等等と言った仕様に依存しない
形式で、複雑な図形の描画や任意の大きさの文字出力等
の定義が行える言語であり、非常に抽象度の高い表現能
力を持っている。特に、文字出力処理に関しては、ＰＤ
Ｌを用いて文書画像のデータを記述することによって、
任意の大きさの文字が出力できるだけでなく、描画する
文字のフォント（書体とも呼ぶ）の種類においても幅広
い選択ができるようになっている。このように、ＰＤＬ
では、複数のフォントを選択できることによって一般の
印刷物のように見出しと本文、和文と英文等にフォント
を使い分けることが可能となり、文書の表現能力がそれ
以前と比較して格段に進歩した。なお、これらＰＤＬの
例としては、Ｘｅｒｏｘ社のＩｎｔｅｒｐｒｅｓｓ（登
録商標）、Ａｄｏｂｅ社のＰｏｓｔＳｃｒｉｐｔ（登録
商標）等が知られている。

【０００３】このようなＰＤＬデータに対しての従来の
処理出力装置及び処理の流れを図８及び図９を参照して
説明する。ＰＤＬ処理出力装置１に入力された全てのＰ
ＤＬデータは、入力解析部２で読み取られ（手順１）、
構築、描画、パラメータ設定、印刷指示といったＰＤＬ
データの属性にしたがって処理される（手順２）。すな
わち、入力されたＰＤＬデータが描画用図形の構築に関
するものである場合には、図形管理部３が当該ＰＤＬデ
ータに従って図形バッファ４に描画用の図形データを構
築する（手順３）。また、入力されたＰＤＬデータが描
画コマンドである場合には、パラメータテーブル６に設
定されているパラメータにしたがって、描画処理部５が
図形バッファ４に構築された描画用図形データを読み出
し、プリンタやＣＲＴディスプレイ等から成る出力装置
７の表現能力に適したラスター展開を行ってフレームバ
ッファ８に書き込む（手順４）。

【０００４】また、入力されたＰＤＬデータがパラメー
タ設定コマンドである場合には（手順５）、まず、パラ
メータ管理部９がそのパラメータがフォント指定のもの
であるかどうかを判断し（手順６）、フォント指定に関
連するものでない場合は、パラメータテーブル６に登録
してそれぞれ必要な処理を行う（手順７）。一方、フォ
ント指定のものである場合は、パラメータ管理部９が、
パラメータをパラメータテーブル６に登録した後（手順
８）、主記憶装置上のフォント格納領域であるＶＭ領域
１０にそのフォントがすでに展開されているかどうかを
検索する（手順９）。この結果、既に展開されている場
合には、そのフォントを描画処理部５に現在使用中のフ
ォントとして扱わせる一方、未だ展開されていないフォ
ントの場合には、図外の外部記憶装置等に格納されてい
るフォントを読み込んでＶＭ領域１０上に展開して、現
在使用中のフォントとして扱わせる（手順１１）。

【０００５】また、入力されたＰＤＬデータが印刷出力
コマンドである場合には、描画コマンドによって既にフ
レームバッファ８に描画されている内容を、印刷処理部
１１が出力装置７に同期して読み出し印字操作を行わせ
る（手順１２）。なお、フレームバッファ８はバンド形
式のバッファでも原理は同じである。そして、入力され
た全てのＰＤＬデータが上記のように処理されたところ
で、一連の処理を終了する（手順１３）。

【０００６】更に、このようなＰＤＬデータに対する従
来の処理の内のフォントの選択処理について詳しく説明
するが、説明を分かり易くするために、ＰＤＬの一例と
してＡｄｏｂｅ社のＰｏｓｔＳｃｒｉｐｔ（登録商標）
及びその処理系を登載したプリンタを例にとって説明す
る。なお、ＰｏｓｔＳｃｒｉｐｔ（登録商標）の言語仕
様については、Ａｄｏｂｅ社の”ＰｏｓｔＳｃｒｉｐｔ
ＲｅｆｅｒｅｎｃｅＭａｎｕａｌ Ｓｅｃｏｎｄ Ｅ
ｄｉｔｉｏｎ”において詳しく説明されている。

【０００７】ＰｏｓｔＳｃｒｉｐｔ（登録商標）の言語
仕様では、フォントはＶＭと呼ばれる主記憶装置のある
領域に対して展開される。なお、このＶＭと呼ばれてい
る領域の他には、印刷処理を行う際の印刷装置用バッフ
ァや内部処理のためのＷｏｒｋ領域が必要なため、ＶＭ
は主記憶装置内においてＰＤＬの言語処理に使用される
領域とも表現でき、つまり、ＶＭはＰＤＬデータを解析
処理する際にその内部状態を保持するための領域として
使用されている。ここで、ＶＭはＬｏｃａｌＶＭとＧｌ
ｏｂａｌＶＭの２種類に分かれており、両者の違いはＬ
ｏｃａｌＶＭにはｓａｖｅ／ｒｅｓｔｏｒｅという記憶
状態の世代管理機構が提供されていることである。すな
わち、ｓａｖｅコマンドを発行した段階以降にＶＭに行
われた変更を、ｒｅｓｔｏｒｅコマンドによって無効に
し、ｓａｖｅした段階まで状態を復帰することができる
ことである。ＰｏｓｔＳｃｒｉｐｔ（登録商標）におい
ては、この機構を多用しており、例えば、１ページの処
理ごとに状態を復帰させてｐａｇｅ毎に独立をはかるた
めの手段として用いている。

【０００８】ところで、フォントはｆｉｎｄｆｏｎｔコ
マンド等によってＶＭ上に展開されることによって使用
可能（参照可能）なフォントとして設定される。この展
開処理に際して、現在のＶＭのモードによってＬｏｃａ
ｌＶＭ上に展開されるかＧｌｏｂａｌＶＭ上に展開され
るかが決定される。そして、ＬｏｃａｌＶＭに展開され
た場合には、既に一度ｓａｖｅされた状態であれば、ｒ
ｅｓｔｏｒｅコマンドによってそのフォントが展開され
た状態が取り消され、元の状態に戻すことができる。

【０００９】ここで、一般的に、フォントのＶＭ上への
展開処理にはかなりの時間がかかる。英語のように１フ
ォント辺り数十文字から多くても百文字程度のものであ
れば、例えば１ページごとにＶＭがｒｅｓｔｏｒｅされ
てフォントを展開する前の状態に戻された後、再び当該
フォントが選択された時には新規にフォントを展開する
ような方式であっても、その処理時間は無視できる程度
である。しかしながら、日本語のように文字数が１フォ
ントに付き数千文字になると、展開処理の時間は大きな
オーバヘッドとなる。また、それだけの大容量のフォン
トを展開するにはＶＭも大量に消費することとなる。

【００１０】このような不具合について更に詳しく説明
するとともに、従来において考えられていたな解決方法
を説明する。例えば、ＰｏｓｔＳｃｒｉｐｔ（登録商
標）の通常のフォントフォーマットはＴｙｐｅ１と呼ば
れているものであるが、このフォーマットに限らず、図
１０に示すように、全てのフォントはＰＤＬデータの言
語プログラムの形式で記述されている。主記憶装置１２
内のＶＭ領域１０上に展開されていない状態では、フォ
ントを記述しているプログラムはそのままＰＤＬ処理出
力装置１が有するｆｉｌｅ ｓｙｓｔｅｍ上のＲＯＭや
Ｄｉｓｋ等の外部記憶装置１３に格納されており、描画
処理においてフォントを参照する等の必要に応じて、当
該プログラムを実行することによってフォントがＶＭ領
域１０上に展開される。

【００１１】ここで、ＰｏｓｔＳｃｒｉｐｔにおけるＶ
Ｍ領域上への展開処理は、図１１に示すように、キーと
それに対応するデータ内容の組みを辞書と呼ばれるオブ
ジェクトとし、これらオブジェクトを複数格納した形式
のオブジェクトとして行われる。つまり、あるフォント
が選択された場合、そのフォントがＶＭ領域上にすでに
展開されている時には、その該当する辞書オブジェクト
が参照されるが、未だＶＭ領域上に展開されていない時
には、外部記憶装置からその辞書を作成するためのプロ
グラムファイルが検索されて実行され、辞書が作成され
る。このようにＰｏｓｔＳｃｒｉｐｔのフォントはプロ
グラム形式で記述されている情報を辞書オブジェクトの
形式でＶＭ領域上に展開するため、展開処理に時間およ
びＶＭ資源を多量に消費することとなる。特に、Ｔｙｐ
ｅ１と呼ばれる形式は全ての情報についてＶＭ上に展開
するフォーマットであるので、これが顕著である。

【００１２】このような不具合を解決するためには、辞
書の基本部分のみをＶＭ上に置いた状態とし、一番デー
タ容量の大きいアウトラインデータ定義部分は別の外部
領域（ＤＩＳＫやＲＯＭ上）に格納してた状態で使用
し、プログラムにはその領域へのアクセスメソッドおよ
びポインタのみを置くという方法が考えられる。この解
決方法によれば、高価な半導体メモリによって提供され
ているＶＭについて、必要とされる容量を抑えることが
でき、また、最もサイズの大きいアウトラインデータ本
体はＶＭ上には展開しないので、トータルでの展開時間
も削減することができる。

【００１３】このようにアウトラインデータ定義部分は
外部領域に格納してた状態で使用する、すなわち、所謂
ＲＯＭ化するのが効果的な方法と考えられる。このＲＯ
Ｍ化方式において一番理想的な方法は、コンピュータの
オペレーティングシステムに用いられているような仮想
記憶装置における記憶領域スワップの方式を用いて、Ｐ
ＤＬ処理出力装置の立ち上げ時に使用可能なすべての保
有フォントをＶＭ上に展開した状態で、そのＶＭをスワ
ップ領域として扱い、そのままＲＯＭ化する方式、つま
りＶＭのＳｎａｐＳｈｏｔを作成してそのままＲＯＭに
焼き、なおかつ、その状態でメモリ管理システムで認識
する方式である。この方式は、ＶＭをそのままＲＯＭに
焼くのでＲＡＭのＶＭは一切消費しないので、一番効率
がよい方法と考えられる。ただし、ＶＭのＳｎａｐＳｈ
ｏｔをＲＯＭに焼くためには、ＰＤＬ処理出力装置のメ
モリ管理とオペレーティングシステムのメモリ管理を一
元化する必要があり、そのため、固有のオペレーティン
グシステムに依存し、ＰＤＬ処理出力装置のＶＭ管理機
構そのものを変更する必要がある。

【００１４】このような事情から、ＲＯＭ化方式を容易
に実現するためには、フォントデータの枠組みとしては
既存のフォーマットを利用して互換性を保ち、その一部
をＲＯＭ化してＶＭの消費量を減らし、なおかつ、ＲＯ
Ｍ化した部分はＶＭ上に展開はしないので展開速度を早
くするという方式が有利と考えられる。このような観点
から考案された独自方式の一例として、富士ゼロックス
社発行の「富士ゼロックステクニカルリポートＮｏ．８
１９９３」の「フルカラープリントサービス技術」の
項にある方式について説明する。

【００１５】図１２に示すように、この方式は次の２つ
を柱にしており、その一つはＴｙｐｅ８５という外部記
憶装置に対応するフォントフォーマット、もう一つは遅
延評価方式である。ＰｏｓｔＳｃｒｉｐｔ（登録商標）
は、英語用のものをベースに日本語対応を果たしたＰＤ
Ｌであり、そのため、１つのフォント辞書は通常２５６
文字以内で表現される。したがって、漢字のように数千
文字が必要なフォントにおいては、フォントを複合形式
によって管理している。すなわち、複数のフォントを階
層的に配置し、最終的には２５６文字以下にすることに
よって管理している。この複合形式によるフォントの管
理において、階層の上位に位置する、つまりマッピング
を行うためのフォントを”Ｃｏｍｐｏｓｉｔｅ Ｆｏｎ
ｔ”と呼び、Ｔｙｐｅ０という形式番号が与えられてい
る。つまり、１つの書体に対しては１つのＴｙｐｅ０フ
ォントが対応するため、既存の英語のフォント管理方式
と共存できる。このような管理においては、フォントの
実体はそのＴｙｐｅ０フォントから階層的にマッピング
された複数のフォント”Ｄｅｓｃｅｎｄｅｒ Ｆｏｎ
ｔ”によって構成され、最終的にはＴｙｐｅ１などの実
体を持つフォント”Ｂａｓｅ Ｆｏｎｔ”へ辿ることに
より行われる。

【００１６】ここで、この方式における特徴は、この”
Ｂａｓｅ Ｆｏｎｔ”として富士ゼロックス社が独自に
定義したＴｙｐｅ８５というフォントを用いていること
である。このフォントはＰｏｓｔＳｃｒｉｐｔの辞書と
して必要なエントリーは持っているが、フォントのアウ
トラインデータ自体は外部記憶装置上におくことによっ
て、新規のフォントが選択された時のローディング速度
とＶＭの消費を抑えている。さらに、遅延評価方式をフ
ォント管理に対して適用しており、ｆｉｎｄｆｏｎｔコ
マンドを実行した時には仮のオブジェクト（疑似フォン
ト）を作成して登録し、実際にｓｃａｌｅｆｏｎｔなど
によってある特定の大きさの実際の処理対象となるフォ
ントが必要になったときに、初めて実際にフォントの実
体の展開／作成を行う。この遅延評価方式では、必要と
なるまではフォントの実体部分は展開されないので、仮
に初期化時に多くのフォントをあらかじめ展開して備え
るような場合においても負荷が集中することがないので
負荷分散にもなる。

【００１７】しかしながら、この方式ではフォントの実
際の展開を先延ばしにすることはできるが、多数の日本
語フォントなどが選択されて文字出力が行われた場合に
は、主記憶装置の消費量は際限なく大きくなってしま
う。したがって、この方式では、英語のみ対応している
ものに対して、日本語対応とするためには主記憶装置に
多くのメモリ容量を必要としてしまう。

【００１８】また、特開平７−６４９７１号公報には、
日本語のような文字数の多いフォントについて、フォン
トをグループ分けして外部記憶装置等に格納しておき、
文字描画を行う際に該当するフォントが主記憶装置にす
でに展開されているかどうかを検索し、未展開の場合に
は外部記憶装置から展開するシステムが開示されてい
る。このシステムによれば、システム立上げ時には全て
のフォントを展開する必要がないので、展開時間の速さ
と主記憶装置の容量の低減をはかることができるとして
いる。

【００１９】しかしながら、このシステムでは、文字を
描画する段階になって初めてあるグループのフォント展
開を新規に開始するため、既存のＰＤＬ、特にＰｏｓｔ
Ｓｃｒｉｐｔのような書体の選択および文字出力方式に
は適用できないものであった。すなわち、ＰＤＬ処理に
おいては図３に示すようなテーブル（ＦｏｎｔＤｉｒｅ
ｃｔｒｙ）を用いてフォントを管理しているが、ｆｉｎ
ｄｆｏｎｔコマンドで指定された名前のフォントを使用
可能なオブジェクトとして作成すると同時に、当該名前
はＦｏｎｔＤｉｒｅｃｔｏｒｙに登録される。つまり、
書体が選択された段階で、フォントオブジェクトはＦｏ
ｎｔＤｉｒｅｃｔｏｒｙに登録されていないといけな
い。これに対して、特開平７−６４９７１号公報に記載
されたシステムでは、単純に主記憶装置上に展開するフ
ォントをグループ化された小さい単位で行うとしている
だけであるので、このようにＦｏｎｔＤｉｒｅｃｔｏｒ
ｙなどの管理テーブルから間接参照された場合に参照さ
れたフォントが主記憶装置には展開されていない事態が
発生してしまう。また、このシステムでは、単に文字コ
ードから逆引きでフォントを選択するので、複数の書体
には対応しておらず、ＰｏｓｔＳｃｒｉｐｔのような高
機能のＰＤＬ処理出力装置には適用できないものであっ
た。

【００２０】

【発明が解決しようとする課題】上述のように、従来に
おいては、ＰＤＬ処理出力装置において、日本語のよう
に書体数が多いフォントの扱いについては主記憶装置の
容量を増やすなどして対応するしかなかった。したがっ
て、従来にあっては、日本語のように多数のフォントの
展開処理を高速に行うことができず、また、主記憶装置
におけるフォントに使用される容量がかなり大きなもの
となってしまうとともに、メモリ管理が極めて複雑化し
てしまうという問題があった。本発明は上記従来に事情
に鑑みなされたもので、限られた主記憶装置の容量で日
本語等の多くのフォントを扱うことが可能なフォント管
理装置を提供することを目的とする。

【００２１】

【課題を解決するための手段】上記目的を達成するた
め、本発明では、ＰＤＬにより記述されたＰＤＬデータ
に基づいて参照される複数の文字画像のフォントを管理
するフォント管理装置において、複数のフォントを保持
するＲＯＭ等の補助記憶手段と、描画処理に用いるフォ
ントを保持するＶＭ領域等の主記憶手段と、を備え、展
開受付手段がフォントを展開する指示を受け取ると、主
記憶管理手段が展開を指示されたフォントを展開するこ
とによって主記憶手段に保持されるフォントの総量が所
定の容量を超えるか否かを検出する。そして、主記憶管
理手段によってフォントの総量が前記容量を超えること
が検出された場合には、排除手段が主記憶手段に保持さ
れているフォントの中で参照頻度が最も低いフォントか
ら排除して領域を確保し、この領域確保後に、展開手段
が展開指示のあったフォントを参照可能な形式として補
助記憶手段から主記憶手段に展開する。

【００２２】また、本発明に係るフォント管理装置で
は、各フォントは文字画像の情報を管理する実体フォン
ト部分と、ＰＤＬデータと実体フォント部との関連付け
を管理する識別フォント部分とを有しており、参照受付
手段が既に主記憶手段に保持されたフォントに対しての
参照指示を受け付けると、主記憶管理手段が参照指示の
あった実体フォント部分を展開することによって主記憶
手段に保持されるフォントの総量が所定の容量を超える
か否かを検出する。そして、主記憶管理手段によってフ
ォントの総量が前記容量を超えることが検出された場合
には、排除手段が主記憶手段に保持されている実体フォ
ント部分の中で参照頻度が最も低い実体フォント部分か
ら排除して領域を確保し、この領域確保後に、参照展開
手段が参照指示のあった実体フォント部分を参照可能な
形式として補助記憶手段から主記憶手段に展開する。

【００２３】より具体的には、本発明に係るフォント管
理装置では、入力されたＰＤＬデータを解析してフォン
ト処理に関する命令を抽出する。そして、抽出したフォ
ントに関する命令の内のフォントを主記憶装置上に展開
する必要のあるものについて、外部記憶装置から読み出
して展開する。この展開を行う際に、該当するフォント
の使用頻度をカウントし、主記憶装置の容量の制限にし
たがって使用頻度の低いフォントについてはその主記憶
装置上の領域を解放して再利用可能とする。また、この
再利用可能な状態においても識別フォント部分は主記憶
装置上に存在させて、間接参照が行えるようにしてい
る。

【００２４】

【発明の実施の形態】本発明の一実施形態に係るフォン
ト管理装置を、図面を参照して説明する。なお、図８〜
図１２に示した従来例も必要に応じて適宜参照する。図
１には、本実施形態に係るフォント管理装置を示してあ
り、このフォント管理装置は図８に示したＰＤＬ処理出
力装置１におけるパラメータ管理部９内のフォント管理
部２０として構成されている。フォント管理部２０に
は、ＰＤＬデータのパラメータ設定関連コマンドにより
フォントを展開する指示を受け取る受付手段２１と、展
開を指示されたフォントを主記憶装置のＶＭ領域１０に
展開することによってＶＭ領域１０に保持されるフォン
トの総量が所定の容量を超えるか否かを検出する主記憶
管理手段２２と、フォントの総量が当該容量を超えるこ
とが検出された場合にＶＭ領域１０に保持されているフ
ォントの中で参照頻度が最も低いフォントを順次排除す
る排除手段２３と、排除によって展開領域が確保された
ＶＭ領域１０に展開指示のあったフォントを参照可能な
形式として外部記憶装置１３から展開する展開手段２４
と、を備えている。

【００２５】ここで、後述するように、本実施形態にお
けるフォントは文字画像の情報を管理する実体フォント
部分と、ＰＤＬデータと前記実体フォント部との関連付
けを管理する識別フォント部分とを有しており、排除手
段２３による排除処理は既にＶＭ領域１０に保持されて
いる実体フォント部分のデータ領域を指示に基づいて展
開する他の実体フォント部分で上書きすることにより行
われる。このような処理を実行するために、フォント管
理部２０には、展開手段２４が実体フォント部を展開す
る際に、指示された実体フォント部分のエントリを排除
する実体フォント部分の対応するエントリに対して反映
させる制御を行う展開制御手段２５が、備えられてい
る。

【００２６】次に、本実施形態のフォント管理部２０に
よって行われる処理を図２を参照して説明する。なお、
本実施形態におけるＰＤＬデータの処理は、図９に示し
た従来例に対してパラメータ設定関連コマンドについて
の処理部分の一部（手順１４〜手順１６）が異なるだけ
であるので、他の処理部分（手順１〜手順１０及び手順
１２、手順１３）についての説明は重複を避けるために
割愛する。本実施形態においても、フォントがＶＭ領域
１０に展開されていない場合は、外部記憶装置１３から
フォントを生成するＰＤＬデータ（プログラム形式）を
読み込み、それを実行することによってＶＭ領域１０上
に展開処理を行ってフォントオブジェクトを生成する。
ここで、ＶＭ領域１０内に新規に展開のための領域を確
保すると、従来の問題点として説明したように、フォン
ト数が増えるに比例してＶＭ領域１０を際限なく消費し
てしまう。

【００２７】このため、まず、主記憶管理手段２２が、
現在ＶＭ領域１０内において使用されているフォントの
中で、一番使用頻度の低いものを探し（手順１４）、そ
のフォントが確保していた領域を排除手段２３が解放す
る（手順１５）。この使用頻度については、１文字出力
処理を行うごとに、主記憶管理手段２２が該当フォント
の使用頻度情報を更新して、その頻度情報に従って判定
する。そして、ＶＭ領域１０内に展開可能な領域を確保
した後、該当する新規フォントを展開手段２４が外部記
憶装置１３から読み出してＶＭ領域１０に展開する。

【００２８】ここで、上記の処理を単純に行っただけで
は、ＰｏｓｔＳｃｒｉｐｔの処理系においては問題が発
生する。すなわち、図３に示すように、ＰｏｓｔＳｃｒ
ｉｐｔでは、ＶＭ上に展開されているフォントはフォン
トディレクトリー”ＦｏｎｔＤｉｒｅｃｔｒｙ”という
称せられる管理テーブルによって管理されており、ユー
ザはそれを参照することができる。このため、単にＶＭ
からフォントを解放してしまうと、この管理テーブルと
の対応がとれなくなる。なお、管理テーブルに対してＶ
Ｍの現在の内容をそのまま反映させると、この管理テー
ブルには使用頻度の高いフォントのみ登録されているこ
とになる。これはＰｏｓｔＳｃｉｒｐｔの言語仕様上一
般には許されないものである。ＰｏｓｔＳｃｉｒｐｔの
言語仕様上は一度ＶＭに展開されたフォントは、そのＶ
Ｍ領域がｒｅｓｔｏｒｅなどの明示的なコマンドで前の
状態に戻るなどしなければ、そのまま保持されつづれな
ければならないからである。

【００２９】したがって、本実施形態の基本的な処理で
は、あるフォントが解放された際には、”ＦｏｎｔＤｉ
ｒｅｃｔｏｒｙ”に登録されているエントリーはそのま
まにして、データ部分（つまり、フォント辞書そのも
の）はダミーのものを残すことにしている。そして、”
ＦｏｎｔＤｉｒｅｃｔｏｒｙ”を通して実際にアクセス
された際には、再びその辞書を新規にＶＭ領域に展開し
て、対応するダミーと換えるようにしている。但し、こ
のような処理だけでは、”ＦｏｎｔＤｉｒｅｃｔｏｒ
ｙ”の管理に負荷をかけることとなって処理速度の低下
を招く可能性がある。そこで、本実施形態では、このよ
うなフォントの頻度による管理を複合形式のフォントの
うちの”Ｂａｓｅ Ｆｏｎｔ”のみについて限定して実
施するようにしている。

【００３０】複合形式のフォントは先にも説明したよう
に、ＰｏｓｔＳｃｒｉｐｔで漢字を扱うために主に用い
られているものであり、図３に示すように、フォント名
に対応した一番上位のフォントを”Ｒｏｏｔ Ｆｏｎ
ｔ”、この”Ｒｏｏｔ Ｆｏｎｔ”から派生する下位の
フォントを”Ｄｅｓｃｅｎｄｅｒ Ｆｏｎｔ”と呼び、
この”Ｄｅｓｃｅｎｄｅｒ Ｆｏｎｔ”の内の最下位の
フォントで実際にフォントデータを持っているフォント
を特に”Ｂａｓｅ Ｆｏｎｔ”と呼ぶ。基本的な漢字フ
ォントは、１つの”Ｒｏｏｔ Ｆｏｎｔ”と数十の”Ｂ
ａｓｅ Ｆｏｎｔ”から成っているが、複雑なコード体
系のフォントであると、中間段に”Ｄｅｓｃｅｎｄｅｒ
Ｃｏｍｐｏｓｉｔｅ Ｆｏｎｔ”が幾つか入ることも
ある。なお、”Ｂａｓｅ Ｆｏｎｔ”はいわゆる漢字の
区単位に分かれており、その数は１フォントに付き数十
から百個程である。

【００３１】本実施形態では、”Ｂａｓｅ Ｆｏｎｔ”
のみをＶＭ領域からの解放の対象とし、さらに、次の処
理を組み合せることによって問題を回避している。すな
わち、”Ｂａｓｅ Ｆｏｎｔ”のみを単に解放の対象と
すると、その上位の”Ｄｅｓｃｅｎｄｅｒ Ｆｏｎｔ”
は自分の下位の”Ｂａｓｅ Ｆｏｎｔ”が解放されてい
ることを認識して内容を随時更新しなければならず、ま
た、解放された”Ｂａｓｅ Ｆｏｎｔ”のために”Ｆｏ
ｎｔＤｉｒｅｃｔｏｒｙ”も更新されなければならない
という問題を回避している。

【００３２】本実施形態では、ｆｉｎｄｆｏｎｔコマン
ドによって漢字フォントが呼び出されると、通常は”Ｒ
ｏｏｔ Ｆｏｎｔ”および”Ｂａｓｅ Ｆｏｎｔ”の全
てのフォントが呼び出されるが、従来例にある遅延評価
の手法を導入し、最初にｆｉｎｄｆｏｎｔされた段階で
は疑似フォントのみを生成し、実際に文字描画時に指定
された文字が格納されている”Ｂａｓｅ Ｆｏｎｔ”の
みを逐次ＶＭ領域に展開するものである。つまり、使用
した区だけＶＭ領域に展開するようにしており、このた
め、あまり使用されない第二水準のようなフォントはほ
とんどＶＭ領域に展開されないこととなってＶＭ領域の
使用量が減少する。さらに、本実施形態では、これにＶ
Ｍ領域の解放の仕組みと、解放と新規生成の繰り返しに
よる主記憶装置の領域の断片化を防ぐ仕組みとを採用し
ている。

【００３３】まず、領域の解放と間接参照について説明
する。本実施形態では、日本語フォントは図４に示すよ
うな階層で管理される。最上位の”Ｒｏｏｔ Ｃｏｍｐ
ｏｓｉｔｅ Ｆｏｎｔ”は、そのフォントが管理してい
る次の階層の”Ｄｅｓｃｅｎｄｅｒ Ｆｏｎｔ”を”Ｆ
ＤｅｐＶｅｃｔｏｒ”というエントリー名の辞書の配列
で管理している。”Ｒｏｏｔ Ｃｏｍｐｏｓｉｔｅ Ｆ
ｏｎｔ”の”ＦｏｎｔＴｙｐｅ”エントリーは０であ
り、”ＦＭａｐＴｙｐｅ”エントリーは次の階層のフォ
ントの内のどのフォントを選択するかのアルゴリズムを
決定する。例えば、”ＦＭａｐＴｙｐｅ”エントリーが
２の場合は、ｓｈｏｗコマンドの対象となる文字列の最
初の１Ｂｙｔｅの数値を”ＦＤｅｐＶｅｃｔｏｒ”エン
トリーに示された配列のインデックスとして用いて、次
の階層の辞書を特定する。

【００３４】ここで、本来は、この次の階層に”Ｂａｓ
ｅ Ｆｏｎｔ”がくるわけであるが、本実施形態では独
自のフォントフォーマットのフォント”Ｄｅｓｃｅｎｄ
ｅｒＣｏｍｐｏｓｉｔｅ Ｆｏｎｔ”をもう一段はさん
でいる。なお、このフォントのＦｏｎｔＴｙｐｅは、疑
似フォントを示す８８としてある。また、この”Ｄｅｓ
ｃｅｎｄｅｒ Ｃｏｍｐｏｓｉｔｅ Ｆｏｎｔ”は、
（１）”Ｂａｓｅ Ｆｏｎｔ”の取得のための手続き、
（２）既に”Ｂａｓｅ Ｆｏｎｔ”が取得されている場
合はその辞書へのポインタ、を有しているフォントであ
る。

【００３５】まず、最初にある日本語書体が選択された
時には、このＴｙｐｅ８８のフォント”Ｄｅｓｃｅｎｄ
ｅｒ Ｃｏｍｐｏｓｉｔｅ Ｆｏｎｔ”までは、ＶＭ領
域上に新規に展開される。この結果、選択された書体は
フォント管理テーブル”ＦｏｎｔＤｉｒｅｃｔｏｒｙ”
に登録され、間接参照されることが可能となる。このよ
うにＴｙｐｅ８８フォントが展開された段階で書体選択
処理は終了するが、このＴｙｐｅ８８フォントが指し示
す実際の”Ｂａｓｅ Ｆｏｎｔ”まではＶＭ領域上に作
成されない。したがって、ほとんどＶＭ領域の消費がな
い状態でフォントの展開処理が実現される。

【００３６】次いで、文字を描画するためにマッピング
アルゴリズムにしたがって”Ｂａｓｅ Ｆｏｎｔ”を実
際に探す状態が生ずると、Ｔｙｐｅ８８フォントが選択
された段階で初めて必要となる”Ｂａｓｅ Ｆｏｎｔ”
のみを、Ｔｙｐｅ８８フォントに登録されている上記
（１）の手続きを実行することによって作成し、或い
は、上記（２）のポインタで選択し、その”Ｂａｓｅ
Ｆｏｎｔ”内で実際に文字描画処理を行う。なお、こ
の”Ｂａｓｅ Ｆｏｎｔ”は、本実施形態では”Ｆｏｎ
ｔＴｙｐｅ”を８７とするが、Ｔｙｐｅ１をベースにし
たＲＯＭ対応の独自フォーマットである。また、ＲＯＭ
に対応しているためにＶＭ領域に実際のフォントデータ
は展開されず、この点からもＶＭ領域の消費量を減らす
ことができる。

【００３７】このように、最初にある日本語フォントが
選択された段階ではＦｏｎｔＴｙｐｅ８８の”Ｃｏｍｐ
ｏｓｉｔｅ Ｆｏｎｔ”までしか生成されないので、Ｖ
Ｍ領域の消費量が抑えられるとともに展開速度も迅速に
行われ、実際に文字描画をする段階になって初めて必要
な”Ｂａｓｅ Ｆｏｎｔ”のみをＶＭ領域に展開する。
ここで、上記のような展開処理を単純に行うだけでは、
数多くの文字が描画されると次第にＶＭ領域の消費量が
増えて行くこととなる。このような事態を回避するため
に、本実施形態では図５に示すような頻度管理を行って
いる。

【００３８】すなわち、予め設定してあるＶＭ領域の消
費量の上限値となった場合で、且つ、新たにＴｙｐｅ８
７の”Ｂａｓｅ Ｆｏｎｔ”を作成する場合には、ＶＭ
領域に展開されている各フォントの使用頻度を管理して
いる頻度管理テーブルを参照して、Ｔｙｐｅ８７の”Ｂ
ａｓｅ Ｆｏｎｔ”の使用頻度情報から使用頻度の低い
ものを選択する。そして、その”Ｂａｓｅ Ｆｏｎｔ”
を指している上位のＴｙｐｅ８８のフォントを調べ、そ
のフォントに登録されているＢａｓｅ Ｆｏｎｔポイン
タをクリアし、その”Ｂａｓｅ Ｆｏｎｔ”が展開され
ているＶＭ領域内の領域を再利用するために初期化す
る。このような処理によって、１つのフォントを生成す
るために１つのフォントを解放してＶＭ領域の消費量を
抑えることができる。なお、先のＴｙｐｅ８８フォント
のは”Ｂａｓｅ Ｆｏｎｔ”が未展開の状態に戻る。

【００３９】更に、本実施形態では、フォントが使用し
ている主記憶装置のＶＭ領域の排除／展開に際して、領
域を単に解放してから再確保するのではなく、図６に示
すように、書き換え処理によって再利用する方式を用い
ている。すなわち、ＶＭ領域に展開されている前の”Ｄ
ｅｓｃｅｎｄｅｒ Ｃｏｍｐｏｓｉｔｅ Ｆｏｎｔ”を
排除して、この領域に次の”Ｄｅｓｃｅｎｄｅｒ Ｃｏ
ｍｐｏｓｉｔｅ Ｆｏｎｔ”を展開するために、前の”
Ｄｅｓｃｅｎｄｅｒ Ｃｏｍｐｏｓｉｔｅ Ｆｏｎｔ”
の”Ｂａｓｅ Ｆｏｎｔ Ｐｏｉｎｔｅｒ”をＮＵＬＬ
として、次の”Ｄｅｓｃｅｎｄｅｒ Ｃｏｍｐｏｓｉｔ
ｅ Ｆｏｎｔ”の”Ｂａｓｅ ＦｏｎｔＰｏｉｎｔｅ
ｒ”を該当する”Ｂａｓｅ Ｆｏｎｔ”に設定する。

【００４０】ここで、単に”Ｂａｓｅ Ｆｏｎｔ”を展
開する領域を解放して再度確保していたのでは、ＶＭ領
域が虫食い状態のように使用領域と解放領域が入り乱れ
た断片化状態が発生してしまう。ＶＭ領域のリアルタイ
ムなガベージコレクションを持ったシステムであればこ
のような問題は回避することができるが、迅速な処理を
実現するためにはリアルタイムなガベージコレクション
を実現することは困難である。本実施形態の書き換え処
理は、このようなＶＭ領域の断片化を防ぐために行われ
る。

【００４１】すなわち、図７に示すように、”Ｂａｓｅ
Ｆｏｎｔ”は解放せずに、フォント辞書の中身を新規
の内容で書き換える処理を行う。この処理を実現するた
めに、全ての”Ｂａｓｅ Ｆｏｎｔ”のエントリー構成
を統一化しており、再利用は対応するエントリーを書き
換えることにより行う。すなわち、図７（１）に示すよ
うに各”Ｂａｓｅ Ｆｏｎｔ”間で共通するエントリー
の値は書き換えず、図７（２）に示すように各”Ｂａｓ
ｅ Ｆｏｎｔ”間で異なるエントリーの値は上書きす
る。なお、エントリー構成の統一化を実現するために、
図７（３）に示すように各”Ｂａｓｅ Ｆｏｎｔ”間で
異なる値となるエントリーの数が不定のものについて
は、最大数のエントリーを持った形式で全ての”Ｂａｓ
ｅ Ｆｏｎｔ”を構成してある。

【００４２】つまり、書換えに対応するために、書き換
え専用の辞書をあらかじめＦｏｎｔ用のＶＭ領域の制限
値に従って適当な数用意しておき、確保はここから行う
ようにする。日本語フォントの”Ｂａｓｅ Ｆｏｎｔ”
のすべてに対応できるようにするためには、不定長のデ
ータが格納される可能性があるような場合は、その最大
値で書き換え用のフォント辞書を生成しておく。辞書の
ようにエントリーとデータの組みで表現されるようなも
のの場合は、エントリーについてもすべてのフォントで
使用されるものをあらかじめ登録する。

【００４３】このような処理を行うことにより、常にフ
ォントに使用されるＶＭ領域の容量を制限することが可
能となり、また、再利用することによる主記憶装置の領
域の断片化も発生しない。さらに、この処理による速度
的なオーバヘッドも少なく、特に、最初にある日本語フ
ォントが選択された時の展開速度は、”Ｂａｓｅ Ｆｏ
ｎｔ”を生成しないために迅速である。

【００４４】

【発明の効果】以上説明したように、本発明によれば、
日本語フォントのように多種類のフォントについての展
開処理を高速に実行することができ、また、主記憶装置
内のフォントに使用される領域の容量を一定量以下に抑
えることが可能となり、メモリ管理が容易になる。

【図面の簡単な説明】

【図１】 本発明に係るＰＤＬ処理出力装置の要部の構
成を示す図である。

【図２】 本発明に係るＰＤＬ処理出力装置の処理手順
を示すフローチャートである。

【図３】 Ｆｏｎｔ Ｄｉｒｅｃｔｏｒｙを説明する概
念図である。

【図４】 本発明に係る漢字フォントの階層構造を示す
図である。

【図５】 本発明に係る頻度管理を説明する概念図であ
る。

【図６】 再利用処理における上位フォントの変化を示
す図である。

【図７】 本発明に係るフォントの再利用処理を説明す
る図である。

【図８】 従来例に係るＰＤＬ処理出力装置の構成を示
す図である。

【図９】 従来例に係るＰＤＬ処理出力装置の処理手順
を示すフローチャートである。

【図１０】 フォント辞書の展開を説明する概念図であ
る。

【図１１】 フォント辞書の一例を示す構成図である。

【図１２】 従来のフォント展開処理を説明する概念図
である。

【符号の説明】

９・・・パラメータ管理部、 １０・・・ＶＭ領域（主
記憶手段）、１３・・・外部記憶手段、 ２０・・・フ
ォント管理部、２１・・・受付手段、 ２２・・・主記
憶管理手段、 ２３・・・排除手段、２４・・・展開手
段、 ２５・・・展開制御手段、

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ Ｇ０６Ｆ 12/02 ５２０ Ｇ０６Ｆ 12/02 ５２０Ａ 17/21 ５６２ 17/21 ５６２Ｐ (58)調査した分野(Int.Cl.⁷，ＤＢ名) G09G 5/00 - 5/42 G06F 3/12 G06F 3/14 G06F 17/21 B41J 2/485

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】 ＰＤＬにより記述されたＰＤＬデータに
   基づいて参照される複数の文字画像のフォントを管理す
   るフォント管理装置において、 各フォントは文字画像の情報を管理する実体フォント部
   分と、ＰＤＬデータと前記実体フォント部分との関連付
   けを管理する識別フォント部分とを有しており、 複数のフォントを保持する補助記憶手段と、 描画処理に用いるフォントを保持する主記憶手段と、 フォントを登録する指示を受け付ける登録受付手段と、 登録受付手段が登録指示を受け付けたことに基づいて、
   フォントの識別フォント部分のみを補助記憶手段から主
   記憶手段に展開する登録展開手段と、を備えたことを特
   徴とするフォント管理装置。
2. 【請求項２】 請求項１に記載したフォント管理装置に
   おいて、 さらに、既に主記憶手段に保持されたフォントが管理し
   ている文字画像情報に対しての参照指示を受け付ける参
   照受付手段と、 参照受付手段が参照指示を受け付けたことに基づいて、
   参照指示のあった文字画像情報を管理する実体フォント
   部分を展開することによって主記憶手段に保持されるフ
   ォントの総量が所定の容量を超えるか否かを検出する主
   記憶管理手段と、 主記憶管理手段によってフォントの総量が前記容量を超
   えることが検出されたことに基づいて、主記憶手段に保
   持されている実体フォント部分の中で参照頻度が最も低
   い実体フォント部分から排除して領域を確保する排除手
   段と、 排除手段による領域確保の後に、参照指示のあった実体
   フォント部分を参照可能な形式として補助記憶手段から
   主記憶手段の前記確保した領域に展開する参照展開手段
   と、を備えたことを特徴とするフォント管理装置。
3. 【請求項３】 請求項２に記載したフォント管理装置に
   おいて、 各フォントの実体フォント部分の大きさを統一したこと
   を特徴とするフォント管理装置。
4. 【請求項４】 ＰＤＬにより記述されたＰＤＬデータに
   基づいて参照される複 数の文字画像のフォントを管理す
   るフォント管理装置において、 各フォントは文字画像の情報を管理する実体フォント部
   分と、ＰＤＬデータと前記実体フォント部分との関連付
   けを管理する識別フォント部分とを有しており、 複数のフォントを保持する補助記憶手段と、 描画処理に用いるフォントを保持する主記憶手段と、 既に主記憶手段に保持されたフォントが管理している文
   字画像情報に対しての参照指示を受け付ける参照受付手
   段と、 参照受付手段が参照指示を受け付けたことに基づいて、
   参照指示のあった文字画像情報を管理する実体フォント
   部分を展開することによって主記憶手段に保持されるフ
   ォントの総量が所定の容量を超えるか否かを検出する主
   記憶管理手段と、 主記憶管理手段によってフォントの総量が前記容量を超
   えることが検出されたことに基づいて、主記憶手段に保
   持されている実体フォント部分の中で参照頻度が最も低
   い実体フォント部分から排除して領域を確保する排除手
   段と、 排除手段による領域確保の後に、参照指示のあった実体
   フォント部分を参照可能な形式として補助記憶手段から
   主記憶手段の前記確保した領域に展開する参照展開手段
   と、を備え、 さらに、各フォントの実体フォント部分の大きさを統一
   したことを特徴とするフォント管理装置。
5. 【請求項５】 請求項３又は請求項４に記載したフォン
   ト管理装置において、 さらに、各フォントの実体フォント部分のエントリの構
   成を統一しており、 前記排除手段による排除処理は既に主記憶手段に保持さ
   れている実体フォント部分のデータ領域を上書きするこ
   とにより行い、 参照展開手段が実体フォント部分を展開する際に、参照
   指示された実体フォント部分のエントリを排除する実体
   フォント部分の対応するエントリに対して反映させる制
   御を行う展開制御手段を、備えたことを特徴とするフォ
   ント管理装置。