プリンタにドキュメントおよびリソースを送信するシステム
プリンタによる印刷ジョブの印刷を制御するシステムおよび方法。印刷要求が、クライアントからプリンタに送信される。要求は、印刷ジョブに対する固有のソース識別子、印刷ジョブを構成する１つまたは複数のドキュメントのタイプ、複数のドキュメントリソースを取り込めるソースアドレス、ならびに上記１つまたは複数のドキュメントに適用するプリンタ設定を含む。プリンタはジョブのサイズを通知されてよく、あるいは、データが利用可能であればデータがプリンタに送信されるストリーミングモードで動作してもよい。プリンタは、この初期要求に対して、印刷ジョブ要求が受入れ可能であるかどうかを示す初期応答により回答し、要求が受入れ可能である場合、クライアントが用いるためにプリンタでのジョブに対してプリンタ識別子を供給して、次いでプリンタ上のジョブを特定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷デバイスと、個人ユーザのパーソナルコンピュータもしくは共有プリンタサーバ等のクライアントとの間で対話するためのプリンタプロトコルに関する。
【背景技術】
【０００２】
コンピュータがレンダリングのためにデバイス（プリンタ等）にドキュメントを送信した際に、このデバイスがメモリに全ドキュメントを記憶するためのリソースを備えているとは限らない。このような場合、デバイスがその限られた使用可能なリソースだけを用いて全ドキュメントをレンダリングするのを可能にするある種の機構を使用しなければならない。本明細書では、用語「印刷クライアント」はパーソナルコンピュータと共有印刷サーバの両方を指すのに用いられる。
【０００３】
ラスタベースのドキュメントフォーマットについては、通常これは、デバイスにドキュメントをバンドまたはタイルで送信することによって行われる。１つのバンドが処理されると、次のバンドがプリンタに送信される。
【０００４】
ベクトルベースのドキュメントについては、限られたリソースを用いて印刷するという問題はさらに深刻になる。ドキュメントは、それが直線、曲線およびグリフ等の描画基本要素（ｄｒａｗｉｎｇ ｐｒｉｍｉｔｉｖｅ）により表現される場合、ベクトルベースであるとみなされる。直線は、レンダリングの開始位置および修了位置、直線の幅、ならびにレンダリングの可能な色によって特徴付けられる。曲線については曲率半径という複雑さが加わる。グリフは、記号または文字の断片である。ローマ式アルファベットにおいては、文字とそのグリフとの間には、ほぼ１対１の対応がある。アラビア系または東アジア系の書記言語では、１つの文字は通常２つ以上のグリフから構成される。通常のベクトル言語には、傾き、アルファブレンド（ａｌｐｈａ ｂｌｅｎｄ）、ポリンゴン等、さらなる描画基本要素もある。しばしば、フォントもしくはピクチャ、および描画基本要素等のリソースを埋め込んだベクトルベースのドキュメントは、それら追加リソースを参照するために使用することもできる。レンダリングデバイスまたは機構を用いて、全ドキュメント、または、ドキュメント内の全リソースもしくは構成要素を、メモリ内に保持することができないということもよくある。この状況は、デバイスがドキュメントを、そして基本要素でさえも、少しずつレンダリングしなければならないということを意味している。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来技術では、ページに対するドキュメントリソースをプリンタにダウンロードして、ドキュメントリソースが必要なときに確実に使用可能になるように、ドキュメントをフォーマットしている。この解決策では、印刷クライアントが制御される（ｉｓ ｉｎ ｃｏｎｔｒｏｌ）。ＰＤＬ（ページドキュメント言語）においては、ドキュメントリソースの寿命および可用性を管理するための精巧な機構が必要となる。
【０００６】
この機構を堅牢なもの（ｒｏｂｕｓｔ）とするために、以下の３つの方策の１つが実施される。
【０００７】
１）印刷クライアントが各ページにページ用ドキュメントリソースを埋め込み、これをプリンタに送信する。これは有効ではあるものの、リソース（多数のページに共通のフォントの透かしまたはグリフ）が多くのページに現れる場合、帯域幅の観点から非効率となる。１枚のページに対するリソース要件がデバイスの能力を超えた場合、ページの印刷は不可能となる。
【０００８】
２）印刷クライアントは、ＰＤＬジェネレータ（印刷クライアントドライバのレンダリング部）からプリンタへの双方向通信チャネルを必要とする。これは、以下のいずれかを目的としている：
２ａ）消費されるプリンタリソース量を監視し、ＰＤＬストリームがリソースの一部を解放する操作を担当する場合、同操作をこのＰＤＬストリームで行うこと；
２ｂ）前もって送信されたドキュメントリソースが依然として利用可能であるかどうかを照会し、そうでない場合に限り、該ドキュメントリソースを再度送信すること。
【０００９】
３）ＰＤＬジェネレータからの双方向通信チャネルを欠いている場合、ジェネレータはそれが消費するプリンタリソース量の推定を試み、この推定に基づいて選択肢２ａ）（上述）を実行することが可能である。勿論、１００％信頼できるものではない。というのは、プリンタがどのようにＰＤＬを実行するのかをドライバが確実に把握することはできないからである。
【００１０】
上記第３の選択肢（この選択肢は現在Ｗｉｎｄｏｗｓ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）ＸＰ（登録商標）などのＷｉｎｄｏｗｓ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムが実行する）の利点は、印刷クライアントとプリンタとの間の通信が一方向で十分であるということである。
【００１１】
第３の方策を用いると、アプリケーションプログラムがプリンタの使用を開始したいとき、まずこのアプリケーションはプリンタデバイスコンテキストに対するハンドルを取得し、これによりプリンタデバイスドライバライブラリモジュール（ＤＬＬ拡張子を有するファイルおよび他のデータファイル）がメモリにロードされ、それ自身が初期化される。印刷ドライバは、オペレーティングシステムグラフィックによる支援を受けて、ＰＤＬにレンダリングする。その結果、プリンタリソースの必要量は１枚のページに対してさえも膨大になる可能性がある。この問題を解消するため、１つの先行技術の手法では、フォントをサブセットに分け、場合により画像のサイズを小さくする。必然的に上記第３の方策がプリンタを処理できないデータで一杯にする（その結果エラーメッセージを生じ、印刷が中断する）という可能性は、クライアントとプリンタの間の簡単な基本的に一方向の通信によって相殺されるのであり、このことは、パラレルプリンタポートまたはプリンタが接続された既存ネットワークから送信する場合に有利である。
【課題を解決するための手段】
【００１２】
典型的なシステムはデバイス上でのテキスト、画像等のレンダリングを制御する。クライアントとデバイスとの間に少なくとも半二重またはそれより優れた双方向通信パスを形成する通信チャネルが確立される。１つの典型的な用途では、デバイスはテキスト画像等を紙に転写するためのプリンタである。クライアントは、クライアントとして構成されたコンピュータすなわち、ネットワーク上でクライアントソフトウェアを実行するノードであってよく、あるいは、いくつかの可能な通信プロトコルのうちの１つを用いて通信する単一のコンピュータであってよい。印刷デバイスは、印刷データを記憶し、双方向通信パスを介して印刷クライアントから印刷デバイスに送信されたデータに基づく画像をレンダリングするための印刷リソースを含む。
【００１３】
クライアントは、印刷ジョブに関係する印刷サービスを求める初期要求を送信することによって、印刷デバイスによるレンダリングを開始する。一実施形態によると、この初期要求は、印刷ジョブのデータ量およびこのデータの特徴を示している。この初期要求は、印刷デバイスによって応答され、初期量のデータが要求される。印刷クライアントはそれに応じて初期量のデータを送信し、さらなるデータを求める追加の要求を待つ、または、初期の要求に応答して印刷ジョブの印刷データすべてが送信された場合、その印刷ジョブの印刷が終了したという指示を待つ。
【００１４】
代替実施形態では、ジョブのイニシエータはジョブ開始の時点で送信されたデータ量を知らされていない。それにもかかわらず、これ以上印刷するデータがなくなるまでイニシエータがプリンタにデータ要求を続けるよう通知する「ストリーム」モードでプリンタが動作できることが必要となる。この前提は上記の実施形態と類似しているが、これ以上送信するものがなくなるまでプリンタがページレベルのデータを要求し続け、クライアントがノーモアデータ（ｎｏ ｍｏｒｅ ｄａｔａ）（ＮＡＫ）メッセージで応答する点が異なる。
【００１５】
本発明に関する上記および他の目的、利点および特徴を添付の図面を参照しながら説明する。
【発明を実施するための最良の形態】
【００１６】
図面を参照すると、本発明の例示的な実施形態が示されている。本発明の対象となるタスクは、レンダリングするドキュメントをプリンタ等のデバイスに転送する処理である。図２は、典型的な印刷シナリオを示す。印刷クライアント１０２は通信パス１０６を用いてプリンタ１０４と通信する。コンピュータとプリンタの間の通信セッションは、照会／応答形式の通信をサポートできる任意の通信チャネルを介して実行される。例としては、ＴＣＰ、ＵＳＢ、１３９４、ブルートゥース、ＨＴＴＰ、ＳＳＬがある。半二重またはそれより優れたチャネルを使用してよい。ＨＴＴＰは、本発明のこの例示的実施形態のキャリアとして特に適している。印刷クライアント１０２のさらなる詳細は、図１を参照して説明される。
【００１７】
ドキュメントを印刷したいデバイス（たいていは印刷クライアントまたはＰＣ１０２であり、以後クライアントと称す）とプリンタとの間で行き来する通信（図３）により印刷タスクが実行される。印刷クライアントは、初期要求１１０をプリンタ１０４に送信する。１つの例示的実施形態では、初期要求は、ａ）印刷ジョブに対する固有の識別子、ｂ）ドキュメントのタイプ、および、ｃ）ドキュメントリソースが検索されるアドレス（たいていクライアントのアドレス）を含む。これは上記のコンピュータのアドレスとしてよいが、アドレスは、プリンタ１０４と通信する別の通信チャネルを介して利用可能な他のコンピュータのアドレスであってもよいことに留意されたい。
【００１８】
初期要求１１０は、印刷するページ範囲、コピーの部数など、ドキュメントに適用するプリンタ設定も含む。文書に関するメタデータ、たとえば総サイズもプリンタに送られる。最後に、初期要求はタイムアウトプリンタハートビートを含む。ハートビートは、プリンタがジョブをキューに入れている、または実施にジョブを印刷していることをクライアントに知らせる。プリンタは、メッセージを周期的に（タイムアウトで指定されるように）クライアントに送信し、印刷ジョブ要求が依然として引受け中であることをクライアントに通知する。このことにより、プリンタの電力供給が停止する等の予見できない理由により、ジョブが放棄されたかどうかをクライアントが知ることができる。
【００１９】
プリンタ１０４は、ドキュメント印刷要求が受入れ可能であるかどうかを示す応答１１２と共に、クライアントからの要求に回答する。印刷ジョブが受け入れられた場合、応答１１２はプリンタ１０４での印刷ジョブに対する固有識別子も含む。印刷ジョブが受け入れられた場合、クライアントは、プリンタが将来要求を引き受ける意志があるものとみなす。プリンタは、複数のジョブをキューに入れることも可能である。クライアント１０２は上記の識別子を用いて、管理プロトコルによりプリンタ上のドキュメントを後で操作することも可能である。プリンタ１０４はネットワークと結合してもよく、他のソースから多数の印刷ジョブを印刷する要求を受信してもよく、したがって、各ジョブにはプリンタにより固有のジョブ識別子が割当てられ、次いでクライアントにより上記ジョブに割当てられた固有の印刷ジョブ識別子（ｐｒｉｎｔ ｊｏｂ ｄｅｓｉｇｎａｔｏｒ）がプリンタに知らされる。
【００２０】
図４Ａおよび図４Ｂに示した２つのプリンタ１３０、１３２のリソースについて検討する。各プリンタは、印刷ヘッド１３４、１３５を含み、印刷ヘッド１３４、１３５は同ヘッドに送信されたデータに基づいて各プリンタにより画像をレンダリングするためのものである。代表的な印刷ヘッドは、レーザまたはインクジェット印刷ヘッドを含んでよい。２つのプリンタ１３０、１３２はまた、印刷ジョブのドキュメントのページをフォーマットするためのメモリ領域１３６、１３８を含む。両プリンタでは、メモリ１３６、１３８はほぼ同じサイズであり、典型的なプリンタでは数メガバイトのＲＡＭを含んでよい。
【００２１】
プリンタ１３０は、追加の高速メモリと、ハードドライブと、場合により特殊なグラフィックプロセッサとを含む追加のプリンタリソース１４０を有する。またプリンタ１３０は、クライアントから受信したデータを操作し、このデータをメモリ１３６に転送できるようにフォーマットするコンピュテーションハードウェア（ｃｏｍｐｕｔａｔｉｏｎａｌ ｈａｒｄｗａｒｅ）１４４を含む。プリンタ１３２は、場合により小容量の付加メモリを含むより制限されたリソース１５０を有する。第２のプリンタ１３２内のコンピュテーションハードウェア１５４もクライアントからデータを受信し、このデータをメモリ１３８で記憶するためのフォーマットで体系化する。
【００２２】
プリンタ１３０は、より多くのリソースを有しているという点で、プリンタ１３２よりも強力である。たとえば、これは複数のソースからの複数の印刷ジョブに関するリソースすべてを完全に記憶する容量を有する。プリンタ１３２は、より制約されている。これは、１ページ超のテキストを占める印刷ジョブのごく一部に対するリソースを有する。ある種のラスタプリンタについては、プリンタは、１ページのコンテンツを記憶するのに十分なリソースさえも持たない場合がある。このようなプリンタは、各ページを印刷する際にコンテンツのページを、バンド／タイル処理（ｂａｎｄ／ｔｉｌｅ）しなければならない。
【００２３】
プリンタがドキュメントをレンダリングする準備が済むと、プリンタは、クライアントが指定したアドレスにドキュメントデータを求める要求１１４を送信する。図３に示したデータの交換では、クライアントと、データを見出すアドレスとは同一である。要求１１４は、クライアントから送信された情報に基づいてドキュメントを識別する。例示的システムの一実施形態によると、データ要求１１４は、３タプル（ｘ，ｙ，ｚ）であり、ただし、ｘは検索するドキュメント内のリソースを特定し、ｙはリソースデータに対するオフセットであり、ｚはｙで開始する検索データの量である。本発明の範囲から逸脱することなく、要求の他のフォーマットも可能である。たとえば、グリフの範囲をプリンタが要求してもよい。２つのプリンタ１３０、１３２間の能力に差があるために、この要求はプリンタが異なると全く異なるものである。プリンタは、ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）により印刷に必要なリソースを参照してもよい。プリンタのコンピュテーションハードウェアは、クライアントからの戻りデータが従うべき、要求に含まれた調査および属性情報（長さ、データフォーマット、圧縮レベル、画像解像度、等）を具備するリソースを要求してよい。
【００２４】
ドキュメントリソースの記述ｘは、ドキュメントフォーマットに関連付けられる。プリンタは、初期要求１１０でフォーマットについて通知されているので、フォーマットを知っていることになる。プリンタはドキュメントフォーマットを理解する必要がある。印刷ジョブが開始すると、たとえば、プリンタはオフセットがゼロで印刷されるべき最初のページのページ記述を求め、検索されるデータに対するある好都合なサイズを指定する。プリンタは後で、ドキュメント中の他のリソースを求めてもよい。
【００２５】
図５は、複数のページを各ドキュメントが含んでよい複数のドキュメントからなる印刷ジョブ１６０を例示している。ドキュメントの１つの例は、ＸＭＬマークアップ言語によりフォーマットされたドキュメントである。各ドキュメントページは、埋め込まれたアスキーテキストならびにテキストフォント、ピッチ等の詳細を含んで良い。さらに、ページは、ドキュメントの一部ではないがリソース１６２のカタログまたはフォルダでクライアントに記憶されたドキュメント中のＸＭＬタグで定義された位置で画像（ｊｐｅｇ、ｂｍｐ等）に対する参照を含んでよい。クライアントまたはデータソース上にドキュメントファイルが存在すること、ならびにアスキーまたは他のリソースが様々なデータストリームで単一のドキュメントファイルに記憶されることも可能である。
【００２６】
この要求に対するクライアント応答１１６は、プリンタ１０４が要求したデータを含む。ジョブを完了するために必要な残りのデータが要求された量よりも自然に（ｎａｔｕｒａｌｌｙ）少ない場合、要求されたよりも少ないデータが返される。ある状況においては、プリンタは要求１１０の開始時にジョブサイズを知らないことになる。したがって、プリンタおよびクライアントが、送信すべきデータがこれ以上なくなるまでプリンタがページレベルでデータをさらに求めるストリーミングモードを実行できる必要がある。そのような必要性の一例は、数千のエントリを有するペイロールジョブに対するバッチランである。印刷ジョブに対するデータの全長は、ジョブが開始した際にクライアントに知らされる。この代替実施形態では、クライアントは、特定のサイズをジョブに対して指定することなく初期要求１１０を送信できることが必要である。
【００２７】
受信すると、プリンタはデータを処理し、このデータが何を含んでいるかに基づいて追加のデータを求める別のまたは追加の要求１１８を、クライアント１０４に対して発行する。ページがピクチャを、または場合によりフォントを含む場合は、プリンタ要求はそのピクチャまたはフォントを要求してもよい。これは、プリンタでリソースが不足しているために以前そのデータがあるページをフォーマットするために使用されたものの他ページのフォーマットが必要なため（場合により他ソースからの他の印刷ジョブが必要なため）該データが廃棄された場合に行うことができる。
【００２８】
一般に、プリンタおよびクライアントは、データをページに編成する。限られたリソースを有するプリンタ１３２があるページを印刷した場合、プリンタ１３２は次のページのデータを取り込む要求を発行する。この要求も複雑になる可能性がある、というのも、プリンタ１３２等リソースが限られたプリンタにおいては、該要求はたとえばテキストおよび画像データをインターリーブし、このデータを一度に１つのバンドで専用ページメモリ１３８にロードするからである。プリンタからのデータ要求、およびクライアントからプリンタへのデータを伴う応答は、要求されたジョブすべてが印刷されるまで繰り返される。プリンタ１３０は、他のジョブで過負荷状態でなければ、データ１１４を求める要求の中でジョブ１６０に関するリソースすべてを求める。プリンタ１３０はデータを記憶する大量のリソースを有しているので、フォントまたは画像であってもその詳細がプリンタ１３０のリソース領域１４０に既に記憶されていてもよい。
【００２９】
動作の一形態によると、プリンタは初期要求１１０でドキュメントサイズが送信されており、そのため、（ドキュメントのサイズおよびパージ範囲に基づいて）図３に示す対話のやり取りをショートサーキット化（ｓｈｏｒｔ ｃｉｒｃｕｉｔ）する十分なリソースがあるかどうかを判定できる。プリンタは、１つの要求１１４ですべてのリソースを求めてよい。これは、大量のリソースを有するプリンタに対する最適化となる。こうすることが最も効率的である、というのも、クライアントがドキュメントすべてを印刷したくて、かつプリンタがリソースを有している場合、最も速い方法は一度にドキュメントリソースすべてを受信することであるからである。
【００３０】
他の動作形態では、初期要求１１０はジョブまたはドキュメントサイズを知らない。プリンタは、データの要求を続ける全ドキュメント印刷モードに加えて、送信すべきものがなくなるまでオープンエンド要求または「ストリーム」モードに応答する必要がある。クライアントは、ページに対するデータすべてが利用可能な場合のみ新しいページの送信を開始することになる。利用可能なページがない場合、クライアントは「ノーモアデータ」メッセージを送信し、プリンタは印刷動作を終了する。
【００３１】
第１の実施形態では、基本的な前提は、プリンタが印刷開始を求められたときドキュメントが既に完全であること、または、プリンタが消費できるよりも迅速にドキュメント（サイズは既知）のコンテンツが生成されることである。この前提は通常は成立するが、常に成り立つというわけではない。この起こり得る問題を解消するため、２つの概念を導入する。
【００３２】
プリンタがリソース１１４を求める要求を送信すると、クライアントからの応答１１６がリソースは利用可能でないことを提示してよい。この応答はタイムアウトを含む。プリンタは、この時点でジョブの処理を停止する。次いで印刷クライアントは、要求データが利用可能になったとき、別の要求をプリンタに送信しなければならない。プリンタはリソース利用可能メッセージ（ｒｅｓｏｕｒｃｅ ａｖａｉｌａｂｌｅ ｍｅｓｓａｇｅ）に対して承認（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）で応答する。プリンタは、リソースを求める要求を再送することによりジョブを再開する。リソースがタイムアウト内に利用可能にならず、かつコンテンツがドキュメントに対して依然として追加中であれば、クライアントは他リソース利用不可能要求（ａｎｏｔｈｅｒ ｒｅｓｏｕｒｃｅ ｎｏｔ ａｖａｉｌａｂｌｅ ｒｅｑｕｅｓｔ）を送信することにより、タイムアウトを新タイムアウトによってリセットする。プリンタは待機し続ける。
【００３３】
リソース要求に対する各応答１１６は、コンテンツが依然としてドキュメントに追加中であるか否かを示すフラグを有する。これは、プリンタがドキュメント全体を印刷することを求められ、かつプリンタがドキュメントをその作成よりも速く消費する場合に重要となる。プリンタは次のページを求め続けることが可能である。ページが存在しない場合、クライアントはコンテンツ利用不可能メッセージ（ｃｏｎｔｅｎｔ ｕｎａｖａｉｌａｂｌｅ ｍｅｓｓａｇｅ）で応答する。プリンタは、コンテンツにフラグセットが追加されていない応答を見ると、すべてのページが印刷されたことを知る。リソース要求に対するすべての応答パケットは適切にフラグセットを有するべきである。
【００３４】
プリンタは様々なリソースを有し、本発明の１つの特徴は、一度に１つずつドキュメントまたはジョブのリソースをプリンタが求める場合に対処できることである。単純な例では、プリンタは、ページ１の最後に到達するまでに、ドキュメントの最初のページの１０００バイト分を求め、次いで次の１０００バイト分を求め、以下同様にする。より現実的なシナリオでは、ドキュメントフォーマットは、クライアントとプリンタとの間の通信を効率的にするために、リソース参照に対する埋込みリソースサイズを含むページサイズ、および、ページ記述を有するページインデックスを含む。
【００３５】
プリンタは、ジョブが完了したことを判定する要求１１８をクライアントに送信する。クライアントがプリンタからの要求への応答に失敗した、もしくは、ドキュメントが存在しない（ドキュメントが削除された可能性があることを示す）場合、プリンタはジョブを削除しなければならない。プリンタは、適切とみなされる場合に、要求を再び試みてよい。
【００３６】
図３の一連の通信対話は、印刷ドキュメントの基本フォーマットを示す。基本的概念に追加された特徴を実現するいくつかの改善が企図される。プリンタ１０４がクライアント１０２により送信されたメタデータから、ドキュメント全体に対処する十分なリソースを有すると判定された場合、プリンタはドキュメント全体を転送する要求を行ってもよい。
【００３７】
プリンタ１３０等の強力なプリンタはリソースまたはリソースの一部をダウンロードすると、それをヒットキャッシュ（ｈｉｔ ｃａｃｈｅ）に記憶できる。リソースは、利用されていない場合、または、新たなリソースがキャッシュに追加された場合、キャッシュから経時的に除かれる（ａｇｅ ｏｕｔ）。このシナリオでは、プリンタはまず、リソースを求める要求を発行する必要がある場合、キャッシュを確認する。これにより通信量が軽減され、プロトコルの騒然な行き交い（ｃｈａｔｔｉｎｅｓｓ）が低減され、レンダリングの性能が改善される。
【００３８】
コンピュータシステム
図１は、例示的な処理デバイスを示す。図１に示した処理デバイスはクライアント１０２として機能できる。図１に示したようなデバイスは、プリンタ１３０等より強力なプリンタ向けのコンピュテーションハードウェアとしても機能できる。システムは従来型のコンピュータ２０の形態の汎用コンピューティングデバイスを含み、コンピュータ２０は、１つもしくは複数の処理ユニット２１、システムメモリ２２、ならびに該システムメモリを処理ユニット２１に対して接続することも含めて、各種のシステム構成部品を互いに接続するシステムバス２３を含む。システムバス２３は、メモリバスもしくはメモリコントローラと、周辺バスと、各種バスアーキテクチャのいずれかを用いたローカルバスを含む数種のバス構造のうちのいずれであってもよい。
【００３９】
システムメモリは、読出専用メモリ（ＲＯＭ）２４、ランダムアクセスメモリ（ＲＡＭ）２５を含む。起動時等にコンピュータ２０内の各要素間で情報の伝達を助ける基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４に記憶されている。
【００４０】
コンピュータ２０は、ハードディスクからの読取りおよびそれに対する書込みをするためのハードディスクドライブ２７（不図示）、取外し可能磁気ディスク２９からの読取りまたはそれに対する書込みをするための磁気ディスクドライブ２８、ならびに、ＣＤ ＲＯＭまたは他の光メディア等の取外し可能光ディスク３１からの読取りまたはそれに対する書込みをするための光ディスクドライブ３０をさらに含む。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれ、ハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ディスクドライブインターフェース３４を介してシステムバス２３に接続されている。上記ドライバおよび上記ドライバに関連するコンピュータ読取り可能メディアは、コンピュータ２０用のコンピュータ読取り可能な命令、データ構造、プログラムモジュールおよび他のデータのための不揮発性ストレージを形成する。本明細書で説明する例示的環境ではハードディスク、取外し可能磁気ディスク２９、および取外し可能光ディスク３１を使用するが、コンピュータがアクセス可能なデータ記憶可能な他の種類のコンピュータ読取り可能メディア、たとえば磁気カセット、フラッシュメモリカード、デジタルビデオディスク、Ｂｅｒｎｏｕｌｌｉカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読出専用メモリ（ＲＯＭ）等も例示的動作環境で使用可能であることを当業者は理解されよう。
【００４１】
オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含め、いくつかのプログラムモジュールをハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ ２４またはＲＡＭ ２５に記憶してよい。ユーザは、キーボード４０およびポインティングデバイス４２等の入力デバイスを介してコンピュータ２０にコマンドおよび情報を入力できる。他のデバイス（不図示）は、マイクロフォン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ等を含む。上記および他の入力デバイスはしばしばシステムバスに結合されたシリアルポートインターフェース４６を介して処理ユニット２１に接続されるが、他のインターフェース、たとえばパラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）を介して接続されてもよい。モニタ４７または他の種類の表示デバイスも、ビデオアダプタ４８等のインターフェースを介してシステムバス２３に接続される。モニタに加えて、パーソナルコンピュータは典型的には、スピーカおよびプリンタ等の他の周辺出力デバイス（不図示）を含む。
【００４２】
コンピュータ２０は、遠隔コンピュータ４９等の１つまたは複数の遠隔コンピュータに対する論理接続を用いたネットワーク環境で動作してもよい。遠隔コンピュータ４９は、他のパーソナルコンピュータ、クライアント、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードであってよく、典型的にはコンピュータ２０に関する上述の要素の多くまたは全てを含むが、ただし図１では１つのメモリストレージデバイス５０しか示さない。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。
【００４３】
ＬＡＮネットワーク環境で使用する場合、コンピュータ２０は、ネットワークインターフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーク環境で使用する場合、コンピュータ２０は典型的には、インターネット等の広域ネットワーク５２上の通信を確立するためのモデム５４または他の手段を含む。モデム５４は内部的でも外部的でもよいが、シリアルポートインターフェース４６を介してシステムバス２３に接続されている。ネットワーク環境では、コンピュータ２０に関連して示したプログラムモジュール、またはその一部は遠隔メモリストレージデバイスに記憶されてよい。図示のネットワーク接続は例示的なものであり、構成要素間で通信リンクを確立する他の手段も使用できることが理解されよう。
【００４４】
本発明の例示的な実施形態をある程度具体的に説明したが、本発明は特許請求の精神と範囲にある開示構成からのすべての変更および改変を含むことが意図される。
【図面の簡単な説明】
【００４５】
【図１】例示的なコンピュータシステムの概略図である。
【図２】通信パスを用いて通信するプリンタと印刷クライアントの概略図である。
【図３】印刷ジョブを印刷する際のプリンタと印刷クライアントとの間の通信シーケンスの概略図である。
【図４Ａ】印刷ジョブを印刷する異なるリソースを有するプリンタを示す図である。
【図４Ｂ】印刷ジョブを印刷する異なるリソースを有するプリンタを示す図である。
【図５】印刷クライアントに記憶された印刷ジョブの概略図である。
【技術分野】
【０００１】
本発明は、印刷デバイスと、個人ユーザのパーソナルコンピュータもしくは共有プリンタサーバ等のクライアントとの間で対話するためのプリンタプロトコルに関する。
【背景技術】
【０００２】
コンピュータがレンダリングのためにデバイス（プリンタ等）にドキュメントを送信した際に、このデバイスがメモリに全ドキュメントを記憶するためのリソースを備えているとは限らない。このような場合、デバイスがその限られた使用可能なリソースだけを用いて全ドキュメントをレンダリングするのを可能にするある種の機構を使用しなければならない。本明細書では、用語「印刷クライアント」はパーソナルコンピュータと共有印刷サーバの両方を指すのに用いられる。
【０００３】
ラスタベースのドキュメントフォーマットについては、通常これは、デバイスにドキュメントをバンドまたはタイルで送信することによって行われる。１つのバンドが処理されると、次のバンドがプリンタに送信される。
【０００４】
ベクトルベースのドキュメントについては、限られたリソースを用いて印刷するという問題はさらに深刻になる。ドキュメントは、それが直線、曲線およびグリフ等の描画基本要素（ｄｒａｗｉｎｇ ｐｒｉｍｉｔｉｖｅ）により表現される場合、ベクトルベースであるとみなされる。直線は、レンダリングの開始位置および修了位置、直線の幅、ならびにレンダリングの可能な色によって特徴付けられる。曲線については曲率半径という複雑さが加わる。グリフは、記号または文字の断片である。ローマ式アルファベットにおいては、文字とそのグリフとの間には、ほぼ１対１の対応がある。アラビア系または東アジア系の書記言語では、１つの文字は通常２つ以上のグリフから構成される。通常のベクトル言語には、傾き、アルファブレンド（ａｌｐｈａ ｂｌｅｎｄ）、ポリンゴン等、さらなる描画基本要素もある。しばしば、フォントもしくはピクチャ、および描画基本要素等のリソースを埋め込んだベクトルベースのドキュメントは、それら追加リソースを参照するために使用することもできる。レンダリングデバイスまたは機構を用いて、全ドキュメント、または、ドキュメント内の全リソースもしくは構成要素を、メモリ内に保持することができないということもよくある。この状況は、デバイスがドキュメントを、そして基本要素でさえも、少しずつレンダリングしなければならないということを意味している。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来技術では、ページに対するドキュメントリソースをプリンタにダウンロードして、ドキュメントリソースが必要なときに確実に使用可能になるように、ドキュメントをフォーマットしている。この解決策では、印刷クライアントが制御される（ｉｓ ｉｎ ｃｏｎｔｒｏｌ）。ＰＤＬ（ページドキュメント言語）においては、ドキュメントリソースの寿命および可用性を管理するための精巧な機構が必要となる。
【０００６】
この機構を堅牢なもの（ｒｏｂｕｓｔ）とするために、以下の３つの方策の１つが実施される。
【０００７】
１）印刷クライアントが各ページにページ用ドキュメントリソースを埋め込み、これをプリンタに送信する。これは有効ではあるものの、リソース（多数のページに共通のフォントの透かしまたはグリフ）が多くのページに現れる場合、帯域幅の観点から非効率となる。１枚のページに対するリソース要件がデバイスの能力を超えた場合、ページの印刷は不可能となる。
【０００８】
２）印刷クライアントは、ＰＤＬジェネレータ（印刷クライアントドライバのレンダリング部）からプリンタへの双方向通信チャネルを必要とする。これは、以下のいずれかを目的としている：
２ａ）消費されるプリンタリソース量を監視し、ＰＤＬストリームがリソースの一部を解放する操作を担当する場合、同操作をこのＰＤＬストリームで行うこと；
２ｂ）前もって送信されたドキュメントリソースが依然として利用可能であるかどうかを照会し、そうでない場合に限り、該ドキュメントリソースを再度送信すること。
【０００９】
３）ＰＤＬジェネレータからの双方向通信チャネルを欠いている場合、ジェネレータはそれが消費するプリンタリソース量の推定を試み、この推定に基づいて選択肢２ａ）（上述）を実行することが可能である。勿論、１００％信頼できるものではない。というのは、プリンタがどのようにＰＤＬを実行するのかをドライバが確実に把握することはできないからである。
【００１０】
上記第３の選択肢（この選択肢は現在Ｗｉｎｄｏｗｓ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）ＸＰ（登録商標）などのＷｉｎｄｏｗｓ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムが実行する）の利点は、印刷クライアントとプリンタとの間の通信が一方向で十分であるということである。
【００１１】
第３の方策を用いると、アプリケーションプログラムがプリンタの使用を開始したいとき、まずこのアプリケーションはプリンタデバイスコンテキストに対するハンドルを取得し、これによりプリンタデバイスドライバライブラリモジュール（ＤＬＬ拡張子を有するファイルおよび他のデータファイル）がメモリにロードされ、それ自身が初期化される。印刷ドライバは、オペレーティングシステムグラフィックによる支援を受けて、ＰＤＬにレンダリングする。その結果、プリンタリソースの必要量は１枚のページに対してさえも膨大になる可能性がある。この問題を解消するため、１つの先行技術の手法では、フォントをサブセットに分け、場合により画像のサイズを小さくする。必然的に上記第３の方策がプリンタを処理できないデータで一杯にする（その結果エラーメッセージを生じ、印刷が中断する）という可能性は、クライアントとプリンタの間の簡単な基本的に一方向の通信によって相殺されるのであり、このことは、パラレルプリンタポートまたはプリンタが接続された既存ネットワークから送信する場合に有利である。
【課題を解決するための手段】
【００１２】
典型的なシステムはデバイス上でのテキスト、画像等のレンダリングを制御する。クライアントとデバイスとの間に少なくとも半二重またはそれより優れた双方向通信パスを形成する通信チャネルが確立される。１つの典型的な用途では、デバイスはテキスト画像等を紙に転写するためのプリンタである。クライアントは、クライアントとして構成されたコンピュータすなわち、ネットワーク上でクライアントソフトウェアを実行するノードであってよく、あるいは、いくつかの可能な通信プロトコルのうちの１つを用いて通信する単一のコンピュータであってよい。印刷デバイスは、印刷データを記憶し、双方向通信パスを介して印刷クライアントから印刷デバイスに送信されたデータに基づく画像をレンダリングするための印刷リソースを含む。
【００１３】
クライアントは、印刷ジョブに関係する印刷サービスを求める初期要求を送信することによって、印刷デバイスによるレンダリングを開始する。一実施形態によると、この初期要求は、印刷ジョブのデータ量およびこのデータの特徴を示している。この初期要求は、印刷デバイスによって応答され、初期量のデータが要求される。印刷クライアントはそれに応じて初期量のデータを送信し、さらなるデータを求める追加の要求を待つ、または、初期の要求に応答して印刷ジョブの印刷データすべてが送信された場合、その印刷ジョブの印刷が終了したという指示を待つ。
【００１４】
代替実施形態では、ジョブのイニシエータはジョブ開始の時点で送信されたデータ量を知らされていない。それにもかかわらず、これ以上印刷するデータがなくなるまでイニシエータがプリンタにデータ要求を続けるよう通知する「ストリーム」モードでプリンタが動作できることが必要となる。この前提は上記の実施形態と類似しているが、これ以上送信するものがなくなるまでプリンタがページレベルのデータを要求し続け、クライアントがノーモアデータ（ｎｏ ｍｏｒｅ ｄａｔａ）（ＮＡＫ）メッセージで応答する点が異なる。
【００１５】
本発明に関する上記および他の目的、利点および特徴を添付の図面を参照しながら説明する。
【発明を実施するための最良の形態】
【００１６】
図面を参照すると、本発明の例示的な実施形態が示されている。本発明の対象となるタスクは、レンダリングするドキュメントをプリンタ等のデバイスに転送する処理である。図２は、典型的な印刷シナリオを示す。印刷クライアント１０２は通信パス１０６を用いてプリンタ１０４と通信する。コンピュータとプリンタの間の通信セッションは、照会／応答形式の通信をサポートできる任意の通信チャネルを介して実行される。例としては、ＴＣＰ、ＵＳＢ、１３９４、ブルートゥース、ＨＴＴＰ、ＳＳＬがある。半二重またはそれより優れたチャネルを使用してよい。ＨＴＴＰは、本発明のこの例示的実施形態のキャリアとして特に適している。印刷クライアント１０２のさらなる詳細は、図１を参照して説明される。
【００１７】
ドキュメントを印刷したいデバイス（たいていは印刷クライアントまたはＰＣ１０２であり、以後クライアントと称す）とプリンタとの間で行き来する通信（図３）により印刷タスクが実行される。印刷クライアントは、初期要求１１０をプリンタ１０４に送信する。１つの例示的実施形態では、初期要求は、ａ）印刷ジョブに対する固有の識別子、ｂ）ドキュメントのタイプ、および、ｃ）ドキュメントリソースが検索されるアドレス（たいていクライアントのアドレス）を含む。これは上記のコンピュータのアドレスとしてよいが、アドレスは、プリンタ１０４と通信する別の通信チャネルを介して利用可能な他のコンピュータのアドレスであってもよいことに留意されたい。
【００１８】
初期要求１１０は、印刷するページ範囲、コピーの部数など、ドキュメントに適用するプリンタ設定も含む。文書に関するメタデータ、たとえば総サイズもプリンタに送られる。最後に、初期要求はタイムアウトプリンタハートビートを含む。ハートビートは、プリンタがジョブをキューに入れている、または実施にジョブを印刷していることをクライアントに知らせる。プリンタは、メッセージを周期的に（タイムアウトで指定されるように）クライアントに送信し、印刷ジョブ要求が依然として引受け中であることをクライアントに通知する。このことにより、プリンタの電力供給が停止する等の予見できない理由により、ジョブが放棄されたかどうかをクライアントが知ることができる。
【００１９】
プリンタ１０４は、ドキュメント印刷要求が受入れ可能であるかどうかを示す応答１１２と共に、クライアントからの要求に回答する。印刷ジョブが受け入れられた場合、応答１１２はプリンタ１０４での印刷ジョブに対する固有識別子も含む。印刷ジョブが受け入れられた場合、クライアントは、プリンタが将来要求を引き受ける意志があるものとみなす。プリンタは、複数のジョブをキューに入れることも可能である。クライアント１０２は上記の識別子を用いて、管理プロトコルによりプリンタ上のドキュメントを後で操作することも可能である。プリンタ１０４はネットワークと結合してもよく、他のソースから多数の印刷ジョブを印刷する要求を受信してもよく、したがって、各ジョブにはプリンタにより固有のジョブ識別子が割当てられ、次いでクライアントにより上記ジョブに割当てられた固有の印刷ジョブ識別子（ｐｒｉｎｔ ｊｏｂ ｄｅｓｉｇｎａｔｏｒ）がプリンタに知らされる。
【００２０】
図４Ａおよび図４Ｂに示した２つのプリンタ１３０、１３２のリソースについて検討する。各プリンタは、印刷ヘッド１３４、１３５を含み、印刷ヘッド１３４、１３５は同ヘッドに送信されたデータに基づいて各プリンタにより画像をレンダリングするためのものである。代表的な印刷ヘッドは、レーザまたはインクジェット印刷ヘッドを含んでよい。２つのプリンタ１３０、１３２はまた、印刷ジョブのドキュメントのページをフォーマットするためのメモリ領域１３６、１３８を含む。両プリンタでは、メモリ１３６、１３８はほぼ同じサイズであり、典型的なプリンタでは数メガバイトのＲＡＭを含んでよい。
【００２１】
プリンタ１３０は、追加の高速メモリと、ハードドライブと、場合により特殊なグラフィックプロセッサとを含む追加のプリンタリソース１４０を有する。またプリンタ１３０は、クライアントから受信したデータを操作し、このデータをメモリ１３６に転送できるようにフォーマットするコンピュテーションハードウェア（ｃｏｍｐｕｔａｔｉｏｎａｌ ｈａｒｄｗａｒｅ）１４４を含む。プリンタ１３２は、場合により小容量の付加メモリを含むより制限されたリソース１５０を有する。第２のプリンタ１３２内のコンピュテーションハードウェア１５４もクライアントからデータを受信し、このデータをメモリ１３８で記憶するためのフォーマットで体系化する。
【００２２】
プリンタ１３０は、より多くのリソースを有しているという点で、プリンタ１３２よりも強力である。たとえば、これは複数のソースからの複数の印刷ジョブに関するリソースすべてを完全に記憶する容量を有する。プリンタ１３２は、より制約されている。これは、１ページ超のテキストを占める印刷ジョブのごく一部に対するリソースを有する。ある種のラスタプリンタについては、プリンタは、１ページのコンテンツを記憶するのに十分なリソースさえも持たない場合がある。このようなプリンタは、各ページを印刷する際にコンテンツのページを、バンド／タイル処理（ｂａｎｄ／ｔｉｌｅ）しなければならない。
【００２３】
プリンタがドキュメントをレンダリングする準備が済むと、プリンタは、クライアントが指定したアドレスにドキュメントデータを求める要求１１４を送信する。図３に示したデータの交換では、クライアントと、データを見出すアドレスとは同一である。要求１１４は、クライアントから送信された情報に基づいてドキュメントを識別する。例示的システムの一実施形態によると、データ要求１１４は、３タプル（ｘ，ｙ，ｚ）であり、ただし、ｘは検索するドキュメント内のリソースを特定し、ｙはリソースデータに対するオフセットであり、ｚはｙで開始する検索データの量である。本発明の範囲から逸脱することなく、要求の他のフォーマットも可能である。たとえば、グリフの範囲をプリンタが要求してもよい。２つのプリンタ１３０、１３２間の能力に差があるために、この要求はプリンタが異なると全く異なるものである。プリンタは、ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）により印刷に必要なリソースを参照してもよい。プリンタのコンピュテーションハードウェアは、クライアントからの戻りデータが従うべき、要求に含まれた調査および属性情報（長さ、データフォーマット、圧縮レベル、画像解像度、等）を具備するリソースを要求してよい。
【００２４】
ドキュメントリソースの記述ｘは、ドキュメントフォーマットに関連付けられる。プリンタは、初期要求１１０でフォーマットについて通知されているので、フォーマットを知っていることになる。プリンタはドキュメントフォーマットを理解する必要がある。印刷ジョブが開始すると、たとえば、プリンタはオフセットがゼロで印刷されるべき最初のページのページ記述を求め、検索されるデータに対するある好都合なサイズを指定する。プリンタは後で、ドキュメント中の他のリソースを求めてもよい。
【００２５】
図５は、複数のページを各ドキュメントが含んでよい複数のドキュメントからなる印刷ジョブ１６０を例示している。ドキュメントの１つの例は、ＸＭＬマークアップ言語によりフォーマットされたドキュメントである。各ドキュメントページは、埋め込まれたアスキーテキストならびにテキストフォント、ピッチ等の詳細を含んで良い。さらに、ページは、ドキュメントの一部ではないがリソース１６２のカタログまたはフォルダでクライアントに記憶されたドキュメント中のＸＭＬタグで定義された位置で画像（ｊｐｅｇ、ｂｍｐ等）に対する参照を含んでよい。クライアントまたはデータソース上にドキュメントファイルが存在すること、ならびにアスキーまたは他のリソースが様々なデータストリームで単一のドキュメントファイルに記憶されることも可能である。
【００２６】
この要求に対するクライアント応答１１６は、プリンタ１０４が要求したデータを含む。ジョブを完了するために必要な残りのデータが要求された量よりも自然に（ｎａｔｕｒａｌｌｙ）少ない場合、要求されたよりも少ないデータが返される。ある状況においては、プリンタは要求１１０の開始時にジョブサイズを知らないことになる。したがって、プリンタおよびクライアントが、送信すべきデータがこれ以上なくなるまでプリンタがページレベルでデータをさらに求めるストリーミングモードを実行できる必要がある。そのような必要性の一例は、数千のエントリを有するペイロールジョブに対するバッチランである。印刷ジョブに対するデータの全長は、ジョブが開始した際にクライアントに知らされる。この代替実施形態では、クライアントは、特定のサイズをジョブに対して指定することなく初期要求１１０を送信できることが必要である。
【００２７】
受信すると、プリンタはデータを処理し、このデータが何を含んでいるかに基づいて追加のデータを求める別のまたは追加の要求１１８を、クライアント１０４に対して発行する。ページがピクチャを、または場合によりフォントを含む場合は、プリンタ要求はそのピクチャまたはフォントを要求してもよい。これは、プリンタでリソースが不足しているために以前そのデータがあるページをフォーマットするために使用されたものの他ページのフォーマットが必要なため（場合により他ソースからの他の印刷ジョブが必要なため）該データが廃棄された場合に行うことができる。
【００２８】
一般に、プリンタおよびクライアントは、データをページに編成する。限られたリソースを有するプリンタ１３２があるページを印刷した場合、プリンタ１３２は次のページのデータを取り込む要求を発行する。この要求も複雑になる可能性がある、というのも、プリンタ１３２等リソースが限られたプリンタにおいては、該要求はたとえばテキストおよび画像データをインターリーブし、このデータを一度に１つのバンドで専用ページメモリ１３８にロードするからである。プリンタからのデータ要求、およびクライアントからプリンタへのデータを伴う応答は、要求されたジョブすべてが印刷されるまで繰り返される。プリンタ１３０は、他のジョブで過負荷状態でなければ、データ１１４を求める要求の中でジョブ１６０に関するリソースすべてを求める。プリンタ１３０はデータを記憶する大量のリソースを有しているので、フォントまたは画像であってもその詳細がプリンタ１３０のリソース領域１４０に既に記憶されていてもよい。
【００２９】
動作の一形態によると、プリンタは初期要求１１０でドキュメントサイズが送信されており、そのため、（ドキュメントのサイズおよびパージ範囲に基づいて）図３に示す対話のやり取りをショートサーキット化（ｓｈｏｒｔ ｃｉｒｃｕｉｔ）する十分なリソースがあるかどうかを判定できる。プリンタは、１つの要求１１４ですべてのリソースを求めてよい。これは、大量のリソースを有するプリンタに対する最適化となる。こうすることが最も効率的である、というのも、クライアントがドキュメントすべてを印刷したくて、かつプリンタがリソースを有している場合、最も速い方法は一度にドキュメントリソースすべてを受信することであるからである。
【００３０】
他の動作形態では、初期要求１１０はジョブまたはドキュメントサイズを知らない。プリンタは、データの要求を続ける全ドキュメント印刷モードに加えて、送信すべきものがなくなるまでオープンエンド要求または「ストリーム」モードに応答する必要がある。クライアントは、ページに対するデータすべてが利用可能な場合のみ新しいページの送信を開始することになる。利用可能なページがない場合、クライアントは「ノーモアデータ」メッセージを送信し、プリンタは印刷動作を終了する。
【００３１】
第１の実施形態では、基本的な前提は、プリンタが印刷開始を求められたときドキュメントが既に完全であること、または、プリンタが消費できるよりも迅速にドキュメント（サイズは既知）のコンテンツが生成されることである。この前提は通常は成立するが、常に成り立つというわけではない。この起こり得る問題を解消するため、２つの概念を導入する。
【００３２】
プリンタがリソース１１４を求める要求を送信すると、クライアントからの応答１１６がリソースは利用可能でないことを提示してよい。この応答はタイムアウトを含む。プリンタは、この時点でジョブの処理を停止する。次いで印刷クライアントは、要求データが利用可能になったとき、別の要求をプリンタに送信しなければならない。プリンタはリソース利用可能メッセージ（ｒｅｓｏｕｒｃｅ ａｖａｉｌａｂｌｅ ｍｅｓｓａｇｅ）に対して承認（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）で応答する。プリンタは、リソースを求める要求を再送することによりジョブを再開する。リソースがタイムアウト内に利用可能にならず、かつコンテンツがドキュメントに対して依然として追加中であれば、クライアントは他リソース利用不可能要求（ａｎｏｔｈｅｒ ｒｅｓｏｕｒｃｅ ｎｏｔ ａｖａｉｌａｂｌｅ ｒｅｑｕｅｓｔ）を送信することにより、タイムアウトを新タイムアウトによってリセットする。プリンタは待機し続ける。
【００３３】
リソース要求に対する各応答１１６は、コンテンツが依然としてドキュメントに追加中であるか否かを示すフラグを有する。これは、プリンタがドキュメント全体を印刷することを求められ、かつプリンタがドキュメントをその作成よりも速く消費する場合に重要となる。プリンタは次のページを求め続けることが可能である。ページが存在しない場合、クライアントはコンテンツ利用不可能メッセージ（ｃｏｎｔｅｎｔ ｕｎａｖａｉｌａｂｌｅ ｍｅｓｓａｇｅ）で応答する。プリンタは、コンテンツにフラグセットが追加されていない応答を見ると、すべてのページが印刷されたことを知る。リソース要求に対するすべての応答パケットは適切にフラグセットを有するべきである。
【００３４】
プリンタは様々なリソースを有し、本発明の１つの特徴は、一度に１つずつドキュメントまたはジョブのリソースをプリンタが求める場合に対処できることである。単純な例では、プリンタは、ページ１の最後に到達するまでに、ドキュメントの最初のページの１０００バイト分を求め、次いで次の１０００バイト分を求め、以下同様にする。より現実的なシナリオでは、ドキュメントフォーマットは、クライアントとプリンタとの間の通信を効率的にするために、リソース参照に対する埋込みリソースサイズを含むページサイズ、および、ページ記述を有するページインデックスを含む。
【００３５】
プリンタは、ジョブが完了したことを判定する要求１１８をクライアントに送信する。クライアントがプリンタからの要求への応答に失敗した、もしくは、ドキュメントが存在しない（ドキュメントが削除された可能性があることを示す）場合、プリンタはジョブを削除しなければならない。プリンタは、適切とみなされる場合に、要求を再び試みてよい。
【００３６】
図３の一連の通信対話は、印刷ドキュメントの基本フォーマットを示す。基本的概念に追加された特徴を実現するいくつかの改善が企図される。プリンタ１０４がクライアント１０２により送信されたメタデータから、ドキュメント全体に対処する十分なリソースを有すると判定された場合、プリンタはドキュメント全体を転送する要求を行ってもよい。
【００３７】
プリンタ１３０等の強力なプリンタはリソースまたはリソースの一部をダウンロードすると、それをヒットキャッシュ（ｈｉｔ ｃａｃｈｅ）に記憶できる。リソースは、利用されていない場合、または、新たなリソースがキャッシュに追加された場合、キャッシュから経時的に除かれる（ａｇｅ ｏｕｔ）。このシナリオでは、プリンタはまず、リソースを求める要求を発行する必要がある場合、キャッシュを確認する。これにより通信量が軽減され、プロトコルの騒然な行き交い（ｃｈａｔｔｉｎｅｓｓ）が低減され、レンダリングの性能が改善される。
【００３８】
コンピュータシステム
図１は、例示的な処理デバイスを示す。図１に示した処理デバイスはクライアント１０２として機能できる。図１に示したようなデバイスは、プリンタ１３０等より強力なプリンタ向けのコンピュテーションハードウェアとしても機能できる。システムは従来型のコンピュータ２０の形態の汎用コンピューティングデバイスを含み、コンピュータ２０は、１つもしくは複数の処理ユニット２１、システムメモリ２２、ならびに該システムメモリを処理ユニット２１に対して接続することも含めて、各種のシステム構成部品を互いに接続するシステムバス２３を含む。システムバス２３は、メモリバスもしくはメモリコントローラと、周辺バスと、各種バスアーキテクチャのいずれかを用いたローカルバスを含む数種のバス構造のうちのいずれであってもよい。
【００３９】
システムメモリは、読出専用メモリ（ＲＯＭ）２４、ランダムアクセスメモリ（ＲＡＭ）２５を含む。起動時等にコンピュータ２０内の各要素間で情報の伝達を助ける基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４に記憶されている。
【００４０】
コンピュータ２０は、ハードディスクからの読取りおよびそれに対する書込みをするためのハードディスクドライブ２７（不図示）、取外し可能磁気ディスク２９からの読取りまたはそれに対する書込みをするための磁気ディスクドライブ２８、ならびに、ＣＤ ＲＯＭまたは他の光メディア等の取外し可能光ディスク３１からの読取りまたはそれに対する書込みをするための光ディスクドライブ３０をさらに含む。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれ、ハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ディスクドライブインターフェース３４を介してシステムバス２３に接続されている。上記ドライバおよび上記ドライバに関連するコンピュータ読取り可能メディアは、コンピュータ２０用のコンピュータ読取り可能な命令、データ構造、プログラムモジュールおよび他のデータのための不揮発性ストレージを形成する。本明細書で説明する例示的環境ではハードディスク、取外し可能磁気ディスク２９、および取外し可能光ディスク３１を使用するが、コンピュータがアクセス可能なデータ記憶可能な他の種類のコンピュータ読取り可能メディア、たとえば磁気カセット、フラッシュメモリカード、デジタルビデオディスク、Ｂｅｒｎｏｕｌｌｉカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読出専用メモリ（ＲＯＭ）等も例示的動作環境で使用可能であることを当業者は理解されよう。
【００４１】
オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含め、いくつかのプログラムモジュールをハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ ２４またはＲＡＭ ２５に記憶してよい。ユーザは、キーボード４０およびポインティングデバイス４２等の入力デバイスを介してコンピュータ２０にコマンドおよび情報を入力できる。他のデバイス（不図示）は、マイクロフォン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ等を含む。上記および他の入力デバイスはしばしばシステムバスに結合されたシリアルポートインターフェース４６を介して処理ユニット２１に接続されるが、他のインターフェース、たとえばパラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）を介して接続されてもよい。モニタ４７または他の種類の表示デバイスも、ビデオアダプタ４８等のインターフェースを介してシステムバス２３に接続される。モニタに加えて、パーソナルコンピュータは典型的には、スピーカおよびプリンタ等の他の周辺出力デバイス（不図示）を含む。
【００４２】
コンピュータ２０は、遠隔コンピュータ４９等の１つまたは複数の遠隔コンピュータに対する論理接続を用いたネットワーク環境で動作してもよい。遠隔コンピュータ４９は、他のパーソナルコンピュータ、クライアント、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードであってよく、典型的にはコンピュータ２０に関する上述の要素の多くまたは全てを含むが、ただし図１では１つのメモリストレージデバイス５０しか示さない。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。
【００４３】
ＬＡＮネットワーク環境で使用する場合、コンピュータ２０は、ネットワークインターフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーク環境で使用する場合、コンピュータ２０は典型的には、インターネット等の広域ネットワーク５２上の通信を確立するためのモデム５４または他の手段を含む。モデム５４は内部的でも外部的でもよいが、シリアルポートインターフェース４６を介してシステムバス２３に接続されている。ネットワーク環境では、コンピュータ２０に関連して示したプログラムモジュール、またはその一部は遠隔メモリストレージデバイスに記憶されてよい。図示のネットワーク接続は例示的なものであり、構成要素間で通信リンクを確立する他の手段も使用できることが理解されよう。
【００４４】
本発明の例示的な実施形態をある程度具体的に説明したが、本発明は特許請求の精神と範囲にある開示構成からのすべての変更および改変を含むことが意図される。
【図面の簡単な説明】
【００４５】
【図１】例示的なコンピュータシステムの概略図である。
【図２】通信パスを用いて通信するプリンタと印刷クライアントの概略図である。
【図３】印刷ジョブを印刷する際のプリンタと印刷クライアントとの間の通信シーケンスの概略図である。
【図４Ａ】印刷ジョブを印刷する異なるリソースを有するプリンタを示す図である。
【図４Ｂ】印刷ジョブを印刷する異なるリソースを有するプリンタを示す図である。
【図５】印刷クライアントに記憶された印刷ジョブの概略図である。
【特許請求の範囲】
【請求項１】
デバイスによりレンダリングを制御する方法であって、
ａ）クライアントとレンダリングデバイスの間に少なくとも半二重またはそれより優れた双方向通信パスを形成するステップであって、前記デバイスは、データを記憶し、前記双方向通信パスを介してクライアントから前記デバイスに送信されたデータに基づいて画像をレンダリングするためのリソースを含むことと、
ｂ）前記デバイスによるレンダリングを、
ｉ）ジョブの特徴を示す、前記ジョブに関するサービスを求める初期要求を前記デバイスに送信し、
ｉｉ）初期要求に応答し、送信されるべきレンダリングデータを要求し、
ｉｉｉ）レンダリングデータを求める前記要求に応答して、レンダリングデータを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記レンダリングデバイスに送信された場合は前記ジョブのレンダリングが完了したという指示を待つ
ことにより、総合調整するステップと、
を備えることを特徴とする方法。
【請求項２】
前記初期要求と共に送信された前記特徴は前記ジョブのデータ量を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記初期要求は前記ジョブのデータ量が未知であることを示すことを特徴とする請求項１に記載の方法。
【請求項４】
前記デバイスに送信された前記データは、前記ジョブに対するデータが現在利用不可能であることを前記デバイスに示すデータ利用不可能インジケータを含み、さらに、前記データが利用可能になるまで前記デバイスが前記ジョブの処理をその間中断するタイムアウトを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記クライアントはデータを、前記データが前記クライアントに利用可能になった場合に前記レンダリングデバイスに送信し、前記レンダリングデバイスはさらなるデータの受信またはデータインジケータの終了を待つことを特徴とする請求項１に記載の方法。
【請求項６】
前記デバイスは、既に前記デバイスに送信されたデータを廃棄して、印刷クライアントからの追加データを収容することを特徴とする請求項１に記載の方法。
【請求項７】
前記デバイスは、後続のレンダリングで使用するために、前記ジョブのレンダリング中に以前廃棄したデータの再送信を求める要求を行うことを特徴とする請求項６に記載の方法。
【請求項８】
前記レンダリングデバイスはプリンタであり、前記データは前記クライアントにより複数のページに編成されており、前記プリンタから前記クライアントに送信されたデータを求める前記要求は、１つまたは複数のページを印刷する必要を満足することを特徴とする請求項１に記載の方法。
【請求項９】
前記初期要求は前記ジョブのデータ量を含み、前記クライアントから送信された前記初期要求から前記プリンタが、ドキュメントすべてに対処する十分なリソースを有すると判断した場合、前記プリンタはドキュメントすべてを印刷するためのデータ転送を要求することを特徴とする請求項８に記載の方法。
【請求項１０】
前記レンダリングデバイスはプリンタであり、前記プリンタは、ドキュメントリソースまたはドキュメントリソースの一部を記憶するメモリを備え、前記プリンタはヒットキャッシュを保持し、新たなリソースが前記キャッシュに加えられた場合に、前記リソースが最近使用されていない場合、前記キャッシュからリソースを削除することを特徴とする請求項１に記載の方法。
【請求項１１】
前記プリンタは、リソースを求める要求を発行する必要がある場合、まず前記キャッシュを確認することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記初期要求に応答してデータのレンダリングを求めることが、実質的に直ちに、または、他のクライアントからのデータをレンダリングするためにリソースを利用することによる遅延の後に行われることを特徴とする請求項１に記載の方法。
【請求項１３】
プリンタによる印刷ジョブの印刷を制御する方法であって、
クライアントから前記プリンタに印刷ジョブ要求を送信するステップであって、前記要求は、ジョブに対する固有ソース識別子、前記印刷ジョブを構成する１つもしくは複数のドキュメントのタイプ、複数のドキュメントリソースを取り込めるソースアドレス、前記１つまたは複数のドキュメントに適用する印刷設定、前記１つまたは複数のドキュメントに関するメタデータ、およびプリンタタイムアウトを含むことと、
前記要求に対して、前記ドキュメント印刷要求が受入れ可能であるかどうかを示す初期応答によって回答し、前記要求が受入れ可能である場合、前記クライアントが次いで前記プリンタ上の前記印刷ジョブを特定するのに使用するために、前記プリンタでの前記印刷ジョブに対してプリンタ識別子を供給するステップと、
前記ソースアドレスでのドキュメントデータを求めるデータ要求を提出するステップであって、前記データ要求は、取り込むべき前記ドキュメント内のリソース、および取り込むべきリソースデータの量を特定することと、
前記要求されたドキュメントデータを前記プリンタに送信するステップと、
前記データを前記プリンタにおいて処理し、前記ドキュメントデータのコンテンツに基づいて、追加のドキュメントデータを求める前記クライアントに向けた追加要求を発行するステップと、
を備えることを特徴とする方法。
【請求項１４】
前記メタデータは前記１つまたは複数のドキュメントのサイズおよびタイプを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記データ要求はリソースデータ集合に対するオフセットを含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記リソースデータ集合はグリフまたはグリフの範囲であることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記リソースはピクチャまたはフォントを含み、前記プリンタは前記フォントまたはピクチャ用のデータを取り込むための新たな要求を発行することを特徴とする請求項１３に記載の方法。
【請求項１８】
前記プリンタはページを１つずつフォーマットし、各ページの後に前記プリンタは次のページのデータを取り込むための要求を発行することを特徴とする請求項１３に記載の方法。
【請求項１９】
印刷リソースを求める要求はジョブのすべてが印刷されるまで繰り返されることを特徴とする請求項１３に記載の方法。
【請求項２０】
前記プリンタは、前記ジョブが完了したことを示すメッセージを前記クライアントに送信することを特徴とする請求項１３に記載の方法。
【請求項２１】
前記印刷ジョブ要求は、前記プリンタが前記印刷ジョブを受け入れると、それが前記クライアントに利用可能になったときデータが前記クライアントから前記プリンタに送信されるストリーミングモードを示すことを特徴とする請求項１３に記載の方法。
【請求項２２】
前記初期要求はジョブのデータ量が未知であることを示すことを特徴とする請求項１３に記載の方法。
【請求項２３】
前記プリンタに送信された前記データは、前記ジョブのデータは現在利用不可能であることを前記プリンタに示すデータ利用不可能インジケータを含み、さらに、前記データが利用可能になるまで前記デバイスが前記ジョブの処理をその間中断するタイムアウトを含むことを特徴とする請求項１３に記載の方法。
【請求項２４】
データが前記クライアントに利用可能な場合に前記クライアントは前記データを前記プリンタに送信し、前記プリンタはさらなるデータまたはデータ終了インジケータの受信を待つことを特徴とする請求項１３に記載の方法。
【請求項２５】
ａ）送信するために印刷データを複数のページにフォーマットするクライアントと、
ｂ）前記クライアントから前記印刷データを受信し、前記印刷データに基づいて画像をレンダリングするプリンタと、
ｃ）クライアントと前記プリンタの間に少なくとも半二重またはそれより優れた双方向通信パスを形成する通信チャネルであって、前記プリンタは、印刷データを記憶し、前記双方向通信パスを介してクライアントから前記プリンタに送信されたデータに基づいて画像をレンダリングするための印刷リソースを含ことと、
ｄ）前記プリンタによる画像レンダリングの総合調整を、
ｉ）ジョブの特徴を示す、前記ジョブに関するサービスを求める初期要求を前記プリンタに送信し、
ｉｉ）初期要求に応答し、送信されるべき印刷データを要求し、
ｉｉｉ）印刷データを求める前記要求に応答して、印刷データを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記プリンタに送信された場合は前記ジョブの印刷が完了したという指示を待つ
ことによって行う、前記プリンタまたは前記クライアントに含まれる構成要素と、
を備えることを特徴とするドキュメント印刷システム。
【請求項２６】
前記プリンタは１ページ分のデータを記憶するページメモリを備え、前記ページメモリのコンテンツに基づいて画像をレンダリングするために前記ページメモリと通信する印刷ヘッドをさらに備えることを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記プリンタは、前記印刷クライアントから印刷データを求める要求を繰り返すことを回避するために、印刷データを記憶するリソースを含むことを特徴とする請求項２５に記載のシステム。
【請求項２８】
前記プリンタはドキュメントリソースまたはドキュメントリソースの一部を保持するメモリを備え、前記プリンタは、ヒットキャッシュを保持し、新たなリソースが前記キャッシュに加えられた場合に前記リソースが最近使用されていない場合、前記キャッシュからのリソースを削除するコンピュテーションデバイスを備えることを特徴とする請求項２５に記載のシステム。
【請求項２９】
前記プリンタのコンピュテーションデバイスは、リソースを求める要求を発行する必要がある場合、まず前記キャッシュを確認することを特徴とする請求項２８に記載のシステム。
【請求項３０】
ａ）クライアントとデバイスの間に少なくとも半二重またはそれより優れた双方向通信パスを形成する手段であって、前記デバイスは、データを記憶し、前記双方向通信パスを介してクライアントから前記デバイスに送信されたデータに基づいて画像をレンダリングするためのリソースを含むことと、
ｂ）前記デバイスによるレンダリングを、
ｉ）ジョブの特徴を示す、前記ジョブに関するサービスを求める初期要求を前記デバイスに送信し、
ｉｉ）初期要求に応答し、送信されるべきレンダリングデータを要求し、
ｉｉｉ）レンダリングデータを求める前記要求に応答して、レンダリングデータを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記レンダリングデバイスに送信された場合は前記ジョブのレンダリングが完了したという指示を待つ
ことにより、総合調整する手段と、
を備えることを特徴とするデバイスによるレンダリングを制御する装置。
【請求項３１】
プリンタによる印刷を制御するための命令を含むコンピュータ読取り可能媒体であって、前記命令は、
ａ）クライアントと、データを記憶するリソースを含むプリンタとの間に半二重またはそれより優れた双方向通信パスを形成し、前記双方向通信パスを介してクライアントから前記プリンタに送信されたデータに基づいて画像をレンダリングすることと、
ｂ）前記デバイスによる印刷を、
ｉ）印刷ジョブの特徴を示す、ジョブに関するサービスを求める初期要求を前記プリンタに送信し、
ｉｉ）初期要求に応答し、送信されるべきレンダリングデータを要求し、
ｉｉｉ）レンダリングデータを求める前記要求に応答して、レンダリングデータを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記レンダリングデバイスに送信された場合は前記ジョブのレンダリングが完了したという指示を待つことにより、総合調整することと、
を備えることを特徴とするコンピュータ読取り可能媒体。
【請求項１】
デバイスによりレンダリングを制御する方法であって、
ａ）クライアントとレンダリングデバイスの間に少なくとも半二重またはそれより優れた双方向通信パスを形成するステップであって、前記デバイスは、データを記憶し、前記双方向通信パスを介してクライアントから前記デバイスに送信されたデータに基づいて画像をレンダリングするためのリソースを含むことと、
ｂ）前記デバイスによるレンダリングを、
ｉ）ジョブの特徴を示す、前記ジョブに関するサービスを求める初期要求を前記デバイスに送信し、
ｉｉ）初期要求に応答し、送信されるべきレンダリングデータを要求し、
ｉｉｉ）レンダリングデータを求める前記要求に応答して、レンダリングデータを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記レンダリングデバイスに送信された場合は前記ジョブのレンダリングが完了したという指示を待つ
ことにより、総合調整するステップと、
を備えることを特徴とする方法。
【請求項２】
前記初期要求と共に送信された前記特徴は前記ジョブのデータ量を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記初期要求は前記ジョブのデータ量が未知であることを示すことを特徴とする請求項１に記載の方法。
【請求項４】
前記デバイスに送信された前記データは、前記ジョブに対するデータが現在利用不可能であることを前記デバイスに示すデータ利用不可能インジケータを含み、さらに、前記データが利用可能になるまで前記デバイスが前記ジョブの処理をその間中断するタイムアウトを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記クライアントはデータを、前記データが前記クライアントに利用可能になった場合に前記レンダリングデバイスに送信し、前記レンダリングデバイスはさらなるデータの受信またはデータインジケータの終了を待つことを特徴とする請求項１に記載の方法。
【請求項６】
前記デバイスは、既に前記デバイスに送信されたデータを廃棄して、印刷クライアントからの追加データを収容することを特徴とする請求項１に記載の方法。
【請求項７】
前記デバイスは、後続のレンダリングで使用するために、前記ジョブのレンダリング中に以前廃棄したデータの再送信を求める要求を行うことを特徴とする請求項６に記載の方法。
【請求項８】
前記レンダリングデバイスはプリンタであり、前記データは前記クライアントにより複数のページに編成されており、前記プリンタから前記クライアントに送信されたデータを求める前記要求は、１つまたは複数のページを印刷する必要を満足することを特徴とする請求項１に記載の方法。
【請求項９】
前記初期要求は前記ジョブのデータ量を含み、前記クライアントから送信された前記初期要求から前記プリンタが、ドキュメントすべてに対処する十分なリソースを有すると判断した場合、前記プリンタはドキュメントすべてを印刷するためのデータ転送を要求することを特徴とする請求項８に記載の方法。
【請求項１０】
前記レンダリングデバイスはプリンタであり、前記プリンタは、ドキュメントリソースまたはドキュメントリソースの一部を記憶するメモリを備え、前記プリンタはヒットキャッシュを保持し、新たなリソースが前記キャッシュに加えられた場合に、前記リソースが最近使用されていない場合、前記キャッシュからリソースを削除することを特徴とする請求項１に記載の方法。
【請求項１１】
前記プリンタは、リソースを求める要求を発行する必要がある場合、まず前記キャッシュを確認することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記初期要求に応答してデータのレンダリングを求めることが、実質的に直ちに、または、他のクライアントからのデータをレンダリングするためにリソースを利用することによる遅延の後に行われることを特徴とする請求項１に記載の方法。
【請求項１３】
プリンタによる印刷ジョブの印刷を制御する方法であって、
クライアントから前記プリンタに印刷ジョブ要求を送信するステップであって、前記要求は、ジョブに対する固有ソース識別子、前記印刷ジョブを構成する１つもしくは複数のドキュメントのタイプ、複数のドキュメントリソースを取り込めるソースアドレス、前記１つまたは複数のドキュメントに適用する印刷設定、前記１つまたは複数のドキュメントに関するメタデータ、およびプリンタタイムアウトを含むことと、
前記要求に対して、前記ドキュメント印刷要求が受入れ可能であるかどうかを示す初期応答によって回答し、前記要求が受入れ可能である場合、前記クライアントが次いで前記プリンタ上の前記印刷ジョブを特定するのに使用するために、前記プリンタでの前記印刷ジョブに対してプリンタ識別子を供給するステップと、
前記ソースアドレスでのドキュメントデータを求めるデータ要求を提出するステップであって、前記データ要求は、取り込むべき前記ドキュメント内のリソース、および取り込むべきリソースデータの量を特定することと、
前記要求されたドキュメントデータを前記プリンタに送信するステップと、
前記データを前記プリンタにおいて処理し、前記ドキュメントデータのコンテンツに基づいて、追加のドキュメントデータを求める前記クライアントに向けた追加要求を発行するステップと、
を備えることを特徴とする方法。
【請求項１４】
前記メタデータは前記１つまたは複数のドキュメントのサイズおよびタイプを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記データ要求はリソースデータ集合に対するオフセットを含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記リソースデータ集合はグリフまたはグリフの範囲であることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記リソースはピクチャまたはフォントを含み、前記プリンタは前記フォントまたはピクチャ用のデータを取り込むための新たな要求を発行することを特徴とする請求項１３に記載の方法。
【請求項１８】
前記プリンタはページを１つずつフォーマットし、各ページの後に前記プリンタは次のページのデータを取り込むための要求を発行することを特徴とする請求項１３に記載の方法。
【請求項１９】
印刷リソースを求める要求はジョブのすべてが印刷されるまで繰り返されることを特徴とする請求項１３に記載の方法。
【請求項２０】
前記プリンタは、前記ジョブが完了したことを示すメッセージを前記クライアントに送信することを特徴とする請求項１３に記載の方法。
【請求項２１】
前記印刷ジョブ要求は、前記プリンタが前記印刷ジョブを受け入れると、それが前記クライアントに利用可能になったときデータが前記クライアントから前記プリンタに送信されるストリーミングモードを示すことを特徴とする請求項１３に記載の方法。
【請求項２２】
前記初期要求はジョブのデータ量が未知であることを示すことを特徴とする請求項１３に記載の方法。
【請求項２３】
前記プリンタに送信された前記データは、前記ジョブのデータは現在利用不可能であることを前記プリンタに示すデータ利用不可能インジケータを含み、さらに、前記データが利用可能になるまで前記デバイスが前記ジョブの処理をその間中断するタイムアウトを含むことを特徴とする請求項１３に記載の方法。
【請求項２４】
データが前記クライアントに利用可能な場合に前記クライアントは前記データを前記プリンタに送信し、前記プリンタはさらなるデータまたはデータ終了インジケータの受信を待つことを特徴とする請求項１３に記載の方法。
【請求項２５】
ａ）送信するために印刷データを複数のページにフォーマットするクライアントと、
ｂ）前記クライアントから前記印刷データを受信し、前記印刷データに基づいて画像をレンダリングするプリンタと、
ｃ）クライアントと前記プリンタの間に少なくとも半二重またはそれより優れた双方向通信パスを形成する通信チャネルであって、前記プリンタは、印刷データを記憶し、前記双方向通信パスを介してクライアントから前記プリンタに送信されたデータに基づいて画像をレンダリングするための印刷リソースを含ことと、
ｄ）前記プリンタによる画像レンダリングの総合調整を、
ｉ）ジョブの特徴を示す、前記ジョブに関するサービスを求める初期要求を前記プリンタに送信し、
ｉｉ）初期要求に応答し、送信されるべき印刷データを要求し、
ｉｉｉ）印刷データを求める前記要求に応答して、印刷データを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記プリンタに送信された場合は前記ジョブの印刷が完了したという指示を待つ
ことによって行う、前記プリンタまたは前記クライアントに含まれる構成要素と、
を備えることを特徴とするドキュメント印刷システム。
【請求項２６】
前記プリンタは１ページ分のデータを記憶するページメモリを備え、前記ページメモリのコンテンツに基づいて画像をレンダリングするために前記ページメモリと通信する印刷ヘッドをさらに備えることを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記プリンタは、前記印刷クライアントから印刷データを求める要求を繰り返すことを回避するために、印刷データを記憶するリソースを含むことを特徴とする請求項２５に記載のシステム。
【請求項２８】
前記プリンタはドキュメントリソースまたはドキュメントリソースの一部を保持するメモリを備え、前記プリンタは、ヒットキャッシュを保持し、新たなリソースが前記キャッシュに加えられた場合に前記リソースが最近使用されていない場合、前記キャッシュからのリソースを削除するコンピュテーションデバイスを備えることを特徴とする請求項２５に記載のシステム。
【請求項２９】
前記プリンタのコンピュテーションデバイスは、リソースを求める要求を発行する必要がある場合、まず前記キャッシュを確認することを特徴とする請求項２８に記載のシステム。
【請求項３０】
ａ）クライアントとデバイスの間に少なくとも半二重またはそれより優れた双方向通信パスを形成する手段であって、前記デバイスは、データを記憶し、前記双方向通信パスを介してクライアントから前記デバイスに送信されたデータに基づいて画像をレンダリングするためのリソースを含むことと、
ｂ）前記デバイスによるレンダリングを、
ｉ）ジョブの特徴を示す、前記ジョブに関するサービスを求める初期要求を前記デバイスに送信し、
ｉｉ）初期要求に応答し、送信されるべきレンダリングデータを要求し、
ｉｉｉ）レンダリングデータを求める前記要求に応答して、レンダリングデータを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記レンダリングデバイスに送信された場合は前記ジョブのレンダリングが完了したという指示を待つ
ことにより、総合調整する手段と、
を備えることを特徴とするデバイスによるレンダリングを制御する装置。
【請求項３１】
プリンタによる印刷を制御するための命令を含むコンピュータ読取り可能媒体であって、前記命令は、
ａ）クライアントと、データを記憶するリソースを含むプリンタとの間に半二重またはそれより優れた双方向通信パスを形成し、前記双方向通信パスを介してクライアントから前記プリンタに送信されたデータに基づいて画像をレンダリングすることと、
ｂ）前記デバイスによる印刷を、
ｉ）印刷ジョブの特徴を示す、ジョブに関するサービスを求める初期要求を前記プリンタに送信し、
ｉｉ）初期要求に応答し、送信されるべきレンダリングデータを要求し、
ｉｉｉ）レンダリングデータを求める前記要求に応答して、レンダリングデータを送信し、さらなるデータを求める追加要求を待つ、またはジョブのデータすべてが前記レンダリングデバイスに送信された場合は前記ジョブのレンダリングが完了したという指示を待つことにより、総合調整することと、
を備えることを特徴とするコンピュータ読取り可能媒体。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【公表番号】特表２００７−５１４２３６（Ｐ２００７−５１４２３６Ａ）
【公表日】平成１９年５月３１日（２００７．５．３１）
【国際特許分類】
【出願番号】特願２００６−５４３７９７（Ｐ２００６−５４３７９７）
【出願日】平成１６年７月３０日（２００４．７．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２４６９８
【国際公開番号】ＷＯ２００５／０６０３９０
【国際公開日】平成１７年７月７日（２００５．７．７）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成１９年５月３１日（２００７．５．３１）
【国際特許分類】
【出願日】平成１６年７月３０日（２００４．７．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２４６９８
【国際公開番号】ＷＯ２００５／０６０３９０
【国際公開日】平成１７年７月７日（２００５．７．７）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]