JP4619433B2 - 印刷制御装置及び印刷制御方法、並びにプログラム - Google Patents

Description

本発明は、印刷制御及び印刷制御方法、並びにプログラムに関し、特に、ＸＰＳデータを解析する印刷制御装置及び印刷制御方法、並びにプログラムに関する。

パーソナルコンピュータ等の情報処理装置には、キーボード入力や画像出力といった入出力機能、ディスクやメモリの管理機能などの多くのアプリケーションソフト（以下、単に「アプリケーション」と呼ぶ。）により共通して利用される基本的な機能を提供し、情報処理装置全体を管理するソフトウェアであるオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：ＯＳ）が搭載されている。例えば、Ｍｉｃｒｏｓｏｆｔ社製のＷ
ｉｎｄｏｗｓ（登録商標） ＸＰ、Ｗｉｎｄｏｗｓ（登録商標） ２０００やＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａなどが挙げられる。

このような情報処理装置を用いてユーザが各種文書を閲覧できるように様々な文書ファイルフォーマットが存在するが、その一つにＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＸＰＳ）という文書ファイルフォーマットがある。上述のＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａでは、ＸＰＳが文書ファイルフォーマットとしてのみでなく印刷スプールファイルのフォーマットとしても利用される。

ＸＰＳのフォーマットに従ったデータをＸＰＳデータ、データがＸＰＳ形式のファイルをＸＰＳファイルと呼ぶ。また、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）とは、文書やデータの意味や、構造を記述するためのマークアップ言語の１つであり、構造化文書と呼ばれる。構造化文書は他には、ＨＴＭＬやＳＧＭＬなどがある。

ところで、情報処理装置とプリンタなどの印刷装置とからなるシステムにおいて印刷を実施する場合、通常、情報処理装置内のアプリケーションがユーザからの印刷実行命令を受けると、当該アプリケーションが起動しているＯＳ及びＯＳが提供する印刷システムに応じた印刷命令の発行処理を行う。例えば、Ｗｉｎｄｏｗｓ（登録商標） ＸＰやＷｉｎｄｏｗｓ（登録商標） ２０００などのＯＳ上で起動しているアプリケーションは、ＯＳ
が提供するＧＤＩ（Ｇｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）プリントパスと呼ばれる印刷システムの形式に従って印刷命令を発行している。

一方、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａにおいては、前述したＧＤＩプリントパスに加えて、ＸＰＳプリントパスと呼ばれる印刷システムが新たに提供されている。ＧＤＩプリントパス、ＸＰＳプリントパスの詳細については後述する。

ここで、ＸＰＳデータのフォーマットについて説明する。

ＸＰＳデータは、複数のファイルがＺＩＰ圧縮形式で圧縮されて一つのファイルにアーカイブされたアーカイブデータである。アーカイブされるファイルは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイル、ＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）ファイル、ＰＮＧ（Ｐｏｒｔａｂｌｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ）ファイル、ＴＩＦＦ（Ｔａｇｇｅｄ Ｉｍａｇｅ Ｆｉｌｅ Ｆｏｒｍａｔ）ファイル、ＨＤ Ｐｈｏｔｏファイル、及びフォントファイルなどである。ＸＭＬファイルには、文書を形成するための各種情報がＸＭＬ形式で記述される。なお、記述される情報毎に複数のＸＭＬファイルに分割されている。ＸＰＳでは、一つの文書は幾つかの括りに分割されて構成されているものと考えられている。すなわち、一つの文書は複数若しくは一つのドキュメントという括りから成り、一つのドキュメントは複数若しくは一つのページという括りから成る。

また、ＪＰＥＧ、ＰＮＧ、ＴＩＦＦ、ＨＤ Ｐｈｏｔｏは各々イメージを表現するためのフォーマットであり、これらのファイルを総称してイメージファイルと呼ぶ。ＸＰＳデータには、一つの文書を構成するのに必要な数のイメージファイルやフォントファイルが包含される。また、これらのＸＰＳデータに包含されるファイルを各々パーツと呼ぶ。つまり、一つのＸＰＳデータには、複数のパーツが包含されている。ＸＰＳデータの構成例を図４に示す。

ＸＰＳデータに包含された各パーツは他のパーツへの参照を有する。この参照により、ＸＰＳデータ内の全パーツが関係性を持つ一つの文書情報として形成されている。ＸＰＳデータには、イメージファイル８０８，８０９やフォントファイル８０７の他に、例えば、以下のような複数種類のパーツが包含され、各々が以下のような参照を有する。

ａ）＿ｒｅｌｓ／．ｒｅｌｓ８０１：文書データの開始点となるパーツである。後述するＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅ（以下、「ＦＤＳ」と略す。）への参照を有する。

ｂ）ＦＤＳ８１０：一つの文書データの構成情報が記述されたパーツである。後述するＦｉｘｅｄＤｏｃｕｍｅｎｔ（以下、「ＦＤ」と略す。）への参照を有する。なお、一つのデータは複数のドキュメントを有する場合がある。つまり、ＦＤＳは、複数のＦＤへの参照を有する場合がある。

ｃ）ＦＤ８０４，８０６：一つのドキュメントに存在する複数のページをページ順に並べ、束ねるためのパーツである。一つのドキュメントの構成情報が記述されたパーツであり、ＦｉｘｅｄＰａｇｅ（以下、「ＦＰ」と略す。）への参照を有する。なお、一つのドキュメントは複数のページを有する場合がある。つまり、ＦＤは、複数のＦＰへの参照を有する場合がある。

ｄ）ＦＰ８０２，８０３，８０５：１ページの描画内容が記述されたパーツである。必要に応じて、イメージファイル８０８，８０９やフォントファイル８０７への参照を有する。例えば、当該ページにイメージの描画が存在する場合は、当該イメージファイルへの参照を有することになる。

e）ＦＰ．ｒｅｌｓ３２０１：ＦｉｘｅｄＰａｇｅに関連するパーツへの参照情報が記述されたパーツである。１ＦＰにつき１つ対応するＦＰ．ｒｅｌｓが存在する。対応するＦＰから参照される全ての、イメージファイルへの参照を有することになる。

図５は、図４のＸＰＳデータにおけるパーツ間の参照関係の論理的構造の一例を示す参考図であり、図６及び図３２は、パーツデータのＸＭＬファイルの記述に基づいたパーツ間の参照関係の一例を示す参考図である。

図示では、＿ｒｅｌｓ／．ｒｅｌｓ８０１はＦＤＳ８１０を参照し、ＦＤＳ８１０はＦＤ８０４，８０６を参照し、ＦＤ８０４はＦＰ８０２，８０３を参照し、ＦＤ８０６はＦＰ８０５を参照し、ＦＰ８０２はイメージファイル８０８及びフォントファイル８０７を参照し、ＦＰ８０３はイメージファイル８０９を参照し、ＦＰ８０５はイメージファイル８０９を参照している。

また、図３２に示すように、ＦＰ．ｒｅｌｓ３２０１は、イメージファイル８０８及びフォントファイル８０７等のリソースファイルを参照している。

次に、ＸＰＳデータを構成するＺＩＰ圧縮形式で圧縮（以下、「ＺＩＰ圧縮」と呼ぶ。）されたデータについて図７を参照して説明する。

図７は、ＸＰＳデータを構成するＺＩＰ圧縮形式で圧縮されたデータの構成例を示す参考図である。

ＺＩＰ圧縮されたデータには、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ６０１やファイルデータ６０２と呼ばれるデータ部分が存在する。図示のように、ファイルデータ６０２の直前には、必ずＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ６０１が存在し、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ６０１とファイルデータ６０２の組によって伸張データの一つのファイルの情報が構成される。言い換えると、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ６０１とファイルデータ６０２の一組によって伸張データの一つのファイルを伸張することができる。以下、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ６０１とファイルデータ６０２の組み合わせをファイルデータ部と呼ぶ。伸張データに複数のファイルが存在する場合には、ファイルデータ部が複数組列挙される。

ＺＩＰ圧縮では、伸張データ時のディレクトリ構成を保持したままの圧縮が可能である。しかし、あるファイルが伸張データ時のディレクトリ構成では上位の階層に存在したとしても、圧縮データ時に当該ファイルを構成するファイルデータ部がデータの前方にあるとは限らない。言い換えると、伸張データ時のディレクトリ構成上の階層位置と圧縮データ時（データストリームにおける位置）のファイルデータ部の位置に関連性はない。

Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａでは、ＸＰＳを文書ファイルフォーマットとしてのみでなく印刷スプールファイルのフォーマットとして利用することができる。ＸＰＳプリントパスが使用される場合、通常ＯＳにより提供される印刷システムが自動で印刷スプールファイルをＸＰＳファイルフォーマットの形で生成するが、ユーザが任意のＸＰＳデータを作成してスプールすることも可能であり、後述するＭＸＤＷで作成されたＸＰＳデータをスプールすることも可能である。

また、ＸＰＳデータをプリントデータとして利用する場合、例えば、ＺＩＰ圧縮されたデータが情報処理装置からネットワークを介して印刷装置に送信される。なお、送信されるデータは全てが一括で送られるのではなく、幾つかに分割されて印刷装置に送られるのが一般的である。その後、印刷装置は、データを受信する処理を行った後、印刷処理を実施するために受信したデータ（ＸＰＳデータ）を解析する処理を行う。なお、印刷装置は、通常、データ受信処理と既に受信済みのＸＰＳデータの解析処理とを並行して行うことが可能である。

Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａの機能の一つとして、Ｍｉｃｒｏｓｏｆｔ ＸＰＳ Ｄｏｃｕｍｅｎｔ Ｗｒｉｔｅｒ（ＭＸＤＷ）なるＸＰＳファイルを生成するためのアプリケーションが存在する。ＭＸＤＷによってＸＰＳファイルが生成された場合、通常は、上述した＿ｒｅｌｓ／．ｒｅｌｓの情報を有するファイルデータ部、ＦＤＳの情報を有するファイルデータ部、ＦＤの情報を有するファイルデータ部、及びＦＰの情報を有するファイルデータ部のデータは各々、図８に示すように、ＦＰ８０２，８０３，８０５→ＦＤ８０４，８０６→ＦＤＳ８１０→＿ｒｅｌｓ／．ｒｅｌｓ８０１の順序に並んで構成される。以降、この順序をデータストリームにおけるデータ順と呼ぶ。

ＸＰＳをプリントデータとして利用する場合、前述した通り、ＸＰＳデータは幾つかに分割されて印刷装置に送信されるが、データ順に並んだＸＰＳデータは、送信開始後、ＦＰ、ＦＤ、ＦＤＳの情報を有するファイルデータ部が全て送信された後に、＿ｒｅｌｓ／．ｒｅｌｓの情報を有するファイルデータ部が印刷装置に送信される。前述した通り、＿ｒｅｌｓ／．ｒｅｌｓは文書の開始点となるパーツであるため、印刷装置は＿ｒｅｌｓ／．ｒｅｌｓの情報を有するファイルデータ部を受信するまでＸＰＳデータの解析を開始できない。その結果、印刷装置は、ＸＰＳデータの受信処理とＸＰＳデータの解析処理と並行して行うことができず、全体としての印刷スループットが低下してしまう。

仮に、ＸＰＳデータの先頭に＿ｒｅｌｓ／．ｒｅｌｓの情報を有するファイルデータ部があったとしても、次に参照すべきＦＤＳの情報を有するファイルデータ部がＸＰＳデータの最後尾等にあるようなデータ順であった場合には、印刷装置は当該ファイルデータ部を受信するまでＸＰＳデータの解析処理を中断せざるを得ず、同様に、全体としての印刷スループットが低下してしまう。

ＸＰＳには、一つのパーツを複数のパーツに分割するインタリーブと呼ばれる仕様が存在し、ＭＸＤＷの設定でインタリーブの仕様に則ったデータを作成することが可能である。この仕様に即したＸＰＳデータがピースデータである。ＸＰＳデータ内において、意味のある最小単位が「パーツ」であり、物理的なデータとしての最小単位が「ピース」である。

通常のＸＰＳデータをインタリーブの仕様に即したデータに変換することをインタリーブ化と呼び、インタリーブ化されたＸＰＳデータをインタリーブデータと呼ぶ。例えば、図６に示すＸＰＳデータを、図９に示すインタリーブデータのように、インタリーブ化することができる。図９のインタリーブデータでは、次のパーツへの参照が存在するところまでで各パーツが分割されている。インタリーブ化されたＸＰＳデータの構成例を図１０に示す。

図１０に示すＸＰＳデータでは、＿ｒｅｌｓ／．ｒｅｌｓは２個のパーツ８５１，８５２に分割され、ＦＤＳは３個のパーツ８５８，８５９，８６０に分割され、１個目のＦＤは３個のパーツ８５３，８５４，８５５に分割され、２個目のＦＤは２個のパーツ８５６，８５７に分割されている。

図９のように分割された各パーツを、図１１に示すように、各参照部の直後に参照先データが配置されるようなデータ順に並び替えることにより、印刷スループットが低下する問題を解決することが可能である。何故ならば、印刷装置は、解析すべきパーツの情報を有するファイルデータ部を順番に受信していくので、当該ファイルデータ部の受信後すぐに当該ファイルデータ部の解析処理を行うことが可能になるからである。

例えば、図１０では、２個に分割された＿ｒｅｌｓ／．ｒｅｌｓ（パーツ８５１，８５２）の１個目のパーツ８５１の情報を有するファイルデータ部を受信する。ここで、印刷装置は最初に当該パーツを解析する必要があるが、既に当該パーツの情報を有するファイルデータ部を受信済みであるため、すぐに当該パーツの解析を開始することができる。続いて、３個に分割されたＦＤＳの１個目のパーツ８５８の情報を有するファイルデータ部を受信する。ここで、印刷装置は次に当該パーツを解析する必要があるが、既に当該パーツの情報を有するファイルデータ部を受信済みであるため、すぐに当該パーツの解析を開始することができる。

続いて、３個に分割された１つ目のドキュメントの構成情報が記述されたＦＤの１個目のパーツ８５３の情報を有するファイルデータ部を受信する。ここで、印刷装置は次に当該パーツを解析する必要があるが、既に当該パーツの情報を有するファイルデータ部を受信済みであるため、すぐに当該パーツの解析を開始することができる。

続いて、１つ目のドキュメントの１ページ目のページ情報が記述されたＦＰ８６１の情報を有するファイルデータ部を受信する。ここで、印刷装置は次に当該パーツを解析する必要があるが、既に当該パーツの情報を有するファイルデータ部を受信済みであるため、すぐに当該パーツの解析を開始することができる。この結果、１つ目のドキュメントの１ページ目の印刷を行うことができる。

続いて、３個に分割された１つ目のドキュメントの構成情報が記述されたＦＤの２個目のパーツ８５４の情報を有するファイルデータ部を受信する。ここで、印刷装置は次に当該パーツを解析する必要があるが、既に当該パーツの情報を有するファイルデータ部を受信済みであるため、すぐに当該パーツの解析を開始することができる。

続いて、１つ目のドキュメントの２ページ目のページ情報が記述されたＦＰ８６２の情報を有するファイルデータ部を受信する。ここで、印刷装置は次に当該パーツを解析する必要があるが、既に当該パーツの情報を有するファイルデータ部を受信済みであるため、すぐに当該パーツの解析を開始することができる。この結果、１つ目のドキュメントの２ページ目の印刷を行うことができる。以降、同様に、ファイルデータ部を受信後すぐに当該パーツの解析ができるようになり、印刷スループットが低下する問題は解決される。

次に、ＸＰＳパーツ名が判明している場合、ＸＰＳからパーツデータを取得する方法について説明する。

Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒでは、その先頭データが“ＰＫ３４”というバイナリデータであり、その後、既定の位置にＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒと対になるファイルデータのデータ名とデータサイズが記述されている。そこで、“ＰＫ３４”というバイナリデータを先頭から順番に検索し、発見後規定の位置に存在するファイルデータ名を検索・取得・判定し、所望していたパーツデータでなければ、前記データサイズ分、後方に存在するＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒの“ＰＫ３４”というバイナリデータを再度前回検索した位置から開始する。目的のパーツデータを取得できるまで繰り返す。

ＺＩＰデータに含まれる内部データを効率よく検索する既存技術として、内部データの位置情報を示す管理ファイルを予め作成して、検索時にその管理ファイルを利用して検索処理を行うものが提案されている（例えば、特許文献１参照）。
特開特開２００６−８５５６９号公報

しかしながら、ＭＸＤＷで作成されたＸＰＳデータからパーツデータを取得する際、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒをデータの先頭から検索する方法では、ＸＰＳデータに含まれるパーツデータの数が増えるほど、入出力Ｉ／Ｏ回数が増大するため、処理に多くの時間を要する。

また、ＭＸＤＷでＸＰＳデータを作成する場合、インタリーブ化されたＸＰＳデータとインタリーブ化されていないＸＰＳデータとではＸＰＳデータ内部のデータ構造が違うため、そのデータ構造に則った検索を行わなければならない。

例えば、インタリーブ化されたＸＰＳデータでは、イメージファイル８０８を参照する箇所で分割することがある。同じイメージファイル８０８を参照している箇所が複数あった場合には、同じイメージファイルであるにも関わらず、繰り返しデータの先頭から検索してしまい、処理に多くの時間を要する。

さらに、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒをデータの先頭から検索して、処理すべきパーツか否かを判定して、処理すべきパーツでない場合には次のＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒを検索することを繰り返す。処理すべきパーツがあった場合には、再度Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒをデータの先頭から検索して、処理すべきパーツを取得して処理するため、所望のパーツを検索するために時間がかかり、印刷処理時間が増大することが発生してしまっていた。

そこで、本発明は、構造化文書形式のデータを受信しながら解析し、パーツデータを取得する際、当該データを繰り返し先頭から検索することなく、必要なパーツデータの取得時間を削減して、印刷処理時間を向上させることができる印刷制御装置及び印刷制御方法、並びにプログラムを提供することを目的とする。

上記目的を達成するために、請求項１記載の印刷制御装置は、文書データの開始点となる開始ファイル、前記文書データの構成情報が記述されたページ構成データのファイル、１ページの描画内容が記述された印刷対象データのファイル、及びリソースファイルがアーカイブされた構造化文書形式のデータを受け取る受取手段と、前記受取手段で上位処理から受け取る構造化文書形式のデータを、先頭から検索する第１の検索手段と、前記第１の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を記憶する第１の記憶手段と、次に処理する印刷対象データのファイルを検索するために、前記第１の検索手段で構造化文書形式のデータを先頭から検索することなく、前記第１の記憶手段に記憶されている配置位置から、前記受取手段で上位処理より受け取る構造化文書形式のデータを検索する第２の検索手段と、前記第２の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を更新する更新手段と、前記第２の検索手段による検索を、前記印刷対象データのファイルに応じて繰り返す繰返制御手段と、前記検索された印刷対象データを解析処理して得られる印刷描画データを出力する出力手段とを備えることを特徴とする。

上記目的を達成するために、請求項８記載の印刷制御装置の印刷制御方法は、文書データの開始点となる開始ファイル、前記文書データの構成情報が記述されたページ構成データのファイル、１ページの描画内容が記述された印刷対象データのファイル、及びリソースファイルがアーカイブされた構造化文書形式のデータを受け取る受取工程と、前記受取工程で上位処理から受け取る構造化文書形式のデータを、先頭から検索する第１の検索工程と、前記第１の検索工程の検索によって得られる前記印刷対象データのファイルの配置位置を記憶する第１の記憶工程と、次に処理する印刷対象データのファイルを検索するために、前記第１の検索工程で構造化文書形式のデータを先頭から検索することなく、前記第１の記憶工程で記憶された配置位置から、前記受取工程で上位処理より受け取る構造化文書形式のデータを検索する第２の検索工程と、前記第２の検索工程の検索によって得られる前記印刷対象データのファイルの配置位置を更新する更新工程と、前記第２の検索工程による検索を、前記印刷対象データのファイルに応じて繰り返す繰返制御工程と、前記検索された印刷対象データを解析処理して得られる印刷描画データを出力する出力工程とを備えることを特徴とする。

上記目的を達成するために、請求項９記載のプログラムは、印刷制御装置を、文書データの開始点となる開始ファイル、前記文書データの構成情報が記述されたページ構成データのファイル、１ページの描画内容が記述された印刷対象データのファイル、及びリソースファイルがアーカイブされた構造化文書形式のデータを受け取る受取手段と、前記受取手段で上位処理から受け取る構造化文書形式のデータを、先頭から検索する第１の検索手段と、記第１の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を記憶する第１の記憶手段と、次に処理する印刷対象データのファイルを検索するために、前記第１の検索手段で構造化文書形式のデータを先頭から検索することなく、前記第１の記憶手段に記憶されている配置位置から、前記受取手段で上位処理より受け取る構造化文書形式のデータを検索する第２の検索手段と、前記第２の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を更新する更新手段と、前記第２の検索手段による検索を、前記印刷対象データのファイルに応じて繰り返す繰返制御手段と、前記検索された印刷対象データを解析処理して得られる印刷描画データを出力する出力手段として機能させることを特徴とする。

本発明によれば、構造化文書形式のデータを受信しながら解析し、パーツデータを取得する際、当該データを繰り返し先頭から検索することなく、必要なパーツデータの取得時間を削減して、印刷処理時間を向上させることができる。

以下、本発明の実施の形態を図面を参照して詳細に説明する。

図１は、本発明の第１の実施形態に係る情報処理装置を含めた印刷システムの構成例を示すブロック図である。

図１において、本発明の実施形態における印刷システムは、情報処理装置としてのコンピュータ１０００と、印刷装置としてのプリンタ１５００とを備え、これらはネットワーク１２１を介して互い接続されている。

コンピュータ１０００は、ＣＰＵ１０１と、ＲＡＭ１０２と、ＲＯＭ１０３と、入力コントローラ（入力Ｃ）１０５と、ビデオコントローラ（ＶＣ）１０６と、メモリコントローラ（ＭＣ）１０７と、通信Ｉ／Ｆコントローラ（通信Ｉ／Ｆ Ｃ）１０８と、操作装置１０９と、表示装置１１０と、外部メモリ１１１とを備える。ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、入力コントローラ１０５、ビデオコントローラ１０６、メモリコントローラ１０７、及び通信Ｉ／Ｆコントローラ１０８は、システムバス１０４を介して互いに接続されている。

ＣＰＵ１０１は、後述する処理の実行に際して必要なプログラム等をＲＡＭ１０２にロードして、プログラムを実行することで各種動作を実現する。また、ＣＰＵ１０１は、例えば、ＲＡＭ１０２の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、表示装置１１０上での表示を可能としている。また、ＣＰＵ１０１は、表示装置１１０上の不図示のマウスカーソル等でのユーザによる指示を可能とする。

ＲＡＭ１０２は、ＣＰＵ１０１の主メモリ、ワークエリア等として機能する。ＲＯＭ１０３または外部メモリ１１１には、ＣＰＵ１０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、「ＯＳ」という。）、後述する各処理を実行するために必要な各種プログラム等が記憶されている。本実施の形態で使用するＯＳは、例えば、Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａ（Ｍｉｃｒｏｓｏｆｔ社製）を想定しているが、これに限られるものではない。

入力コントローラ１０５は、マウス等のポインティングデバイスやキーボードで構成される操作装置１０９からの入力を制御する。ビデオコントローラ１０６は、ＣＲＴディスプレイ等の表示装置１１０への表示を制御する。なお、表示装置１１０は、ＣＲＴに限られるものではなく、液晶ディスプレイでも構わない。

メモリコントローラ１０７は、外部メモリ１１１へのアクセスを制御する。外部メモリ１１１は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、及び各種データ等を記憶し、ハードディスク（ＨＤ）、フロッピー（登録商標）ディスク（ＦＤ）、またはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等から構成される。通信Ｉ／Ｆコントローラ１０８は、ネットワーク等を介した外部機器との接続・通信を制御する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信などにより、ネットワーク１２１を介してプリンタ１５００との間でデータ送受信等が可能である。なお、ネットワーク１２１はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であっても、インターネットであってもよく、またケーブル等で接続されたローカルなものであってもよい。

プリンタ１５００は、ＣＰＵ１１２、ＲＡＭ１１９、フォントＲＯＭ１１３ａと、プログラムＲＯＭ１１３ｂと、データＲＯＭ１１３ｃと、入力部１１８と、印刷部インターフェース（印刷部Ｉ／Ｆ）１１６と、印刷部（プリンタエンジン）１１７と、操作部１５０１と、メモリコントローラ（ＭＣ）１２０と、外部メモリ１１４とを備える。ＣＰＵ１１２、ＲＡＭ１１９、ＲＯＭ１１３、入力部１１８、印刷部Ｉ／Ｆ１１６、操作部１５０１と、ＭＣ１２０は、システムバス１１５を介して互いに接続されている。

ＣＰＵ１１２は、プログラムＲＯＭ１１３ｂまたは外部メモリ１１４に記憶された制御プログラム等に基づいて、印刷部Ｉ／Ｆ１１６を介して印刷部１１７に出力情報としての画像信号（描画データ）を出力する。プログラムＲＯＭ１１３ｂには、ＣＰＵ１１２により実行される制御プログラム等が記憶される。フォントＲＯＭ１１３ａには、上記出力情報を生成する際に使用するフォントデータ等が記憶される。データＲＯＭ１１３ｃには、プリンタ１５００がハードディスク等の外部メモリ１１４を有していない場合には、コンピュータ１０００上で利用される情報等が記憶される。

ＣＰＵ１１２は、入力部１１８を介してコンピュータ１０００との通信処理を行い、プリンタ１５００内の情報等をコンピュータ１０００に通知することができる。ＲＡＭ１１９は、ＣＰＵ１１２の主メモリであり、ワークエリア等として機能する。また、ＲＡＭ１１９は、不図示の増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。なお、ＲＡＭ１１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等にも用いられる。

メモリコントローラ１２０は、外部メモリ１１４へのアクセスを制御する。外部メモリ１１４は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶し、ハードディスク（ＨＤ）、ＩＣカード等で構成される。

操作部１５０１は、操作のためのスイッチやＬＥＤ等が配されている操作パネルである。なお、プリンタ１５００が備える外部メモリ１１４は、１個に限られるものではなく、複数であってもよい。また、プリンタ１５００は、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。さらに、プリンタ１５００は、操作部１５０１により設定されたプリンタモード設定情報を記憶するＮＶＲＡＭ（不図示）を有していてもよい。

本実施の形態では、プリンタ１５００がサポートするプリントデータは、上述したＸＰＳデータを想定しているが、これに限定されるものではなく、同様のＸＭＬ形式のファイルフォーマットを有するデータであってもよい。

本発明を実現するための印刷機器制御プログラム（以下、「プリンタドライバ」という。）は外部メモリ１１１に記録されており、必要に応じてＲＡＭ１０２にロードされることによりＣＰＵ１０１によって実行される。プリンタドライバが用いる定義ファイル及び各種情報テーブルは外部メモリ１１１に格納されている。

なお、上記印刷システムの構成は一例であり、用途や目的に応じて様々な構成例があることは云うまでもない。例えば、本発明の機能が実現されるのであれば、単体の機器に適用されてもよく、ＬＡＮ、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワークを介して接続された複数の機器からなるシステムに適用されてもよい。

図２は、図１のコンピュータ１０００での印刷制御処理時に機能するソフトウェアの構成を示すブロック図である。

図２において、コンピュータ１０００は、アプリケーションプログラム（以下、「アプリケーション」という。）２０１と、グラフィックスエンジン２０２と、プリンタドライバ２０３と、プリントサブシステム２０４とを備える。これらは、それぞれ外部メモリ１１１にファイルとして保存されたプログラムモジュールである。これらのモジュールは、ＯＳやそのモジュールを利用するモジュールによってＲＡＭ１０２にロードされて実行される。

アプリケーション２０１及びプリンタドライバ２０３は、外部メモリ１１１から、または後述する図３のネットワーク３０１を介して接続された外部機器から、ハードディスク（ＨＤ）等の外部メモリ１１１に追加可能になっている。外部メモリ１１１に保存されているアプリケーション２０１は、ＣＰＵ１０１によってＲＡＭ１０２にロードされて実行される。このアプリケーション２０１からプリンタ１５００に対して印刷を行わせる際には、同様にＣＰＵ１０１によってＲＡＭ１０２にロードされて実行されるグラフィックスエンジン２０２を利用して出力（描画）を行う。

グラフィックスエンジン２０２は、プリンタ毎に用意されたプリンタドライバ２０３を起動する。これにより、プリンタドライバ２０３は、ＣＰＵ１０１によって外部メモリ１１１からＲＡＭ１０２にロードさせて実行される。グラフィックスエンジン２０２は、このプリンタドライバ２０３を用いて、アプリケーション２０１から出力された印字命令や描画命令をプリンタに適するプリンタ制御命令に変換する。

プリンタドライバ２０３により変換されたプリンタ制御コマンドは、プリントサブシステム２０４を経由して、ネットワーク１２１を介してプリンタ１５００に出力される。プリントサブシステム２０４は、ＯＳによって起動されて、ＣＰＵ１０１によって外部メモリ１１１からＲＡＭ１０２にロードされて実行されるものであり、印刷ジョブのスケジューリング、コンピュータ１０００とプリンタ１５００との接続制御、及びプリンタ１５００のステータスの管理を行う。

なお、プリンタドライバ２０３は、前述した、アプリケーション２０１から出力された印字命令や描画命令をプリンタ制御コマンドに変換し、プリント出力に反映されるようプリンタ１５００に指示する機能に加えて、プリンタドライバ２０３やプリンタ１５００が有する機能を制御するための設定を行う機能（以下、「ユーザインターフェース（ＵＩ）」という。）、その設定を記憶する機能、プリンタドライバ２０３やプリンタ１５００が有する機能の情報をアプリケーション２０１やＯＳに提供する機能、ＵＩで設定された機能がプリンタの有する機能である場合にプリンタ制御命令を生成する機能、及び、ＵＩで設定された機能がプリンタドライバ２０３独自で行う機能の場合にその機能を実現する機能等を有する。

図３は、図１のコンピュータ１０００及びプリンタ１５００を利用した印刷システムの一例を示すブロック図である。

図３において、印刷システムは、クライアントコンピュータとしての複数のコンピュータ１０００と、プリンタ１５００と、プリントサーバコンピュータ４０００とを有し、これらがネットワーク３０１を介して互いに接続されている。コンピュータ１０００内の通信Ｉ／Ｆコントローラ１０８は、ネットワークインターフェースカード（ＮＩＣ）の機能を有するものとする。

プリンタ１５００は、セントロニクスやＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のローカルインターフェース３０２を介してプリントサーバコンピュータ４０００と接続され、該プリントサーバコンピュータ４０００を介してネットワーク３０１に接続される形態であってもよく、ネットワーク３０１に直接接続される形態であってもよい。なお、ネットワーク３０１に直接接続されたプリンタ１５００内の入力部１１８は、ネットワークインターフェースカード（ＮＩＣ）の機能を有するものとする。

コンピュータ１０００は、プリントサーバコンピュータ４０００を介してネットワーク３０１に接続されたプリンタ１５００に印刷ジョブを送信する場合、まず、プリントサブシステム２０４を介して、プリントサーバコンピュータ４０００へ印刷ジョブを送信する。そして、プリントサーバコンピュータ４０００は、コンピュータ１０００から送信されてきた印刷ジョブを、プリントサーバコンピュータ４０００上の不図示のプリントサブシステムを介して、プリンタ１５００へ送信する。

また、コンピュータ１０００は、ネットワーク３０１に直接接続されたプリンタ１５００に印刷ジョブを送信する場合、プリントサブシステム２０４を介して、プリンタ１５００に直接印刷ジョブを送信する。

次に、図１２を用いて、ＧＤＩプリントパスに従って機能するコンピュータ１０００について説明する。

図１２は、コンピュータ１０００での印刷制御処理時に、図２でＧＤＩプリントパスを用いて機能する機能部の構成を示す図である。なお、ＧＤＩプリントパスの場合、図２のプリンタドライバ２０３が図１２のプリンタグラフィックスドライバ４０６に対応する。

図１２において、ＧＤＩプリントパスに従って機能するコンピュータ１０００の機能部は、アプリケーション２０１、ＧＤＩ４０１、ユーザインターフェースドライバ４０２、スプーラ４０３、ＥＭＦスプールファイル４０４、プリントプロセッサ４０５、プリンタグラフィックスドライバ４０６、及びランゲージモニタ４０７で構成される。

まず、図１２に示す各機能部の印刷制御機能について説明する。

アプリケーション２０１は、ＧＤＩ４０１を介して、プリンタ１５００に対して印刷条件を設定する。具体的には、アプリケーション２０１は、例えば、印刷に使用する用紙のサイズや逆順で印刷するか否かの設定や製本の体裁で印刷を行う製本印刷を実施するか否かの設定などの各種印刷条件を設定する。また、アプリケーション２０１は、ＧＤＩ４０１を介して、プリンタ１５００に対して文書や写真画像等の描画命令を発行し、印刷実行を指示する。以下、図１２の説明において、描画命令の発行に伴いＧＤＩ４０１を介してスプーラ４０３に通知される文書、画像データ、及び描画命令を総称して「印刷データ」と呼ぶ。

ユーザインターフェースドライバ４０２は、ＧＤＩ４０１を介して通知された印刷条件をプリンタ１５００に適合する内容に変更し、最終的な印刷条件を確定する。また、ユーザインターフェースドライバ４０２は、ＧＤＩ４０１を介して、最終的に確定した印刷条件をスプーラ４０３に通知する。

スプーラ４０３は、ＧＤＩ４０１を介して通知された印刷データ及び印刷条件をＥＭＦスプールファイル４０４に格納する。プリントプロセッサ４０５は、ＥＭＦスプールファイル４０４に格納された印刷データを１ページ単位で処理する。プリンタグラフィックスドライバ４０６は、印刷データをプリンタ１５００で印刷出力可能なＰＤＬデータに変換する。ランゲージモニタ４０７は、プリンタ１５００と双方向の通信を行い、プリンタ１５００の情報を取得して表示装置１１０に表示する。また、ランゲージモニタ４０７は、プリンタグラフィックスドライバ４０６が生成したＰＤＬデータをプリンタ１５００に供給する。なお、ランゲージモニタ４０７は、プリンタ１５００が備えるメモリ容量やエンジンコントローラの構成により異なる転送方法を採用することができる。

次に、ＧＤＩプリントパスにおける印刷制御機能の一連の動作について説明する。

まず、アプリケーション２０１は、ユーザからの操作指示に従って、印刷条件の設定、任意の文書または写真画像等の印刷実行の指示を行う。このようにしてＧＤＩ４０１は、アプリケーション２０１から印刷実行の指示を受け付けると、ユーザインターフェースドライバ４０２に対して、プリンタ１５００での印刷条件の設定内容及び印刷開始のイベントを通知する。

ユーザインターフェースドライバ４０２は、プリンタ１５００での印刷条件の設定内容の通知を受けると、通知された印刷条件の設定内容を参照し、プリンタ１５００にて印刷出力可能な設定内容になっているか否かを判断する。ここで、通知された印刷条件の設定内容が、プリンタ１５００にて印刷出力可能な設定内容になっていないと判断した場合には、ユーザインターフェースドライバ４０２は、プリンタ１５００にて印刷出力可能な設定内容になるように、印刷条件の設定内容を一部更新して印刷条件を確定する。

続いて、アプリケーション２０１は、ＧＤＩ４０１を介して、文書・画像データの描画命令を発行する。スプーラ４０３は、アプリケーション２０１における描画命令の発行に伴って生成された印刷データ及びユーザインターフェースドライバ４０２が確定した印刷条件の通知を受けると、通知された印刷データ及び印刷条件をＥＭＦスプールファイル４０４に格納する。

プリントプロセッサ４０５は、ＥＭＦスプールファイル４０４から印刷条件の設定内容及び印刷データを取得する。続いて、プリントプロセッサ４０５は、ＧＤＩ４０１を介して、当該印刷条件の設定内容及び印刷データを１ページ単位でプリンタグラフィックスドライバ４０６に供給する。

ＧＤＩ４０１は、プリントプロセッサ４０５からプリンタグラフィックスドライバ４０６に印刷データを供給する際に、印刷データに含まれる描画命令をグラフィックス描画コマンドに変換する。プリンタグラフィックスドライバ４０６は、ＧＤＩ４０１により生成されたグラフィックス描画コマンド及びＧＤＩ４０１から通知された印刷条件の設定内容に基づいて、プリントプロセッサ４０５から供給された印刷データからプリンタ１５００が解釈できるＰＤＬデータを生成する。ランゲージモニタ４０７は、コンピュータ１０００からプリンタ１５００にＰＤＬデータを伝送するために使用されるインターフェースを経由して、プリンタグラフィックスドライバ４０６により供給されたＰＤＬデータをプリンタ１５００に供給する。プリンタ１５００は、ランゲージモニタ４０７から供給されたＰＤＬデータを解釈し、印刷画像データを用紙上に印刷出力する。

次に、図１３を用いて、ＸＰＳプリントパスに従って機能するコンピュータ１０００について説明する。

図１３は、コンピュータ１０００での印刷制御処理時に、図２でＸＰＳプリントパスを用いて機能する機能部の構成を示す図である。なお、ＸＰＳプリントパスの場合、図２のプリンタドライバ２０３が図１３のユーザインターフェースドライバ４０２と、レイアウトフィルタ４１１と、レンダリングフィルタ４１２とを備えるプリンタドライバに対応する。

図１３において、ＸＰＳプリントパスに従って機能するコンピュータ１０００の機能部は、アプリケーション２０１、Ｗｉｎｄｏｗｓ（登録商標） Ｐｒｅｓｅｎｔａｔｉｏｎ Ｆｏｕｎｄａｔｉｏｎ（以下、「ＷＰＦ」と略する。）印刷サポート４０８、ユーザインターフェースドライバ４０２、スプーラ４０３、ＸＰＳスプールファイル４０９、フィルタパイプラインマネージャ４１０、レイアウトフィルタ４１１、レンダリングフィルタ４１２、及びランゲージモニタ４０７で構成される。なお、レンダリングフィルタ４１２は、プリンタ１５００側に構成されていてもよい。レンダリングフィルタ４１２を備えるプリンタドライバ或いはレンダリングフィルタ４１２を備えるプリンタを印刷制御装置と言い換えることが可能である。

まず、図１３に示す各機能部の印刷制御機能について説明する。

アプリケーション２０１は、ＷＰＦ印刷サポート４０８を介して、ＸＰＳデータを作成する。また、アプリケーション２０１は、文書や写真画像等のドキュメント、印刷条件、描画命令をＸＰＳデータに対して設定する。以下、ＸＰＳデータに含まれている文書や写真画像等のドキュメント、及び描画命令を総称して「印刷データ」と呼ぶ。さらに、アプリケーション２０１は、ＷＰＦ印刷サポート４０８を介して、印刷実行を指示する。

ＷＰＦ印刷サポート４０８は、アプリケーション２０１の指示を受けてＸＰＳデータを構成する。また、ＷＰＦ印刷サポート４０８は、ＸＰＳデータから印刷条件の設定内容を取り出してユーザインターフェースドライバ４０２に通知する。また、ＷＰＦ印刷サポート４０８は、ユーザインターフェースドライバ４０２が確定した印刷条件の設定内容をＸＰＳデータに設定する。さらに、ＷＰＦ印刷サポート４０８は、ＸＰＳデータをスプーラ４０３に通知する。

ユーザインターフェースドライバ４０２は、ＷＰＦ印刷サポート４０８から通知された印刷条件をプリンタ１５００に適合する内容に変更し、最終的な印刷条件を確定する。また、ユーザインターフェースドライバ４０２は、最終的に確定した印刷条件をＷＰＦ印刷サポート４０８に通知する。

スプーラ４０３は、ＷＰＦ印刷サポート４０８から通知されたＸＰＳデータをＸＰＳスプールファイル４０９に格納する。フィルタパイプラインマネージャ４１０は、レイアウトフィルタ４１１及びレンダリングフィルタ４１２を介して、ＸＰＳスプールファイル４０９に格納されたＸＰＳデータをプリンタ１５００で印刷出力可能なＰＤＬデータに変換し、該ＰＤＬデータをプリンタ１５００に供給する。なお、ＸＰＳデータをプリンタ１５００で解釈可能な場合、ＰＤＬデータに変換することをせずにプリンタ１５００にＸＰＳデータを供給することができる。

レイアウトフィルタ４１１は、ＸＰＳデータ内の印刷データやページ構成を編集する。また、レンダリングフィルタ４１２は、レイアウトフィルタ４１１により編集されたＸＰＳデータ内の印刷データをプリンタ１５００で印刷出力可能なＰＤＬデータに変換する。

ランゲージモニタ４０７は、プリンタ１５００と双方向の通信を行い、プリンタ１５００の情報を取得し表示装置１１０に表示する。また、ランゲージモニタ４０７は、フィルタパイプラインマネージャ４１０から通知されたＰＤＬデータをプリンタ１５００に供給する。なお、ランゲージモニタ４０７は、プリンタ１５００が備えるメモリ容量や、エンジンコントローラの構成により異なる転送方法を採用することができる。

ＯＳは、スプーラ４０３、ＷＰＦ印刷サポート４０８、及びフィルタパイプラインマネージャ４１０の機能を提供する。本発明を有するモジュールは、レンダリングフィルタ４１２に含まれる。

ＸＰＳデータには、イメージファイルやフォントファイル等のリソースファイルの他に、以下のような複数種類のパーツが包含され、各々が以下のような参照を有する。

ａ）＿ｒｅｌｓ／．ｒｅｌｓ：文書データとしてのＸＰＳデータの開始点となるパーツ（開始ファイル）である。ＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅ（以下、「ＦＤＳ」と略す。）への参照を有する。

ｂ）ＦＤＳ：一つの文書データの構成情報が記述されたパーツである。ＦｉｘｅｄＤｏｃｕｍｅｎｔ（以下、「ＦＤ」と略す。）への参照を有する。なお、一つのデータは複数のドキュメントを有する場合がある。つまり、ＦＤＳは、複数のＦＤへの参照を有する場合がある。

ｃ）ＦＤ：一つのドキュメントに存在する複数のページをページ順に並べて束ねるためのパーツ（ページ構成データのファイル）である。一つのドキュメントの構成情報が記述されたパーツであり、ＦｉｘｅｄＰａｇｅ（以下、「ＦＰ」と略す。）への参照を有する。なお、一つのドキュメントは複数のページを有する場合がある。つまり、ＦＤは、複数のＦＰへの参照を有する場合がある。

ｄ）ＦＰ：印刷対象となる１ページの描画内容が記述されたパーツ（印刷対象データのファイル）である。ＦＰパーツは、必要に応じて、イメージファイルやフォントファイルへの参照を有する場合がある。例えば、当該ページにイメージの描画が存在する場合は、当該イメージファイルへの参照を有することになる。

次に、ＸＰＳプリントパスにおける印刷制御機能の一連の動作について説明する。

まず、アプリケーション２０１は、ユーザからの操作指示に従って、任意の文書または写真画像等のドキュメントを読み込む。なお、任意の文書には、予め作成されていたＸＰＳデータも含まれる。続いて、アプリケーション２０１は、ユーザからの操作指示に従って、ＸＰＳデータの作成を行い、文書や写真画像等のドキュメント、印刷条件、描画命令をＸＰＳデータに設定する。なお、予め作成されていたＸＰＳデータを読み込んだ場合には、新たにＸＰＳデータを作成することはなく、アプリケーション２０１は、読み込んだＸＰＳデータに含まれる印刷条件や描画命令をユーザからの操作指示に従って編集すればよい。

ＸＰＳプリントパスでは、予め定義されたＸＭＬスキーマの形式に従って記述されたＸＭＬファイルを用いて印刷条件の設定が行われる。印刷設定を行うために予め定義されたＸＭＬスキーマの形式を「プリントスキーマ」と呼び、印刷スキーマに従って印刷条件が記述されているＸＭＬファイルを「プリントチケット」と呼ぶ。プリントチケットはそのままの形式でＸＰＳデータに含まれることになる。

続いて、アプリケーション２０１は、ユーザからの操作指示に従って、ＸＰＳデータを用いて印刷実行の指示を行う。ＷＰＦ印刷サポート４０８は、アプリケーション２０１から印刷実行の指示を受け付けると、ＸＰＳデータ内のプリントチケットを取り出し、印刷条件の設定内容として当該プリントチケットをユーザインターフェースドライバ４０２に通知する。

ユーザインターフェースドライバ４０２は、プリンタ１５００での印刷条件の設定内容の通知を受けると、通知された印刷条件の設定内容を参照し、プリンタ１５００にて印刷出力可能な設定内容になっているか否かを判断する。通知された印刷条件の設定内容が、プリンタ１５００にて印刷出力可能な設定内容になっていないと判断した場合、ユーザインターフェースドライバ４０２は、プリンタ１５００にて印刷出力可能な設定内容になるように、印刷条件の設定内容を一部更新し、印刷条件を確定する。続いて、ユーザインターフェースドライバ４０２は、確定した印刷条件によりプリントチケットを更新し、ＷＰＦ印刷サポート４０８に通知する。ＷＰＦ印刷サポート４０８は、ユーザインターフェースドライバ４０２から通知されたプリントチケットをＸＰＳデータに設定し、当該ＸＰＳデータをスプーラ４０３に通知する。

スプーラ４０３は、ＷＰＦ印刷サポート４０８からＸＰＳデータの通知を受けると、通知されたＸＰＳデータをＸＰＳスプールファイル４０９に格納する。なお、ＷＰＦ印刷サポート４０８を介さず、アプリケーション２０１からスプーラ４０３に任意のＸＰＳデータを通知することも可能である。つまり、ＭＸＤＷで作成したＸＰＳデータを通知することも可能である。続いて、スプーラ４０３は、フィルタパイプラインマネージャ４１０に対して印刷開始のイベントを通知する。

フィルタパイプラインマネージャ４１０は、スプーラ４０３から印刷開始のイベントの通知を受けると、ＸＰＳスプールファイル４０９に格納されているＸＰＳデータを取得し、当該ＸＰＳデータをレイアウトフィルタ４１１に通知する。

レイアウトフィルタ４１１は、通知されたＸＰＳデータから印刷データ、及びプリントチケットを取得する。続いて、レイアウトフィルタ４１１は、プリントチケットに記載されている印刷条件の設定内容に基づいて、印刷データの編集、及びＸＰＳデータのページ構成の編集を行う。なお、印刷データやページ構成の編集内容には、ビットマップの合成（ウォーターマーク）、ページ合成（割付）、ページ順序の変更（逆順）等が含まれる。

続いて、レイアウトフィルタ４１１は、印刷データやページ構成の編集を終えた後のＸＰＳデータをフィルタパイプラインマネージャ４１０に通知する。フィルタパイプラインマネージャ４１０は、レイアウトフィルタ４１１から通知されたＸＰＳデータをレンダリングフィルタ４１２に通知する。

レンダリングフィルタ４１２は、通知されたＸＰＳデータから印刷データ、及びプリントチケットを取得する。続いて、レンダリングフィルタ４１２は、プリントチケットに記載されている印刷条件の設定内容に基づいて、印刷データからプリンタ１５００が解釈できるＰＤＬデータを生成し、該ＰＤＬデータをフィルタパイプラインマネージャ４１０に通知する。

フィルタパイプラインマネージャ４１０は、レンダリングフィルタ４１２から通知されたＰＤＬデータをランゲージモニタ４０７に供給する。ランゲージモニタ４０７は、コンピュータ１０００からプリンタ１５００にＰＤＬデータを伝送するために使用されるインターフェースを経由して、フィルタパイプラインマネージャ４１０により供給されたＰＤＬデータをプリンタ１５００に供給する。プリンタ１５００は、ランゲージモニタ４０７から供給されたＰＤＬデータを解釈し、印刷画像データを用紙上に印刷出力する。

本発明は、特に、ＭＸＤＷでＸＰＳデータを作成する際に、図３１に示すように、インタリーブ設定がＯＮまたはＯＦＦにかかわらず、ＭＸＤＷ作成されたＸＰＳデータをレンダリングフィルタ４１２でＰＤＬデータを作成する際、ＸＰＳデータ内のパーツデータを検索するのに有効である。
次に、上述したＸＰＳプリントパスにおける印刷制御機能の中で、レイアウトフィルタ４１１が行う処理について説明する。

図３３は、レイアウトフィルタ４１１により実行されるＸＰＳデータ内のパーツのインタリーブ化処理を示すフローチャートである。なお、インタリーブ化すると、ＸＰＳデータ内のパーツを、例えば、印刷処理順に並べることができる。

レイアウトフィルタ４１１は、まず、ユーザインターフェースドライバ４０２でユーザの操作によって、印刷するデータをインタリーブするか否かの指定を判定する（ステップＳ２４００）。言い換えると、インタリーブ化するか否かを決定する処理である。

インタリーブをする指定がなかった場合、インタリーブ処理を行わず、本処理を終了とする。一方、インタリーブをする指定があった場合、インタリーブをするために、パーツを取得する（ステップＳ２４０１）。初めに取得するパーツは、＿ｒｅｌｓ／．ｒｅｌｓである。次に、本パーツが既にインタリーブ化されているかを判断する（ステップＳ２４０２）。パーツがインタリーブ化されているか否かは、＿ｒｅｌｓ／．ｒｅｌｓが一つのファイルである構成であるか、若しくは＿ｒｅｌｓ／．ｒｅｌｓはディレクトリであり、本ディレクトリ内にファイルを有する構成であるかによって判断され得る。

ステップＳ２４０２の判断の結果、取得したパーツがインタリーブ化されていない場合は、レイアウトフィルタ４１１は、本パーツがＸＭＬデータであるかを判断する（ステップＳ２４０３）。本パーツがＸＭＬデータである場合は、レイアウトフィルタ４１１は、本パーツがプリントチケットまたはＦＰパーツであるかを判断する（ステップＳ２４０４）。本パーツがプリントチケットまたはＦＰパーツでない場合は、レイアウトフィルタ４１１は、後述するインタリーブ化（分割）処理を実施する（ステップＳ２４０５）。

レイアウトフィルタ４１１は、取得したパーツが既にインタリーブ化（分割）されていると判断した場合（ステップＳ２４０２でＹＥＳ）、該パーツがＸＭＬデータでないと判断した場合（ステップＳ２４０３でＮＯ）、該パーツがプリントチケット、またはＦＰパーツであると判断した場合（ステップＳ２４０４でＹＥＳ）には、取得したパーツがインタリーブ化を行う必要がないことを意味するため、ステップＳ２４０５のインタリーブ化（分割）処理を実施しない。

次に、レイアウトフィルタ４１１は、ステップＳ２４０１〜Ｓ２４０５の処理を全てのパーツに対して実施したかを判断する（ステップＳ２４０６）。全てのパーツに対して当該処理を実施していないと判断した場合には、レイアウトフィルタ４１１は、当該パーツから他のパーツへの参照タグを検索し、検索されたパーツに対してステップＳ２４０１〜Ｓ２４０５を実施する。一方、全てのパーツに対して当該処理を実施済みと判断した場合には、インタリーブ化されていないパーツをインタリーブ化する処理を終了する。

次に、図３４を用いて、図３３のステップＳ２４０５におけるインタリーブ化処理の詳細を説明する。本処理では、他のパーツへの参照タグを有するパーツデータが、他のパーツへの参照タグを有するタグに分割され、当該パーツがインタリーブ化される。

図３４は、図３３のステップＳ２４０５におけるインタリーブ化処理の詳細を示すフローチャートである。

レイアウトフィルタ４１１は、まず、パーツデータを取得する（ステップＳ２５０１）。次に、レイアウトフィルタ４１１は、タグの検索処理の開始位置をパーツの先頭に設定する（ステップＳ２５０２）。次に、レイアウトフィルタ４１１は、当該パーツの記述内容より、他のパーツへの参照タグを検索する（ステップＳ２５０３）。次に、レイアウトフィルタ４１１は、ステップＳ２５０３で他のパーツへの参照タグが見付かったかを判断する（ステップＳ２５０４）。

ステップＳ２５０４において、他のパーツへの参照タグが見付かったと判断した場合、レイアウトフィルタ４１１は、当該パーツと同一の階層に新規ディレクトリを追加する（ステップＳ２５０５）。なお、本ディレクトリの名称を当該パーツと同一にする。一方、ステップＳ２５０４において、他のパーツへの参照タグが見付からなかったと判断した場合、レイアウトフィルタ４１１は、インタリーブ化する必要がないパーツであることを意味するため、ステップＳ２５０５〜Ｓ２５１４の処理を実施せず、本処理を終了する。

次に、レイアウトフィルタ４１１は、ステップＳ２５０５で追加した新規ディレクトリ以下にパーツを追加する（ステップＳ２５０６）。なお、追加するファイルの名称を「［ｓ］．ｐｉｅｃｅ」とする。ここで、“ｓ”は１０進数の数値であり、当該ディレクトリ以下に追加したファイルに、０から順に１を加算した値を割り振る。Ｓは、レイアウトフィルタ４１１が管理するＲＡＭ１０２に確保されたメモリ領域に保持される。

次に、レイアウトフィルタ４１１は、ステップＳ２５０２で設定したタグ検索開始位置からステップＳ２５０３で検索した他のパーツへの参照タグの間に存在する記述内容を、ステップＳ２５０６で追加したパーツに書き出す（ステップＳ２５０７）。次に、レイアウトフィルタ４１１は、タグ検索開始位置をステップＳ２５０３で検索した他のパーツへの参照タグの終端の位置に移動する（ステップＳ２５０８）。次に、レイアウトフィルタ４１１は、ステップＳ２５０６と同様に、ステップＳ２５０５で追加した新規ディレクトリ以下にパーツを追加する（ステップＳ２５０９）。なお、本ファイルの名称の決定方法もステップＳ２５０６と同様とする。

次に、レイアウトフィルタ４１１は、ステップＳ２５０３と同様に、当該パーツの記述内容より、他のパーツへの参照タグを検索する（ステップＳ２５１０）。次に、レイアウトフィルタ４１１は、ステップＳ２５０４と同様に、ステップＳ２５１０で他のパーツへの参照タグが見付かったかを判断する（ステップＳ２５１１）。

ステップＳ２５１１において、他のパーツへの参照タグが見付かったと判断した場合、ステップＳ２５０７と同様に、レイアウトフィルタ４１１は、ステップＳ２５０８で移動したタグ検索開始位置からステップＳ２５１０で検索した他のパーツへの参照タグの間に存在する記述内容を、ステップＳ２５０９で追加したパーツに書き出す（ステップＳ２５１４）。続いて、ステップＳ２５０８〜Ｓ２５１１を繰り返す。

一方、ステップＳ２５１１の判断の結果、他のパーツへの参照タグが見付からなかったと判断した場合、レイアウトフィルタ４１１は、ステップＳ２５０８で移動したタグ検索開始位置から当該パーツデータの終端までの間に存在する記述内容を、ステップＳ２５０９で追加したパーツに書き出す（ステップＳ２５１２）。続いて、レイアウトフィルタ４１１は、元のパーツデータを削除して（ステップＳ２５１３）、リターンする。

上述したインタリーブ化（分割）処理を図３５のようなインタリーブされていないデータに対して実施すると、図３６のように分割される。

次に、上述したＸＰＳプリントパスにおける印刷制御機能の中で、レンダリングフィルタ４１２が行う処理について説明する。

図１４は、レンダリングフィルタ４１２により実行されるＸＰＳデータの解析処理を示すフローチャートである。

前述の通り、フィルタパイプラインマネージャ４１０は、スプーラ４０３から印刷開始のイベントの通知を受けると、ＸＰＳスプールファイル４０９に格納されているＭＸＤＷで作成されたＸＰＳデータを取得し、当該ＸＰＳデータをレイアウトフィルタ４１１に通知する。レイアウトフィルタ４１１は、プリントチケットに記載されている印刷条件の設定内容に基づいて、印刷データの編集及びＸＰＳデータのページ構成の編集を行い、編集を終えた後のＸＰＳデータをフィルタパイプラインマネージャ４１０に通知する。フィルタパイプラインマネージャ４１０は、レイアウトフィルタ４１１から通知されたＸＰＳデータをレンダリングフィルタ４１２に通知する。レンダリングフィルタ４１２はフィルタパイプラインマネージャ４１０から通知を受け取ると、図２８に示すジョブ情報管理テーブル２８００を当該レンダリングフィルタ４１２が管理するＲＡＭ１０２内のメモリ領域に作成して保持する（ステップＳ１００１）。

ここで、ジョブ情報管理テーブル２８００を構成する項目の内容について図２８及び図２９を参照して説明する。

図２８はジョブ情報管理テーブル２８００の構成を示す図であり、図２９は、ジョブ情報管理テーブル２８００におけるイメージ位置リストのデータ構造を示す図である。

図２８において、インタリーブ２８０１は、処理対象のＸＰＳデータがインタリーブ化（分割）されているか否かを示す情報が格納される。すなわち、ＸＰＳデータがインタリーブ化（分割）されている場合には、インタリーブ２８０１に“ＯＮ”が格納され、インタリーブ化されていない場合にはインタリーブ２８０１に“ＯＦＦ”が格納されている。

イメージ配置方法２８０２は、イメージファイルとしてのイメージパーツがどこに配置されるかを示す情報（配置情報）が格納される。すなわち、イメージ配置方法２８０２に格納される情報としては、“ページの前”若しくは“ページの後”である。フォント配置方法２８０３は、イメージ配置方法２８０２と同様に、フォントファイルとしてのフォントパーツがどこに配置されるかを示す情報が格納される。すなわち、フォント配置方法２８０３に格納される情報としては、“ページの前”若しくは“ページの後”である。

イメージ位置リスト最初のデータへのポインタ２８０４は、図２９に示す、全ての処理済みのイメージパーツのＸＰＳデータ内での位置を記録したリスト（イメージ位置リスト）への最初のデータへのポインタ（配置位置）が格納される。イメージ位置リスト最後のデータへのポインタ２８０５は、図２９に示す、全ての処理済みのイメージパーツのＸＰＳデータ内での位置を記録したリスト（イメージ位置リスト）への最後のデータへのポインタ（配置位置）が格納される。

フォント位置リスト最初のデータへのポインタ２８０６及びフォント位置リスト最後のデータへのポインタ２８０７は、イメージ位置リスト最初／最後のデータへのポインタ２８０４，２８０５と同様である。

図１４に戻り、ステップＳ１００２において、レンダリングフィルタ４１２は、図３０に示す処理中ページ情報管理テーブル３０００をレンダリングフィルタ４１２が管理するＲＡＭ１０２内にメモリ領域に作成して保持する。処理中ページ情報管理テーブル３０００を構成する項目の内容を図３０に示す。

図３０は、処理中ページ情報管理テーブル３０００の構成を示す図である。

図３０において、ドキュメント位置３００１は、処理中ＦＰパーツのパスが記述されているＦＤパーツ（またはピース）のＸＰＳデータの先頭からの位置（バイト単位、配置位置）が格納される。インタリーブ化されていないＸＰＳデータを処理するのであれば、ここに入力される値は一つのドキュメントの処理が終わるまで一定である。これは、ＦＤパーツがＦＤピースにインタリーブされないためである。なお、ドキュメント位置３００１は、ＸＰＳデータの先頭からの位置（バイト単位、配置位置）以外に、ＲＡＭ１０２内に記憶されているアドレスを用いてもよい。

ページ位置３００２は、ＦＰパーツのＸＰＳデータの先頭からの位置（バイト単位、配置位置）が格納される。なお、ページ位置３００２は、ＦＰパーツを検索するたびに更新されるものである。前ページ位置３００３は、現在処理しているＦＰパーツの前に処理していたＦＰパーツのＸＰＳデータの先頭からのページ位置（バイト単位、配置位置）が格納される。この項目（前ページ位置３００３）はインタリーブ化されていないＸＰＳデータにのみ使用される。なお、ページ位置３００２、前ページ位置３００３は、ドキュメント位置３００１と同様に、ＲＡＭ１０２内に記憶されているアドレスを用いてもよい。

図１４に戻り、ステップＳ１００３では、レンダリングフィルタ４１２は、ＺＩＰ圧縮されたＸＰＳデータを取得する。続いて、レンダリングフィルタ４１２は、取得したＸＰＳデータを解析し、プリンタ１５００が解釈できるＰＤＬデータを生成するための中間データを生成し、当該レンダリングフィルタ４１２が管理するＲＡＭ１０２内のメモリ領域に作成して保持する（ステップＳ１００４）（ＸＰＳデータ解析処理）。なお、レンダリングフィルタ４１２が管理可能なメモリ領域が作成可能であれば、ＲＡＭ１０２に限定されず、他の記憶装置であってもよい。また、レンダリングフィルタ４１２は、プリンタ１５００に構成されていてもよい。このプリンタ１５００にレンダリングフィルタ４１２に保持する場合は、ＰＤＬデータを生成せずに、印刷部１１７で印字する描画データを生成する。

ステップＳ１００３でのＸＰＳデータの取得は、ＸＰＳデータを取得しながら、Ｓ１００４のＸＰＳデータの解析処理を平行して実行する（ストリーミングする）ために、フィルタパイプラインマネージャ４１０から細分化データ（パケット）単位でデータを取得するように構成してもよい。この場合、分割されたデータを取得しながら、レンダリングフィルタ４１２は解析を実行する。

また、プリンタ１５００にレンダリングフィルタ４１２が構成されている場合は、プリンタ１５００へプリントデータ（ＸＰＳデータ）を送信する際に、プリンタ１５００で即時に印刷処理を実行できるようにするために、フィルタパイプラインマネージャ４１０またはランゲージモニタ４０７がＸＰＳデータを細分化データ（パケット）単位にしてプリンタ１５００に送信する。つまり、プリンタ１５００は、データを受信しながら、解析処理して、順次印刷を実行することが可能となる。

なお、受信または取得した細分化データは、記憶領域（ＲＡＭ１０２またはＲＡＭ１１９）に記憶される。また、細分化データを受信または取得しながら解析処理をするため、解析処理が実行できる単位（１つのファイル（パーツ）分）のデータを受信していない、または取得できない（読出しができない）場合は解析処理を実行できるようになるまで待機する。

次に、レンダリングフィルタ４１２は、ステップＳ１００４で生成された中間データをＰＤＬデータに変換するモジュールに渡してＰＤＬデータに変換し、当該ＰＤＬデータをフィルタパイプラインマネージャ４１０に通知する（ステップＳ１００５）。なお、後述する図２３のステップＳ１９０４の処理の後に１ページ毎の中間データをその都度ＰＤＬ変換モジュールに渡すか、または図２２のステップＳ１８０１で抽出した１描画命令を中間データに変換して、その都度ＰＤＬ変換モジュールに渡しても構わない。

また、中間データ（ＸＰＳデータ）を用いて印刷することが可能なプリンタである場合には、ステップＳ１００５の処理を実行することなく、中間データをプリンタ１５００に送信するように構成することも可能である。さらに、プリンタ１５００にレンダリングフィルタが構成され、プリンタ１５００が中間データを用いて印刷することが可能である場合は、ステップＳ１００５の処理を実行することなく、中間データを描画データに変換して印刷部（プリンタエンジン）１１７に渡して印刷することも可能である。

次に、図１５を用いて、図１４のステップＳ１００４におけるＸＰＳデータ解析処理の詳細を説明する。

図１５は、図１４のステップＳ１００４におけるＸＰＳデータ解析処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、取得したＸＰＳデータにおける＿ｒｅｌｓ／．ｒｅｌｓパーツデータを全て解析したか否かを判断する（ステップＳ１１０１）。全て解析したか否かの判断は、＿ｒｅｌｓ／．ｒｅｌｓパーツデータが前述したようにＸＭＬ形式であるので、ルート要素の終了タグを処理したか否かで行われる。具体的には、レンダリングフィルタ４１２は、図９に示すパーツ８５２に記述されている＜／Ｒｅｌａｔｉｏｎｓｈｉｐｓ＞というルート要素の終了タグを検出したところで、＿ｒｅｌｓ／．ｒｅｌｓパーツデータの解析終了と判断する。以降、ＸＭＬ形式のパーツに関して、全て解析したか否かの判断は同様の方法をとるものとする。なお、ルート要素の終了タグは最後のピースデータに必ず存在する。

なお、ステップＳ１１０１では、取得したＸＰＳデータがインタリーブ化されているか否かを判定することもできる。ＸＰＳデータがインタリーブ化されていない場合は、＿ｒｅｌｓ／．ｒｅｌｓパーツデータが１つしか存在しないためである（インタリーブ判定手段）。

ステップＳ１１０１の判断の結果、＿ｒｅｌｓ／．ｒｅｌｓパーツデータを全て解析済みであれば、本処理を終了する。一方、未処理の＿ｒｅｌｓ／．ｒｅｌｓパーツデータが存在しているのであれば（ステップＳ１１０１でＹＥＳ）、レンダリングフィルタ４１２は、未処理の＿ｒｅｌｓ／．ｒｅｌｓパーツデータ（またはピースデータ）を全て取得したか否かを判断する（ステップＳ１１０２）。＿ｒｅｌｓ／．ｒｅｌｓパーツデータを全て取得したか否かの判断は、インタリーブ化されている場合は、後述するＸＰＳデータ内のパーツ（またはピース）の検索時に、データ名の最後が「／＿ｒｅｌｓ／．ｒｅｌｓ／［ｉ］．ｌａｓｔ．ｐｉｅｃｅ」となっているピースデータを取得したときに全て取得したと判断される。なお、ＸＰＳデータがインタリーブ化されていない場合は、＿ｒｅｌｓ／．ｒｅｌｓパーツデータが１つしか存在しないので、ステップＳ１１０３の処理は１回しか行われない。

以降、パーツを全て取得したか否かの判断は、上記と同様の方法をとるものとする。

ステップＳ１１０２の判断の結果、まだ＿ｒｅｌｓ／．ｒｅｌｓパーツデータ（またはピースデータ）を全て取得していないのであれば（ステップＳ１１０２でＹＥＳ）、レンダリングフィルタ４１２は、次のパーツデータ（またはピースデータ）を検索・伸長して取得する（ステップＳ１１０３）。ここで、本検索方法は、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒをデータの先頭から検索する方法を採用するものとする。また、このとき、検索するＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒ内のデータ名としては、“＿ｒｅｌｓ／．ｒｅｌｓ”若しくは、インタリーブ化されている場合の“＿ｒｅｌｓ／．ｒｅｌｓ／［ｉ］．ｐｉｅｃｅ”（ｉは０で始まる通し番号）である。

以降、特に断りが無い限り、ＸＰＳデータ内のパーツの検索方法はこの方法をとるものとする。また、本伸張方法は一般的なＺＩＰデータの伸張方法であり、伸張したデータはディレクトリ構成を保持したまま各種ファイルを外部メモリ１１１に書き出す形で保存される。伸長方法についても、以降の説明ではこの方法をとるものとする。

次に、レンダリングフィルタ４１２は、取得した＿ｒｅｌｓ／．ｒｅｌｓパーツデータ（またはピースデータ）を解析し、ＦＤＳのＸＰＳ内でのデータ名を取得する（ステップＳ１１０４）。＿ｒｅｌｓ／．ｒｅｌｓパーツデータは、前述の通り、ＸＭＬ形式で記述されたファイルであり、本解析方法については一般的なＸＭＬファイルの解析方法を採用する。なお、以後、ＸＭＬ形式で記述されたファイルを解析する場合は、同様に、一般的なＸＭＬファイルの解析方法を採用するものとする。

ステップＳ１１０５において、レンダリングフィルタ４１２は、ＦＤＳのデータ名を取得することができたときは（ステップＳ１１０５でＹＥＳ）、ＦＤＳの処理を行う（ステップＳ１１０６）。一方、ＦＤＳのデータ名を取得することができかなったときは（ステップＳ１１０５でＮＯ）、ステップＳ１１０１へ戻る。

次に、図１６を用いて、図１５のステップＳ１１０６におけるＦＤＳの処理の詳細を説明する。

図１６は、図１５のステップＳ１１０６におけるＦＤＳの処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、ＸＰＳデータにおけるＦＤＳパーツデータを全て解析したか否かを判断する（ステップＳ１２０１）。この判断の結果、まだＦＤＳパーツデータに未解析の箇所が存在すれば（ステップＳ１２０１でＹＥＳ）、レンダリングフィルタ４１２は、ＦＤＳパーツデータを全て取得したか否かの判断を行う（ステップＳ１２０２）。この判断の結果、まだＦＤＳパーツデータ（またはピースデータ）を全て取得していないのであれば（ステップＳ１２０２でＹＥＳ）、レンダリングフィルタ４１２は、次のＦＤＳパーツデータ（またはピースデータ）を検索・伸長して取得する（ステップＳ１２０３）。

次に、レンダリングフィルタ４１２は、取得したＦＤＳパーツデータ（またはピースデータ）を解析し、ＦＤのＸＰＳ内でのデータ名を一つ取得する（ステップＳ１２０４）。ＦＤのデータ名を取得することができたときは（ステップＳ１２０５でＹＥＳ）、レンダリングフィルタ４１２は、ＦＤの処理を行う（ステップＳ１２０６）。一方、ＦＤのデータ名を取得することができなかったときは（ステップＳ１２０５でＮＯ）、ステップＳ１２０１へ戻る。

次に、図１７を用いて、図１６のステップＳ１２０６におけるＦＤの処理の詳細を説明する。

図１７は、図１６のステップＳ１２０６におけるＦＤの処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、ＸＰＳデータにおけるＦＤパーツデータを全て解析したか否かを判断する（ステップＳ１３０１）。この判断の結果、まだＦＤパーツデータに未解析の箇所が存在すれば（ステップＳ１３０１でＹＥＳ）、レンダリングフィルタ４１２は、ＦＤパーツデータを全て取得したか否かを判断する（ステップＳ１３０２）。この判断の結果、まだＦＤパーツデータを全て取得していないときは（ステップＳ１３０２でＹＥＳ）、レンダリングフィルタ４１２は、次のＦＤパーツデータ（またはピースデータ）を検索・伸長して取得する（ステップＳ１３０３）。ここでの検索方法の詳細については後述する。

次に、レンダリングフィルタ４１２は、取得したＦＤパーツデータ（またはピースデータ）を解析し、ＦＰのＸＰＳ内でのデータ名を一つ取得する（ステップＳ１３０４）。ＦＰのデータ名を取得することができたときは（ステップＳ１３０５でＹＥＳ）、ＦＰの処理を行う（ステップＳ１３０６）。一方、ＦＰのデータ名を取得できなかったときは（ステップＳ１３０５でＮＯ）、ステップＳ１３０１へ戻る。

次に、図１８を用いて、図１７のステップＳ１３０３におけるＦＤパーツデータの検索・伸長・取得処理の詳細を説明する。

図１８は、図１７のステップＳ１３０３におけるＦＤパーツデータの検索・伸長・取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、上述した図２８に示すジョブ情報管理テーブル２８００を参照し、ＸＰＳデータがインタリーブ化されているか否かの判断がなされているかを判断する（ステップＳ１４０１）。具体的な判断方法としては、ジョブ情報管理テーブル２８００におけるインタリーブ２８０１に“ＯＮ”も“ＯＦＦ”も何も格納されていないか否かで判断される。

ステップＳ１４０１の判断の結果に応じて、レンダリングフィルタ４１２は、第１のＦＤパーツ取得処理（ステップＳ１４０２）または第２のＦＤパーツ取得処理（ステップＳ１４０３）のいずれかの処理を実行する。すなわち、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００におけるインタリーブ２８０１が空であるときは、ステップＳ１４０２の第１のＦＤパーツ取得処理を実行する一方、ジョブ情報管理テーブル２８００におけるインタリーブ２８０１が空でないときは、ステップＳ１４０３の第２のＦＤパーツ取得処理を実行する。

次に、図１９を用いて、図１８のステップＳ１４０２における第１のＦＤパーツ取得処理の詳細を説明する。

図１９は、図１８のステップＳ１４０２における第１のＦＤパーツ取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、フィルタパイプラインマネージャ４１０から順次受信し、ＲＡＭ１０２などの記憶領域に記憶されたＸＰＳデータを読み出し、ＦＤＳパーツデータの解析によって判明するＦＤパーツ名のデータをＸＰＳデータの先頭から検索し、伸長し、取得する（ステップＳ１５０１）。次に、レンダリングフィルタ４１２は、取得したＦＤパーツデータがピースデータに分割されているか、すなわちＦＤパーツデータがインタリーブ化されているかを判断する（ステップＳ１５０２）（インタリーブ判定手段）。この判断の結果、取得したＦＤパーツデータのヘッダ内のデータ名が“ＦＤ名／［ｉ］．ｐｉｅｃｅ”（ｉは０から始まる通し番号）となっていれば、レンダリングフィルタ４１２は、ＦＤパーツデータがインタリーブ化されていると判断して（ステップＳ１５０２でＹＥＳ）、ジョブ情報管理テーブル２８００のインタリーブ２８０１に“ＯＮ”を書き込む（ステップＳ１５０３）。

一方、レンダリングフィルタ４１２は、インタリーブ化されていないと判断した場合は（ステップＳ１５０２でＮＯ）、ジョブ情報管理テーブル２８００のインタリーブ２８０１に“ＯＦＦ”を書き込む（ステップＳ１５０４）。ここでは、ＦＤパーツ名によってインタリーブ化されているか否かの判断を行っているが、インタリーブＯＮの設定で、ＭＸＤＷからＸＰＳデータが作成されているのであれば、＿ｒｅｌｓ／．ｒｅｌｓ、またはＦＤＳパーツデータのパーツ名で判断することも可能である。

次に、ステップＳ１５０５では、レンダリングフィルタ４１２は、図３０に示した処理中ページ情報管理テーブル３０００のドキュメント位置３００１に、取得したＦＤパーツデータ（またはピースデータ）のＸＰＳデータ内での先頭からの位置をバイト単位（配置位置）で書き込む。続いて、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のドキュメント位置３００１以外の項目を空にする（ステップＳ１５０６）。

次に、図２０を用いて、図１８のステップＳ１４０３における第２のＦＤパーツ取得処理の詳細を説明する。

図２０は、図１８のステップＳ１４０３における第２のＦＤパーツ取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のインタリーブ２８０１の内容を確認し、“ＯＮ”か否かを判断する（ステップＳ１６０１）。この判断の結果、ジョブ情報管理テーブル２８００のインタリーブ２８０１が“ＯＮ”のときは、ステップＳ１６０２へ進む一方、“ＯＦＦ”のときは、ステップＳ１６０５へ進む。

ステップＳ１６０２では、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のページ位置３００２が空か否かを判断する。処理中ページ情報管理テーブル３０００のページ位置３００２が空の場合、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のドキュメント位置３００１に記述されたバイト数分（配置位置）、ＸＰＳデータの先頭から進んだＸＰＳデータから正順に検索し、ＦＤパーツデータを取得する（ステップＳ１６０３）。一方、処理中ページ情報管理テーブル３０００のページ位置３００２が空でない場合、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のページ位置３００２に格納されたページ位置から正順に検索してＦＤパーツデータを取得する（ステップＳ１６０４）。ここで「正順」とは、データの先頭から終端の方向を意味する。

ステップＳ１６０５では、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のドキュメント位置３００１に格納されたドキュメント位置から正順にＦＤパーツデータを検索し、取得する。

次に、レンダリングフィルタ４１２は、ステップＳ１６０３またはステップＳ１６０４またはステップＳ１６０５における検索処理が終了した後、ＦＤパーツデータ（またはピースデータ）が取得できたか否かを判断する（ステップＳ１６０６）。この結果、取得できていなければ、レンダリングフィルタ４１２は、ＸＰＳデータの先頭から順番に検索してＦＤパーツデータを取得する（ステップＳ１６０７）。これは、データの配置規則が統一されていないＸＰＳデータに対応するための処理である。ＭＸＤＷで作成されたデータの場合、本ステップをスルーする。

次に、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のドキュメント位置３００１に、取得したＦＤパーツデータ（またはピースデータ）のＸＰＳデータ内での先頭からの位置（バイト単位、配置位置）を書き込む（ステップＳ１６０８）。続いて、処理中ページ情報管理テーブル３０００のドキュメント位置３００１以外の項目を空にする（ステップＳ１６０９）。

次に、図２１を用いて、図１７のステップＳ１３０６におけるＦＰの処理の詳細について説明する。

図２１は、図１７のステップＳ１３０６におけるＦＰの処理の詳細を示すフローチャートである。

レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のインタリーブ２８０１の内容を確認する（ステップＳ１７０１）。ジョブ情報管理テーブル２８００のインタリーブ２８０１が“ＯＮ”のときは、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のドキュメント位置３００１に格納されたドキュメント位置から正順にＦＰパーツデータを検索し、ＦＰパーツデータを取得する（ステップＳ１７０２）。続いて、レンダリングフィルタ４１２は、ＦＰパーツデータを取得できたか否かを判断する（ステップＳ１７０３）。取得できないときは、レンダリングフィルタ４１２は、ＸＰＳデータの先頭から正順に検索して、ＦＰパーツデータを取得する（ステップＳ１７０４）。

次に、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のインタリーブ２８０１が“ＯＦＦ”のときは、処理中ページ情報管理テーブル３０００のページ位置３００２が空か否かを判断する（ステップＳ１７０５）。空の場合は、レンダリングフィルタ４１２は、ＸＰＳデータの先頭から正順に検索して、ＦＰパーツデータを取得する（ステップＳ１７０６）。空でない場合は、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のページ位置３００２に格納されたページ位置から正順に検索して、ＦＰパーツデータを取得する（ステップＳ１７０７）。続いて、レンダリングフィルタ４１２は、ＦＰパーツデータを取得できたか否かを判断する（ステップＳ１７０８）。取得できないときは、レンダリングフィルタ４１２は、ＸＰＳデータの先頭から正順に検索して、ＦＰパーツデータを取得する（ステップＳ１７０９）。

なお、本実施形態では、インタリーブされていない場合（ジョブ情報管理テーブル２８００のインタリーブ２８０１が“ＯＦＦ”のとき）には、ステップＳ１７０５〜Ｓ１７１０の処理を行うように構成したが、インタリーブされていない場合には、ＸＰＳデータの先頭から毎回検索するように構成してもよい。これは、インタリーブされていないＸＰＳデータは印刷処理する順にファイル（パーツ）が並んでいないこともあるため、ＸＰＳデータの先頭から検索する構成をとることが可能である。つまり、インタリーブされていない場合の検索の先頭は、ＸＰＳデータの先頭の位置、或いはＦＤパーツデータの先頭位置などいずれを検索位置としてもよい。

ステップＳ１７１０では、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のインタリーブ２８０１が“ＯＦＦ”の場合は、続けて処理中ページ情報管理テーブル３０００の前ページ位置３００３にページ位置３００２の内容をコピーする。次に、ＦＰパーツデータの取得後、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のページ位置３００２に、取得したＦＰパーツデータのＸＰＳデータ先頭からの位置をバイト単位（配置位置）で書き込む（ステップＳ１７１１）。続けて、レンダリングフィルタ４１２は、取得したＦＰパーツデータの解析処理を行う（ステップＳ１７１１）。なお、複数のＦＰパーツデータを構成するＸＰＳデータの場合、このページ位置３００２は、ＦＰパーツデータを検索し、取得するたびに更新される。

次に、図２２を用いて、図２１のステップＳ１７１２におけるＦＰパーツデータの解析処理の詳細を説明する。

図２２は、図２１のステップＳ１７１２におけるＦＰパーツデータの解析処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、取得したＦＰパーツデータを解析し、描画命令を抽出する（ステップＳ１８０１）。次に、レンダリングフィルタ４１２は、抽出した描画命令にイメージデータやフォントデータへの外部リソース参照が含まれているかを判断する（ステップＳ１８０２）。外部リソース参照が含まれているのであれば、レンダリングフィルタ４１２は、外部リソース検索・伸長・取得処理を行う（ステップＳ１８０３）。続いて、レンダリングフィルタ４１２は、現在処理中のＦＰパーツデータまたはＦＰピースデータの終端まで解析したか否かを判断する（ステップＳ１８０４）。この判断の結果、まだ未解析の箇所が残っているのであれば（ステップＳ１８０４でＮＯ）、ステップＳ１８０１に戻る。

次に、図２３を用いて、図２２のステップＳ１８０３における外部リソース検索・伸長・取得処理の詳細を説明する。

図２３は、図２２のステップＳ１８０３における外部リソース検索・伸長・取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のインタリーブ２８０１の内容を確認する（ステップＳ１９０１）。ジョブ情報管理テーブル２８００のインタリーブ２８０１が“ＯＮ”のときは、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２の内容を確認する（ステップＳ１９０２）。ジョブ情報管理テーブル２８００のイメージ配置方法２８０２の内容が空だった場合、レンダリングフィルタ４１２は、第１の外部リソース取得処理を行う（ステップＳ１９０３）。空でない場合、レンダリングフィルタ４１２は、第２の外部リソース取得処理を行う（ステップＳ１９０４）。

一方、ステップＳ１９０１において、ジョブ情報管理テーブル２８００のインタリーブ２８０１が“ＯＦＦ”の場合、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２の内容を確認する（ステップＳ１９０５）。ジョブ情報管理テーブル２８００のイメージ配置方法２８０２の内容が空だった場合、レンダリングフィルタ４１２は、第３の外部リソース取得処理を行う（ステップＳ１９０６）。空でない場合、レンダリングフィルタ４１２は、第３の外部リソース取得処理を行う（ステップＳ１９０７）。

次に、図２４を用いて、図２３のステップＳ１９０３における第１の外部リソース取得処理の詳細について説明する。第１の外部リソース取得処理は、外部リソースがイメージデータであって、ＸＰＳデータがインタリーブ化されており（インタリーブＯＮ）、イメージデータのＸＰＳデータ内における配置方法が判明していない場合に実行される処理である。

図２４は、図２３のステップＳ１９０３における第１の外部リソース取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のドキュメント位置３００１に格納されたドキュメント位置からページ位置３００２に格納されたページ位置まで正順にイメージパーツの検索を行う（ステップＳ２００１）。続いて、レンダリングフィルタ４１２は、イメージパーツが発見できたか否かを判断する（ステップＳ２００２）。イメージパーツが発見できなかったときは、ステップＳ２００５へ進む。一方、イメージパーツが発見できたときは、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２に“ページの前”と書き込む（ステップＳ２００３）。

次に、ステップＳ２００４では、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００の“イメージ位置リストの最後のデータへのポインタ”（配置位置）に、発見したイメージパーツのＸＰＳデータ内での位置が記述されたデータを作成し付け加えることで更新する。

ステップＳ２００５では、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のページ位置３００２に格納されたページ位置からＸＰＳデータの最後まで正順に検索を行う。続いて、レンダリングフィルタ４１２は、イメージパーツが発見できたか否かを判断する（ステップＳ２００６）。イメージパーツが発見できたときは、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２に“ページの後”と書き込む（ステップＳ２００７）。続いて、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００の“イメージ位置リストの最後のデータへのポインタ”（配置位置）に、発見したイメージパーツのＸＰＳデータ内での位置が記述されたデータを作成し付け加えることで更新する（ステップＳ２００８）。

一方、ステップＳ２００６において、イメージデータが発見できなかった場合、レンダリングフィルタ４１２は、ＸＰＳデータの先頭から正順にイメージパーツを検索して取得する（ステップＳ２００９）。

次に、図２５を用いて、図２３のステップＳ１９０４における第２の外部リソース取得処理の詳細について説明する。第２の外部リソース取得処理は、外部リソースがイメージデータであって、ＸＰＳデータがインタリーブ化されており（インタリーブＯＮ）、イメージデータのＸＰＳデータ内における配置方法が判明している場合に実行される処理である。

図２５は、図２３のステップＳ１９０４における第２の外部リソース取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２の内容を確認し、イメージ配置方法２８０２の内容が“ページの前”か否かを判断する（ステップＳ２１０１）。この判断の結果、イメージ配置方法２８０２の内容が“ページの後”である場合（ステップＳ２１０１でＮＯ）、ステップＳ２１０６へ進む。一方、イメージ配置方法２８０２の内容が“ページの前”である場合（ステップＳ２１０１でＹＥＳ）、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のドキュメント位置３００１に格納されたドキュメント位置からページ位置３００２に格納されたページ位置まで正順にイメージパーツの検索を行う（ステップＳ２１０２）。

次に、レンダリングフィルタ４１２は、イメージパーツが発見できたか否かを判断する（ステップＳ２１０３）。イメージパーツを発見できたときは（ステップＳ２１０３でＹＥＳ）、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ位置リストの最後のデータへのポインタ２８０５に、発見したイメージパーツのＸＰＳデータ内での位置が記述されたデータを作成して格納することで更新して（ステップＳ２１０４）、ステップＳ２１０７へ進む。

一方、ステップＳ２１０３において、イメージパーツが発見できなかったときは、レンダリングフィルタ４１２は、以前使われたイメージデータかもしれないので、イメージ位置リストの最初から順番にその指し示す先のデータを調べて（ステップＳ２１０５）、ステップＳ２１０６へ進む。

ステップＳ２１０６では、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ位置リストの最初のデータへのポインタ２８０４の指し示す先の位置からＸＰＳデータの最後まで正順にイメージパーツを検索する。

ステップＳ２１０７では、イメージパーツが発見できたか否かを判断し、発見できなければ（ステップＳ２１０７でＮＯ）、ＸＰＳデータの先頭から検索してイメージパーツを取得する（ステップＳ２１０８）。

次に、図２６を用いて、図２３のステップＳ１９０６における第３の外部リソース取得処理の詳細について説明する。第３の外部リソース取得処理は、外部リソースがイメージデータであって、ＸＰＳデータがインタリーブ化されておらず（インタリーブＯＦＦ）、イメージデータのＸＰＳデータにおける配置方法が判明していない場合に実行される処理である。

図２６は、図２３のステップＳ１９０６における第３の外部リソース取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００の前ページ位置３００３に格納された前ページ位置からページ位置３００２に格納されたページ位置まで正順にイメージパーツの検索を行う（ステップＳ２２０１）。続いて、レンダリングフィルタ４１２は、イメージパーツが発見できたか否かを判断する（ステップＳ２２０２）。イメージパーツが発見できなかったときは、ステップＳ２２０５へ進む。一方、イメージデータが発見できたときは、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２に“ページの前”と書き込む（ステップＳ２２０３）。

次に、ステップＳ２２０４では、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００の“イメージ位置リストの最後のデータへのポインタ”（配置位置）に、発見したイメージパーツのＸＰＳデータ内での位置が記述されたデータを作成し付け加えることで更新する。

ステップＳ２２０５では、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００のページ位置３００２に格納されたページ位置からＸＰＳデータの最後まで正順に検索を行う。続いて、レンダリングフィルタ４１２は、イメージパーツが発見できたか否かを判断する（ステップＳ２２０６）。イメージパーツが発見できたときは、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２に“ページの後”と書き込む（ステップＳ２２０７）。続いて、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００の“イメージ位置リストの最後のデータへのポインタ”（配置位置）に、発見したイメージパーツのＸＰＳデータ内での位置が記述されたデータを作成し付け加えることで更新する（ステップＳ２２０８）。

一方、ステップＳ２２０６において、イメージデータが発見できなかった場合、レンダリングフィルタ４１２は、ＸＰＳデータの先頭から正順にイメージパーツを検索して取得する（ステップＳ２２０９）。

次に、図２７を用いて、図２３のステップＳ１９０７における第４の外部リソース取得処理の詳細について説明する。第４の外部リソース取得処理は、外部リソースがイメージデータであって、ＸＰＳデータがインタリーブ化されておらず（インタリーブＯＦＦ）、イメージデータのＸＰＳデータにおける配置方法が判明している場合に実行される処理である。

図２７は、図２３のステップＳ１９０７における第４の外部リソース取得処理の詳細を示すフローチャートである。

まず、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ配置方法２８０２の内容を確認し、イメージ配置方法２８０２の内容が“ページの前”か否かを判断する（ステップＳ２３０１）。この判断の結果、イメージ配置方法２８０２の内容が“ページの後”である場合（ステップＳ２３０１でＮＯ）、ステップＳ２３０６へ進む。一方、イメージ配置方法２８０２の内容が“ページの前”である場合（ステップＳ２
３０１でＹＥＳ）、レンダリングフィルタ４１２は、処理中ページ情報管理テーブル３０００の前ページ位置３００３に格納された前ページ位置からページ位置３００２に格納されたページ位置まで正順にイメージパーツの検索を行う（ステップＳ２３０２）。

次に、レンダリングフィルタ４１２は、イメージパーツが発見できたか否かを判断する（ステップＳ２３０３）。イメージパーツを発見できたときは（ステップＳ２３０３でＹＥＳ）、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ位置リストの最後のデータへのポインタ２８０５に、発見したイメージパーツのＸＰＳデータ内での位置が記述されたデータを作成して格納して（同上）（ステップＳ２３０４）、ステップＳ２３０７へ進む。

一方、ステップＳ２３０３において、イメージパーツが発見できなかったときは、レンダリングフィルタ４１２は、以前使われたイメージデータかもしれないので、イメージ位置リストの最初から順番にその指し示す先のデータを調べて（ステップＳ２３０５）、ステップＳ２３０７へ進む。

ステップＳ２３０６では、レンダリングフィルタ４１２は、ジョブ情報管理テーブル２８００のイメージ位置リストの最初のデータへのポインタ２８０４の指し示す先の位置からＸＰＳデータの最後まで正順にイメージパーツを検索する。

ステップＳ２３０７では、イメージパーツが発見できたか否かを判断し、発見できないときは（ステップＳ２３０７でＮＯ）、ＸＰＳデータの先頭から検索してイメージパーツを取得する（ステップＳ２３０８）。

上記実施形態によれば、ＸＰＳデータの解析結果からＦＤパーツデータ及びＦＰパーツデータの配置情報であるドキュメント位置やページ位置をＲＡＭ１０２に作成された処理中ページ情報管理テーブルに格納し、ＸＰＳデータがインタリーブ化されているか否かを判定する。この判定結果をジョブ情報管理テーブルに格納し、このジョブ情報管理テーブルに格納された判定結果に応じて取得方法を変更し、処理中ページ情報管理テーブルに格
納された配置情報に基づいてＸＰＳデータからＦＰパーツデータを取得する。これにより、ＭＸＤＷで作成されたＸＰＳデータからパーツデータを取得する際、Ｌｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒを先頭から検索することなく、ＸＰＳデータへの入出力Ｉ／Ｏ回数を削減して処理を向上させることができる。

次に、図３７を用いて、本実施形態の効果を、ＺＩＰデータの先頭からＬｏｃａｌ Ｆｉｌｅ Ｈｅａｄｅｒを順番に調べる第１の方法を用いた場合における入出力Ｉ／Ｏの数と比較して説明する。

図３７の、全３ページで、各ページで２つのイメージへの参照があるインタリーブ化（分割）処理が施されたＸＰＳデータで考える。ＸＰＳデータはＲＡＭ１０２などの記憶領域に展開されているものとする。

なお、ここでは、本実施形態によって特に効果を得られる最初のＦＤピースを発見してから、最後のＦＰパーツが処理されるまでの入出力Ｉ／Ｏ回数についての説明を行う。

第１の方法の場合、４０８回入出力Ｉ／Ｏが発生する（内訳は以下の通り）。

・図３７の３７０１のＦｉｘｅｄＤｏｃｕｍｅｎｔ［０］（ｆｄｏｃ／［０]．ｐｉｅｃｅ）の取得（ヘッダ検索数：１０回）
・図３７の３７０２のＦｉｘｅｄＰａｇｅ１（１．ｆｐａｇｅ）の取得（ヘッダ検索数：２７回）
・図３７の３７０３のイメージ１（１．ｊｐｇ）の取得（ヘッダ検索数：２２回）
・図３７の３７０４のイメージ２（２．ｊｐｇ）の取得（ヘッダ検索数：２５回）
・図３７の３７０５のＦｉｘｅｄＤｏｃｕｍｅｎｔ［１］（ｆｄｏｃ／［１]．ｐｉｅｃｅ）の取得（ヘッダ検索数：２８回）
・図３７の３７０６のＦｉｘｅｄＰａｇｅ２（２．ｆｐａｇｅ）の取得（ヘッダ検索数：３９回）
・図３７の３７０７のイメージ３（３．ｊｐｇ）の取得（ヘッダ検索数：３４回）
・図３７の３７０８のイメージ４（４．ｊｐｇ）の取得（ヘッダ検索数：３７回）
・図３７の３７０９のＦｉｘｅｄＤｏｃｕｍｅｎｔ［２］（ｆｄｏｃ／［２]．ｐｉｅｃｅ）の取得（ヘッダ検索数：４０回）
・図３７の３７１０のＦｉｘｅｄＰａｇｅ３（３．ｆｐａｇｅ）の取得（ヘッダ検索数：５１回）
・図３７の３７１１のイメージ５（５．ｊｐｇ）の取得（ヘッダ検索数：４６回）
・図３７の３７１２のイメージ６（６．ｊｐｇ）の取得（ヘッダ検索数：４９回）
本実施形態の場合、１８４回目入出力Ｉ／Ｏが発生する（内訳は以下の通り）。

ＦＤ１の処理
・ジョブ管理情報テーブルの“インタリーブ”が空と確認（読み込み１回）
・先頭から図３７の３７０１のＦｉｘｅｄＤｏｃｕｍｅｎｔ［０]（ｆｄｏｃ／［０]．ｐｉｅｃｅ）を検索して取得（ヘッダ検索数：１０回）
・ジョブ管理情報テーブルの“インタリーブ”への“ＯＮ”の書き込み（書き込み１回）
・処理中ページ情報管理テーブルの“ドキュメント位置”に取得したＦＤパーツのピースデータのＸＰＳデータの先頭からの位置（バイト単位、配置位置）の書き込み（書き込み１回）
・処理中ページ情報管理テーブルの“ドキュメント位置”以外の項目を空にする（書き込み１回）
ＦＰ１の処理
・ジョブ管理情報テーブルの“インタリーブ”が“ＯＮ”と判断（読み込み１回）
・図３７の３７０２のＦｉｘｅｄＰａｇｅ１（１．ｆｐａｇｅ）を取得し、位置情報を処理中ページ情報管理テーブルの“ページ位置”に書き込む（ＦｉｘｅｄＤｏｃｕｍｅｎｔ［０］の位置読み込み１回、ヘッダ検索数：１８回、書き込み１回、合計：２０回）。

・ジョブ管理情報テーブルの“インタリーブ”が“ＯＮ”と判断（読み込み１回）
・ジョブ情報管理テーブルの“イメージ配置方法”が空と確認（読み込み１回）
・処理中ページ情報管理テーブルの“ドキュメント位置”と“ページ位置”を取得（読み込み２回）
・図３７の３７０３のイメージ１（１．ｊｐｇ）の取得（ヘッダ検索数：１３回）
・ジョブ情報管理テーブルの“イメージ配置方法”に“ページの前”と記述（書き込み１回）
・取得したイメージの位置が格納されたデータを作成し、イメージ位置リストの最後につなげる（生成１回、書き込み１回、合計２回）。

・図３７の３７０４のイメージ２（２．ｊｐｇ）の取得（読み込み４回、ヘッダ検索数：１６回、生成１回、書き込み１回、合計２２回）
ＦＤ２の処理
・ジョブ管理情報テーブルの“インタリーブ”への“ＯＮ”の確認（読み込み１回）
・処理中ページ情報管理テーブルの“ページ位置”の取得（読み込み１回）
・図３７の３７０５のＦｉｘｅｄＤｏｃｕｍｅｎｔ［１］（ｆｄｏｃ／［１]．ｐｉｅｃｅ）の取得（ヘッダ検索数：２回）
・“ドキュメント位置”に取得したＦＤパーツのピースデータのＸＰＳデータの先頭からの位置（バイト単位、配置位置）の書き込み（書き込み１回）
・処理中ページ情報管理テーブルの“ドキュメント位置”以外の項目を空にする（書き込み１回）。

ＦＰ２の処理
・ジョブ管理情報テーブルの“インタリーブ”が“ＯＮ”と判断（読み込み１回）
・図３７の３７０６のＦｉｘｅｄＰａｇｅ２（２．ｆｐａｇｅ）を取得し、位置情報を処理中ページ情報管理テーブルの“ページ位置”に書き込む（ＦｉｘｅｄＤｏｃｕｍｅｎｔ［１］の位置読み込み１回、ヘッダ検索数：１２回、書き込み１回、合計：２０回）
・ジョブ管理情報テーブルの“インタリーブ”が“ＯＮ”と判断（読み込み１回）
・ジョブ情報管理テーブルの“イメージ配置方法”が“ページの前”と確認（読み込み１回）
・処理中ページ情報管理テーブルの“ドキュメント位置”と“ページ位置”を取得（読み込み２回）
・図３７の３７０７のイメージ３（３．ｊｐｇ）の取得（ヘッダ検索数：７回）
・取得したイメージの位置が格納されたデータを作成し、イメージ位置リストの最後につなげる（生成１回、書き込み１回、合計２回）。

図３７の３７０８のイメージ４（４．ｊｐｇ）の取得（読み込み４回、ヘッダ検索数：１０回、生成１回、書き込み１回、合計１６回）
ＦＤ３の処理
・ジョブ管理情報テーブルの“インタリーブ”への“ＯＮ”の確認（読み込み１回）
・処理中ページ情報管理テーブルの“ページ位置”の取得（読み込み１回）
・図３７の３７０９のＦｉｘｅｄＤｏｃｕｍｅｎｔ［２］（ｆｄｏｃ／［２]．ｐｉｅｃｅ）の取得（ヘッダ検索数：２回）
・“ドキュメント位置”に取得したＦＤパーツのピースデータのＸＰＳデータの先頭からの位置（バイト単位、配置位置）の書き込み（書き込み１回）
・処理中ページ情報管理テーブルの“ドキュメント位置”以外の項目を空にする（書き込み１回）。

ＦＰ３の処理
・ジョブ管理情報テーブルの“インタリーブ”が“ＯＮ”と判断（読み込み１回）
・図３７の３７１０のＦｉｘｅｄＰａｇｅ３（３．ｆｐａｇｅ）を取得し、位置情報を処理中ページ情報管理テーブルの“ページ位置”に書き込む（ＦｉｘｅｄＤｏｃｕｍｅｎｔ［２］の位置読み込み１回、ヘッダ検索数：１２回、書き込み１回、合計：２０回）。

・ジョブ管理情報テーブルの“インタリーブ”が“ＯＮ”と判断（読み込み１回）
・ジョブ情報管理テーブルの“イメージ配置方法”が“ページの前”と確認（読み込み１回）
・処理中ページ情報管理テーブルの“ドキュメント位置”と“ページ位置”を取得（読み込み２回）
・図３７の３７１１のイメージ５（５．ｊｐｇ）の取得（ヘッダ検索数：７回）
・取得したイメージの位置が格納されたデータを作成し、イメージ位置リストの最後につなげる（生成１回、書き込み１回、合計２回）。

・図３７の３７１２のイメージ６（６．ｊｐｇ）の取得（読み込み４回、ヘッダ検索数：１０回、生成１回、書き込み１回、合計１６回）
上述のことから、例えば、２つのイメージを参照するページがＮページ（変数：Ｎ）あるＸＰＳデータをインタリーブ化（分割）処理が施されたＸＰＳデータを第１の方法と本実施形態の方法で処理するとき、入出力Ｉ／Ｏ回数は以下のようになる。

従来の方法
７４＋１３８×（Ｎ−１）＋４８×（Ｎ^２−３Ｎ＋２）／２回
本実施形態の方法
７６＋５４×（Ｎ−１）回
上記により求められた入出力Ｉ／Ｏ回数を、アルゴリズムの効率の指標を表す計算量（オーダー）で比較した場合、「７４＋１３８×（Ｎ−１）＋４８×（Ｎ^２−３Ｎ＋２）／２回」：「７６＋５４×（Ｎ−１）回」＝「Ｏ（Ｎ^２）」：「Ｏ（Ｎ）」となり、第１の方法での順次検索では、ページ数に対する、入出力Ｉ／Ｏ回数のオーダーは（Ｏ（Ｎ^２））であり、本実施形態の方法では（Ｏ（Ｎ））であるので、ページ数（Ｎ）が増えるほど、本実施形態による効果が得られる。また、イメージパーツや、フォントパーツ増えるほど、本実施形態による効果が得られる。

なお、本発明をＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａでの印刷時以外においても、ＭＸＤＷで作成されたＸＰＳデータを処理・解析する情報処理装置、プログラムに適用することができる。

また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等である。または、プログラムコードをネットワークを介してダウンロードしてもよい。

また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

さらに、前述した実施形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行う場合である。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した各実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現する場合も含まれる。この場合、上記プログラムは、該プログラムを記憶した記憶媒体から直接、またはインターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続された不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。

本発明の実施形態に係る情報処理装置を含めた印刷システムの構成例を示すブロック図である。 図１のコンピュータでの印刷制御処理時に機能するソフトウェアの構成を示すブロック図である。 図１のコンピュータ及びプリンタを利用した印刷システムの一例を示すブロック図である。 ＸＰＳデータの構成例を示す参考図である。 図４のＸＰＳデータにおけるパーツ間の参照関係の論理的構造の一例を示す参考図である。 パーツデータのＸＭＬファイルの記述に基づいたパーツ間の参照関係の一例を示す参考図である。 ＸＰＳデータを構成するＺＩＰ圧縮形式で圧縮されたデータの構成例を示す参考図である。 ＭＸＤＷにより通常生成されるＸＰＳファイルのデータ順の一例を示す参考図である。 インタリーブ化されたパーツデータの一例を示す参考図である。 インタリーブ化されたＸＰＳデータの構成例を示す参考図である。 Ｗｉｎｄｏｗｓ（登録商標）Ｖｉｓｔａの印刷システムがＸＰＳプリントパスに従って生成する印刷スプールファイルのデータ順の一例を示す参考図である。 コンピュータでの印刷制御処理時にＧＤＩプリントパスに従って機能する機能部の構成を示す図である。 コンピュータでの印刷制御処理時にＸＰＳプリントパスに従って機能する機能部の構成を示す図である。 レンダリングフィルタ４１２により実行されるＸＰＳデータの解析処理を示すフローチャートである。 図１４のステップＳ１００４におけるＸＰＳデータ解析処理の詳細を示すフローチャートである。 図１５のステップＳ１１０６におけるＦＤＳの処理の詳細を示すフローチャートである。 図１６のステップＳ１２０６におけるＦＤの処理の詳細を示すフローチャートである。 図１７のステップＳ１３０３におけるＦＤパーツデータの検索・伸長・取得処理の詳細を示すフローチャートである。 図１８のステップＳ１４０２における第１のＦＤパーツ取得処理の詳細を示すフローチャートである。 図１８のステップＳ１４０３における第２のＦＤパーツ取得処理の詳細を示すフローチャートである。 図１７のステップＳ１３０６におけるＦＰの処理の詳細を示すフローチャートである。 図２１のステップＳ１７１２におけるＦＰパーツの解析処理の詳細を示すフローチャートである。 図２２のステップＳ１８０３における外部リソース検索・伸長・取得処理の詳細を示すフローチャートである。 図２３のステップＳ１９０３における第１の外部リソース取得処理の詳細を示すフローチャートである。 図２３のステップＳ１９０４における第２の外部リソース取得処理の詳細を示すフローチャートである。 図２３のステップＳ１９０６における第３の外部リソース取得処理の詳細を示すフローチャートである。 図２３のステップＳ１９０７における第４の外部リソース取得処理の詳細を示すフローチャートである。 ジョブ情報管理テーブルの構成を示す図である。 イメージ位置リストのデータ構造を示す図である。 処理中ページ情報管理テーブルの構成を示す図である。 ＭＸＤＷでＸＰＳデータを出力する場合のインタリーブＯＮ／ＯＦＦ設定ＵＩを示す図である。 パーツデータのＸＭＬファイルの記述に基づいたパーツ間の参照関係の他の例を示す図である。 レイアウトフィルタにより実行されるＸＰＳデータ内のパーツのインタリーブ化処理を示すフローチャートである。 図３３のステップＳ２４０５におけるインタリーブ化処理の詳細を示すフローチャートである。 図３３の説明で用いるインタリーブ化される前のＸＰＳデータの構成例を示す参考図である。 図３３の説明で用いるインタリーブ化されたＸＰＳデータの構成例を示す参考図である。 検索効果を説明するための一例を示す参考図である。

符号の説明

１５００ プリンタ
１０００ コンピュータ
１０１ ＣＰＵ
１０２ ＲＡＭ
２０１ アプリケーション
４０３ スプーラ
４０７ ランゲージモニタ
４１０ フィルタパイプラインマネージャ
４１１ レイアウトフィルタ
４１２ レンダリングフィルタ

Claims (9)

1. 文書データの開始点となる開始ファイル、前記文書データの構成情報が記述されたページ構成データのファイル、１ページの描画内容が記述された印刷対象データのファイル、及びリソースファイルがアーカイブされた構造化文書形式のデータを受け取る受取手段と、
   前記受取手段で上位処理から受け取る構造化文書形式のデータを、先頭から検索する第１の検索手段と、
   前記第１の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を記憶する第１の記憶手段と、
   次に処理する印刷対象データのファイルを検索するために、前記第１の検索手段で構造化文書形式のデータを先頭から検索することなく、前記第１の記憶手段に記憶されている配置位置から、前記受取手段で上位処理より受け取る構造化文書形式のデータを検索する第２の検索手段と、
   前記第２の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を更新する更新手段と、
   前記第２の検索手段による検索を、前記印刷対象データのファイルに応じて繰り返す繰返制御手段と、
   前記検索された印刷対象データを解析処理して得られる印刷描画データを出力する出力手段とを備えることを特徴とする印刷制御装置。
2. 前記構造化文書形式のデータが、処理順に並べられる処理であるインタリーブ化されているか否かを判定する判定手段と、
   前記判定手段でインタリーブ化されていると判定される場合に、前記第２の検索手段は、前記第１の記憶手段に記憶されている配置位置を用いて前記構造化文書形式のデータを検索することを特徴とする請求項１に記載の印刷制御装置。
3. 前記判定手段でインタリーブ化されていないと判定される場合に、前記第１の検索手段は、前記構造化文書形式のデータを先頭から検索することを特徴とする請求項２に記載の印刷制御装置。
4. 前記ページ構成データのファイルを検索する第３の検索手段と、
   前記第３の検索手段の検索によって得られるページ構成データのファイルの配置位置を記憶する第２の記憶手段とをさらに備え、
   前記第１の検索手段で、インタリーブ化されていないと判定される場合に検索する前記構造化文書形式のデータの先頭は、前記ページ構成データのファイルの配置位置であることを特徴とする請求項３に記載の印刷制御装置。
5. 前記第１の検索手段または前記第２の検索手段の検索によって得られる印刷対象データ内で参照するリソースファイルを、前記第２の記憶手段で記憶されるページ構成データのファイルの配置位置を用いて検索する第４の検索手段と、
   前記第４の検索手段の検索によって得られるリソースファイルの配置位置を記憶する第３の記憶手段とを備えることを特徴とする請求項２乃至４のいずれか１項に記載の印刷制御装置。
6. 前記判定手段でインタリーブ化されていると判定される場合、次のリソースファイルを前記第３の記憶手段で記憶されるリソースファイルの配置位置を用いて検索する第５の検索手段とを備えることを特徴とする請求項５に記載の印刷制御装置。
7. 前記構造化文書形式のデータをインタリーブ化するか否かを決定する決定手段と、
   前記決定手段で、インタリーブ化すると決定された場合に、前記構造化文書形式のデータをインタリーブ化するインタリーブ化手段とをさらに備え、
   前記受取手段は、前記インタリーブ化手段でインタリーブ化された構造化文書形式のデータを受け取ることを特徴とする請求項２乃至６のいずれか１項に記載の印刷制御装置。
8. 文書データの開始点となる開始ファイル、前記文書データの構成情報が記述されたページ構成データのファイル、１ページの描画内容が記述された印刷対象データのファイル、及びリソースファイルがアーカイブされた構造化文書形式のデータを受け取る受取工程と、
   前記受取工程で上位処理から受け取る構造化文書形式のデータを、先頭から検索する第１の検索工程と、
   前記第１の検索工程の検索によって得られる前記印刷対象データのファイルの配置位置を記憶する第１の記憶工程と、
   次に処理する印刷対象データのファイルを検索するために、前記第１の検索工程で構造化文書形式のデータを先頭から検索することなく、前記第１の記憶工程で記憶された配置位置から、前記受取工程で上位処理より受け取る構造化文書形式のデータを検索する第２の検索工程と、
   前記第２の検索工程の検索によって得られる前記印刷対象データのファイルの配置位置を更新する更新工程と、
   前記第２の検索工程による検索を、前記印刷対象データのファイルに応じて繰り返す繰返制御工程と、
   前記検索された印刷対象データを解析処理して得られる印刷描画データを出力する出力工程とを備えることを特徴とする印刷制御装置の印刷制御方法。
9. 印刷制御装置を、文書データの開始点となる開始ファイル、前記文書データの構成情報が記述されたページ構成データのファイル、１ページの描画内容が記述された印刷対象データのファイル、及びリソースファイルがアーカイブされた構造化文書形式のデータを受け取る受取手段と、
   前記受取手段で上位処理から受け取る構造化文書形式のデータを、先頭から検索する第１の検索手段と、
   前記第１の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を記憶する第１の記憶手段と、
   次に処理する印刷対象データのファイルを検索するために、前記第１の検索手段で構造化文書形式のデータを先頭から検索することなく、前記第１の記憶手段に記憶されている配置位置から、前記受取手段で上位処理より受け取る構造化文書形式のデータを検索する第２の検索手段と、
   前記第２の検索手段の検索によって得られる前記印刷対象データのファイルの配置位置を更新する更新手段と、
   前記第２の検索手段による検索を、前記印刷対象データのファイルに応じて繰り返す繰返制御手段と、
   前記検索された印刷対象データを解析処理して得られる印刷描画データを出力する出力手段として機能させることを特徴とするプログラム。

Images