(57)【特許請求の範囲】
【請求項１】
ホスト装置からプリンタ装置へ送られる描画データの処理を行う画像処理装置において、
データを記憶するキャッシュメモリと、
前記プリンタ装置に特定の書体に対応する書体データが装備されていない文字の当該特定の書体での描画指示が前記ホスト装置側に発生し、かつ、当該文字の当該特定の書体に対応した抽象化描画データが前記キャッシュメモリに記憶されていない場合に、当該文字の当該特定の書体に対応したベクタ形式のアウトラインフォーマットデータ、または、ランレングス形式のラスタフォーマットデータである抽象化描画データを生成する描画データ生成手段と、
前記描画データ生成手段によって生成された抽象化描画データを前記プリンタ装置に送信する送信手段と、
前記描画データ生成手段によって生成された抽象化描画データを前記キャッシュメモリに格納する格納手段と、
前記プリンタ装置に特定の書体に対応する書体データが装備されていない文字の当該特定の書体での描画指示が前記ホスト装置側に発生し、かつ、当該文字の当該特定の書体に対応した抽象化描画データが前記キャッシュメモリに記憶されている場合には、前記描画データ生成手段は当該文字の当該特定の書体に対応した抽象化描画データを生成せず、前記送信手段は前記キャッシュメモリに記憶された当該文字の当該特定の書体に対応した抽象化描画データを前記プリンタ装置に送信することを特徴とする画像処理装置。
【請求項２】
前記プリンタ装置との間で双方向通信が可能な場合には、前記プリンタ装置からの印刷に使用される用紙のサイズおよび向きに関する情報を取得することにより、前記プリント装置において行われる描画処理において画像のサイズまたは向きを使用可能な印刷用紙のサイズまたは向きに適合させる変換処理が行われるか否かを判定し、前記プリンタ装置との間で双方向通信をすることができない場合には、予め記憶した当該プリント装置における使用可能な用紙のサイズおよび向きに関する情報に基づき、前記変換処理が行われるか否かを判定する判定手段を具備し、
前記描画データ生成手段は、前記変換処理が行われない旨の判定が前記判定手段によってなされた場合には、ランレングス圧縮形式のラスタフォーマットデータを前記抽象化描画データとして生成し、前記変換処理が行われる旨の判定が前記判定手段によってなされた場合には、ベクタ形式のアウトラインフォーマットデータを前記抽象化描画データとして生成することを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記送信手段によって送信された抽象化描画データが前記プリンタ装置のキャッシュメモリに記憶された場合に、該抽象化描画データを特定する情報を記憶するダウンロードキャッシュ管理テーブルを具備し、
前記描画データ生成手段によって生成すべき抽象化描画データを特定する情報が前記ダウンロードキャッシュ管理テーブルに記憶されている場合には、前記描画データ生成手段は、当該抽象化描画データの生成を行わず、前記送信手段は、当該抽象化描画データを指定した描画指示を前記プリンタ装置に送信することを特徴とする請求項１または２に記載の画像処理装置。
【請求項４】
前記ダウンロードキャッシュ管理テーブルは、前記プリンタ装置のキャッシュメモリに保持されている抽象化描画データが最後にアクセスされた日時、および、前記プリンタ装置のキャッシュメモリに抽象化描画データが格納された日時を、当該抽象化描画データを特定する情報と対応付けて記憶し、
前記送信手段は、前記プリンタ装置に送信すべき新たな抽象化描画データがあり、かつ、該抽象化描画データを格納するのに必要な記憶エリアが前記キャッシュメモリに残されていないと判断される場合に、前記ダウンロードキャッシュ管理テーブルに記憶された情報に基づいて、最も長く使用されていない抽象化描画データを特定し、この抽象化描画データが格納されている記憶エリアに新たな抽象化描画データを格納すべき旨の指示を前記プリンタ装置に送ることを特徴とする請求項３に記載の画像処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、ホスト装置とプリンタ装置からなるプリントシステムに好適な画像処理装置およびプリンタ装置に関する。
【０００２】
【従来の技術】
現在、ＤＴＰ（Desk Top Publishing）と呼ばれるような高品位な文書作成を行うシステムが各種提供されている。この種のシステムでは、ホスト装置側において作成された文書をプリンタ装置により最終的に印刷するのに先立ち、予めホスト装置側のデイスプレイに当該文書の印刷イメージを表示し、ユーザがこの印刷イメージを確認しながら当該文書の編集を行うＷＹＳＩＷＹＧ（What You See Is What You Get）と呼ばれる環境を提供しているのが一般的である。
【０００３】
【発明が解決しようとする課題】
ところで、上述したＷＹＳＩＷＹＧによるＤＴＰ環境の下では、多種の書体を使用して文字の描画表現が行われることが多い。従って、ユーザが多種の書体を使用した文書を作成することができるよう多種の書体データをホスト装置に装備しておくとともに、多種の書体での印刷を行い得るよう多種の書体データをプリンタ装置に装備しておくことが望まれるのである。
【０００４】
しかし、多種の書体データがホスト装置およびプリンタ装置の双方に各々装備されていたとしても、同一の書体データが双方に装備されているとは限らない。これは、ホスト装置が、書体データに限らず、アプリケーションソフトウエアなど、後から追加装備されることを前提としている装置であるのに対し、プリンタ装置は後から書体データを追加装備することを前提とした装置ではないからである。従って、一般的には、ホスト装置によって作成された文書の印刷に必要な書体データがプリンタ装置に装備されておらず、そのような書体の文字を印刷することができない場合も生じ得る。なお、書体データの追加装備を認め、なるべく多くの書体での印刷を可能にしたシステムも提供されている。しかしながら、この種のシステムは、数種類の書体データの追加が限界であるものが多いため、この問題を解決する有効な手段と言うことはできない。
【０００５】
そこで、この問題を解決するための方法として、書体データを記憶するための追加の記憶領域をプリンタ装置に設け、印刷に必要な書体データをオフラインまたはオンラインで書体単位で当該記憶領域にダウンロードし、プリンタ装置の搭載書体数を増加させるという方法が考えられる。
【０００６】
しかし、プリンタ装置に追加の記憶領域がない場合あるいは追加の記憶領域があったとしても当該記憶領域に書体データをダウンロードする機能がない場合には上記方法を採ることができない。また、必要な書体が多数あり、その全てを追加の記憶領域にダウンロードすることができない場合も生じうる。また、追加の記憶領域が十分な記憶容量を有している場合であっても、書体単位のダウンロードは時間が掛かるという問題がある。
【０００７】
このような書体単位のダウンロードを行うことなく、必要な書体での印刷を可能にするための技術として、例えば図１３に示すプリントシステムが考えられる。
【０００８】
このプリントシステムは、ホスト装置１と、プリンタ装置２とをネットワークなどにより接続してなるものである。
【０００９】
ホスト装置１は、文書作成のためのアプリケーション１１と、文書に含まれる描画データをプリンタ装置２に対応した描画コマンドに変換するプリンタドライバ１２と、描画ライブラリ１３とを有している。そして、描画ライブラリ１３は、フォントラスタイザ１３１と、書体管理部１３２と、プリンタ情報モジュール１３３とを有している。ここで、フォントラスタイザ１３１は、文字の描画データを構成する書体データをラスタデータに展開するフォント展開処理を行う手段である。また、プリンタ情報モジュール１３３は、プリンタ装置２の解像度、プリンタ装置２に装備されている書体などに関する情報を記憶している。また、書体管理部１３２は、プリンタ情報モジュール１３３をアクセスする手段である。
【００１０】
一方、プリンタ装置２は、ホスト装置１側から送られてくる描画コマンドなどを処理するデコンポーザ２１と、このデコンポーザ２１から出力されるラスタデータに従って印刷を行う印刷装置２２とを有している。そして、デコンポーザ２１は、インタプリタ２１１と、グラフィックス描画処理モジュール２１２と、出力用バッファ２１３とを有している。
【００１１】
このような構成において、ホスト装置１側では、アプリケーション１１により文書が作成される。そして、ユーザからその文書の印刷の指示が与えられると、その文書内の描画データがプリンタドライバ１２によって描画コマンドに変換される。この変換処理の詳細は次の通りである。
【００１２】
まず、文書に含まれる通常のグラフィックスなどの描画データは、プリンタドライバ１２によってプリンタ装置２に対応した描画コマンドに変換され、プリンタ装置２側に送られる。
【００１３】
次に文書に含まれる文字については、その文字の書体データがプリンタ装置２に装備されているか否かの問い合わせがプリンタドライバ１２から描画ライブラリ１２の書体管理部１３２に送られる。そして、上記文字の書体データがプリンタ装置２に装備されている旨の回答が書体管理部１３２から得られた場合、上記文字の描画データがプリンタドライバ１２によってプリンタ装置２に対応した描画コマンドに変換され、プリンタ装置２側へ送られる。一方、上記文字の書体データがプリンタ装置２に装備されていない旨の回答が書体管理部１３２から得られた場合、上記文字の書体データをラスタデータに展開すべき旨の展開要求がプリンタドライバ１２からフォントラスタイザ１３１に送られる。これにより上記文字のラスタデータがフォントラスタイザ１３１によって生成される。そして、プリンタドライバ１２により、このラスタデータが描画コマンドとしてプリンタ装置２側に送られる。図１４はこの描画コマンドの内容を示したものである。
【００１４】
プリンタ装置２側では、このようにしてホスト装置１側から送られてくるコマンドがインタプリタ２１１によって受信され、各コマンドは各々の種類に対応した処理に委ねられる。
【００１５】
まず、通常のグラフィックスやプリンタ装置２に書体データが装備されている文字の描画データは、上述したように、プリンタ装置２に対応した描画コマンドに変換されてインタプリタ２１１に送られてくる。これらの描画コマンドは、インタプリタ２１１によって通常のグラフィックス描画処理モジュール２１２に引き渡され、このモジュールによりラスタデータに変換される。そして、このラスタデータが出力用バッファ２１３を介して印刷装置２２に送られ、グラフィックスや文字の印刷が行われるのである。
【００１６】
一方、プリンタ装置２に書体データが装備されていない文字の描画データは、上述したように、ラスタデータに変換され、このラスタデータが描画コマンドとしてインタプリタ２１１に送られてくる。この描画コマンド（ラスタデータ）は、インタプリタ２１１によって出力用バッファ２１３に送られ、この出力用バッファ２１３から印刷装置２２に送られるのである。
【００１７】
以上がこのプリントシステムの詳細である。
このプリントシステムによれば、プリンタ装置２に書体データが装備されていない文字であっても、ホスト装置１側においてプリンタ装置２の解像度や用紙の設定方向などの情報を把握し、この情報に適合した当該文字の書体のラスタデータを生成してプリンタ装置２に送るのであれば、プリンタ装置２によりその文字の印刷を行うことができる。
【００１８】
しかしながら、一般に文書には多くの文字が含まれている。従って、必要な書体の書体データがプリンタ装置に配備されていない場合には、多くの文字についてホスト装置１側でラスタデータを生成し、描画コマンドとしてプリント装置２側へ送ることとなる。ところが、個々の文字の描画コマンドは、ラスタデータを含むため、そのデータ量が多い。従って、上記のプリントシステムにおいては、ネットワークのトラヒック量が問題となる。特にプリンタ装置２が高速のプリンタ装置である場合、プリンタ装置２の処理に対し、描画コマンドの転送が間に合わないという事態も生じる。
【００１９】
また、プリンタ装置２側においても、データ量の大きなラスタデータからなる描画コマンドを受信した場合、インタプリタ２１１における描画コマンドの解釈に時間が掛かるため、プリンタ装置２の処理速度が低下するという問題がある。
【００２０】
このような問題を幾分でも解決するためには、ホスト装置１側からプリンタ装置２側へ送るデータのトラヒック量を減らす手段が求められる。図１５はこのような観点から図１３のプリントシステムに改良を加えたものである。
【００２１】
この図１５に示すプリントシステムでは、プリンタ装置２のデコンポーザ２１内にダウンロードバッファ領域２１４が新たに追加されている。このプリントシステムにおいて、プリンタ装置２に書体データが装備されていない文字の印刷要求がホスト装置１側に生じた場合、当該文字のラスタデータがダウンロードバッファ領域２１４に記憶されていなければ、ホスト装置１側で当該文字のラスタデータが生成され、このラスタデータがプリンタ装置２側に送られる。プリンタ装置２側では、このラスタデータがダウンロードバッファ領域２１４にダウンロードされるとともに、当該ラスタデータを用いた文字の印刷が行われる。一方、プリンタ装置２に書体データが装備されていない文字の印刷要求がホスト装置１側に生じた場合において、当該文字のラスタデータがダウンロードバッファ領域２１４に記憶されているときには、ホスト装置１からプリンタ装置２へのラスタデータのダウンロードは行われず、プリンタ装置２側ではダウンロードバッファ領域２１４内の当該文字に対応した既存のラスタデータを用いて印刷が行われるのである。
【００２２】
このプリントシステムによれば、印刷すべき文字の書体データがプリンタ装置２に装備されていない場合であっても、その文字のラスタデータがダウンロードバッファ領域２１４に記憶されている限り、ホスト装置１からプリンタ装置２へのラスタデータのダウンロードは行われない。従って、このプリントシステムによれば、前掲図１３のものに比べて、ホスト装置１およびプリント装置２間のトラフィック量を幾分か低減することができると言えよう。しかしながら、ダウンロードバッファ領域２１４の記憶容量にも限りがあるため、文字のラスタデータのダウンロードを続けていれば、いずれはダウンロードバッファ領域２１４がラスタデータによって埋め尽くされ、もはや新たな文字のラスタデータをダウンロードすることができなくなってしまう。従って、ダウンロードの回数を低減する効果も、ダウンロードバッファ領域２１４の記憶容量の制約を受けることとなり、十分な効果を期待することはできない。
【００２３】
ここで、ホスト装置１およびプリンタ装置２間のトラフィック量を低減するために、１回のダウンロードによって送られるデータ量を減らすこと、すなわち、ラスタデータを圧縮して転送するという方法も考えられる。しかし、この方法を採った場合、ホスト装置１側でラスタデータを圧縮し、プリンタ装置側ではこの圧縮されたデータを伸長して元のラスタデータに戻さなければならず、そのための処理に時間を要し、処理速度が低下するという新たな問題が生じてしまう。
【００２４】
以上、図１３および図１５に示す各プリントシステムの問題点について説明したが、これらのプリントシステムは、最近のプリンタ装置の機能との関係で、さらに別の問題を有している。以下、この問題について説明する。
【００２５】
一般的にプリンタ装置は、ユーザが複数の用紙サイズの中から所望の用紙サイズを指定したり、用紙方向を指定したりすることができるものが多い。この種のプリンタ装置を使用したプリントシステムでは、各用紙サイズおよび用紙方向毎にプリンタ装置に用紙トレイを設け、プリンタ装置がホスト装置からの指示に従ってこの用紙トレイを切り替えることによりユーザの要求に対応している。
【００２６】
しかし、プリンタ装置に装備することができる用紙トレイの数には限りがあるため、用紙のサイズと用紙方向の全ての組み合わせをユーザに提供することは難しい。また、紙切れなど予期しない状況が発生し、用紙トレイが使用不可能となる場合もあり、かかる場合にはユーザが望む用紙サイズおよび用紙方向での印刷を行うことができないことがある。
【００２７】
このため、最近のプリンタ装置の中には、例えば図１６に示すように、描画コマンドを処理する際に９０度単位での回転や拡大または縮小を行うことにより、現在使用可能となっているトレイに出力することができるようにしたものが多い。この種のプリンタ装置を使用したプリントシステムによれば、例えばホスト装置での編集はＡ４横で行われたがプリンタ装置にＡ４縦の用紙トレイしかない場合に、プリンタ装置側で９０度回転して処理することにより使用可能なＡ４縦の用紙トレイを用いた印刷を行うことができる。また、この種のプリント装置を使用し、ホスト装置において縦置きの書式で編集された文書であっても、プリンタ装置側ではこれを横置きに回転させてから印刷するようにしてもよい。このようにすることにより、１回の印刷に必要な印刷装置の送り量を少なくすることができるため、連続印刷速度を速くすることができる。
【００２８】
さて、このようなプリント装置を用いて前掲図１３または図１５のプリントシステムを構成するものとする。
【００２９】
まず、図１３または図１５に示すプリントシステムにおいて、ホスト装置を操作するユーザは、用紙のサイズおよび向きなどを設定して文書を編集するのが一般的である。しかし、このユーザが設定した用紙を供給する用紙トレイがプリンタ装置側に用意されていないという場合が起こりうる。この場合にプリンタ装置側では、使用可能な用紙トレイを使用して印刷を行うべく、ホスト装置によって作成された文書に対して回転処理や拡大または縮小処理を必要に応じて施すことになる。また、連続印刷速度を高めるべく、プリンタ装置側において常に横置きの書式で印刷を行うようにしている場合もある。この場合もホスト装置側において縦置きの書式で文書が作成された場合には、プリンタ装置側ではその文書を横置きの書式の文書に回転して印刷を行うこととなる。
【００３０】
このような回転処理や拡大または縮小処理がプリンタ装置側で行われるような場合において、ホスト装置側でプリンタ装置側に書体データが装備されていない文字の描画コマンドが発生すると、以下説明する新たな問題が生じることとなるのである。
【００３１】
すなわち、このような文字の印刷を行う場合には、当該文字のラスタデータがホスト装置側で発生され、これが描画コマンドとしてプリンタ装置側に送られることとなるが、このラスタデータはユーザによってホスト装置に設定された用紙向きおよび用紙のサイズに対応したラスタデータとなっている。従って、このようなラスタデータを受け取るプリンタ装置側では、実際の印刷時の用紙の向きまたはサイズに適合するように、ラスタデータに対して回転処理や拡大または縮小処理を行うか、あるいはラスタデータを印刷装置用の出力バッファにそのまま書き込み、この書き込み順序とは異なった順序でラスタデータを構成する各データを出力バッファから読み出して回転処理を行う等の方法を採らなければならない。いずれにしても、このような処理を行うためには、時間および回転処理に使用する膨大な記憶容量の記憶領域が必要になる（図１７参照）。また、プリンタ装置側での回転処理のための処理時間によっては、印刷装置の印刷速度に間に合わなくなる可能性もある。
【００３２】
この発明は以上説明した事情に鑑みてなされたものであり、ホスト装置およびプリンタ装置間のトラヒック量を抑え、処理速度を犠牲にすることなく、多種の書体による印刷を行うことを可能にする画像処理装置およびプリンタ装置を提供することを目的としている。
【００３３】
【課題を解決するための手段】
請求項１に記載の発明は、ホスト装置からプリンタ装置へ送られる描画データの処理を行う画像処理装置において、データを記憶するキャッシュメモリと、前記プリンタ装置に特定の書体に対応する書体データが装備されていない文字の当該特定の書体での描画指示が前記ホスト装置側に発生し、かつ、当該文字の当該特定の書体に対応した抽象化描画データが前記キャッシュメモリに記憶されていない場合に、当該文字の当該特定の書体に対応したベクタ形式のアウトラインフォーマットデータ、または、ランレングス形式のラスタフォーマットデータである抽象化描画データを生成する描画データ生成手段と、前記描画データ生成手段によって生成された抽象化描画データを前記プリンタ装置に送信する送信手段と、前記描画データ生成手段によって生成された抽象化描画データを前記キャッシュメモリに格納する格納手段と、前記プリンタ装置に特定の書体に対応する書体データが装備されていない文字の当該特定の書体での描画指示が前記ホスト装置側に発生し、かつ、当該文字の当該特定の書体に対応した抽象化描画データが前記キャッシュメモリに記憶されている場合には、前記描画データ生成手段は当該文字の当該特定の書体に対応した抽象化描画データを生成せず、前記送信手段は前記キャッシュメモリに記憶された当該文字の当該特定の書体に対応した抽象化描画データを前記プリンタ装置に送信することを特徴とする画像処理装置を提供する。
【００３４】
請求項２に記載の発明は、請求項１に記載の画像処理装置において、前記プリンタ装置との間で双方向通信が可能な場合には、前記プリンタ装置からの印刷に使用される用紙のサイズおよび向きに関する情報を取得することにより、前記プリント装置において行われる描画処理において画像のサイズまたは向きを使用可能な印刷用紙のサイズまたは向きに適合させる変換処理が行われるか否かを判定し、前記プリンタ装置との間で双方向通信をすることができない場合には、予め記憶した当該プリント装置における使用可能な用紙のサイズおよび向きに関する情報に基づき、前記変換処理が行われるか否かを判定する判定手段を具備し、前記描画データ生成手段は、前記変換処理が行われない旨の判定が前記判定手段によってなされた場合には、ランレングス圧縮形式のラスタフォーマットデータを前記抽象化描画データとして生成し、前記変換処理が行われる旨の判定が前記判定手段によってなされた場合には、ベクタ形式のアウトラインフォーマットデータを前記抽象化描画データとして生成することを特徴とする。
【００３５】
請求項３に記載の発明は、請求項１または２に記載の画像処理装置において、前記送信手段によって送信された抽象化描画データが前記プリンタ装置のキャッシュメモリに記憶された場合に、該抽象化描画データを特定する情報を記憶するダウンロードキャッシュ管理テーブルを具備し、前記描画データ生成手段によって生成すべき抽象化描画データを特定する情報が前記ダウンロードキャッシュ管理テーブルに記憶されている場合には、前記描画データ生成手段は、当該抽象化描画データの生成を行わず、前記送信手段は、当該抽象化描画データを指定した描画指示を前記プリンタ装置に送信することを特徴とする。
【００３６】
請求項４に記載の発明は、請求項３に記載の画像処理装置において、前記ダウンロードキャッシュ管理テーブルは、前記プリンタ装置のキャッシュメモリに保持されている抽象化描画データが最後にアクセスされた日時、および、前記プリンタ装置のキャッシュメモリに抽象化描画データが格納された日時を、当該抽象化描画データを特定する情報と対応付けて記憶し、前記送信手段は、前記プリンタ装置に送信すべき新たな抽象化描画データがあり、かつ、該抽象化描画データを格納するのに必要な記憶エリアが前記キャッシュメモリに残されていないと判断される場合に、前記ダウンロードキャッシュ管理テーブルに記憶された情報に基づいて、最も長く使用されていない抽象化描画データを特定し、この抽象化描画データが格納されている記憶エリアに新たな抽象化描画データを格納すべき旨の指示を前記プリンタ装置に送ることを特徴とする。
【００４８】
【発明の実施の形態】
以下、図面を参照し、本発明の実施の形態について説明する。
【００４９】
Ａ．第１の実施形態
図１はこの発明の第１の実施形態である画像処理装置を含んだプリントシステムの構成を示すブロック図である。なお、この図１において、前掲図１３または図１５と対応する部分には同一の符号が付されている。
【００５０】
前掲図１３または図１５のプリントシステムでは、ホスト装置１側の描画ライブラリ１３内にフォントラスタライザ１３１が設けられており、プリンタ装置２側に書体データが装備されていない文字については、このフォントラスタライザ１３１により当該文字の書体データをラスタデータに展開するようにしていた。
【００５１】
これに対し、本実施形態におけるホスト装置１側の描画ライブラリ１３には、このフォントラスタライザ１３１に代えて、フォント展開処理手段１３１Ａが設けられている。このフォント展開処理手段１３１Ａは、プリンタドライバ１２からの展開要求に従い、文字の書体データを抽象化描画データに変換する手段である。
【００５２】
ここで、抽象化描画データについて説明する。この抽象化描画データとは、例えばベクタ形式のアウトラインフォーマットによって定義されるようなデータであり、文字の書体データとラスタデータとの中間の抽象度を有するデータである。この種の抽象化形式の描画データは、文字の書体データから生成することができ、また、この抽象化描画データからラスタデータを生成することができる。図４はベクタ形式のフォーマットの一例を示すものである。この種の抽象化描画データをラスタデータラスタデータと比較した場合、後者のものは文字が大きくなるとその２乗のオーダでデータサイズが増大するのに対し、前者のものはそのデータサイズが文字の大きさの変化に殆ど依存しない。
【００５３】
例えば、白黒２値のデータからなるラスタデータにより、一般に使用頻度が高いと思われる大きさである６００ｄｐｉ、１０．５ｐｏｉｎｔの文字を印刷するものとすると、このときのラスタデータは１ｋｂｙｔｅｓ弱のデータサイズとなる。これに対し、ベクタ形式の描画データは、文字を構成する線種の数と制御点列のみにより文字を表現したデータであるため、そのデータサイズは小さなものとなる。例えば、線種を１本当たり４ｂｉｔ、制御点を１組当たり４ｂｙｔｅｓにより表現し、線種が５０本、制御点列が１００組の比較的複雑な文字のベクタ形式の描画データを生成するものとすると、そのデータサイズは５０＊０．５＋１００＊４＝４２５ｂｙｔｅｓとなり、上記ラスタデータのデータサイズの半分程度の大きさとなる。勿論、ベクタ形式の描画データの場合、文字の形によって線数、制御点数が変化するため、上記データサイズはあくまでも計算例に止まる。しかし、通常の文章に使用されるような使用頻度の高い文字群について考えると、そのような文字群には、上記のような複雑な形のものばかりではなく、簡単な形のものも多数含まれている。従って、これらの文字を平均すれば、抽象化形式の描画データのデータサイズは、ラスタデータのデータサイズの半分以下になると考えられる。
【００５４】
また、本実施形態におけるホスト装置１側の描画ライブラリ１３には、フォントキャッシュ１３４が設けられている。このフォントキャッシュ１３は、フォント展開処理手段１３１Ａによって生成された抽象化描画データを記憶するキャッシュメモリである。本実施形態では、フォント展開処理手段１３１Ａによって生成された抽象化描画データをこのフォントキャッシュ１３４に格納し、再度、同じ抽象化描画データが必要になった場合にはこのフォントキャッシュ１３４内の抽象化描画データを再利用することで、同一内容の抽象化描画データが重複して生成されるのを回避している。
【００５５】
また、本実施形態では、このフォントキャッシュ１３４内の抽象化描画データについて、いわゆるＬＲＵ（Least Recently Use）法により追い出し制御を行う。すなわち、フォントキャッシュ１３４の空き容量が不足し、新たなデータの格納を行うことができない状況となった場合、同フォントキャッシュ１３４に記憶されたデータのうち最も長く使用されていないものを追い出し、新たなデータを書き込むための空きエリアを確保するのである。このようなＬＲＵ法による追い出し制御を行うため、本実施形態では、フォントキャッシュ１３４内に現在格納されている各描画データを特定するデータを最も古い描画データ（すなわち、最も長く使用されていない描画データ）に対応したものから順に並べたデータ列をキャッシュ管理データとして保持するようにしている。なお、追い出し制御の方法は、ＬＲＵ法に限定されるものではなく、当業者が任意に選択すればよい。
【００５６】
一方、プリンタ装置２側のデコンポーザ２１には、出力用フォントデータ生成モジュール２１８が設けられている。この出力用フォントデータ生成モジュール２１８は、インタプリタ２１１を介して供給される描画コマンドを構成する抽象化形式のフォントデータからラスタデータを生成する手段である。
【００５７】
図２はホスト装置１の動作を示すフローチャート、図３はプリンタ装置の動作を示すフローチャートである。以下、これらの図を参照し、本実施形態の動作を説明する。
【００５８】
ホスト装置１では、アプリケーションソフトウエア１１に従って、紙面の編集が行われる。そして、紙面の編集後、印刷の指示がホスト装置１に与えられると、この紙面を構成している各描画オブジェクトについて描画指示がアプリケーションソフトウエア１１を介してプリンタドライバ１２に送る。
【００５９】
プリンタドライバ１１は、このアプリケーションソフトウエア１１からの描画指示を受け取ると、その描画指示がフォント描画指示か否かを判断する（ステップＳ２０１）。
【００６０】
ここで、通常のグラフィックス等についての描画指示が与えられた場合には、プリンタドライバ１１は、その描画指示からプリンタ装置２向けの描画コマンドを作成し（ステップＳ２０２）、プリンタ装置２側へ出力する（ステップＳ２０３）。このとき、前述のようにホスト装置１では実際の印刷時の用紙のサイズや向きを想定して編集作業が行われるため、このホスト装置１側が想定している用紙のサイズや向きの情報もプリンタ装置２に送信される。
【００６１】
一方、アプリケーションソフトウエア１１を介して文字の描画指示があった場合、プリンタドライバ１２は、当該文字に対応した書体データの所在を書体管理部１３２に問い合わせる。書体管理部１３２は、この問い合わせを受けると、プリンタ装置２に装備されている書体のリストをプリンタ情報モジュール１３３から読み出すとともに、ホスト装置１に装備されている書体のリストを図示しないメモリから読み出す。そして、当該文字の書体データがプリンタ装置２またはホスト装置のいずれに装備されているかを判断し、その結果を上記問い合わせに対する回答としてプリンタドライバ１２に送る（以上、ステップＳ２０４）。
【００６２】
プリンタドライバ１２は、当該文字の書体データがプリンタ装置２に装備されている旨の回答を書体管理部１３２から受け取った場合、書体ＩＤと文字コードおよび文字の大きさを表す情報等からなる当該文字を特定するパラメータを含んだ描画コマンドを生成し（ステップＳ２０５）、プリンタ装置２に送信する（ステップＳ２０６）。
【００６３】
これに対し、当該文字の書体データがプリンタ装置２に装備されておらず、ホスト装置１にのみ装備されている旨の回答を書体管理部１３２から受け取った場合、プリンタドライバ１２は、当該書体データの展開要求をフォント展開処理部１３１Ａに送る。
【００６４】
フォント展開処理部１３１Ａは、この展開要求を受け取ると、当該書体データに対応した抽象化描画データがフォントキャッシュ１３４に格納されているか否かを判断する（ステップＳ２０７）。
【００６５】
そして、印刷すべき文字の抽象化描画データがフォントキャッシュ１３４に格納されていない場合、フォント展開処理部１３１Ａは、ホスト装置１に装備されている当該文字の書体データを書体管理部１３２を介して取得し、この書体データから抽象化描画データを生成し、プリンタドライバ１２に送る（ステップＳ２０８）。
【００６６】
次に、フォント展開処理部１３１Ａは、以上説明したような抽象化描画データをステップＳ２０８において生成すると、この描画データをフォントキャッシュ１３４に格納し、キャッシュ管理データの更新を行う（ステップＳ２０９）。
【００６７】
ここで、ステップＳ２０９においては、フォント展開処理部１３１Ａによって生成された描画データをフォントキャッシュ１３４に格納するが、そのための空きエリアがフォントキャッシュ１３４内にない場合もある。かかる場合には、キャッシュ管理データによって特定される最も古い描画データから順にフォントキャッシュ１３４から追い出し、このようにして確保されたフォントキャッシュ１３４内の空きエリアに新たな描画データを書き込むのである。また、この場合には、フォントキャッシュ１３４内に新たに格納した描画データを特定するデータをキャッシュ管理データの最後尾に配置し、追い出した描画データを特定するデータをキャッシュ管理データ中から削除するのである。
【００６８】
一方、ステップＳ２０７における判断結果が「ＹＥＳ」である場合、フォント展開処理部１３１Ａは、該当する抽象化描画データをフォントキャッシュ１３４から読み出してプリンタドライバ１２へ送り、キャッシュ管理データの更新を行う（ステップＳ２０８）。この場合のキャッシュ管理データの更新は、ステップＳ２０８においてフォントキャッシュ１３４から読み出された抽象化描画データを特定するデータをキャッシュ管理データの最後尾に移動することにより行う。
【００６９】
本実施形態によれば、このようにフォント展開処理部１３１Ａにより生成した抽象化形式の描画データをフォントキャッシュ１３４に格納し、同一文字についての描画データが要求された場合にはこのフォントキャッシュ１３４内の描画データを読み出して使用するようにしているので、描画データの生成のための負担を減らすことができる。一般の文章においては、フォントキャッシュのヒット率は８０〜９０％を越えることもあるため、このようなキャッシュ記憶の導入は極めて効果的であると考えられる。
【００７０】
次に、プリンタドライバ１２は、以上のようにしてフォント展開処理部１３１Ａから送られてくる抽象化形式の描画データを受け取ると、その描画データを用いて抽象化形式の描画データ専用の描画コマンドを生成し、プリンタ装置２に送信する（ステップＳ２０６）。
以上がホスト装置１側の動作である。
【００７１】
次にプリンタ装置２の動作について説明する。
プリンタ装置２におけるインタプリタ２１１は、以上のようにしてホスト装置１側から送信された描画コマンドを受信し、その解釈および実行を行う。
【００７２】
ここで、ホスト装置１から最初に送られてくるコマンドは、ユーザがアプリケーションにおいて指定した用紙サイズおよび向きを指定するコマンドである。これは、用紙のサイズと向きを決定しないと、プリンタ装置２側においてどの用紙トレイを使用するかを決定することができないからである。
【００７３】
インタプリタ２１１は、上記の用紙サイズおよび向きを指定するコマンドをホスト装置１から受け取ると、このコマンドを用紙監視モジュール２１６に通知する。ここで、用紙監視モジュール２１６は、プリンタ装置２が用意している用紙トレイの状態や紙切れの発生の有無などを常時監視している。また、連続印刷速度を高めるために、横置きでの印刷しか行わないようなモード設定がなされた場合には、その旨を検知する。そして、用紙監視モジュール２１６は、上記監視結果および検知結果に基づき、印刷の際の用紙サイズおよび向きを決定するとともに、そのような印刷を行う際に必要な変換処理のためのマトリックスを生成し、インタプリタ２１１に対してその変換マトリックスを使用した変換処理（以下、用紙対応の変換処理という。）を指示する。例えば次の通りである。
【００７４】
ａ．紙切れなどの原因により、ユーザが指定した用紙サイズの用紙がなく、しかも、そのような場合には最も近い用紙サイズの用紙を使用して印刷を行ってもよい旨がプリンタ装置に設定されている場合には、その最も近い用紙サイズの用紙を使用して印刷を行うこととし、この印刷を行うのに必要な拡大または縮小処理をインタプリタ２１１に指示する。例えばユーザが指定した用紙サイズがＢ５サイズであるが、その用紙がプリンタ装置２になく、Ａ４サイズの用紙ならばある場合には、Ａ４サイズ／Ｂ５サイズの倍率での拡大処理を行うための変換マトリックスを生成し、描画の際にこの変換マトリックスを使用した拡大処理を行うべき旨をインタプリタ２１１に指示する。
【００７５】
ｂ．ユーザが指定した用紙の向きでの印刷を行うことができない場合に、印刷の際には使用可能な用紙の向きに合わせて印刷を行うための回転処理を行う旨を決定する。例えばユーザはＡ５縦置きでの印刷を指定しているが、その用紙がプリンタ装置２になかったり、あるいは連続印刷速度を高めるために横置きでの印刷した行わないように設定されている場合に、９０度の回転処理を施すための変換マトリックスを生成し、描画の際にこの変換マトリックスを使用した回転処理を行うべき旨をインタプリタ２１１に指示する。
【００７６】
上記の用紙サイズおよび向きを指定するコマンドに続き、文書などの印刷を行うための描画コマンドがホスト装置１からプリンタ装置２に順次送られる。図３に示すフローは、この描画コマンドに対応したプリンタ装置２の動作を示すものである。
【００７７】
まず、インタプリタ２１１は、描画コマンドを受信すると、その描画コマンドが抽象化描画データ専用の描画コマンドか否かを判断する（ステップＳ３０１）。この判断結果が「ＮＯ」である場合、インタプリタ２１１は、基本描画モジュール２１７を実行し、ホスト装置１から受信した描画コマンドに従って通常の描画処理を行い、ラスタデータを生成する（ステップＳ３０２）。
【００７８】
このとき用紙監視モジュールから用紙対応の変換処理が指示されている場合には、描画処理において当該変換処理も同時に行う。ここで、プリンタ装置向けの描画コマンドは、一般的にベクタ描画コマンドが主である。このホスト装置１からの描画コマンドがこのベクタ描画コマンドである場合、インタプリタ２１１では、描画コマンドからラスタデータを生成するベクタ／ラスタ変換のためのマトリックスに対して、上記用紙対応の変換処理のための変換マトリックスを連結して使用するのみにより、用紙監視モジュールから指示された変換処理の施されたラスタデータを得ることができる。従って、用紙監視モジュールから変換処理が指示されている場合であっても、そうでない場合であっても、描画処理の速度に変化はない。
【００７９】
次にインタプリタ２１１は、上記描画処理により得られたラスタデータを出力用バッファ２１３に書き込む（ステップＳ３０３）。この出力用バッファ２１３に書き込まれたラスタデータは、その後、印刷装置２２に引き渡される。そして、印刷装置２２により、ラスタデータに従って印刷が行われる。
【００８０】
一方、ステップＳ３０１における判断結果が「ＹＥＳ」である場合、インタプリタ２１１は、出力用フォントデータ生成モジュール２１８を実行し、受信した抽象化描画データ専用の描画コマンドに従って描画処理を行う。すなわち、この描画コマンドに含まれる抽象化形式の描画データをラスタデータに変換する（ステップＳ３０４）。
【００８１】
このときインタプリタ２１１は、用紙監視モジュール２１６から用紙対応の変換処理の指示を受け取っている場合には、描画コマンドに含まれるベクタ形式の抽象化描画データに対し、指示された変換処理を施す。そして、この変換処理を経た描画データから最終的な出力形式であるラスタデータを生成する。
【００８２】
次にインタプリタ２１１は、上記描画処理により得られたラスタデータを出力用バッファ２１３に書き込む（ステップＳ３０５）。この出力用バッファ２１３に書き込まれたラスタデータは、その後、印刷装置２２に引き渡される（ステップＳ３０６）。そして、印刷装置２２により、ラスタデータに従って印刷が行われる。
【００８３】
以上が本実施形態の動作である。本実施形態に係るプリントシステムの利点を前掲図１３または図１５に記載のプリントシステムと対比しつつ検討すると次の通りである。
【００８４】
（１）印刷品質について
前掲図１３または図１５に記載のプリントシステムでは、プリンタ装置側に書体データが装備されていない文字の印刷を行う場合に、その文字のラスタデータをホスト装置からプリンタ装置に送った。この場合において、描画の際に回転や拡大または縮小などの変換処理を行うべき旨が指示されているものとすると、ラスタデータに対して変換処理を施すこととなり、印刷品質の劣化を招くこととなる。
【００８５】
これに対し、本実施形態では、ホスト装置からプリンタ装置に送られるのはラスタデータではなく抽象化形式の描画データであり、変換処理が指示されている場合には、この描画データに対して変換処理がなされる。従って、最終的な出力フォーマットでの印刷品質の劣化を招くことなく、変換処理を行うことができる。
【００８６】
（２）トラヒック量および処理速度について
本実施形態においては、プリンタ装置側において書体データが装備されていない文字の印刷を行う場合に、ホスト装置側から送られてくる抽象化描画データをラスタデータに変換して印刷を行うこととなるため、この変換のための時間が余分に必要となる。従って、用紙の回転や拡大または縮小が全く指定されない場合には、前掲図１３または図１５に記載のプリントシステムのように、ホスト装置側からプリンタ装置側にラスタデータを送り、プリンタ装置側ではこのラスタデータをそのまま使用して印刷を行う方が、本実施形態のものよりもプリンタ装置側の処理を高速化することができる。
【００８７】
しかし、ラスタデータはデータ量が多いので、ホスト装置からプリンタ装置へのトラヒック量が大きなものとなり、このトラヒック量がネックとなって、プリントシステム全体としての性能が低下する可能性が高い。従って、ホスト装置およびプリンタ装置間でラスタデータの授受を行う構成とするのは得策ではない。
【００８８】
ここで、ホスト装置側においてプリントドライバがラスタデータを圧縮して送信し、プリンタ装置側でこの圧縮されたラスタデータを伸長して使用することによって、ホスト装置およびプリンタ装置間のトラヒック量を減らす方法を採ることも考えられる。しかし、この方法においては、ホスト装置側での圧縮処理およびプリンタ装置側での伸長処理のための時間が余分に掛かることとなる。従って、この時間を含めてプリンタ装置側の処理時間を本実施形態の場合と比較すると、両者の間には大きな差は生じないということができる。
【００８９】
また、プリンタ装置側において、描画の際に回転処理や拡大または縮小処理などの変換処理を行う場合には、その変換処理の対象がラスタデータであると、処理時間が極めて長くなってしまう。
【００９０】
従って、以上説明した全ての事情を考慮に入れると、本実施形態に係るプリントシステムの方が、前掲図１３または図１５に記載のプリントシステムに比較し、総合的に優れた性能を有しているということができる。
【００９１】
Ｂ．第２の実施形態
上記第１の実施形態においては、プリンタ装置側において描画の際に回転処理や拡大または縮小処理が行われる場合があるので、そのような場合をも考慮してベクタ形式の抽象化描画データをホスト装置からプリンタ装置へ送るようにした。しかし、プリントシステムの中には、プリンタ装置が描画の際に回転処理や拡大または縮小処理を行う機能を有していないものもある。また、この他、プリント装置側での変換処理を不要にしたプリントシステム、すなわち、プリンタ装置側において使用可能な用紙サイズおよび用紙の向きをホスト装置側が常時把握し、ユーザが指定する用紙サイズや用紙の向きがこれと一致していない場合には、ホスト装置側において、必要な回転処理や拡大または縮小処理などの変換処理を描画データに施して送信するプリントシステムもある。本実施形態は、このようなプリンタ装置側において描画の際に変換処理を行うことのないプリントシステムに本発明を適用したものである。
【００９２】
本実施形態に係るプリントシステムでは、プリント装置に書体データが装備されていない文字についての描画コマンドがホスト装置側に発生した場合、上記第１の実施形態におけるベクタ形式のアウトラインフォーマットの抽象化描画データよりも抽象度の低いフォーマットの抽象化描画データをホスト装置において生成し、プリンタ装置に送る。
【００９３】
具体的には、本実施形態では、例えばホスト装置側において上記文字の書体データからラスタデータを生成し、このラスタデータをランレングスフォーマットに圧縮し、この圧縮データをプリント装置側に送る。そして、プリンタ装置側では、このランレングスフォーマットの圧縮データをラスタデータに伸長し、その印刷を行うのである。
【００９４】
ここで、ラスタデータは印刷画像を構成する各ドットに対応したビットからなるビットマップデータであるが、ランレングス形式の圧縮データは印刷画像のドット群を例えば水平方向に走査し、走査された連続ドット群の各々の長さを表す情報を集めて構成したものである。図５はランレングス形式の圧縮データの構成例を示すものである。このランレングス形式は、圧縮フォーマットの中でもラスタ形式に近いため、圧縮率は低いが、圧縮および伸長に要する処理時間が短くて済む。
【００９５】
ただし、このランレングス形式をホスト装置からプリンタ装置へ送る抽象化描画データのフォーマットとして採用する場合には、既に述べたようにプリンタ装置側では描画の際の変換処理を行わないようにすることが望ましい。何故ならば、このランレングスフォーマットの圧縮データに対して変換処理を行った場合には処理時間が長くなってしまい、また、印刷品質の劣化を招くからである。
【００９６】
また、本実施形態には以上の他に別の適用例が考えられる。すなわち、次の通りである。まず、プリント装置における印刷装置への出力フォーマットはラスタ形式が一般的であるが、印刷装置の中には上述したランレングス形式やデイスプレイリストと呼ばれるような中間形式のデータを直接入力する方式のものもある。ここで、プリンタ装置が例えばデイスプレイリストの入力が必要な印刷装置によって構成されているものとすると、ホスト装置からプリンタ装置へラスタデータを送った場合には、プリンタ装置側ではこのラスタデータから中間形式のデイスプレイリストを再度生成する逆変換を行う必要が生じ、極めて非効率的である。本実施形態は、このような印刷装置によって構成されたプリント装置を含むシステムにも好適である。
【００９７】
すなわち、プリンタ装置における印刷装置への出力フォーマットがラスタ形式ではなく、ランレングス形式やデイスプレイリストなどの中間形式である場合、本実施形態では、ラスタ形式ではなく、この出力フォーマットと同一、若しくは、より抽象度の高いフォーマットの抽象化描画データをホスト装置側で生成し、プリンタ装置側へ送るようにするのである。このようにすることで、より効率の高いプリントシステムを構成することができる。
【００９８】
Ｃ．第３の実施形態
図６はこの発明の第３の実施形態であるプリントシステムの構成を示すブロック図である。なお、この図において、前掲図１と対応する部分には同一の符号が付されている。
【００９９】
図６において、ホスト装置１には各種のプリンタ装置２がネットワークなどを介して接続される。そして、ホスト装置１の描画ライブラリ１３におけるプリンタ情報モジュール１３３は、これらの各プリンタ装置毎に、そのプリント装置の解像度、装備している用紙トレイ、用紙トレイに収納されている用紙のサイズおよび向きなどのプリンタ情報を予め保持している。
【０１００】
一方、ホスト装置１に接続される各プリンタ装置２の中には、ホスト装置１との間で双方向通信が可能なものもある。これらのプリンタ装置２では、使用可能な用紙のサイズおよび向きが用紙監視モジュール２１６によって常時監視され、その監視結果がリアルタイムにホスト装置１に報告される。従って、ホスト装置１は、これらのプリンタ装置２については、使用可能な用紙のサイズおよび向きを判断することができる。
【０１０１】
本実施形態におけるホスト装置１は、双方向通信が可能なプリンタ装置に印刷を行わせる場合には、当該プリンタ装置の用紙監視モジュール２１６を介して取得される情報を利用し、双方向通信が不可能なプリンタ装置に印刷を行わせる場合には上記プリンタ情報モジュール１３３内の保持情報を参照することにより、プリンタ装置側において用紙対応の変換処理が行われるか否かを判断または予測し、その結果に基づきプリンタ装置側に送る抽象化描画データの形式を設定する。図７は、このようなホスト装置側の制御の内容を示すフローチャートである。以下、このフローチャートに沿って本実施形態の動作を説明する。
【０１０２】
ホスト装置１は、アプリケーション１１からの描画指示が発生すると、印刷を行わせるプリンタ装置２と双方向通信が可能か否かを判断する（ステップＳ７０１）。
【０１０３】
この判断結果が「ＹＥＳ」である場合、ホスト装置１は、当該プリンタ装置２において使用可能な用紙のサイズおよび向きに関する情報を用紙監視モジュール２１６から取得する（ステップＳ７０２）。一方、ステップＳ７０１の判断結果が「ＮＯ」である場合、ホスト装置１は、当該プリンタ装置２に対応したプリンタ情報をプリンタ情報モジュール１３３から取得し、このプリンタ情報から当該プリンタ装置において使用可能な用紙のサイズおよび向きを予測する（ステップＳ７０３）。
【０１０４】
次にホスト装置１は、ユーザが指定した用紙のサイズおよび向きに関する情報を上記描画指示から取得し、上記ステップＳ７０２またはＳ７０３において取得したプリンタ装置側で使用可能な用紙のサイズおよび向きに関する情報と比較する。そして、ホスト装置１は、この比較結果に基づき、プリント装置側で用紙対応の変換処理が行われるか否かを判断する（ステップＳ７０４）。
【０１０５】
この判断結果が「ＹＥＳ」である場合、ホスト装置１におけるプリンタドライバ１２は、以後、書体データがプリンタ装置２に装備されていない文字についてのフォント描画指示がアプリケーション１１から与えられたときに、その書体データをフォント展開処理部１３１Ａによりベクタ形式の抽象化描画データに変換する（ステップＳ７０５）。そして、この抽象化描画データを含む描画コマンドを作成し（ステップＳ７０６）、この描画コマンドをプリンタ装置２に送る（ステップＳ７０７）。
【０１０６】
一方、ステップＳ７０４の判断結果が「ＮＯ」である場合、プリンタドライバ１２は、以後、書体データがプリンタ装置２に装備されていない文字についてのフォント描画指示がアプリケーション１１から与えられたときに、その書体データをフォント展開処理部１３１Ａによりランレングス形式の抽象化描画データに変換し（ステップＳ７０８）、この抽象化描画データを含む描画コマンドを作成し（ステップＳ７０６）、この描画コマンドをプリンタ装置２に送る（ステップＳ７０７）。なお、この場合、書体データを、ランレングス形式ではなく、ラスタデータに変換してプリンタ装置に送ってもよい。
【０１０７】
さて、以上説明した本実施形態の動作において、プリンタ装置２との双方向通信が不可能である場合におけるステップＳ７０４の判断は、あくまでも予測に止まる。何故ならば、プリンタ情報モジュール１３５に記憶されたプリント情報は、各プリンタ装置の通常の状態を反映した内容となっており、例えばプリンタ装置において紙切れなどが生じた場合には当該プリンタ装置の現在の状態とプリント情報によって表された当該プリンタ装置の状態とが異なったものとなるからである。
【０１０８】
例えばプリンタ装置２にＡ４横置きの用紙トレイとＡ４縦置きの用紙トレイが装着されているが、これらのうちＡ４縦置きの用紙トレイが紙切れ状態となっているときに、ユーザが縦置きＡ４での印刷をホスト装置１に指示したとする。この場合、ホスト装置１は、当該プリンタ装置にＡ４縦置きの用紙トレイが装備されている旨の情報がプリンタ情報モジュール１３５に保持されていることから、プリンタ装置２側において画像の変換処理は行われないと判断することとなる。しかし、実際にはＡ４縦置きの用紙トレイは紙切れとなっているので、プリンタ装置２側では描画の際に画像の回転処理を行うこととなる。
【０１０９】
この場合、ホスト装置からはランレングス形式の抽象化描画データやラスタデータが送られてくるので、プリンタ装置２側ではそれらに対する回転処理に時間が掛かり、処理速度が低下することとなる。従って、双方向通信が不可能なプリンタ装置については、紙切れなどの場合に印刷をしないように構成することも考慮に値する。勿論、処理速度の低下を許容することができる場合には、紙切れの場合であっても処理を続けるように構成すればよい。
【０１１０】
一方、双方向通信が可能なプリンタ装置については、紙切れなどの事態が生じたとしても、常にプリンタ装置の正確な状況がホスト装置１に報告される。従って、双方向通信が可能なプリンタ装置に印刷を行わせる場合におけるステップＳ７０４にお判断の結果は常に正確なものとなる。
【０１１１】
なお、プリンタ装置側で連続印刷速度を高めるために縦置きでの印刷を行わず、常に横置きでの印刷を行うような場合も考えられる。しかし、当該プリンタ装置が双方向通信が可能なものである場合には、そのような事実についてもホスト装置側で把握することができ、必要があればホスト装置側で描画データを回転してプリンタ装置に送ることができる。従って、ホスト装置側が予期しない回転処理等がプリンタ装置側で行われ、処理速度が低下する、といった不具合は発生しない。
【０１１２】
Ｄ．第４の実施形態
図８はこの発明の第４の実施形態であるプリントシステムの構成を示すブロック図である。なお、この図において、前掲図１と対応する部分には同一の符号が付されている。
【０１１３】
上記第１の実施形態では、アプリケーション１１からの描画指示毎にプリンタドライバ１２が描画コマンドを生成し、プリンタ装置２に送信した。ここで、プリンタ装置２に書体データが装備されていない文字についてのフォント描画指示がアプリケーション１１から与えられた場合には、その文字の書体データから生成された抽象化描画データを含む描画コマンドがプリンタ装置２側に送られる。しかし、同一文字についてのフォント描画指示がアプリケーション１１から与えられる場合も多く、そのような場合には同一内容の抽象化描画データが複数回重複してプリンタ装置２に送られることとなる。この発明の第４の実施形態は、このような無駄をなくすべく上記第１の実施形態に改良を加えたものである。
【０１１４】
上記の重複した抽象化描画データの送信を回避するため、本実施形態におけるプリンタ装置２のデコンポーザ２１１には、抽象化描画データを記憶するためのキャッシュ領域（以下、ダウンロード用フォントキャッシュという。）を有するキャッシュメモリ（図示略）と、ホスト装置１から送られてくる抽象化描画データをこのダウンロード用フォントキャッシュに書き込んだり、ホスト装置１からの描画コマンドに応じてダウンロード用フォントキャッシュから抽象化描画データを読み出す役割を果たすフォントダウンロードモジュール２１９が新たに設けられている。ここで、ダウンロード用フォントキャッシュに抽象化描画データを格納する際の格納アドレスは、ホスト装置１のプリンタドライバ１２によって指定される。また、新たな抽象化描画データをフォントダウンロードモジュール２１９に書き込む際に空きエリアが不足している場合には、既に記憶された抽象化描画データのうち最も長く使用されていないものに対して当該抽象化描画データを上書きする。このダウンロード用フォントキャッシュを対象としたキャッシュ追い出し制御もプリンタドライバ１２により行われる。すなわち、フォントダウンロードモジュール２１９が行うダウンロード用フォントキャッシュのアクセスは、全てプリンタドライバ１２からの指示により行われる。
【０１１５】
一方、ホスト装置１の描画ライブラリ１３には、ダウンロードキャッシュ管理テーブル１３５が新たに設けられている。このダウンロードキャッシュ管理テーブル１３５は、プリンタ装置２側のダウンロード用フォントキャッシュに格納された各抽象化描画データについて、以下の情報からなるキャッシュ管理データを記憶するためのテーブルである。
ａ．各抽象化描画データを特定する情報
ｂ．各抽象化描画データが格納されているダウンロード用フォントキャッシュ内の格納アドレス
ｃ．各抽象化描画データの追い出し制御を行うための情報（具体的には最後に当該抽象化描画データがアクセスされた日時などの情報である）
【０１１６】
図９は本実施形態におけるホスト装置の動作を示すフローチャート、図１０は本実施形態におけるプリンタ装置の動作を示すフローチャートである。以下、これらの図を参照し、本実施形態の動作を説明する。
【０１１７】
ホスト装置１では、アプリケーションソフトウエア１１からの描画指示がプリンタドライバ１２に与えられると、プリンタドライバ１２は、その描画指示がフォント描画指示か否かを判断する（ステップＳ９０１）。
【０１１８】
ここで、通常のグラフィックス等についての描画指示が与えられた場合には、プリンタドライバ１１は、その描画指示からプリンタ装置２向けの描画コマンドを作成し（ステップＳ９０２）、プリンタ装置２側へ出力する（ステップＳ９０３）。
【０１１９】
一方、アプリケーションソフトウエア１１を介して文字のフォント描画指示があった場合、プリンタドライバ１２は、書体管理部１３２に問い合わせを行うことにより、当該文字の書体データがプリンタ装置２に装備されているか否かを判断する（ステップＳ９０４）。
【０１２０】
そして、当該文字の書体データがプリンタ装置２に装備されている場合には、プリンタドライバ１２は、書体ＩＤと文字コードおよび文字の大きさを表す情報等からなる当該文字を特定するパラメータを含んだ描画コマンドを生成し（ステップＳ９０５）、プリンタ装置２に送信する（ステップＳ９０６）。
【０１２１】
これに対し、当該文字の書体データがプリンタ装置２に装備されておらず、ホスト装置１にのみ装備されている場合、プリンタドライバ１２は、当該文字に対応した抽象化描画データがプリンタ装置２側に既に送られているか否かをダウンロードキャッシュ管理モジュール１３５に問い合わせる（ステップＳ９０７）。
【０１２２】
ここで、当該文字に対応した抽象化描画データがプリンタ装置２側に既に送られている場合、プリンタドライバ１２は、そのダウンロード済みの抽象化描画データを用いて描画を行うべき旨のダウンロードフォント描画コマンドを作成し（ステップＳ９０５）、プリンタ装置Ｓ９０６に送信する（ステップＳ９０６）。ここで、ダウンロードフォント描画コマンドには、ダウンロード済みの抽象化描画データの識別子として、当該抽象化描画データの格納アドレスを示す情報が含まれているが、その抽象化描画データ自体は含まれていない。
【０１２３】
また、この場合、ホスト装置１では、識別子の送信を行った抽象化描画データについて、ダウンロードキャッシュ管理テーブル１３５内のキャッシュ管理データにおける追い出し制御のための情報を更新する（ステップＳ９０８）。
【０１２４】
一方、当該文字に対応した抽象化描画データがプリンタ装置２側に未だ送られていない場合、プリンタドライバ１２は、当該文字の書体データを抽象化描画データに展開すべき旨の要求をフォント展開処理部１３１Ａに送る。
【０１２５】
フォント展開処理部１３１Ａは、この展開要求を受け取ると、当該文字に対応した抽象化描画データがフォントキャッシュ１３４に格納されているか否かを判断する（ステップＳ９０９）。
【０１２６】
そして、当該文字の抽象化描画データがフォントキャッシュ１３４に格納されていない場合、フォント展開処理部１３１Ａは、その文字のフォント種ＩＤ、文字識別コード、文字の大きさ、ホスト装置上で設定されている用紙方向およびプリンタ装置２の出力解像度をパラメータとして、当該文字の抽象化描画データを生成する（ステップＳ９１０）。
【０１２７】
次にフォント展開処理部１３１Ａは、この生成した抽象化描画データをフォントキャッシュ１３４に格納するとともにプリンタドライバ１２に送る。プリンタドライバ１２は、ダウンロードキャッシュ管理テーブル１３５を参照することにより、ダウンロード用フォントキャッシュ内の空きエリアを求め、この空きエリア内に上記抽象化描画データの格納エリアを定める。そして、上記抽象化描画データを特定する情報、上記抽象化描画データの格納エリアを示す情報および追い出し制御のための情報（この場合、現在の日時などの情報）からなるキャッシュ管理データをダウンロードキャッシュ管理テーブル１３５に登録する（ステップＳ９１１）。
【０１２８】
なお、ステップＳ９１１において、抽象化描画データを格納する空きエリアが見つからない場合もある。かかる場合にプリンタドライバ１２は、ダウンロードキャッシュ管理テーブル１３５内の追い出し制御のための情報を参照することにより、ダウンロード用フォントキャッシュ内に記憶されている抽象化描画データのうち最も長く使用されていないものを求め、その格納エリアを新たな抽象化描画データの格納エリアに当てる。
【０１２９】
一方、ステップＳ９０９における判断結果が「ＹＥＳ」である場合、フォント展開処理部１３１Ａは、その抽象化描画データをフォントキャッシュ１３４から読み出してプリンタドライバ１２へ送る。そして、プリンタドライバ１２は、上記ステップＳ９１１と同様の方法により、ダウンロード用フォントキャッシュにおける当該抽象化描画データの格納エリアを定め、当該抽象化描画データに対応したキャッシュ管理データをダウンロードキャッシュ管理テーブル１３５に登録する（ステップＳ９１２）。
【０１３０】
次に、プリンタドライバ１２は、以上のようにしてフォント展開処理部１３１Ａから送られてくる抽象化描画データを受け取ると、その抽象化描画データと、ダウンロード用フォントキャッシュにおける当該抽象化描画データの格納エリアを指定する情報とからなるダウンロードコマンドを含んだ描画コマンドを生成し（ステップＳ９０５）、プリンタ装置２に送信する（ステップＳ９０６）。
以上がホスト装置１側の動作である。
【０１３１】
次にプリンタ装置２の動作について説明する。
プリンタ装置２におけるインタプリタ２１１は、ホスト装置１からの描画コマンドを受信すると、その描画コマンドがダウンロードフォント描画コマンドか否かを判断する（ステップＳ１００１）。
【０１３２】
この判断結果が「ＹＥＳ」である場合、インタプリタ２１１は、そのダウンロードフォント描画コマンドから抽象化描画データの識別子（すなわち、格納アドレス）を取り出し、フォントダウンロードモジュール２１９内の当該格納アドレスから抽象化描画データを読み出す。そして、インタプリタ２１１は、用紙監視モジュール２１６からの画像の回転や拡大または縮小の指示が与えられている場合には、その指示を取得する（ステップＳ１００２）。
【０１３３】
次いでインタプリタ２１１は、出力用フォントデータ生成モジュール２１８により、上記抽象化描画データから、出力形式であるラスタデータを生成する（ステップＳ１００３）。ここで、抽象化描画データがベクタ形式のものである場合、ラスタデータは、ベクタ／ラスタ変換により生成される。また、インタプリタ２１１は、上記ステップＳ１００２において回転などの指示を取得している場合にはこのラスタデータの生成の際に回転などの変換処理を併せて行う。そして、インタプリタ２１１は、このようにして生成したラスタデータを出力用バッファ２１３に書き込む（ステップＳ１００４）。これにより、このラスタデータを使用して印刷が行われる（ステップＳ１００５）。
【０１３４】
一方、ステップＳ１００１の判断結果が「ＮＯ」である場合、インタプリタ２１１は、描画コマンドがダウンロードコマンドを含んでいるか否かを判断する（ステップＳ１００６）。
【０１３５】
そして、この判断結果が「ＹＥＳ」である場合、インタプリタ２１１は、描画コマンドからダウンロードコマンドを取り出する。そして、フォントダウンロードモジュール２１９により、そのダウンロードコマンドに従って抽象化描画データをダウンロード用フォントキャッシュに格納する（ステップＳ１００７）。この場合、ダウンロードコマンドによって特定されるダウンロード用フォントキャッシュ内のエリアに別の抽象化描画データが既に格納されていることもありうる。そのような場合であっても、フォントダウンロードモジュール２１９は、ダウンロードコマンドによって指定されたエリアに抽象化描画データを書き込む。以後、インタプリタ２１１は、この抽象化描画データに対し、既に説明したステップＳ１００２〜Ｓ１００５の処理を行う。
【０１３６】
なお、ステップＳ１００６における判断結果が「ＮＯ」である場合には、ホスト装置１から受信した描画コマンドは、プリンタ装置２に書体データが装備されている文字の描画コマンドまたはグラフィックなどの描画処理を指示するコマンドであるので、基本描画モジュール２１７による通常の描画処理を行い（ステップＳ１００８）、その結果得られるラスタデータを出力用バッファ２１３に書き込む（ステップＳ１００９）。
以上がプリンタ装置側の動作である。
【０１３７】
本実施形態によれば、既にプリンタ装置にダウンロードされた抽象化描画データが重複してダウンロードされるという無駄が避けられるので、上記第１の実施形態よりも、ホスト装置およびプリンタ装置間のトラヒック量をさらに低減することができ、プリントシステムとしての処理速度をさらに高めることができる。
【０１３８】
Ｅ．第５の実施形態
上記第４の実施形態によれば、ホスト装置およびプリンタ装置間のトラヒック量を大幅に低減することができるが、その一方、プリンタ装置側では依然としてホスト装置から受信される抽象化描画データを出力形式描画データ（例えばラスタデータ）に変換する必要があり、そのための処理時間が余分に掛かる。従って、ホスト装置とプリンタ装置とを結ぶネットワークが十分に高速であり、ホスト装置およびプリンタ装置間のトラヒック量がプリントシステム全体としての処理速度に与える影響が少ないような場合には、プリンタ装置側での上記変換のための処理時間がプリントシステム全体の性能を高める上でのボトルネックとなってくる。本実施形態は、この点に鑑み、上記第４の実施形態にさらに改良を加えたものである。
【０１３９】
図１１は本実施形態におけるプリントシステムのプリンタ装置２の構成を示すブロック図である。なお、この図において前掲図８と対応する部分には同一の符号が付されている。また、本実施形態におけるホスト装置１の構成は上記第４の実施形態において使用されているものと同一構成である。
【０１４０】
本実施形態において、デコンポーザ２１には、キャッシュメモリ２２０が設けられている。このキャッシュメモリ２２０は、以下の３つのキャッシュ領域に分かれている。
【０１４１】
ａ．通常の文字描画用フォントキャッシュ
このキャッシュ領域は、プリンタ装置２に装備されている書体データを使用して描画を行う際に基本描画モジュール２１７によってアクセスされる。すなわち、プリンタ装置２に書体データが装備されている文字についての描画コマンドがホスト装置１から与えられると、プリンタ装置２では、基本描画モジュール２１７により、当該書体データを用いて描画が行われるが、その際に基本描画モジュール２１７は、この文字描画用フォントキャッシュの中から該当する書体データを検索する。そして、該当する書体データが格納されている場合にはその書体データを用いて描画を行う。一方、該当する書体データが文字描画用フォントキャッシュに格納されていない場合には、プリント装置２に装備された書体データ用の記憶手段（図示略）から該当する書体データを読み出し、描画に使用する。また、この場合、基本描画モジュール２１７は、描画に使用した書体データを文字描画用フォントキャッシュに格納し、その際に必要であれば、最も長く使用されていない書体データを文字描画用フォントキャッシュから追い出す。
【０１４２】
ｂ．ダウンロード用フォントキャッシュ
このダウンロード用フォントキャッシュは、フォントダウンロードモジュール２１９によってアクセスされるキャッシュ領域である。その詳細については、既に第４の実施形態において説明したので、ここでの重複した説明は省略する。
【０１４３】
ｃ．展開後の出力フォーマット用フォントキャッシュ
この出力フォーマット用フォントキャッシュは、出力用フォントデータ生成モジュール２１８によって生成された出力形式描画データ（例えばラスタデータ）を記憶するためのキャッシュ領域である。本実施形態における最大の特徴は、この出力フォーマット用フォントキャッシュをデコンポーザ２１内のキャッシュメモリに設けた点および出力用フォントデータ生成モジュール２１８がこの出力フォーマット用フォントキャッシュに格納された出力形式描画データを利用する点にある。なお、この場合の描画データの利用の態様については、説明の重複を避けるため、その説明を本実施形態の動作説明に譲ることとする。
【０１４４】
図１２は本実施形態におけるプリンタ装置２の動作を示すフローチャートである。以下、このフローチャートを参照し、本実施形態の動作を説明する。なお、ホスト装置１の動作は上記第４の実施形態と変わるところがないので、その説明を省略する。
【０１４５】
プリンタ装置２におけるインタプリタ２１１は、ホスト装置１からの描画コマンドを受信すると、その描画コマンドがダウンロードフォント描画コマンドか否かを判断する（ステップＳ１２０１）。
【０１４６】
この判断結果が「ＹＥＳ」である場合、インタプリタ２１１は、そのダウンロードフォント描画コマンドにより指示された抽象化描画データをフォントダウンロードモジュール２１９を介して取得する。そして、インタプリタ２１１は、出力用フォントデータ生成モジュール２１８に対し、上記抽象化描画データから、出力形式の描画データを生成すべき旨を指示する。
【０１４７】
出力用フォントデータ生成モジュール２１８は、上記抽象化描画データに対応し、かつ、現在行おうとしている印刷に必要な用紙対応の変換処理（回転、拡大または縮小）を経た出力形式描画データを出力フォーマット用フォントキャッシュの中から検索する（ステップＳ１２０２）。なお、この検索は後述するキャッシュキーを利用して行われる。
【０１４８】
上記検索の結果、該当する出力形式描画データが見つからなかった場合、出力用フォントデータ生成モジュール２１８は、用紙対応の変換処理（画像の回転、拡大または縮小）の指示を用紙監視モジュール２１６から取得する（ステップＳ１２０３）。
【０１４９】
次に出力用フォントデータ生成モジュール２１８は、上記抽象化描画データから出力形式描画データを生成する（ステップＳ１２０４）。ここで、抽象化描画データがベクタ形式のものであり、出力形式描画データがラスタデータである場合、出力形式描画データは、ベクタ／ラスタ変換により生成することができる。また、出力用フォントデータ生成モジュール２１８は、上記ステップＳ１２０３において変換処理の指示を取得している場合にはこの出力形式描画データの生成の際に回転などの変換処理を併せて行う。
【０１５０】
次に出力用フォントデータ生成モジュール２１８は、出力形式描画データを出力フォーマット用フォントキャッシュに格納する（ステップＳ１２０５）。また、この際に出力用フォントデータ生成モジュール２１８は、当該描画データの格納アドレスと、当該描画データを生成する際に併せて行った印刷用紙対応の変換処理（画像の回転、拡大または縮小）に使用した変換マトリックスと、元の抽象化描画データの抽象化フォーマットとからなるキャッシュキーを出力フォーマット用フォントキャッシュ内の特定のエリアに格納する。次いで、出力フォーマット用フォントキャッシュに書き込んだ抽象化描画データに関する情報を同キャッシュ内のキャッシュ管理テーブルに登録する（ステップＳ１２０６）。このキャッシュ管理テーブルの内容を参照することにより、出力フォーマット用フォントキャッシュ内の出力形式描画データの追い出し制御が行われる。
【０１５１】
次に、出力用フォントデータ生成モジュール２１８は、生成した出力形式描画データを出力用バッファ２１３に書き込む（ステップＳ１２０９）。これにより、この出力形式描画データを使用して印刷が行われる（ステップＳ１２１０）。
【０１５２】
これに対し、ステップＳ１２０２における検索において該当する出力形式描画データが見つかった場合、出力フォントデータ生成モジュール２１８は、その出力形式描画データを出力フォーマット用フォントキャッシュから読み出す（ステップＳ１２０７）。次いで、出力フォーマット用フォントキャッシュ内の出力形式描画データの追い出し制御を行うためのキャッシュ管理テーブルを更新する（ステップＳ１２０８）。
【０１５３】
次に出力用フォントデータ生成モジュール２１８は、ステップＳ１２０９において読み出した出力形式描画データをそのまま出力用バッファ２１３に書き込む（ステップＳ１２０９）。これにより、この出力形式描画データを使用して印刷が行われる（ステップＳ１２１０）。
【０１５４】
このように本実施形態によれば、抽象化描画データから生成すべき出力形式描画データが出力フォーマット用フォントキャッシュに格納されている場合には、その出力形式描画データがそのまま印刷に使用される。従って、出力形式描画データを生成するための処理時間が大幅に短縮される。
【０１５５】
さて、ステップＳ１２０１の判断結果が「ＮＯ」である場合、インタプリタ２１１は、描画コマンドがダウンロードコマンドを含んでいるか否かを判断する（ステップＳ１００６）。
【０１５６】
そして、この判断結果が「ＹＥＳ」である場合、インタプリタ２１１は、描画コマンドからダウンロードコマンドを取り出す。そして、フォントダウンロードモジュール２１９により、そのダウンロードコマンドに従って抽象化描画データをダウンロード用フォントキャッシュに格納する（ステップＳ１２１２）。以後、本実施形態では、この抽象化描画データに対し、既に説明したステップＳ１２０２〜Ｓ１２１０の処理が行われる。
【０１５７】
なお、ステップＳ１２１１における判断結果が「ＮＯ」である場合には、ホスト装置１から受信した描画コマンドは、プリンタ装置２に書体データが装備されている文字の描画コマンドまたはグラフィックなどの描画処理を指示するコマンドであるので、基本描画モジュール２１７による通常の描画処理を行い（ステップＳ１２１３）、その結果得られるラスタデータを出力用バッファ２１３に書き込む（ステップＳ１２１４）。
以上が本実施形態の動作である。
【０１５８】
本実施形態によれば、プリンタ装置側において同一内容の出力形式描画データが重複して生成されるのを回避することができるため、プリンタ装置側の処理速度をさらに高めることができる。
【０１５９】
【発明の効果】
以上説明したように、この発明によれば、ホスト装置からプリンタ装置へ送られる描画データの処理を行う画像処理装置において、前記プリンタ装置に書体データが装備されていない文字の描画指示が前記ホスト装置側に発生した場合に、当該文字に対応した抽象化形式のデータフォーマットの描画データである抽象化描画データを生成する描画データ生成手段と、前記描画データ生成手段によって生成された抽象化描画データを前記プリンタ装置に送信する送信手段とを設けたので、ホスト装置およびプリンタ装置間のトラヒック量を抑え、処理速度を犠牲にすることなく、多種の書体による印刷を行うことができるという効果がある。
【図面の簡単な説明】
【図１】  この発明の第１の実施形態であるプリントシステムの構成を示すブロック図である。
【図２】  同実施形態におけるホスト装置の動作を示すフローチャートである。
【図３】  同実施形態におけるプリンタ装置の動作を示すフローチャートである。
【図４】  同実施形態における抽象化描画データの例であるベクタ形式のアウトラインフォーマットデータを例示する図である。
【図５】  この発明の第２の実施形態における抽象化描画データの例であるランレングス形式のラスタデータを例示する図である。
【図６】  この発明の第３の実施形態であるプリントシステムの構成を示すブロック図である。
【図７】  同実施形態におけるホスト装置の動作を示すフローチャートである。
【図８】  この発明の第４の実施形態であるプリントシステムの構成を示すブロック図である。
【図９】  同実施形態におけるホスト装置の動作を示すフローチャートである。
【図１０】  同実施形態におけるプリンタ装置の動作を示すフローチャートである。
【図１１】  この発明の第５の実施形態におけるプリンタ装置の構成を示すブロック図である。
【図１２】  同プリンタ装置の動作を示すフローチャートである。
【図１３】  プリンタ装置に書体データが装備されていない文字の印刷を可能にしたプリントシステムの第１の構成例を示すブロック図である。
【図１４】  同システムにおいてホスト装置からプリンタ装置に送られる描画コマンドの内容を示す図である。
【図１５】  プリンタ装置に書体データが装備されていない文字の印刷を可能にしたプリントシステムの第２の構成例を示すブロック図である。
【図１６】  上記第１および第２の構成例の問題点を説明する図である。
【図１７】  プリンタ装置に書体データが装備されていない文字の印刷を可能にしたプリントシステムの第３の構成例を示すブロック図である。
【符号の説明】
１……ホスト装置、２……プリンタ装置、
１３１Ａ……フォント展開処理部（描画データ生成手段）、
１２……プリンタドライバ（送信手段）、
２１１……インタプリタ（受信装置）、２１８……出力用フォントデータ生成モジュール（出力用データ生成手段）、２２……印刷装置。
【図１】
0004038887.tif 000002
【図２】
0004038887.tif 000003
【図３】
0004038887.tif 000004
【図４】
0004038887.tif 000005
【図５】
0004038887.tif 000006
【図６】
0004038887.tif 000007
【図７】
0004038887.tif 000008
【図８】
0004038887.tif 000009
【図９】
0004038887.tif 000010
【図１０】
0004038887.tif 000011
【図１１】
0004038887.tif 000012
【図１２】
0004038887.tif 000013
【図１３】
0004038887.tif 000014
【図１４】
0004038887.tif 000015
【図１５】
0004038887.tif 000016
【図１６】
0004038887.tif 000017
【図１７】
0004038887.tif 000018