JP6102323B2

JP6102323B2 - 印刷処理システム

Info

Publication number: JP6102323B2
Application number: JP2013031067A
Authority: JP
Inventors: 千種　孝也; 孝也千種
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2012-07-10
Filing date: 2013-02-20
Publication date: 2017-03-29
Anticipated expiration: 2033-02-20
Also published as: US20140016160A1; US9250849B2; JP2014032647A

Description

本発明は印刷処理の技術に関する。

昨今、Ｍａｃ（Ａｐｐｌｅ社のパーソナルコンピュータ）のＺｅｒｏＣｏｎｆｉｇに代表されるように、通信ケーブルで印刷機器とＰＣ（Personal Computer）を接続するだけで印刷機器のオプション構成情報を双方向通信にて取得し、印刷可能な状態に自動的にセットアップする機能が知られている。プリントキュー（プリンタ毎のジョブ等の状態を管理するデータ）を作成する時に、印刷機器のオプション構成情報を自動的に取得して設定する機能（ツール）として、ＰＳＱｕｅｒｙやＡｕｔｏＳｅｔｕｐＴｏｏｌがある。

また、トナー残量等のサプライ情報をＳＮＭＰ（Simple Network Management Protocol）によって取得し、ＯＳ（Operating System）やアプリケーションの表示機能を使って表示する機能が知られている。印刷機器のサプライ情報を取得する機能（ツール）として、ＭａｃＯＳ標準のｓｎｍｐＩｎｋやベンダー作成のＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒが知られている。

一方、特許文献１には、サーバー・クライアントシステムにおいて、コンフィギュレーションデータ取得ツールを自動化することで管理者の負担を軽くすることができる画像印刷システムが開示されている。

特許文献２には、通信機器を駆動するオンデマンドドライバを作成する装置側からの取得要求に対して通信機器が応答する機器情報を、機器外部から任意にあるいは機器内部で自動的に更新可能とする技術が開示されている。

特許文献３には、いわゆるＷｉｎｄｏｗｓ（登録商標）の双方向通信によるオプション構成情報の自動反映として、ドライバインストール後のオプション構成情報を双方向で取得し、ドライバの印刷機能に反映することを目的として、「プリンタ記述ファイルとドライバとスプーラとポートモニタとに関連づけられるネットワークプリンタのインストレーション後の自動構成のためのシステムであって、前記ドライバが、双方向要求及び双方向応答を生成できるようにするための、前記スプーラに関連する双方向アプリケーションプログラムインターフェースと、前記双方向要求及び前記双方向応答を表して印刷機能に関連づけるための、前記プリンタ記述ファイル内のシンタクスと、双方向値とプリンタ値を関連づけるための、前記ドライバに記憶される拡張ファイルと、構成変更の双方向通知を前記ドライバ及び選択されたアプリケーションに提供するための、前記ポートモニタによって制御される通知インフラストラクチャとを備えていることを特徴とするシステム」といった構成が開示されている。

特許文献４には、ドライバソフトウェアをインストールする際に、所望の印刷装置からオプション構成情報や資源情報を取得してドライバソフトウェアに書込み、インストールする技術が開示されている。

上述したように、トナー残量等のサプライ情報を取得するためにＭａｃＯＳ標準のｓｎｍｐＩｎｋやベンダー作成のＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒが用いられる。

しかし、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒのようなコマンド通信ツールでは、印刷機器によって決まる印刷プロトコル（通信プロトコル）によって不都合が発生するという問題がある。

例えば、Ｍａｃで採用されているＣＵＰＳ（Common Unix Printing System）印刷システムにおいて、サプライ情報を取得する場合にＣｏｍｍａｎｄＦｉｌｅＦｉｔｌｅｒを使用する際に、ＣＵＰＳの本体との通信をつかさどるバックエンドのサイドチャネルのみを使用することがあり、その場合にはバックエンドはオープンされるが、印刷データがバックエンドに流れることなくクローズされる。ＳＮＭＰ通信のみなので、印刷ポートに何も出力されない。

そのため、印刷プロトコルのＬＰＤ（Line Printer Daemon Protocol）とＩＰＰ（Internet Printing Protocol）の各バックエンドでは、この操作をすると、不具合が発生するという問題があった。例えば、ＩＰＰでは、スプーラが停止してしまうという問題があった。また、ＬＰＤでは、ダーティジョブがプリントキューに残ってしまって、それを削除しないと、次ジョブが流れないという問題があった。これは、印刷ポートへのゼロバイトのデータの入出力が不正な処理と判断されることに起因している。

そのため、ＬＰＤとＩＰＰではＯＳのｓｎｍｐＩｎｋを使用し、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒを使用したくない。また、ＵＳＢ（Universal Serial Bus）やＢｏｎｊｏｕｒ（Ｓｏｃｋｅｔ９１００）では、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒを使用したい、といった印刷プロトコルに応じて通信経路の選択をしたいというニーズが発生する。

しかし、どの通信経路（ツール）を使用するかはプリントキュー作成時にプリンタ記述ファイル（ＰＰＤ：PostScript printer description file）の定義で決まってしまうため、同一機種であっても印刷プロトコルごとにプリンタ記述ファイルを作らざるを得なくなるとともに、印刷プロトコルを意識してプリンタ記述ファイルを選択しなければならなくなり、都合が悪いという問題がある。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、プリントキューの作成の際に、ユーザが印刷プロトコルを意識することなく、最適な印刷システム環境を自動的に構築することにある。

上記の課題を解決するため、本発明にあっては、画像処理装置の状態を表示するためのプリントキューを作成する際に、前記画像処理装置に対して使用する印刷プロトコルを識別する手段と、識別した印刷プロトコルに応じた、情報処理装置と前記画像処理装置との間の双方向通信に利用する通信設定の定義を前記プリントキューに反映する手段とを備え、前記通信設定の定義をプリントキューに反映する手段は、識別した印刷プロトコルに応じた、画像処理に関する機能の設定の定義を前記プリントキューに同時に反映する。

本発明の印刷処理システムにあっては、プリントキューの作成の際に、ユーザが印刷プロトコルを意識することなく、最適な印刷システム環境を自動的に構築することができる。

本発明の一実施形態にかかるシステムの構成例を示す図である。情報処理装置の機能構成例を示す図である。機能構成内の信号の流れの例を示す図である。実施形態の処理例を示すフローチャート（その１）である。実施形態の処理例を示すフローチャート（その２）である。プリンタ記述ファイル（ＰＰＤ）の例を示す図（その１）である。プリンタ記述ファイル（ＰＰＤ）の例を示す図（その２）である。プリンタ記述ファイル（ＰＰＤ）の例を示す図（その３）である。プリンタ記述ファイル（ＰＰＤ）の例を示す図（その４）である。使用する印刷プロトコルと定義の書き換え内容の例を示す図である。プリンタ記述ファイル（ＰＰＤ）の他の例を示す図である。使用する印刷プロトコルと定義の書き換え内容の他の例を示す図である。プリンタ記述ファイル（ＰＰＤ）の他の例を示す図である。

以下、本発明の好適な実施形態につき説明する。

＜構成＞
図１は本発明の一実施形態にかかるシステムの構成例を示す図である。

図１において、情報処理装置（ＰＣ）１にはネットワーク３を介して画像処理装置（プリンタ）２Ａが接続されるとともに、ＵＳＢケーブル等により画像処理装置（プリンタ）２Ｂが接続されている。

情報処理装置１には、記憶装置１１、ＣＰＵ（Central Processing Unit）１２、主記憶装置１３、ネットワーク入出力インタフェース１４、ＵＳＢインタフェース１５等が設けられている。記憶装置１１には、アプリケーション、ＣＵＰＳ印刷システムやＳｎｍｐＩｎｋを含むＯＳ、ドライバ（プリンタドライバ）等が保存されている。ドライバの中には、ＰＰＤ、印刷フィルタ、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒ、ＡｕｔｏＳｅｔｕｐＴｏｏｌ、ＬａｗＩｎｋＴｏｏｌ、Ｕｔｉｌｉｔｙ、ＰｌｕｇＩｎ等が含まれる。

画像処理装置２Ａ、２Ｂには、記憶装置２１、ＣＰＵ２２、主記憶装置２３、ネットワーク入出力インタフェース２４、操作パネル２５、画像処理エンジン２６等が設けられている。記憶装置２１は、ＨＤＤ、ＦｌａｓｈＲＯＭ、ＵＳＢメモリなど、情報を記憶できるものであればよい。記憶装置２１には、本体制御ソフトウェアが格納されており、ＭＦＰ（Multi Function Printer、Multi Function Peripheral）のＣｏｐｙ機能、Ｆａｘ機能、Ｓｃａｎｎｅｒ機能、Ｐｒｉｎｔｅｒ機能、ユーザ認証機能、課金機能などが保存されている。本体制御ソフトウェアは、ＣＰＵ２２上で実行され、画像処理エンジン２６や記憶装置２１、主記憶装置２３を制御して画像処理装置２Ａ、２Ｂの各機能を実現し、ネットワーク入出力インタフェース２４を介した通信制御、操作パネル２５の制御を行う。

図２は情報処理装置１の機能構成例を示す図である。

図２において、情報処理装置１には、印刷システム１０１、アプリケーション１２１、ユーティリティ１２２、ベンダー製サプライ情報取得ツール１２５、ＯＳ内サプライ情報取得ツール１２６が設けられている。印刷システム１０１は、自動セットアップツール１０２、アプリケーションインタフェース１０３、スプーラ１０４、コンフィグファイル１０５（プリンタ記述ファイル１０６を含む）、印刷フィルタ１０７、スプール１０８、バックエンド１０９、コマンド通信ツール１１０、互換インタフェース１１１を含んでいる。ユーティリティ１２２は、ＯＳ内ユーティリティ１２３、ベンダー製ユーティリティ１２４を含んでいる。

図３は機能構成内の信号の流れの例を示す図であり、信号経路にある主要な構成要素のみを示している。

図３において、アプリケーション１２１が出力したＰＤＦファイル等の印刷文書は、印刷フィルタ１０７を通してＰＳ（Post Script）等の印刷データに変換され、スプール（１０８）に保持される。スプールに保持された印刷データは、使用する印刷プロトコルに一致したバックエンド１０９のモジュールに出力され、画像処理装置２Ａ、２Ｂに送られる。

ユーティリティ１２２（ＯＳ内ユーティリティ１２３、ベンダー製ユーティリティ１２４）が画像処理装置２Ａ、２Ｂからサプライ情報を取得する際には、印刷ポートがＳｏｃｋｅｔ９１００かＵＳＢの場合は、コマンド通信ツール（ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒ）１１０を経由してバックエンドのサイドチャネル経由で画像処理装置２Ａ、２Ｂと双方向通信を行う。コマンド通信ツール１１０は、通信した結果をデーモン（ＣＵＰＳＤａｅｍｏｎ）１１２に通知し、通知した結果はユーティリティ１２２に反映される。なお、デーモン１１２は印刷システム１０１（図２）により提供されるものである。

ＩＰＰやＬＰＤの場合、ユーティリティ１２２は、コマンド通信ツール１１０ではなく、ベンダー製サプライ情報取得ツール（ＬａｗＩｎｋＴｏｏｌ）１２５やＯＳ内サプライ情報取得ツール（ｓｎｍｐＩｎｋ）１２６にリクエストを出し、それらのツールがバックエンドを通さずにＳＮＭＰ通信を画像処理装置２Ａと行い、通信した結果をデーモン１１２に通知し、通知した結果はユーティリティ１２２に反映される。

なお、コマンド通信ツール（ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒ）１１０には、サプライ情報の取得以外に、オプション構成情報を取得するためのＳＮＭＰ通信機能や、テスト印刷や画像処理装置のメンテナンス実行などのコマンドをＰＪＬ（Printer Job Language）のＪｏｂ形式でバックエンドに流す機能がある。

＜動作＞
図４は上記の実施形態の処理例を示すフローチャートであり、プリンタディスカバリ後のプリントキュー自動作成時の動作の例である。なお、プリンタディスカバリの機能は、ＭａｃのＺｅｒｏＣｏｎｆｉｇのように、ＢｏｎｊｏｕｒやＳＮＭＰ通信等のどのようなものでもよい。

図４において、処理を開始すると（ステップＳ１０１）、通信によってプリンタを発見した後、そのＰｌａｇ＆Ｐｌａｙ情報やＭＩＢ（Management Information Base）情報から一致するＰＰＤが発見され、発見されたＰＰＤでプリントキューを自動作成する時、ＰＰＤにＡｕｔｏＳｅｔｕｐＴｏｏｌが定義されているか否か判断する（ステップＳ１０２）。

ＰＰＤにＡｕｔｏＳｅｔｕｐＴｏｏｌが定義されていると判断した場合（ステップＳ１０２のＹｅｓ）、ＡｕｔｏＳｅｔｕｐＴｏｏｌを実行する（ステップＳ１０３）。ＡｕｔｏＳｅｔｕｐＴｏｏｌの動作の詳細は後述する。

そして、ＡｕｔｏＳｅｔｕｐＴｏｏｌの実行が成功すると（ステップＳ１０４のＮｏ）、最適化されたＰＰＤデータが出力されるので、それを使ってプリントキューを作成し（ステップＳ１０５）、正常終了する（ステップＳ１０６）。プリントキューには、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒが受付可能なコマンドの指定や、ＯＳ標準のサプライ情報取得ツールであるｓｎｍｐＩｎｋを使うか使わないかの指定が含まれている。

ＡｕｔｏＳｅｔｕｐＴｏｏｌの実行が失敗するか（ステップＳ１０４のＹｅｓ）、ＡｕｔｏＳｅｔｕｐＴｏｏｌの定義がＰＰＤに無い場合（ステップＳ１０２のＮｏ）、本体構成情報の取得を実行する（ステップＳ１０７）。本体構成情報の取得方法は、ＰＳＱｕｅｒｙでもＳＮＭＰでも何でもよい。

本体構成情報の取得が成功した場合（ステップＳ１０８のＹｅｓ）、その本体構成情報を反映したＰＰＤデータでプリントキューを作成し（ステップＳ１０９）、正常終了する（ステップＳ１１０）。

本体構成情報の取得が失敗した場合（ステップＳ１０８のＮｏ）、本体構成情報を入力する画面を表示し、ユーザにより入力された本体構成情報を反映したＰＰＤデータでプリントキューを作成し（ステップＳ１１１）、正常終了する（ステップＳ１１２）。

図５はＡｕｔｏＳｅｔｕｐＴｏｏｌの実行（図４のステップＳ１０３）の処理例を示している。

図５において、処理を開始すると（ステップＳ２０１）、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒに対応したＯＳであるか否か判断する（ステップＳ２０２）。これはＯＳの提供する関数を呼び出すことで行う。

ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒに対応したＯＳでないと判断した場合（ステップＳ２０２のＮｏ）、エラー終了する（ステップＳ２０３）。エラー終了すると、ＯＳ側の機能で本体構成情報の取得が試みられる（図４のステップＳ１０７〜Ｓ１１２）。

ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒに対応したＯＳであると判断した場合（ステップＳ２０２のＹｅｓ）、使用する印刷プロトコルを調べ（ステップＳ２０４）、ＰＰＤにその印刷プロトコルに応じた通信設定の初期値が定義されているか判断する（ステップＳ２０５）。

定義がある場合（ステップＳ２０５のＹｅｓ）、印刷プロトコルに応じた通信設定の初期値に設定を書き換え、出力するＰＰＤデータに反映する（ステップＳ２０６）。

その後もしくは定義がない場合（ステップＳ２０５のＮｏ）、プリンタからオプション構成情報を取得し、出力するＰＰＤデータに反映する（ステップＳ２０７）。オプション構成情報の取得方法は、ＰＳＱｕｅｒｙでもＳＮＭＰでも何でもよい。

最後に、反映されたＰＰＤデータを出力し（ステップＳ２０８）、正常終了する（ステップＳ２０９）。

図６〜図９はプリンタ記述ファイル（ＰＰＤ）１０６の例を示す図であり、図６〜図９は１つのプリンタ記述ファイル１０６を示している。

図６における記述Ｄ１の「＊ｃｕｐｓＣｏｍｍａｎｄｓ」は、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒが受付可能なコマンドを定義している。初期値は空「""」である。

記述Ｄ２の「＊ＲＩＣｕｐｓＣｏｍｍａｎｄｓ」で始まる６行は、各印刷プロトコルに応じた「＊ｃｕｐｓＣｏｍｍａｎｄｓ」の受付可能なコマンドを定義している。

また、記述Ｄ３の「＊ｃｕｐｓＳＮＭＰＳｕｐｐｌｉｅｓ」は、ＯＳ標準のサプライ情報取得ツール（ｓｎｍｐＩｎｋ）を使うか使わないかを定義している。初期値は「Ｔｒｕｅ（使う）」である。

記述Ｄ４の「＊ＲＩＣｕｐｓＳＮＭＰＳｕｐｐｌｉｅｓ」で始まる６行は、各印刷プロトコルに応じた「＊ｃｕｐｓＳＮＭＰＳｕｐｐｌｉｅｓ」を定義している。

図７の記述Ｄ５、図８の記述Ｄ６、図９の記述Ｄ７は、ＰＳＱｕｅｒｙで自動セットアップする本来の対象（オプション構成情報）である。

ＡｕｔｏＳｅｔｕｐＴｏｏｌは、使用する印刷プロトコルに応じて、該当する「＊ＲＩＣｕｐｓＣｏｍｍａｎｄｓ」の定義内容を「＊ｃｕｐｓＣｏｍｍａｎｄｓ」の定義に反映し、該当する「＊ＲＩＣｕｐｓＳＮＭＰＳｕｐｐｌｉｅｓ」の定義の内容を「＊ｃｕｐｓＳＮＭＰＳｕｐｐｌｉｅｓ」に反映する。図１０に、使用する印刷プロトコルと書き換え内容の対応関係を示している。

ＯＳは、「＊ｃｕｐｓＣｏｍｍａｎｄｓ」に実行したいコマンドが定義されている場合は、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒを利用し、そうでない場合は、ＯＳ標準のツール・機能を利用する。また、「＊ｃｕｐｓＳＮＭＰＳｕｐｐｌｉｅｓ」が「Ｔｒｕｅ」ならＯＳ標準のＳｎｍｐＩｎｋを利用する。

この定義の例では、印刷プロトコルがＵＳＢの場合は、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒ経由でサプライ情報のみを取得する。ＯＳ標準のｓｎｍｐＩｎｋは利用しない。ＵＳＢはネットワークではないので、ＯＳのｓｎｍｐＩｎｋは利用できない。オプション構成情報の取得はＯＳ標準のＰＳＱｕｅｒｙを利用する。

印刷プロトコルがＬＰＤ，ＩＰＰの場合は、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒを使用せずにＯＳ標準のｓｎｍｐＩｎｋを利用する。ＬＰＤやＩＰＰは、バックエンドのサイドチャネルのみを使った双方向通信は、スプーラ停止などの不都合が発生するので、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒは利用しない。サプライ情報の取得にはＯＳ標準のｓｎｍｐＩｎｋを利用する。オプション構成情報の取得は、ＯＳ標準のＰＳＱｕｅｒｙを利用する。

印刷プロトコルがＳｏｃｋｅｔ、ＤＮＳＳＤ、ＭＤＮＳの場合は、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒ経由でサプライ情報取得と本体構成の自動反映を行い、ＯＳ標準のｓｎｍｐＩｎｋは利用しない。

これらの印刷プロトコル毎の通信設定の初期値は、テキストファイルであるＰＰＤで定義してあるだけなので、ユーザ都合やＯＳのパッチリリースに応じて、簡単にカスタマイズすることができる。

次に、印刷プロトコルに応じた通信設定に連動して、画像処理に関する他の設定を併せて行う例について説明する。画像処理に関する他の設定としては、
・インクジェット機のように本体側でヘッドクリーニングをするためのコマンド（Ｃｌｅａｎ）の定義
・本体側で搭載されている設定サマリやテストページを印刷するコマンド（ＰｒｉｎｔＳｅｌｆＴｅｓｔＰａｇｅ）の定義
・本体側のステータスを通知するコマンド（ＲｅｐｏｒｔＳｔａｔｕｓ）の定義
・本体側の調整シートを印刷するコマンド（ＰｒｉｎｔＡｌｉｇｎｍｅｎｔＰａｇｅ）の定義
・本体側に調整値を設定するコマンド（ＳｅｔＡｌｉｇｎｍｅｎｔ）の定義
等がある。

図１１はプリンタ記述ファイル（ＰＰＤ）１０６の他の例を示す図である。なお、処理は図４および図５に示したのと同様である。

図１１における記述Ｄ１の「＊ｃｕｐｓＣｏｍｍａｎｄｓ」は、ＣｏｍｍａｎｄＦｉｌｅＦｉｌｔｅｒが受付可能なコマンドを定義している。初期値は空「""」である。

図１２は、図１１の記述Ｄ２による、使用する印刷プロトコルと定義の書き換え内容の対応関係を示している。

この定義の例では、印刷プロトコルがＵＳＢの場合は、「ＲｅｐｏｒｔＬｅｖｅｌｓ」による通信設定に加え、「Ｃｌｅａｎ」「ＰｒｉｎｔＳｅｌｆＴｅｓｔＰａｇｅ」「ＲｅｐｏｒｔＳｔａｔｕｓ」「ＰｒｉｎｔＡｌｉｇｎｍｅｎｔＰａｇｅ」「ＳｅｔＡｌｉｇｎｍｅｎｔ」による画像処理に関する他の設定が行われる。

印刷プロトコルがＬＰＤ，ＩＰＰの場合は、通信設定はブランクであるが、「Ｃｌｅａｎ」「ＰｒｉｎｔＳｅｌｆＴｅｓｔＰａｇｅ」による画像処理に関する他の設定が行われる。

印刷プロトコルがＳｏｃｋｅｔの場合は、「ＲｅｐｏｒｔＬｅｖｅｌｓ」「ＡｕｔｏＣｏｎｆｉｇｕｒｅ」による通信設定に加え、「Ｃｌｅａｎ」「ＰｒｉｎｔＳｅｌｆＴｅｓｔＰａｇｅ」「ＲｅｐｏｒｔＳｔａｔｕｓ」「ＰｒｉｎｔＡｌｉｇｎｍｅｎｔＰａｇｅ」「ＳｅｔＡｌｉｇｎｍｅｎｔ」による画像処理に関する他の設定が行われる。

印刷プロトコルがＤＮＳＳＤ、ＭＤＮＳの場合は、「ＲｅｐｏｒｔＬｅｖｅｌｓ」「ＡｕｔｏＣｏｎｆｉｇｕｒｅ」による通信設定のみで、画像処理に関する他の設定は行っていない。

なお、上記の画像処理に関する他の設定に用いるコマンドは、印刷プロトコルに応じて単純に書き換えるだけでもよいが、更に、ＡｕｔｏＳｅｔｕｐＴｏｏｌによる書き換え処理（図５のステップＳ２０６）に際し、画像形成装置の本体側と双方向通信をして該当機能が本体側に搭載されているかどうかを確認し、搭載されている機能に対応するコマンドだけを有効なものとして書き換えに用いることができる。

調整値（Ａｌｉｇｎｍｅｎｔ）の設定に用いる具体的な値に関しては、ＡｕｔｏＳｅｔｕｐＴｏｏｌが、搭載している調整シートの種類・数・調整値の種類・数・調整値の範囲等を動的に画像形成装置の本体側から取得し、プリンタ記述ファイル（ＰＰＤ）の一部に出力することができる。処理のタイミングとしては、ＡｕｔｏＳｅｔｕｐＴｏｏｌによる書き換え処理（図５のステップＳ２０６）において行うことができる。

図１３はプリンタ記述ファイル（ＰＰＤ）に出力された調整値の例を示しており、項目毎にユニークなキーが割り当てられ、値が対応付けられている。ＯＳないしユーティリティはそれらのデータを参照することで、適切な調整シートの印刷選択肢を表示したり、調整値を選択・入力させたりすることができる。

＜総括＞
以上説明したように、本実施形態によれば、次のような利点がある。
（１）プリントキューの作成の際に、使用される印刷プロトコルを自動的に識別し、使用される印刷プロトコルに応じて、サプライ情報やオプション構成情報の取得のための通信経路を自動的に最適な設定に切り替えることにより、ユーザが印刷プロトコルを意識することなく、最適な印刷システム環境を自動的に構築することができる。
（２）テキストファイルであるＰＰＤを編集するだけでよいため、ユーザ都合やＯＳ・印刷バックエンドの仕様変更に柔軟に対応することができ、印刷プロトコルに応じた通信経路を簡単にカスタマイズすることができる。
（３）印刷プロトコルに応じた通信設定に連動して、画像処理に関する他の設定を併せて行うことができ、利便性をいっそう向上させることができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１情報処理装置
１１記憶装置
１２ＣＰＵ
１３主記憶装置
１４ネットワーク入出力インタフェース
１５ＵＳＢインタフェース
１０１印刷システム
１０２自動セットアップツール
１０３アプリケーションインタフェース
１０４スプーラ
１０５コンフィグファイル
１０６プリンタ記述ファイル
１０７印刷フィルタ
１０８スプール
１０９バックエンド
１１０コマンド通信ツール
１１１互換インタフェース
１１２デーモン
１２１アプリケーション
１２２ユーティリティ
１２３ＯＳ内ユーティリティ
１２４ベンダー製ユーティリティ
１２５ベンダー製サプライ情報取得ツール
１２６ＯＳ内サプライ情報取得ツール
２Ａ、２Ｂ画像処理装置
２１記憶装置
２２ＣＰＵ
２３主記憶装置
２４ネットワーク入出力インタフェース
２５操作パネル
２６画像処理エンジン
３ネットワーク

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

Claims

画像処理装置の状態を表示するためのプリントキューを作成する際に、前記画像処理装置に対して使用する印刷プロトコルを識別する手段と、
識別した印刷プロトコルに応じた、情報処理装置と前記画像処理装置との間の双方向通信に利用する通信設定の定義を前記プリントキューに反映する手段と
を備え、
前記通信設定の定義をプリントキューに反映する手段は、識別した印刷プロトコルに応じた、画像処理に関する機能の設定の定義を前記プリントキューに同時に反映する
ことを特徴とする印刷処理システム。
請求項１に記載の印刷処理システムにおいて、
前記通信設定の定義は、初期値の通信設定と、印刷プロトコル毎の通信設定とを記述したテキストファイルに格納される
ことを特徴とする印刷処理システム。
請求項１または２に記載の印刷処理システムにおいて、
前記通信設定の定義をプリントキューに反映する手段は、前記画像処理装置と双方向通信を行って該当する機能が前記画像処理装置に搭載されているかどうかを確認し、搭載されている機能に対応する画像処理に関する機能の設定の定義を有効なものとして前記プリントキューに反映する
ことを特徴とする印刷処理システム。
請求項１乃至３のいずれか一項に記載の印刷処理システムにおいて、
前記通信設定の定義をプリントキューに反映する手段は、前記画像処理装置と双方向通信を行って前記画像処理装置に搭載されている機能の調整値を取得し、前記プリントキューに反映する
ことを特徴とする印刷処理システム。
画像処理装置の状態を表示するためのプリントキューを作成する際に、前記画像処理装置に対して使用する印刷プロトコルを識別する手段と、
識別した印刷プロトコルに応じた、自装置と前記画像処理装置との間の双方向通信に利用する通信設定の定義を前記プリントキューに反映する手段と
を備え、
前記通信設定の定義をプリントキューに反映する手段は、識別した印刷プロトコルに応じた、画像処理に関する機能の設定の定義を前記プリントキューに同時に反映する
ことを特徴とする情報処理装置。
コンピュータを、
画像処理装置の状態を表示するためのプリントキューを作成する際に、前記画像処理装置に対して使用する印刷プロトコルを識別する手段、
識別した印刷プロトコルに応じた、自装置と前記画像処理装置との間の双方向通信に利用する通信設定の定義を前記プリントキューに反映する手段
として機能させ、
前記通信設定の定義をプリントキューに反映する手段は、識別した印刷プロトコルに応じた、画像処理に関する機能の設定の定義を前記プリントキューに同時に反映する
印刷処理プログラム。