JP2004110337A - 画像形成方法、画像形成システム、クライアント端末、サーバ装置、プログラム、記憶媒体 - Google Patents

Abstract

【課題】ネットワーク印刷システムにおいて、出力指示を発してから印刷物が出力されるまでの時間を短縮することができるようにする。
【解決手段】クライアント端末１００は、文書の作成あるいは編集の作業過程において、ユーザから印刷指示を受ける前の適当な時期に仮の印刷指令を発する。プリントサーバ５００は、この仮の印刷指令を受けたときには、印刷装置２００やＩＯＴ４００における可視画像の形成に使用可能なレディーデータをデータ格納部５３０に保存しておくに留める。ユーザから出力指示が発せられたときには、プリントサーバ５００のイメージデータ展開部５１０は、データ格納部５３０に保存されている部分については、このデータ格納部５３０に保存されている部分のレディーデータを使用して出力用のレディーデータを生成して印刷装置２００やＩＯＴ４００に渡し印刷出力を指示する。
【選択図】　　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、たとえばプリンタ装置、ファクシミリ装置、あるいはそれらの機能を有する複合機など、受信した電子データに基づいて可視画像を所定の記録媒体に出力する画像形成方法や画像形成システムに関する。
【０００２】
また、本発明は、前記画像形成システムに使用されるクライアント端末およびサーバ装置に関する。さらに、本発明は、前記クライアント端末やサーバ装置にインストールされるプログラムおよびこのプログラムを格納したコンピュータ読取り可能な記憶媒体に関する。
【０００３】
より詳細には、クライアント端末と画像形成装置とがネットワーク接続されているシステムにおいて、クライアント端末で用意された電子データに基づいて画像形成装置にて可視画像を出力する際の、処理効率の改善や処理負荷を軽減するための技術に関する。
【０００４】
【従来の技術】
【特許文献１】
特開２０００−２０７１５０号公報
【０００５】
今日、家庭やオフィスなどにおいて、たとえばプリンタ装置やファクシミリ装置などの画像形成装置が広く利用されている。また、オフィス内では、それらの機能や複写装置の機能を複合的に備える複合機も使用されている。
【０００６】
たとえば、ホストコンピュータやワークステーションなどの文書作成装置で作成された印刷データを印刷するプリンタ装置には、解像度が異なるものや、印刷速度の異なるものがある。また、単色印刷のものと多色印刷が可能なものなど様々なタイプのものがある。これら全てのタイプのプリンタ装置をそれぞれのホストコンピュータに直接接続すると、多大の費用を要し、また設置スペースの問題も発生する。
【０００７】
そこで近年では、プリンタ装置をＬＡＮ（ローカルエリアネットワーク）などの通信網に接続し、この通信網に接続されている複数のホストコンピュータや文書作成装置でプリンタ装置を共用することも行なわれるようになっている。
【０００８】
一方、再印刷を効率よく行なうために、プリントサーバとクライアント端末の間、もしくはプリントサーバの中に、文書を保存・管理する文書管理装置が設けられることがある。このようなシステムでは、ある文書の再印刷の必要が生じた場合、文書管理装置から、以前の印刷時に保存しておいた同文書のデータを取り出して印刷することで、クライアント端末で再び同じ文書の印刷指示データを生成してプリントサーバへ送信する手間を省き、再印刷の効率を向上させている。
【０００９】
ここで、文書編集から印刷までの一連の処理を考えた場合、一つの文書がそれぞれの処理段階において適切な様々なファイルフォーマットに変換されて扱われることはよく知られている。各フォーマットにはそれぞれ長所短所があり、文書管理装置で保管する文書のファイルフォーマットをどうするかは、システムの効率を考える上で重要なポイントとなる。
【００１０】
文書編集アプリケーションの（もしくはそれに近い）ファイルフォーマットは、文書の編集には適しているが、アプリケーション固有のフォーマットである場合がほとんどで汎用性の点で問題がある。また、ファイルフォーマットの仕様自体が公開されていない場合もあり、このような場合は文書保管装置の構築がそもそも困難となる。
【００１１】
また、文書編集アプリケーションのファイルフォーマットを用いた場合、再印刷の指示から完了までに時間を要し、また、最初の印刷時と異なる印刷装置を出力先に指定した場合などにはフォントの不一致などから同じ印刷結果が得られない可能性もあり、このフォーマットは再印刷用の保管データのフォーマットに適しているとは言い難い。
【００１２】
一方、プリンタ内部で最終的に使用されるファイルフォーマット（たとえばラスタイメージ）は、通常、そのプリンタ（あるいはプリンタベンダ）独自のものになり、他のプリンタなどで汎用的に利用することはできない。プリントサーバに、様々なベンダが提供する種々のプリンタを接続するシステム構成を考えた場合、そのようなフォーマットは再印刷用の文書保管フォーマットには適さない。
【００１３】
このような理由から、再印刷を目的とした文書管理装置では、保管する文書のフォーマットとしてＰＤＬ（Ｐａｇｅ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｌａｎｇｕａｇｅ　；ページ記述言語）を用いることが多い。ＰＤＬは、ページを記述する言語であり、一般に、クライアント端末からプリントサーバへの文書データ転送時のフォーマットとして用いられている。
【００１４】
ＰＤＬは、プリンタなどの個々のデバイスの機種に依存しないページ記述を目指したものであり、たとえば業界標準的なＰｏｓｔＳｃｒｉｐｔ（ポストスクリプト；米国アドビシステムズ社の商標）など、多くのベンダのプリントサーバでサポートされているものもある。ＰＤＬを文書の保管用フォーマットとして用いた場合、様々なプリンタで汎用的に利用でき、再印刷結果の同一性をかなりの程度保証することができ、再印刷時の印刷速度も文書編集アプリケーションのフォーマットに比べ改善される。
【００１５】
しかしながら、ＰＤＬは、プリンタで処理可能なラスタフォーマットに変換するのにある程度の時間を要する。特にカラーイメージを含んだ文書は、ＰＤＬからラスタイメージへの展開にかなり長い時間を要する。このため、ＰＤＬ形式で文書を保管するシステムでは、再印刷速度の改善が要望されている。
【００１６】
この要望に応えるシステムとして、文書をＰＤＬファイルの形で保管するだけでなく、特定のプリンタでの印刷に特化したフォーマット（ＰＲＦ（プリントレディフォーマット）という）のファイルも合わせて保管するシステムが存在する。ＰＲＦとは、プリンタが最も効率的に働くように、たとえば解像度やイメージ主走査方向などが設定されたフォーマット（一般にはラスタの一種）であり、通常は、ＰＤＬファイルを展開処理した結果作成される。このようなシステムでは、前回印刷時と同じプリンタで文書を再印刷する場合は、ＰＤＬと対応づけて保管した当該文書のＰＲＦファイルを利用することにより、高速に再印刷処理を行なうことができる。
【００１７】
しかしながら、このようなシステムでは、ＰＤＬファイル単位で文書管理を行なっており、アプリケーションレベルで若干の文書の修正が行なわれるような、なかり頻繁に発生しうる事象が起こった場合には非効率的な事態が生じる。たとえば、アプリケーション上で印刷後に誤字を発見して修正した場合などには、たった１文字の修正でも、その文書全体のＰＤＬファイルを作成し直す必要があり、その場合ＰＤＬファイル自体が変更されたので、以前作成しておいた修正前の当該文書のＰＲＦファイルを使用することができず、作成し直されたＰＤＬファイルに対し再び処理の遅い展開処理を行なう必要があった。
【００１８】
つまり、従来のＰＤＬベースの文書管理は、印刷を目前にした修正のない完成された文書を管理するには適しているが、修正が頻繁に行なわれる文書を取り扱う環境では、以前に作ったＰＲＦファイルを利用することができず、再印刷の高速化などのメリットを得ることができなかった。
【００１９】
このような問題を解決する一手法が、たとえば特許文献１に開示されている。この特許文献１に開示されている手法では、クライアント端末にて生成される文書データの更新の有無をページ単位やオブジェクト単位で管理することで、印刷指示があったときには、印刷可能なイメージデータをページ単位やオブジェクト単位で再利用することを可能としている。
【００２０】
すなわち、ページＩＤやオブジェクトＩＤを用いて文書の編集履歴をページ単位やオブジェクト単位で管理し、各ページのページＩＤやオブジェクトＩＤを印刷ジョブの中に埋め込んでプリントサーバ（データ保存装置）に渡す。プリントサーバでは、ページごとやオブジェクトごとに、以前に作成したイメージがキャッシュ（保存）されているかどうかをページＩＤやオブジェクトＩＤを検索キーとして調べ、保存されている部分（ページやオブジェクト）については、それを再利用する。このような連携により、再印刷などの場合に修正のなかったページやオブジェクトについてはＰＤＬからのイメージ作成処理を省略することで、再印刷処理の処理速度を向上させるようにしている。
【００２１】
【発明が解決しようとする課題】
しかしながら、上記の仕組みは、専ら再印刷を効率よく行なうためのアプローチであり、特許文献１に記載の手法による効果も、再印刷要求を受けたときにしか効果を発揮することができない。
【００２２】
したがって、ユーザがクライアント端末で作成した文書データに基づいて初めて印刷を行なう際には、ユーザがクライアント端末よりプリント指示を開始した時点から印刷処理が開始され、クライアント端末にけるＰＤＬデータの生成、生成したＰＤＬデータのプリンタ装置やプリンタサーバへの転送、イメージ展開、およびプリント出力処理を順に行なう必要がある。
【００２３】
このため、初めて印刷を行なう際には、出力指示を発してから印刷物が仕上がるまでに多くの時間が掛かってしまう。特に、非常に複雑で多枚数文書の場合は大きな問題であった。つまり、再印刷における処理効率の改善、再印刷の高速化などのメリットを、最初の印刷時に享受することは全くできなかった。
【００２４】
本発明は、上記事情に鑑みてなされたものであり、クライアント端末で作成した文書データに基づいて初めて印刷を行なう場合であっても、プリント指示を開始した時点から印刷物が仕上がるまでの処理速度を改善することのできる画像形成方法や画像形成システムを提供することを目的とする。
【００２５】
また、本発明は、本発明の画像形成システムに使用されるクライアント端末やサーバ装置を提供することを目的とする。
【００２６】
さらに、本発明は、前記クライアント端末やサーバ装置にインストールされるプログラムおよびこのプログラムを格納したコンピュータ読取り可能な記憶媒体を提供することを目的とする。
【００２７】
【課題を解決するための手段】
すなわち、本発明に係る画像形成方法は、画像形成装置における可視画像の形成に関わる電子データを生成するクライアント端末と、当該クライアント端末にて生成された電子データに対応するデータであって可視画像の形成に使用可能なレディーデータを保存するとともに、画像形成装置にレディーデータを供給するサーバ装置とを備えてなる画像形成システムにおける画像形成方法であって、出力指示を発する以前の、クライアント端末における電子データの生成過程における所定のタイミングで、可視画像の形成に使用可能なレディーデータをサーバ装置に保存しておき、クライアント端末から、その時点にて生成されている電子データに対応する可視画像の出力指示を発する段階では、当該可視画像に対応するレディーデータがサーバ装置に保存されている部分については、当該サーバ装置に保存されている部分のレディーデータを使用して可視画像を形成することとした。
【００２８】
つまり、出力指示がある前に仮の印刷指示をサーバ装置に発して事前にレディーデータを用意させておく。そして、ユーザから出力指示があったときには、この事前に用意しておいたレディーデータの再利用を可能とする仕組みとした。
【００２９】
この事前に用意させておくレディーデータは、できるだけ実際に出力指示があるときのものに近いことが望ましい。編集が頻繁になされるときには、レディーデータを最後に保持した時点と印刷指示を受けた時点との間の時間経過が大きいと、その差が大きくなる。したがって、出力指示がある前に、何度か繰り返して、レディーデータを用意させておくことが望ましい。たとえば、電子データの生成過程における所定のサイクルごと（たとえば数分おきに）や、電子データに編集が加えられる都度などである。
【００３０】
サーバ装置にレディーデータを保存しておく仕組みや、保存しておいたレディーデータを再利用する仕組みは、レディーデータの生成に際してＰＤＬデータを解釈するという手順を踏む特許文献１に記載の手法をそのまま利用することができる。
【００３１】
また、文書データに対する作業中のモニタ画面に表示されているラスタデータを流用してレディーデータをクライアント端末にて生成し、これをサーバ装置に送信して保存させるなど、ＰＤＬデータを解釈することなくレディーデータを用意する仕組みを使ってもよい。
【００３２】
本発明に係る画像形成システムは、画像形成装置と、当該画像形成装置における可視画像の形成に関わる電子データを生成するクライアント端末と、当該クライアント端末にて生成された電子データに対応するデータであって可視画像の形成に使用可能なレディーデータを保存するとともに、画像形成装置にレディーデータを供給するサーバ装置とを備えてなる画像形成システムであって、クライアント端末を、出力指示を発する前の電子データの生成過程における所定のタイミングで、可視画像の形成に使用可能なレディーデータをサーバ装置に保存させる司令部を備えるものとするとともに、サーバ装置を、可視画像の出力指示をクライアント端末から受けたときに、当該可視画像に対応するレディーデータを保存しているか否かを判断する判断部を備えるものとした。
【００３３】
そして、クライアント端末から、その時点にて生成されている電子データに対応する可視画像の出力指示を発したときには、当該可視画像に対応するレディーデータがサーバ装置に保存されている部分については、当該サーバ装置に保存されている部分のレディーデータを使用して可視画像を形成するようにした。
【００３４】
本発明に係るクライアント端末は、本発明に係る画像形成システムに使用される端末であって、出力指示を発する前の、電子データの生成過程における所定のタイミングで、可視画像の形成に使用可能なレディーデータをサーバ装置に保存させる司令部を備えるものとした。
【００３５】
本発明に係るサーバ装置は、本発明に係る画像形成システムに使用される装置であって、可視画像の形成に使用可能なレディーデータを保存するデータ格納部と、クライアント端末から指令されたジョブが画像形成の出力指示に該当するものであるか否かを判断する判断部と、判断部が出力指示に該当すると判断していることを条件として、指示された可視画像に対応するレディーデータがデータ格納部に保存されている部分については、当該データ格納部に保存されている部分のレディーデータを使用して可視画像の形成に供されるイメージデータを生成するイメージデータ展開部とを有するものとした。
【００３６】
また従属項に記載された発明は、本発明のさらなる有利な具体例を規定する。さらに、本発明に係るプログラムは、本発明に係るクライアント端末やサーバ装置を、電子計算機（コンピュータ）を用いてソフトウェアで実現するために好適なものである。なお、プログラムは、コンピュータ読取り可能な記憶媒体に格納されて提供されてもよいし、有線あるいは無線による通信手段を介して配信されてもよい。
【００３７】
【作用】
本発明に係る上記の構成においては、どのように複雑で多枚数の文書の場合でも、ユーザによるクライアント端末での出力指示がある前のドキュメント編集／操作段階において、仮の出力指示を発し、その時点のプリントレディーフォーマットデータをサーバ装置に保存しておくに留める。そして、ユーザからの出力指示があったときには、出力指示があった電子データのうち、対応するレディーデータがサーバ装置に保存されている部分については、その保存されているレディーデータを使用して可視画像を形成する。
【００３８】
つまり、印刷指示がある前に予めレディーデータを用意しておき、実際に出力指示があったときには、その旨とその後の更新部分が分かるような情報をサーバ装置に送信し、サーバ装置に保存しておいたレディーデータのうち、再利用可能な部分についてはそれを使用して画像を形成する。
【００３９】
これにより、文書データの生成や編集の作業を開始し最初にレディーデータをサーバ装置に保存した後から出力指示までの間に、修正のなかったページやオブジェクトについてはイメージ作成処理を省略することで、出力指示を発してから画像形成が完了するまでの処理速度を向上させる。
【００４０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について詳細に説明する。
【００４１】
図１は、本発明に係る画像形成システムの一実施形態としての印刷システムの第１実施形態の構成を示す図である。図示するように、第１実施形態の印刷システム１は、画像形成処理要求としての印刷ジョブを発するユーザ側の装置であるクライアント端末１００と、受信した印刷ジョブを処理する画像形成装置の一例である印刷装置２００と、サーバ装置の一例であるプリントサーバ５００とが、ネットワーク９に接続されて構成されている。
【００４２】
図示した例では、クライアント端末１００として第１および第２といった２台のホストコンピュータ１０２，１０４がネットワーク９に接続され、印刷装置２００として１台が接続され、プリントサーバ５００として１台が接続されているが、これは本願の基本的な仕組みを説明するためのものであり、実際には、それぞれさらに多くの装置がネットワーク９に接続されて印刷システム１が構築される。このようなマルチのシステムとする場合、複数台の印刷装置２００が１台のプリントサーバ５００を共用可能なシステムとすることが好ましい。また、複数のプリントサーバ５００が有機的に結合して、各々が保存しているデータを共用し合うシステムを構築してもよい。つまり、それぞれがキャッシュしているデータに関する情報を交換し合うということである。
【００４３】
なお、印刷装置２００とプリントサーバ５００とを専用ケーブルなどで接続して、１台の印刷装置２００が１台のプリントサーバ５００を専用する構成としてもよい。この場合、印刷装置２００の機能部分としては、画像形成に関わるＩＯＴ（Ｉｍａｇｅ　Ｏｕｔｐｕｔ　Ｔｅｒｍｉｎａｌ　）４００のみをプリントサーバ５００に接続する構成で足りる。ＩＯＴ４００は、１つのプリントサーバ５００に対して複数接続することができる。
【００４４】
ネットワーク９は、クライアント端末１００と印刷装置２００とを接続するものであればよく、たとえば局所的なＬＡＮ（ローカルエリアネットワーク）であっても、あるいは公衆電話回線を利用したＷＡＮ（広域ネットワーク）であってもよい。また、インターネット（Ｗｅｂ）を利用したものであってもよい。なお、ネットワーク９が公衆電話回線である場合には、ネットワークインタフェース（ネットワークＩ／Ｆ）としてモデム装置がクライアント端末１００や印刷装置２００に備えられる。
【００４５】
また、ネットワーク９がＬＡＮやＷＡＮあるいはインターネットである場合、ネットワークインタフェースとしてＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）がクライアント端末１００や印刷装置２００に備えられる。また、クライアント端末１００や印刷装置２００とネットワーク９との間には、ハブ（ＨＵＢ）が介在してもかまわない。
【００４６】
クライアント端末１００の一例である第１および第２のホストコンピュータ１０２，１０４は、それぞれ、印刷に供される文書データを作成する文書作成装置としての機能を備える。たとえば、クライアント端末１００は、文書や図形などの画像データを生成するデータ生成部１１０と、このクライアント端末１００内の各部の動作を制御する中央制御部（ＣＰＵ；Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ　）１２０と、ネットワーク９との間のインタフェース機能をなすネットワークＩ／Ｆ部１３０とが備えられる。
【００４７】
データ生成部１１０には、たとえば、文書や図形などの電子原稿データを生成するためのアプリケーションソフトウェアが組み込まれる。また中央制御部１２０には、クライアント端末１００の全体を制御するソフトウェアであるＯＳ（オペレーティングシステム）１２２や、ネットワーク９に接続されている印刷装置２００に印刷処理を、プリントサーバ５００を介して要求するためのソフトウェアであるプリンタドライバ１２４が組み込まれる。プリンタドライバ１２４は、レディーデータをプリントサーバ５００に保存させる司令部の機能をなす。
【００４８】
これにより、クライアント端末１００は、プログラムに基づいてソフトウェア的に印刷用のデータを生成する装置として構成されるようになる。すなわち、後述する各機能部を構成するためのプログラムを格納したＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ　）などからプログラムを読み出して図示しないハードディスク装置などにインストールさせておき、ハードディスク装置からプログラムを読み出して図示しないＣＰＵが後述する処理手順を実行することにより、各機能をソフトウェア的に実現することができる。
【００４９】
なお、プログラムは、コンピュータ読取り可能な記憶媒体に格納されて提供されてもよいし、有線あるいは無線による通信手段を介して配信されてもよい。また、これらのプログラムや当該プログラムを格納した記憶媒体は、既存のシステムやアプリケーションプログラムあるいはプリンタドライバをバージョンアップするものとして提供されてもよい。あるいは、各機能部分をソフトウェア的に実現するパッチファイルなど、一部の機能に対応したオプションプログラムとして提供されてもよい。
【００５０】
ユーザは、クライアント端末１００（ホストコンピュータ１０２，１０４）を利用して、文書データを生成したり編集したりする。ここで、本実施形態のクライアント端末１００は、ユーザがソフトウェアで文書を作成／編集している作業途中に、ユーザからの印刷指示を待つことなく、所定のタイミングで、たとえば予め定めた繰り返しサイクルごとに、あるいは文書への修正がある都度、印刷装置２００における可視画像の形成に使用可能なレディーデータＰＲＦをプリントサーバ５００に保存させる。本実施形態のクライアント端末１００は、この点に特徴を有する。
【００５１】
以下本明細書においては、印刷指示を待つことなく、所定のタイミングで、レディーデータＰＲＦをプリントサーバ５００に保存させるための指示に基づく印刷ジョブ（仮の印刷指令）を中間印刷ジョブといい、ユーザからの印刷指示に基づく印刷ジョブを出力印刷ジョブということで、両者を区別し、特に区別する必要のない場合には、両者を纏めて印刷ジョブもしくはジョブという。
【００５２】
レディーデータＰＲＦのプリントサーバ５００への保存ため、印刷データをプリントサーバ５００に送信する際の印刷データの形式は、ＰＤＬ形式に限らず、その他の形式、たとえばラスタ形式であってもよい。何れの形式を採用する場合であっても、作業過程における文書の修正部分を特定し得る情報を、プリントサーバ５００に送信する印刷データに対応付けて送信すればよい。
【００５３】
たとえば、ＰＤＬデータを利用する場合、以下のような仕組みとする。先ず、クライアント端末１００のデータ生成部１１０は、文書の各ページに固有な識別番号（ページＩＤという）を付与し、各ページの修正履歴を管理する機能を持つ。各ページには、新規生成されたときにページＩＤが付与されるとともに、保存されていた状態からそのページが変更されたら、そのページには新たなページＩＤが付与される。データ生成部１１０が作成する文書データには、各ページのページＩＤが含まれる。なお、ページＩＤは、少なくとも当該印刷システムの内部で一意的になるように付与する。ページＩＤ付与のアルゴリズムは、当該印刷システム内で一意性を保証できるものであればどのようなものでもよい。
【００５４】
プリンタドライバ１２４は、データ生成部１１０と協業して印刷ジョブ（以下単にジョブともいう）を作成する。ジョブは、たとえば、文書の各ページの印刷イメージをＰＤＬで記述したＰＤＬファイルと、部数やフィニッシング処理（ステープル留めなどの後処理）などの印刷処理属性の指定を記述したジョブチケットファイルから構成される。なお、ジョブチケットファイルを含まない印刷ジョブを生成するシステムであってもかまわない。
【００５５】
プリンタドライバ１２４は、印刷ジョブのＰＤＬファイルの作成に際し、データ生成部１１０の文書データから、その文書の各ページの印刷イメージを表すＰＤＬ記述を作成するとともに、文書データからそれら各ページのページＩＤを検出し、ＰＤＬの記述の中に組み込む。ページＩＤのＰＤＬファイルへの組み込みは、この部分がラスタデータへの展開時に影響されることのないように（解釈されなうように）、たとえばコメント文の形式を用いることにより行なうことができる。このコメント文によるページＩＤの記述は、たとえば当該ページのＰＤＬ記述の先頭部分に埋め込まれる。
【００５６】
このように、ページＩＤをコメント文としてＰＤＬ記述中に組み込むという方式によれば、プリントサーバ５００側では、ページＩＤの記述を検出、解析するために、コメント文を解析してページＩＤを抽出する機構（プログラム）をＰＤＬのインタプリタとは別に設ければよく、ＰＤＬのインタプリタ自体には何ら変更を加える必要がない。また、コメント文はＰＤＬのインタプリタでは無視され、インタプリタには何の影響も与えないので、この方式には、ページＩＤのコメント文を解析する機構を持たないプリントサーバに対しても互換性を失わないという利点もある。
【００５７】
この方式では、プリンタドライバ１２４はデータ生成部１１０と協業して、ユーザに指示された範囲のすべてのページを表すＰＤＬ記述を作成し、そこに各ページのページＩＤをコメント文として埋め込む。本実施形態では、詳細を後述するように、中間印刷ジョブを発行したことのあるページは、その時作成した印刷可能データ（レディーデータＰＲＦ）を再利用するので、すべてのページを含むＰＤＬファイルを作成することは一見無駄に見えるかもしれないが、これは、ページＩＤを認識できないシステムでも問題なく印刷できるようにするためのものである。すなわち、この方式により、ネットワーク９上にページＩＤを認識できる本実施形態のプリントサーバ５００と、ページＩＤを認識できないプリントサーバとが混在する場合でも、プリンタドライバ１２４はそのような混在を意識せずに全く同じＰＤＬファイルを作成することができる。
【００５８】
このようなページＩＤが埋め込まれたジョブによれば、プリントサーバ５００は、各ページが、既に中間印刷ジョブを発行されたものであるのか、それとも初めて受け取ったものかを判別することができる。たとえば、ある文書１のバージョンＡのジョブがすでにプリントサーバ５００に送信されている状況で（実際に印刷が完了しているかどうかは不問）、クライアント端末１００側でページＸおよびＹのみが変更されたその文書１のバージョンＢが作成され、プリントサーバ５００に送られた場合、プリントサーバ５００では、各ページのページＩＤを調べることにより、ページＸおよびＹのみが変更されたことが理解できる。他のページのページＩＤは前のバージョンのときと同じであるが、ページＸおよびＹだけ前のバージョンとは異なる未知のページＩＤを持っているからである。
【００５９】
このようにしてプリンタドライバ１２４で作成されたＰＤＬファイルは、別途作成されたジョブチケットファイルとともに、ジョブとしてネットワーク９を介しプリントサーバ５００に送信される。
【００６０】
ユーザは、データ生成部１１０に組み込まれているアプリケーションソフトウェアで作成／編集した文書に対し、所定のタイミング（作業完了後など）で、印刷指示を発する。プリンタドライバ１２４は、出力を指示された文書についての印刷ジョブを生成し、ネットワーク９に接続されたプリントサーバ５００に送信する。
【００６１】
この印刷出力指示時の印刷ジョブに含まれる印刷データは、ＰＤＬデータであってもよいし、ラスタデータであってもよい。ＰＤＬデータとする場合、プリンタドライバ１２４は、アプリケーションのデータ形式の文書をページ記述言語（ＰＤＬ）のデータ形式に変換して印刷ジョブを生成し、ネットワーク９に接続されたプリントサーバ５００に送信する。
【００６２】
たとえば、クライアント端末１００に組み込まれているアプリケーションプログラムから、イメージ描画命令、グラフィック描画命令、フォント描画命令などの命令種別を持った描画命令が順次プリンタドライバ１２４に入力される。プリンタドライバ１２４は、たとえば、図形、文字などの拡大、回転、変形などを自由に制御できるように、描画命令を印刷装置２００が理解可能なプリント命令に変換してネットワークＩ／Ｆ部１３０に出力する。ネットワークＩ／Ｆ部１３０に入力されたプリント命令は、伝送路であるネットワーク９を通りプリントサーバ５００に伝送される。
【００６３】
プリントサーバ５００は、ネットワーク９とのインタフェース機能をなすネットワークＩ／Ｆ部５０２と、クライアント端末１００から受け取った印刷ジョブに基づいてイメージデータを生成するイメージデータ展開部５１０と、各ジョブの情報を印刷や再印刷のために保管するデータベースの一例であるジョブ保管部５２０と、イメージデータ展開部５１０にて生成されたイメージを、ファイルとして保管し管理する（キャッシュする）データ格納部５３０と、イメージをデータ格納部５３０から取り出し、印刷装置２００やＩＯＴ４００に渡して印刷を行なわせるＩＯＴ制御部５４０とを備えている。
【００６４】
プリントサーバ５００は、ネットワーク９およびネットワークＩ／Ｆ部５０２を介してクライアント端末１００から印刷ジョブを受信すると、この印刷ジョブをジョブ保管部５２０に保存する。
【００６５】
イメージデータ展開部５１０は、この印刷ジョブに含まれているプリント命令を解釈して、ネットワーク９に接続された印刷装置２００やプリントサーバ５００に専用接続されたＩＯＴ４００にて取り扱うことのできるラスタイメージなどの印刷可能データであるＰＲＦ（プリントレディフォーマット）のファイルデータ（レディーデータＰＲＦ）を生成し、データ格納部５３０に保存する。
【００６６】
なお、サーバ装置の一例であるプリントサーバ５００にレディーデータＰＲＦを保存しておく仕組みや、保存しておいたレディーデータＰＲＦを再利用する仕組みは、レディーデータＰＲＦの生成にＰＤＬデータの生成（クライアント端末１００側）や解釈（プリントサーバ５００側）の処理の手順を踏む特許文献１に記載の手法をそのまま利用することができる。
【００６７】
また、クライアント端末１００側にて、文書データに対する作業中のモニタ画面に表示されているラスタデータを流用してレディーデータＰＲＦを生成しこれをプリントサーバ５００に送信するなど、ＰＤＬデータの生成や解釈の処理を経ることなくレディーデータＰＲＦを用意する仕組みを使ってもよい。
【００６８】
印刷装置２００は、クライアント端末１００からネットワーク９やプリントサーバ５００を介して送られてくる印刷可能データ（ラスタライズ済み）であるレディーデータＰＲＦを受信して、用紙上に文書の可視イメージを形成する（印刷する）ようになっている。
【００６９】
たとえば、図示するように、印刷装置２００は、ネットワークインタフェースとしてのネットワークＩ／Ｆ部２０１と、印刷のための各種制御を行なう制御部２０２と、記録紙への印刷を実行する印刷実行部（画像形成部）２１０と、印刷された記録紙を排出する排出部２８０とを備えている。
【００７０】
また、印刷装置２００には、オペレータによって各種指示を入力するためのキーボード２９２と、印刷装置内部の各種情報を表示するためのＣＲＴや液晶（ＬＣＤ）などからなるディスプレイ（モニタ）２９４などを具備したユーザインタフェース部２９０を備えている。ディスプレイ２９４には蓄積されている印刷データに関する各種情報などが表示されるようになっている。
【００７１】
なお、図示しないが、印刷装置２００は、ネットワーク以外から印刷データを入力するためのフレキシブルディスク装置や磁気テープ装置（ストリーマ）などを含む種々のドライブユニットが接続可能となっている。
【００７２】
プリントサーバ５００と専用線で接続されたＩＯＴ４００は、印刷装置２００の印刷実行部２１０と同様の構成のもので、プリントサーバ５００から専用線を介して入力されるラスタライズされたレディーデータＰＲＦに基づき、用紙上に文書の可視イメージを形成する（印刷する）ようになっている。
【００７３】
図２は、図１に示した構成の印刷システム１におけるクライアント端末１００とプリントサーバ５００との関わりにおける処理手順の一例を示したフローチャートである。
【００７４】
ユーザは、クライアント端末１００を使用して文書を作成もしくは編集する場合、データ生成部１１０に組み込まれているアプリケーションを起動する。そして、新規ファイルの生成であれば、デフォルトの作業ファイル（ジョブ生成フラグはオフ）をロードする。また、既存の文書に対する編集作業の場合には、所定の記憶媒体から保存してある編集対象のデータファイルをロードする。
【００７５】
中央制御部１２０は、文書作成作業が開始されたことを検知すると、先ず、その作業が新規ファイルの生成なのか、それとも編集作業なのかを、作業中のファイルにジョブ生成フラグが記述されているか否かで確認する（Ｓ１００）。後述するように、編集作業の場合には、ジョブ生成フラグがオンとなっているので、そのまま作業を継続する（Ｓ１００−ＹＥＳ）。一方、デフォルトの作業ファイルのジョブ生成フラグはオフとなっているので（Ｓ１００−ＮＯ）、新規に文書を作成する場合、中央制御部１２０は先ず、ジョブ生成フラグをオンに設定し（Ｓ１０１）、プリンタドライバ１２４にデフォルトの作業ファイルの状態のまま中間印刷ジョブを生成するように指示する（Ｓ１２０）。
【００７６】
多くの場合、白紙の印刷ジョブとなるであろうが、たとえば、背景画像などがデフォルトの作業ファイルに記述されていれば、プリンタドライバ１２４は、これらの画像を印刷するためのＰＤＬデータを含む中間印刷ジョブを生成することになる。プリンタドライバ１２４は、中間印刷ジョブの生成が完了すると（Ｓ１２０）、生成した中間印刷ジョブをプリントサーバ５００に送信する。そして、アプリケーションが終了されない限り、文書の作成作業を継続する（Ｓ１３０−ＮＯ、Ｓ１０２）。
【００７７】
文書の作成作業や編集作業に入ると（Ｓ１０２）、中央制御部１２０は、タイマーを起動し、文書を作成／編集している段階で、予め取り決めてある中間ジョブ生成タイミングに到達していないかどうかを監視する（Ｓ１０４）。中間ジョブ生成タイミングは、一定時間ごとであってもよいし、あるいは文書への修正がある都度であってもよい。
【００７８】
中間ジョブ生成タイミングに到達している場合、中央制御部１２０は、プリンタドライバ１２４にその時点の作業ファイルの状態のまま、中間印刷ジョブを生成するように指示する（Ｓ１０４−ＹＥＳ，Ｓ１２０）。プリンタドライバ１２４は、新規作成時と同様に、中間印刷ジョブの生成が完了すると、生成した中間印刷ジョブをプリントサーバ５００に送信する。そして、アプリケーションが終了されない限り、文書の作成／編集作業を継続する（Ｓ１３０−ＮＯ、Ｓ１０２）。
【００７９】
中間ジョブ生成タイミングに到達していない場合（Ｓ１０４−ＮＯ）、中央制御部１２０は、ユーザによる文書保存指示の割込みをチェックする（Ｓ１０６）。文書保存が指示されている場合（Ｓ１０６−ＹＥＳ）、中央制御部１２０は、作業中のファイルを所定の（ユーザが指定したファイル名の）ファイルとして保存する（Ｓ１０８）。このとき、ジョブ生成フラグ（オン）をそのファイルに記述しておく。
【００８０】
また、中央制御部１２０は、保存したファイルについて、中間印刷ジョブを生成するようにプリンタドライバ１２４に指示する（Ｓ１２０）。プリンタドライバ１２４は、生成した中間印刷ジョブをプリントサーバ５００に送信するとともに、アプリケーションの終了指示があればアプリケーションを終了させる一方（Ｓ１３０−ＹＥＳ）、終了されなければ文書の作成／編集作業を継続する（Ｓ１３０−ＮＯ、Ｓ１０２）。
【００８１】
文書保存が指示されていない場合（Ｓ１０６−ＮＯ）、中央制御部１２０は、ユーザによる印刷指示の割込みをチェックする（Ｓ１０６）。印刷が指示されている場合（Ｓ１１０−ＹＥＳ）、中央制御部１２０は、印刷指示フラグをオンに設定し（Ｓ１１２）、その時点の作業ファイルの状態のまま、出力印刷ジョブを生成するようにプリンタドライバ１２４に指示する（Ｓ１２０）。プリンタドライバ１２４は、出力印刷ジョブの生成が完了すると、生成した出力印刷ジョブと印刷指示フラグ（オン）をプリントサーバ５００に送信する。そして、アプリケーションが終了されない限り、文書の作成／編集作業を継続する（Ｓ１３０−ＮＯ、Ｓ１０２）。
【００８２】
一方、プリントサーバ５００側においては、クライアント端末１００から印刷ジョブを受け取るまで待機している（Ｓ１４０−ＮＯ）。そして、クライアント端末１００から印刷ジョブ（中間印刷ジョブおよび出力印刷ジョブの何れでもよい）を受け取ると（Ｓ１４０−ＹＥＳ）、イメージデータ展開部５１０は、その印刷ジョブに基づくイメージ形成処理を実行する（Ｓ１４２）。イメージデータ展開部５１０は、印刷ジョブに基づいてイメージを生成する際、該当ジョブの各ページや各オブジェクトが既にデータ格納部５３０に保存されているかどうかを確認し、保存されている部分については、改めてＰＤＬファイルを解釈してイメージ作成を行なうことなく、その保存されているデータを再利用する（詳細は後述する）。たとえば、修正の全くない同じ内容の文書の場合、基本的にＰＤＬの解釈処理を行なわず、保存してあるデータを利用する。「修正の全くない同じ内容」の単位は、たとえば、ページやオブジェクトなどである。
【００８３】
イメージデータ展開部５１０は、生成したイメージをデータ格納部５３０に保存する（Ｓ１４４）。次に、ＩＯＴ制御部５４０は、受け取った印刷ジョブがユーザによる出力指示に対応する出力印刷ジョブなのか、それとも作業途中の所定タイミングで生成された印刷ジョブであるのかを、印刷指示フラグで判断する。（Ｓ１４６）。
【００８４】
ＩＯＴ制御部５４０は、印刷指示フラグがオンの場合には、イメージデータ展開部５１０にて生成されデータ格納部５３０に保存されたイメージを印刷装置２００やＩＯＴ４００に送信して印刷処理を要求する（Ｓ１４６−ＹＥＳ）。一方、印刷指示フラグがオフの場合には、プリントサーバ５００は、引き続き次の印刷ジョブの受信に備える（Ｓ１４６−ＮＯ，Ｓ１４０）。これにより、ユーザから積極的に印刷指示がある場合に限って、印刷装置２００やＩＯＴ４００にて実際の印刷がなされる一方で、作業途中に自動的に生成した印刷ジョブに基づいてプリントサーバ５００にて生成したイメージは、データ格納部５３０への保存だけに留められる。
【００８５】
この第１実施形態によれば、クライアント端末１００における作業過程の所定タイミングで中間印刷ジョブが生成されていれば、当該ジョブのイメージは既にデータ格納部５３０に保存されているため、改めてＰＤＬファイルを解釈してイメージ作成を行なうことはしない（Ｓ１４２）。これにより、文書の編集完了後などにユーザから積極的に印刷指示を受けて印刷する際には、予め保存しておいた部分のデータを利用することができるようになる。よって、初めて印刷を行なう場合であっても、処理効率の改善、印刷の高速化などを図ることができる。
【００８６】
図３は、図１に示したプリントサーバ５００の一構成例を示したブロック図であって、回路構成を機能的に表わしており、特にイメージデータ展開部５１０の詳細を示している。
【００８７】
図示するように、プリントサーバ５００のイメージデータ展開部５１０は、ネットワーク９からネットワークＩ／Ｆ部５０２を経由してジョブを受信するジョブ受信部５１２と、ジョブ受信部５１２が受信したジョブを保管し印刷の流れ全体を統括制御するジョブ管理部５１４と、ジョブの文書を印刷装置２００やＩＯＴ４００で取扱可能な印刷可能データであるレディーデータＰＲＦに共同作業で変換するイメージ形成部５１６およびデコンポーザ５１８とを有する。
【００８８】
ジョブ受信部５１２は、受信したジョブをジョブ管理部５１４に送る。イメージ形成部５１６は、ジョブ管理部５１４からジョブのイメージ形成処理の依頼を受け、このとき同時に受け取ったＰＤＬファイルおよびジョブチケットファイルに従って、各ページの印刷可能データであるページイメージを作成する。
【００８９】
デコンポーザ５１８は、ジョブのＰＤＬファイルを解釈して各ページのラスタイメージを作成し（この解釈、イメージ作成処理を合わせて「デコンポーズ処理」という）、イメージ形成部５１６に返送する。デコンポーザ５１８は、ＰＤＬの記述を解釈するインタプリタに加え、コメント文を解析してページＩＤを検出し、そのＩＤに対応するページイメージが既にデータ格納部５３０に保存されているか否かを問い合わせるための機構を有する。
【００９０】
デコンポーザ５１８は、ＰＤＬファイルの記述を先頭から順に調べていき、ページＩＤの検出すると、そのページＩＤに対応したページイメージファイルがデータ格納部５３０に保存されているかどうか、イメージ形成部５１６に対して問合せを行なう。そして、この問合せにより、データ格納部５３０内にそのページＩＤのページイメージが既に保存されていると分かった場合は、そのページについてのデコンポーズ処理を省略する。
【００９１】
ここで注意すべきは、ＰＤＬ解釈および描画処理という実際のイメージ作成のための処理を行なうのは、デコンポーザ５１８であるということである。イメージ作成という観点でいえば、イメージ形成部５１６は、デコンポーザ５１８に対してイメージ作成を依頼し、イメージ作成処理全体を管理する上位装置として機能する。このような管理手段としてのイメージ形成部５１６を設けるのは、データ格納部５３０を利用したイメージ形成処理の効率化を実現するためである。
【００９２】
本実施形態では、この処理は、デコンポーザ５１８からのデータ格納部問合せに応じて行なわれる。イメージ形成部５１６は、ＰＤＬファイルに組み込まれたページＩＤを利用して、各ページのページイメージがデータ格納部５３０内に既に格納済みかどうかを調べる。そして、イメージ形成部５１６は、ジョブの各ページのページイメージがデータ格納部５３０に保存されていないと判明した場合は、デコンポーザ５１８にそのページのページイメージを作成させ、データ格納部５３０に既に保存されていると判明した場合は、デコンポーザ５１８にそのページのイメージの作成を省略させ、データ格納部５３０中のそのページイメージを利用する。このような処理を各ページについて繰り返すことにより、ジョブの全ページのページイメージが、デコンポーザ５１８またはデータ格納部５３０のいずれかから取得できる。
【００９３】
ジョブの全ページのページイメージが作成できると、イメージ形成部５１６は、ジョブ管理部５１４に対し、イメージ作成依頼の応答として、ジョブを構成する各ページのページイメージの情報を返す。本実施形態では、デコンポーザ５１８で作成されたページイメージはすべてデータ格納部５３０に保存し、ジョブ管理部５１４へは、データ格納部５３０内のそれら各ページのイメージへアクセスするために必要な情報、すなわち構成ページファイルを渡す。
【００９４】
ジョブ保管部５２０は、クライアント端末１００から受信したジョブファイル（すなわちＰＤＬファイルおよびジョブチケットファイル）や、データ格納部５３０に保管されている各ページイメージとジョブとの関連付け情報である構成ページファイルを保管する。
【００９５】
ジョブ保管部５２０には、ジョブに関する一連の情報が保存されているため、プリントサーバ５００の図示しないユーザインタフェースまたはクライアント端末１００からジョブ保管部５２０にアクセスし、そこでジョブを指定することにより、そのジョブの再印刷をジョブ管理部５１４に指示することができる。
【００９６】
ここで、クライアント端末１００における文書の編集過程で、ユーザからの印刷指示を待つことなく所定のタイミングで中間印刷ジョブが生成されていれば、当該ジョブの各ページのページイメージは既にデータ格納部５３０に保存されているため、改めてＰＤＬファイルを解釈してイメージ作成を行なう必要はない。これにより、文書の編集完了後などにユーザから積極的に印刷指示を受けて印刷する際にも、この予め保存しておいた部分のデータを利用することができるようになる。よって、初めて印刷を行なう場合であっても、処理効率の改善、印刷の高速化などを図ることができる。もちろん、再印刷の場合にも、改めてＰＤＬファイルを解釈してイメージ作成を行なう必要はない。
【００９７】
データ格納部５３０は、デコンポーザ５１８でのデコンポーズ処理によりＰＤＬファイルから作成された各ページのページイメージを、ファイルとして保管し、管理する。ここで、ページイメージのファイルには、当該ページのページＩＤの情報が関連づけられる。たとえば、ページＩＤ自体を当該ページイメージのファイル名とすることが好適である。
【００９８】
ページＩＤは一意的なものであるため、各ページイメージのファイルは、特にジョブごとに管理する必要はなく、すべてのジョブのすべてのページのイメージを同じレベルで均質に管理することができる。たとえば、ファイルシステム上の１つのディレクトリをデータ格納部５３０とし、すべてのページイメージファイルを管理することができる。
【００９９】
ページイメージのファイル名にページＩＤを用いた場合、たとえば｛５ａ６１ｆ８ｆ３−ｃｄｅ１−１１ｃｆ−９１１３−００ａａ００４２５ｃ６２｝というページＩＤを持つページのページイメージファイルは、｛５ａ６１ｆ８ｆ３−ｃｄｅ１−１１ｃｆ−９１１３−００ａａ００４２５ｃ６２｝というファイル名で保管する。このようにデータ格納部中のページイメージファイルのファイル名としてページＩＤを用いると、デコンポーザ５１８からの問合せに応じて特定のページＩＤを持つページイメージファイルを検索する際、データ格納部５３０を構成するディレクトリの中のファイル名を検索するだけでよい。
【０１００】
なお、この代わりに、ページイメージファイルをジョブごとに整理して管理する方式も考えられる。たとえば、データ格納部５３０のディレクトリ中にジョブごとにサブディレクトリを作成し、そのサブディレクトリ下にそのジョブのページイメージファイルを保存するなどである。この方式の方が検索性がよく、ジョブ単位での印刷指示を受けた場合などにはこちらの方が高速に対応できる。
【０１０１】
データ格納部５３０は、典型的にはハードディスク装置のような大容量記憶装置を用いて実現される。データ格納部５３０は、このような記憶装置の容量に依存し、有限の大きさであるため、ページイメージファイルを無限に保存することはできない。このため、不要なページイメージファイルを適宜削除する機能を持つ必要がある。この機能は、一般的なキャッシュメモリにおいて公知の様々な手法を用いて実現できる。
【０１０２】
たとえば、ページイメージの総量が予め定めた上限値を超えたときに、最も古く作成されたページイメージから削除したり、最も長い間参照されないページイメージから削除したりするという方式である。また、ページイメージの利用頻度の統計データを順次作成し、この統計データをもとに削除するページイメージを決めてもよい。また、ページイメージの総量が上限値を超えたときに、サーバ管理者に警告を出し、管理者に削除させるような仕組みも可能である。
【０１０３】
ＩＯＴ制御部５４０は、構成ページファイルに示されたアクセス情報（ファイル名やページＩＤなど）に基づき、ジョブの各ページのページイメージをデータ格納部５３０から読み出して順次ＩＯＴ４００に送り、ジョブチケットの情報、たとえば部数やフィニッシングなどの指定に基づきＩＯＴ４００を制御して印刷を行なわせる。なお、ネットワーク９に接続されている印刷装置２００に印刷を行なわせる場合には、データ格納部５３０から読み出したデータとジョブチケットの情報とを印刷装置２００に送る。印刷装置２００は、受け取ったこれらのデータに基づいて印刷処理を実行する。
【０１０４】
図４は、図３に示したプリントサーバ５００におけるジョブ管理部５１４の処理手順の一例を示すフローチャートである。
【０１０５】
ジョブ管理部５１４は、ジョブ受信部５１２からジョブを受け取ると（Ｓ２００）、まず受信したジョブファイル、すなわちＰＤＬファイルとジョブチケットファイルをジョブ保管部５２０に送り、それらファイルの保管を依頼する（Ｓ２０２）。ジョブ保管部５２０は、その依頼に応じてそれらファイルを保管する（Ｓ２２０）。また、ジョブ管理部５１４は、それら受信ジョブの処理順序を管理する。すなわちジョブ管理部５１４は、受信したジョブを印刷待ちのキューに登録し、スケジューリングする。そして、ジョブを印刷する順番が来ると、そのジョブをイメージ形成部５１６に送り、ページイメージの作成を依頼する（Ｓ２０４）。この依頼の後、ジョブ管理部５１４は、イメージ形成処理の完了待ちの状態となる（Ｓ２０６）。
【０１０６】
イメージ形成部５１６は、この依頼に応じて、デコンポーザ５１８とデータ格納部５３０を制御して、そのジョブの各ページのページイメージを作成し、作成したページイメージをデータ格納部５３０に保存するとともに、それらデータ格納部５３０に保存した各ページイメージへのアクセス情報（各ページイメージのファイル名など）を示したファイル（構成ページファイルという）を作成し、ジョブ管理部５１４に渡す。ジョブ管理部５１４は、この構成ページファイルをジョブ保管部５２０に送り、元のジョブのファイル（ＰＤＬファイルやジョブチケットファイル）との関連付け処理を依頼する（Ｓ２０８）。この依頼に応じ、ジョブ保管部５２０は、構成ページファイルをジョブファイルに対応づけて保管する（Ｓ２６０）。
【０１０７】
そして、ジョブ管理部５１４は、その構成ページファイルをジョブチケットの情報とともにＩＯＴ制御部５４０に送り、印刷処理を依頼する（Ｓ２１０）。ＩＯＴ制御部５４０は、この依頼に応じ、構成ページファイルを参照して各ページのページイメージをデータ格納部５３０から取り出し、ＩＯＴ４００に渡して印刷を行わせる（Ｓ２８０）。
【０１０８】
なお、上述したイメージデータ展開部５１０における一連の処理手順についての詳細は、説明を割愛する。その詳細については、特開２０００−２０７１５０号（特に図５の説明）を参照するとよい。
【０１０９】
図５は、上記第１実施形態の構成における処理の概念を示した図である。クライアント端末１００にて文書作成／編集中において、所定のタイミングで、たとえば各オブジェクト操作が発生するとその都度、各オブジェクトに対するＰＤＬ生成、データ転送、およびイメージ展開までの処理を、バックグラウンドで行なう。これにより、プリンタ側は、ユーザごとに固有のシェアードバッファ（Ｓｈａｒｅｄ　Ｂｕｆｆｅｒ　）および同期化セッションを持つことができる。
【０１１０】
そして、ユーザがプリント指示したときには、キャッシュしておいたデータにより出力用のイメージデータは殆ど完成されており、キャッシュされていない部分の変更だけで済むので、出力用のイメージデータをほぼ瞬間的に生成することができる。すなわち、イメージ展開処理の効率化を図ることができ、その分だけ、出力までの時間を従来よりも短縮することができる（図５（Ｂ），（Ｃ）参照）。
【０１１１】
以上説明したように、上記第１実施形態によれば、クライアント端末１００側でジョブに含まれる個々のページごとに一意的なページＩＤを付与し、プリントサーバ５００側で各ページのページイメージをこのページＩＤと対応づけて保存することにより、印刷可能なイメージデータをページ単位で再利用することを可能とした。
【０１１２】
また、ユーザからの印刷指示があるか否かに拘わらず、文書作成／編集過程の所定タイミングでも作業時点の文書に対応する印刷ジョブを自動的に作成し、この印刷ジョブに基づいてイメージを生成し保存しておくようにしたので、初めて印刷を行なう場合（ファーストプリント；Ｆｉｒｓｔ　Ｐｒｉｎｔ　）であっても、事前に保存しておいたデータを再利用することができるようになり、再印刷の指示をユーザから受けた場合に限らず、ファーストプリント時であっても、処理効率の改善や印刷の高速化などを図ることができるようになった。すなわち、プリントサーバ５００での処理の量が低減されサーバの全体的なスループットの向上が見込める。
【０１１３】
なお、上述した第１実施形態では、クライアント端末１００は文書のすべてのページを表すＰＤＬ記述を作成し、その中に各ページのページＩＤを埋め込んでいたが、このような手法に限らず、たとえば、クライアント端末１００とプリントサーバ５００との対話セッションにより、クライアント端末１００側でプリントサーバ５００のデータ格納部５３０の情報を取得し、これをもとにして、ＰＤＬ記述量の削減や生成時間の短縮を図るようにしてもよい。
【０１１４】
この場合、転送するＰＤＬファイルのサイズが小さくなるので、ネットワーク９の負荷低減やファイル転送の高速化が見込める。またプリントサーバ５００側では、処理するＰＤＬファイルが小さくて済むので、ジョブ保管部５２０で必要となるディスク容量が少なくて済み、プリントサーバ５００全体の処理負荷も低減され、結果的に高速化が見込める（図５（Ｄ）参照））。
【０１１５】
また、上述した第１実施形態では、プリントサーバ５００にデータ格納部５３０にてキャッシュするイメージデータの単位（以下キャッシュ単位という）を文書のページとしてきたが、キャッシュ単位は、必ずしもページ単位に限らない。
【０１１６】
たとえば、文書中に含まれる個々の描画オブジェクトをキャッシュ単位としてもよい。描画オブジェクトとは、ページよりも小さな、文書の物理的な構成要素であり、たとえば文字枠（テキスト）や図形枠（グラフィックス、連続階調イメージなど）などである。この場合、クライアント端末１００は、このような各描画オブジェクトにそれぞれ固有のＩＤを付与してＰＤＬファイルに組み込み、プリントサーバ５００側では、作成した各描画オブジェクトのイメージデータをそのＩＤと対応づけてキャッシュ（データ格納部５３０に格納）する。
【０１１７】
キャッシュするイメージデータには、当該描画オブジェクトのページ内での位置の情報を対応づけて保管する。クライアント端末１００は、描画オブジェクトに対して内容変更、移動、拡大・縮小などの変更が加えられると、変更後のオブジェクトには新たなＩＤを付与する。
【０１１８】
クライアント端末１００から一部を修正した文書の印刷ジョブ（中間／出力の何れでもよい）がプリントサーバ５００に送信されると、プリントサーバ５００では、このジョブの各描画オブジェクトのＩＤをＰＤＬファイルから検出し、そのＩＤを持つイメージデータがキャッシュ装置の一例であるデータ格納部５３０に保存されているかどうかを調べ、保存されている場合には、そのイメージデータをデータ格納部５３０から読み出して再利用する。
【０１１９】
そのＩＤのイメージデータがキャッシュされていない場合は、その描画オブジェクトのＰＤＬ記述について通常のデコンポーズ処理を行なう。この場合、デコンポーザ５１８が、データ格納部５３０から読み出したイメージおよびデコンポーズ処理により生成したイメージを合成し、１ページのイメージを生成する。
【０１２０】
このように、描画オブジェクト単位でイメージデータをキャッシュすれば、一度作成したイメージデータをより効率的に再利用することができ、処理を高速化することができる。また、ページよりも小さな単位でキャッシュすると、キャッシュの利用効率も上昇する。
【０１２１】
なお、描画オブジェクト単位でキャッシュする構成では、
１）テキストデータやベクトル描画データ（グラフィックス）などのオブジェクトはデコンポーズ処理に大きな時間は掛からないが、ラスタイメージのオブジェクトはデコンポーズ処理に多大の時間を要する場合が多い、
２）テキストデータは頻繁に編集されて更新されることが多いがラスタイメージはテキストよりも編集される頻度は少ない、
という各描画オブジェクトの性質を考慮して、ラスタイメージオブジェクトのみをキャッシュすることで、プリントサーバ５００におけるキャッシュ検索負荷の増大を避けつつ、デコンポーズ処理の負荷を軽減するようにしてもよい。
【０１２２】
図６は、印刷システムの第２実施形態の処理を説明する概念図である。上記第１実施形態では、印刷データをプリントサーバ５００に送信する際にＰＤＬ形式で送信し、プリントサーバ５００にてラスタデータに展開することでレディーデータＰＲＦを生成していたが、この第２実施形態では、新規文書のジョブに限ってＰＤＬ形式とし（図２のＳ１０１−ＮＯのルート）、それ以後（作成／編集作業の何れも）は、ラスタデータの形式で送信する点に特徴を有する。
【０１２３】
クライアント端末１００に備えられている表示モニタ上には、アプリケーションによって設定された作業領域が表示されている。ユーザは、この作業領域内で文書の編集作業をする。このとき、作業領域内には、処理対象の全ページを一度に表示させず、編集対象のページ、しかも、そのページ内の編集箇所を中心として表示させて作業するのが一般的である。図示したモニタ画面の一例は、このような状態を示している。
【０１２４】
表示モニタに表示データを渡す画像データ生成部（いわゆるグラフィックスアクセサレータ）のイメージ生成分解能は、印刷出力用のイメージ分解能と同程度もしくはそれ以上とする。
【０１２５】
図示した例では、年賀状の作成作業をしている段階で、画像オブジェクトが既に所定位置に張り付いている編集前の文書（ここでは年賀状）に対して、“謹賀新年”という文字を挿入しようとしている段階である。
【０１２６】
プリントサーバ５００には、画像オブジェクトが既に所定位置に張り付いている年賀状（文書のページ番号Ｐ１２）をはじめとして、他のページデータのラスタデータが、既にデータ格納部５３０にレディーデータＰＲＦとして保存されている（Ｓ３００）。
【０１２７】
ユーザが、このようなモニタ画面上において、“謹賀新年”という文字を挿入し確定キーをクリック（押下）すると、クライアント端末１００のプリンタドライバ１２４は、作業領域部分のラスタデータを中間印刷ジョブとしてプリントサーバ５００に送信する（Ｓ３０２）。このとき、プリンタドライバ１２４は、編集作業中のページとそのページ内の位置を特定する情報を、作業領域部分のラスタデータとともに中間印刷ジョブとして送信プリントサーバ５００に送信する（Ｓ３０４）。また、ラスタデータ中の個々の画素データには、データ値の他に、編集の有無を識別する識別コードを付与する（フラグを立てる）（Ｓ３０６）。
【０１２８】
プリントサーバ５００は、クライアント端末１００からラスタデータを含む中間印刷ジョブ（実質的にはモニタ画面の作業領域部分のラスタデータそのもの）を受信すると、編集作業中のページと位置を特定する情報に基づいて、該当ページのラスタデータ（レディーデータＰＲＦ）をデータ格納部５３０から読み出し、そのページ内の該当部分（モニタに表示されている作業領域と対応する部分）のラスタデータのうち、編集ありの画素（本例では、“謹賀新年”という文字が挿入された部分の画素）のデータのみ、受け取ったデータ値に更新する（Ｓ３０８）。
【０１２９】
なお、上記説明では、編集ありの画素データのみ更新することとしていたが、編集作業中のページと位置を特定する情報に基づいて、該当ページのラスタデータ（レディーデータＰＲＦ）をデータ格納部５３０から読み出し、そのページ内の該当部分（モニタに表示されている作業領域と対応する部分）の全ラスタデータを、受け取ったデータに置き換えてもよい。この場合でも、実質的に変更が加えられるのは、編集された部分（本例では、“謹賀新年”という文字が挿入された部分）だけである。
【０１３０】
また、究極的には、編集された部分（本例では、“謹賀新年”という文字が挿入された部分）だけの画素データと、その部分の属するページとページ内の位置を特定する情報のみを送信するようにしてもかまわない。
【０１３１】
このように、第２実施形態の処理手順によれば、クライアント端末１００は、第１実施形態のようなＰＤＬデータの生成という処理を省略することができる。通常の編集作業を考えた場合、変更を加える部分はモニタ画面に表示させていると考えてよく、ラスタデータは、モニタ画面への表示のために常に生成することになる（第１実施形態の構成でも）。
【０１３２】
したがって、グラフィックスアクセサレータのイメージ生成分解能を、印刷出力用のイメージ分解能と同程度もしくはそれ以上としておき、モニタ画面用のイメージとして生成されたデータそのものを印刷イメージとして利用することとすれば、クライアント端末１００側では、印刷用のために別途データを生成する必要はなくなる。
【０１３３】
一方、プリントサーバ５００側にとっては、クライアント端末１００から受け取ったラスタデータを使用して、同じくラスタデータであるデータ格納部５３０に保存していあるレディーデータＰＲＦのうち、所用部分を更新するだけでよく、ＰＤＬデータのデコンポーズ処理（イメージ展開）は新規文書生成時の初回を除いて、不要である。
【０１３４】
ただし、周知のように、ラスタデータを送信すると、ＰＤＬデータを送信するよりも通信負荷が増えデータ転送時間が増える。したがって、編集作業中の所定タイミングごとに（たとえばオリジナル文書の変更発生の都度）、ラスタデータをプリントサーバ５００に送信していたのでは、ネットワーク９に障害が生じる虞れがある。
【０１３５】
しかしながら、今日の通信環境は、いわゆるブロードバンド時代といわれるように、高速通信対応可能なネットワーク（たとえばギガビット／秒クラス）が構築されつつある。この場合、従来のように、クライアント端末１００側にてＰＤＬデータを生成してプリントサーバ５００側にデータ転送することすると、ＰＤＬ生成処理の方がデータ転送時間よりも支配的となる。
【０１３６】
よって、ブロードバンド時代にあっては、第２実施形態のように、ＰＤＬ生成処理を省略した構成とすれば、通信負荷が増えることでデータ転送時間が増える、あるいはネットワーク９に障害が生じるなどの問題は、高速通信対応可能なネットワークを利用することで解消され、クライアント端末１００にてＰＤＬ作成を省略した効果を十分に享受することができるようになる。
【０１３７】
つまり、従来技術が必要とする、ＰＤＬ生成やデータ転送およびイメージ展開などの時間を限りなくゼロにすることができる。結果としてプリント出力時間の短縮に大きく寄与する（図５（Ｅ）を参照）。
【０１３８】
こういった意味では、この第２実施形態は、ブロードバンド時代において、高速印刷処理可能な画像形成システムを構築するのに適したものと考えることができる。そして、データ転送速度が高速であればあるほど、つまり、ネットワークの通信速度が高速であればあるほど、効果が高まる。
【０１３９】
これにより、クライアントサイドのメモリストレージ資源とプリンタサイドのメモリストレージ資源（本例ではプリントサーバ５００）を共有することができる。あるいは、それぞれにストレージ資源を持たせる場合であっても、それぞれの記憶内容を常時同期化させることができる。
【０１４０】
以上、本発明を実施形態を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。発明の要旨を逸脱しない範囲で上記実施形態に多様な変更または改良を加えることができ、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれる。
【０１４１】
また、上記の実施形態は、クレーム（請求項）にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組合せの全てが発明の解決手段に必須であるとは限らない。前述した実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜の組合せにより種々の発明を抽出できる。実施形態に示される全構成要件から幾つかの構成要件が削除されても、効果が得られる限りにおいて、この幾つかの構成要件が削除された構成が発明として抽出され得る。
【０１４２】
たとえば、上記第１実施形態では、ページＩＤをコメント文としてＰＤＬファイル中に埋め込んだが、このような方式に限定されるものではない。たとえば、各ページとページＩＤとの対応関係を示すテーブルを作成し、ＰＤＬファイルに対応づけてサーバ装置に送るような方式でも同様の効果を得ることができる。
【０１４３】
また、上記第１実施形態では、ジョブの情報（ＰＤＬファイル、ジョブチケット、構成ページファイルなど）を保管するジョブ保管部をサーバ装置の内部に設けたが、ジョブ保管部をサーバ装置とは別の装置としてネットワーク９に接続するようなであってもかまわない。
【０１４４】
また、上記実施形態では、クライアント端末１００側での作業過程で、適宜ＰＤＬデータやラスタデータを中間印刷ジョブとしてプリントサーバ５００に送信して、サーバ装置にレディーデータＰＲＦとして（ＰＤＬの場合は展開後のラスタデータを）保存しておくようにしたが、このように、レディーデータＰＲＦをユーザによる積極的な印刷指示の前に保存しておくことができる限り、クライアント端末からサーバ装置に送るデータの形式はどのようなものであってもよい。
【０１４５】
なお、上記実施形態では、印刷指示前のレディーデータＰＲＦの保存に際して、印刷の書式設定に関しては全く触れていなかった。この書式設定に関しては、クライアント端末に組み込まれているプリンタドライバのデフォルトの設定をそのまま使用すればよい。印刷における通常の使用形態では、クライアントが印刷指示を発するときは、デフォルトの設定をそのまま使用することが多いからである。
【０１４６】
また、デフォルト設定を使用しないケースに対応するには、アプリケーションを起動したときや作業途中で、事前に、出力時の書式設定を確認し、ここで指示された書式で印刷イメージのレディーデータを用意しておくようにしてもよい。特に、アプリケーションを起動したときや作業ファイルをロード（ファイルをオープン）したときには、書式設定の確認ダイアログを先ず表示して、ユーザの確認を経た後に、文書に対する作業に取りかかるようにする仕組みとすることが好ましい。
【０１４７】
また、作業途中で出力時の書式設定が変更されたときには、この変更後の最初にレディーデータ保存指令を発するときには、ページ記述言語のデータで全ページ分のデータをサーバ装置に送信するようにするとよい。
【０１４８】
なお、書式変更が、すでにサーバ装置に保存されているデータと等倍であるか縮小処理のみでその変更後の書式設定にイメージを合わせることが可能なものである場合には、変更後の書式の情報のみをサーバ装置に送信し、サーバ装置側でレディーデータの書式合わせをする仕組みとしてもよい。たとえば、印字位置の変更や、１枚の用紙に割り付ける（いわゆるＮｉｎ１／Ｎアップ）ページ数の変更であって、割付数の増大や割付位置の変更などの場合である。
【０１４９】
【発明の効果】
以上のように、本発明によれば、クライアント端末側での文書の作成あるいは編集の作業過程において、所定の繰返しサイクルで、あるいは文書に変更が加えられる都度など、ユーザから印刷指示を受ける前の適当な時期に仮の印刷指令を発することで、画像形成装置における可視画像の形成に使用可能なレディーデータをサーバ装置に保存しておき、画像出力を保留しておく。そして、ユーザから出力指示が発せられたときには、サーバ装置に保存されている部分については、このサーバ装置に保存されている部分のレディーデータを使用して出力用のイメージデータを生成して可視画像を形成するようにした。
【０１５０】
つまり、ユーザからの印刷指示があるか否かに拘わらず、文書作成／編集過程の所定タイミングでも作業時点の文書に対応する印刷ジョブを自動的に作成し、この印刷ジョブに基づいてイメージを生成し保存しておき、ユーザからの印刷指示があれば、事前に保存しておいたデータを再利用して画像を出力ようにした。
【０１５１】
これにより、初めて印刷を行なうファーストプリント時であっても、処理効率の改善や印刷の高速化などを図ることができるようになり、プリント出力時間の短縮に大きく寄与することができるようになった。
【図面の簡単な説明】
【図１】本発明に係る画像形成システムの一実施形態としての印刷システムの第１実施形態の構成を示す図である。
【図２】図１に示した構成の印刷システムにおけるクライアント端末とプリントサーバとの関わりでの処理手順の一例を示したフローチャートである。
【図３】図１に示したプリントサーバの一構成例を示したブロック図である。
【図４】図３に示したプリントサーバにおけるジョブ管理部の処理手順の一例を示すフローチャートである。
【図５】第１実施形態の構成における処理の概念を示した図である。
【図６】印刷システムの第２実施形態の処理を説明する概念図である。
【符号の説明】
１…印刷システム、９…ネットワーク、１００…クライアント端末、１０２…第１のホストコンピュータ、１０４…第２のホストコンピュータ、１１０…データ生成部、１２０…中央制御部、１２２…ＯＳ、１２４…プリンタドライバ、１３０…ネットワークＩ／Ｆ部、２００…印刷装置、２０１…ネットワークＩ／Ｆ部、２０２…制御部２０２、２１０…印刷実行部、２７０…出力制御部、２８０…排出部、２９０…ユーザインタフェース部、４００…ＩＯＴ、５００…プリントサーバ、５０２…ネットワークＩ／Ｆ部、５１０…イメージデータ展開部、５１２…ジョブ受信部、５１４…ジョブ管理部、５１６…イメージ形成部、５１８…デコンポーザ、５２０…ジョブ保管部、５３０…データ格納部、５４０…ＩＯＴ制御部

Claims (14)

1. 画像形成装置における可視画像の形成に関わる電子データを生成するクライアント端末と、当該クライアント端末にて生成された前記電子データに対応するデータであって前記可視画像の形成に使用可能なレディーデータを保存するとともに、前記画像形成装置に前記レディーデータを供給するサーバ装置とを備えてなる画像形成システムにおける画像形成方法であって、
   出力指示を発する以前の、前記クライアント端末における前記電子データの生成過程における所定のタイミングで、前記可視画像の形成に使用可能なレディーデータを前記サーバ装置に保存しておき、
   前記クライアント端末から、その時点にて生成されている前記電子データに対応する前記可視画像の出力指示を発する段階では、当該可視画像に対応する前記レディーデータが前記サーバ装置に保存されている部分については、当該サーバ装置に保存されている部分の前記レディーデータを使用して前記可視画像を形成する
   ことを特徴とする画像形成方法。
2. 前記電子データの生成過程における所定のサイクルごとに、前記可視画像の形成に使用可能なレディーデータを前記サーバ装置に保存しておくことを特徴とする請求項１に記載の画像形成方法。
3. 前記電子データに編集が加えられる都度、前記可視画像の形成に使用可能なレディーデータを前記サーバ装置に保存しておくことを特徴とする請求項２に記載の画像形成方法。
4. 画像形成装置と、当該画像形成装置における可視画像の形成に関わる電子データを生成するクライアント端末と、当該クライアント端末にて生成された前記電子データに対応するデータであって前記可視画像の形成に使用可能なレディーデータを保存するとともに、前記画像形成装置に前記レディーデータを供給するサーバ装置とを備えてなる画像形成システムであって、
   前記クライアント端末は、出力指示を発する前の前記電子データの生成過程における所定のタイミングで、前記可視画像の形成に使用可能なレディーデータを前記サーバ装置に保存させる司令部を備え、
   前記サーバ装置は、前記可視画像の出力指示を前記クライアント端末から受けたときに、当該可視画像に対応する前記レディーデータを保存しているか否かを判断する判断部を備え、
   前記クライアント端末から、その時点にて生成されている前記電子データに対応する前記可視画像の出力指示を発したときには、当該可視画像に対応する前記レディーデータが前記サーバ装置に保存されている部分については、当該サーバ装置に保存されている部分の前記レディーデータを使用して前記可視画像を形成するようにしたことを特徴とする画像形成システム。
5. 請求項４に記載の画像形成システムに使用されるクライアント端末であって、
   出力指示を発する前であって、前記電子データの生成過程における所定のタイミングで、前記可視画像の形成に使用可能なレディーデータを前記サーバ装置に保存させる司令部を備えたことを特徴とするクライアント端末。
6. 新規生成または変更した文書構成要素に対し、少なくとも前記画像形成システム内で一意的な識別子を付与する手段と、
   付与された識別子と文書構成要素との対応関係の情報を前記サーバ装置に送信する送信手段と
   を有することを特徴とする請求項５に記載のクライアント端末。
7. 前記送信手段は、前記文書構成要素に基づいて生成されたラスタデータと前記付与された識別子とを対応付けて送信することを特徴とする請求項６に記載のクライアント端末。
8. 請求項４に記載の画像形成システムに使用されるサーバ装置であって、
   前記可視画像の形成に使用可能なレディーデータを保存するデータ格納部と、前記クライアント端末から指令されたジョブが前記画像形成の出力指示に該当するものであるか否かを判断する判断部と、
   前記判断部が前記出力指示に該当すると判断していることを条件として、指示された可視画像に対応する前記レディーデータが前記データ格納部に保存されている部分については、当該データ格納部に保存されている部分の前記レディーデータを使用して前記可視画像の形成に供されるイメージデータを生成するイメージデータ展開部と
   を有することを特徴とするサーバ装置。
9. 前記イメージデータ展開部は、前記クライアント端末から送信された、文書構成要素に対して付与された識別子と前記文書構成要素との対応関係の情報とに基づいて、前記指示された可視画像に対応する前記レディーデータが前記データ格納部に保存されているか否かを判断することを特徴とする請求項８に記載のサーバ装置。
10. 前記データ格納部は、前記クライアント端末から受信した文書構成要素に基づいて生成されたラスタデータを前記可視画像の形成に使用可能なレディーデータとして保存することを特徴とする請求項８または９に記載のサーバ装置。
11. 請求項４に記載の画像形成システムに使用されるクライアント端末にインストールされるプログラムであって、
    コンピュータに、
    出力指示を発する前であって、前記電子データの生成過程における所定のタイミングで、前記可視画像の形成に使用可能なレディーデータを前記サーバ装置に保存させる手順を
    を実行させることを特徴とするプログラム。
12. 請求項４に記載の画像形成システムに使用されるサーバ装置にインストールされるプログラムであって、
    コンピュータに、
    前記クライアント端末から指令されたジョブが前記画像形成の出力指示に該当するものであるか否かを判断する手順と、
    前記出力指示に該当すると判断されたことを条件として、指示された可視画像に対応する前記レディーデータが所定のデータ格納部に保存されている部分については、当該データ格納部に保存されている部分の前記レディーデータを使用して前記可視画像の形成に供されるイメージデータを生成する手順と
    を実行させることを特徴とするプログラム。
13. 請求項４に記載の画像形成システムに使用されるクライアント端末にインストールされるプログラムを格納したコンピュータ読取可能な記憶媒体であって、
    コンピュータに、
    出力指示を発する前であって、前記電子データの生成過程における所定のタイミングで、前記可視画像の形成に使用可能なレディーデータを前記サーバ装置に保存させる手順を
    を実行させるプログラムを格納したことを特徴とする記憶媒体。
14. 請求項４に記載の画像形成システムに使用されるサーバ装置にインストールされるプログラムを格納したコンピュータ読取可能な記憶媒体であって、
    コンピュータに、
    前記クライアント端末から指令されたジョブが前記画像形成の出力指示に該当するものであるか否かを判断する手順と、
    前記出力指示に該当すると判断されたことを条件として、指示された可視画像に対応する前記レディーデータが所定のデータ格納部に保存されている部分については、当該データ格納部に保存されている部分の前記レディーデータを使用して前記可視画像の形成に供されるイメージデータを生成する手順と
    を実行させるプログラムを格納したことを特徴とする記憶媒体。

Images