JP2014102577A - 印刷装置、印刷システム - Google Patents

Abstract

【課題】プリンタエンジンの速度維持に必要な場合のみ、画像生成サーバを効率よく使用することで、限られた計算機リソースを効率よく使用しつつ、プリンタエンジンの速度ダウンを極力防ぐことができる印刷装置、及び印刷システムを提供する。
【解決手段】
印刷装置は、印刷データを解析し、画像生成部が行うＲＩＰ処理によって生成されるラスタ画像の生成速度が、プリンタエンジンの画像形成速度よりも遅い場合は、印刷データの一部に対するＲＩＰ処理を、所定の画像生成サーバに代行させ、トータルでのラスタ画像の生成速度を高速化する。
【選択図】図１

Description

本発明は、画像生成サーバを利用する印刷装置、及びその印刷システムに関する。

デジタル画像処理機能を応用した印刷機が、一般オフィスのみならず出版・商業印刷等の、より高い画質及び生産性が要求される分野にも浸透しつつある。このデジタル印刷機は、ＰＤＬ（Page Description Language、ページ記述言語）形式の印刷データから電子形式のラスタ画像を生成するプリンタコントローラと、このプリンタコントローラが生成したラスタ画像に基づいて紙媒体上に実画像を形成し最終印刷物の出力を行うプリンタエンジンを組み合わせた構成が一般的である。

ＰＤＬには、PostScript(登録商標)、ＰＤＦ(Portable Document Format)、ＰＣＬ(Printer Control Language)６、ＸＰＳ（XML Paper Specification）、ＰＰＭＬ(Personalized Print Markup Language)などの種別があるが、商業印刷向けデジタル印刷機では、高品位印刷向け言語とされて来たPostScriptと基本的に同様のイメージングモデルを持ちながら、さらに言語仕様として透明効果や色空間定義の追加が行われ画像表現力/再現力が一層強化されているＰＤＦが比較的良く用いられ、また特に内容の一部を差し替えながら印刷を行うバリアブル印刷に対応すべく再利用オブジェクトの定義、及びそのメモリキャッシングと合成の概念が導入されたＰＰＭＬなどもまた比較的良く用いられる。

プリンタコントローラが行うラスタ画像の生成処理は、ＲＩＰ(Raster Image Processing)処理などと呼ばれ、一般的に、特にフルカラー画像の印刷を行うシステムなどにおいてはこのＲＩＰ処理において多くのＣＰＵ(Central Processing Unit)等の計算機リソースを消費する。このため、プリンタコントローラの能力とプリンタエンジンの能力のバランス、あるいは印刷データにおける１ページあたりのデータ量の多さなどによっては、ラスタ画像の生成速度がプリンタエンジンの印刷出力速度を下回る場合がある。

たとえば、プリンタエンジンの能力（印刷出力速度）は、Ａ４サイズの長辺給紙において８０PPM(Pages Per Minute)、つまり1分間に８０ページの印刷出力が可能である、というように一般的に表現される。この例で言えば、プリンタコントローラが１分間に８０ページ分以上のＡ４ラスタ画像の生成を行いプリンタエンジンに供給できていれば、プリンタエンジンの印刷出力は最大速度の状態で保たれる。しかし、プリンタコントローラが１分間にプリンタエンジンに供給できるＡ４ラスタ画像の数が８０ページ分未満である場合、ラスタ画像の供給速度がボトルネックとなり、プリンタエンジンの印刷出力は最大速度が保たれず、速度ダウンが発生することとなる。

１ページ分のラスタ画像（以後、ページラスタ画像と呼ぶ）を生成するために要する時間は、そのページに配置されるオブジェクトを画素データに展開する際のデータ量及びその際に必要となる計算量に大きく影響を受ける。オブジェクトには、スキャナやデジタルカメラなどによりデジタル化され取り込まれたイメージオブジェクトや、方程式表現された曲線/直線などにより表される文字オブジェクト(アウトラインフォントデータ)やベクタグラフィックオブジェクトなどの種別があり、これらをプリンタ解像度やその色空間/色深度などを考慮しプリンタ向けラスタ画像データ内に画素表現データとしてマッピングして行く際のデータ量が多い場合、またそのために必要となる計算量が多い場合は、そのページに対するラスタ画像の生成に比較的大きな時間を要する。こラスタ画像の生成に大きな時間がかかる場合、プリンタエンジンの印刷の出力速度に見合った画像供給ができず、前述の速度ダウンが発生する可能性も高くなる。そこで、このような速度ダウンの発生を防ぐ方法が複数提案されている。

たとえば、特許文献１には、印刷装置内に、並列処理を行う為のハードウェアを内蔵し、これを用いて処理を高速化する方法が記載されている（特許文献１）。

特開２０１１−８３９１４号公報 特開２０１１−２５３３３７号公報

特許文献１に開示の方法では、ＲＩＰ処理の高速化を図り、プリンタエンジンの速度ダウンの発生を極力防ぐことができる。しかし、ラスタ画像の生成速度は、投入される印刷データの内容によって変動するため、ラスタ画像の生成速度とプリンタエンジンの印刷出力速度の比率は常に一定であるわけではない。並列処理を行わなくともプリンタエンジンの速度ダウンが発生しないようなデータ量の少ない印刷データが投入される場合、一時的にデータに対し過剰な性能を持つハードウェア資源が存在し、その一部が遊休している状態が発生することになる。

また、特許文献２には、内蔵のハードウェアではなく、クラウドサーバを使用して並列処理を行う方法が開示されている。クラウドとは、クラウドコンピューティング環境におけるサーバ群が配置される領域のことである。クラウドコンピューティング環境においては、ユーザはコンピュータ処理をネットワーク経由でサービスとして利用する。この方法では、印刷ジョブに含まれる印刷データを分割した分割ジョブを作成し、その分割ジョブの一部に対するＲＩＰ処理等（特許文献２では印刷データ変換処理と記す）をクラウドサーバに依頼している。しかし、特許文献２に開示の方法では、使用可能な全てのクラウドサーバを使用して並列処理を行う。これでは、並列処理を行わなくともプリンタエンジンの速度ダウンが発生しないようなデータ量の少ない印刷データが投入された場合、不必要であるにもかかわらず、クラウドサーバを使用して並列処理を行うことになる。

なお、クラウドサーバが混んでいる場合、クラウドサーバの処理能力は低下する。クラウドサーバの処理能力が低下している状態では、クラウドサーバに処理を依頼する場合の方が、クラウドサーバに処理を依頼しない場合と比べて処理効率が低いことがある。

本発明は、上記の問題を解決するものであり、プリンタエンジンの速度維持に必要な場合のみ、画像生成サーバを効率よく使用することで、限られた計算機リソースを効率よく使用しつつ、プリンタエンジンの速度ダウンを極力防ぐことができる印刷装置及び印刷システムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。

［１］印刷データに基づいてラスタ画像を生成するＲＩＰ処理を行うラスタ画像生成部と、
前記ラスタ画像生成部によって生成されたラスタ画像に基づいて用紙上に画像形成するプリンタエンジンと、
前記ラスタ画像生成部によるラスタ画像の生成速度が、前記プリンタエンジンの画像形成速度を下回っていると判断した場合に、前記印刷データに対する前記ＲＩＰ処理の一部をネットワーク上の所定の画像生成サーバに代行させ、前記ラスタ画像生成部によって生成されたラスタ画像と前記画像生成サーバから前記代行の結果として受信したラスタ画像とに基づいて前記プリンタエンジンに画像形成を行わせる制御部と、
を有する
ことを特徴とする印刷装置。

上記発明では、画像生成部によるラスタ画像の生成速度が、プリンタエンジンの画像形成速度を下回っていると判断した場合に、ＲＩＰ処理の一部を画像生成サーバに代行させることで、印刷データに対するＲＩＰ処理を、画像生成部と画像生成サーバとで並列的に行う。これによりトータルのラスタ画像の生成速度が高速化され、プリンタエンジンの速度ダウンを極力防ぐことができる。なお、印刷装置単体（画像生成部単体）でのラスタ画像の生成速度が、プリンタエンジンの画像形成速度を下回っていない場合は、印刷装置のみでＲＩＰ処理を行う。プリンタエンジンの速度維持に必要な場合のみ、画像生成サーバを使用することで、限られた計算機リソースを効率よく使用しつつ、プリンタエンジンの速度ダウンを極力防ぐことができる。

［２］前記制御部は、前記画像生成サーバの負荷状況に応じて、前記画像生成サーバに代行させる処理量を決定する
ことを特徴とする［１］に記載の印刷装置。

上記発明では、画像生成サーバに代行させるＲＩＰ処理の処理量は、画像生成サーバの負荷状況に応じて決定する。画像生成サーバが混みあっている場合、画像生成サーバの処理能力が低下するので、ＲＩＰ処理の代行を依頼する際の処理能力に応じて、その依頼する処理量を決定する。これにより、画像生成サーバの処理能力に見合った処理量を依頼することが可能となる。

［３］前記制御部は、前記画像生成サーバに前記ＲＩＰ処理の代行を依頼してからその代行結果のラスタ画像を受信するまでの時間に基づいて前記画像生成サーバの負荷状況を判断する
ことを特徴とする［２］に記載の印刷装置。

上記発明では、画像生成サーバに所定の処理量を依頼してから、その処理結果を受信するまでの時間によって、画像生成サーバの処理能力（負荷状況）を判断する。

［４］前記制御部は、前記ラスタ画像生成部によるラスタ画像の生成が前記プリンタエンジンの画像形成に間に合わない分のＲＩＰ処理を上限にして、前記画像生成サーバに代行させる処理量を決定する
ことを特徴とする［１］乃至［３］のいずれか１つに記載の印刷装置。

上記発明では、画像生成部によるラスタ画像の生成がプリンタエンジンの画像形成に間に合う分のＲＩＰ処理は、画像生成部に行わせ、足りない分（間に合わない分）のＲＩＰ処理を上限として画像生成サーバに代行させるようにして依頼量を決定する。これにより、印刷装置のハードウェアリソースを可能な限り使用しつつ、プリンタエンジンの速度ダウンの発生を極力抑えることができる。

［５］前記制御部は、前記上限を越えない範囲で、前記画像生成サーバでの処理時間と前記ラスタ画像生成部での処理時間が等しくなるように、前記画像生成サーバに代行させる処理量を決定する
ことを特徴とする［４］に記載の印刷装置。

上記発明では、画像生成サーバに印刷データの一部に対するＲＩＰ処理を代行させても、そのトータルでのラスタ画像の生成速度がプリンタエンジンの画像形成速度に満たない場合は、画像生成部に割り当てる処理にかかると予測される時間（Ｘとする）と、画像生成サーバに割り当てる処理にかかると予測される時間（Ｙとする）が等しくなるように（Ｘ＝Ｙとなるように）、それぞれの処理分配量を決定する。これにより、最も高速なラスタ画像の生成を可能とする。

［６］前記制御部は、前記画像生成サーバに代行させる処理量を、ページ単位に増減させる
ことを特徴とする［１］乃至［５］のいずれか１つに記載の印刷装置。

［７］前記印刷データは、ページ記述言語で記述された印刷データである
ことを特徴とする［１］乃至［６］のいずれか１つに記載の印刷装置。

上記発明では、印刷データはページ記述言語で記述された印刷データである。たとえば、ＰＰＭＬ、ＰＤＦ、ＸＰＳ等の形式のデータで構成される。

［８］［１］乃至［６］のいずれか１つに記載の印刷装置と、
前記印刷装置から依頼されたＲＩＰ処理を行って、その結果物であるラスタ画像を前記印刷装置へ送信する画像生成サーバと、
を有する
ことを特徴とする印刷システム。

本発明に係る印刷装置及び印刷システムによれば、プリンタエンジンの速度維持に必要な場合のみ、画像生成サーバを使用することで、限られた計算機リソースを効率よく使用しつつ、プリンタエンジンの速度ダウンを極力防ぐことができる。

本発明の実施の形態に係る印刷システムの一例を示す説明図である。 本発明の実施の形態に係るクライアントシステムの一例を示す説明図である。 本発明の実施の形態に係る印刷装置の概略構成を示すブロック図である。 本発明の実施の形態に係るクライアント端末の概略構成を示すブロック図である。 本発明の実施の形態に係るネットワーク間接続装置の概略構成を示すブロック図である。 本発明の実施の形態に係るクラウドサービスシステムの一例を示す説明図である。 本発明の実施の形態に係る画像生成サーバの概略構成を示すブロック図である。 非バリアブルの印刷物と、バリアブルの印刷物の一例を示す説明図である。 ＰＰＭＬデータの記述を簡単に示した例を示す説明図である。 図９のＰＰＭＬデータによって参照されるＰＤＦデータの一例を示す説明図である。 印刷システムの機能構成を示すブロック図である。 印刷システムが印刷を行う際の処理の流れ図である。 図１２の処理の続きを示す流れ図である。 図１３の処理の続きを示す流れ図である。 並列ＲＩＰ処理を行う際のタイムチャートを示す説明図である。

以下、図面に基づき本発明の実施の形態を説明する。

図１は、本発明の実施の形態に係る印刷システム５を示す。印刷システム５は、複数のクライアントシステム７（７Ａ、７Ｂ、７Ｃ）と、クラウドサービスシステム６がＷＡＮ（Wide Area Network）４を介して接続されて構成されている。なお、クライアントシステム７Ａ、７Ｂ、７Ｃのうち、任意のいずれか１つを指す場合は、クライアントシステム７と示す。

クライアントシステム７は、印刷データに基づいて印刷を行う。印刷を行う際には、印刷データに対してＲＩＰ処理を行い、そのＲＩＰ処理で生成されたラスタ画像の示す画像を後述のプリンタエンジン２０にて記録紙上に画像形成する。また、クライアントシステム７は、印刷データの一部に対するＲＩＰ処理をクラウドサービスシステム６に代行させる機能を果たす。クライアントシステム７で行われるＲＩＰ処理と、クラウドサービスシステム６で行うＲＩＰ処理を並列的に行うことで、ＲＩＰ処理の高速化を図ることができる。

図２は、クライアントシステム７の構成を示す。クライアントシステム７は、印刷装置１０Ａ、印刷装置１０Ｂと、クライアント端末４０と、ネットワーク間接続装置５０が、ＬＡＮ（Local Area Network）３で接続されて構成されている。なお、印刷装置１０Ａ、１０Ｂのうち、任意のいずれか１つを指す場合は、印刷装置１０と示す。

印刷装置１０は、クライアント端末４０から送出された印刷データに係る画像を記録紙に画像形成して出力する印刷ジョブを実行する機能を備えている。

クライアント端末４０は、印刷ジョブを印刷装置１０に投入する役割を果たす、所謂、ＰＣ（Personal Computer）端末である。

ネットワーク間接続装置５０は、図１に示すＷＡＮ４を介してクラウドサービスシステム６とクライアントシステム７を接続する役割を果たす。印刷装置１０がクラウドサービスシステム６とデータの送受信を行う際には、そのデータはネットワーク間接続装置５０を経由する。

図３は、本発明の実施の形態に係る印刷装置１０の概略構成を示す。印刷装置１０は、当該印刷装置１０の動作を統括的に制御するＣＰＵ１１を有している。ＣＰＵ１１にはシステムバスを通じてフラッシュメモリ１２と、ＲＡＭ(Random Access Memory)１３と、ハードディスク装置１４と、画像生成部１５と、ネットワークＩ／Ｆ（Interface）部１６と、VideoＩ／Ｆ１７と、プリンタエンジン２０を備えている。

ＣＰＵ１１は、ＯＳ（Operating System）プログラムをベースとし、その上で、ミドルウェアやアプリケーションプログラムなどを実行する。

フラッシュメモリ１２には、各種のプログラムが格納されており、これらのプログラムに従ってＣＰＵ１１が各種処理を実行することで印刷装置１０の各機能が実現される。また、フラッシュメモリ１２には、印刷装置１０の一連の制御をＣＰＵ１１が実行するためのプログラムが格納されている。

ＲＡＭ１３は、ＣＰＵ１１がプログラムに基づいて処理を実行する際に各種のデータを一時的に格納するワークメモリや画像データを格納する画像メモリなどとして使用される。

ハードディスク装置１４は、大容量の不揮発の記憶装置であり、ＯＳプログラムや各種アプリケーションプログラム、ユーザ情報、画像データ、ネットワークＩ／Ｆ部１６が受信した印刷ジョブ（印刷データ）等が保存される。

ネットワークＩ／Ｆ部１６は、ＬＡＮ３のネットワークを通じてクライアント端末４０等との間でデータを通信する機能を果たす。たとえば、クライアント端末４０から印刷ジョブ（印刷データ）を受信する場合、あるいはクライアントシステム７の外部の装置と通信を行う場合は、ネットワーク間接続装置５０を介してデータの送受信を行う。

画像生成部１５は、画像の拡大縮小、回転などの処理のほか、印刷データをイメージデータに変換するラスタライズ処理（ＲＩＰ処理）、画像データの圧縮、伸張処理などを行う。クライアント端末４０から受信した印刷ジョブに含まれる印刷データに対してＲＩＰ処理を行い、ラスタ画像を生成する。なお、印刷データは、ＰＤＬ形式のデータであって、ＰＤＦデータやＰＰＭＬデータで構成されている。

プリンタエンジン２０は、ラスタ画像の示す画像を記録紙上に画像形成する機能を果たす。ここでは、記録紙の搬送装置と、感光体ドラムと、帯電装置と、レーザーユニットと、現像装置と、転写分離装置と、クリーニング装置と、定着装置とを有し、電子写真プロセスによって画像形成を行う、所謂、レーザープリンタとして構成されている。画像形成プロセスは他の方式でもかまわない。

ＣＰＵ１１、フラッシュメモリ１２、ＲＡＭ１３、ハードディスク装置１４、画像生成部１５、ネットワークＩ／Ｆ部１６、VideoＩ／Ｆ１７をまとめてプリンタコントローラとする。VideoＩ／Ｆ１７は、プリンタコントローラとプリンタエンジン２０間でのデータの送受信を行う。画像生成部１５で生成されたラスタ画像はVideoＩ／Ｆ１７を介してプリンタエンジン２０に送られる。

印刷装置１０がクライアント端末４０から印刷ジョブを受信したら、ＣＰＵ１１は、その印刷ジョブに含まれる印刷データを解析する。この解析では、ＲＩＰ処理を開始してからラスタ画像をプリンタエンジン２０に供給するまでの速度（ラスタ画像供給速度とする）を調べる。プリンタエンジン２０の印刷出力速度よりもラスタ画像供給速度の方が遅い場合は、プリンタエンジン２０の印刷出力は最大速度が保たれず、速度ダウンが発生すると判断する。ＣＰＵ１１は、速度ダウンが発生すると判断した場合、印刷データの一部に対するＲＩＰ処理をクラウドサービスシステム６に代行させる。クラウドサービスシステム６が代行するＲＩＰ処理は、画像処理部１５の行うＲＩＰ処理と並列的に行われるため、以後、この代行するＲＩＰ処理を、並列ＲＩＰ処理と呼ぶ。ラスタ画像の生成を、画像生成部１５とクラウドサービスシステム６にて並列的に行うことで、ＲＩＰ処理の高速化を図り、プリンタエンジン２０の速度ダウンの発生を防ぐことができる。また、代行させる処理量（並列ＲＩＰ処理で依頼する処理量）は、画像生成部１５によるラスタ画像の生成がプリンタエンジン２０の画像形成に間に合わない分のＲＩＰ処理を上限にして決定する。また、クラウドサービスシステム６の処理能力（負荷状況等）に応じてその処理量を増減させる。

なお、図示を省略しているが、印刷装置１０は、操作パネルが備えられている。操作パネルは、表示部と操作部で構成される。操作部は、スタートボタンなどのスイッチ部とタッチパネル部とを備えている。表示部は、液晶ディスプレイ（ＬＣＤ…Liquid Crystal Display）などで構成され、各種の操作画面、設定画面などを表示する機能を果たす。タッチパネル部は、表示部上に設けられている。タッチパネル部は、タッチペンや指などで押下された表示部上の座標位置や、フリック操作やドラッグ操作等を検出する。ユーザはクライアント端末４０、もしくは操作パネルに対して操作を行うことで、印刷装置１０にジョブの実行等の指示を出すことができる。

図４は、クライアント端末４０の概略構成を示す。クライアント端末４０は、当該クライアント端末４０の動作を統括的に制御するＣＰＵ４１を有している。ＣＰＵ４１にはシステムバスを通じてＲＡＭ４２と、ハードディスク装置４３と、ネットワーク通信部４４と、入力Ｉ／Ｆ４５と、キーボード４６と、ポインティングデバイス４７と、出力Ｉ／Ｆ４８と、モニタ４９を備えている。

ＣＰＵ４１は、ＯＳプログラムをベースとし、その上で、ミドルウェアやアプリケーションプログラムなどを実行する。

ハードディスク装置４３は、大容量の不揮発の記憶装置であり、ＯＳプログラム等の各種のプログラムが格納されており、これらのプログラムに従ってＣＰＵ４１が各種処理を実行することでクライアント端末４０の各機能が実現される。

ＲＡＭ４２は、ＣＰＵ４１がプログラムに基づいて処理を実行する際に各種のデータを一時的に格納するワークメモリや画像データを格納する画像メモリなどとして使用される。実施の形態では、ハードディスク装置４３から印刷ジョブ（印刷データ）を作成するためのプログラムがロードされ、ＣＰＵ４１によって実行される。

ネットワーク通信部４４は、ＬＡＮ３を通じて印刷装置１０とネットワーク間接続装置５０との間でデータを通信する機能を果たす。

キーボード４６、ポインティングデバイス４７（マウス等）は、操作部としての役割を果たし、キーボード４６、ポインティングデバイス４７が受け付けた操作内容は入力Ｉ／Ｆ４５がＣＰＵ４１に送信する。

モニタ４９は、液晶ディスプレイなどで構成され、出力Ｉ／Ｆ４８から出力される各種の操作画面、設定画面などを表示する表示部としての機能を果たす。

印刷ジョブ（印刷データ）を作成するためのプログラムは通常ＧＵＩ(Graphical User Interface)ベースのプログラムであり、キーボード４６及びポインティングデバイス４７が画像編集のため使用され、またその内容はモニタ４９において随時確認可能となる。

画像編集終了後は印刷ジョブ（印刷データ）の生成が行われ、生成された印刷ジョブ（印刷データ）はネットワーク通信部４４を経由し印刷装置１０へ送信される。

図５は、ネットワーク間接続装置５０の概略構成を示す。ネットワーク間接続装置５０は、当該ネットワーク間接続装置５０の動作を統括的に制御するＣＰＵ５１を有している。ＣＰＵ５１にはシステムバスを通じてフラッシュメモリ５２と、ＲＡＭ５３と、第１ネットワークＩ／Ｆ部５４と、第２ネットワークＩ／Ｆ部５５とを備えている。

ＣＰＵ５１は、ＯＳプログラムをベースとし、その上で、ミドルウェアやアプリケーションプログラムなどを実行する。

フラッシュメモリ５２は、電源をオフにしても記憶内容が破壊されないメモリである。フラッシュメモリ５２には各種のプログラムが格納されており、これらのプログラムに従ってＣＰＵ５１が各種処理を実行することでネットワーク間接続装置５０の各機能が実現される。他にも、ネットワーク間接続装置５０の各種設定情報等の保存に使用される。

ＲＡＭ５３は、ＣＰＵ５１がプログラムに基づいて処理を実行する際に各種のデータを一時的に格納するワークメモリなどとして使用される。具体的には、ネットワークパケット転送のためのプログラムが、フラッシュメモリ５２よりＲＡＭ５３にロードされ、ＣＰＵ５１において実行される。ＲＡＭ５３には、パケット転送のためのルーティング情報もまた存在し、ネットワークパケット転送のためのプログラムは、このルーティング情報に基づき第１ネットワークＩ／Ｆ部５４、あるいは第２ネットワークＩ／Ｆ部５５のうちの一方より受信したパケットを他方へ転送する処理を行う。

第１ネットワークＩ／Ｆ部５４は、ＬＡＮ３を通じて印刷装置１０とネットワーク間接続装置５０との間でデータを通信する機能を果たす。

第２ネットワークＩ／Ｆ部５５は、ＷＡＮ４を通じてクラウドサービスシステム６（後述のクラウドサービスシステム６を構成するネットワーク間接続装置５０、図６参照）との間でデータを通信する機能を果たす。

図６は、クラウドサービスシステム６の詳細を示す。クラウドサービスシステム６は、クラウドサーバとしての機能を果たす画像生成サーバ６０Ａと、画像生成サーバ６０Ｂと、ネットワーク間接続装置５０がＬＡＮ３を介して接続されて構成されている。なお、画像生成サーバ６０Ａ、６０Ｂのうち、任意のいずれか１つを指す場合は画像生成サーバ６０と示す。ＬＡＮ３とネットワーク間接続装置５０は、図２に示すものと同一構成であるが、図２に示すものとは別体である。

画像生成サーバ６０はラスタ画像の生成を行う役割を果たす。ネットワーク間接続装置５０を介して、印刷装置１０から並列ＲＩＰ処理の依頼（リクエストジョブ）を受信したら、受信したリクエストジョブに含まれる印刷データに対してＲＩＰ処理を行い、ラスタ画像を生成する。また、その生成したラスタ画像を、ネットワーク間接続装置５０を介して、印刷装置１０に送信する。

図７は、画像生成サーバ６０の概略構成を示す。画像生成サーバ６０は、当該画像生成サーバ６０の動作を統括的に制御するＣＰＵ６１を有している。ＣＰＵ６１にはシステムバスを通じてＲＡＭ６２と、ハードディスク装置６３と、ネットワーク通信部６４とを備えている。

ＣＰＵ６１は、ＯＳプログラムをベースとし、その上で、ミドルウェアやアプリケーションプログラムなどを実行する。ハードディスク装置６３は、大容量の不揮発の記憶装置であり、各種のプログラム（ラスタ画像を生成のためのプログラム等）や、受信したデータが格納される。また、これらのプログラムに従ってＣＰＵ６１が各種処理を実行することで画像生成サーバ６０の各機能が実現される。

ＲＡＭ６２は、ＣＰＵ６１がプログラムに基づいて処理を実行する際に各種のデータを一時的に格納するワークメモリや画像データを格納する画像メモリなどとして使用される。ラスタ画像を生成するためのプログラムは、ハードディスク装置６３からＲＡＭ６２にロードされた後、ＣＰＵ６１によって実行される。

ネットワーク通信部６４は、ＬＡＮ３を通じてネットワーク間接続装置５０との間でデータを通信する機能を果たす。並列ＲＩＰ処理の依頼（リクエストジョブ）は、ネットワーク通信部６４を通じて受信され、この内容に基づいて生成したラスタ画像もまたネットワーク通信部６４を通じてクライアントシステム７に送信される。

次に、印刷装置１０が取り扱う印刷データについて説明する。

印刷装置１０が印刷出力する印刷物は非バリアブルの印刷物と、バリアブルの印刷物に分けられる。図８（Ａ）は非バリアブルの印刷物の例を、図８（Ｂ）はバリアブルの印刷物の例を示す。図（Ａ）は、非バリアブルの印刷物としてポスターやチラシなど、大量に印刷される同一内容の印刷物を示す。図８（Ｂ）は、バリアブルの印刷物として、宛先毎に違った住所氏名が印刷されるダイレクトメールなど、内容の一部に可変する要素を含む印刷物を示す。

非バリアブルの印刷に適したデータ形式の代表的なものは、ＰＤＦ形式などであり、またバリアブルの印刷に適したデータ形式の代表的なものは、ＰＰＭＬ形式(ＰＰＭＬデータとＰＤＦデータをＺＩＰアーカイブした形式)のものである。図９は、図８（Ｂ）に挙げたバリアブルの印刷物を印刷する指示のＰＰＭＬデータを示し、図１０は、図９のＰＰＭＬファイルによって参照されるＰＤＦデータの例を示す。

ＰＰＭＬデータは、ＰＤＦデータの配置、配列を示すデータである。印刷を行う際には、ＰＰＭＬデータの示す配置、配列で、ＲＩＰ処理後のＰＤＦデータを並べて合成することによって、記録紙１ページに印刷されるラスタ画像（以後、ページラスタ画像と呼ぶ。）を生成する。ＰＰＭＬデータは、ＰＯＤｉ(Digital Printing Initiative)によりその仕様が規定されており、実際にはＰＰＭＬはＸＭＬ(Extensible Markup Language)形式での記述となるが、図９ではこれを理解し易く示している。

ＰＤＦデータは、複数ページにおいて繰り返し使用される再利用オブジェクトと、１ページのみに使用される一時利用オブジェクトの２種類がある。図９に示すように、ＰＰＭＬデータにおいては通常先頭部において再利用オブジェクトが宣言され、その後に各ページのレイアウト記述が続く構成となっている。各ページは一時利用オブジェクトのみ、あるいは一時利用オブジェクトと再利用オブジェクトから成る。図９の例では、ページ１のオブジェクト１、オブジェクト２、オブジェクト３が一時利用オブジェクトであり、オブジェクト４が再利用オブジェクトとなっている。ページ２以降も基本的に同様の記述が続くことになるが、一時利用オブジェクトの部分はページごとに可変となる。

図１０は、図９のＰＰＭＬデータより参照されるＰＤＦデータを示す。図１０は、ＰＤＦデータをViewer表示した際の各ページの内容を示している。ページ１は再利用オブジェクトとして利用されるものであり、ページ２〜４は一時利用オブジェクトとして利用される郵便番号、住所、氏名に対応する内容となっている。なお、ページ５以降には、内容が変化した一時利用オブジェクト、つまり各人に対応した郵便番号、住所、氏名の内容のデータが繰り返し現れることになる。

印刷装置１０は、先ず再利用オブジェクトをＲＩＰし、そのＲＩＰ処理によって生成されるラスタ画像（以後、キャッシュ画像と呼ぶ）をＲＡＭ１３にキャッシュする。その後、各ページの一時利用オブジェクトをＲＩＰし、そのＲＩＰ処理によって生成されるラスタ画像（以後、可変画像と呼ぶ）とキャッシュ画像を、ＰＰＭＬデータの示す配置、配列で合成することによって、ページラスタ画像を生成する。

次に、印刷データから、ページラスタ画像を生成する処理のための機能構成、及び処理の流れについて説明する。

図１１は、本発明の印刷システム５において、ＰＰＭＬデータからページラスタ画像を生成する処理を行う為の機能構成図である。なお、ここでは、ネットワーク間接続装置５０は省略している。

クライアントシステム７は、クライアント端末４０と印刷装置１０を含み、印刷装置１０は、ハードディスク装置１４と、スプーラスレッド８１と、再利用オブジェクト画像キャッシュメモリ８２と、送信スレッド８３と、ＰＰＭＬインタプリタスレッド８４と、ＰＳ（Post Script）/ＰＤＦインタプリタスレッド８５と、エンジン制御スレッド８６と、受信/エンジン転送スレッド８７と、フレームメモリ８８と、プリンタエンジン２０で構成されている。

スプーラスレッド８１は、クライアント端末４０から印刷ジョブ（印刷データ）を受信し、ハードディスク装置１４に格納する。

ＰＰＭＬインタプリタスレッド８４は、ハードディスク装置１４に格納された印刷データのＰＰＭＬデータによって、ページラスタ画像を生成する機能を持つ。また、必要時には、後述の送信スレッド８３を経由し、クラウドサービスシステム６へ並列ＲＩＰ処理を依頼するリクエストジョブを送信する。ページラスタ画像を生成する際には、再利用オブジェクトはＲＩＰし、キャッシュ画像としてキャッシュしておき、可変画像を生成したら、後述のフレームメモリ８８内でキャッシュ画像と合成する。

ＰＳ/ＰＤＦインタプリタスレッド８５は、印刷ジョブに含まれているＰＤＦファイルにＲＩＰ処理を行い、ラスタ画像（キャッシュ画像や、可変画像）を生成する機能を持つ。

フレームメモリ８８は、生成された可変画像及び合成済みページ画像を一時的に格納するために使用される。再利用オブジェクト画像キャッシュメモリ８２は、ＲＩＰされた再利用オブジェクト（キャッシュ画像）をキャッシュする際に使用される。

エンジン制御スレッド８６は、ページラスタ画像をプリンタエンジン２０へ転送する機能を持つ。

送信スレッド８３は、クラウドサービスシステム６へ並列ＲＩＰ処理を依頼するリクエストジョブを送信する機能をもつ。

受信/エンジン転送スレッド８７は、クラウドサービスシステム６から圧縮状態のページラスタ画像を受信し、フレームメモリ８８に格納し、伸張した後、エンジン制御スレッド８６へ通知する機能を持つ。

クラウドサービスシステム６は、画像生成サーバ６０を含み、画像生成サーバ６０は、ハードディスク装置６３と、受信スレッド９１、ＰＰＭＬインタプリタスレッド９２、フレームメモリ９３、ＰＳ/ＰＤＦインタプリタスレッド９４と、再利用オブジェクト画像キャッシュメモリ９５で構成されている。

受信スレッド９１は、送信スレッド８３からリクエストジョブを受信し、ハードディスク装置６３に格納する。

ＰＰＭＬインタプリタスレッド９２は、ハードディスク装置６３に格納されたリクエストジョブに含まれるＰＰＭＬデータに従って、ページラスタ画像を生成する機能を持つ。また、生成したページラスタ画像を圧縮し、クライアントシステム７に送信する。

ＰＳ/ＰＤＦインタプリタスレッド９４は、リクエストジョブに含まれているＰＤＦファイルをＲＩＰし、ラスタ画像（キャッシュ画像や可変画像）を生成する機能を持つ。

フレームメモリ９３は、生成された可変画像及び合成済みページ画像を一時的に格納するために使用される。再利用オブジェクト画像キャッシュメモリ９５は、ＲＩＰされた再利用オブジェクト（キャッシュ画像）をキャッシュする際に使用される。

なお、クラウドサービスシステム６は、図６に示すように複数台の画像生成サーバ６０が備えられていることがあり得る。この場合におけるリクエストジョブの振り分け方法について説明する。

複数の画像生成サーバ６０がある場合、ある１つの画像生成サーバ６０が代表サーバとなってリクエストジョブの受信を行い、自装置を含む各画像生成サーバ６０の負荷状況に基づき、受信したリクエストジョブのＲＩＰ処理を行う画像生成サーバ６０を決定し、その決定した画像生成サーバ６０へ受信したリクエストジョブの転送処理を行う。

なお、代表サーバとなった画像生成サーバ６０の受信スレッド９１は、リクエストジョブを受信した際、そのリクエストジョブが既にいずれかの画像生成サーバ６０にて処理中のリクエストジョブに係るものである場合は、その画像生成サーバ６０へ転送し、そうでない場合、処理中のジョブ数が少ない画像生成サーバ６０を選択して送信する。

以上が複数の画像生成サーバ６０間でのリクエストジョブの振り分けの方法であるが、以降の説明では、記述内容が過度に複雑とならないよう、振り分け処理についてはその記述を行わない。(単一の画像生成サーバ６０のみ存在するクラウドサービスシステム６を想定した記述を行う。)

次に、本発明の印刷システム５が、ページラスタ画像を生成する際に行う詳細な処理の流れについて説明する。図１２、図１３、図１４は印刷システム５においてページラスタ画像を生成する際に行う詳細な処理の流れを示す。なお、図１３、図１４には、クライアントシステム７で行われる処理と、クラウドサービスシステム６で行われる処理の流れを示しているが、後者の処理の流れは破線で囲み、前者の処理の流れと区別して示す。

先ず、クライアントシステム７においては、ＺＩＰアーカイブされたバリアブルデータ（印刷データ）を受信しハードディスク装置１４（図中ではＨＤＤと記す）へ格納する（ステップＳ１０１）。これは、スプーラスレッド８１（図１１参照）により実行される。

以下、ＰＰＭＬインタプリタスレッド８４を中心に実行される処理となる。ステップＳ１０２では、ハードディスク装置１４内に格納されたＺＩＰファイルを解凍し、ＰＰＭＬデータ及びＰＤＦデータを取得する。

ステップＳ１０３では、ステップＳ１０２で取得したＰＰＭＬデータが再利用オブジェクトとして示すＰＤＦデータをＲＩＰし（キャッシュ画像を生成し）、キャッシュメモリに格納する。なお、ページラスタ画像を生成する処理ではＰＰＭＬインタプリタスレッド８４を使用し、ＰＤＦデータをＲＩＰする処理では、ＰＳ/ＰＤＦインタプリタスレッド８５を使用するが、以下、都度の説明は省略する。

次に、１０ページ分のページラスタ画像を生成し、プリンタエンジン２０へ転送処理を行う（ステップＳ１０４）。ステップＳ１０４における処理は、具体的には、まず、処理対象ページの一時利用オブジェクトをＲＩＰし（可変画像を生成し）、当該ページに含まれる再利用オブジェクトに係るキャッシュ画像と、可変画像を合成する。その後、エンジン制御スレッド８６が、そのページラスタ画像をプリンタエンジン２０へ転送する。この一連の処理を、１０ページ分繰り返す。プリンタエンジン２０はこの転送されたページラスタ画像に基づいて印刷を行う。

ステップＳ１０４では、１０ページ分のページラスタ画像の生成に要した時間を計測しておく。次に、ＰＰＭＬインタプリタスレッド８４は、ステップＳ１０４で計測した時間の実測値から、１ページ分のページラスタ画像の生成速度（平均生成速度）を割り出し、プリンタエンジン２０の印刷速度より遅いか否かを判定する（ステップＳ１０５）。

プリンタエンジン２０の印刷速度は用紙サイズ及び給紙方向(用紙の長手/短手方向)により予め決まっており、この速度数値と比較する。平均生成速度がプリンタエンジン２０の印刷速度以上であれば（ステップＳ１０５；Ｙｅｓ）、印刷が終了したか否かの判定を行い（ステップＳ１０６）、印刷終了であれば（ステップＳ１０６；Ｙｅｓ）、処理を終了する。印刷終了でない場合は（ステップＳ１０６；Ｎｏ）、ステップＳ１０４に戻って処理を継続する。

ここで、１０ページ分のページラスタ画像の生成に要した時間から求めた、ページラスタ画像の平均生成速度と、プリンタエンジン２０の印刷速度を比較するのは、特にバリアブル印刷データでは複数ページの異なったデータ量を持つページ群が周期的に繰り返し現れるケースが多く見られ、処理時間を平均化することが望ましいためである。

このように、平均生成速度がプリンタエンジン２０の印刷速度を上回っている限りは、クライアントシステム７内で処理が完結する。

ステップＳ１０５において、ラスタ画像供給速度がプリンタエンジン２０の印刷速度を下回っているとの判定となった場合（ステップＳ１０５；Ｎｏ）、印刷データの一部に対するＲＩＰ処理をクラウドサービスシステム６に代行させる処理を開始する。

まず、図１３のステップＳ１０７にて、ＰＰＭＬインタプリタスレッド８４は、印刷データ（ＰＰＭＬデータ、ＰＤＦデータ）における再利用オブジェクトに係る部分（記述等）を抽出してＺＩＰアーカイブし、クラウドサービスシステム６へ送信する。

次に、クライアントシステム７とクラウドサービスシステム６の処理配分、つまり、クラウドサービスシステム６に並列ＲＩＰ処理を依頼する処理量（依頼量）を決定する（ステップＳ１０８）。なお、ここで決定する依頼量は初期値である。並列ＲＩＰ処理の依頼は、以後、繰り返し行われ、その度に画像生成サーバ６０の混み具合（負荷状況）等によって、依頼量は増減される。なお、実施の形態では、依頼量はページ単位で決定する。

この依頼量の初期値は、画像生成部１５によるラスタ画像の生成がプリンタエンジン２０の画像形成に間に合わない分を上限として決定される。基本的には、間に合う分のＲＩＰ処理は、引き続き画像生成部１５に行わせ、足りない分（間に合わない分）をクラウドサービスシステム６に代行させるものとする。

具体的な依頼量は、ＰＰＭＬインタプリタスレッド８４が、クライアントシステム７とクラウドサービスシステム６で行う処理の分配量を決め、分配量が決定することで依頼量の初期値が決定する。先ずステップＳ１０４において実行した１０ページ分のページラスタ画像の生成に要した時間より、プリンタエンジン２０の印刷速度に対するプリンタコントローラの生産性比率を算出する。

１０ページ分のページラスタ画像の生成時間をＮ(秒)とし、プリンタエンジン２０の印刷速度をＳ(PPM)、求めるべき生産性比率をＲとすると、
式「Ｒ＝６０×１０÷Ｎ÷Ｓ」
に対し具体的数値を代入することによりＲが算出可能となる。次に、この生産性比率（Ｒ）をもとに処理の分配量を決定することになる。１５ページ単位で以降の並列ＲＩＰ処理の依頼を繰り返すこととし、クライアントシステム７側の配分をＣ(ページ)とすると、
「Ｃ＝１５×Ｒ」(切り捨てにより整数値化)
となり、クラウドサービスシステム６側の配分は、「１５−Ｃ」により求められる。たとえば、印刷速度（Ｓ）が６０PPM、生成時間（Ｎ）が１５秒であった場合、生産性比率Ｒは、０．６６６…となり、クライアントシステム７側の配分Ｃは１０ページ、クラウドサービスシステム６側配分は５ページとなる。このようにして、クラウドサービスシステム６に依頼する並列ＲＩＰ処理の依頼量の初期値を決定する。

なお、並列ＲＩＰ処理によってラスタ画像の生成を高速化しても、その生成速度がプリンタエンジン２０の画像形成速度に満たない場合は、画像生成部１５に割り当てる処理にかかると予測される時間（Ｘとする）と、クラウドサービスシステム６に割り当てる処理にかかると予測される時間（Ｙとする）が等しくなるように（Ｘ＝Ｙとなるように）処理を割り振る。

次にＰＰＭＬインタプリタスレッド８４は、ステップＳ１０８で決定した依頼量に基づいて、クラウドサービスシステム６に依頼する並列ＲＩＰ処理で使用するＰＰＭＬデータ及びＰＤＦデータをＺＩＰアーカイブし、クラウドサービスシステム６へ転送する（ステップＳ１０９）。

ここで、一度クラウドサービスシステム６（画像生成サーバ６０）で行われる処理の流れの説明に移る。まず、クラウドサービスシステム６は、起動後、先ず画像生成サーバ６０がクライアントシステム７からの接続を待つ状態となる（ステップＳ２０１）。

クライアントシステム７のステップＳ１０７の動作において接続が行われると、クラウドサービスシステム６はＺＩＰアーカイブを受信し、ハードディスク装置６３へ格納する（ステップＳ２０２）。これは、受信スレッド９１が行う動作となる。

次にＰＰＭＬインタプリタスレッド９２はハードディスク装置６３へ格納されたＺＩＰアーカイブファイルの解凍を行い、ＰＰＭＬデータ及びＰＤＦデータを抽出する（ステップＳ２０３）。ここで抽出したＰＰＭＬデータ及びＰＤＦデータは、再利用オブジェクトに係るデータのみが含まれている。

次にＰＰＭＬインタプリタスレッド９２は、ＰＳ/ＰＤＦインタプリタスレッド９４の機能を利用し、抽出したＰＰＭＬデータ及びＰＤＦデータからキャッシュ画像を生成し、生成したキャッシュ画像を再利用オブジェクト画像キャッシュメモリ９５へ格納する（ステップＳ２０４）。

次に、クライアントシステム７のステップＳ１０９でクライアントシステム７から送信されたＺＩＰアーカイブを受信し、ハードディスク装置６３へ格納する（ステップＳ２０５）。これは、受信スレッド９１が行う動作となる。

次に、図１４のステップＳ２０６では、クラウドサービスシステム６に割り当てられた分のページラスタ画像の生成処理を行う。具体的には、先ずＰＰＭＬインタプリタスレッド９２において、ステップＳ２０５でハードディスク装置６３に格納したＺＩＰアーカイブファイルの解凍を行う。その解凍によって得たＰＰＭＬデータ及びＰＤＦデータから、処理対象ページの一時利用オブジェクトをＲＩＰし、可変画像を生成する。当該ページに含まれる再利用オブジェクトに係るキャッシュ画像を再利用オブジェクト画像キャッシュメモリ９５から読み出して、フレームメモリ９３にて可変画像とキャッシュ画像を合成し、ページラスタ画像を生成する。

その後、その生成したページラスタ画像を圧縮した後、ＷＡＮ４経由でクライアントシステム７へ送信（返却）する（ステップＳ２０７）。なお、ステップＳ２０６、ステップＳ２０７の各ステップは、クラウドサービスシステム６に割り当てられたページ数分繰り返される。

クライアントシステム７の動作の説明に戻る。図１４のステップＳ１１０では、クラウドサービスシステム６のステップＳ２０６の動作と並行して、クライアントシステム７に割り当てたページ分のページラスタ画像を生成し、プリンタエンジン２０への転送を行う。これは具体的には、ステップＳ１０４において行われるものと同様の処理を、割り当てページ数分繰り返して行うことになる。

受信/エンジン転送スレッド８７は、クラウドサービスシステム６より送信/返却されたページラスタ画像（圧縮されている状態）を受信し、フレームメモリ８８へ格納する（ステップＳ１１１）。

次に、フレームメモリ８８に格納したページラスタ画像（圧縮されている状態）に伸張処理を行い、その伸張処理後のページラスタ画像をエンジン制御スレッド８６の機能を利用することによりプリンタエンジン２０への転送を行う（ステップＳ１１２）。なお、ステップＳ１１１、ステップＳ１１２の各ステップもまた、クラウドサービスシステム６に割り当てたページ数分繰り返される。

次に、ＰＰＭＬインタプリタスレッド８４は、全データの処理が終了したか否か（印刷が終了したか否か）の判定を行い（ステップＳ１１３）、終了した場合は（ステップＳ１１３；Ｙｅｓ）処理を終了する。

全データが終了していない場合は（ステップＳ１１３；Ｎｏ）、残りの印刷データを処理するにあたって、クライアントシステム７と、クラウドサービスシステム６で行う処理の分配量を再調整する。

依頼量を調整する際には、ステップＳ１０８の時と同じく、Ｘ≧Ｙとなるように（画像生成部１５に割り当てる処理にかかると予測される時間をＸとし、クラウドサービスシステム６に割り当てる処理にかかると予測される時間をＹとする）それぞれに割り振る処理量を調整する。並列ＲＩＰ処理によってラスタ画像の生成を高速化しても、その生成速度がプリンタエンジン２０の画像形成速度に満たない場合は、Ｘ＝Ｙとなるように依頼量を調整する。

まず、ＰＰＭＬインタプリタスレッド８４は、クライアントシステム７とクラウドサービスシステム６のそれぞれに割り当てた分のＲＩＰ処理に要した時間を比較する。

クライアントシステム７に割り当てたＲＩＰ処理に要した時間と、クラウドサービスシステム６に割り当てたＲＩＰ処理に要した時間が同じであれば（ステップＳ１１４；Ｙｅｓ）、ステップＳ１１８に進む。

クライアントシステム７に割り当てたＲＩＰ処理に要した時間と、クラウドサービスシステム６に割り当てたＲＩＰ処理に要した時間が同じでない場合（ステップＳ１１４；Ｎｏ）、クライアントシステム７に割り当てたＲＩＰ処理に要した時間が、クラウドサービスシステム６に割り当てたＲＩＰ処理に要した時間よりも多ければ（ステップＳ１１５；Ｎｏ）、次回のリクエストジョブにおける並列ＲＩＰ処理の依頼量を加算して（ステップＳ１１７）、つまり、クラウドサービスシステム６に割り当てる処理量を加算し、ステップＳ１１８に進む。

クライアントシステム７に割り当てたＲＩＰ処理に要した時間が、クラウドサービスシステム６に割り当てたＲＩＰ処理に要した時間よりも少なければ（ステップＳ１１５；Ｙｅｓ）、次回のリクエストジョブにおける並列ＲＩＰ処理の依頼量を減算して（ステップＳ１１６）、ステップＳ１１８に進む。

ステップＳ１１５〜ステップＳ１１７は、基本的には、クラウドサービスシステム６の処理能力（負荷状況）等に対応して、並列ＲＩＰ処理の依頼量を調整する位置付けとなる。画像生成サーバ６０は、負荷状況（混み具合等）に応じて処理能力が変化するので、ステップＳ１０９で依頼した依頼量を消化するまでに要した時間から、画像生成サーバ６０の処理能力を判断し、次回依頼する際の依頼量を調整している。

ステップＳ１１８では、ＰＰＭＬインタプリタスレッド８４が、プリンタコントローラ（クライアントシステム７）の処理能力に余裕が生じているか否かの判定を行う。余裕が生じていれば（ステップＳ１１８；Ｙｅｓ）、次回のリクエストジョブにおける並列処理の依頼量を減算して（ステップＳ１１９）、ステップＳ１０９に戻って処理を継続する。

ステップＳ１１９は、ステップＳ１１４〜ステップＳ１１７において行った次回のリクエストジョブにおける並列ＲＩＰ処理の依頼量の補正処理（加算、減算）によって生じたプリンタコントローラ（クライアントシステム７）の処理能力の余裕に対する再補正処理、あるいは印刷ジョブ中のデータの重さの変化によって生じたプリンタコントローラの能力の余裕に対する補正処理の位置付けとなる。クライアントシステム７の画像生成部１５によるラスタ画像の生成がプリンタエンジン２０の画像形成に間に合う分のＲＩＰ処理は、全て画像生成部１５で行うことが望ましいので、プリンタコントローラに余裕があれば、その分だけ処理量を増やし、クラウドサービスシステム６に割り当てる依頼量を減算する。

具体的には、ステップＳ１１０における１ページ分の平均処理時間に、ステップＳ１１４〜ステップＳ１１７の補正（加算、減算）後のクライアントシステム７に割り当てられたページ数を乗じた値が、ステップＳ１０８にて取得した１０ページ分（初期値を決定した際に割り振られたページ分）のページラスタ画像を生成するまでにかかった時間を下回っていないか否かを判定し、下回っている場合は、両値が近似となるように、クラウドサービスシステム６に割り当てるページ数を減算し、その減算値をクライアントシステム７に割り当てるページ数に加算する。

ステップＳ１１８にてプリンタコントローラに余裕がない場合（ステップＳ１１８；Ｎｏ）、あるいはステップＳ１１９にてクラウド割当ての再補正を行った後には、ステップＳ１０９に戻って処理を継続する。

図１５は、印刷システム５が並列ＲＩＰ処理を行う場合における、並列ＲＩＰ処理の流れをタイムチャート形式で示したものである。図１５の示すタイムチャートは図１２〜図１４の処理の流れにおける、ステップＳ１０７〜ステップＳ１１９、及びステップＳ２０２〜ステップＳ２０７に該当する。

図１５におけるＡ、Ｂ、Ｃはクライアントシステム７に含まれている部位であり、Ａ＝ＰＰＭＬインタプリタスレッド８４（図１１参照）、Ｂ＝送信スレッド８３（図１１参照）、Ｃ＝受信/エンジン転送スレッド８７（図１１参照）を表す。図１５、Ｄは、クラウドサービスシステム６に含まれている部位であり、Ｄ＝ＰＰＭＬインタプリタスレッド９２を表す。実際にはクラウドサービスシステム６では受信スレッド９１の動作が介在するが、本図においてはこの動作を省略し、ＰＰＭＬインタプリタスレッド９２が受信機能を併せ持つものとして示す。なお、図１５中に示すページ番号は、ステップＳ１０５（図１２参照）において並列ＲＩＰ処理が必要との判定となった以降で処理される対象ページに対し番号を１から順番に振った、相対的なページ番号である。

図１５のステップＳ３０１は、図１２のステップＳ１０５において、クラウドサービスシステム６を使用しての並列ＲＩＰ処理が必要との判定となった後で最初に実行されるステップＳ１１０の処理に該当する処理動作である。図１５では、クライアントシステム７に割り当てるページ数が１０ページであり、ステップＳ３０１は、１〜１０ページのページラスタ画像の生成を行い、プリンタエンジン２０へ転送する処理動作を示している。

ステップＳ３０１の開始時点では、まだ並列処理が行われていないため、プリンタエンジン２０の印刷速度以上でのページラスタ画像の生成及び転送が行われていない。ステップＳ３０１を開始すると同時に、ＰＰＭＬインタプリタスレッド８４は、送信スレッド８３を使用してページ１１〜１５に対応する印刷データを含むＺＩＰアーカイブの転送を行う（ステップＳ３０２）。

クラウドサービスシステム６のＰＰＭＬインタプリタスレッド９２は、送信スレッド８３から受信したＺＩＰアーカイブを解凍した後、ページ１１〜１５のページラスタ画像の生成を行い、その生成されたページラスタ画像を圧縮し、受信/エンジン転送スレッド８７に対し返却（送信）する（ステップＳ３０３）。

受信/エンジン転送スレッド８７は、受信した圧縮画像データをフレームメモリ８８（図１１参照）へ格納し、伸張しながらプリンタエンジン２０へ転送して行く（ステップＳ３０４）。ここでは、ステップＳ３０１終了後、直ちにプリンタエンジン２０への転送を開始し、プリンタエンジン２０の印刷速度に遅れないようにページラスタ画像を転送していくことが期待されるが、もしこの期待通りとならない場合は、クラウドサービスシステム６に割り当てられたページ数が多すぎることになるため、次の並列ＲＩＰ処理の依頼に向けて、ここでクラウドサービスシステム６に割り当てるページ数を減算補正する。

クライアントシステム７のＰＰＭＬインタプリタスレッド８４は、１０ページ分のページラスタ画像の生成及びプリンタエンジン２０への転送が終了した直後、ページ２６〜３０に対応するＺＩＰアーカイブをクラウドサービスシステム６へ転送する（ステップＳ３０５）

その後、ページ１６〜２５に対応するページラスタ画像の生成及び圧縮を行い、フレームメモリ８８へ格納する（ステップＳ３０６）。

次に、ＰＰＭＬインタプリタスレッド８４は、ステップＳ３０４においてクラウドサービスシステム６が返却したページラスタ画像のプリンタエンジン２０への転送が終了したことを確認し、圧縮されたページ１６〜〜２５のページラスタ画像の伸張とプリンタエンジン２０への転送を行って行く（ステップＳ３０７）。

ここでの処理は、ステップＳ３０４の終了後直ちに開始され、プリンタエンジン２０の印刷速度以上の速度で、ページラスタ画像の供給（転送）を行っていくことが期待されるが、もしこの期待通りとならない場合は、クラウドサービスシステム６に割り当てているページ数が少なすぎることになるため、次回のサイクルの並列ＲＩＰ処理に向け、ここでクラウドサービスシステム６に割り当てるページ数を加算補正する。また、このタイミングにおいて、さらに図１４のステップＳ１１８、１１９に対応する割り当てページ数の減算補正を行う。

以上が基本的な並列ＲＩＰ処理の１サイクルであり、図のステップＳ３０８は、ステップＳ３０５で送信された２６〜３０のページに対応するＺＩＰアーカイブに対してステップＳ３０３と同様の処理を行う。ステップＳ３０９は、ステップＳ３０８にて生成されたページ２６〜３０のページラスタ画像に対して、ステップＳ３０４と同様の処理を行う。

以上のように、本発明の印刷システム５では、並列ＲＩＰ処理の依頼、及び、その依頼量の調整を行うことができる。これにより、クライアントシステム７のプリンタコントローラの能力ではプリンタエンジン２０の印刷速度と同等以上の速度でページラスタ画像の生成/供給ができないような重いデータであっても、並列ＲＩＰ処理によりページラスタ画像の生成/供給の速度を高速化し、プリンタエンジン２０と同等の速度でラスタ画像の生成/供給を行うことができる。

基本的には、画像生成部１５によるラスタ画像の生成がプリンタエンジン２０の画像形成に間に合う分のＲＩＰ処理は、画像生成部１５に行わせ、足りない分（間に合わない分）をクラウドサービスシステム６に代行させるようにして依頼量を決定する。これにより、印刷装置１０のハードウェアリソースを可能な限り使用しつつ、プリンタエンジンの速度ダウンの発生を極力抑えることができる。

他にも、クラウドサービスシステム６の処理能力（負荷状況等）に応じて並列ＲＩＰ処理の依頼量を調整することで、印刷システム５全体で、最も効率よく並列ＲＩＰ処理を行うことができる。

以上、本発明の実施の形態を図面によって説明してきたが、具体的な構成は実施の形態に示したものに限られるものではなく、本発明の要旨を逸脱しない範囲における変更や追加があっても本発明に含まれる。

本発明の本実施の形態では、ＰＰＭＬデータ対応のソフトウェア機能構成及び処理の流れを説明したが、本発明を実施するための形態としては、他のＰＤＬに対応したソフトウェア機能構成を採っても構わない。たとえば、ＰＤＦ/PostScript、ＸＰＳ、ＰＣＬ・ＸＬの形式のデータなどは、ＰＰＭＬデータと違い、単独のインタプリタ機能にて、ＰＤＬデータの解析と、ラスタ画像の生成機能が完結しているが、これらのようなＰＤＬインタプリタ機能を採用した場合と、ＰＰＭＬデータに対応する機能を採用した場合との差異を述べる。

まず、図１１のスレッド構成においては、クライアントシステム７におけるＰＰＭＬインタプリタスレッド８４及びＰＳ/ＰＤＦインタプリタスレッド８５が単一のインタプリタスレッドに集約され、また同様にクラウドサービスシステム６におけるＰＰＭＬインタプリタスレッド９２及びＰＳ/ＰＤＦインタプリタスレッド９４も単一のインタプリタスレッドに集約されることになる。

他にも、図１２〜図１４の処理フローにおいては、クライアントシステム７におけるステップＳ１０１及びステップＳ１０２は、受信データをハードディスク装置１４へ格納し、また格納データをハードディスク装置１４より再取得する処理となる。また、クライアントシステム７におけるステップＳ１０３、ステップＳ１０７、及びクラウドサービスシステム６におけるステップＳ２０２、ステップＳ２０３、ステップＳ２０４はＰＰＭＬデータを処理する際の固有の処理ステップであり、不要となる。さらに、ステップＳ１０９及びステップＳ２０５は、処理対象となるＰＤＬよりクラウドサービスシステム６への割り当て分を抽出し送信し、クラウドサービスシステム６がこれを受信する処理となる。上記ステップ以外のページラスタ画像のハンドリング処理動作や各種判定動作部分については、ＰＰＭＬデータ以外のＰＤＬの場合でも不変となる。

なお、印刷データはＰＤＬ（ページ記述言語）形式に限らない。

本発明の実施の形態では、並列ＲＩＰ処理の依頼量と、クラウドサービスシステム６にリクエストジョブを送信してから、その返信を受け取るまでの時間によって、クラウドサービスシステム６の処理能力（混み具合状況）を判断し、次回の依頼量を調整していたが、クラウドサービスシステム６から、混み具合状況（負荷状況）を示す情報を直接取得してその情報に基づいて次回の依頼量を調整してもよい。

並列ＲＩＰ処理において、クラウドサービスシステム６に依頼する処理量（依頼量）の決定方法は、実施の形態で用いた方法に限らない。たとえば、負荷状況に対応しないようにして決定してもよい。固定値でもよい。また、依頼量の増減はページ単位でなくともよい。

３…ＬＡＮ
４…ＷＡＮ
５…印刷システム
６…クラウドサービスシステム
７（７Ａ、７Ｂ、７Ｃ）…クライアントシステム
１０（１０Ａ、１０Ｂ）…印刷装置
１１…ＣＰＵ
１２…フラッシュメモリ
１３…ＲＡＭ
１４…ハードディスク装置
１５…画像生成部
１６…ネットワークＩ／Ｆ部
１７…VideoＩ／Ｆ
２０…プリンタエンジン
４０…クライアント端末
４１…ＣＰＵ
４２…ＲＡＭ
４３…ハードディスク装置
４４…ネットワーク通信部
４５…入力Ｉ／Ｆ
４６…キーボード
４７…ポインティングデバイス
４８…出力Ｉ／Ｆ
４９…モニタ
５０…ネットワーク間接続装置
５１…ＣＰＵ
５２…フラッシュメモリ
５３…ＲＡＭ
５４…第１ネットワークＩ／Ｆ部
５５…第２ネットワークＩ／Ｆ部
６０（６０Ａ、６０Ｂ）…画像生成サーバ
６１…ＣＰＵ
６２…ＲＡＭ
６３…ハードディスク装置
６４…ネットワーク通信部
８１…スプーラスレッド
８２…再利用オブジェクト画像キャッシュメモリ
８３…送信スレッド
８４…ＰＰＭＬインタプリタスレッド
８５…ＰＳ/ＰＤＦインタプリタスレッド
８６…エンジン制御スレッド
８７…受信/エンジン転送スレッド
８８…フレームメモリ
９１…受信スレッド
９２…ＰＰＭＬインタプリタスレッド
９３…フレームメモリ
９４…ＰＳ/ＰＤＦインタプリタスレッド
９５…再利用オブジェクト画像キャッシュメモリ

Claims (8)

1. 印刷データに基づいてラスタ画像を生成するＲＩＰ処理を行うラスタ画像生成部と、
   前記ラスタ画像生成部によって生成されたラスタ画像に基づいて用紙上に画像形成するプリンタエンジンと、
   前記ラスタ画像生成部によるラスタ画像の生成速度が、前記プリンタエンジンの画像形成速度を下回っていると判断した場合に、前記印刷データに対する前記ＲＩＰ処理の一部をネットワーク上の所定の画像生成サーバに代行させ、前記ラスタ画像生成部によって生成されたラスタ画像と前記画像生成サーバから前記代行の結果として受信したラスタ画像とに基づいて前記プリンタエンジンに画像形成を行わせる制御部と、
   を有する
   ことを特徴とする印刷装置。
2. 前記制御部は、前記画像生成サーバの負荷状況に応じて、前記画像生成サーバに代行させる処理量を決定する
   ことを特徴とする請求項１に記載の印刷装置。
3. 前記制御部は、前記画像生成サーバに前記ＲＩＰ処理の代行を依頼してからその代行結果のラスタ画像を受信するまでの時間に基づいて前記画像生成サーバの負荷状況を判断する
   ことを特徴とする請求項２に記載の印刷装置。
4. 前記制御部は、前記ラスタ画像生成部によるラスタ画像の生成が前記プリンタエンジンの画像形成に間に合わない分のＲＩＰ処理を上限にして、前記画像生成サーバに代行させる処理量を決定する
   ことを特徴とする請求項１乃至３のいずれか１つに記載の印刷装置。
5. 前記制御部は、前記上限を越えない範囲で、前記画像生成サーバでの処理時間と前記ラスタ画像生成部での処理時間が等しくなるように、前記画像生成サーバに代行させる処理量を決定する
   ことを特徴とする請求項４に記載の印刷装置。
6. 前記制御部は、前記画像生成サーバに代行させる処理量を、ページ単位に増減させる
   ことを特徴とする請求項１乃至５のいずれか１つに記載の印刷装置。
7. 前記印刷データは、ページ記述言語で記述された印刷データである
   ことを特徴とする請求項１乃至６のいずれか１つに記載の印刷装置。
8. 請求項１乃至６のいずれか１つに記載の印刷装置と、
   前記印刷装置から依頼されたＲＩＰ処理を行って、その結果物であるラスタ画像を前記印刷装置へ送信する画像生成サーバと、
   を有する
   ことを特徴とする印刷システム。

Images