JP5127232B2 - データ処理装置、データ処理方法、及びコンピュータプログラム - Google Patents

データ処理装置、データ処理方法、及びコンピュータプログラム Download PDF

Info

Publication number
JP5127232B2
JP5127232B2 JP2007000747A JP2007000747A JP5127232B2 JP 5127232 B2 JP5127232 B2 JP 5127232B2 JP 2007000747 A JP2007000747 A JP 2007000747A JP 2007000747 A JP2007000747 A JP 2007000747A JP 5127232 B2 JP5127232 B2 JP 5127232B2
Authority
JP
Japan
Prior art keywords
data
content data
vdp
image forming
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007000747A
Other languages
English (en)
Other versions
JP2008171033A5 (ja
JP2008171033A (ja
Inventor
裕 妙木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2007000747A priority Critical patent/JP5127232B2/ja
Priority to US11/961,794 priority patent/US8294942B2/en
Priority to EP08150044.9A priority patent/EP1942407B1/en
Publication of JP2008171033A publication Critical patent/JP2008171033A/ja
Publication of JP2008171033A5 publication Critical patent/JP2008171033A5/ja
Application granted granted Critical
Publication of JP5127232B2 publication Critical patent/JP5127232B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1237—Print job management
    • G06F3/1244—Job translation or job parsing, e.g. page banding
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/1211—Improving printing performance
    • G06F3/1215—Improving printing performance achieving increased printing speed, i.e. reducing the time between printing start and printing end
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
    • G06F3/1285—Remote printer device, e.g. being remote from client or server
    • G06F3/1288—Remote printer device, e.g. being remote from client or server in client-server-printer device configuration

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Accessory Devices And Overall Control Thereof (AREA)
  • Facsimiles In General (AREA)
  • Record Information Processing For Printing (AREA)
  • Storing Facsimile Image Data (AREA)
  • Editing Of Facsimile Originals (AREA)
  • Control Or Security For Electrophotography (AREA)
  • Processing Or Creating Images (AREA)
  • Document Processing Apparatus (AREA)

Description

本発明は、データ処理装置、データ処理方法、及びコンピュータプログラムに関し、特に、差込領域にコンテンツデータを差し込んで画像を形成するために用いて好適なものである。
商業的印刷業界では、依頼主（顧客、クライアント）から印刷物（雑誌、新聞、カタログ、広告、グラビア等）の作成依頼を受注し、受注した作成依頼に基づき依頼主が所望する印刷物を作成し、作成した印刷物を依頼主に納品して依頼主から報酬を得ている。かかる商業的印刷業界では、現在でも、オフセット製版印刷機等の大規模な印刷装置等を用いているのが主流である。オフセット製版印刷機を用いた場合には、次のような様々な工程を踏んで作業が進められる。即ち、入稿、デザイン・レイアウト、カンプ（プリンタ出力によるプレゼンテーション）、校正（レイアウト修正や色修正）、校正刷り（プルーフプリント）、版下作成、印刷、後処理加工、及び発送といった様々な工程を踏んで作業が進められる。
オフセット製版印刷機を利用した場合には、版下の作成を欠かすことができない。一度版下を作成すると、その版下の修正を行うことは容易でなく、かつコスト的にかなり不利である。このため、入念な校正、即ちレイアウトのチェックや色の確認作業が必須となる。このように、従来の商業的印刷業界では、大掛かりな印刷装置を必要とし、かつクライアントが所望する印刷物を作成するのにある程度の時間が必要であった。しかも、印刷物を作成するためのそれぞれの作業には専門知識が必要であり、いわば職人と呼ばれる熟練者のノウハウが必要であった。
一方、最近、電子写真方式の印刷装置やインクジェット方式の印刷装置等の高速化と、高画質化とに伴い、電子データを用いたデジタルプリントを実現するＰＯＤ（Print on Demand）市場も出現しつつある。かかるＰＯＤ市場では、前述した大掛かりな印刷装置で扱うジョブよりも比較的小ロットのジョブを、大掛かりな印刷装置やシステムを用いずに、短納期で取り扱えることを目指している。そこで、ＰＯＤ市場では、例えば、デジタル複写機やデジタル複合機等のデジタル画像形成装置を最大限に活用して、電子データを用いたデジタルプリントを実現している。
このようなＰＯＤ市場では、従来の商業的印刷業界に比べて、印刷物を作成するための情報のデジタル化が進み、コンピュータを利用した管理や制御が浸透してきている。そして、コンピュータを利用することによって、ＰＯＤ市場で作成される印刷物のレベル（品質）は、前述した商業的印刷業界で作成されている印刷物のレベル（品質）にある程度近づこうとしている。このような背景の中で、ＰＯＤ市場には、コピー・プリントショップや印刷会社で行われる印刷サービスであるＰＦＰ（Print For Pay）が存在する。この他、企業内（社内）向けの印刷サービスであるＣＲＤ（Centralized Reproduction Department）等も存在する。
以上のような商業的印刷業界やＰＯＤ市場では、商品となる印刷物の受発注から、梱包、配送、アフターサービス、在庫管理、及び入金管理までの全ての業務を一括して代行するサービスを提供することが考えてはいるものの、まだまだ検討の余地が残されている。
また、商業的印刷業界やＰＯＤ市場では、生産関連データの収集、加工、及び報告を通して経営計画と管理業務とを支援し、必要なときに必要な部署に必要な情報を提供することができるようなシステムも検討されている。しかしながら、最適なシステムの実現・運用化には、まだまだ至っていないのが実情である。
また、ＰＯＤ市場では、従来の商業的印刷業界ほど、スキルのある作業者を雇えないのが現状である。更に、ＰＯＤ市場でも、低いコストでジョブを仕上げたい、少ない投資で商売を行いたい、ＴＣＯ（Total Cost of Ownership）を削減したい等の要望も出ている。しかしながら、ＰＯＤ市場は、まだまだ新しい市場のために、このような事情に十分に対応しきれていないのが実情であり、解決すべき問題点が残されている。
また、従来から、文書を固定部分と可変部分とに分け、可変部分のデータをデータベースやＣＶＳファイル等から供給する差し込み印刷を利用し、一枚毎に少しずつ異なる内容の印刷を大量に行う技術がある。かかる技術を用いて行う印刷は、可変情報印刷（Variable Data Printing；以下、ＶＤＰと称する）として知られている。このＶＤＰで行われる業務には、印刷結果の検品や、印刷物のフィニッシング処理、更には印刷物の封筒への梱包や、封筒へ梱包された印刷の配送処理が広く含まれる場合がある。
ＶＤＰを実現するための文書フォーマット技術として、PODi（Digital Print Initiative）で策定されたPPML（Personalized Printing Markup Language）がある。PPMLはXML（eXtensible Markup Language）をベースとし、文書を固定部分と可変部分とに分けて記述するための標準仕様となる言語である。文書の固定部分と可変部分とはそれぞれラスタライズ（Raster Image Processing；以下、必要に応じてＲＩＰと称する）され、ラスタライズされた結果を保存して再利用することが可能となるようにする。また、PPMLをベースとした仕様として、コンテンツデータにＰＤＦ（Portable Document Format）を使用したPPML/VDX（Variable Data eXchange）という仕様もある。
ＶＤＰを実現するための文書フォーマット技術としては、PPMLの他にFreeForm、ＶＰＳ、VIPP等の技術がある。
FreeFormはＥＦＩ社のFieryにおいて使用されている技術である。かかる技術では、文書の固定部分を予めラスタライズしてマスターデータとして保存しておく。そして、文書の可変部分を順次ラスタライズし、ラスタライズしたデータを、保存しておいたマスターデータと合成する。この他、複数のマスターデータを扱えるようにしたFreeForm2も提案されている。このようなものと同様の技術は、特許文献１で開示されている。即ち、特許文献１では、オーバーレイデータを格納しておく。そして、オリジナルデータを受信すると、受信したオリジナルデータとオーバーレイデータとを合成してビットマップメモリ上に展開する技術が開示されている。
ＶＰＳ（Variable Print Specifications）は、Creo社によるPostScriptの拡張言語である。ＶＰＳでは、ページ内のデータを、固定部分であるか可変部分であるかにかかわらずパーツ単位に分割する。そして、それらパーツ単位に分割されたデータをラスタライズし、ラスタライズした結果を記録媒体（ディスク）に保存して再利用できるようにする。このようなＶＰＳでは、個々のパーツを合成して出力する際にラスタライズ処理を省略することができるので、出力処理を高速化できる。
VIPP（Variable-data Intelligent PostScript Printware）は、ゼロックス（登録商標）社のＶＤＰ用ソフトウェア技術である。かかる技術では、クライアントからプリンタにCSV（Comma Separated Value）等の可変データを送信する。そして、プリンタに設けられたプリンタコントローラで、可変データと固定部分のデータとを合成し、ラスタライズ処理を行う。
特開平４−１７５９２３号公報
ＶＤＰを行うシステムでは、コンテンツデータが、画像データのように比較的サイズの大きく処理に時間のかかるデータである場合がある。PPMLやPPML/VDXのように、固定部分のデータと可変部分のデータとを常にパッケージにして使用する場合、コンテンツデータのサイズが大きいと、パッケージ全体のサイズが大きくなる。そうすると、記録媒体（ディスク）へのデータの読み書き速度、ＣＰＵにおけるデータの処理負荷、及びネットワークを経由したデータの転送速度等のパフォーマンスに影響が出る。
また、固定部分のデータと可変部分のデータとを常にパッケージにして使用する場合には、複数のパッケージで同じコンテンツデータが使われていたとしても、それぞれのパッケージに同じデータが保存されてしまう。このため、コンテンツデータに無駄が生じる。
また、ＶＤＰの文書を作成するためのＶＤＰアプリケーションと、文書の印刷処理を行うプリンタとは別の装置であるにも関わらず、文書の作成処理と印刷処理とが逐次的に行われていた。このため、システム全体のＶＤＰの実行速度が最適化されず、ＶＤＰ全体のスループットが低下してしまうという問題点があった。
本発明は、このような問題点に鑑みてなされたものであり、画像形成領域の中に設定された差込領域にコンテンツデータを差し込んで画像を形成する際のスループットを従来よりも向上させることを目的とする。
本発明のデータ処理装置は、画像を形成する画像形成装置と通信可能なデータ処理装置であって、差込領域に差し込まれるコンテンツデータを、データベースから取得するコンテンツデータ取得手段と、前記画像を形成するための画像形成用データが前記画像形成装置に送信される前に、前記コンテンツデータ取得手段により取得されたコンテンツデータを、前記画像形成装置に送信するコンテンツデータ送信手段と、前記コンテンツデータ送信手段により送信されたコンテンツデータの識別情報を、前記画像形成装置から取得する識別情報取得手段と、前記識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成する画像形成用データ生成手段と、前記画像形成用データ生成手段により生成された画像形成用データを、前記画像形成装置に送信する画像形成用データ送信手段とを有し、前記画像形成装置において実行される前記コンテンツデータに基づくラスタデータの生成処理は、前記データ処理装置において実行される前記画像形成用データの生成処理と並行して実行されることを特徴とする。
本発明のデータ処理方法は、画像を形成する画像形成装置と通信可能なデータ処理装置におけるデータ処理方法であって、差込領域に差し込まれるコンテンツデータを、データベースから取得するコンテンツデータ取得ステップと、前記画像を形成するための画像形成用データが前記画像形成装置に送信される前に、前記コンテンツデータ取得ステップにより取得されたコンテンツデータを、前記画像形成装置に送信するコンテンツデータ送信ステップと、前記コンテンツデータ送信ステップにより送信されたコンテンツデータの識別情報を、前記画像形成装置から取得する識別情報取得ステップと、前記識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成する画像形成用データ生成ステップと、前記画像形成用データ生成ステップにより生成された画像形成用データを、前記画像形成装置に送信する画像形成用データ送信ステップとを有し、前記画像形成装置において実行される前記コンテンツデータに基づくラスタデータの生成処理と、前記データ処理装置において実行される前記画像形成用データの生成処理とが並行して実行されることを特徴とする。
本発明のコンピュータプログラムは、画像を形成する画像形成装置と通信可能なデータ処理装置におけるデータ処理方法の各ステップをコンピュータに実行させるためのコンピュータプログラムであって、前記各ステップは、差込領域に差し込まれるコンテンツデータを、データベースから取得するコンテンツデータ取得ステップと、前記画像を形成するための画像形成用データが前記画像形成装置に送信される前に、前記コンテンツデータ取得ステップにより取得されたコンテンツデータを、前記画像形成装置に送信するコンテンツデータ送信ステップと、前記コンテンツデータ送信ステップにより送信されたコンテンツデータの識別情報を、前記画像形成装置から取得する識別情報取得ステップと、前記識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成する画像形成用データ生成ステップと、前記画像形成用データ生成ステップにより生成された画像形成用データを、前記画像形成装置に送信する画像形成用データ送信ステップとを有し、前記画像形成装置において実行される前記コンテンツデータに基づくラスタデータの生成処理と、前記データ処理装置において実行される前記画像形成用データの生成処理とが並行して実行されることを特徴とする。
本発明によれば、画像を形成する時間を短縮することができる。
次に、図面を参照しながら、本発明の一実施形態について説明する。
＜全体構成＞
まず、図１を参照して、画像形成システムの一例である印刷システムの全体構成を説明する。図１は、印刷システムの概略構成の一例を示す図である。
図１において、１０１は、ユーザが操作を行うＶＤＰクライアントである。ＶＤＰクライアント１０１は、例えば、ＰＣ（Personal Computer）であり、ネットワークインタフェースを経由してネットワーク１０４に接続されている。１０２は、ネットワーク１０４を経由して、ＶＤＰクライアント１０１から印刷指示を受け付けるＶＤＰプリンタである。ＶＤＰプリンタ１０２も、ＶＤＯクライアント１０１と同じくネットワークインタフェースを経由してネットワーク１０４に接続されている。このように、ＶＤＰクライアント１０１は、ネットワーク１０４を通じてＶＤＰプリンタ１０２に印刷指示を送信することが可能である。本実施形態では、例えば、このＶＤＰクライアント１０１がデータ処理装置として設けられ、ＶＤＰプリンタ１０２が画像形成装置として設けられる。
１０３は、データベースを格納するＤＢ（データベース）サーバである。ＤＢサーバ１０３は、ネットワーク１０４を経由して外部から送信されたデータをデータベースに書き込んだり、データベースに書き込まれたデータを読み出し、読み出したデータを、ネットワーク１０４を経由して外部に送信したりするが可能である。ＤＢサーバ１０３も、ＶＤＯクライアント１０１及びＶＤＰプリンタ１０２と同じくネットワークインタフェースを経由してネットワーク１０４に接続されている。
＜コンピュータ装置の構成＞
次に、図２及び図３を参照して、図１に示した印刷システムで使用されるコンピュータ装置及びプリンタ装置の構成の一例について説明する。
図２は、ＶＤＰクライアント１０１及びＤＢサーバ１０３の構成の一例を示すブロック図である。
図２において、２０１は、ＲＡＭ２０２に格納されている制御プログラムに従って本装置全体の制御を行うＣＰＵである。ＲＡＭ２０２は、ＣＰＵ２０１が実行する本装置の制御プログラムや、文書画像等のデータを格納する内部記憶部である。
２０３は、ＣＰＵ２０１の制御の下に、ネットワーク１０４と本装置（ＶＤＰクライアント１０１及びＤＢサーバ１０３）との接続を行ってデータ等を送受信するネットワークインタフェース（NetI/F）である。２０４は、データを保存する磁気ディスク等の外部記憶装置である。２０５はディスプレイ、２０６はキーボード、２０７は、マウス等のポインティングデバイスである。２０８は、キーボード２０６及びポインティングデバイス２０７と本装置（ＶＤＰクライアント１０１及びＤＢサーバ１０３）とを相互に接続するためのキーボードインタフェース（KeyI/F）である。
ＲＡＭ２０２に格納されているプログラムは、同じくＲＡＭ２０２に格納されているＯＳ（Operating System）の機能を必要に応じて使用して処理を実行する。具体的に、ＲＡＭ２０２に格納されているプログラムは、ＲＡＭ２０２に一時的に記憶するデータの内容を読み書きしたり、外部記憶装置２０４に対してデータを読み書きしたり、ネットワークインタフェース２０３を通じてデータの送受信を行ったりする。この他、プログラムは、キーボード２０６やポインティングデバイス２０７からの入力を受け取ったり、ディスプレイ２０５に画像の表示を行ったりする。
ＤＢサーバ１０３は、外部記憶装置２０４にデータベースを格納している。ＲＡＭ２０２に格納されたデータベースプログラムは、ＶＤＰクライアント１０１から、ネットワークインタフェース２０３を通じてデータベースの読み書き命令を受け取ると、その読み書き命令に対応するデータを、データベースから読み出す。そして、ＲＡＭ２０２に格納されたデータベースプログラムは、読み出したデータを、ネットワークインタフェース２０３を通じてＶＤＰクライアント１０１に送信する。
図３は、ＶＤＰプリンタ１０２の構成の一例を示すブロック図である。
図３において、３０１は、ＶＤＰプリンタ１０２全体の制御を行うＭＦＰ制御部である。３０２、３０３、３０５は、夫々ＲＡＭ、ネットワークインタフェース、外部記憶装置であり、図２に示したＲＡＭ２０２、ネットワークインタフェース２０３、外部記憶装置２０４と同じ機能を有する。
３０４は、ネットワークインタフェース３０３から受信したプリントデータがＰＤＬ（Page Description Language）データである場合にそれを解釈してラスタライズする装置であるＲＩＰ部である。３０６は、ＲＩＰ部３０４でラスタライズされたラスタデータを画像処理して画像データを生成する出力画像処理部である。３０７は、シートを給紙し、出力画像処理部３０６で生成された画像データを、そのシート上に順次印字してプリントアウトするプリンタエンジンである。プリントアウトされたシートは後処理部３０８へ送り込まれる。後処理部３０８は、プリンタエンジン３０７からプリントアウトされたシートの仕分け処理やシートの仕上げ処理を行う。
＜全体のブロック図＞
次に、図４〜図５を参照して、印刷システムの構成の一例について説明する。
図４は、印刷システムの基本となる構成の一例を示すブロック図である。
図４において、４０１は、ＶＤＰクライアントである。ＶＤＰクライアント４０１では、ＶＤＰアプリケーションプログラム４０４が動作している。４０２は、ＤＢサーバである。ＤＢサーバ４０２は、コンテンツＤＢ４０５を管理している。４０３は、ＶＤＰプリンタである。ＶＤＰプリンタ４０３では、ＲＩＰプログラム４０６が動作している。
ＶＤＰアプリケーションプログラム４０４は、ユーザが編集するＶＤＰドキュメントにおいて、固定データ或いは可変データとして指定されたコンテンツに対するコンテンツデータの取得要求を、通信経路４０８を介してＤＢサーバ４０２に送信する。ＤＢサーバ４０２は、ＶＤＰアプリケーションプログラム４０４からのコンテンツデータの取得要求に基づいて、コンテンツＤＢ４０５からコンテンツデータ４１０を取得する。そして、ＤＢサーバ４０９は、取得したコンテンツデータ４１０を、通信経路４０９を介してＶＤＰクライアント４０１に送信する。ＶＤＰアプリケーションプログラム４０４は、ＤＢサーバ４０２から取得したコンテンツデータ４１０に基づいて、ＶＤＰジョブファイル４１２を作成する。このとき、ＶＤＰアプリケーションプログラム４０４は、PPML等のＶＤＰ文書フォーマットを使用してＶＤＰジョブファイル４１２を作成する。
ＶＤＰジョブファイル４１２には、ＤＢサーバ４０２から取得したコンテンツデータ４１０がそのまま格納される。ＶＤＰアプリケーションプログラム４０４は、作成したＶＤＰジョブファイル４１２を、通信経路４１１を介してＶＤＰプリンタ４０３に送信する。ＶＤＰジョブファイル４１２がＶＤＰプリンタ４０３で受信されると、ＲＩＰプログラム４０６は、受信されたＶＤＰジョブファイル４１２に対するＲＩＰ処理を行い、ＲＩＰ処理の結果をプリンタエンジン３０７に送信する。これによりＶＤＰジョブファイル４１２の印刷処理が行われる。
図５は、印刷システムの構成の一例を特徴となる部分を含めて示すブロック図である。即ち、図５は、物理的に図１の構成をとるＶＤＰクライアント１０１、ＶＤＰプリンタ１０２、ＤＢサーバ１０３、及びネットワーク１０４において、本実施形態の動作に関わる論理ブロック（プログラムモジュール、データエンティティ、及び通信経路）を示す。
図５において、ＶＤＰクライアント１０１は、ＯＳの制御の下で動作する。５０４、５０５は、夫々ＶＤＰアプリケーションプログラム、ＤＢブローカープログラムであり、通常は外部記憶装置２０４に保存されている。ＶＤＰアプリケーションプログラム５０４とＤＢブローカープログラム５０５は、ユーザ、ＯＳ、又は別のプログラムから実行が指示されると、ＯＳの制御によりＲＡＭ２０２に読み出され、実行可能な状態となる。
ＤＢブローカープログラム５０５は、ＶＤＰアプリケーションプログラム５０４からコンテンツＤＢ５０６に対して行われるコンテンツデータの取得要求を仲介する。そして、ＤＢブローカープログラム５０５は、ＶＤＰアプリケーションプログラム５０４に代理して、ＶＤＰプリンタ５０３のキャッシュマネージャプログラム５０９との通信を行う。５１１は、ＶＤＰアプリケーションプログラム５０４からＤＢブローカープログラム５０５へ行なわれるコンテンツデータの取得要求の通信経路である。１０４ａは、ＤＢブローカープログラム５０５がＶＤＰアプリケーションプログラム５０４に代理してＤＢサーバ１０３へ行うコンテンツデータ５１６の取得要求の通信経路である。
１０４ｂは、コンテンツデータの取得要求に対して、ＤＢサーバ１０３からＤＢブローカープログラム５０５に返されるコンテンツデータ５１６の通信経路である。５１２は、ＤＢブローカープログラム５０５で生成されたプロキシデータ５１３の通信経路である。図５に示すように、プロキシデータ５１３は、ＤＢブローカープログラム５０５からＶＤＰアプリケーションプログラム５０４に送信される。１０４ｄは、ＤＢブローカープログラム５０５からキャッシュマネージャプログラム５０９へ送信されるコンテンツデータ５１６の通信経路である。１０４ｅは、コンテンツデータ５１６の送信に基づいて返信されるキャッシュＩＤ５２３の通信経路を示す。また、１０４ｃは、ＤＢブローカープログラム５０５から取得したプロキシデータ５１３を使用してＶＤＰアプリケーションプログラム５０４が作成したＶＤＰジョブファイル５１８の通信経路である。図５に示すように、ＶＤＰジョブファイル５１８は、ＶＤＰクライアント１０１からＶＤＰプリンタ１０２に送信される。
ＶＤＰジョブファイル５１８には、通信経路５１２を介してＤＢブローカープログラム５０５から取得したプロキシデータ５１３がそのまま格納される。コンテンツデータの取得要求の通信経路５１１と、プロキシデータ５１３の通信経路５１２における通信は、ＯＳの制御によりＶＤＰアプリケーションプログラム５０４と、ＤＢブローカープログラム５０５とのプロセス間通信として実行される。ＶＤＰジョブファイル５１８、コンテンツデータ５１６、及びキャッシュＩＤ５２３の通信経路１０４ｃ、１０４ｄ、１０４ｅを介した通信には、ＶＤＰクライアント１０１及びＶＤＰプリンタ１０２のネットワークインタフェース２０３、３０３が使用される。
ＤＢサーバ１０３は、ＯＳの制御の下で動作する。５０６は、ＤＢサーバ１０３の外部記憶装置２０４に格納されたコンテンツＤＢである。ＶＤＰクライアント１０１や他のコンピュータで動作するプログラムは、ＤＢサーバ１０３のネットワークインタフェース２０３を通じて、ＤＢサーバ１０３で動作する不図示のデータベースプログラムと通信する。これにより、ＶＤＰクライアント１０１や他のコンピュータで動作するプログラムは、コンテンツＤＢ５０６の内容（コンテンツデータ５１６）を読み書きすることが可能である。
前述したように、１０４ａは、ＤＢブローカープログラム５０５からＤＢサーバ１０３へ行われるコンテンツデータ５１６の取得要求の通信経路である。また、１０４ｂは、コンテンツデータの取得要求に対して、ＤＢサーバ１０３からＤＢブローカープログラム５０５に返されるコンテンツデータ５１６の通信経路である。通信経路１０４ａ、１０４ｂにおける通信は、ＶＤＰクライアント１０１のネットワークインタフェース２０３と、ＤＢサーバ１０３のネットワークインタフェース２０３とを使用して行われる。
ＶＤＰプリンタ１０２は、ＭＦＰ制御部３０１の制御の下で動作する。５１０は、ＶＤＰプリンタ１０２の外部記憶装置３０５に格納されたキャッシュＤＢである。５０８、５０９は、ＲＩＰプログラム、キャッシュマネージャプログラムであり、ＶＤＰプリンタ１０２のＲＡＭ３０２に格納され、常に実行可能なプログラムである。
ＲＩＰプログラム５０８は、ネットワークインタフェース３０３を通じてＶＤＰジョブファイル５１８を受信すると、ＶＤＰジョブファイル５１８のデータを必要に応じて外部記憶装置３０５に格納する。そして、ＲＩＰプログラム５０８は、必要に応じてキャッシュマネージャプログラム５０９を呼び出しながら、出力画像処理部３０６やプリンタエンジン３０７を制御してＶＤＰジョブファイル５１８の内容の印刷を行う。
キャッシュマネージャプログラム５０９は、ＭＦＰ制御部３０１の制御の下で、キャッシュＤＢ５１０の内容を読み書きすることが可能である。５２６は、キャッシュマネージャプログラム５０９からＲＩＰプログラム５０８に送信されるコンテンツデータ５１６の通信経路である。５２５は、コンテンツデータ５１６の取得に対応して、ＲＩＰプログラム５０８からキャッシュマネージャプログラム５０９に送信されるラスタデータ５０７の通信経路である。また、キャッシュデータの取得要求（キャッシュＩＤ５２３）も、通信経路５２５を介して、ＲＩＰプログラム５０８からキャッシュマネージャプログラム５０９へ送信される。更に、そのキャッシュデータの取得要求であるキャッシュＩＤ５２３の取得に対応して、キャッシュマネージャプログラム５０９からラスタデータ５２８が、通信経路５２６を介してＲＩＰプログラム５０８に返される。通信経路５２５、５２６における通信は、ＭＦＰ制御部３０１の制御により、ＲＩＰプログラム５０８とキャッシュマネージャプログラム５２６とのプロセス間通信として実行される。
＜ＶＤＰジョブの概念的な構造＞
次に、図６〜図７を参照して、図４に示した基本的なＶＤＰジョブファイル４１２と、本実施形態で説明する特徴を含んだＶＤＰジョブファイル５１８の概念的な構造の一例について説明する。
図６は、文書フォーマット技術としてPPMLを使用した場合のＶＤＰジョブファイル４１２の概念的な基本構造の一例を示す図である。
６０２は、PPMLファイルである。PPMLの仕様では、ＶＤＰジョブファイル６０１の１つにつき、１つのPPMLファイル６０２が存在する。
４１０ａ〜４１０ｃは、図４に示したコンテンツデータ４１０に相当するファイルであり、夫々PostScriptのファイル、ＰＤＦのファイル、JPEGフォーマットのファイルである。
６０３、６０４、６０５は、PPMLファイル６０２で定義された描画領域を表わす。これらの描画領域６０３〜６０５には、夫々コンテンツデータ４１０ａ〜４１０ｃが関連付けられている。
ＶＤＰクライアント４０１とＶＤＰプリンタ４０３との間で事前の合意、或いは送信時のネゴシエーションがあれば、ＶＤＰジョブファイル４１２の各構成ファイル４１０ａ〜４１０ｃ、６０２を送信する方法として、任意の方法を採ることが可能である。通常は、ＺＩＰフォーマットに代表される圧縮フォーマットを使用して、各構成ファイル４１０ａ〜４１０ｃ、６０２を１つのファイルに結合・圧縮して送信することが行われる。
ＶＤＰジョブファイル４１２を受け取ったＲＩＰプログラム４０６は、そのＶＤＰジョブファイル４１２が圧縮されている場合には、そのＶＤＰジョブファイル４１２を伸長して、各構成ファイル４１０ａ〜４１０ｃ、６０２を復元する。その後ＲＩＰプログラム４０６は、各構成ファイル４１０ａ〜４１０ｃ、６０２の情報に基づいてＲＩＰ処理を行う。
図７は、文書フォーマット技術としてPPMLを使用した場合のＶＤＰジョブファイル５１８の概念的な構造の一例を示す図である。
７０２は、PPMLファイルである。前述したように、PPMLの仕様では、ＶＤＰジョブファイル７０１の１つにつき１つのPPMLファイル７０２が存在する。７０３、７０４、７０５は、PPMLファイル７０２で定義された描画領域を表わす。
５１３ａ〜５１３ｃは、コンテンツデータ５１６の代わりとなるプロキシデータ５１３に相当するファイルである。プロキシデータ５１３の概念的な構造を、図７（ｂ）に拡大して示す。図７（ｂ）に示すように、プロキシデータ５１３には、コンテンツデータ５１６の識別情報の一例であるキャッシュＩＤ５２３と、サムネイルデータ７０９とが格納される。尚、プロキシデータ５１３ａ〜５１３ｃは、夫々同様の構造を持つ。
尚、描画領域７０３〜７０５には、夫々プロキシデータ５１３ａ〜５１３ｃが関連付けられている。また、本実施形態では、ＶＤＰアプリケーションプログラム５０４は、ＺＩＰフォーマットを使用して１つのファイルに結合・圧縮してから、ＶＤＰジョブファイル５１８をＶＤＰプリンタ１０２に送信するようにしている。
ＶＤＰジョブファイル５１８を受け取ったＲＩＰプログラム５０８は、そのＶＤＰジョブファイル５１８を伸長して、各構成ファイル５１３ａ〜５１３ｃ、７０２を復元する。その後、ＲＩＰプログラム５０８は、キャッシュＩＤ５１３をキャッシュマネージャプログラム５０９に送信し、送信したキャッシュＩＤ５２３に対する返信としてキャッシュマネージャプログラム５０９からラスタデータ５０７を取得する。ＲＩＰプログラム５０８は、このようにしてラスタデータ５０７を取得しながら、復元した各構成ファイル５１３ａ〜５１３ｃ、７０２に基づいてＲＩＰ処理を行う。
＜ＶＤＰシステムの処理シーケンス＞
次に、図８〜図９を参照して、印刷システムにおける印刷処理シーケンスの一例について説明する。
図８は、図４に示した印刷システムにおいて、ユーザが印刷を指示した場合に行われる印刷処理シーケンスの一例を示す図である。図８では、ネットワーク１０４を経由した通信もシーケンス図のメッセージを用いて図示したり、複数のメッセージをまとめて"｝"で示したりしている。したがって、図８は、ＵＭＬ（Unified Modeling Language）の記法に厳密に従って記載されているわけではない。
ユーザ８０１は、図４に示した印刷システムを使用するアクターの一例を示す。ここで、アクターは、印刷システム内のオブジェクトと直接相互作用するオブジェクトの役割を果たす。実際の印刷システムでは、ＤＢサーバ１０３の管理者や、ＶＤＰプリンタ１０２のオペレーターといったその他のアクターが想定され得る。印刷処理シーケンスを示す目的からすると、アクターの数は本質的ではないので、ここでは印刷を指示するユーザ８０１のみをアクターとしている。
まず、ユーザ８０１は、キーボード２０６やポインティングデバイス２０７を用いて、ＶＤＰアプリケーションプログラム４０４に印刷を指示する（ステップＳ８０１）。
ＶＤＰアプリケーションプログラム４０４は、通信経路４０８を介してコンテンツＤＢ４０５に、コンテンツデータ４１０の取得要求のメッセージを送信する（ステップＳ８０２）。
コンテンツＤＢ４０５は、取得要求のあったコンテンツデータ４１０を、通信経路４０９を介してＶＤＰアプリケーションプログラム４０４に返す（ステップＳ８０３）。
ステップＳ８０２、Ｓ８０３は、ＶＤＰジョブファイル４１２に含めるコンテンツデータ４１０の数だけ繰り返される。図６に示したＶＤＰジョブファイル４１２の場合、コンテンツデータ４１０ａ〜４１０ｃが３つ存在するので、ステップＳ８０２、Ｓ８０３が３回繰り返される。
ＶＤＰアプリケーションプログラム４０４は、ステップＳ８０２、Ｓ８０３を繰り返して取得した１つ以上のコンテンツデータ４１０を使用してＶＤＰジョブファイル４１２を作成する（ステップＳ８０４）。このステップＳ８０４で作成されるＶＤＰジョブファイル４１２の概念的な構造は、例えば図６に示したものとなる。
ＶＤＰアプリケーションプログラム４０４は、ステップＳ８０４で作成したＶＤＰジョブファイル４１２を、通信経路４１１を介してＲＩＰプログラム４０６に送信する（ステップＳ８０５）。
ＲＩＰプログラム４０６は、ステップＳ８０５で受信したＶＤＰジョブファイル４１２に含まれるコンテンツデータ４１０のＲＩＰ処理を行ってラスタデータを作成する（ステップＳ８０６）。
ステップＳ８０６は、ＶＤＰジョブファイル４１２に含まれるコンテンツデータ４１０の数だけ繰り返される。図６に示したＶＤＰジョブファイル４１２の場合、コンテンツデータ４１０ａ〜４１０ｃが３つ存在するので、ステップＳ８０６が３回繰り返される。
ＲＩＰプログラム４０６は、ステップＳ８０６で作成したラスタデータを使用して印刷データを作成する（ステップＳ８０７）。そして、ＲＩＰプログラム４０６は、印刷データの印刷処理を行う（ステップＳ８０８）。
図９は、図５に示した本実施形態の特徴を有する印刷システムにおいて、ユーザが印刷を指示した場合に行なわれる印刷処理シーケンスの一例を示す図である。図９でも、図８と同様に、ネットワーク１０４を経由した通信を行う部分と、"｝"で示している部分は、ＵＭＬの記法に従っていない。また、ＶＤＰクライアント１０１における処理とＶＤＰプリンタ１０２における動作とが並行に行われていることを示す表記もＵＭＬの記法に従っていない。図９において、ユーザ９０１は、図４に示したユーザ８０１と同様に、図５に示した印刷システムを使用するアクターの一例を示す。
まず、ユーザ９０１は、キーボード２０６やポインティングデバイス２０７を用いて、ＶＤＰアプリケーションプログラム５０４に印刷を指示する（ステップＳ９０１）。
ＶＤＰアプリケーションプログラム５０４は、ＤＢブローカープログラム５０５に、コンテンツデータの取得要求のメッセージを、通信経路５１１を介して送信する（ステップＳ９０２）。
ＤＢブローカープログラム５０５は、コンテンツデータの取得要求のメッセージを、通信経路１０４ａを介してそのままコンテンツＤＢ５０６に送信する（ステップＳ９０３）。
コンテンツＤＢ５０６は、取得要求のあったコンテンツデータ５１６を、通信経路１０４ｂを介してＤＢブローカープログラム５０５に返す（ステップＳ９０４）。これにより、ＤＢブローカープログラム５０５は、コンテンツデータ５１６を取得する。これによりＶＤＰアプリケーションプログラム４０４は、コンテンツデータ４１０を取得する。このように本実施形態では、例えば、ステップＳ９０４の処理によってコンテンツデータ取得手段、コンテンツデータ取得ステップが実現される。
ＤＢブローカープログラム５０５は、取得したコンテンツデータ５１６を、ＶＤＰアプリケーションプログラム５０４に直接返すのではなく、通信経路１０４ｅを介してキャッシュマネージャプログラム５０９に送信する（ステップＳ９０５）。このように本実施形態では、例えば、ステップＳ９０５の処理によってコンテンツデータ送信手段、コンテンツデータ送信ステップが実現される。
コンテンツデータ５１６を受信したキャッシュマネージャプログラム５０９は、キャッシュＩＤ５２３を生成し（ステップＳ９０６）、生成したキャッシュＩＤ５２３をＤＢブローカープログラム５０５に返信（返信）する（ステップＳ９０７）。ＤＢブローカープログラム５０９は、ステップＳ９０４で取得したコンテンツデータ５１６から作成したサムネイルデータ７０９と、ステップＳ９０７で取得したキャッシュＩＤ５２３とを用いて、プロキシデータ５１３を生成する（ステップＳ９０８）。このステップＳ９０８で生成されるプロキシデータ５１３の概念的な構造は、例えば、図７に示したものとなる。以上のように本実施形態では、例えば、ステップＳ９０６の処理によって、コンテンツデータ受信手段、識別情報生成手段、コンテンツデータ受信ステップ、識別情報生成ステップが実現される。また、例えば、ステップＳ９０７の処理によって、識別情報送信手段、識別情報送信ステップが実現される。更に、例えば、ステップＳ９０８の処理によって、識別情報取得手段、識別情報取得ステップが実現される。
また、ＤＢブローカープログラム５０９は、ステップＳ９０４で取得したコンテンツデータ５１６、コンテンツデータ５１６から作成したサムネイルデータ７０９、ステップＳ９０７で取得したキャッシュＩＤ５２３を対応付けて、外部記憶装置２０４に格納する。これにより、ＤＢブローカープログラム５０５は、ＶＤＰアプリケーションプログラム５０４から取得要求のあったコンテンツデータ５１６に関するキャッシュＩＤ５２３が既に取得されている場合には、ステップＳ９０５〜Ｓ９０７の処理を省略できる。このように本実施形態では、例えば、ステップＳ９０８の処理によって、データ処理装置の記憶手段、データ処理方法の記憶ステップが実現される。
ＤＢブローカープログラム５０９は、ステップＳ９０８で生成したプロキシデータ５１３をＶＤＰアプリケーションプログラム５０４に返信（送信）する（ステップＳ９０９）。ＶＤＰアプリケーションプログラム５０４から見ると、コンテンツデータの取得要求（ステップＳ９０２）に対してプロキシデータ５１３が返ってきたように見える。
ＶＤＰアプリケーションプログラム０４は、ステップＳ９０９で取得したプロキシデータ５１３を、例えば図７に示す構造を持つＶＤＰジョブファイル５１８に追加する（ステップＳ９１０）。このように本実施形態では、例えば、ＶＤＰジョブファイル５１８が画像形成用データに相当し、更に、例えば、ステップＳ９１０の処理によって画像形成用データ送信手段が実現される。
一方、キャッシュマネージャプログラム５０９は、ステップＳ９０７で、キャッシュＩＤ５２３をＤＢブローカープログラム５０５に返す。その後、キャッシュマネージャプログラム５０９は、ステップＳ９０５で受信したコンテンツデータ５１６を、通信経路５２９を介してキャッシュＤＢ５１０に保存する（ステップＳ９１１）。このとき、キャッシュマネージャプログラム５０９は、ステップＳ９０７でＤＢブローカープログラム５０５に返したキャッシュＩＤ５２３と、ステップＳ９０５で受信したコンテンツデータ５１６とを対応付けてキャッシュＤＢ５１０に保存する。尚、キャッシュＤＢ５１０の構造については、図１４を用いて後述する。
キャッシュマネージャプログラム５０９は、ステップＳ９０５で受信したコンテンツデータ５１６と同じコンテンツデータ５１６を、通信経路５２６を介してＲＩＰプログラム５０８に送信する。これにより、コンテンツデータ５１６のラスタライズの要求（ラスタデータの生成要求）がなされる（ステップＳ９１２）。
ＲＩＰプログラム５０８は、ステップＳ９１２で受信したコンテンツデータ５１６に対してラスタライズ処理を行う。そして、ＲＩＰプログラム５０８は、そのラスタライズ処理を行うことにより得られたラスタデータ５０７を、通信経路５２５を介してキャッシュマネージャプログラム５０９に返す（ステップＳ９１３）。以上のように本実施形態では、ステップＳ９１３の処理によって、画像化データ生成手段、画像化データ生成ステップが実現される。
キャッシュマネージャプログラム５０９は、ステップＳ９１３で取得したラスタデータ５０７を、通信経路５２９を介してキャッシュＤＢ５１０に保存する（ステップＳ９１４）。このとき、キャッシュマネージャプログラム５０９は、ステップＳ９０７でＤＢブローカープログラム５０５に返したキャッシュＩＤ５２３と、ステップＳ９１１で保存されたコンテンツデータ５１６と対応付けてラスタデータ５０７を保存する。このように本実施形態では、ステップＳ９１４の処理によって、画像形成装置の記憶手段、画像形成方法の記憶ステップが実現される。
ここで、ＶＤＰクライアント１０１で実行されるステップＳ９０８〜Ｓ９１０と、ＶＤＰプリンタ１０２で実行されるステップＳ９１１〜Ｓ９１４とは、別のハードウェア上で実行されるため、並行処理が可能となっている。
ステップＳ９０２〜Ｓ９１４は、ＶＤＰジョブファイル５１８に含まれるコンテンツデータ（プロキシデータ５１３）の数だけ繰り返される。図７に示したＶＤＰジョブファイル５１８の場合、コンテンツデータ（プロキシデータ５１３ａ〜５１３ｃ）が３つ存在するので、ステップＳ９０２〜Ｓ９１４が３回繰り返される。
ＶＤＰアプリケーションプログラム５０４は、ステップＳ９０２〜Ｓ９１４を繰り返して作成した１つ以上のプロキシデータ５１３を使用して作成したＶＤＰジョブファイル５１８を、ＲＩＰプログラム５０８に送信する（ステップＳ９１５）。このステップＳ９１５で作成されるＶＤＰジョブファイル５１８の概念的な構造は、例えば図７に示したものとなる。
ＲＩＰプログラム５０８は、ステップＳ９１５で受信したＶＤＰジョブファイル５１８にプロキシデータ５１３が含まれていれば、そのプロキシデータ５１３に含まれているキャッシュＩＤ５２３を取得する（図７を参照）。そして、ＲＩＰプログラム５０８は、その取得したキャッシュＩＤ５２３をキーとして、通信経路５２５を介して、キャッシュマネージャプログラム５０９に、ラスタデータ５０７の取得を要求する（ステップＳ９１６）。このように本実施形態では、ステップＳ９１６の処理によって画像形成用データ受信手段、画像形成用データ受信ステップが実現される。
キャッシュマネージャプログラム５０９は、ステップＳ９１６で受信したキャッシュＩＤ５２３をキーとして、通信経路５２９を介してキャッシュＤＢ５１０を検索する（ステップＳ１７）。キャッシュＤＢ５１０は、ステップＳ９１４で保存されたラスタデータ５０７のうち、ステップＳ９１６で受信したキャッシュＩＤ５１３に合致するラスタデータ５０７を検索する。そして、キャッシュＤＢ５１０は、検索したラスタデータ５０７を、通信経路５３０を介してキャッシュマネージャプログラム５０９に返す（ステップＳ９１８）。
キャッシュマネージャプログラム５０９は、ステップＳ９１８で取得したラスタデータ５０７を、通信経路５２６を介してＲＩＰプログラム５０８に返す（ステップＳ９１９）。
ＲＩＰプログラム５０８は、ステップＳ９１９で取得したラスタデータ５０７を印刷データに追加する（ステップＳ９２０）。
ステップＳ９１６〜Ｓ９２０は、ＶＤＰジョブファイル５１８に含まれるプロキシデータ５１３の数だけ繰り返される。図７に示したＶＤＰジョブファイル５１８の場合、コンテンツデータ（プロキシデータ５１３ａ〜５１３ｃ）が３つ存在するので、ステップＳ９１６〜９２０が３回繰り返される。
ＲＩＰプログラム５０８は、ステップＳ９１６〜Ｓ９２０を繰り返して作成した印刷データの印刷処理を行う（ステップＳ９２１）。このように本実施形態では、ステップＳ９２０の処理によって画像形成手段、画像形成ステップが実現される。
＜ＶＤＰアプリケーションのレイアウト画面＞
次に、図１０を参照して、本実施形態で使用されるＶＤＰアプリケーションのレイアウト画面について説明する。
図１０は、ＶＤＰクライアント１０１において、ＶＤＰアプリケーションプログラム５０４がＲＡＭ２０２に読み込まれて実行されている最中に、ディスプレイ２０５に表示されるレイアウト画面の一例を示す図である。
図１０において、１００１は、ＶＤＰアプリケーションプログラム５０４が作成するＶＤＰ文書のレイアウト（編集）を行うためのメインウィンドウである。このメインウィンドウ１００１の境界は、ＶＤＰ文書のページの境界を表している。このように、本実施形態では、メインウィンドウ１００１の領域が、画像形成領域に対応する。
１００２、１００３、１００４、１００５は、固定データや可変データを配置するための枠である。ユーザは、キーボード２０６やポインティングデバイス２０７を使用して、これらの枠１００２〜１００５の作成・移動・選択といった操作を行う。このように本実施形態では、例えば、枠１００２〜１００５が、差込領域に対応する。
図１０に示す例では、ユーザが、キーボード２０６やポインティングデバイス２０７を使用して、枠１００４にテキストデータを入力した様子を示している。後述する図１２の枠管理テーブル１２００に示すように、枠１００２〜１００５に入力されるデータは、固定のテキストデータに限らない。ユーザは、枠１００２〜１００５に入力されるデータを、枠管理テーブル１２００に登録された枠ルールに従って指定することができる。このように、ユーザは、枠管理テーブル１２００に枠ルールを登録することによって固定データや可変データを指定できる。
１００６は、ＶＤＰアプリケーションプログラム５０４に対して指定可能なオプションを指定したり実行可能なコマンドを実行したりするためのメニューウィンドウである。ユーザは、キーボード２０６やポインティングデバイス２０７を使用して、このメニューウィンドウ１００６に対して、入力や操作を行う。
１００７は、作成中のＶＤＰ文書に対して関連付けるデータソースをユーザが指定するためのテキストボックスである。ここでは"CUSTOMER"というテーブルが指定されている。
１００８は、ＶＤＰ文書に作成された枠１００２〜１００５の中から選択した枠に対する枠ルールを、ユーザが表示・編集するためのテキストボックスである。
１００９は、ＶＤＰ文書で使用される固定データのうち、どのデータをキャッシュする対象のデータとするかのかを判断するためのスレッショルド値をユーザが指定するためのテキストボックスである。ここで指定したスレッショルド値以上のサイズを持つ固定データはキャッシュする対象となる。
１０１０は、ＶＤＰ文書の新規作成をユーザが指示するためのボタンである。
１０１１は、ＶＤＰクライアント１０１の外部記憶装置２０４に存在するＶＤＰ文書を開く（オープンする）ことをユーザが指示するためのボタンである。
１０１２は、作成したＶＤＰ文書をＶＤＰクライアント１０１の外部記憶装置２０４への上書き保存をユーザが指示するためのボタンである。１０１３は、作成したＶＤＰ文書をＶＤＰクライアント１０１の外部記憶装置２０４への別名での保存をユーザが指示するためのボタンである。
１０１４は、編集中のＶＤＰ文書を閉じることをユーザが指示するためのボタンである。
ボタン１０１０〜１０４が実行する機能は、Microsoft Windows（登録商標）やApple MacＯＳ（登録商標）で実行されるアプリケーションプログラムにより実現される標準的なものであるので、ここでは詳細な説明を省略する。
１０１５は、新規の枠を作成することをユーザが指示するためのボタンである。ユーザは、キーボード２０６やポインティングデバイス２０７を使用してこのボタン１０１５を押下すると、メインウィンドウ１００１が枠作成モードに変わる。ユーザは、メインウィンドウ１００１が枠作成モードに変わった状態で、キーボード２０６やポインティングデバイス２０７を使用して枠の起点とサイズを指定することにより、新規の枠を作成することができる。枠を作成すると枠作成モードは終了し、メインウィンドウ１００１は、通常の編集状態に戻る。
１０１６は、編集中のＶＤＰ文書をＶＤＰプリンタ１０２で印刷することをユーザが指示するためのボタンである。
＜CUSTOMERテーブルの構造と内容＞
次に、図１１を参照して、本実施形態で使用されるデータソースの構造と内容について説明する。
図１１は、作成中のＶＤＰ文書に関連付けられるデータソースの一例として指定されているCUSTOMERテーブルの内容の一例を示す図である。このCUSTOMERテーブル１１００は、例えば、ＶＤＰクライアント１０１の外部記憶装置２０４に格納される。
１１０１は、レコード番号を示すための列である。このレコード番号１１０１は、データ構造に含まれない。レコード番号は、最初のレコードから順に「１」、「２」、「３」・・・と昇順に発番される。
１１０２〜１１０６は、CUSTOMERテーブル１１００を構成する五つの列である。具体的に１１０２は、姓を格納するLastName列であり、１１０３は、名を格納するFirstName列であり、１１０４は、性別を格納するGender列である。また、１１０５は、郵便番号を格納するZipCode列であり、１１０６は、住所を格納するAddress列である。
LastName列１１０２、FirstName列１１０３、ZipCode列１１０５、Address列１１０６には、任意の文字列を格納することが可能である。一方、Gender列１１０４には、文字"Ｍ"（男性を表わす）又は"Ｆ"（女性を表わす）のみを格納することが可能である。
図１１に示すCUSTOMERテーブル１１００では、レコード番号１〜３の３つのレコードが格納されている。図１５〜図２６を用いて後述する印刷動作では、これら図１１に示すレコードを使用した場合を例に挙げて説明を行う。
＜枠管理テーブルの構造と内容＞
次に、図１２を参照して、本実施形態で使用される枠管理テーブルの構造と内容について説明する。
図１２は、枠１００２〜１００５についての情報をＲＡＭ２０２に格納しておく際に使用する枠管理テーブルの構造と、本実施形態で使用する枠情報の内容との一例を示す図である。この枠管理テーブル１２００は、例えば、ＶＤＰクライアント１０１の外部記憶装置２０４に格納される。
１２０１は、FrameNo列であり、枠番号が格納される。枠番号は枠管理テーブル１２００内で一意に特定されれば任意の数字でよい。
１２０２は、FrameRule列であり、枠ルールが格納される。枠ルールは、枠１００２〜１００５に適用されるコンテンツデータ５１６を導出するためのルールである。具体的に枠ルールは、「条件判定」、「文字列」、「データソース参照」、「コンテンツデータベース参照」の４つの構成要素を使って、最終的に「文字列」又は「コンテンツデータベース参照」の何れかが導出されるように記述される。枠ルールを記述するための枠ルール文法の一例を以下にEBNF（Extended Backus-Naur Form）で示す。
［１］枠ルール::= 文字列 | コンテンツデータ参照 | 条件文
［２］文字列 ::= (リテラル文字列 | データソース参照 | 空白)+
［３］コンテンツデータ参照 ::= (使用文字)+
［４］リテラル文字列 ::= '"' (使用文字)+ '"'
［５］データソース参照 ::= '$' (使用文字)+
［６］条件文 ::= if 空白 判定式 空白 枠ルール 空白 else 空白 枠ルール
［７］判定式 ::= データソース参照 空白? 判定記号 空白? リテラル文字列
［８］判定記号 ::= '='
［９］使用文字 ::= [a-zA-Z0-9] | [-'()+.=#@＿%] | [亜-熙]
［１０]空白 ::= (#x20 | #x9 | #xD | #xA)+
［１］により、枠ルールは、「文字列」、「コンテンツデータ参照」、又は「条件文」である。
［２］により、「文字列」は、「リテラル文字列」、「データソース参照」、又は「空白」を一個以上並べたものである。「文字列」は、「リテラル文字列」や「データソース参照」の結果を連結したものとなる。尚、空白の部分は無視される。
［３］により、「コンテンツデータ参照」は、使用可能な文字（使用文字）を一個以上並べたものである。「コンテンツデータ参照」には、コンテンツＤＢ５０６内のコンテンツデータ５１６のファイルを参照するための情報が記述される。本実施形態では、Microsoft Windows（登録商標）で使われているＵＮＣ（Universal Naming Convention）表記を使用して、「コンテンツデータ参照」の記述がなされる。具体的に、「コンテンツデータ参照」には、コンテンツＤＢ５０６内のコンテンツデータ５１６のファイルがＵＮＣ名で直接表記される。［９］により、使用文字には、「"」や「$」が含まれない。従ってＶＤＰクライアント１０１は、先頭が「"」や「$」で始まっていなければ、「コンテンツデータ参照」であると判定できる。
［４］により、「リテラル文字列」は、使用文字を１個以上並べたものを「"、"」で囲んだものである。「リテラル文字列」は、最終的に文字列を導出する際の構成要素、又は条件文［６］に含まれる判定式［７］で使用される。
［５］により、「データソース参照」は、「$」から始まり、使用文字を一個以上並べたものである。本実施形態では、ＶＤＰアプリケーションプログラム５０４によってＶＤＰ文書に関連付けられているデータソース１００７の列名に「$」を付けて使用する。そして、そのデータソース１００７が参照するテーブルの該当する列のデータに相当する「リテラル文字列」が導出される。例えば、データソースとして、図１１に示すCUSTOMERテーブル１１００がＶＤＰ文書に関連付けられており、「データソース参照」として「$LastName」と指定されているとする。そうすると、レコード番号１のレコードを処理中は"山田"という文字列が導出され、レコード番号２のレコードを処理中は"鈴木"という文字列が導出される。
［６］により、「条件文」は、「if、判定式、枠ルール、else、枠ルール」という順番で表記される。判定式が真と判定されると前者の枠ルールが導出され、判定式が偽と判定されると後者の枠ルールが導出される。［１］により、枠ルールには条件文も含まれるため、条件文を入れ子（ネスト）にして表記することも可能である。
［７］により、「判定式」は、「データソース参照」と「リテラル文字列」とを判定記号でつなげたものである。尚、判定記号の両側には空白があってもよい。
［８］により、判定記号は「＝」である。判定式［７］では、判定記号の左側のデータソース文字列から導出される「リテラル文字列」と、判定記号の右側の「リテラル文字列」とを文字列として比較し、両者が同じ文字列であれば真と判定される。一方、違う文字列であれば偽と判定される。
［９］には、枠ルールで使用可能な文字の定義がなされており、アルファベット、日本語、いくつかの記号が含まれる。
［１０］には、空白文字の定義がなされている。
図１２に説明を戻し、１２０３は、ReusableObject列であり、枠１００２〜１００５に関連付けられたコンテンツデータ５１６が再利用可能オブジェクトか否かを判定するための情報（「TRUE」又は「FALSE」）が格納される。この判定は、ＶＤＰアプリケーションプログラム５０４によって行われる。「TRUE」と判定されるのは、その枠に対する枠ルールがデータソース参照を含まない場合であり、それ以外の場合には、「FALSE」と判定される。
図１０で作成した４つの枠１００２〜１００５に対して、以上のようにして定義された枠ルール文法を使用して決定した枠ルールの一例を図１２に示す。
FrameNo列１２０１に枠番号として「１」が格納されている枠は、図１０に示した枠１００２に対応する。この枠に対する枠ルールは、FrameRule列１２０２の１行目に格納されている通り、「コンテンツデータ参照」である。ここでは、コンテンツＤＢ５０６に存在するコンテンツデータ５１６のファイルを「\\Share\img\logo.jpg」としており、ＵＮＣで「コンテンツデータ参照」の表記をしている。この枠ルールには、「データソース参照」は含まれない。したがって、ReusableObject列１２０３の１行目には、「TRUE」が格納されている。すなわち、「\\Share\img\logo.jpg」で示されるコンテンツデータ５１６は、再利用可能オブジェクトである。コンテンツＤＢ５０６に存在するコンテンツデータ５１６の内容については図１３を使用して後述する。
FrameNo列１２０１に枠番号として「２」が格納されている枠は、図１０に示した枠１００３に対応する。この枠に対する枠ルールは、FrameRule列１２０２の２行目に格納されている通り、「リテラル文字列」と「データソース参照」とを連結したものである。したがって、「データソース参照」を解決すれば文字列が導出される。また、この枠ルールには、「データソース参照」が含まれる。したがって、この枠ルールに従って作成されるコンテンツデータ５１６は、再利用可能オブジェクトではないので、ReusableObject列１２０３の２行目には、「FALSE」が格納される。
FrameNo列１２０１に枠番号として「３」が格納されている枠は、図１０に示した枠１００４に対応する。この枠に対する枠ルールを格納するFrameRule列１２０２には、何もない。このように、FrameRule列１２０２に何も格納されていない場合は、枠（ここでは枠１００４）に入力されたテキストがそのままリテラル文字列として使用されるようにしている。また、この枠ルールには、「データソース参照」が含まれない。したがって、この枠ルールに従って作成されるコンテンツデータ５１６は、再利用可能オブジェクトであるので、ReusableObject列１２０３の３行目には、「TRUE」が格納される。
FrameNo列１２０１に枠番号として「４」が格納されている枠は、図１０に示した枠１００５に対応する。この枠に対する枠ルールは、FrameRule列１２０２の４行目に格納されている通り、「条件文」である。この「条件文」の判定式では、図１１に示したGender列に登録されている値（$Gender）とリテラル文字列「Ｍ」との比較の結果に基づいて、異なるデータソースを参照するようにしている。したがって、「データソース参照」を解決して判定式を評価することにより、いずれかの「コンテンツデータ参照」（「\\Share\img\car.jpg」、「\\Share\img\bag.jpg」）が導出される。このように、各「コンテンツデータ参照」を、コンテンツＤＢ５０６に存在するコンテンツデータ５１６のファイルをＵＮＣで表記している。
＜コンテンツＤＢ５０６の内容＞
次に、図１３を参照して、本実施形態で使用されるコンテンツＤＢ５０６の内容の一例について説明する。
図１３は、コンテンツＤＢ５０６に存在するコンテンツデータ５１６のうち、本実施形態の説明に必要なコンテンツデータの情報の一例を示す図である。
図１３において、１３０１は、FrameRule列１２０２に格納されている枠ルールにおいて、「コンテンツデータ参照」を記述する場合に使用されるパス名を格納する領域である。前述したように、本実施形態では、このパス名を、ＵＮＣで表記している。
１３０２は、コンテンツデータ５１６のファイルサイズを格納する領域である。
１３０３は、コンテンツデータ５１６が表示、或いは印刷される場合の様子を表示するためのサムネイルデータ７０９を格納する領域である。
＜キャッシュＤＢ５１０の構造＞
次に、図１４を参照して、本実施形態で使用されるキャッシュＤＢ５１０の構造について説明する。
図１４は、キャッシュＤＢ５１０の構造の一例を示す図である。
図１４において、１４０１は、キャッシュＩＤ５２３を格納する領域である。キャッシュＩＤ５２３は、各レコードについて一意となるようにキャッシュマネージャプログラム５０９によって発番される。
１４０２は、コンテンツＩＤを格納する領域である。コンテンツＩＤは、同一のコンテンツデータ５１６に対して、同一の値となるようにキャッシュマネージャプログラム５０９によって発番される。
１４０３は、コンテンツデータ５１６を格納する領域である。
１４０４は、コンテンツデータ５１６をＲＩＰプログラム５０８がＲＩＰすることにより得られたラスタデータ５０７を格納する領域である。
＜ＶＤＰアプリケーションプログラム５０４の動作＞
次に、図１５のフローチャートを参照して、ボタン１０１６がユーザによって押され、印刷が指示された場合のＶＤＰアプリケーションプログラム５０４における動作の一例について説明する。尚、図１５のフローチャートは、ＣＰＵ２０１が、例えば外部記憶装置２０４に格納されたプログラムをＲＡＭ２０２に展開して実行することにより実現される。ここで、図１０に示したレイアウト画面において、ＶＤＦ文書の編集を行うためのメインウィンドウ１００１には、図１１に示したCUSTOMERテーブル１１００がデータソースとして関連付けられている。また、メインウィンドウ１００１に作成された枠１００２〜１００５には、図１２に示した枠管理テーブル１２００の情報（枠番号、枠ルール、再利用可能オブジェクトか否かを示す情報（フラグ））が設定されている。
図１５の処理を大まかに分けると、ステップＳ１５０１が前処理、ステップＳ１５０２〜Ｓ１５１２が再利用可能オブジェクトの処理、ステップＳ１５１３〜Ｓ１５２８が印刷データの作成処理、ステップＳ１５２９が印刷データの送信処理となる。
まず、ステップＳ１５０１において、ＶＤＰアプリケーションプログラム５０４は、ＶＤＰジョブファイル５１８を作成するための一時的なディレクトリをＶＤＰクライアント５０１の外部記憶装置２０４に作成する。この一時的なディレクトリのディレクトリのパス名をtmpDirとする。
ステップＳ１５０２〜１５１２は、ＶＤＰアプリケーションプログラム５０４が、ＶＤＰ文書に含まれる再利用可能オブジェクトを処理するためのループ処理となっている。すなわち、ステップＳ１５０２〜１５１２では、図１２に示した枠管理テーブル１２００に存在する枠情報に対して順番に処理が行われる。ループ処理の終了はステップＳ１５０４で判定される。
ステップＳ１５０２において、ＶＤＰアプリケーションプログラム５０４は、図１２に示した枠管理テーブル１２００を参照するための変数frameIndexをＲＡＭ２０２に用意し、その変数frameIndexの値を０にする（初期化する）。
次に、ステップＳ１５０３において、ＶＤＰアプリケーションプログラム５０４は、変数frameIndexの値を増分（＋１）する。
次に、ステップＳ１５０４において、ＶＤＰアプリケーションプログラム５０４は、変数frameIndexの値が、図１２に示した枠管理テーブル１２００に格納されている枠の数以下であるか否かを判定する。この判定の結果、変数frameIndexの値が枠の数以下であれば、ループ処理を継続すると判定してステップＳ１５０５に進む。一方、変数frameIndexの値が枠の数より大きければ、ループ処理を終了すると判定して後述する図１５−２のステップＳ１５１３に進む。
ステップＳ１５０５において、ＶＤＰアプリケーションプログラム５０４は、枠情報を保持するための変数frameInfoがまだ用意されていなければＲＡＭ２０２に用意する。そして、ＶＤＰアプリケーションプログラム５０４は、図１２に示した枠管理テーブル１２００に格納されている枠情報のうち、frameIndex番目の枠情報を、変数frameInfoに格納する。
次に、ステップＳ１５０６において、ＶＤＰアプリケーション５０４は、ステップＳ１５０５で格納した枠情報に含まれるReusableObject列１２０３の値が、「TRUE」か否かを判定する。すなわち、ＶＤＰアプリケーション５０４は、ステップＳ１５０５で格納した枠情報で特定される枠に関連づけられたコンテンツデータ５１６が、再利用可能なオブジェクトか否かを判定する。この判定の結果、ReusableObject列１２０３の値が、「FALSE」であれば、枠に関連づけられたコンテンツデータ５１６が、再利用可能なオブジェクトでないと判定して、ステップＳ１５０３に戻り、次の枠情報に対する処理を開始する。
一方、ReusableObject列１２０３の値が、「TRUE」であれば、枠に関連づけられたコンテンツデータ５１６が、再利用可能なオブジェクトであると判定して、ステップＳ１５０７に進む。図１２に示した例では、変数frameIndexの値が「１」の場合と、変数frameIndexの値が「３」の場合に（枠１００２、１００４の場合）、枠に関連づけられたコンテンツデータ５１６が再利用可能オブジェクトであると判定される。
ステップＳ１５０７において、ＶＤＰアプリケーションプログラム５０４は、再利用可能なオブジェクトであるコンテンツデータ５１６の枠ルールを特定するための変数pathNameがまだ用意されていなければＲＡＭ２０２に用意する。そして、ＶＤＰアプリケーションプログラム５０４は、用意した変数pathNameを、枠情報に含まれる枠ルール（FrameRule列１２０２に格納されている枠ルール）に初期化する。ステップＳ１５０６の判定処理と、図１２の枠管理テーブル１２００における再利用可能オブジェクトか否かの判定方法とにより、このステップＳ１５０７で変数pathNameにより特定される枠ルールには「データソース参照」が含まれない。すなわち、図１２に示した例では、コンテンツデータ５１６が再利用可能なオブジェクトでなければ、そのコンテンツデータ５１６が入る枠に対する枠ルールには、「データソース参照」が含まれない。したがって、変数pathNameは、「空」か、「リテラル文字列」か、「コンテンツデータ参照」かの何れかとなる。
次に、ステップＳ１５０８において、ＶＤＰアプリケーションプログラム５０４は、変数pathNameが「空」又は「リテラル文字」か否かを判定する。すなわち、ＶＤＰアプリケーションプログラム５０４は、枠に入力された「テキスト」又は「リテラル文字列」を処理するのか、それとも「コンテンツデータ参照」を利用するのかを判定する。この判定の結果、変数pathNameが「空」又は「リテラル文字列」であれば、枠に入力された「テキスト」又は「リテラル文字列」を処理すると判定して、ステップＳ１５０９に進む。一方、変数pathNameが「空」又は「リテラル文字列」でなければ、コンテンツデータ５１６を参照すると判定して後述するステップＳ１５１１に進む。図１２の枠管理テーブル１２００の例では、変数frameIndexが「１」の場合は、変数pathNameが「コンテンツデータ参照」なのでステップＳ１５１１進む。一方、変数frameIndexが「３」の場合は、変数pathNameが「空」なのでステップＳ１５０９に進む。
ステップＳ１５０９に進むと、ＶＤＰアプリケーションプログラム５０４は、枠に入力された「テキスト」又は「リテラル文字列」をPostScriptデータに変換する。そして、ＶＤＰアプリケーションプログラム５０４は、そのPostScriptデータを、ステップＳ１５０１でＲＡＭ２０２に用意した変数tmpDataが指す一時的なディレクトリに格納する。ここで、変数pathNameが「空」の場合には、処理中の枠（枠管理テーブル１２００のframeIndex番目の枠）に対してメインウィンドウ１００１に入力されたテキストデータを文字列として使用する。一方、変数pathNameが「リテラル文字列」の場合には、その「リテラル文字列」を文字列としてそのまま使用する。図１２の枠管理テーブル１２００の例では、変数frameIndexが「３」の場合（図１０の枠１００４の場合）に、変数pathNameが「空」になる。したがって、図１０の枠１００４に入力されたテキストがPostScriptデータに変換されて変数tmpDataに格納される。
次に、ステップＳ１５１０において、ＶＤＰアプリケーションプログラム５０４は、変数isPorxy、data、cacheIdがまだ用意されていなければＲＡＭ２０２に用意する。そして、変数tmpDataに格納されているPostScriptデータの内容を引数として、ＤＢブローカープログラム５０５に対して、キャッシュＩＤの生成を依頼する。その後、ＶＤＰアプリケーションプログラム５０４は、ＤＢブローカープログラム５０５から、プロキシデータ５１２とキャッシュＩＤ５１６を受け取る。そして、ＶＤＰアプリケーションプログラム５０４は、受け取ったプロキシデータ５１２とキャッシュＩＤ５２３を、変数dataと変数cacheIdに夫々格納する。また、ＶＤＰアプリケーションプログラム５０４は、変数isProxyに「TRUE」を格納する。そして、ステップＳ１５１２に進む。尚、キャッシュＩＤの生成の依頼を受けたＤＢブローカープログラム５０５の動作は、図１６を使用して後述する。
尚、ステップＳ１５１０において、ＶＤＰアプリケーションプログラム５０４は、取得する必要のあるキャッシュＩＤ５２３とプロキシデータ５１２とが、変数cacheIdと変数dataとに既に記録されているか否かを判定する。この判定の結果、取得する必要のあるキャッシュＩＤ５２３とプロキシデータ５１２とが既に記録されている場合には、キャッシュＩＤの生成を依頼しないようにする。一方、取得する必要のあるキャッシュＩＤ５２３とプロキシデータ５１２とが既に記録されている場合には、前述したように、キャッシュＩＤの生成を依頼する。
前記ステップＳ１５０８において、変数pathNameが「空」又は「リテラル文字列」でないと判定された場合には、ステップＳ１５１１に進む。ステップＳ１５１１に進むと、ＶＤＰアプリケーションプログラム５０４は、変数isPorxy、data、cacheIdがまだ用意されていなければＲＡＭ２０２に用意する。ＶＤＰアプリケーションプログラム５０４は、変数pathNameに格納されている「コンテンツデータ参照」から特定されるコンテンツデータ５１６の名前を第１の引数として、ＤＢブローカープログラム５０５にコンテンツデータ５１６の取得を依頼する。このときＶＤＰアプリケーションプログラム５０４は、ステップＳ１５０６の判定の結果からも明らかなように、再利用可能オブジェクトを処理している。再利用可能オブジェクトは、複数のページで使用される。このため、ＶＤＰアプリケーションプログラム５０４は、再利用可能オブジェクトを常にキャッシュした方が効率がよいと判断する。そして、ＶＤＰアプリケーションプログラム５０４は、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）を「TRUE」に設定し、ＤＢブローカープログラム５０５に送信する。
ＶＤＰアプリケーションプログラム５０４は、コンテンツデータ５１６の取得を依頼すると、ＤＢブローカープログラム５０５から、データ、そのデータがプロキシデータか否かを識別するためのフラグ、及びキャッシュＩＤ５２３を受け取る。そして、ＶＤＰアプリケーションプログラム５０４は、受け取ったデータ、そのデータがプロキシデータか否かを識別するためのフラグ、及びキャッシュＩＤ５２３を、変数data、変数isProxy、変数cacheIdに夫々格納する。そして、ステップＳ１５１２に進む。尚、コンテンツデータ５１６の取得の依頼を受けたＤＢブローカープログラム５０５の動作は、図１６を使用して後述する。
尚、ステップＳ１５１１においても、ＶＤＰアプリケーションプログラム５０４は、取得する必要のあるデータが、変数data、変数isProxy、変数cacheIdに既に記録されているか否かを判定する。この判定の結果、取得する必要のあるデータが既に記録されている場合には、コンテンツデータの取得を依頼しないようにする。一方、取得する必要のあるデータが既に記録されている場合には、前述したように、コンテンツデータの取得を依頼する。
ステップＳ１５１２に進むと、ＶＤＰアプリケーションプログラム５０４は、コンテンツデータ５１６を保持するための配列contentData[]がまだ用意されていなければＲＡＭ２０２に用意する。そして、ＶＤＰアプリケーションプログラム５０４は、ステップＳ１５１０又はＳ１５１１で変数dataに格納した情報を、ステップＳ１５０１で用意した変数tmpDirが指す一時的なディレクトリに格納する。ここで、一時的なディレクトリに格納する情報のファイル名を「"0000"＋"枠番号"」とする。枠番号は、処理中の枠に対してFrameNo列１２０１に格納されている値を４桁で表わしたものとする。尚、FrameNo列１２０１に格納されている値が４桁に満たない部分は、満たない部分を"０"で埋めた文字列とする。例えば、処理中の枠に対してFrameNo列１２０１に格納されている値（枠番号）が「１」の場合、ファイル名は"00000001"となる。ファイル名の拡張子は、変数dataが保持しているデータの種別に応じて適切なものが使用される。
ＶＤＰアプリケーションプログラム５０４は、このようにして与えられるファイル名をＲＡＭ２０２に用意した変数fileNameに格納する。ＶＤＰアプリケーションプログラム５０４は、変数frameIndexの値を参照する。そして、ＶＤＰアプリケーションプログラム５０４は、コンテンツデータ５１６を保持するための配列contentData[]に対して、変数fileName、変数isProxy、変数cacheIdの値をそれぞれ格納する。そして、ステップＳ１５０３に戻る。
前記ステップＳ１５０４において、枠管理テーブル１２００を参照するための変数frameIndexの値が枠の数より大きいと判定された場合には、図１５−２のステップＳ１５１３に進む。図１５−２のステップＳ１５１３〜Ｓ１５２８は、ＶＤＰ文書に関連付けられたデータソースを枠ルールに適用することで、ＶＤＰアプリケーションプログラム５０４が、データソースのレコード毎にＶＤＰ文書のPPMLファイルのページを作成する処理である。これらステップＳ１５１３〜Ｓ１５２８は、二重ループになっている。外側のループであるステップＳ１５１３〜Ｓ１５２８は、データソースの各レコードを処理するループである。この外側のループの終了はステップＳ１５１５で判定される。一方、内側のループであるステップＳ１５１６〜Ｓ１５２７は、ＶＤＰ文書に存在する各枠の枠ルールに対してレコードを適用する処理である。この内側のループの終了はステップＳ１５１８で判定される。
ステップＳ１５１３において、ＶＤＰアプリケーションプログラム５０４は、図１１に示したCUSTOMERテーブル１１００を参照するための変数recordNoをＲＡＭ２０２に用意し、その変数recordNoの値を０にする（初期化する）。
次に、ステップＳ１５１４において、ＶＤＰアプリケーションプログラム５０４は、変数recordNoの値を増分（＋１）する。
次に、ステップＳ１５１５において、ＶＤＰアプリケーションプログラム５０４は、変数recordNoの値が、図１１に示したCUSTOMERテーブル１１００に格納されているレコードの数以下であるか否かを判定する。この判定の結果、変数recordNoの値がレコードの数以下でなければ、ループの終了と判定して後述するステップＳ１５２９に進む。一方、変数recordNoの値がレコードの数以下であれば、ループを継続すると判定してステップＳ１５１６に進む。
ステップＳ１５１６において、ＶＤＰアプリケーションプログラム５０４は、ステップＳ１５０３でＲＡＭ２０２に用意した変数frameIndexの値を０にする（初期化する）。
次に、ステップＳ１５１７において、ＶＤＰアプリケーションプログラム５０４は、変数frameIndexの値を増分（＋１）する。
次に、ステップＳ１５１８において、ＶＤＰアプリケーションプログラム５０４は、変数frameIndexの値が、図１２に示した枠管理テーブル１２００に格納されている枠の数以下であるか否かを判定する。この判定の結果、変数frameIndexの値が枠の数より大きければ、ループ処理を終了すると判定して後述する図１５−２のステップＳ１５２８に進む。一方、変数frameIndexの値が枠の数以下であれば、ループ処理を継続すると判定してステップＳ１５１９に進む。
ステップＳ１５１９において、ＶＤＰアプリケーションプログラム５０４は、図１２に示した枠管理テーブル１２００に格納されている枠情報のうち、frameIndex番目の枠情報を、ステップＳ１５０５で用意した変数frameInfoに格納する。
次に、ステップＳ１５２０において、ＶＤＰアプリケーションプログラム５０４は、ステップＳ１５１９で格納した枠情報に含まれるReusableObject列１２０３の値が、「TRUE」か否かを判定する。すなわち、ＶＤＰアプリケーション５０４は、ステップＳ１５１９で格納した枠情報で特定される枠に関連づけられたコンテンツデータ５１６が、再利用可能なオブジェクトか否かを判定する。
この判定の結果、ReusableObject列１２０３の値が、「TRUE」であれば、枠に関連づけられたコンテンツデータ５１６が、再利用可能なオブジェクトであると判定する。この場合、再利用可能オブジェクトのコンテンツデータ５１６は、ステップＳ１５０２〜Ｓ１５１２で処理済みなので、ステップＳ１５１７に戻り、次のループを開始する。
一方、ReusableObject列１２０３の値が、「FALSE」であれば、枠に関連づけられたコンテンツデータ５１６が、再利用可能なオブジェクトでないと判定して、ステップＳ１５２１に進む。図１２に示した例では、変数frameIndexの値が「２」の場合と、変数frameIndexの値が「４」の場合（枠１００３、１００５の場合）に、枠に関連づけられたコンテンツデータ５１６が再利用可能オブジェクトではないと判定される。
ステップＳ１５２１において、ＶＤＰアプリケーションプログラム５０４は、変数recordがまだ用意されていなければＲＡＭ２０２に用意する。そして、ＶＤＰアプリケーションプログラム５０４は、図１１に示したCUSTOMERテーブル１１００に格納されているレコード情報のうち、recordNo番目のレコード情報を、変数recordに格納する。
次に、ステップＳ１５２２において、ＶＤＰアプリケーションプログラム５０４は、ステップＳ１５１９で格納した枠情報に含まれる枠ルール（FrameRule列１２０２の情報）に、ステップＳ１５２１で格納したレコード情報を適用する。ステップＳ１５２１の判定処理と、図１２の枠管理テーブル１２００における再利用可能オブジェクトか否かの判定方法とにより、このステップ１５２２で処理される枠ルールには「データソース参照」が含まれる。そこで、ＶＤＰアプリケーションプログラム５０４は、その「データソース参照」に、変数recordに格納されているレコード情報を適用することで、枠ルールとして「リテラル文字列」か「コンテンツデータ参照」の何れかを導出する。そして、ＶＤＰアプリケーションプログラム５０４は、導出した「リテラル文字列」又は「コンテンツデータ参照」を、ステップＳ１５０７で用意した変数pathNameに格納する。
例えば、変数recordNoが「１」であり、且つ変数frameIndexが「２」の場合、変数recordに含まれる情報は、図１１に示すレコード番号が「１」の情報である。そして、変数frameInfoに含まれる情報は、図１２に示すFrameNoが「２」の情報である。このとき、枠ルールは、次のようになる。
"〒" $ZipCode
$Address
$LastName $FirstName "様"
この枠ルールに含まれるコンテンツデータ参照（$ZipCode）を、レコード番号が「１」の場合におけるZipCode列１１０５の値（111-2222）に置き換える。その他のコンテンツデータ参照（$Address、$LastName、$FirstName）も同様に、レコード番号が「１」の場合におけるAddress列１１０６、LastName列１１０２、FirstName列１１０３の値に夫々置き換える。その結果、枠ルールから以下のリテラル文字列が導出される。
〒111-2222
東京都千代田区丸の内○−○−○
山田 太郎 様
また、例えば、変数recordNoが「１」であり、且つ変数frameIndexが「４」の場合、変数recordに含まれる情報は、図１１に示すレコード番号が「１」の情報である。そして、変数frameInfoに含まれる情報は、図１２に示すFrameNoが「４」の情報である。このとき、枠ルールは、次のようになる。
if $Gender="M"
\\Share\img\car.jpg
else
\\Share\img\bag.jpg
この枠ルールに含まれるコンテンツデータ参照（$Gender）を図１１に示すレコード番号が「１」の場合におけるGender列１１０４の値（Ｍ）に置き換える。そして、「条件文」に対して前述した枠ルール文法［６］を適用すると、「コンテンツ参照（\\Share\img\car.jpg）」が導出される。
図１５−２に説明を戻し、ステップＳ１５２３において、ＶＤＰアプリケーションプログラム５０４は、変数pathNameが「リテラル文字」か否かを判定する。すなわち、ＶＤＰアプリケーションプログラム５０４は、枠に入力されたリテラル文字列を処理するのか、それとも「コンテンツデータ参照」を利用するのかを判定する。この判定の結果、変数pathNameが「リテラル文字列」であれば、リテラル文字列を処理すると判定して、ステップＳ１５２４に進む。一方、変数pathNameが「リテラル文字列」でなければ、コンテンツトデータ５１６を参照すると判定してステップＳ１５２６に進む。
図１２の枠管理テーブル１２００の例では、変数frameIndexが「２」の場合は、変数pathNameが「リテラル文字列」なのでステップＳ１５２４に進む。一方、変数frameIndexが「４」の場合は、変数pathNameが「コンテンツ参照」なので後述するステップＳ１５２６に進む。
ステップＳ１５２４に進むと、ＶＤＰアプリケーションプログラム５０４は、枠に入力されたリテラル文字列をPostScriptデータに変換する。そして、ＶＤＰアプリケーションプログラム５０４は、そのPostScriptデータを、ステップＳ１５０１でＲＡＭ２０２に用意した変数tmpDataが指す一時的なディレクトリに格納する。図１２に示す枠管理テーブルの例において、変数frameIndexが「２」の場合は、前述した
〒111-2222
東京都千代田区丸の内○−○−○
山田 太郎 様
というリテラル文字列がPostScriptデータに変換されて変数tmpDataが指す一時的なディレクトリに格納される。
次に、ステップＳ１５２５において、ＶＤＰアプリケーションプログラム５０４は、変数tmpDataに格納されているPostScriptデータを引数として、ＤＢブローカープログラム５０５に対して、キャッシュＩＤの生成を依頼する。その後、ＶＤＰアプリケーションプログラム５０４は、ＤＢブローカープログラム５０５から、プロキシデータ５１２とキャッシュＩＤ５２３を受け取る。また、ＶＤＰアプリケーションプログラム５０４は、変数isProxyに「TRUE」を格納する。そして、ステップＳ１５２７に進む。尚、キャッシュＩＤの生成の依頼を受けたＤＢブローカープログラム５０５の動作は、図１６を使用して後述する。
前記ステップＳ１５２３において、変数pathNameが「リテラル文字列」でないと判定された場合には、ステップＳ１５２６に進む。そして、ＶＤＰアプリケーションプログラム５０４は、変数pathNameに格納されている「コンテンツデータ参照」から特定されるコンテンツデータの名前を第１の引数として、ＤＢブローカープログラム５０５にコンテンツデータ５１６の取得を依頼する。また、ＶＤＰアプリケーションプログラム５０４は、サイズの大きなオブジェクトのみをキャッシュした方が効率がよいと判断し、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）を「FALSE」に設定する。そして、ＶＤＰアプリケーションプログラム５０４は、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）の値をＤＢブローカープログラム５０５に送信する。更に、ＶＤＰアプリケーションプログラム５０４は、キャッシュするか否かを判定する際のスレッショルド値（第３の引数）として、図１０のテキストボックス１００９に入力された値を設定し、ＤＢブローカープログラム５０５に送信する。尚、ここでは、キャッシュするか否かを判定する際のスレッショルド値を「200KB」とする。
ＶＤＰアプリケーションプログラム５０４は、コンテンツデータ５１６の取得を依頼すると、ＤＢブローカープログラム５０５から、データ、プロキシデータか否かを識別するためのフラグ、及びキャッシュＩＤ５２３を受け取る。そして、ＶＤＰアプリケーションプログラム５０４は、受け取ったデータ、そのデータがプロキシデータか否かを識別するためのフラグ、及びキャッシュＩＤ５２３を、変数data、変数isProxy、及び変数cacheIdに夫々格納する。そして、ステップＳ１５２７に進む。尚、コンテンツデータ５１６の取得の依頼を受けたＤＢブローカープログラム５０５の動作は、図１６を使用して後述する。
ステップＳ１５２７に進むと、ＶＤＰアプリケーション５０４は、ステップＳ１５２５又はＳ１５２６で変数dataに格納した情報を、ステップＳ１５０１で用意した変数tmpDirが指す一時的なディレクトリに格納する。ここで、一時的なディレクトリに格納する情報のファイル名を「"レコード番号"+"枠番号"」とする。レコード番号は、処理中のレコードに対してレコード番号の列１１０１に格納されている値を４桁で表わしたものとする。レコード番号の列１１０１に格納されている値が４桁に満たない部分は、満たない部分を"０"で埋めた文字列とする。また、枠番号は、処理中の枠に対してFrameNo列１２０１に格納されている値を４桁で表わしたものとする。尚、FrameNo列１２０１に格納されている値が４桁に満たない部分は、満たない部分を"０"で埋めた文字列とする。
例えば、処理中のレコードに対してレコード番号の列１１０１に格納されている値（レコード番号）が「２」であり、処理中の枠に対してFrameNo列１２０１に格納されている値（枠番号）が「３」の場合、ファイル名は"00020003"となる。ファイル名の拡張子は、変数dataが保持しているデータの種別に応じて適切なものが使用される。
ＶＤＰアプリケーションプログラム５０４は、このようにして与えられるファイル名をＲＡＭ２０２に用意した変数fileNameに格納する。ＶＤＰアプリケーションプログラム５０４は、変数frameIndexの値を参照する。そして、ＶＤＰアプリケーションプログラム５０４は、ステップＳ１５１２で用意したコンテンツデータ５１６を保持するための配列contentData[]に対して、変数fileName、変数isProxy、変数cacheIdの値を夫々格納する。そして、ステップＳ１５１７に戻る。
前記ステップＳ１５１８において、変数frameIndexの値が枠の数より大きいと判定された場合には、ステップＳ１５２８に進む。そして、ＶＤＰアプリケーションプログラム５０４は、コンテンツデータ５１６を保持するための配列contentData[]に格納されたデータを利用して、recordNoページ目のPPMLデータファイル７０２を作成する。ここで、ステップＳ１５０１で用意した変数tmpDirが指す一時的なディレクトリに保存されたコンテンツデータ５１６又はプロキシデータ５１２が参照される。作成されたPPMLデータファイル７０２も、ステップＳ１５０１で用意した変数tmpDirが指す一時的なディレクトリに保存される。そして、ステップＳ１５１４に戻る。
前記ステップＳ１５１５において、変数recordNoの値がレコードの数以下でないと判定された場合には、ステップＳ１５２９に進む。そして、ＶＤＰアプリケーションプログラム５０４は、ステップＳ１５０１で用意した変数tmpDirが指す一時的なディレクトリに格納されている内容を全てＺＩＰフォーマットで結合及び圧縮し、ＶＤＰジョブファイル５１８を作成する。ＶＤＰアプリケーションプログラム５０４は、作成したＶＤＰジョブファイル５１８を、ＲＩＰプログラム５０８に送信する。尚、ＶＤＰジョブファイル５１８を受信したＲＩＰ５０８の動作は、図１８を使用して後述する。
＜ＤＢブローカープログラム５０５の動作＞
図１６のフローチャートを参照して、ステップＳ１５１０、Ｓ１５２５でキャッシュＩＤの生成が依頼された場合と、ステップＳ１５１１、Ｓ１５２６でコンテンツデータ５１６の取得が依頼された場合のＤＢブローカープログラム５０５の動作の一例を説明する。尚、図１６のフローチャートは、ＣＰＵ２０１が、例えば外部記憶装置２０４に格納されたプログラムをＲＡＭ２０２に展開して実行することにより実現される。
まず、ステップＳ１６０１においてＤＢブローカープログラム５０５は、ＶＤＰアプリケーションプログラム５０４から、コンテンツデータ５１６の取得依頼があったか否かを判定する。この判定の結果、コンテンツデータ５１６の取得依頼がなかった場合には、後述するステップＳ１６０７に進む。一方、コンテンツデータ５１６の取得依頼があった場合には、ステップＳ１６０２に進む。
尚、前述したように、コンテンツデータ５１６の取得依頼に際しては、変数pathNameに格納されている「コンテンツデータ参照」から特定されるコンテンツデータの名前が第１の引数としてＤＢブローカープログラム５０５に送信される。また、常にキャッシュを行うか否かを識別するためのフラグが第２の引数としてＤＢブローカープログラム５０５に送信される。更に、キャッシュするか否かを判定する際のスレッショルド値が第３の引数としてＤＢブローカープログラム５０５に送信される。
ステップＳ１６０２において、ＤＢブローカープログラム５０５は、ＲＡＭ２０２に変数data、isProxy、cacheIdを用意する。ＤＢブローカープログラム５０５は、第１の因数と同じファイル名のコンテンツデータ５１６を、通信経路１０４ａ、１０４ｂを通じてコンテンツＤＢ５０６から取得する。そして、ＤＢブローカープログラム５０５は、取得したコンテンツデータ５１６を変数dataに格納する。また、ＤＢブローカープログラム５０５は、変数isProxyと変数cacheIdの値を、夫々「FALSE」と「N/A（値なし）」に初期化する。
次に、ステップＳ１６０３において、ＤＢブローカープログラム５０５は、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）が、「TRUE」か否かを判定する。この判定の結果、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）が、「TRUE」である場合には、キャッシュを行うと判定して、後述するステップＳ１６０５に進む。一方、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）が、「FALSE」である場合には、ステップＳ１６０４に進む。
ステップＳ１６０４に進むと、ＤＢブローカープログラム５０５は、ステップＳ１６０２で変数dataに格納したコンテンツデータ５１６の容量が、キャッシュするか否かを判定する際のスレッショルド値（第３の引数）よりも大きいか否かを判定する。この判定の結果、変数dataに格納したコンテンツデータ５１６の容量が、キャッシュするか否かを判定する際のスレッショルド値（第３の引数）よりも大きい場合には、キャッシュを行うと判定して、ステップＳ１６０５に進む。一方、変数dataに格納したコンテンツデータ５１６の容量が、キャッシュするか否かを判定する際のスレッショルド値（第３の引数）よりも大きくない場合には、キャッシュを行わないと判定する。この場合、コンテンツデータ５１６の取得依頼に対する戻り値（変数data、変数isProxy、変数cacheId）として、以下のデータがＤＢブローカープログラム５０５からＶＤＰアプリケーションプログラム５０４に返される。すなわち、変数dataの値として引数pathNameで指定されたコンテンツデータ５１６の内容が返される。また、変数isProxyの値として「FALSE」が返される。更に、変数cacheIdの値として「N/A（値なし）」が返される。
ステップＳ１６０４でキャッシュを行わないと判定されるのは、例えば次のような場合である。即ち、枠１００４（図１２のFrameNoが「４」の枠）に対して、第２の引数として「FALSE」が設定され、第３の引数として「200KB」が設定された場合のうち、レコード番号が「２」のレコードをステップＳ１５２６で処理している場合である。この場合、レコード番号が「２」のレコードは$Genderの値が「Ｆ」であることから、枠１００４に対する枠ルールは、「\\Share\img\bag.jpg」と導出される。そして、このファイルパスに一致するコンテンツデータ５１６のサイズは、図１３に示すように100KBである。したがって、ステップＳ１６０４において、Ｎｏと判定される。
以上のように本実施形態では、例えば、ステップＳ１６０３、Ｓ１６０４で予め定められた条件に基づいて、キャッシュＩＤ５２３を生成するか否か（コンテンツデータ５１６の代わりとしてキャッシュＩＤ５２３を用いるか否か）を判定する。
前記ステップＳ１６０４において、変数dataに格納したコンテンツデータ５１６の容量が、キャッシュするか否かを判定する際のスレッショルド値（第３の引数）よりも大きい場合には、ステップＳ１６０５に進む。ステップＳ１６０５に進むと、ＤＢブローカープログラム５０５は、変数dataに格納したコンテンツデータ５１６の内容を引数として、キャッシュマネージャプログラム５０９に、キャッシュＩＤ５２３の取得依頼を行う。このキャッシュＩＤ５２３の取得依頼には、通信経路１０４ｄ、１０４ｅが使用される。その後、キャッシュマネージャプログラム５０９から、プロキシデータ５１２とキャッシュＩＤ５２３とが返されるので、ＤＢブローカープログラム５０５は、キャッシュＩＤ５２３をＲＡＭ２０２に用意した変数data、cacheIdに夫々格納する。また、ＤＢブローカープログラム５０５は、変数isProxyに「TRUE」を格納する。この場合、コンテンツデータ５１６の取得処理に対する戻り値（変数data、変数isProxy、変数cacheId）として、以下のデータがＤＢブローカープログラム５０５からＶＤＰアプリケーションプログラム５０４に返される。即ち、変数dataの値として、キャッシュマネージャプログラム５０９から送信されたプロキシデータ５１３が返される。また、変数isProxyの値として「TRUE」が返される。更に、変数cacheIdの値として、キャッシュマネージャプログラム５０９から送信されたキャッシュＩＤ５２３が返される。
ステップＳ１６０５の処理が行われるのは、例えば次のようにして、ステップＳ１５１１において、コンテンツデータ５１６の取得依頼があった場合である。即ち、「TRUE」が設定された第２の引数がＤＢデータプログラム５０５に送信された場合である。この場合には、ステップＳ１６０３においてＹｅｓと判定され、ステップＳ１６０５に処理が進む。
また、枠１００４に対して、第２の引数として「FALSE」が設定され、第３の引数として「200KB」が設定され、且つレコード番号が「１」及び「３」のレコードをステップＳ１５２６で処理している場合にもステップＳ１６０５の処理が行われる。この場合、レコード番号が「１」及び「３」のレコードは$Genderの値が「Ｍ」であることから、枠１００４に対する枠ルールは、「\\Share\img\car.jpg」と導出される。そして、このファイルパスに一致するコンテンツデータ５１６のサイズは、図１３に示すように「300KB」である。したがって、ステップＳ１６０４において、Ｙｅｓと判定されステップＳ１６０５に処理が進む。
尚、キャッシュマネージャプログラム５０９のキャッシュ処理の動作については、図１７を使用して後述する。
次に、ステップＳ１６０６において、ＤＢブローカープログラム５０５は、変数dataに格納したコンテンツデータ５１６の内容から、サムネイルデータ７０９を作成し、ＲＡＭ２０２に用意した変数dataに格納する。そして、ＤＢブローカープログラム５０５は、変数data、isProxy、変数cacheIdの値を戻り値として、ＶＤＰアプリケーションプログラム５０４に返す。
前記ステップＳ１６０１において、コンテンツデータ５１６の取得依頼がなかったと判定された場合には、ステップＳ１６０７に進む。そして、ＤＢブローカープログラム５０５は、ＶＤＰアプリケーションプログラム５０４から、キャッシュＩＤの取得依頼があったか否かを判定する。この判定の結果、キャッシュＩＤの生成依頼がなかった場合には、処理を終了する。一方、キャッシュＩＤの生成依頼があった場合には、前述したステップＳ１６０５に進む。ただし、ステップＳ１６０７からステップＳ１６０５に進んだ場合には、ＤＢブローカープログラム５０５は、キャッシュＩＤ５２３を受け取る。したがって、ＤＢブローカープログラム５０５は、キャッシュＩＤ５２３をＲＡＭ２０２に用意した変数cacheIdに夫々格納する。その後、ＤＢブローカープログラム５０５は、ステップＳ１６０６でサムネイルデータ７０９を生成し、変数dataの値と変数cacheIdの値とを戻り値として、ＶＤＰアプリケーションプログラム５０４に返す。
＜キャッシュマネージャプログラム５０９の動作＞
次に、図１７のフローチャートを参照して、ステップＳ１６０５で、キャッシュＩＤ５２３の取得依頼があった場合のキャッシュマネージャプログラム５０９における動作の一例を説明する。前述したように、キャッシュＩＤ５２３の取得依頼の際には、変数dataに格納したコンテンツデータ５１６の内容が引数として、キャッシュマネージャプログラム５０９に渡される。尚、図１７のフローチャートは、ＭＦＰ制御部（ＣＰＵ）３０１が、例えば外部記憶装置３０５に格納されたプログラムをＲＡＭ３０２に展開して実行することにより実現される。
ステップＳ１７０１において、キャッシュマネージャプログラム５０９は、ＶＤＰプリンタ５０３のＲＡＭ３０２に変数cacheIdを用意する。そして、キャッシュマネージャプログラム５０９は、一意なキャッシュＩＤ５２３を生成して変数cacheIdに格納する。キャッシュマネージャプログラム５０９は、例えば、Microsoft Windows（登録商標）で使用されるGUID（Global Unique Identifier）を使用することによりキャッシュＩＤ５２３を生成できる。
次に、ステップＳ１７０２において、キャッシュマネージャプログラム５０９は、変数cacheIdの値を戻り値としてＤＢブローカープログラム５０５に返す。次のステップＳ１７０３〜Ｓ１７０４の処理は時間がかかる可能性がある。しかしながら、ステップＳ１７０２で、キャッシュＩＤの取得依頼に対する応答を終了するので、依頼側のＤＢブローカープログラム５０５は、ステップＳ１７０３〜Ｓ１７０４の終了を待たずに処理を続けることができる。
次に、ステップＳ１７０３において、キャッシュマネージャプログラム５０９は、ＶＤＰプリンタ５０３のＲＡＭ３０２に、変数contentId、rasterDataを用意する。まず、キャッシュマネージャプログラム５０９は、引数であるコンテンツデータ５１６の内容から一意なコンテンツＩＤ５２３を生成して変数contentIdに格納する。ここでは、引数の値からMD5（Message Digest Algorithm 5）を計算して使用する。次に、キャッシュマネージャプログラム５０９は、ＲＩＰプログラム５０８に対して、ラスタデータ５０７の生成依頼を行う。その後、キャッシュマネージャプログラム５０９は、引数であるコンテンツデータ５１６の内容をＲＩＰ処理することにより生成されたラスタデータ５０７を取得し、変数rasterDataに格納する。このラスタデータ５０７を生成する際のやり取りは、通信経路５２５、５２６を介して行われる。
次に、ステップＳ１７０４において、キャッシュマネージャプログラム５０９は、変数cacheId、変数contentId、引数contentData、変数rasterDataの値を、通信経路５２９を介してキャッシュＤＢ５１０に保存する。図１４に示した例では、領域１４０１〜１０４に、変数cacheId、変数contentId、引数contentData、変数rasterDataが、夫々保存される。
＜処理中のＶＤＰシステムの内部状態＞
次に、図１８〜図２１を参照して、図１５〜図１７のフローチャートを実行している最中のＶＤＰシステムの内部状態の一例について説明する。
図１８は、ステップＳ１５０１、Ｓ１５０２を実行した後にステップＳ１５０３〜Ｓ１５１２のループ実行し、ステップＳ１５０４でＮｏと判定されてループを終了した時点でのＶＤＰシステムの内部状態の一例を示す図である。すなわち、枠管理テーブル１２００に格納されている全ての枠に対して再利用可能オブジェクトに関わる処理を実行した時点でのＶＤＰシステムの内部状態の一例を示す図である。
１９０１は、ＶＤＰアプリケーションプログラム５０４で作成されたＶＤＰ文書のレイアウトを示す。
枠１００２は、図１２の枠管理テーブル１２００の先頭に存在する。したがって、ステップＳ１５０１〜Ｓ１５１２のループでは、この枠１００２に対する処理が最初に実行される。すなわち、枠１００２に対する処理では、変数frameIndexの値として「１」が使用される。
枠１００３〜１００５に対する処理では、変数frameIndexの値として、夫々「２」〜「４」が使用される。
１９０２は、ステップＳ１５１２で設定される配列contentData[]の内容を示す。前述したように、ステップＳ１５０６でコンテンツデータが再利用可能オブジェクトであると判定された場合に、ステップＳ１５０７〜Ｓ１５１２の処理が実行される。したがって、ステップＳ１５０７〜Ｓ１５１２の処理は、図１２のReusableObject列１２０３の値が、「TRUE」の枠に対してのみ実行される。すなわち、図１２に示した例では、枠１００２、１００４に対してのみステップＳ１５０７〜Ｓ１５１２の処理が実行される。
枠１００２に対する処理で使用される変数frameIndexの値は「１」である。１９０９は、枠１００２に対するコンテンツデータ５１６を保持するための配列contentData[1]を示す。contentData[1].fileNameの値は、ステップＳ１５１２において前述した規則に従って「00000001.jpg」となる。枠１００２の枠ルールは、図１２より、「\\Share\img\logo.jpg」という「コンテンツ参照」である。したがって、ステップＳ１５０８の判定はＮｏとなり、ステップＳ１５１１に進む。そして、ステップＳ１５１１において、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）を「TRUE」として、コンテンツデータ５１６の取得依頼が行われる。そうすると、図１６のステップＳ１６０６で「TRUE」に設定された変数isProxyがで戻り値として返され、ステップＳ１５１２でcontentData[1].isProxyに、「TRUE」設定される。
また、ステップＳ１６０５でキャッシュＩＤの取得依頼がなされると、図１７のステップＳ１７０１、Ｓ１７０３、Ｓ１７０４で、夫々キャッシュＩＤ５２３、コンテンツＩＤ、ラスタデータ５０７が生成され、キャッシュＤＢ５１０に保存される。ここでは、キャッシュＩＤ５２３として、「C55AACBD-66EE-4dc6-974A-2BAC781D0D31」というGUID１９１５が生成される。また、コンテンツＩＤとして、図１３に示すコンテンツ「\\Share\img\logo.jpg」から「1bbb0237adef732589b4daca8ce0497e」というMD5値１９１６が生成される。
コンテンツデータは、例えば、図１８に示すような内容のJPEGデータである。このJPEGデータ１９１７は、図１３に示したものと同じである。また、ラスタデータ５０７は、JPEGデータ１９１７をラスタライズ処理したデータとなる。
以上のようなキャッシュＩＤ５２３（GUID１９１５）が、ステップＳ１５１１において、戻り値cacheIdとしてＶＤＰアプリケーションプログラム５０４に返される。そして、ステップＳ１５１２において、そのキャッシュＩＤ５２３（GUID１９１５）が、contentData[1].cacheIdに設定される。
また、ステップＳ１６０６で生成されたサムネイルデータ７０９ａが、戻り値dataとしてＶＤＰアプリケーションプログラム５０４に返される。このサムネイルデータ７０９ａは、ステップＳ１５１２において、contentData[1].fileName（00000001.jpg）１９１１というファイル名で、変数tmpDataが指す一時的なディレクトリに保存される。
枠１００４に対する処理で使用される変数frameIndexの値は「３」である。１９１０は、枠１００４に対するコンテンツデータ５１６を保持するための配列contentData[3]を示す。contentData[3].fileNameの値は、ステップＳ１５１２において前述した規則に従って「00000003.jpg」となる。枠１００４の枠ルールは、図１２より「空」である。したがって、ステップＳ１５０８の判定はＹｅｓとなり、ステップＳ１５０９、Ｓ１５１０に進む。
そして、ステップＳ１５１０で変数isProxyが「TRUE」に設定されることから、ステップＳ１５１２において、contentData[3].isProxyの値が「TRUE」に設定される。また、ステップＳ１５１０でキャッシュＩＤ５２３の生成依頼が行われて、図１６のフローチャートが実行され、更にステップＳ１６０５においてキャッシュＩＤ５２３の取得依頼が行われて図１７のフローチャートが実行される。
そして、ステップＳ１７０１、Ｓ１７０３、Ｓ１７０４で、夫々キャッシュＩＤ５２３、コンテンツＩＤ、ラスタデータ５０７が生成され、キャッシュＤＢ５１０に保存される。ここではキャッシュＩＤ５２３として、「1E3B90CC-A325-4d68-AE61-050C7166E14F」というGUID１９１８が生成される。また、コンテンツＩＤとして、図１０の枠１００４内に示す表示をPostScriptデータに変換したデータから「cce49c2d2d7f16cc0b9180fcaa5af015」というMD5値１９１９が生成される。
コンテンツデータ５１６は、例えば、図１８に示すような内容のPostScriptデータ１９１４である。また、ラスタデータ５０７は、そのPostScriptデータ１９１４をラスタライズ処理したデータとなる。
以上のようなキャッシュＩＤ５２３（GUID１９１８）が戻り値cacheIdとしてＶＤＰアプリケーションプログラム５０４に返される。そして、ステップＳ１５１２において、そのキャッシュＩＤ５２３（GUID１９１８）が、contentData[3].cacheIdに設定される。
また、ステップＳ１６０６で生成されたサムネイルデータ７０９ｂが戻り値dataとしてＶＤＰアプリケーションプログラム５０４に返される。このサムネイルデータ７０９ｂは、ステップＳ７０９ｂにおいて、contentData[3].fileName（00000003.jpg）１９１３というファイル名で、変数tmpDataが指す一時的なディレクトリに保存される。
図１９は、ステップＳ１５１３を実行した後に、ステップＳ１５１４〜Ｓ１５２７を１回実行した（ジョブの１ページ目の処理が完了した）時点でのＶＤＰシステムの内部状態の一例を示す図である。この場合、変数recordNoの値として「１」が使用される。
２０１０、２０１２は、ステップＳ１５２７で設定される配列contentData[]の内容を示す。前述したように、ステップＳ１５２０でコンテンツデータが再利用可能オブジェクトでないと判定された場合に、ステップＳ１５２１〜Ｓ１５２７の処理が実行される。したがって、ステップＳ１５２１〜Ｓ１５２７の処理は、図１２のReusableObject列１２０３の値が、「FALSE」の枠に対してのみ実行される。すなわち、図１２に示した例では、枠１００３、１００５に対してのみステップＳ１５２１〜Ｓ１５２７の処理が実行される。
枠１００３に対する処理で使用されるframeIndexの値は「２」である。２０１０は、枠１００３に対するコンテンツデータ５１６を保持するための配列contetnData[2]を示す。contentData[2].fileNameの値は、ステップＳ１５２７において前述した規則に従って「00010002.jpg」となる。枠１００３の枠ルールは、図１２より以下のようになる。
"〒" $ZipCode
$Address
$LastName $FirstName "様"
このように、枠１００３の枠ルールには「データソース参照」が含まれる。したがって、ステップＳ１５２１において、図１１のレコード情報のうち、レコード番号が「１」（recordNo＝１）であるレコード情報が取得される。そして、ステップＳ１５２２において、そのレコード情報が枠ルールに適用され、以下の「リテラル文字列」が導出される。
〒111-2222
東京都千代田区丸の内○−○−○
山田 太郎 様
このようにレコード情報が枠ルールに適用され、「リテラル文字列」が導出されると、ステップＳ１５２３の判定は、Ｙｅｓとなり、ステップＳ１５２４、Ｓ１５２５に進む。そして、ステップＳ１５２５において変数isProxyが「TRUE」に設定されることから、ステップＳ１５２７において、contentData[2].isProxyの値が「TRUE」に設定される。
また、ステップＳ１６０５でキャッシュＩＤ５２３の取得依頼がなされると、図１７のステップＳ１７０１、Ｓ１７０３、Ｓ１７０４で、夫々キャッシュＩＤ５２３、コンテンツＩＤ、ラスタデータ５０７が生成され、キャッシュＤＢ５１０に保存される。ここでは、キャッシュＩＤ５２３として、「D8BB50FE-44E7-41ea-A658-99E77AF3235A」というGUID２０２７が生成される。また、前述したリテラル文字列は、ステップＳ１５２４でPostScriptデータに変換される。そして、このPostScriptデータから「f2950230fffc3d5d346f84135d149a67」というMD5値２０２８がコンテンツＩＤとして生成される。
コンテンツデータは、例えば、図１９示すような内容のPostScriptデータ２０２９である。また、ラスタデータ５０７は、PostScriptデータ２０２９をラスタライズ処理したデータとなる。
以上のようなキャッシュＩＤ５２３（GUID２０２７）が、ステップＳ１５２５において、戻り値cacheIdとしてＶＤＰアプリケーションプログラム５０４に返される。そして、ステップＳ１５２７において、そのキャッシュＩＤ５２３（GUID２０２７）が、contentData[2].cacheIdに設定される。
また、ステップＳ１６０６で生成されたサムネイルデータ７０９ｃが、戻り値dataとしてＶＤＰアプリケーションプログラム５０４に返される。このサムネイルデータ７０９ｃ８は、ステップＳ１５２７において、contentData[2].fileName（00010002.jpg）２０２７というファイル名で、変数tmpDataが指す一時的なディレクトリに保存される。
枠１００５に対する処理で使用される変数frameIndexの値は「４」である。２０１２は、枠１００５に対するコンテンツデータ５１６を保持するための配列contentData[4]を示す。contentData[4].fileNameの値は、ステップＳ１５２７において前述した規則に従って「00010004.jpg」となる。枠１００５の枠ルールは、図１２より以下のようになる。
if $Gender="M"
\\Share\img\car.jpg
else
\\Share\img\bag.jpg
このように、枠１００５の枠ルールには「データソース参照」が含まれる。したがって、ステップ１５２１において、図１１のレコード情報のうち、レコード番号が「１」（recordNo＝１）であるレコード情報が取得される。そして、ステップＳ１５２２において、そのレコード情報が枠ルールに適用され、以下の「コンテンツ参照」が導出される。
\\Share\img\car.jpg
「コンテンツ参照」が導出されると、ステップＳ１５２３では、Ｎｏと判定され、ステップＳ１５２６に進む。そして、ステップＳ１５２６において、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）を「FALSE」とし、キャッシュするか否かを判定する際のスレッショルド値（第３の引数）を「200KB」とする。そして、これら第２及び第３の引数を用いて、コンテンツデータ５１６の取得依頼が行われる。そうすると、図１６の処理が実行される。
常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）は「FALSE」であるので、ステップＳ１６０３ではＮｏと判定され、ステップＳ１６０４に進む。
ここで、「コンテンツ参照」で示される「\\Share\img\car.jpg」のサイズは、図１３に示したように「300KB」である。したがって、ステップＳ１６０４では、Ｙｅｓと判定され、ステップＳ１６０５の処理に進む。このステップＳ１６０５では、変数isProxyに「TRUE」が設定され、この「TRUE」が設定された変数isProxyが、ステップＳ１５２６において戻り値としてＶＤＰアプリケーションプログラム５０４に返される。そして、その戻り値が、ステップＳ１５２７においてcontentData[4].isProxyに設定される。
また、ステップＳ１６０５でキャッシュＩＤの取得依頼がなされると、図１７のステップＳ１７０１、Ｓ１７０３、Ｓ１７０４で、夫々キャッシュＩＤ５２３、コンテンツＩＤ、ラスタデータ５０７が生成され、キャッシュＤＢ５１０に保存される。ここでは、キャッシュＩＤ５２３として「3688C04A-32B6-45eb-B189-ADCED3B9310B」というGUID２０３０が生成される。また、コンテンツＩＤとして、「コンテンツ参照」で示される「\\Share\img\car.jpg」から「cce49c2d2d7f16cc0b9180fcaa5af015」というMD5値２０３１が生成される。
コンテンツデータは、例えば、図１９に示すような内容のJPEGデータ２０３２である。このJPEGデータ２０３２は、図１３に示したものと同じである。また、ラスタデータ５０７は、JPEGデータ２０３２をラスタライズ処理したデータとなる。
以上のようなキャッシュＩＤ５２３（GUID２０３０）が、ステップＳ１５２６において、戻り値cacheIdとしてＶＤＰアプリケーションプログラム５０４に返される。そして、ステップＳ１５２７において、そのキャッシュＩＤ５２３（GUID２０３０）が、contentData[4].cacheIdに設定される。
また、ステップＳ１６０６で生成されたサムネイルデータ７０９ｄが、戻り値dataとしてＶＤＰアプリケーションプログラム５０４に返される。このサムネイルデータ７０９ｄは、ステップＳ１５２７において、contentData[4].fileName（00010004.jpg）２０１９というファイル名で、変数tmpDataが指す一時的なディレクトリに保存される。
図２０は、ステップＳ１５１４〜Ｓ１５２７を２回実行した（ジョブの２ページ目の処理が完了した）時点でのＶＤＰシステムの内部状態の一例を示す図である。この場合、変数recordNoの値として「２」が使用される。
枠１００３に対する処理は、図１９を用いて説明した処理と略同様であるが、ステップＳ１５２１で取得されるレコード情報が、図１９を用いて説明したレコード情報と異なる。すなわち、ここでは、図１１のレコード情報のうち、レコード番号が「２」（recordNo＝２）であるレコード情報が取得される。尚、２１１０は、枠１００３に対するコンテンツデータ５１６を保持するための配列contentData[2]を示す。また、７０９ｅは、コンテンツデータ５１６のサムネイルデータ７０９であり、２１２１は、そのサムネイルデータ７０９ｅのファイル名である。また、２１３７は、キャッシュＩＤ５２３として生成されるGUIDである。２１３８は、コンテンツＩＤとして生成されるMD5値である。２１３９は、コンテンツデータとして生成されるPostScriptデータである。
枠１００５に対する処理は、図１９を用いて説明した処理処理と似ているが、いくつの点が異なるので、以下詳細に説明する。
枠１００５に対する処理で使用される変数frameIndexの値は「４」である。２１１２は、枠１００５に対するコンテンツデータ５１６を保持するための配列contentData[4]を示す。contentData[4].fileNameの値は、ステップＳ１５２７において前述した規則に従って「00020004.jpg」となる。枠１００５の枠ルールは、図１２より以下のようになる。
if $Gender="M"
\\Share\img\car.jpg
else
\\Share\img\bag.jpg
このように、枠１００５の枠ルールには「データソース参照」が含まれる。したがって、ステップ１５２１において、図１１のレコード情報のうち、レコード番号が「２」（recordNo＝２）であるレコード情報が取得される。そして、ステップＳ１５２２において、そのレコード情報が枠ルールに適用され、以下の「コンテンツ参照」が導出される。
\\Share\img\bag.jpg
「コンテンツ参照」が導出されると、ステップＳ１５２３では、Ｎｏと判定され、ステップＳ１５２６に進む。そして、ステップＳ１５２６において、常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）を「FALSE」とし、キャッシュするか否かを判定する際のスレッショルド値（第３の引数）を「200KB」とする。そして、これら第２及び第３の引数を用いて、コンテンツデータ５１６の取得依頼が行われる。そうすると、図１６の処理が実行される。
常にキャッシュを行うか否かを識別するためのフラグ（第２の引数）は「FALSE」であるので、ステップＳ１６０３ではＮｏと判定され、ステップＳ１６０４に進む。
ここで、「コンテンツ参照」で示される「\\Share\img\bag.jpg」のサイズは、図１３に示したように「100KB」である。したがって、ステップＳ１６０４では、Ｎｏと判定され、図１６のフローチャート（コンテンツデータ取得処理）が終了する。ここで、戻り値data、isProxy、cacheIdの値は、ステップＳ１６０２で設定された値となり、夫々「\\Share\img\bag.jpg」の内容、「FALSE」、「N/A（値なし）」となる。そして、これらの戻り値data、isProxy、cacheIdの値が、ＶＤＰアプリケーションプログラム５０４に返される。
そして、ステップＳ１５２７において、戻り値dataに含まれる「\\Share\img\bag.jpg」のコンテンツデータが、変数tmpDataが指す一時的なディレクトリに保存される。２１２４は、このコンテンツデータを示す。ここで、コンテンツデータ２１２４は、contentData[4].fileName（00020004.jpg）２１２３というファイル名で保存される。このように、ここで保存されるのはサムネイルデータではなく、オリジナルのコンテンツデータである。また、戻り値cacheId、isProxyは、ステップＳ１５２７において、夫々contentData[4].cacheId、contentData[4].isProxyに設定される。
図２１は、ステップＳ１５１４〜Ｓ１５２７を３回実行し、ステップＳ１５１８でＮｏと判定された（ジョブの３ページ目（全ページ）の処理が完了した）時点でのＶＤＰシステムの内部状態の一例を示す図である。この場合、変数recordNoの値として「３」が使用される。
枠１００３に対する処理は、図１９及び図２０を用いて説明した処理と略同様であるが、ステップＳ１５２１で取得されるレコード情報が、図１９及び図２０を用いて説明したレコード情報と異なる。すなわち、ここでは、図１１のレコード情報のうち、レコード番号が「３」（recordNo＝3）であるレコード情報が取得される。尚、２２１０は、枠１００３に対するコンテンツデータ５１６を保持するための配列contentData[2]を示す。また、７０９ｆは、コンテンツデータ５１６のサムネイルデータであり、２２２５は、そのサムネイルデータ７０９ｆのファイル名である。また、２２４４は、そのコンテンツデータ５１６に対するキャッシュＩＤであり、２２４５は、そのコンテンツデータ５１６のコンテンツＩＤであり、２２４６は、そのコンテンツデータ５１６の内容である。
枠１００５に対する処理も、図１９及び図２０を用いて説明した処理と略同様であるが、ステップＳ１５２１で取得されるレコード情報が、図１９及び図２０を用いて説明したレコード情報と異なる。すなわち、ここでは、図１１のレコード情報のうち、レコード番号が「３」（recordNo＝3）であるレコード情報が取得される。また、「コンテンツ参照」に示される「\\Share\img\car.jpg」に対するキャッシュＩＤ、コンテンツＩＤ、コンテンツデータ、及びラスタデータは、キャッシュＤＢ５１０に既に存在している。すなわち、キャッシュＤＢ５１０には、「\\Share\img\car.jpg」に対するキャッシュＩＤ２０３０、コンテンツＩＤ２０３１、コンテンツデータ／ラスタデータ２０３２が既に存在している。したがって、「コンテンツ参照」に示される「\\Share\img\car.jpg」に対するキャッシュＩＤ、コンテンツＩＤ、コンテンツデータ、及びラスタデータは、新たに作成されない。
＜生成されるPPMLファイル＞
図２２は、図１５−２のステップＳ１５２８で生成されるPPMLデータファイル７０２の一例を示す図である。尚、図２２の左側にある３桁の数字は説明用に付加した行番号であるので、実際のPPMLデータファイル７０２の記述には含まれない。
前述したように、図１１に示したCUSTOMERテーブル１１００には、レコード情報が３つ含まれている。したがって、図１１に示したCUSTOMERテーブル１１００の例では、ステップS１５２８８は３回実行される。
ステップＳ１５２８を１回実行したときのＶＤＰシステムの内部状態は、図１９に示す状態である。１回目のステップＳ１５２８で行番号００１〜０４１（１行目〜４１行目）を作成する。ステップＳ１５２８を２回実行したときのＶＤＰシステムの内部状態は、図２０に示す状態である。２回目のステップＳ１５２８で行番号０４２〜０６０（４２行目〜６０行目）を作成する。ステップＳ１５２８を３回実行したときのＶＤＰシステムの内部状態は、図２１に示す状態である。３回目のステップＳ１５２８で行番号０６１〜０７９（６１行目〜７９行目）を作成する。また、行番号０８０〜０８２（８０行目〜８２行目）は、ステップＳ１５２９でＶＤＰジョブファイル５１８が作成される直前に追加される。
行番号００１（１行目）には、ＸＭＬ宣言（XML Declaration）が記述されている。ここでは、PPMLデータファイル７０２がXML 1.0仕様にしたがって記述されていることを示す。
行番号００２（２行目）には、ルート要素としての「<PPML>要素」の開始タグが記述されている。ここでは、PPML2.1仕様に従い、標準のXML名前空間として「urn://www.podi.org/ppml/ppml2」を指定している。また、本実施形態で使用される拡張記述用のXML名前空間として"ext"という接頭辞と「http://xxx.invalid/ppml2-ext」という名前空間ＵＲＩとを指定している。ここで「http://xxx.invalid/ppml2-ext」は例示のためのもので、実在のＵＲＩではない。
行番号００３（３行目）には、ジョブを示すための「<JOB>要素」の開始タグが記述されている。行番号００４（４行目）には、文書を示すための「<DOCUMENT>要素」の開始タグが記述されている。PPMLデータファイル７０２には、ジョブと文書とを夫々複数格納することが可能だが、図２２に示す例では、どちらも１つずつ格納するものとする。
行番号００５〜０１４（５〜１４行目）には、「枠１００２に対するコンテンツデータ５１６を保持するための配列contentData[1]１９０９（図１８を参照）」に対応するオブジェクトを参照するための再利用可能オブジェクトが定義されている。
行番号００５（５行目）には、再利用可能オブジェクトの定義を開始するための「<REUSABLE＿OBJECT>要素」の開始タグが記述されている。
行番号００６（６行目）には、参照される再利用オブジェクトを定義するための「<OBJECT>要素」の開始タグである。属性のPositionは、再利用可能オブジェクトが参照されたときの描画位置からのオフセットを表わす。オフセットは、1/72インチ単位で行われる。
行番号００７〜００９（７〜９行目）には、再利用可能オブジェクトとなるコンテンツデータの位置を指定するための「<SOURCE>要素」及び「<EXTERNAL＿DATA>要素」が記述されている。「<SOURCE>要素」のFormat属性は、このコンテンツデータのフォーマットを指定するものである。「<SOURCE>要素」のDimension属性は、このコンテンツデータが参照されるときの描画サイズを表わす。
「<EXTERNAL＿DATA>要素」のSrc属性は、コンテンツデータの格納場所を指定するものである。ここでは、「<EXTERNAL＿DATA>要素」のSrc属性として、配列contentData[1]１９０９に示す「contentData[1].fileName」の内容が記述されている。「<EXTERNAL＿DATA>要素」のisProxy属性は、プロキシデータ５１３か否かを指定するためのものである。ここでは、「<EXTERNAL＿DATA>要素」のisProxy属性として、配列contentData[1]１９０９に示す「contentData[1].isProxy」の内容が記述されている。「<EXTERNAL＿DATA>要素」のcacheId属性は、キャッシュＩＤ５２３を指定するためのものである。ここでは、配列contentData[1]１９０９に示す「contentData[1].cacheId」の内容が記述されている。「<EXTERNAL＿DATA>要素」のisProxy属性及びcacheId属性は、本実施形態により拡張された仕様である。このため、「<EXTERNAL＿DATA>要素」のisProxy属性及びcacheId属性として、ext接頭辞で別の名前空間が指定される。
行番号０１０（１０行目）には、「<OBJECT>要素」の終了タグが記述されている。この終了タグは、行番号００６（６行目）に記述されている開始タグに対応している。
行番号０１１〜０１３（１１〜１３行目）には、再利用可能オブジェクトの参照方法を定義するための「<OCCURRENCE＿LIST>要素」及び「<OCCURRENCE>要素」が記述されている。「<OCCURRENCE>要素」のName属性は、再利用可能オブジェクトを参照する場合に指定される名前を定義するためのものである。ここでは、contentData[4].fileName（00010004.jpg）２０１９のうち拡張子を除いた部分を使用して、「<OCCURRENCE>要素」のName属性が記述される。「<OCCURRENCE>要素」のScope属性は、再利用可能オブジェクトを参照する際の有効範囲を指定するためのものであり、ここでは有効範囲が、文書内であることが記述されている。
行番号０１４（１４行目）には、「<REUSABLE＿OBJECT>要素」の終了タグが記述されている。この終了タグは、行番号００５（５行目）に記述されている開始タグに対応している。
行番号０１５〜０２４（１５〜２４行目）には、「枠１００４に対するコンテンツデータ５１６を保持するための配列contentData[3]１９１０（図１８を参照）」に対応するオブジェクトを参照するための再利用可能オブジェクトが定義されている。行番号０１５〜０２４（１５〜２４行目）の記述方法は、行番号００５〜０１４（５〜１４行目）と同様である。
行番号０２５〜０４３（２５〜４３行目）には、１ページ目を印刷出力するためのページの定義がなされる。
行番号０２５（２５行目）には、コメントが記述されている。
行番号０２６（２６行目）には、ページの定義を開始するための「<PAGE>要素」の開始タグが記述されている。
行番号０２７〜０２９（２７〜２９行目）には、枠１００２を描画するための「<MARK>要素」及び「<OCCURRENCE＿REF>要素」が記述されている。「<MARK>要素」のPosition属性で、枠１００２の左下座標が指定される。図１９に示すように、枠１００２に対応するオブジェクトは、配列contentData[1]１９０９で特定されるものであり、このオブジェクトは再利用可能オブジェクトである。したがって、「<OCCURRENCE＿REF>要素」のRef属性で、行番号００５〜０１４（５〜１４行目）で定義された再利用可能オブジェクトを参照する記述がなされている。
行番号０３０〜０３４（３０〜３４行目）には、枠１００３を描画するための「<OBJECT>要素」、「<SOURCE>要素」、及び「<EXTERNAL＿DATA>要素」が記述されている。「<OBJECT>要素」のPosition属性で、枠１００３の左下座標が指定される。図１９に示すように、枠１００３に対応するオブジェクトは、配列contentData[2]２０１０であり、このオブジェクトは再利用可能オブジェクトではない。したがって、「<SOURCE>要素」及び「<EXTERNAL＿DATA>要素」を使ってコンテンツデータが直接指定される。「<SOURCE>要素」のFormat属性には、このコンテンツデータのフォーマットが指定され、「<SOURCE>要素」のDimension属性には、このコンテンツデータが参照されるときの描画サイズが記述されている。
「<EXTERNAL＿DATA>要素」のSrc属性は、コンテンツデータの格納場所を指定するためのものである。ここでは、contentData[2].fileNameの内容である「00010002.jpg」２０１７が記述されている。「<EXTERNAL＿DATA>要素」のisProxy属性は、プロキシデータか否かを指定するためのものである。ここでは、contentData[2].isProxyの内容である「TRUE」が記述されている。「<EXTERNAL＿DATA>要素」のcacheId属性は、キャッシュＩＤを指定するためのものである。ここでは、contentData[2].cacheIdの内容が記述されている。「<EXTERNAL＿DATA>要素」のisProxy属性及びcacheId属性は、本実施形態により拡張された仕様である。このため、「<EXTERNAL＿DATA>要素」のisProxy属性及びcacheId属性として、ext接頭辞で別の名前空間が指定されている。
行番号０３５〜０３７（３５〜３７行目）には、枠１００４を描画するための「<MARK>要素及び「<OCCURRENCE＿REF>要素」が記述されている。「<MARK>要素」のPosition属性で、枠１００４の左下座標が指定される。図１９に示すように、枠１００４に対応するオブジェクトは、配列contentData[3]１９１０で特定されるものであり、このオブジェクトは再利用可能オブジェクトである。したがって、「<OCCURRENCE＿REF>要素」のRef属性で、行番号０１５〜０２４（１５〜２４行目）で定義された再利用可能オブジェクトを参照する記述がなされている。
行番号０３８〜０４２（３８〜４２行目）には、枠１００５を描画するための「<OBJECT>要素」、「<SOURCE>要素」、及び「<EXTERNAL＿DATA>要素」が記述されている。「<OBJECT>要素」のPosition属性で、枠１００５の左下座標が指定される。図１９に示すように、枠１００５に対応するオブジェクトは、配列contentData[4]２０１２であり、このオブジェクトは再利用可能オブジェクトではない。したがって、「<SOURCE>要素及び「<EXTERNAL＿DATA>要素」を使ってコンテンツデータが直接指定される。「<SOURCE>要素」のFormat属性には、このコンテンツデータのフォーマットが指定され、「<SOURCE>要素」のDimension属性には、このコンテンツデータが参照されるときの描画サイズが記述されている。
「<EXTERNAL＿DATA>要素」のSrc属性は、コンテンツデータの格納場所を指定するためのものである。ここでは、contentData[4].fileNameの内容である「00010004.jpg」が記述されている。「<EXTERNAL＿DATA>要素」のisProxy属性は、プロキシデータか否かを指定するためのものである。ここでは、contentData[4].isProxyの内容である「TRUE」が記述されている。「<EXTERNAL＿DATA>要素」のcacheId属性は、キャッシュＩＤを指定するためのものである。ここでは、contentData[4].cacheIdの内容が記述されている。「<EXTERNAL＿DATA>要素」のisProxy属性及びcacheId属性は、本実施形態により拡張された仕様である。このため、「<EXTERNAL＿DATA>要素」のisProxy属性及びcacheId属性として、ext接頭辞で別の名前空間が指定されている。
行番号０４３（４３行目）には、「<PAGE>要素」の終了タグが記述されている。この終了タグは、行番号０２６（２６行目）に記述されている開始タグに対応している。
行番号０４４〜０６２（４４〜６２行目）には、２ページ目を印刷出力するためのページの定義がなされる。図２０に示したＶＤＰシステムの内部状態を参照して記述される点を除いては、行番号０２５〜０４３（２５〜４３行目）の１ページ目の定義と同様にして記述される。枠１００５に対するコンテンツデータ５１６を保持するための配列contentData[4]２１１２の内容に従って、行番号０５９（５９行目）の「<EXTERNAL＿DATA>要素」のisProxy拡張属性として「FALSE」が記述されている。
行番号０６３〜０８１（６３〜８１行目）には、３ページ目を印刷出力するためのページの定義がなされている。図２１に示したＶＤＰシステムの内部状態を参照して記述される点を除いては、行番号０２５〜０４３（２５〜４３行目）の１ページ目の定義と同様にして記述される。
行番号０８２（８２行目）には、「<DOCUMENT>要素」の終了タグが記述されている。この終了タグは、行番号００４（４行目）に記述されている開始タグに対応している。
行番号０８３（８３行目）には、「<JOB>要素」の終了タグが記述されている。この終了タグは、行番号００３（３行目）に記述されている開始タグに対応している。
行番号０８４（８４行目）には、ルート要素としての「<PPML>要素」の終了タグが記述されている。この終了タグは、行番号００２（２行目）に記述されている開始タグに対応している。
＜ＲＩＰ動作＞
次に、図２３のフローチャートを参照しながら、図１５−２のステップＳ１５２９でＶＤＰジョブファイル５１８が送信された場合のＲＩＰプログラム５０８における動作の一例を説明する。ＶＤＰジョブファイル５１８には、図２１の配列contentData[1]〜[4]１９０９、１９１０、２２１０、２２１２（一時的なディレクトリtemDir）内の全てのファイル）と、図２２に示したPPMLデータファイル７０２とが含まれる。ＶＤＰジョブファイル５１８が送信されたときのキャッシュＤＢ５１０の内容は、図２１に示した通りである。尚、図２３のフローチャートは、ＭＦＰ制御部（ＣＰＵ）３０１が、例えば外部記憶装置３０５に格納されたプログラムをＲＡＭ３０２に展開して実行することにより実現される。
ステップＳ１８０１〜Ｓ１８０４は、再利用可能オブジェクトの定義を処理するためのループ処理である。
まず、ステップＳ１８０１において、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の再利用可能オブジェクトの定義に対する処理が全て終了したか否かを判定する。この判定の結果、PPMLデータファイル７０２中の再利用可能オブジェクトの定義に対する処理が全て終了した場合には、後述するステップＳ１８０６に進む。一方、PPMLデータファイル７０２中の再利用可能オブジェクトの定義に対する処理が全て終了していなければステップＳ１８０２に進む。
ステップＳ１８０２において、ＲＩＰプログラム５０８は、処理対象とすべき再利用可能オブジェクトの定義を１つ取得する。具体的にＲＩＰプログラム５０８は、PPMLデータファイル７０２中の再利用可能オブジェクトの定義をＲＡＭ３０２に書き込む。
次に、ステップＳ１８０３において、ＲＩＰプログラム５０８は、ステップＳ１８０２で取得した再利用可能オブジェクトに対応するプロキシデータ５１３がＶＤＰジョブファイル５１８に含まれているか否かを判定する。具体的にＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<EXTERNAL＿DATA>要素」の「<isProxy>拡張属性」の値が「TRUE」であれば、プロキシデータ５１３があると判定する。この判定の結果、ＶＤＰジョブファイル５１８にプロキシデータ５１３が含まれている場合には、ステップＳ１８０４に進む。一方、ＶＤＰジョブファイル５１８にプロキシデータ５１３が含まれていない場合には、ステップＳ１８０５に進む。図２２に示したPPMLデータファイル７０２の例では、行番号００５〜０１４（５〜１４行目）の再利用可能オブジェクトの定義において、「<EXTERNAL＿DATA>要素」の「<isProxy>拡張属性」の値は「TRUE」である。更に、行番号０１５〜０２４（１５〜２４行目）の再利用可能オブジェクトの定義においても、「<EXTERNAL＿DATA>要素」の「<isProxy>拡張属性」の値は「TRUE」である。
ステップＳ１８０４に進んだ場合、再利用可能オブジェクトのコンテンツデータ５１６及びラスタデータ５０７は、既にキャッシュＤＢ５１０に格納されているはずである。したがって、ＲＩＰプログラム５０８は、そのラスタデータ５０７を取得する。具体的にＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<EXTERNAL＿DATA>要素」の「<cacheId 拡張属性」の値をキーとして、ラスタデータ５０７の取得をキャッシュマネージャ５０９に依頼する。キャッシュマネージャ５０９は、該当するラスタデータ５０７をキャッシュＤＢ５１０から読み出し、ＲＩＰプログラム５０８に送信する。このステップＳ１８０４の処理では、通信経路５２５、５２９、５３０、５２６が使用される。こうしてラスタデータ５０７を取得すると、ＲＩＰプログラム５０８は、取得したラスタデータ５０７をＲＡＭ３０２に用意した連想配列reusableObject[]に格納する。連想配列のキーは、「<OCCURRENCE>要素」の「Name属性」の値である。
図２２に示したPPMLデータファイル７０２の例では、行番号００５〜０１４（５〜１４行目）の再利用可能オブジェクトの定義において、「cacheId＝"C55AACBD-66EE-4dc6-974A-2BAC781D0D31"」が記述される。したがって、キャッシュＩＤ１９１５が該当するキャッシュＩＤとなる。よって、ＲＩＰプログラム５０８は、コンテンツデータ１９１７に対応するラスタデータを取得する。そして、ＲＩＰプログラム５０８は、「Name＝"00000001"」をキーとして、取得したラスタデータを、連想配列reusableObject[]に格納する。
行番号０１５〜０２４（１５〜２４行目）の再利用可能オブジェクトの定義において、「cacheId＝"1E3B90CC-A325-4d68-AE61-050C7166E14F"」が記述されている。したがって、キャッシュＩＤ１９１８が該当するキャッシュＩＤとなる。よって、ＲＩＰプログラム５０８は、コンテンツデータ１９２０に対応するラスタデータを取得する。そして、ＲＩＰプログラム５０８は、「Name="00000003"」をキーとして、取得したラスタデータを、連想配列reusableObject[]に格納する。そして、ステップＳ１８０１に戻る。
一方、ステップＳ１８０５に進んだ場合には、再利用可能オブジェクトのコンテンツデータ５１６は、キャッシュＤＢ５１０に格納されていない。したがって、ＲＩＰプログラム５０８は、ＶＤＰジョブファイル５１８からコンテンツデータ５１６を取得して、ラスタライズすることでラスタデータ５０７を生成する。そして、ＲＩＰプログラム５０８は、生成したラスタデータ５０７をＲＡＭ３０２に用意した連想配列reusableObject[]に格納する。連想配列のキーは、「<OCCURRENCE>要素」のName属性の値である。そして、ステップＳ１８０１に戻る。
前記ステップＳ１８０１において、PPMLデータファイル７０２中の再利用可能オブジェクトの定義に対する処理が全て終了した場合には、ステップＳ１８０６に進む。そして、ＲＩＰプログラム５０８は、１ページ分の印刷データをプリンタエンジンに送るための印刷データ用メモリpageDataをＲＡＭ３０２に用意する。
ステップＳ１８０７〜Ｓ１８１７は、二重ループ処理になっている。外側のループであるステップＳ１８０７〜Ｓ１８１７は、各ページを印刷するための処理であり、ステップＳ１８０７で、その外側のループの終了判定を行う。内側のループであるステップＳ１８０９〜Ｓ１８１６は、ページ内の各オブジェクトを、印刷データ用メモリpageDataに描画するための処理であり、ステップＳ１８０８で、その内側のループの終了判定を行う。
ステップＳ１８０７において、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の全ての「<PAGE>要素」の処理が終わったか否かを判定する。具体的にＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<DOCUMENT>要素」の終了タグである</DOCUMENT>が見つかったら、全ての「<PAGE>要素」の処理が終了したと判定する。この判定の結果、全ての「<PAGE>要素」の処理が終了した場合には、処理を終了する。一方、全ての「<PAGE>要素」の処理が終了していない場合には、ステップＳ１８０８に進む。
ステップＳ１８０８において、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の全ての「<PAGE>要素」内の全てのオブジェクトに対する処理が終了したか否かを判定する。具体的に、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<PAGE>要素」の終了タグである</PAGE>が見つかったら、全てのオブジェクトの処理が終了したと判定する。この判定の結果、全ての「<PAGE>要素」内の全てのオブジェクトに対する処理が終了した場合には、後述するステップＳ１８１６に進む。一方、全ての「<PAGE>要素」内の全てのオブジェクトに対する処理が終了した場合には、ステップＳ１８０９に進む。
ステップＳ１８０９において、ＲＩＰプログラム５０８は、処理対象であるオブジェクトを取得する。具体的にＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<PAGE>要素」内の次のオブジェクトをＲＡＭ３０２に書き込む。
次に、ステップＳ１８１０において、ＲＩＰプログラム５０８は、ステップＳ１８０９で書き込んだオブジェクトが、再利用可能オブジェクトか否かを判定する。具体的にＲＩＰプログラム５０８は、ステップＳ１８０９で書き込んだオブジェクトが「<MARK>要素」であれば、そのオブジェクトは、再利用可能オブジェクトであると判定して、後述するステップＳ１８１５に進む。一方、ステップＳ１８０９で書き込んだオブジェクトが「<MARK>要素」でなければ、ステップＳ１８１１に進む。図２２に示したPPMLデータファイル７０２の例では、各ページとも１つ目のオブジェクトと３つ目のオブジェクトが再利用可能オブジェクトであると判定される。
ステップＳ１８１１において、ＲＩＰプログラム５０８は、ステップＳ１８０８で取得したオブジェクトに対応するプロキシデータ５１３がＶＤＰジョブファイル５１４に含まれているか否かを判定する。具体的にＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<EXTERNAL＿DATA>要素」の「<isProxy>拡張属性」の値が「TRUE」であれば、プロキシデータ５１３があると判定する。この判定の結果、ＶＤＰジョブファイル５１８にプロキシデータ５１３が含まれている場合には、ステップＳ１８１２に進む。一方、ＶＤＰジョブファイル５１８にプロキシデータ５１３が含まれていない場合には、後述するステップＳ１８１４に進む。
図２２に示したPPMLデータファイル７０２の例では、行番号００５〜０１４（５〜１４行目）の再利用可能オブジェクトの定義において、「<EXTERNAL＿DATA>要素」の「<isProxy>拡張属性」の値は「TRUE」である。また、行番号０１５〜０２４（１５〜２４行目）の再利用可能オブジェクトの定義でも、「<EXTERNAL＿DATA>要素」の「<isProxy>拡張属性」の値は「TRUE」である。図２２に示したPPMLデータファイル７０２では、１ページ目を処理しているときは、２つ目のオブジェクト（３０〜３４行目）も４つ目のオブジェクト（３８〜４２行目）もプロキシデータ５１３であると判定される。また、２ページ目を処理しているときは、２つ目のオブジェクト（４９行〜５３行目）は、プロキシデータ５１３であると判定されるが、４つ目のオブジェクト（５７〜６１行目）は、プロキシデータ５１３ではないと判定される。また、３ページ目を処理しているときは、２つ目のオブジェクト（６８〜７２行目）も、４つ目のオブジェクト（７６〜８０行目）もプロキシデータ５１３であると判定される。
ステップＳ１８１２に進むと、ステップＳ１８０９でＲＡＭ３０２に書き込んだオブジェクトのコンテンツデータ５１６及びラスタデータ５０７が既にキャッシュＤＢ５１０に格納されている。したがって、ステップＳ１８１２において、ＲＩＰプログラム５０８は、そのラスタデータ５０７を取得する。具体的にＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<EXTERNAL＿DATA>要素」の「<cacheId>拡張属性」の値をキーとして、ラスタデータ５０７の取得をキャッシュマネージャ５０９に依頼する。キャッシュマネージャ５０９は、該当するラスタデータ５０７をキャッシュＤＢ５１０から読み出し、ＲＩＰプログラム５０８に送信する。このステップＳ１８１２の処理では、通信経路５２５、５２９、５３０、５２６が使用される。こうしてラスタデータ５０７を取得すると、ＲＩＰプログラム５０８は、取得したラスタデータ５０７をＲＡＭ３０２に用意した変数dataに格納する。連想配列のキーは、「<OCCURRENCE>要素」の「Name属性」の値である。また、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<OBJECT>要素」の「Position属性」の値を、ＲＡＭ３０２に用意した変数positionに格納する。
図２２に示したPPMLデータファイル７０２の場合、行番号０３０〜０３４（３０〜３４行目）では、「<EXTERNAL＿DATA>要素」の「<cacheId>拡張属性」の値として、「D8BB50FE-44E7-41ea-A658-99E77AF3235A」が記述されている。したがって、キャッシュＩＤ２０２７が該当するキャッシュＩＤとなる。よって、ＲＩＰプログラム５０８は、コンテンツデータ２０２９に対応するラスタデータを取得し、変数dataに格納する。
次に、ステップＳ１８１３において、ＲＩＰプログラム５０８は、変数dataに格納したラスタデータを印刷データ用メモリpageDataの座標positionの位置に上書きコピーする。そして、ステップＳ１８０８に戻る。
前記ステップＳ１８１１において、ステップＳ１８０８で取得したオブジェクトに対応するプロキシデータ５１３がＶＤＰジョブファイル５１４に含まれていないと判定された場合には、ステップＳ１８１４に進む。ステップＳ１８１４に進んだ場合、ステップＳ１８０９で書き込んだオブジェクトのコンテンツデータ５１６が、キャッシュＤＢ５１０に格納されていない。したがって、ステップＳ１８１４において、ＲＩＰプログラム５０８は、ＶＤＰジョブファイル５１８からコンテンツデータ５１６を取得してラスタライズ処理を実行することでラスタデータ５０７を生成する。そして、ＲＩＰプログラム５０８は、生成したラスタデータ５０７を、ＲＡＭ３０２に用意した変数dataに格納する。また、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<OBJECT>要素」の「Position属性」の値を、ＲＡＭ３０２に用意した変数positionに格納する。そして、前述したステップＳ１８１３に進む。
図２２に示したPPMLデータファイル７０２の場合、行番号０５７〜０６１（５７〜６１行目）においては、「<EXTERNAL＿DATA>要素」の「Src属性」の値として"00020004.jpg"が記述されている。したがって、キャッシュＩＤ２０３０が該当するキャッシュＩＤとなる。よって、ＲＩＰプログラム５０８は、ＶＤＰジョブファイル５１８からコンテンツデータ５１６を取得してラスタライズ処理を実行することでラスタデータ５０７を生成する。
前記ステップＳ１８１０において、ステップＳ１８０９で書き込んだオブジェクトが、再利用可能オブジェクトであると判定された場合には、ステップＳ１８１５に進む。ステップＳ１８１５に進んだ場合、ラスタデータ５０７は既に連想配列reusableObject[]に用意されている。したがって、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<OCCURRENCE＿REF>要素」の「Ref属性」に指定された名前をキーとして連想配列reusableObject[]からラスタデータ５０７を取得する。そして、ＲＩＰプログラム５０８は、取得したラスタデータ５０７をＲＡＭ３０２に用意した変数dataに格納する。また、ＲＩＰプログラム５０８は、PPMLデータファイル７０２中の「<MARK>要素」の「Position属性」の値を、ＲＡＭ３０２に用意した変数positionに格納する。
図２２に示したPPMLデータファイル７０２の場合、ＲＩＰプログラム５０８は、行番号０２７〜０２９（２７〜２９行目）における「<OCCURRENCE＿REF>要素」の「Ref属性」の値"00000001"をキーとして連想配列reusableObject[]にアクセスする。そして、ＲＩＰプログラム５０８は、行番号００５〜０１４（５〜１４行目）で定義された再利用可能オブジェクトに対して、ステップＳ１８０４で用意されたラスタデータ５０７を取得する。
前記ステップＳ１８０８において、、PPMLデータファイル７０２中の全ての「<PAGE>要素」内の全てのオブジェクトに対する処理が終了した場合には、ステップＳ１８１６に進む。そして、ＲＩＰプログラム５０８は、印刷データ用メモリpageDataの内容をプリンタエンジン３０７に送信して印刷処理を行う。
図２４、図２５、及び図２６に、以上のようにして得られた１〜３ページ目の印刷結果の一例を夫々示す。
以上のように本実施形態では、ＶＤＰクライアント１０１は、ＶＤＰジョブファイル５１８を生成する前に、コンテンツデータ５１６をＶＤＰプリンタ１０２に送信しておく。そして、ＶＤＰクライアント１０１は、そのコンテンツデータ５１６を識別するキャッシュＩＤ５２３を、ＶＤＰプリンタ１０２から取得して、コンテンツデータ５１６と対応付けて記憶しておく。ＶＤＰクライアント１０１は、キャッシュＩＤ５２３を含むプロキシデータ５１３をコンテンツデータ５１６の代わりに用いて、ＶＤＰジョブファイル５１８を生成してＶＤＰプリンタ１０２に送信する。このように、オリジナルのコンテンツデータ５１６ではなく、そのコンテンツデータ５１６よりもデータ量の小さい代理データを用いてＶＤＰジョブファイル５１８を生成するので、ＶＤＰジョブファイル５１８のデータ量を低減することができる。よって、コンテンツデータ５１６を差し込んで画像を形成する際のスループットを従来よりも向上させることができる。
また、本実施形態では、ＶＤＰプリンタ１０２は、ＶＤＰクライアント１０１からコンテンツデータ５１６を受け取ると、そのコンテンツデータ５１６のキャッシュＩＤ５２３を生成する。更に、ＶＤＰプリンタ１０２は、そのコンテンツデータ５１６をラスタライズしてラスタデータ５０７を生成する。そして、ＶＤＰプリンタ１０２は、それらキャッシュＩＤ５２３と、コンテンツデータ５１６と、ラスタデータ５０７とを対応付けてキャシュＤＢ５１０に記憶する。その後、ＶＤＰクライアント１０１から送信されたＶＤＰジョブファイル５１８にプロキシデータ５１３がある場合、ＶＤＰプリンタ１０２は、そのプロキシデータ５１３に含まれているキャッシュＩＤ５２３に対応するラスタデータ５０７を用いて印刷処理を行う。したがって、ＶＤＰジョブファイル５１８の取得時に行うラスタライズ処理の一部を省略することができ、印刷処理時間を短縮することができる。
また、本実施形態では、キャッシュＩＤ５２３と、そのキャッシュＩＤ５２３で識別されるコンテンツデータ５１６と、そのコンテンツデータ５１６サムネイルデータ７０９とを対応付けて、外部記憶装置２０４に記憶するようにした。したがって、ＶＤＰアプリケーションプログラム５０４から取得要求のあったコンテンツデータ５１６に関するキャッシュＩＤ５２３が既に記憶されている場合には、そのキャッシュＩＤの取得処理を省略することができる。
尚、本実施形態では、図１において、ＶＤＰクライアント１０１、ＶＤＰプリンタ１０２、及びＤＢサーバ１０３が、ネットワーク１０４を介して相互に接続されるようにした。しかしながら、ＶＤＰクライアント１０１、ＶＤＰプリンタ１０２、及びＤＢサーバ１０３の接続形態は、これ以外のものであってもよい。例えば、ＶＤＰクライアント１０１とＶＤＰプリンタ１０２とが直接接続されるようにしてもよい。また、ＶＤＰクライアント１０１とＶＤＰプリンタ１０２とが接続されておらず、可搬メディア（ＵＳＢメモリやリムーバブルＨＤＤ等）を使って、ＶＤＰジョブファイル５１８を、ＶＤＰクライアント１０１からＶＤＰプリンタ１０２に人手で運搬してもよい。
また、本実施形態では、図２において、プログラムがＲＡＭ２０２、３０２に格納されるとしたが、プログラムの格納場所はこれに限るものではない。例えば、プログラムを外部記憶装置２０４、３０５から読み出して実行するようにしてもよいし、ネットワークインタフェース２０３、３０３を介して受信してプログラムを実行するようにしてもよい。また、図２及び図３には示していないが、ＲＯＭ等の読み出し専用の内部記憶媒体からプログラムを読み出して実行するようにしてもよい。
また、ＶＤＰクライアント１０１及びＤＢサーバ１０３は、キーボード２０６やポインティングデバイス２０７の代わりに、或いはそれらに加えて、音声入力等の他の入力装置を備えることもできる。また、ディスプレイ２０５、キーボード２０６、及びポインティングデバイス２０７を、他のコンピュータ装置と共有することもできる。
ＶＤＰプリンタ１０２において、ＲＩＰ処理を行う装置とプリンタエンジンによる出力を行う装置とを別の装置として分離してもよい。
また、本実施形態では、図５においてＶＤＰアプリケーションプログラム５０４が単体のプログラムであるとしたが、ＶＤＰアプリケーションプログラム５０４は単体のプログラムに限るものではない。例えば、ＶＤＰアプリケーションプログラム５０４は、Adobe PhotoShop（登録商標）プラグイン、Adobe Illustrator（登録商標）プラグイン、Adobe InDesign（登録商標）プラグイン、Adobe PDF（登録商標）プラグインとして実行されるようなサブプログラムであってもよい。また、ＶＤＰアプリケーションプログラム５０４は、Microsoft Word（登録商標）アドオンとして実行されるようなサブプログラムであってもよい。
また、ＤＢブローカープログラム５０５は、ＶＤＰクライアント５０１に存在するとしたが、これに限るものではない。例えば、ＤＢブローカープログラム５０５は、ＤＢサーバ１０３又はＶＤＰプリンタ１０２に存在していてもよい。また、全く別のコンピュータ装置にＤＢブローカープログラム５０５が存在してもよい。
また、ＶＤＰアプリケーションプログラム５０４、ＤＢブローカープログラム５０５、コンテンツＤＢ５０６、ＲＩＰプログラム５０８、及びキャッシュマネージャ５０９間で、各種のデータを直接送受信している。しかしながら、ワークフローマネージャや、代理サーバ等のモジュールを介して各種のデータを送受信する形態としてもよい。特にＶＤＰジョブファイル５１８に関しては、ＶＤＰクライアント１０１の外部記憶装置２０４にホットフォルダを設け、ＲＩＰプログラム５０８が、そのホットフォルダの変化を監視するようにしてもよい。このようにすれば、ＲＩＰプログラム５０８が、そのホットフォルダに置かれたＶＤＰジョブファイル５１８を能動的に取得することができる。尚、前記において、各種のデータとは、例えば、ラスタデータ５０７、プロキシデータ５１３、コンテンツデータ５１６、ＶＤＰジョブファイル５１８、キャッシュＩＤ５２３、及びラスタデータ５０７である。
また、入力されたＶＤＰジョブファイル５１８を管理するためのジョブマネージャや、ＲＩＰプログラム５０８の処理を管理するためのＲＩＰマネージャをＶＤＰプリンタ５０３に設けるようにしてもよい。この場合、ＲＩＰプログラム５０８は、ラスタライズ処理のみを行うように構成されている場合が多いが、そのような構成においても、前述した本実施形態のシステムを適用できることは明らかである。
また、本実施形態では、図７において、プロキシデータ５１３が、キャッシュＩＤ５２３とサムネイルデータ７０９とを含む構成とした。しかしながら、サムネイルデータ７０９は、検査、プレビュー、試し印刷等の処理ができるようにするためにＶＤＰジョブファイル５１８に含めているものである。したがって、それらの処理が不要であればサムネイルデータ７０９を省略することができる。また、キャッシュＩＤ５２３は、コンテンツＩＤから検索することもできるので、キャッシュＩＤ５２３の代わりにコンテンツＩＤを使用してもよい。また、キャッシュＩＤ５２３の生成にGUIDを使用したが、システム内での一意性が保証される方法であれば、他の方法でキャッシュＩＤ５２３を生成しても構わない。また、コンテンツＩＤ５２３の生成にMD5を使用したが、同一のコンテンツからは同一のコンテンツＩＤが生成され、異なるコンテンツからは異なるコンテンツＩＤが生成されれば、どのような方法でコンテンツＩＤ５２３を生成してもよい。すなわち、コンテンツＩＤ５２３の衝突がない（或いは無視できる程度に限りなくコンテンツＩＤ５２３の衝突が少ない）方法であれば、どのような方法でコンテンツＩＤ５２３を生成してもよい。
また、本実施形態では、図１０において、メニューウィンドウ１００６と、メインウィンドウ１００１とが別のウィンドウとなっているが、必ずしもこのようにする必要はない。例えば、Windows（登録商標）のアプリケーションで行われているように、メインウィンドウ１００１の上部にメニューバーやツールバーを設けてもよい。また、ユーザがメニューにアクセスすることが可能な方法であれば他の方法を用いてメニューの表示を行ってもよい。また、図１０に示したメニューの項目もあくまでも一例である。
また、メインウィンドウ１００１に作成した枠１００２〜１００５を最小単位としてコンテンツデータを配置したが、必ずしもこのようにする必要はない。例えば、枠１００２〜１００５に入力されたテキストの一部を可変データとして枠ルールを設定するようにしてもよい。また、枠１００２〜１００５の位置・大きさ・変形方法・書式・属性・可視性等を可変データとして枠ルールを設定するようにしてもよい。枠１００２〜１００５に限らず、ＶＤＰ文書に存在するレイヤーやＶＤＰ文書そのものの属性等を可変データとしてルールを設定してもよい。このようにＶＤＰ文書のあらゆる要素を可変データとしてルールを設定することが可能であるが、このような場合でも、前述した本実施形態のシステムに適用することが可能である。
また、本実施形態では、テキストボックス１００７で指定されたCUSTOMERテーブル１１００にＶＤＰアプリケーションプログラム５０４が直接アクセスを行うようにした。しかしながら、このCUSTOMERテーブル１１００を、外部ＤＢ（例えばコンテンツＤＢ５０６）に保存するようにしてもよい。この場合、ＤＢブローカー５０５が、ＶＤＰアプリケーションプログラム５０４からCUSTOMERテーブル１１００へのアクセスを仲介することになる。
また、本実施形態では、図１２の枠管理テーブル１２００に示したように、枠ルール文法を定義したが、必ずしも図１２に示した枠ルール文法を使用する必要はなく、任意の枠ルール文法を定義することが可能である。
また、本実施形態では、ＵＮＣの記述に基づいてコンテンツデータ５１６を参照するようにしたが、必ずしもこのようにする必要はない。例えば、コンテンツデータ５１６を、ＵＲＩ、ＵＲＬ、ＵＲＮ等の記述に基づいて参照してもよいし、特定の環境に依存した方法で参照してもよい。また、何らかのデータベースを参照するような記述（ＳＱＬ文による指定等）や、何らかのプログラムをローカル又はリモートで呼び出すための記述等に基づいて、コンテンツデータ５１６を参照してもよい。つまり、コンテンツデータ５１６が参照できれば、コンテンツデータ５１６を参照するための記述方法は任意である。また、ReusableObject列１２０３に格納されるフラグを、枠管理テーブル１２００に持たせるのではなく、毎回更新するようにしてもよい。
また、本実施形態では、キャッシュデータとしてラスタデータ５０７を使用したが、デバイス（プリンタ）に依存しない中間言語データをキャッシュデータとして使用してもよい。また、中間言語データとラスタデータとの両方をキャッシュデータとして持つようにしてもよい。
また、本実施形態では、図１６において、コンテンツデータ５１６をキャッシュするか否かを判定するスレッショルド値（閾値）としてコンテンツデータ５１６のサイズ（容量）を使用したが、必ずしもこのようにする必要はない。例えば、コンテンツデータ５１６の種別、ラスタライズ処理時の複雑度、又はキャッシュＤＢ５１０の残り容量等、任意の指標（条件）を用いて、スレッショルド値を決定することが可能である。
また、本実施形態では、サムネイルデータ７０９を、ＤＢブローカー５０５で作成するようにしたが、必ずしもこのようにする必要はない。例えば、キャッシュマネージャプログラム５０９が、ＲＩＰプログラム５０８の機能を利用してサムネイルデータ７０９を作成してもよい。このようにした場合、キャッシュマネージャプログラム５０９は、キャッシュＩＤ５２３に加えてサムネイルデータ７０９を、通信経路１０４ｅを介してＤＢブローカー５０５に返すこともできる。このように、サムネイルデータ７０９もキャッシュＤＢ５１０に保存しておくことで、同一のコンテンツデータ５１６に対するサムネイルデータ７０９もキャッシュしておくことができる。
また、本実施形態では、文書フォーマット技術としてPPML技術を使用したが、文書フォーマット技術は、PPML技術に限定されるものではない。例えば、PPML/VDX、PPML Template、VIPP、FreeForm、ＶＰＳ等の文書フォーマット技術を使用してもよい。
また、本実施形態では、プロキシデータ５１３に、キャッシュＩＤ５２３と、サムネイルデータ７０９とを含ませるようにした。その際、サムネイルデータ７０９をＶＤＰジョブファイル５１８に格納し、XML名前空間を使用した拡張属性として、キャッシュＩＤ５２３をPPMLデータファイル７０２に記述した。しかしながら、キャッシュＩＤ５２３を、ＶＤＰジョブファイル５１８内の特定のファイルに記述したり、サムネイルデータ７０９の中に直接埋め込んだりすることもできる。
（本発明の他の実施形態）
前述した本発明の実施形態におけるデータ処理装置、画像形性装置を構成する各手段、並びにデータ処理方法、画像形成方法の各ステップは、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。
また、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図８、図９に示すシーケンス、及び図１５〜図１７、図２３に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などもある。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
なお、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
本発明の実施形態を示し、印刷システムの概略構成の一例を示す図である。 本発明の実施形態を示し、ＶＤＰクライアント及びＤＢサーバの構成の一例を示すブロック図である。 本発明の実施形態を示し、ＶＤＰプリンタの構成の一例を示すブロック図である。 本発明の実施形態を示し、印刷システムの基本となる構成の一例を示すブロック図である。 本発明の実施形態を示し、印刷システムの構成の一例を特徴となる部分を含めて示すブロック図である。 本発明の実施形態を示し、文書フォーマット技術としてPPMLを使用した場合のＶＤＰジョブファイルの基本的な構造の一例を示す図である。 本発明の実施形態を示し、文書フォーマット技術としてPPMLを使用した場合のＶＤＰジョブファイル５１８の構造の一例を特徴部分を含めて示す図である。 本発明の実施形態を示し、図４に示した印刷システムにおいて、ユーザが印刷を指示した場合に行われる印刷処理シーケンスの一例を示す図である。 本発明の実施形態を示し、図５に示した本実施形態の特徴を有する印刷システムにおいて、ユーザが印刷を指示した場合に行なわれる印刷処理シーケンスの一例を示す図である。 本発明の実施形態を示し、ＶＤＰクライアントにおいて、ＶＤＰアプリケーションプログラムがＲＡＭに読み込まれて実行されている最中に、ディスプレイに表示されるレイアウト画面の一例を示す図である。 本発明の実施形態を示し、作成中のＶＤＰ文書に関連付けられるデータソースの一例として指定されているCUSTOMERテーブルの内容の一例を示す図である。 本発明の実施形態を示し、枠についての情報をＲＡＭに格納しておく際に使用する枠管理テーブルの構造と、本実施形態で使用する枠情報の内容との一例を示す図である。 本発明の実施形態を示し、コンテンツＤＢに存在するコンテンツデータのうち、本実施形態の説明に必要なコンテンツデータの情報の一例を示す図である。 本発明の実施形態を示し、キャッシュＤＢの構造の一例を示す図である。 本発明の実施形態を示し、ボタンがユーザによって押され、印刷が指示された場合のＶＤＰアプリケーションプログラムにおける動作の一例について説明するフローチャートである。 本発明の実施形態を示し、図１５−１に続くフローチャートである。 本発明の実施形態を示し、キャッシュＩＤの生成が依頼された場合と、コンテンツデータの取得が依頼された場合のＤＢブローカープログラム５０５の動作の一例を説明するフローチャートである。 本発明の実施形態を示し、キャッシュＩＤの取得依頼があった場合のキャッシュマネージャプログラムにおける動作の一例を説明するフローチャートである。 本発明の実施形態を示し、枠管理テーブルに格納されている全ての枠に対して再利用可能オブジェクトに関わる処理を実行した時点でのＶＤＰシステムの内部状態の一例を示す図である。 本発明の実施形態を示し、ジョブの１ページ目の処理が完了した時点でのＶＤＰシステムの内部状態の一例を示す図である。 本発明の実施形態を示し、ジョブの２ページ目の処理が完了した時点でのＶＤＰシステムの内部状態の一例を示す図である。 本発明の実施形態を示し、ジョブの３ページ目（全ページ）の処理が完了した時点でのＶＤＰシステムの内部状態の一例を示す図である。 本発明の実施形態を示し、PPMLデータファイルの一例を示す図である。 本発明の実施形態を示し、ＶＤＰジョブファイルが送信された場合のＲＩＰプログラムにおける動作の一例を説明するフローチャートである。 本発明の実施形態を示し、１ページ目の印刷結果の一例を示す図である。 本発明の実施形態を示し、２ページ目の印刷結果の一例を示す図である。 本発明の実施形態を示し、３ページ目の印刷結果の一例を示す図である。
符号の説明
１０１ ＶＤＰクライアント
１０２ ＶＤＰプリンタ
１０３ ＤＢサーバ
１０４ ネットワーク
２０１ ＣＰＵ
２０２、３０２ ＲＡＭ
２０４、３０５ 外部記憶装置
３０１ ＭＦＰ制御部
５０４ ＶＤＰアプリケーションプログラム
５０５ ＤＢブローカープログラム
５０６ コンテンツＤＢ
５０７ ラスタデータ
５０８ ＲＩＰプログラム
５０９ キャッシュマネージャプログラム
５１３ プロキシデータ
５１６ コンテンツデータ
５１８ ＶＤＰジョブファイル
５２３ キャッシュＩＤ
７０２ PPMLデータファイル
７０９ サムネイルデータ

Claims (7)

  1. 画像を形成する画像形成装置と通信可能なデータ処理装置であって、
    差込領域に差し込まれるコンテンツデータを、データベースから取得するコンテンツデータ取得手段と、
    前記画像を形成するための画像形成用データが前記画像形成装置に送信される前に、前記コンテンツデータ取得手段により取得されたコンテンツデータを、前記画像形成装置に送信するコンテンツデータ送信手段と、
    前記コンテンツデータ送信手段により送信されたコンテンツデータの識別情報を、前記画像形成装置から取得する識別情報取得手段と、
    前記識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成する画像形成用データ生成手段と、
    前記画像形成用データ生成手段により生成された画像形成用データを、前記画像形成装置に送信する画像形成用データ送信手段とを有し、
    前記画像形成装置において実行される前記コンテンツデータに基づくラスタデータの生成処理は、前記データ処理装置において実行される前記画像形成用データの生成処理と並行して実行されることを特徴とするデータ処理装置。
  2. 前記コンテンツデータと、そのコンテンツデータの識別情報とを対応付けて記憶する記憶手段と、
    前記差込領域に差し込まれるコンテンツデータの識別情報が、前記記憶手段に記憶されているか否かを判定する判定手段とを有し、
    前記画像形成用データ生成手段は、前記画像を形成するために必要なコンテンツデータの識別情報が、前記記憶手段に記憶されていることが、前記判定手段により判定された場合には、その識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成することを特徴とする請求項１に記載のデータ処理装置。
  3. 前記コンテンツデータ取得手段により取得されたコンテンツデータの識別情報を、そのコンテンツデータの代わりに用いるか否かを、予め定められた条件に基づいて判定する第２の判定手段を有し、
    前記コンテンツデータ送信手段は、前記コンテンツデータ取得手段により取得されたコンテンツデータの識別情報を、そのコンテンツデータの代わりに用いることが、前記第２の判定手段により判定された場合に、そのコンテンツデータを、前記画像を形成する画像形成装置に送信し、
    前記画像形成用データ生成手段は、前記コンテンツデータ取得手段により取得されたコンテンツデータの識別情報を、そのコンテンツデータの代わりに用いないことが、前記第２の判定手段により判定された場合には、そのコンテンツデータを用いて、前記画像形成用データを生成することを特徴とする請求項１又は２に記載のデータ処理装置。
  4. 画像を形成する画像形成装置と通信可能なデータ処理装置におけるデータ処理方法であって、
    差込領域に差し込まれるコンテンツデータを、データベースから取得するコンテンツデータ取得ステップと、
    前記画像を形成するための画像形成用データが前記画像形成装置に送信される前に、前記コンテンツデータ取得ステップにより取得されたコンテンツデータを、前記画像形成装置に送信するコンテンツデータ送信ステップと、
    前記コンテンツデータ送信ステップにより送信されたコンテンツデータの識別情報を、前記画像形成装置から取得する識別情報取得ステップと、
    前記識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成する画像形成用データ生成ステップと、
    前記画像形成用データ生成ステップにより生成された画像形成用データを、前記画像形成装置に送信する画像形成用データ送信ステップとを有し、
    前記画像形成装置において実行される前記コンテンツデータに基づくラスタデータの生成処理と、前記データ処理装置において実行される前記画像形成用データの生成処理とが並行して実行されることを特徴とするデータ処理方法。
  5. 画像を形成する画像形成装置と通信可能なデータ処理装置におけるデータ処理方法の各ステップをコンピュータに実行させるためのコンピュータプログラムであって、
    前記各ステップは、
    差込領域に差し込まれるコンテンツデータを、データベースから取得するコンテンツデータ取得ステップと、
    前記画像を形成するための画像形成用データが前記画像形成装置に送信される前に、前記コンテンツデータ取得ステップにより取得されたコンテンツデータを、前記画像形成装置に送信するコンテンツデータ送信ステップと、
    前記コンテンツデータ送信ステップにより送信されたコンテンツデータの識別情報を、前記画像形成装置から取得する識別情報取得ステップと、
    前記識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成する画像形成用データ生成ステップと、
    前記画像形成用データ生成ステップにより生成された画像形成用データを、前記画像形成装置に送信する画像形成用データ送信ステップとを有し、
    前記画像形成装置において実行される前記コンテンツデータに基づくラスタデータの生成処理と、前記データ処理装置において実行される前記画像形成用データの生成処理とが並行して実行されることを特徴とするコンピュータプログラム。
  6. 前記各ステップは、
    前記コンテンツデータと、そのコンテンツデータの識別情報とを対応付けて記憶手段に記憶する記憶ステップと、
    前記差込領域に差し込まれるコンテンツデータの識別情報が、前記記憶手段に記憶されているか否かを判定する判定ステップとを有し、
    前記画像形成用データ生成ステップは、前記画像を形成するために必要なコンテンツデータの識別情報が、前記記憶手段に記憶されていることが、前記判定ステップにより判定された場合には、その識別情報を前記コンテンツデータの代わりに用いて、前記画像を形成するための画像形成用データを生成することを特徴とする請求項５に記載のコンピュータプログラム。
  7. 前記各ステップは、
    前記コンテンツデータ取得ステップにより取得されたコンテンツデータの識別情報を、そのコンテンツデータの代わりに用いるか否かを、予め定められた条件に基づいて判定する第２の判定ステップを有し、
    前記コンテンツデータ送信ステップは、前記コンテンツデータ取得ステップにより取得されたコンテンツデータの識別情報を、そのコンテンツデータの代わりに用いることが、前記第２の判定ステップにより判定された場合に、そのコンテンツデータを、前記画像を形成する画像形成装置に送信し、
    前記画像形成用データ生成ステップは、前記コンテンツデータ取得ステップにより取得されたコンテンツデータの識別情報を、そのコンテンツデータの代わりに用いないことが、前記第２の判定ステップにより判定された場合には、そのコンテンツデータを用いて、前記画像形成用データを生成することを特徴とする請求項５又は６に記載のコンピュータプログラム。
JP2007000747A 2007-01-05 2007-01-05 データ処理装置、データ処理方法、及びコンピュータプログラム Expired - Fee Related JP5127232B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2007000747A JP5127232B2 (ja) 2007-01-05 2007-01-05 データ処理装置、データ処理方法、及びコンピュータプログラム
US11/961,794 US8294942B2 (en) 2007-01-05 2007-12-20 Data processing apparatus, image forming apparatus, and computer program
EP08150044.9A EP1942407B1 (en) 2007-01-05 2008-01-04 Data processing apparatus, image forming apparatus, and computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007000747A JP5127232B2 (ja) 2007-01-05 2007-01-05 データ処理装置、データ処理方法、及びコンピュータプログラム

Publications (3)

Publication Number Publication Date
JP2008171033A JP2008171033A (ja) 2008-07-24
JP2008171033A5 JP2008171033A5 (ja) 2010-02-18
JP5127232B2 true JP5127232B2 (ja) 2013-01-23

Family

ID=39186853

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007000747A Expired - Fee Related JP5127232B2 (ja) 2007-01-05 2007-01-05 データ処理装置、データ処理方法、及びコンピュータプログラム

Country Status (3)

Country Link
US (1) US8294942B2 (ja)
EP (1) EP1942407B1 (ja)
JP (1) JP5127232B2 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4902413B2 (ja) * 2007-04-19 2012-03-21 キヤノン株式会社 印刷データ処理装置、印刷データ処理方法及びプログラム
US8909810B2 (en) * 2008-08-05 2014-12-09 Isabella Products, Inc. Systems and methods for multimedia content sharing
JP5182065B2 (ja) * 2008-12-19 2013-04-10 富士ゼロックス株式会社 画像処理装置、画像処理プログラム及び印刷システム
JP5305930B2 (ja) * 2009-01-13 2013-10-02 キヤノン株式会社 画像形成装置、ジョブ処理方法、プログラム及び記憶媒体
JP5195519B2 (ja) * 2009-02-27 2013-05-08 株式会社リコー 文書管理装置、文書処理システム、文書管理方法
JP5407520B2 (ja) * 2009-04-24 2014-02-05 富士ゼロックス株式会社 印刷制御装置及び印刷制御システム
JP5304422B2 (ja) * 2009-05-01 2013-10-02 コニカミノルタ株式会社 画像処理装置、画像処理方法、および画像処理プログラム
JP2011008352A (ja) * 2009-06-23 2011-01-13 Canon Inc 文書処理装置、文書処理方法、及びプログラム
JP5404303B2 (ja) * 2009-10-19 2014-01-29 キヤノン株式会社 画像処理装置、画像処理方法及びプログラム
JP5586970B2 (ja) * 2010-01-25 2014-09-10 キヤノン株式会社 情報処理装置および制御方法およびプログラム
JP5538995B2 (ja) * 2010-04-30 2014-07-02 キヤノン株式会社 情報処理装置、情報処理方法及びプログラム
JP5100788B2 (ja) * 2010-05-27 2012-12-19 シャープ株式会社 画像形成システム、データ処理装置、画像形成装置及びコンピュータプログラム
JP5516095B2 (ja) 2010-06-08 2014-06-11 コニカミノルタ株式会社 印刷データ生成装置、印刷データ生成方法、及び印刷データ生成装置の制御プログラム
JP5836051B2 (ja) * 2010-12-24 2015-12-24 キヤノン株式会社 印刷制御装置及びその制御方法並びにプログラム
JP2012135958A (ja) * 2010-12-27 2012-07-19 Canon Inc 印刷装置、印刷制御方法及びプログラム
JP2012148429A (ja) * 2011-01-17 2012-08-09 Canon Inc 印刷データ処理装置、キャッシュ処理方法及びプログラム
JP2016212575A (ja) * 2015-05-07 2016-12-15 ミールソリューションズ株式会社 ドキュメント作成システム
EP4266660B1 (en) * 2022-04-19 2026-05-06 Canon Kabushiki Kaisha Inspection apparatus, method for controlling same, and storage medium

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04175923A (ja) 1990-11-09 1992-06-23 Fujitsu Ltd オーバーレイ印刷装置
JP2554395B2 (ja) * 1990-11-30 1996-11-13 株式会社日立製作所 印刷書式管理システム
EP0511438A1 (en) * 1991-04-30 1992-11-04 International Business Machines Corporation Printing in data processing systems
US5611035A (en) * 1992-10-16 1997-03-11 International Business Machines Corporation Relational data base system for conveniently constructing graphical images
US5668897A (en) * 1994-03-15 1997-09-16 Stolfo; Salvatore J. Method and apparatus for imaging, image processing and data compression merge/purge techniques for document image databases
US5729665A (en) * 1995-01-18 1998-03-17 Varis Corporation Method of utilizing variable data fields with a page description language
US6078403A (en) * 1996-10-21 2000-06-20 International Business Machines Corporation Method and system for specifying format parameters of a variable data area within a presentation document
US6330073B1 (en) * 1998-07-20 2001-12-11 Nw Coughlin System and method for merging multi-platform documents
US6144458A (en) * 1998-09-02 2000-11-07 Adobe Systems Incorporated Single-pass transmission of repeated objects between host and printer
JP3975616B2 (ja) * 1999-06-18 2007-09-12 富士ゼロックス株式会社 画像処理装置
ES2269070T3 (es) 1999-08-12 2007-04-01 Seiko Epson Corporation Impresora con funcion de encuadernacion para encuadernar material impreso.
US6919967B1 (en) * 1999-11-18 2005-07-19 Hewlett-Packard Development Company, L.P. Printing performance enhancements for variable data publishing
US7069327B1 (en) * 2000-03-02 2006-06-27 Sharp Laboratories Of America, Inc. Method and apparatus for reducing first copy out times using uniqueness identifiers
US7106469B2 (en) * 2001-08-08 2006-09-12 Hewlett-Packard Development Company, L.P. Variable data printing with web based imaging
US7327487B2 (en) * 2001-10-23 2008-02-05 Eastman Kodak Company Banded compositor for variable data
US7375842B2 (en) * 2002-04-09 2008-05-20 Eastman Kodak Company Variable data printing using variants
US7505172B2 (en) * 2003-10-31 2009-03-17 Hewlett-Packard Development Company, L.P. Method and systems for processing print jobs
US20060023238A1 (en) * 2004-07-30 2006-02-02 Eastman Kodak Company Select reprint of records in variable data printing
US20070253027A1 (en) * 2006-04-27 2007-11-01 Hiebert Steven P System and method for on-press merging of variable data printing documents

Also Published As

Publication number Publication date
US20080165383A1 (en) 2008-07-10
EP1942407B1 (en) 2018-07-04
JP2008171033A (ja) 2008-07-24
EP1942407A2 (en) 2008-07-09
EP1942407A3 (en) 2010-04-14
US8294942B2 (en) 2012-10-23

Similar Documents

Publication Publication Date Title
EP1942407B1 (en) Data processing apparatus, image forming apparatus, and computer program
JP5084378B2 (ja) 画像処理装置、画像処理方法、及びコンピュータプログラム
JP5116323B2 (ja) 情報処理装置、情報処理方法、及びコンピュータプログラム
JP4324060B2 (ja) 文書管理システム及びその方法と文書管理装置及び当該装置の制御方法
KR102038182B1 (ko) 정보 처리 시스템, 서버 장치, 제어 방법 및 저장 매체
CN101652745A (zh) 打印控制装置和方法
KR100991555B1 (ko) 연계 잡 흐름 작성 장치, 연계 잡 흐름 작성 방법, 서비스 처리 장치, 서비스 처리 방법, 관리 서버, 흐름 변환 방법, 잡 흐름 실행 방법, 및 기억 매체
JP2005166050A (ja) Ｐｄｆ文書からｐｐｍｌテンプレートへの翻訳
JP5426843B2 (ja) 情報処理装置、情報処理方法、プログラムおよびプログラムを格納する記憶媒体
JP5733201B2 (ja) 印刷制御装置、印刷制御プログラム
JP5188881B2 (ja) データ変換装置、データ変換プログラム、およびデータ変換方法
JP4668067B2 (ja) 印刷装置、印刷方法、印刷装置のためのプログラム、印刷指示装置およびメモリ解放制御方法
JP2009116688A (ja) 装置、システム、方法、記録媒体、画像処理装置及び画像処理方法
JP6529229B2 (ja) 情報処理装置、制御方法、およびコンピュータプログラム
JP4817932B2 (ja) 情報処理装置、表示制御方法、及びプログラム
JP2008311941A (ja) 情報処理装置及び情報処理方法
JP2002229976A (ja) 情報処理装置及びその方法、コンピュータ可読メモリ、プログラム
JP6370156B2 (ja) 情報処理装置及びその制御方法
JP6155802B2 (ja) 画像形成装置、画像形成システム、その制御方法及びプログラム
WO2011001921A1 (en) Information processing apparatus, control method, and program
JP5106655B2 (ja) 印刷制御装置及び方法
JP2000172464A (ja) プリントシステム、プリンタおよびプリントサーバ
US20090287733A1 (en) Method for preparing prepress image data
JP6320146B2 (ja) 情報処理システム、情報処理装置、情報処理方法、及びプログラム
JP2006235756A (ja) 画像処理装置およびその方法

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091225

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091225

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120622

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120626

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120827

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121023

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121030

R151 Written notification of patent or utility model registration

Ref document number: 5127232

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151109

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees