JP2006235936A - プリンティングシステム - Google Patents

Abstract

【課題】 複数台の出力デバイスを使った大量印刷系のオフィスでは出力デバイスの機種をそろえるのが一般的である。このような環境下でも、グループプリンタドライバは、全てのメンバプリンタに対して機能を問い合わせコンフリクト処理を行った後にＵＩ表示するため、処理の最適化によるＵＩ表示パフォーマンスの向上を目的とする。
【解決手段】 印刷ジョブ制御システムＡＰＩから、メンバプリンタの識別ＩＤを獲得する手段と、メンバプリンタの構成台数を獲得する手段と、構成確認処理の適用について判断する手段と、構成確認処理を行う手段と、前記確認処理結果を保持する手段と、その結果をもとに、コンフリクト処理を適用する手段と、コンフリクト結果を元にグループプリンタドライバＵＩを表示する手段を有する。
【選択図】 図１

Description

本発明は、アプリケーションからの描画コマンドに対応して印刷処理を行う印刷データ処理装置および印刷データ処理方法、コンピュータが実行可能な印刷データ処理を行うプログラム、およびコンピュータが読み出し可能なプログラムを格納したプリンティングシステムに関するものである。

近年、ネットワーク機器が一般に利用され、ネットワーク上に多数のパソコン（以下、ＰＣ）やプリンタが接続されるようになった。このようなネットワーク環境において、印刷を行う際、ページ数の多いドキュメントあるいは部数の多いドキュメントについては、印刷時間の短縮を図るために、いったん印刷ジョブをスプールし、複数のプリンタに頁ごとあるいは部数ごとに分散して出力するシステム（分散印刷システム）が知られている。

さらに、このようなネットワーク環境において、カラー頁、モノクロ頁が混在する一つのドキュメントに対して、印刷時のコストおよび印刷時間の短縮を図るために、カラー頁はカラープリンタへ、モノクロ頁はモノクロプリンタへ分散して出力するシステム（カラー・モノクロ分散印刷システム）が知られている。

さらに、このようなネットワーク環境において、一つのドキュメントを一度の印刷指示で、複数のプリンタに同時に送信し印刷するシステム（同報印刷システム）が知られている。

また、一般のプリンタドライバは、通常の印刷処理に必要な基本的な設定情報（たとえば、印刷の部数、両面印刷の可否情報）をドライバ設定情報の共通領域（Ｐｕｂｌｉｃ ＤＥＶＭＯＤＥ）と呼ばれる領域に記憶している。この領域に設定されている情報は異なるプリンタベンダにおいても、設定項目の読み書きが可能であることが知られている。

一方、プリンタ固有の機能として、たとえば、ステイプル機能、パンチ機能、製本印刷機能といったものは、ドライバ設定情報の拡張領域（拡張 ＤＥＶＭＯＤＥ）に記憶しており、この領域の設定情報はプリンタベンダによってフォーマットが異なることも知られている。

また、アプリケーションデータから作成されたＥＭＦ（Ｅｎｈａｎｃｅｄ Ｍｅｔａ−Ｆｉｌｅ）と、仮想ドライバを介しての設定に基づき作成されたジョブ記述ファイルとを用意し、ジョブ記述ファイルに含まれるジョブの配布先のプリンタに対しＥＭＦを変換したコマンドを送信し、分散・同報印刷を行う仕組みが知られている。

例えば特許文献１には、上に述べたような仮想ドライバを利用する印刷において、仮想ドライバのダイアログ画面を介して設定された、メーカやプリンタ機種に依存しない共通な情報（用紙サイズ、用紙種等）をＤＥＶＭＯＤＥ情報として印刷設定する仕組みが開示されている。この仮想ドライバのダイアログ画面の設定可能項目は固定的なものとなっており、分散・同報印刷に利用される複数のプリンタを代表するものであり、分散・同報印刷は配布印刷などの際に、ユーザは複数のプリンタにまとめて所定の設定を行えるというメリットを受けることができた。
特開平１１−１４３６６１号公報

しかしながら、従来から知られている特許文献１によれば仮想ドライバのダイアログ画面を介して設定可能な項目が固定的なものとなっており、複数のプリンタの各々の機能を画一的なものとして扱うことになり、実際には異なる各々のプリンタの機能を十分に反映させたものであるとは云えず、各々のプリンタの機能を十分に生かしきれないという問題が挙げられている。

また、以上の問題を解決するために複数のプリンタから基本領域には、ＯＳの機能を用いて機能の吸い上げを行い、拡張領域（拡張 ＤＥＶＭＯＤＥ）に関してはプリンタドライバ開発ベンダの提供しているＡＰＩ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ：ＳＤＫ）を利用して機能を吸い上げ、さらに各プリンタドライバから吸い上げた機能に対してコンフリクト処理を施し仮想プリンタＵＩを表示させる方法あるが、全てのプリンタドライバに対して機能を問い合わせ、コンフリクト処理を行った後にＵＩ表示を行う必要があった。

また、複数台の出力デバイスを使った大量印刷系のオフィスでは、同一出力を得るため出力デバイスの機種を限定した形で運用するのが一般的である事が知られており、このようなケースでも各プリンタドライバに対してコンフリクト処理を行っており、台数が増えると、前記コンフリクト処理に時間を要してしまい、仮想プリンタのＵＩ表示要求からＵＩ表示までに時間がかかることがあり処理の最適化によりＵＩ表示パフォーマンスの向上が望まれていた。

本発明は以上の点に着目して成されたもので数台の出力デバイスを使った大量印刷系のオフィスでは出力デバイスの機種をそろえるのが一般的である。このような環境下でも、グループプリンタドライバは、全てのメンバプリンタに対して機能を問い合わせコンフリクト処理を行った後にＵＩ表示するため、処理の最適化によりＵＩ表示パフォーマンスが向上するプリンティングシステムを提供することを目的とする。

ネットワークに接続される複数のメンバプリンタを仮想的に１つのプリンタとして扱うグループプリンタへの印刷ジョブ処理指定を、グループプリンタドライバを使って行う印刷ジョブ制御システムにおいて、印刷ジョブ制御システムＡＰＩを使って、グループプリンタを構成する全てのメンバプリンタドライバの識別ＩＤを獲得する手段と、メンバプリンタの構成台数を獲得する手段と、構成確認処理の適用について判断する手段と、前記判断において適用と判断した場合には構成確認処理を行う手段と、前記確認処理結果を保持する手段と、その結果をもとにメンバプリンタに対してコンフリクト処理を適用する手段と、構成確認処理を適用しなかった場合のコンフリクト処理適用手段と、前記、コンフリクト結果を元にグループプリンタドライバＵＩを表示する手段を備える。

なお、さらに詳細に説明すれば、本発明は下記の構成によって前記課題を解決できた。

（１）ネットワークに接続されるメンバプリンタをグループプリンタとして扱い、そのプリンタに対して、印刷ジョブの処理指定をグループプリンタドライバ上で設定する印刷ジョブ制御システムにおいて、印刷ジョブ制御システムＡＰＩを使って、グループプリンタを構成する全てのメンバプリンタドライバの識別ＩＤを獲得する手段と、メンバプリンタの構成台数を獲得する手段と、構成確認処理の適用について判断する手段と、前記判断において適用と判断した場合には構成確認処理を行う手段と、前記確認処理結果を保持する手段と、その結果をもとに、メンバプリンタに対してコンフリクト処理を適用する手段と、構成確認処理を適用しない場合のコンフリクト処理適用手段と、前記、コンフリクト結果を元にグループプリンタドライバＵＩを表示する手段を有することを特徴とするプリンティングシステム。

複数の同一構成プリンタドライバがある環境下では、グループプリンタドライバＵＩ上で“構成確認フラグ”にリンクしたＵＩ設定をＯＮにする事により、グループプリンタ内の同一構成のメンバプリンタドライバの調査（構成確認処理）を行い、同一構成プリンタドライバが複数ある場合には、その中の一台のみをコンフリクト対象プリンタとする事により、処理の負荷が重いコンフリクト処理の削減を可能とする。また、前記環境下以外（全てのメンバプリンタの構成が異なるよな環境下を指す）では“構成確認フラグ”にリンクしたＵＩ設定をＯＦＦとする事で、構成確認処理によるオーバヘッドなく処理を実行可能とする。以上により、ＵＩ表示処理にかかるコンフリクト処理の最適化を図り、グループプリンタドライバのＵＩ表示処理の大幅なパフォーマンス向上が可能となる。

以下、本発明を適用するのに好適である実施形態について説明を行う。

図１は、本発明を適用可能な情報処理システムの構成を説明するブロック図である。なお、本システムにおけるクライアントコンピュータは、１台、または複数台接続されていることを仮定している。図において、１０２、１０３、１０４はクライアントコンピュータ（クライアント）としての情報処理装置であり、イーサネット（登録商標）などのネットワークケーブルによって、ネットワーク１０６に接続され、アプリケーションプログラム等の各種のプログラムを実行可能であり、印刷データをプリンタに対応するプリンタ言語に変換する機能を有するプリンタドライバを搭載している。なお、プリンタドライバは複数のプリンタドライバをサポートするものとする。１０１は本実施形態のサーバ（以下、プリントサーバと呼ぶ）としての情報処理装置であり、ネットワークケーブルによって、ネットワーク１０６に接続され、ネットワークで使用されるファイルを蓄積したり、ネットワーク１０６の使用状態を監視したりする。プリントサーバ１０１は、ネットワーク１０６に接続されている複数のプリンタを管理している。

構成としては、クライアント１０２〜１０４とプリントサーバ１０１は、一般的な情報処理装置であり、クライアントとプリントサーバには、それぞれ異なる制御を行う印刷制御プログラムが実行可能に格納されている。

また、プリントサーバ１０１は、一般的な情報処理装置であり、クライアント１０２〜１０４の機能を同時に持つこともできる。

本実施形態におけるプリントサーバ１０１は、さらにクライアントコンピュータ１０２、１０３、１０４から印刷要求が出された印字データを含む印刷ジョブを格納して印刷したり、または、クライアントコンピュータ１０２、１０３、１０４から印字データを含まないジョブ情報のみ受け取り、クライアントコンピュータ１０２、１０３、１０４の印刷順序を管理し、印刷順序になったクライアントに対して印字データを含む印刷ジョブの送信許可を通知したり、ネットワークプリンタ１０５のステータスや印刷ジョブの各種情報を取得し、クライアントコンピュータ１０２、１０３、１０４に通知したりする機能を揃えている。

１０５は印刷制御装置であるネットワークプリンタであり、図示省略したネットワークインタフェースを介してネットワーク１０６と接続されており、クライアントコンピュータから送信される印字データを含む印刷ジョブを解析して１ページずつドットイメージに変換して、１ページ毎に印刷する。１０６はネットワークであり、クライントコンピュータ１０２、１０３、１０４、サーバ１０１、ネットワークプリンタ１０５等と接続している。

図２は、本発明の情報処理装置の構成を説明するブロック図であり、情報処理装置であるクライントコンピュータ１０２、１０３、１０４も同じ構成であり、さらにサーバ１０１も同様あるいは同等のハードウェア構成とする。よって、クライアントとサーバの構成を説明するブロック図として説明する。

図２において、２００は情報処理装置の制御手段であるＣＰＵであり、ハードディスク（ＨＤ）２０５に格納されているアプリケーションプログラム、プリンタドライバプログラム、ＯＳや本発明のネットワークプリンタ制御プログラム等を実行し、ＲＡＭ２０２にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。

２０１は記憶手段であるＲＯＭであり、内部には、基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。２０２は一時記憶手段であるＲＡＭであり、ＣＰＵ２００の主メモリ、ワークエリア等として機能する。

２０３は記憶媒体読み込み手段としてのフロッピー（登録商標）ディスク（ＦＤ）ドライブであり、後述する図５に示すようにＦＤドライブ２０３を通じて記憶媒体としてのＦＤ２０４に記憶されたプログラム等を本コンピュータシステムにロードすることができる。なお、記憶媒体は、ＦＤに限らず、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＰＣカード、ＤＶＤ、ＩＣメモリカード、ＭＯ、メモリスティック等、任意である。

２０４は記憶媒体であるフロッピー（登録商標）ディスク（ＦＤ）であり、コンピュータが読み取り可能なプログラムが格納された記憶媒体である。

２０５は外部記憶手段の一つであり、大容量メモリとして機能するハードディスク（ＨＤ）であり、アプリケーションプログラム、プリンタドライバプログラム、ＯＳ、ネットワークプリンタ制御プログラム、関連プログラム等を格納している。さらにスプール手段であるスプーラはここに確保される。スプール手段は、クライアントではクライアントスプーラのことであり、プリントサーバではサーバスプーラのことである。また、プリントサーバでは、クライアントから受けたジョブ情報を格納し、順序制御を行うためのテーブルもこの外部記憶手段に生成されて格納される。

２０６は指示入力手段であるキーボードであり、ユーザがクライアントコンピュータに対して、また、オペレータや管理者がプリントサーバに対して、デバイスの制御コマンドの命令等を入力指示するものである。

２０７は表示手段であるディスプレイであり、キーボード２０６から入力したコマンドや、プリンタの状態等を表示したりするものである。

２０８はシステムバスであり、クライアントやプリントサーバであるコンピュータ内のデータの流れを司るものである。

２０９は入出力手段であるインタフェースであり、該インタフェース２０９を介して情報処理装置は外部装置とのデータのやり取りを行う。

図３は、図２に示したＲＡＭ２０２のメモリマップの一例を示す図であり、ＦＤ２０４からロードされる上記ネットワークプリンタ制御プログラムが、ＲＡＭ２０２にロードされ実行可能となった状態のメモリマップである。

本実施形態では、ＦＤ２０４からネットワークプリンタ制御プログラムおよび関連データを直接ＲＡＭ２０２にロードして実行させる例を示すが、これ以外にも、ＦＤ２０４からネットワークプリンタ制御プログラムを動作させる度に、既にネットワークプリンタ制御プログラムがインストールされているＨＤ２０５からＲＡＭ２０２にロードするようにしてもよい。

また、本ネットワークプリンタ制御プログラムを記憶する媒体は、ＦＤ以外にＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＰＣカード、ＤＶＤ、ＩＣメモリカードであってもよい。さらに、本ネットワークプリンタ制御プログラムをＲＯＭ２０１に記憶しておき、これをメモリマップの一部となすように構成し、直接ＣＰＵ２００で実行することも可能である。

また、以上の各装置と同等の機能を実現するソフトウェアをもって、ハードウェア装置の代替として構成することもできる。

また、本ネットワークプリンタ制御プログラムのことを、簡単に印刷制御プログラムと呼ぶこともある。印刷制御プログラムは、クライアントにおいて印刷ジョブの印刷先の変更を指示したり、印刷順序を変更する指示をするための制御を行うプログラムを含み、また、プリントサーバにおいて、印刷ジョブの順序制御を行ったり、印刷ジョブの印刷終了や印刷先変更要求などを通知するためのプログラムを含んでいる。また、このような制御を行う本発明の印刷制御プログラムは、クライアントにインストールされるモジュールと、プリントサーバにインストールされるモジュールを別々に分けてもよいし、ひとつの印刷制御プログラムが、実行される環境によりクライアント用として機能したり、またはプリントサーバ用として機能するようにしてもよい。あるいは一台のコンピュータに、クライアント用の機能を持つモジュールと、プリントサーバ用として機能するモジュールをともにインストールし、同時に、あるいは時分割で擬似的に平行動作させる構成も可能である。

３０１は基本Ｉ／Ｏプログラムであり、本制御装置の電源がＯＮされたときに、ＨＤ２０５からＯＳがＲＡＭ２０２に読み込まれ、ＯＳの動作を開始させるＩＰＬ（イニシャルプログラムローデイング）機能などを有しているプログラムが入っている領域である。

３０２はオペレーティングシステム（ＯＳ）であり、３０３はネットワークプリンタ制御プログラムで、ＲＡＭ２０２上に確保される領域に記憶される。３０４は関連データで、ＲＡＭ２０２上に確保される領域に記憶される。３０５はワークエリアで、ＣＰＵ２００が本プリンタ制御プログラムを実行する領域が確保されている。

図４は、図２に示したＦＤ２０４のメモリマップの一例を示す図である。

図４において、４００は前記ＦＤ２０４のデータ内容であり、４０１はデータの情報を示すボリューム情報であり、４０２はディレクトリ情報、４０３は本実施形態で説明する印刷制御プログラムであるネットワークプリンタ制御プログラム、４０４はその関連データである。４０３のネットワークプリンタ制御プログラムは、実施形態で説明するフローチャートに基づいてプログラム化したものであり、本実施例では、クライアント、サーバ共、同様の構成をとっている。

図５は、図２に示したＦＤドライブ２０３に対して挿入されるＦＤ２０４との関係を示す図であり、図２と同一のものには同一の符号を付してある。

図５において、ＦＤ２０４には、本実施形態で説明するネットワークプリンタ制御プログラムおよび関連データを格納している。

次に本実施の形態における、プリンタを複数台使用して、前述の分散、同報、代行といった印刷処理を行う、印刷ジョブ制御システムについて説明する。

なお、本実施の形態では、複数のプリンタを１台のプリンタとして仮想的に束ねるプリンタをグループプリンタ、束ねられるプリンタをメンバプリンタと呼ぶ。また、それに対応するプリンタドライバをそれぞれグループプリンタドライバ、メンバプリンタドライバと呼ぶ。

図６は本システムのクライアントサーバモデルにおいてＭｉｃｒｏｓｏｆｔ Ｗｏｒｄなどの一般的なアプリケーションから発行された印刷ジョブが、印刷ジョブ制御システムにおいてどのように処理されるかを示した図である。図６Ａにおいて、６００はクライアントマシンで、印刷ジョブ制御システムのクライアントモジュールが動作するマシンを指す。

通常、印刷の指示がされるとアプリケーションプログラムは一連の描画命令を生成し、プリンタドライバを経てＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒに渡される。Ｗｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒは、ユーザが選択したポートモニタにプリントジョブデータを渡してプリンタデバイスに送信させる手順をとる。

本実施の形態では、ユーザはあらかじめ印刷ジョブ制御システム用のポートモニタ６２１（以降、本実施例ではジョブ制御ポートモニタと略記）を指定して印刷を指示する。アプリケーションプログラム６０１は一連の描画命令を生成する。描画命令を受け取ったグループプリンタＤｒｉｖｅｒ６０３では、汎用印刷ファイルを生成し、プリンタデバイスへプリントジョブデータを送信するポートモニタではなく、ジョブ制御ポートモニタ６２１にプリントジョブデータとして送信する。ジョブ制御ポートモニタ６２１はプリントジョブデータをプリンタデバイス６５０に送信するのではなく、印刷ジョブ制御システム用プリントサービス６２２（以降、本実施例ではジョブ制御プリントサービスと略記）に送信する。ジョブ制御プリントサービス６２２は、プリントジョブデータに対して、後述するような印刷ジョブ制御処理を行う。

印刷ジョブ制御システム用プリントマネージャ６２３（以降、本実施例ではジョブ制御プリントマネージャと略記）は、ユーザがジョブ制御プリントサービス６２２内部でプリントジョブがどのような状態にあるかを調べたり、プリントジョブを操作したりするためのユーザインタフェース（ＵＩ）を提供するプログラムである。

ジョブ制御プリントマネージャ６２３はジョブ制御プリントサービス６２２のソフトウェアのインタフェース（ＡＰＩ）を介して、ジョブ制御プリントサービス６２２と情報・指示をやり取りしている。

印刷ジョブ制御システム用サーバ６３０（以降、本実施例ではジョブ制御サーバと略記）は、個々のクライアント６００上のジョブ制御プリントサービス６２２がプリンタデバイス６５０にプリントジョブデータを送信するタイミングを集中制御（スケジューリング）している。

印刷ジョブ制御システム用マネージメントコンソール６３３（以降、本実施例ではジョブ制御マネージメントコンソールと略記）は、ジョブ制御サーバ６３０が持つソフトウェアがアクセスするためのＡＰＩを介してジョブ制御サーバ６３０と情報・指示をやり取りすることで、印刷ジョブ制御システム全体を監視することができる。

また、ジョブ制御サーバ６３０はデバイス情報コントロールモジュール６３１を用いて各プリンタデバイス６５０と通信を行い、各プリンタ内の印刷ジョブや動作状態に関する情報を入手したり、操作を行ったりする。入手した情報はクライアント６００側のジョブ制御プリントサービス６２２に渡すことができる。

次に本実施の形態におけるグループプリンタＤｒｉｖｅｒ６０３からの印刷について説明する。

グループプリンタＤｒｉｖｅｒ６０３はアプリケーションプログラムが生成した一連の描画コマンドを、プリンタデバイスの種類に依存しない中間フォーマットのファイルである汎用印刷ファイルに変換する。この汎用印刷ファイルの構成については後述する。

この汎用印刷ファイルは前述したようにＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒ６０４からジョブ制御ポートモニタ６２１を経て（ａ）、ジョブ制御プリントサービス６２２に導かれる（ｂ）。ジョブ制御プリントサービス６２２はこのプリントジョブに対して行うジョブ制御の種類に応じて、汎用印刷ファイルをもとに描画コマンドを生成し（ｃ）、続いてＰＤＬＤｒｉｖｅｒ６０２がその描画コマンドをプリンタデバイス６５０が解釈可能なＰＤＬファイルにする。図６Ａでは、ジョブ制御プリントサービス６２２で、このプリントジョブに対してプリントジョブをふたつに分けるジョブ制御が行われる例で、２つのメンバジョブが生成された例を２つの矢印（ｃ）で示している。ＰＤＬＤｒｉｖｅｒ６０２で生成されたＰＤＬファイルはＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒ６０４、ジョブ制御ポートモニタ６２１を経て（ｄ）、再びジョブ制御プリントサービス６２２に渡される（ｅ）。ジョブ制御プリントサービス６２２は、ジョブ制御サーバ６３０の指示に従ってＰＤＬのプリントジョブデータをプリンタデバイス６５０に送信する（ｆ）。

ジョブ制御プリントサービス６２２は、汎用印刷ファイル中の印刷指示書の指示にしたがって、一つの汎用印刷ファイルを複数のプリントジョブに論理的に分割してそれぞれ別のプリンタデバイスに送信したり、一度送信したプリントジョブデータを別のプリンタデバイスに送信し直したりする。図６Ａ中の（ｃ）（ｄ）（ｅ）（ｆ）はそのような場合のプリントジョブデータの経路を示している。

一方、汎用印刷ファイルをアプリケーションソフトウェアが作成し、そのアプリケーションソフトウェアが直接汎用印刷ファイルを印刷ジョブとして投入する場合、一般のアプリケーションとはグループプリンタＤｒｉｖｅｒ６０３への情報の渡し方や、グループプリンタＤｒｉｖｅｒ６０３での処理内容が異なる。前述のように、一般のアプリケーションの場合、アプリケーションはグループプリンタＤｒｉｖｅｒ６０３に描画情報を渡す際、通常のプリンタドライバと同じようにＷｉｎｄｏｗｓ（登録商標）のＧＤＩ関数を呼び出し、グループプリンタＤｒｉｖｅｒ６０３がそれに応じて汎用印刷ファイルを生成する。これに対して汎用印刷ファイルを直接作成するアプリケーションの場合は、アプリケーションが汎用印刷ファイルをすでに持ち、それをグループプリンタＤｒｉｖｅｒ６０３に供給する。グループプリンタＤｒｉｖｅｒ６０３は必要に応じてあらかじめ設定された印刷方法にもとづいて汎用印刷ファイル内部の印刷指示書を書き換えてＷｉｎｄｏｗｓ（登録商標）Ｓｐｏｏｌｅｒ６０４に送る。

図８は、汎用印刷ファイルの構成の一例を示した図である。

本実施の形態で使用される汎用印刷ファイルは、印刷指示部８−ａと、ドキュメントデータ部８−ｂからなる。印刷指示部は、ドキュメントの情報と印刷指示を記述した部分である。また、ドキュメントデータは、アプリケーションのドキュメントのデータを汎用的な形式のデータに変換したものであり、プリンタ言語に依存しないデータフォーマットとなっている。

印刷指示部はヘッダ部、ページ情報部、印刷体裁指示部、出力方法指定部、グループプリンタドライバ設定情報部、メンバプリンタ数、メンバプリンタドライバ名、メンバプリンタドライバ設定情報部などから構成されている。

ヘッダ部は本ファイルのバージョン識別やファイル情報などの情報を格納する部分である。

ページ情報部は、ドキュメントデータ部８−ｂのドキュメントデータのページ数、各ページのサイズなどの情報を格納する部分である。

印刷体裁指示部は、印刷ページ範囲、印刷部数、ドキュメントデータの面付け情報（Ｎ−ＵＰや製本印刷など）、ステイプル指示やパンチ指示など、出力体裁に関する情報を格納する部分である。

出力方法指定部は、出力方法として、分散印刷、カラー・モノクロ分散印刷、同報印刷、代行印刷、などの情報を格納する部分である。

グループプリンタドライバ設定情報部は、後述するグループプリンタドライバのＵＩの設定情報を格納する部分である。

メンバプリンタ数はグループプリンタドライバが関連付けているメンバプリンタの数を格納する部分である。

メンバプリンタドライバ名は、メンバプリンタのプリンタドライバ名を格納する部分である。

メンバプリンタドライバ設定情報部はメンバプリンタのドライバＵＩの設定情報として例えばＤＥＶＭＯＤＥ情報を格納する部分である。

このメンバプリンタドライバ名とメンバプリンタドライバ設定情報部は、前述のメンバプリンタ数に格納された数だけの格納エリアを持っている。

前述の図６Ａで説明したグループプリンタＤｒｉｖｅｒ６０３では、汎用印刷ファイルを生成する際、グループプリンタドライバＧＵＩ上の設定を印刷指示部８−ａへ記録する。さらに、グループプリンタＤｒｉｖｅｒ６０３はＧＤＩで受け取ったデータを汎用的なデータに変換しドキュメントデータとして、本汎用印刷ファイルのドキュメントデータ部に記録することとなる。

なお、本ファイルは、印刷指示部８−ａとドキュメントデータ部８−ｂが異なるファイルであってもかまわない。その場合、印刷指示部は印刷指示書ファイルとして、ドキュメントデータ部はドキュメントデータファイルとしてそれぞれ存在し、これらを一つのアーカイブ形式でまとめて同様に一つのファイルのように扱うこともが可能である。

次に図７でＷｉｎｄｏｗｓ（登録商標）が提供するＰｒｉｎｔＳｙｓｔｅｍと印刷ジョブ制御システムにおける印刷ジョブの関係と処理概要をさらに詳しく述べる。

図７中で印刷ジョブ制御システム７００は、サーバとクライアントの制御プログラムが動作する物理的なマシンをまたいだ、印刷ジョブ制御システムの範囲を示している。また、サーバが管理している出力ポート（Ｏｕｔｐｕｔ Ｐｏｒｔ）７１１は、クライアントのジョブ制御プリントサービス６２２のプロキシ出力ポート（Ｐｒｏｘｙ Ｏｕｔｐｕｔ Ｐｏｒｔ）７１２と関連付けられ、ひとつのポートに関連づけられた各クライアント上のプロキシ出力ポート全てを統一的に管理している。本実施例では、実際のプリントジョブデータはおのおののクライアントのプロキシ出力ポート７１２に保持される。ジョブ制御サーバ６３０は、プリントジョブデータ自体の送信処理は行わず、ジョブ制御プリントサービス６２２に対して印刷ジョブの送信指示のみを行う。その指示に応じてクライアントのジョブ制御プリントサービス６２２はプリントジョブデータをデバイス６５０に送信する。

次に、印刷ジョブ制御システム７００が、分散印刷、同報印刷、代行印刷、などの付加価値的な印刷を行う場合の処理を説明する。

印刷ジョブ制御システム７００が、分散印刷、同報印刷、代行印刷、などの付加価値的な印刷を行う場合には、前述のようにユーザまたはアプリケーション６０１はグループプリンタＤｒｉｖｅｒ６０３が割り当てられたプリンタに印刷ジョブを発行しなければならない。ジョブ制御プリントサービス６２２は、グループプリンタＤｒｉｖｅｒ６０３によって処理されたジョブデータをジョブ制御ポートモニタ６２１を介して汎用印刷ファイルとして受け取る。ジョブ制御プリントサービス６２２はこのジョブを受け取り、Ｄｅ−ｓｐｏｏｌｅｒ７０１を介してＰＤＬドライバが割り当てられた別のプリンタにジョブ（メンバジョブ）を発行して印刷を行わせる。この時、Ｄｅ−ｓｐｏｏｌｅｒ７０１は前述の図８で説明した汎用印刷ファイルの印刷指示部８−ａを解釈し、ドキュメントデータ部８−ｂのドキュメントデータを加工して、Ｗｉｎｄｏｗｓ（登録商標）のＧＤＩに変換し、各プリンタドライバに対して印刷指示を行い印刷ジョブを発行する。例えば印刷体裁指定部に、２−ＵＰの指示が記録されていた場合、用紙１枚に２ページ分のドキュメントデータを縮小レイアウトする。また分散印刷あるいは同報印刷の場合には、それらの設定に応じて印刷指示部８−ａに記述されている複数のメンバプリンタにジョブを発行する。代行印刷の場合は、代行する条件が満たされた時に、自動代行では事前の設定、手動代行ではユーザの操作に応じてメンバジョブを発行する。

また、Ｄｅ−ｓｐｏｏｌｅｒ７０１は各メンバプリンタにジョブを発行する際、メンバプリンタドライバに対応する印刷指示として、各メンバプリンタのＤＥＶＭＯＤＥを作成する必要があるが、このＤＥＶＭＯＤＥは印刷指示部８−ａに記載された内容を適宜各メンバプリンタのＤＥＶＭＯＤＥに反映させて生成する。

クライアント側のジョブ制御プリントサービス６２２は、ＰＤＬＤｒｉｖｅｒ６０２によってレンダリングされた、それぞれのメンバジョブのＰＤＬデータをジョブ制御ポートモニタ６２１を介して受け取り、受け取ったジョブに関する情報をサーバ側に知らせ、ジョブデータは自身のプロキシ出力キュー（Ｐｒｏｘｙ Ｏｕｔｐｕｔ Ｐｏｒｔ）７１２で一時保持する。その後、ジョブ制御サーバ６３０からの送信指示を受けた後にプリントデバイス６５０に送信する。

次に本実施の形態における、共通設定領域と、拡張設定領域といった記憶領域をもつプリンタドライバを持つプリンタを複数台使用して、前述の分散、同報、代行といった印刷処理を行う、印刷ジョブ制御システムのためのプリンタドライバのＵＩ制御について説明する。

図９は、本発明のグループプリンタドライバのＵＩ制御フローを示すフローチャートである。

アプリケーションからグループプリンタドライバへのＵＩ表示要求が来ると、処理はステップ９−１へ進む。ステップ９−２は、印刷ジョブ制御システムＡＰＩを使って、グループプリンタドライバを構成するメンバプリンタドライバの識別ＩＤ及び構成台数を問い合わせるステップであり、グループプリンタドライバを構成する全てのメンバプリンタドライバの識別ＩＤと構成台数を獲得する。

ステップ９−３は、グループプリンタドライバの構成するメンバプリンタドライバの登録台数が複数台（例２台）以上でかつ、メンバプリンタドライバの“構成確認フラグ”がＯＮであるか、判定するステップであり、判定結果がＹＥＳであればステップ９−４の構成確認処理へ進み、ＮＯであればステップ９−５へ進む。なお前記、“構成確認フラグ”は、初期状態ではＯＦＦであり、グループプリンタドライバＵＩ（ステップ９−６）上でＯＮ／ＯＦＦの切り替えを可能としている。ステップ９−４は、構成確認処理を行うステップである。

図１０は、その詳細である。なお、図１０記載の一連のフローにより読み出された各メンバプリンタドライバの構成情報は、図１０−４に示されるメンバプリンタドライバ構成情報テーブル上に格納される。ステップ１０−１は、ステップ９−２で得たメンバプリンタドライバ台数をカウンタ変数（以後ＣＯＵＮＴＥＲ）にセットするステップである。また、本ステップで、メンバプリンタドライバ構成情報テーブルの“構成判定Ｆｌａｇ”をＯＦＦに初期化する。ステップ１０−２は、前記ステップで設定したＣＯＵＮＴＥＲが０かどうか判断するステップであり、ゼロと判断された場合にはステップ９−５の処理へ移行し、それ以外であればステップ１０−３へ進む。ステップ１０−３は、ステップ９−２で得た各メンバプリンタドライバの識別ＩＤを使って当該メンバプリンタドライバが機能制御可能なドライバであるかどうか判断するステップであり、機能制御可能な場合には、ステップ１０−４進み、不可な場合には、メンバプリンタドライバ構成情報テーブル上に“ＮＯＮＥ”を設定しステップ１０−８へ進む（図１０−４ＣＯＵＮＴＥＲ列の“２”を参照）。ステップ１０−４は、メンバプリンタドライバのドライバ名（機種情報）の読み出しを行うステップであり、メンバプリンタドライバの識別ＩＤを使って当該メンバプリンタドライバ名を読み出す。また、ステップ１０−５は、デバイスオプションの読み出しを行うステップであり、当該メンバプリンタドライバに設定されている、パンチ機能モジュール（例Ｐｕｎｃｈｅｒ−Ａ）、製本機能モジュール（例Ｆｉｎｉｓｈｅｒ−１）などといったデバイスに装着されているオプション機能を読み出すステップである。なお、前記ステップ１０−４、１０−５で読み出した機能は、共にメンバプリンタドライバ構成情報テーブル上に格納される。ステップ１０−６は、同一構成プリンタドライバの判定を行うステップであり、前記ステップ１０−４、１０−５で読み出した情報とメンバプリンタドライバ構成情報テーブルに登録されている情報を元に同一構成プリンタドライバが、あるかどうか判定を行うステップである。ここで“ドライバ名”かつ“デバイスオプション”の構成が一致した場合、同一構成プリンタドライバと判断し、ステップ１０−７へ進み、同一構成でないと判断された場合には、メンバプリンタドライバ構成情報テーブルの構成グループに、該当なしとして“ＮＯＮＥ”を登録する。なお、同一プリンタドライバ名でもデバイスオプションが異なれば、同一構成プリンタドライバと見なさない。これは、デバイスオプションの装着状態によって、ドライバの機能が異なる事があるためである。ステップ１０−７は、同一構成プリンタドライバの登録を行うステップであり、前記ステップで同一構成プリンタドライバと判定されたものは、同一グループとして構成グループのＩＤを設定する。また、構成グループのＩＤが未決定な場合には、同一グループプリンタ内で唯一となるＩＤを決定し、メンバプリンタドライバ構成情報テーブルの構成グループに登録する。（図１０−４、ＣＯＵＮＴＥＲ“１”と“３”および“４”と“ｎ−１”、“５”と“ｎ−２”を参照）また、本ステップに入った場合、メンバプリンタドライバ構成情報テーブルの構成判定ＦｌａｇがＯＦＦとなっていた場合、ＦｌａｇをＯＮにする。

ステップ１０−８は、ステップ１０−１で設定したカウンタ変数を１減算するステップである。そしてステップ１０−２へ処理を戻し前述したようなフローにより次のメンバプリンタドライバに対して同一構成プリンタドライバの確認処理を行い、全てのメンバプリンタドライバに対して確認処理が終わるまでステップ１０−３〜１０−７までの処理を繰り返す。

以上のステップを経て、ステップ１０−２へ戻った際にカウンタ変数が０となった場合、同一構成プリンタドライバの確認処理が終わったものと判定し、ステップ９−５へ進む。ステップ９−５では、メンバプリンタドライバから機能を吸い上げコンフリクト処理を行うステップであり、図１１はその詳細である。ステップ１１−１は、ステップ９−２で得たメンバプリンタドライバ台数をＣＯＵＮＴＥＲにセットするステップである。また、このステップでは、ステップ１１−５で使用する“処理済み構成グループ登録テーブル”の初期化を行う。このテーブルは、各構成グループに対して、そのグループ内のメンバプリンタがステップ１１−５の処理へ進んだかどうか判断するためのもので、本ステップではこの情報を全てＯＦＦとして初期化する。ステップ１１−２は、前記ステップで設定したＣＯＵＮＴＥＲが０かどうか判断するステップであり、ゼロと判断された場合にはステップ９−６の処理へ移行し、それ以外であればステップ１１−３へ進む。ステップ１１−３は、メンバプリンタドライバが同一構成プリンタドライバかどうか判定するステップであり、メンバプリンタドライバ構成情報テーブルの構成判定ＦｌａｇがＯＮでかつ、ＣＯＵＮＴＥＲ番号に対応した当該プリンタドライバが、構成情報テーブに構成グループ“あり”（“ＮＯＮＥ”以外が設定されている）として登録されているかどうか判断するステップである。ここで、前記条件に該当すると判断された場合にはステップ１１−４へ進み、なしと判断された場合には、ステップ１１−５へ進む。ステップ１１−４は、コンフリクト処理対応済みドライバであるかどうか判断するステップであり、前記ステップで構成グループありと判断されたドライバが、既に処理済みの構成グループであるかどうか判断する。判断方法としては、ステップ１１−１で初期化された“処理済み構成グループ登録テーブル”に当該の構成グループが登録されているかどうか判断を行い、登録されていれば、コンフリクト処理は既に対応済みと判断しステップ１１―７へ進み、それ以外であれば、前記、登録テーブルに当該の構成グループを登録しステップ１１−５へ進む。

ステップ１１−５は、メンバプリンタドライバの能力を取得するステップであり、当該のメンバプリンタドライバの識別ＩＤを使ってドライバの能力を読み出すステップである。この際に、機能制御不可なメンバプリンタドライバからは共通設定項目のみの取得及び読み出しが行われ、機能制御可能なメンバプリンタドライバに対しては、共通設定項目及び拡張設定項目の取得及び読み出しが行われる。ステップ１１−６はステップ１１−５で取得した各メンバプリンタドライバの機能をグループプリンタドライバＵＩに反映させるためのコンフリクト処理が行われる。

図１２は、ステップ１１−６の詳細である。図１２のステップ１２−１では、前記、ステップ１１−５で取得したメンバプリンタドライバに対して機能の収得がドライバ設定情報の拡張領域の部分まで可能な、“機能制御可能なドライバ”か、または、それ以外の“機能制御不可能なドライバ”か、を判断するステップであり“機能制御可能なドライバ”の場合ステップ１２−３進みへ、それ以外の場合にはステップ１２−２へ進む。ここで、機能制御可能なドライバでは共通設定項目と拡張設定項目との機能が調査され、機能制御不可能なドライバでは共通設定項目のみが調査される。

図１０−２は、共通設定項目・拡張設定項目と各設定項目との対応を示す。なお、本発明では共通設定項目は、図１０−２に示されるような、共通設定領域に存在する項目、拡張設定項目は、拡張設定領域に存在する項目として分類し規定しているが、印刷ジョブ制御システムを運用するＯＳの違いによっては、設定項目の分類が異なる場合や設定可能項目に変更がある場合があるが、本発明のＵＩ制御フローが有効なのはいうまでもない。図１０−２について更に詳しく説明すると、共通設定項目に規定される各機能の項目は複数のメンバプリンタドライバのそれぞれの相違に係らず、印刷制御プログラムがＯＳを介して問い合わせることが可能な項目に相当する。一方、拡張設定項目に対応する各機能の項目は、共通設定項目のように印刷制御プログラムがＯＳを介して問い合わせることが必ずしも保証されているとは限らない。該拡張設定項目はそれぞれのプリンタドライバの提供元が独自に問合せの仕組みを規定しているようなものに相当する。グループプリンタドライバにしてみれば、拡張設定項目の問い合わせが利用できないようなプリンタドライバのことを“機能制御不可能なドライバ”と呼ぶこともある。

次に、機能のコンフリクト処理について具体的に説明すると、機能のコンフリクト処理とは、グループプリンタの対象となる各メンバプリンタドライバのそれぞれからドライバ識別情報や共通設定領域及び拡張設定領域に規定されている各機能の情報の取得や、メンバプリンタドライバから取得された各設定項目に対する機能の“あり”・“なし”をチェックし、対象となるメンバプリンタドライバ全てに機能がある場合にグループプリンタドライバＵＩでその機能を設定可能項目として扱い、また、１台でも、機能がないものがあればその項目については、設定不可能項目として扱うようにする。図１０−３の中のプリンタドライバＡは、グループプリンタドライバを表しプリンタドライバ、Ｂ，Ｃ，Ｄはグループプリンタドライバを構成するメンバプリンタドライバを表し、表中の、 “あり”、“なし”は各メンバプリンタドライバが製本印刷機能、ステイプル印刷機能、パンチ機能をサポートしているかどうかを示したものである。ここで製本印刷機能に着目すると、ドライバＡ、Ｂは製本印刷機能があるが、ドライバＣにはその機能がないため、グループプリンタドライバＡの製本印刷機能は“なし”となる。同様に、ステイプル機能は、Ｂ，Ｃ，Ｄ全てのメンバプリンタドライバに機能があるため、グループプリンタドライバＡのステイプルは、“あり”となり、パンチ機能は、Ｂ，Ｃ，Ｄ全てのメンバプリンタドライバに機能がないため、グループプリンタドライバＡのパンチ機能は、“なし”となる。図１０−３は、特に共通設定項目と拡張設定項目とを区別無く説明してきたが、実際には、メンバプリンタドライバの構成に機能制御不可なものが含まれる場合には、コンフリクト処理（機能の取得及び整合性計算）の対象となる設定項目を共通設定項目のみにし、機能制御可能なドライバのみからメンバプリンタが構成されている場合にはコンフリクト処理の対象となる設定項目を共通設定項目と拡張設定項目にするような処理が行われる。そのメンバプリンタ種別構成とコンフリクト処理の対象とする項目との関係を示す図を図１０−５に示す。また、メンバプリンタ種別構成とコンフリクト処理の対象とする項目との関係を図１０−６のようにしても良い。図１０−３においては、図１０−２中の拡張設定項目について論理和の計算を行っている様子を示しており、図１０−５のメンバプリンタの構成が「機能制御可能なドライバのみ」や、図１０−６の「１台でも機能制御可能なものを含む場合」に行われるコンフリクト処理を示すものとなっている。

図１１のフローに戻るとステップ１１−７は、ステップ１１−１で設定したカウンタ変数を１減算するステップである。そしてステップ１１−２へ処理を戻し前述したようなフローにより次のメンバプリンタドライバに対してコンフリクト処理を試みる全てのメンバプリンタドライバに対して処理が終わるまでステップ１１−３〜１１−６までのステップを繰り返す。以上のステップを経て、ステップ１１−２へ戻りカウンタ変数が０となった場合、処理が終わったものと判定し、ステップ９−６へ進む。ステップ９−６は、グループプリンタドライバＵＩを表示するステップである。このステップでは、前記フローに基づく複数のメンバプリンタドライバとのコンフリクト結果をもとに、機能のないものについてはグループプリンタドライバＵＩ上で設定が行えないように設定入力欄をグレーアウト表示或いは非表示するようにＵＩ制御を行い、機能がある項目については設定入力欄をアクティブにするようＵＩ制御を行う。また、このグループプリンタドライバＵＩの表示制御には、ユーザの指定により、例えば製本印刷が指定された時にパンチ設定やステイプル設定が指定可能となるような機能上ありえない組み合わせの設定ができないよう、設定項目の入力欄についてＵＩ制御が行われる。ＵＩ制御結果の例を、図１３−１、１３−２に示す。図１３−１は上述したコンフリクト処理の結果、設定項目をグレーアウト表示した例を示す。図１３−２は上述したコンフリクト処理の結果、設定項目を非表示した例を示す。

なお、ステップ９−４で前述した“構成確認フラグ”は、グループプリンタドライバＵＩ上でＯＮ／ＯＦＦの切り替えを可能とし、その設定は、グループプリンタＵＩを介して設定はクライアントＰＣのハードディスク（ＨＤ）などの不揮発性記憶エリアに保存され、次回グループプリンタドライバＵＩを表示する際に使用される。

以上のステップにより、グループプリンタドライバのＵＩ表示処理にかかるコンフリクト処理の最適化を実現した本実施の形態における印刷を行うことが可能となる。

本発明を適用可能な情報処理システムの構成を説明するブロック図 本発明の情報処理装置の構成を説明するブロック図 図２に示したＲＡＭ２０２のメモリマップの一例を示す図 図２に示したＦＤ２０４のメモリマップの一例を示す図 図２に示したＦＤドライブ２０３に対して挿入されるＦＤ２０４との関係を示す図 本発明の情報処理装置のプリント制御モジュール構成を説明するブロック図 プリントサーバで管理されるジョブ情報のデータ構造の一例を示す図。 汎用印刷ファイルの構造を示す図 グループメンバプリンタドライバＵＩ表示基本フロー 構成確認処理基本フロー メンバプリンタの構成によるコンフリクト項目例１を示す図 共通設定、拡張設定項目を示す図 グループメンバプリンタドライバＵＩ表示のための機能コンフリクト例を示す図 メンバプリンタドライバ構成情報テーブルを示す図 メンバプリンタの構成によるコンフリクト項目例２を示す図 メンバプリンタの構成によるコンフリクト項目例３を示す図 グループプリンタドライバ構成確認及びコンフリクトフロー グループプリンタドライバコンフリクト切り替えフロー ＵＩ制御例を示す図 ＵＩ制御例を示す図

符号の説明

１０１ サーバ
１０２ クライアント
１０３ クライアント
１０４ クライアント
１０５ ネットワークプリンタ
１０６ ネットワーク

Claims (9)

1. ネットワークに接続される複数のプリンタ、すなわちメンバプリンタを仮想的に１つのプリンタ、すなわちグループプリンタとして扱い、そのプリンタに対して、印刷ジョブの処理指定を仮想プリンタ用プリンタドライバ、すなわちグループプリンタドライバ上で設定する印刷ジョブ制御システムにおいて、印刷ジョブ制御システムＡＰＩを使って、グループプリンタを構成する全てのメンバプリンタドライバの識別ＩＤを獲得する手段と、メンバプリンタの構成台数を獲得する手段と、構成確認処理の適用について判断する手段と、前記判断において適用と判断した場合には構成確認処理を行う手段と、前記確認処理結果を保持する手段と、その結果をもとに、メンバプリンタに対してコンフリクト処理を適用する手段と、構成確認処理を適用しない場合のコンフリクト処理適用手段と、前記、コンフリクト結果を元にグループプリンタドライバＵＩを表示する手段を有することを特徴とするプリンティングシステム。
2. 請求項１に記載のプリンティングシステムおいて、グループプリンタドライバを構成するメンバプリンタドライバの構成台記載のプリンティングシステム数を獲得する手段は、印刷ジョブ制御システムＡＰＩより獲得した識別ＩＤをカウントすることで得ることを特徴とするプリンティングシステム。
3. 請求項１に記載のプリンティングシステムにおいて、構成確認処理の適用について判断する手段は、グループプリンタドライバを構成するメンバプリンタドライバ台数が複数台である場合、かつ、グループプリンタドライバＵＩを介して設定される、“構成確認フラグ”がＯＮの時のみ処理を適用することを特徴とするプリンティングシステム。
4. 請求項１に記載のプリンティングシステムにおいて、請求項３にある構成確認処理の適用について判断する手段は、機能制御可能なプリンタドライバに対してのみ適用することを特徴とするプリンティングシステム。
5. 請求項１に記載のプリンティングシステムにおいて、構成確認処理の適用を行う手段は、グループプリンタドライバを構成するメンバプリンタドライバに対して、プリンタドライバ名、及び、デバイスオプションが一致する場合を同一構成プリンタドライバとして判断することを特徴とするプリンティングシステム。
6. 請求項１に記載のプリンティングシステムにおいて、構成確認処理の適用を行う手段は、グループプリンタドライバを構成するメンバプリンタドライバに対して、プリンタドライバ名が一致しても、デバイスオプションが一致しない場合には、同一構成プリンタドライバとして見なさないことを特徴とするプリンティングシステム。
7. 請求項１に記載のプリンティングシステムにおいて、コンフリクト処理適用手段は、構成確認処理において同一構成プリンタドライバと判定されたものに対しては、同一構成プリンタドライバのグループの中の一台のみをコンフリクト対象プリンタドライバとして処理を行うことを特徴とするプリンティングシステム。
8. 請求項１に記載のプリンティングシステムにおいて、コンフリクト処理適用手段は、構成確認処理が適用されなかった場合には、全てのプリンタをコンフリクト対象プリンタドライバとして処理を行うことを特徴とするプリンティングシステム。
9. 請求項１に記載のプリンティングシステムにおいて、請求項３にあるグループプリンタドライバＵＩを介して設定される、“構成確認フラグ”は、グループプリンタドライバＵＩ上でＯＮ／ＯＦＦの切り替えを可能とし、その設定は、ＵＩを介してクライアントＰＣのハードディスクなどの不揮発性記憶エリアに保存され、次回グループプリンタドライバＵＩを表示する際に使用されることを特徴とするプリンティングシステム。