(57)【要約】      （修正有）【課題】プリンタドライバ／スプーラ／プリントプロセッサのための各構成を変更したＯＳを開示する。【解決手段】ＰＰＤにより規定されるプリンタの各機能のためにはＰＰＤを使用する。残りの各機能は、カスタムプリントプロセッサにて処理される各カスタムアクションとして分類される。カスタムプリントプロセッサは、ＯＳのデフォルトプリントプロセッサに代えてスプーラと結びつけられる。しかし、好ましくはカスタムプリントプロセッサは、従来のプリントプロセッサの機能は実行しない。代わりに、カスタムアクションを実行した後、カスタムプリントプロセッサの各サブルーティンは従来のプリント処理を実行するためにＯＳのデフォルトプリントプロセッサの各サブルーティンを呼び出す。ＯＳにより維持されているプリントプロセッサ等の各機能の複製の手間を回避でき、プリントプロセッサのベンダーでのカスタマイズされた機能の置換えの手間も回避できる。【選択図】  図４
2004157998.tif 000002
【特許請求の範囲】
【請求項１】
システムプリントプロセッサを有する、コンピュータのオペレーティングシステムを、第１タイププリンタのためにプリントジョブを処理するように設定する方法であって、
プリントスプーラを、上記第１タイププリンタのための各プリントジョブがカスタムプリントプロセッサに渡るように設定することと、
上記カスタムプリントプロセッサを、上記プリントスプーラからの各プリントジョブを受け入れ、上記プリントジョブを上記第１タイププリンタに応じてカスタマイズされた状態に処理し、デフォルトプリント処理のための上記システムプリントプロセッサにカスタマイズされた状態の上記プリントジョブを渡すように設定することと、を有する方法。
【請求項２】
上記第１タイププリンタのプリンタは、ページ記述言語の各プリントジョブを受け入れるものであり、
さらに、上記第１タイププリンタのためのプリンタ属性を、上記プリントスプーラにプリントデータを供給する、一般的なページ記述言語のプリンタドライバに対し供給することを有し、
上記カスタマイズされた状態の上記プリントジョブは、一般的なプリンタドライバのドライバ属性によってサポートされていない各プリンタ機能のための各カスタムプリントオプションを含む、請求項１の方法。
【請求項３】
各プリントオプションの少なくとも一つのために、上記カスタムプリントプロセッサを、上記プリントオプションがグラフィカルユーザインターフェースの選択可能な要素として表示されるように設定する、請求項２の方法。
【請求項４】
カスタムプリントプロセッサを、上記カスタマイズされた状態に上記プリントジョブが処理されるように設定することは、上記カスタムプリントプロセッサを、プリントジョブコマンド言語を備えるプリントジョブデータのセクションを修飾するように設定することである、請求項１の方法。
【請求項５】
カスタムプリントプロセッサを、上記カスタマイズされた状態に上記プリントジョブが処理されるように設定することは、上記カスタムプリントプロセッサを、プリンティングデータを備えるプリントジョブデータのセクションを修飾するように設定することである、請求項１の方法。
【請求項６】
カスタムプリントプロセッサを、上記カスタマイズされた状態に上記プリントジョブが処理されるように設定することは、上記カスタムプリントプロセッサを、スプーラの引数データが上記システムプリントプロセッサに渡される前に、上記スプーラの引数データを修飾するように設定することである、請求項１の方法。
【請求項７】
プリントプロセッサのデフォルト動的リンクライブラリ内における、プリントプロセッサの外部から参照されるデフォルトの一セットの各サブルーティンの呼び出し記法に一致させた、外部から参照される一セットの各カスタムサブルーティンと、
上記プリントプロセッサのデフォルト動的リンクライブラリをロードし、上記プリントプロセッサのデフォルトサブルーティンを各エントリポイントにて読み出す、初期化サブルーティンとを有し、
一セットの各カスタムサブルーティン内における、カスタムサブルーティン毎に、上記デフォルトプリントプロセッサの各サブルーティンのエントリポイントに対応する呼び出しを含み、
上記各カスタムサブルーティンの少なくとも一つは、さらに、上記デフォルトプリントプロセッサの各サブルーティンのエントリポイントを呼び出す前に、実行されるカスタムアクションを備え、
上記初期化サブルーティンは、一セットのプリントプロセッサの各サブルーティンの各エントリポイントを呼び出し処理に提供するものである、カスタムプリントプロセッサの動的リンクライブラリ。
【請求項８】
上記外部から参照される一セットの各カスタムサブルーティンは、上記デフォルトプリントプロセッサの各サブルーティンのエントリポイント毎に対する、カスタムサブルーティンの一つのエントリポイントを含む、請求項７のカスタムプリントプロセッサの動的リンクライブラリ。
【請求項９】
上記外部から参照される一セットの各カスタムサブルーティンは、上記デフォルトプリントプロセッサの各サブルーティンの各エントリポイントのサブセットに対する、サブルーティンの一つのエントリポイントを含み、
上記デフォルトプリントプロセッサの各サブルーティンの各エントリポイントは、上記初期化サブルーティンによって、呼び出し処理に供給され、
上記初期化サブルーティンは、対応するカスタムプリントプロセッサのサブルーティンのエントリポイントを有さない各エントリポイントのための、上記デフォルトプリントプロセッサのサブルーティンの各エントリポイントを含む、請求項７のカスタムプリントプロセッサの動的リンクライブラリ。
【請求項１０】
上記カスタムアクションは、ユーザインターフェースの表示アクションを含み、
上記ユーザインターフェースは、対応するプリンタドライバでは利用できない、一セットの各カスタムプリント機能から、カスタムプリント機能をユーザに選択させるようになっている、請求項７のカスタムプリントプロセッサの動的リンクライブラリ。
【請求項１１】
上記カスタムアクションは、さらに、ユーザにより選択された各カスタムプリント機能の基づき、プリントジョブコマンド言語の修飾、プリンティングデータの修飾、および、スプーラの引数データの修飾を備える各アクションのグループから選択される少なくとも一つのアクションを含む、請求項１０のカスタムプリントプロセッサの動的リンクライブラリ。
【請求項１２】
上記カスタムアクションは、さらに、プリントジョブコマンド言語の修飾、プリンティングデータの修飾、および、スプーラの引数データの修飾を備える各アクションのグループから選択される少なくとも一つのアクションを含む、請求項７のカスタムプリントプロセッサの動的リンクライブラリ。
【請求項１３】
コンピュータのオペレーティングシステムに、ポストスクリプトプリンタをインストールする方法であって、
ポストスクリプトプリンタの属性を、一般的なポストスクリプトプリンタドライバによりサポートされている各プリンタ機能を規定するようにインストールすること、
一般的なポストスクリプトプリンタドライバによりサポートされていない、各カスタムプリンタ機能を規定し、実行するカスタムプリントプロセッサをインストールすること、
上記オペレーティングシステムを、上記プリンタに対してスプールされる各プリントジョブのために、デフォルトプリントプロセッサに代えて、上記カスタムプリントプロセッサを呼び出すように設定すること、とを含み、
上記カスタムプリントプロセッサは、上記各カスタムプリンタ機能以外のプリント処理を実行するために上記デフォルトプリントプロセッサに対して動的にリンクされたものである、上記方法。
【請求項１４】
上記オペレーティングシステムを、上記カスタムプリントプロセッサを呼び出すように設定することは、上記プリンタに使用される上記プリントプロセッサが上記カスタムプリントプロセッサであることを示すためのインフォメーションファイルをセットすることを含む、請求項１３の方法。
【請求項１５】
上記オペレーティングシステムを、上記カスタムプリントプロセッサを呼び出すように設定することは、オペレーティングシステムのプロパティをセットすることを含む、請求項１３の方法。
【請求項１６】
上記オペレーティングシステムを、上記カスタムプリントプロセッサを呼び出すように設定することは、スプーラを上記カスタムプリントプロセッサに結びつけるために、スプーラ再配置テーブルのエントリを修飾することを含む、請求項１３の方法。
【請求項１７】
プロセッサにより執行されるとき、プリンタのためのページ記述言語によって生成されるプリントジョブデータを処理するために、カスタムプリントプロセッサを呼び出すことを含む方法を上記プロセッサに実行させる、各命令と各属性とを含む、コンピュータ読み取り可能な媒体を有する装置であって、
上記カスタムプリントプロセッサは、上記ページ記述言語のプリンタドライバを通して実行できない、少なくとも一つのカスタムプリント機能を可能にでき、
デフォルトプリント処理を実行するためにシステムプリントプロセッサを呼び出すものである、装置。
【請求項１８】
上記方法は、さらに、上記カスタムプリントプロセッサにより実行可能な各プリント機能以外の、上記プリンタに付随した各オプションおよび各機能のセットに基づき、上記ページ記述言語のプリンタドライバを動作させることを含む、請求項１７の装置。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、概してプリンティング（printing, 印刷）に関し、より詳しくはプリンタドライバ類(printer drivers)、スプーラ類(spoolers)、プリントプロセッサ類(print processors)、およびそれらに関する各プロセス（processes, 各処理過程）に関するものである。
【０００２】
（背景技術）
多くの、コンピュータのオペレーティングシステムでは、プリンティングタスク類は、幾つかの公知の各プロセスや各機能(functions)の間にて分担されている。図１は、マイクロソフトのウィンドウズ（登録商標）タイプのオペレーティングシステム（ＯＳ）環境内での代表的なポストスクリプト（登録商標）ドライバ２２のための、上記の各プロセス間の関係を示している。
【０００３】
プリンタドライバ２２は、各アプリケーション（または、より一般的には、他の各プロセス）からの、オペレーティングシステム規定の各プリンティング命令を受け入れ、上記各命令を、提供されたフォーマット、または、メタファイル（すなわち、上記ドライバは、遅延された背景表現のため、または、上記各プリンティング命令をジャーナル化（journal、実行記録を付記した記録）に変換される。提供された／ジャーナル化されたプリントデータは、他の情報（インフォメーション、例えば、プリンタジョブ言語の各コマンド）と結合されて、プリント（印刷）ジョブを形成する。
【０００４】
上記プリントジョブは、スプーラ２４にスプールされる（順次引き取られる）。スプーラ２４は、ドライバ２２からのプリントデータに対する待ちキュー行列（queue）を処理し執行するものである。それゆえ、スプーラ２４は、上記プリンタにおいて最初のジョブが待機の状態の間、上記ドライバにて複数の各プリントジョブを生成させることができる。上記スプーラは、直ちに、または遅らせて、上記プリントジョブをプリントプロセッサ２６に対してデスプールする（順次吐き出す）。
【０００５】
上記プリントプロセッサ２６は、上記オペレーティングシステムに応じて、相違する各機能を実行する。一般に、もし、上記プリントデータがジャーナル化（例えば、拡張されたメタファイル、Extended MetaFile or EMF）されたデータであると、プリントプロセッサ２６は、上記ジャーナル化されたデータをそのまま通過させて、上記プリンタドライバ２２に戻す。それ以外の提供されたデータの場合では、プリントプロセッサ２６は、上記プリントデータをポートマネージャ２８にデスプールする。上記ポートマネージャ２８は、実際に、上記プリンタとデータ通信を実行するものである。
【０００６】
プリンタドライバ類は、それらのドライバ類がオペレーティングシステムの各プリンティング命令を、上記ドライバ類がサポートしている特定のプリンタによって理解可能なページ記述言語（ＰＤＬ）、または、ラスタフォーマット（raster format）に変換する必要があるように、概して、プリンタに特定、オペレーティングシステムに特定なものである。上記プリンタドライバ類は、他の各プリンタ機能（ステープリング、ソーティングなど）を執行するために上記データを特定のプリンタジョブ言語（ＰＪＬ）にてカプセル化するものであってもよい。
【０００７】
ヒューレットパッカード製のＰＣＬ（プリンタ制御言語）およびアドビ製のＰＳ（ポストスクリプト）は、２つの普及している各フォーマットである。
【０００８】
ところが、相違する各プリンタは、それらの各フォーマットに対するサポートにおいて、互いに異なる各レベルのサポートをそれぞれ提供することがあり、および／または、それらの標準の各フォーマットにより直接的にはサポートされていない追加の各機能を提供している場合がある。
【０００９】
図１では、ポストスクリプトのドライバ２２は、モノリシックＰＳドライバとして記述されている。モノリシックＰＳドライバとして記述は、このドライバがサポートする上記プリンタ（または、共通の各機能を備えた各プリンタ群）に対して特定のＰＳ機能を執行するように記載されていることを意味する。モノリシックドライバは、必要に応じて、例えば、利用可能な各プリントオプションをユーザに制御させるための、プリンタに特定のメニューや、各アプリケーションから受領された各プリンティング命令を処理するための、マイクロソフトのＯＳデバイスドライバインターフェース（ＯＳＤＤＩ）や、ＰＳプリントデータを上記プリンタに特定なものに生成する生成系や、上記プリンタの特殊な各機能を発動するためのＰＪＬ生成系などを含んでもよい。
【００１０】
モノリシックドライバでは、初めから上記ドライバを設計および開発するために必要なコストは、一度だけでよいが、かなり高くなることがある。上記コストに匹敵する追加のコストとして、上記ドライバをテストし、デバッグした後、搭載するコストが挙げられる。その後、上記ドライバはメンテナンスされる必要がある。
【００１１】
従来の多くのプリンタドライバは、このように実施されている。ところが、異なる機能の各セットを備えた、新規な各オペレーティングシステムの通常の導入や各プリンタモデルの通常の導入や、より複雑な上記両者の通常の導入の場合、モノリシックドライバ類は、もはや費用効率が高いものとはいえない。オペレーティングシステムによりサポートされる上記両者のそれぞれは、上記の現状のドライバに追加の修飾が施される度に、それ自身のテストとデバッグの手続を必要とする。それゆえ、上記のようなアプローチを行うプリンタ製造者（プリンタメーカ）では、継続的な上記の各コストはかなり高くなる。
【００１２】
図２は、各開発コストの幾つかを節約できる、他のアプローチを示す。一般的なＰＳドライバ３４のためのソースコードは、ベンダー（vendor、例えば、アドビ製のポストスクリプト 3.0 ）から供給される。そして、プリンタ製造者は、サポートされている特定のプリンタに適切なように、上記ドライバのソースコードにカスタマイゼーション３６を加えて、ドライバ３２を生成する。
【００１３】
一般的なドライバベンダーは、概して、配布されている上記ドライバのコピ−毎にロイヤリティーを要求する。それゆえ、上記のアプローチは、幾ばくかのコストを前もって節約できるが、現状のドライバのためのソースコードを学び、上記ベンダーから更新され出荷されソースコードを上記ドライバに統合し、上記カスタマイゼーションを維持する必要がある。さらに、上記アプローチは、テスト、デバッグおよび搭載の各コストを低減したり、ヴァージョンアップや更新に関わる各コストを軽減したりできず、市販された全てのプリンタに決まった額のコストを追加することになる。
【００１４】
アップルとマイクロソフトの双方は、設定可能な各ＰＳプリンタドライバを、無料にて、それらの各オペレーティングシステムの一部としてそれぞれ供給している。上記各ＰＳプリンタドライバは、ＰＰＤ（PostScript Printer Definition、ポストスクリプトプリンタ属性（定義））の各ファイル（しかしながら、ＰＰＤの各ファイルの使用は、上記の各オペレーティングシステムの各ファミリーに限定されない）を読み出す。例として、マイクロソフトのドライバを取り上げると（図３参照）、プリンタ製造者は、ＰＰＤファイル４０内に、製造者のプリンタの各仕様を記述し、格納しておくことによって、上記のマイクロソフトＯＳベースのＰＳドライバ４２を使用できる。上記ベースのＰＳドライバ４２は、対応するプリンタのためのプリントジョブを提供するために呼び出されたとき、上記ＰＰＤファイルを読み出す。
【００１５】
上記ＰＰＤはテキストファイルであり、それぞれ、非コメントラインである、例えば、デフォルト（default、初期設定値の）フォントとしてのクーリエといった特性値（*feature:value）のフォーマット（プリンタのデフォルトフォントを設定する）や、"14 14 828 1178"などの画像可能領域（*ImageableArea）Ａ３／Ａ３（Ａ３用紙のためのプリント可能領域の設定）、６００ｄｐｉ等の初期値解像度（*DefaultResolution）（プリンタの解像度）を備えている。メニューにより駆動されるインターフェースから、ＰＰＤファイルを生成するために、種々なツールの各キットが利用可能となっている。
【００１６】
上記のようなＰＰＤのアプローチは、幾つかの利点を有している。上記アプローチは、プリンタドライバが一から記述されたり、維持されたりすることが要求されない。上記アプローチは、カスタマイゼーションが可能である。上記アプローチは、通常は、移植可能であり、ロイヤリティーが要求されない。また、上記アプローチにおいては、上記ＰＰＤが修飾される度に、上記ＰＰＤはテストされる必要があるが、上記ＰＰＤは、オペレーティングシステム毎にはテストされる必要が一般にない。
【００１７】
また、上記ＰＰＤアプローチは、幾つかの欠点を有している。予め属性の決められた各機能や各オプションのＰＰＤセットで、利用可能なものは豊富にあるにもかかわらず、このセットは、限定され、製造者が開発したいと想定される新たな各機能を含むことができない。上記製造者は、そのような各機能を上記ＰＰＤに追加できず、また、ソースコードが公開されていないので対応する、「フリー（使用料無料）」ドライバを修飾できない。それゆえ、ＰＰＤを有するＰＳドライバでは、製造者を、その競合者より優位にできる新たに見出された各機能を利用するように上記ドライバを設定する方法がない。
【００１８】
（本発明のサマリー）
本明細書では、もし、ＰＰＤドライバの利点を享受する方法があれば、さらに非ＰＰＤの各機能をプリンタ上に提供できれば、プリンタ製造者にとって望ましいであろうと認められる。本発明者が見出した一つの方法は、上記ＯＳのデフォルトプリントプロセッサを、カスタムプリントプロセッサに置き換えることである。上記カスタムプリントプロセッサは、上記デフォルトプリントプロセッサと同様に動作するだけではなく、上記プリントプロセッサに対する上記ドライバのオペラビリティー（操作性）の、移動する重要な部分において、ＰＰＤにより執行され得ない各カスタムプリンタ機能を執行する。
【００１９】
この方法は目的通り動作するが、幾つかの欠点を有している。上記デフォルトプリントプロセッサは、一般に、相違する各オペレーティングシステム間での移植性がなく、よって、サポートされるＯＳ毎にカスタムプリントプロセッサがそれぞれ要求される。
【００２０】
例えば、ウィンドウズＮＴのデフォルトプリントプロセッサは、ジョブ毎の単一ファイルとしてＥＭＦデータを読み出す一方、ウィンドウズ９８のデフォルトプリントプロセッサは、インデックスファイルとしてＥＭＦデータを読み出し、ページ毎のためにデータファイルを区分する。また、ウィンドウズ２０００のデフォルトプリントプロセッサは、種々なシートアッセンブリの各オプション等のような、各ウィンドウズＮＴ、９８には見出せない幾つかの各機能を含んでいる。
【００２１】
そして、もし、第三者の、置換されたカスタムプリントプロセッサが、ジョブアカウンティング（ジョブ課金）というような、幾つかの要求されたプリンティング機能を実行するように、既に、インストールされている場合に、ユーザは、上記プリントプロセッサの置換を望んでいないことがある。
【００２２】
それゆえ、モノリシックドライバでは存在する各困難さの幾つかは、上記カスタムプリントプロセッサのアプローチにおいては回避されるけれども、モノリシックのカスタムプリントプロセッサを用いた場合では同様な困難さの幾つかに置き換えられるだけである。      
【００２３】
置換されたカスタムプリントプロセッサは、上記システムプリントプロセッサに対して、インターフェースおよび機能性（functionality）の双方において一致していると想定される。この置換されたカスタムプリントプロセッサのアプローチに対して、本明細書にて記述される幾つかの実施の各形態は、現状のプリンタドライバおよび上記ＯＳに付随するデフォルトプリントプロセッサ（または、第三者の、他の置換されたカスタムプリントプロセッサ）が維持された状態を許容できる、「追加」のアプローチを示す。
【００２４】
すなわち、カスタムプリントプロセッサは、上記プリントスプーラと、上記デフォルトまたは「システム」のプリントプロセッサとの間のデータパス（data path）中に配置される。上記カスタムプリントプロセッサは、上記プリントスプーラに対しては、上記プリントプロセッサとして見える。実際、上記カスタムプリントプロセッサは、上記スプーラから、サブルーティンの呼び出し（call）の各引数（arguments）を、単に、受け入れ、それら各引数を、そのまま通過させて（pass through）、上記のデフォルトプリントプロセッサのサブルーティンの各呼び出しに引き渡す。
【００２５】
しかしながら、上記のそのまま通過させる機能に機能に加えて、上記カスタムプリントプロセッサは、上記各呼び出しを上記デフォルトプリントプロセッサに引き渡す前に、そのサブルーティンの各呼び出しの一つまたは二以上において、カスタムアクションを実行することができる。それゆえ、カスタマイズされた、上記の「カスタム」プリントプロセッサは、上記の各カスタム機能以外の機能については殆ど実行できないが、残りの機能の実行については、上記デフォルトプリントプロセッサが実行する。
【００２６】
それゆえ、このようなカスタムプリントプロセッサは、適正な簡素化と、複数の各オペレーティングシステム間での移植性とを維持できる。これは、上記カスタムプリントプロセッサは、プラットフォーム毎でのプリントプロセッサのサブルーティンの呼び出しのための上記引数の構造を、把握し、保持することのみが必要であることに起因している。
【００２７】
（本発明に係る実施の各形態の詳細な説明）
以下の実施の各形態は、マイクロソフトにおける、ウィンドウズの種々な各オペレーティングシステムの記法にて記述されている。上記の各形態は、代表例ではあるが、本発明を限定的に解釈するものではない。明確に対応するものとは示されていないマイクロソフトのウィンドウズの各オペレーティングシステムと同様に、他のベンダーの各オペレーティングシステムにおいても、示された本発明の技術的思想は適用される。
【００２８】
図４は、本発明の実施の第一形態に係る、通常のプリントデータのフロー（流れ）を示す。ＰＳドライバは、上記ＯＳ内蔵のベースＰＳドライバ５０とＰＰＤ５２とを用いて構成されている。ＰＰＤ５２は、ＰＰＤにより明記できる、どのような各機能や各オプションでも含むことが好ましい（後述するように、ＰＰＤにより仕様が定められているが、特定のプリンタでは認識できない各機能をＰＰＤ５２は含んでもよい。上記各機能は、カスタムプリントプロセッサへの各命令として上記命令をエミュレートするために役立つ。このようにＰＳドライバが構成されると、このＰＳドライバは、対応するプリンタに対する、プリントするためのアプリケーションまたは各プロセス２０が要求されたときはいつでも呼び出される。
【００２９】
一旦、フォーマットが付与された、またはジャーナル化されたプリントデータは、ベースＰＳドライバ５０により、従来と同様に、スプーラ２４にスプールされる。例えば、後述する各方法の一つによって、上記スプーラは、プリントジョブデータを、そのまま、カスタムプリントプロセッサ６０に通過させるように設定されている。カスタムプリントプロセッサ６０は、てきせつな、どのようなカスタムアクションでも実行し、その後、上記プリントジョブデータをそのままシステムプリントプロセッサ７０に引き渡す。システムプリントプロセッサ７０は、あたかも、スプーラ２４から直接的に呼び出されたかのように、従来と同様に、処理を続行する。
【００３０】
上記の図示の補佐として、カスタムプリントプロセッサ６０の不在の状態で、スプーラ２４とシステムプリントプロセッサ７０との間でのインターアクション（対話）について吟味することは有益である。マイクロソフトのＯＳでは、デフォルトプリントプロセッサの各サブルーティンは、ウィンプリント・ディーエルエル（winprint.dll.）と名付けられた動的リンクライブラリ（Dynamic-Link-Library、ＤＬＬ）内に設置されている。当業者によって認識されるように、ＤＬＬは、動的リンクを用いて、コンパイル時に代えて、動作時（runtime）に、呼び出しプログラムにリンクされ得る、バイナリーの各命令を含む。
【００３１】
上記のデフォルトプリントプロセッサのＤＬＬは、幾つかの外部にて参照される各サブルーティンを含む。上記各サブルーティンは、通常、上記スプーラにより呼び出し可能であり、＜エントリ＞プリントプロセッサ（スプーラ：引数）（＜Entry＞PrintProcessor(spooler:args)）の形態をとっている。上記エントリは、[Enum, Open, Close, Control, PrintDocumentOn]のグループから選択される。「スプーラ：引数」は、特定の呼び出しに伴う、上記スプーラから期待される引数を表している。図５は、ウィンプリント・ディーエルエル（winprint.dll.）の各内容を概念的に示し（もちろん、実際のファイルはバイナリーファイル）、それら各サブルーティンのそれぞれと、それらに対応するエントリポイントとの関係を示している。
【００３２】
それら外部にて参照される各サブルーティンに加えて、上記デフォルトプリントプロセッサのＤＬＬは、エクスポートされる（exported）機能を有するサブルーティンである「初期化するプリントプロセッサ（）（InitializePrintProcessor()）を含む。オペレーティングシステムの再起動後、ウィンプリント・ディーエルエル（winprint.dll.）に対応するプリンタドライバが発動された、最初のときに、ウィンプリント・ディーエルエル（winprint.dll.）は、上記スプーラ内に動的に（dynamically）ロードされる。ウィンプリント・ディーエルエル（winprint.dll.）をロードした後、上記スプーラは、上記ＯＳが有する機能（サブルーティン）であるGetProcAddress()を用いて、InitializePrintProcessor()のアドレスを見つけ出す。上記スプーラは、InitializePrintProcessor()を呼び出す。InitializePrintProcessor()は、上記プリントプロセッサ（上述した＜Entry＞PrintProcessor()の各機能）内での、外部に参照されるが、エクスポートされない残りの各機能のアドレスを含むデータ構造にリターン（復帰）するためのものである。その後、上記スプーラは、必要とされるときに＜Entry＞PrintProcessor()の各機能を呼び出すことができる。
【００３３】
本実施の形態では、カスタムプリントプロセッサのＤＬＬは、ウィンプリント・ディーエルエル（winprint.dll.）に代えて、上記スプーラに対して動的にリンクされる。図６に示されるように、上記カスタムプリントプロセッサのＤＬＬは、外部に参照されるサブルーティンの各エントリポイントである、カスタマイズされた、custom:＜Entry＞PrintProcessor()と、エクスポートされる機能を有するInitializePrintProcessor()とを含む。上記のカスタマイズされた、custom:＜Entry＞PrintProcessor()は、ウィンプリント・ディーエルエル（winprint.dll.）の各エントリポイントに対する、タイプと各引数に対応している。
【００３４】
上記カスタムプリントプロセッサのＤＬＬが最初にロードされるとき、ウィンプリント・ディーエルエル（winprint.dll.）もロードされる。カスタムカスタム機能のInitializePrintProcessor()が上記スプーラにより呼び出されるとき、次に、上記スプーラは、ウィンプリント・ディーエルエル（winprint.dll.）の機能のInitializePrintProcessor()を呼び出し、ウィンプリント・ディーエルエル（winprint.dll.）の各機能の＜Entry＞PrintProcessor()のための各アドレスを見つけ出す。その後、上記カスタムプリントプロセッサは、上記スプーラに対し、custom:＜Entry＞PrintProcessor()の各機能の各アドレスを示しているデータ構造をリターンする。
【００３５】
戻って図６には、上記プリントプロセッサの各エントリポイントの一つへの呼び出しが図示されている。上記スプーラは、上記InitializePrintProcessor()の呼び出しの間にリターンされた、対応するアドレスを用いて、サブルーティンの呼び出しを、custom:＜Entry＞PrintProcessor(args)に対して実行する。引数（args）の記法は、呼び出されたサブルーティンに依存する。
【００３６】
上記カスタムプリントプロセッサの機能である、custom:＜Entry＞PrintProcessor(spooler:args)は、適切であれば、どのようなカスタム機能（それらに関する幾つかの実施の各形態は後述される）でも実行できる。しかしながら、上記の各カスタム機能は、一結果として、上記スプーラから受領された各引数を修飾するものであってもよい。
【００３７】
上記の各カスタム機能を取り込んだ後、上記サブルーティンであるcustom:＜Entry＞PrintProcessor()は、それに対応する、デフォルトプリントプロセッサの機能である、＜Entry＞PrintProcessor([modified]spooler:args)をwinprint.dll.から呼び出す共に、上記スプーラにより引き込まれた各引数（修飾されても可）も呼び出す。
【００３８】
上記デフォルトプリントプロセッサの機能は、上記オペレーティングシステムにおいて上記プリントプロセッサが実行する、従来のどのようなアクションでも実行し、それら結果を上記カスタムプリントプロセッサにリターンするものである。上記カスタムプリントプロセッサは、それらデフォルト結果を上記スプーラにリターンする。もし、上記カスタムプリントプロセッサの各アクションの結果が要求すれば、上記の各デフォルト結果は、適切となるように、上記の各カスタム結果と合わされたり、結合されたりしてもよい。
【００３９】
本実施の形態によれば、上記カスタムプリントプロセッサ内に組み込まれた機能性が、上記の各カスタム機能のみを殆ど実行することに集中していて、比較的小さくできることは高く評価される。プリントプロセッサに期待されている通常の作業を実行することを上記デフォルトプリントプロセッサに任せることにより、上記カスタムプリントプロセッサは、プラットフォーム毎の大きな重要性を備えた特異性（idiosyncrasies）と共に、上記機能性を複製する必要がない（当然のことながら、それら特異性が上記の各カスタム機能に関係していると見なされない限り）。上記のように必要がない場合、テストやデバッグの手続は比較的簡素なものとなり、整備や維持の各コストが軽減される。
【００４０】
上記カスタムプリントプロセッサにて実行されてもよい各カスタムアクションは、幾つかの相違する広い各カテゴリ−にわたっている。与えられたプリントジョブのために、該当しない、一つ、幾つか、または、全ての上記各カテゴリ−の各アクションが実行されてもよい。
【００４１】
各カスタムアクションの第１のカテゴリ−は、非ＰＰＤにおける、機能やオプションをユーザが作動させる各アクションのセットを含む。例えば、プリントジョブが上記カスタムプリントプロセッサ（例えば、custom:PrintDocumentOnPrintProcessor()のサブルーティンにおいて）に吐き出された（despool）後、ユーザインターフェースは、ユーザにカスタム機能を選択させるように表示させることができる。
【００４２】
代表的な各機能としては、プールプリンティング（pool-printing）機能、ジョブスプリッティング機能、シートアッセンブリ機能、ドキュメントフィニッシング機能などを含んでもよい。
【００４３】
上記プールプリンティング機能とは、ユーザが、上記プリントプロセッサにより、各プリンタのグループから、例えば、利用可能性および／または最も合う能力に基づいて一つのプリンタを選択するために選択されるものである。
【００４４】
上記ジョブスプリッティング機能とは、プリントジョブを幾つかの各サブジョブに分割し、それらを相違する各プリンタに配分することである。上記シートアッセンブリ機能、ドキュメントフィニッシング機能は、ＰＰＤにおいて利用できないものである。また、上記カスタムアクションには、特定のプリンタまたは特定の複数の各プリンタに上記プリントジョブを指示するクラスタプリンティング機能といった機能を、ポップアップ表示する機能を含むものであってもよい。
【００４５】
各カスタムアクションの第２および第３の各カテゴリ−は、上記プリントデータの文字列（ストリーム）を、例えば、追加したり、削除したりするように修飾するものである。プリントジョブ言語の各コマンドを修飾するのは第２のカテゴリ−である。ポストスクリプトの各命令（directives）を追加または修飾により提供されたデータを修飾することは、第３のカテゴリ−である。マイクロソフトのＯＳでは、上記プリントデータのストリームは、上記プリントプロセッサのアプリケーションバイナリーインターフェース（ＡＢＩ）の一部ではなく、上記プリントジョブに関係するスプーラのデータファイル内に配置されている。それゆえ、第２および第３の各カテゴリ−の各カスタムアクションは、上記カスタムプリントプロセッサが、上記デフォルトプリントプロセッサの前にて、上記プリントジョブのスプールデータを見つけ出し、修飾することを要求する。
【００４６】
PrintDocumentOnPrintProcessor()の機能が呼び出される。上記スプールファイルを、上記ドキュメントデータの引数の一部としてのOpenPrintProcessor()の呼び出しによる、上記スプーラから上記カスタムプリントプロセッサにそのまま引き渡された上記プリントジョブＩＤ（"jobID"）を用いて配置する。ジョブＩＤを用いて、上記カスタムプリントプロセッサは、上記スプールファイルを見出すことができる。上記ジョブＩＤは、例えば、各ウィンドウズ 95/98/Meでは、C:\windows\system\spool\<jobID>.splであり、各ウィンドウズNT/2000においては、C:\windows\system32\spool\printers\<jobID>.splである。
【００４７】
上記ファイルは、一度配置されると、上記カスタムプリントプロセッサは、上記スプールデータファイルを、その位置にて、読み取り修飾し書き込むために開けることができ、また、上記スプールデータファイルを、読み出してコピ−し、そのコピーを修飾した後、上記スプールデータファイルを、新たなスプールデータファイルに置き換えるために開けてもよい。例えば、ＰＪＬコマンドを、上記スプールファイル内に、上記ＰＰＤでは規定され得ない結合（binding）オプションを動作させるように挿入してもよい。
【００４８】
上記ＰＰＤにおいては利用できないシートアッセンブリオプションを上記ポストスクリプトデータ内に規定できる。ジョブを２つの各プリンタ間にて分割（スプリット）される場合、上記スプールファイルは、コピ−され、一つコピーをそれぞれのプリンタに送るようにしてもよい。それぞれのコピ−では、各コピ−の数のコマンドを、必要に応じて、複写機により実際にプリントされる各コピ−の数を反映するように修飾し配置してもよい。
【００４９】
各カスタムアクションの最後のカテゴリ−は、各引数が上記デフォルトプリントプロセッサに引き渡される前に、上記スプーラから受領された各引数を修飾する各アクションを含む。例えば、上記カスタムアクションが上記プリントジョブを相違するプリンタに対して再指示するとき、上記スプーラの各引数は、上記デフォルトプリントプロセッサにて上記再指示を余儀なくさせるように修飾させることができる。
【００５０】
上述したカスタム機能を完全に実行するために、二または二を超える各カテゴリ−内の各カスタムアクションを必要とする場合もある。また、プリントデバイスそれ自身がサポートしていないＰＰＤ特有の機能をエミュレート（模倣）するように、カスタムアクションを上記ＰＰＤと協動させることも可能である。
【００５１】
例えば、上述したシートアッセンブリオプションは、上記プリントデバイスにおいて上記オプションが直接的にはサポートされていないときでさえ、上記ＰＰＤ内にてサポートされているように示されることができる。
【００５２】
ユーザが上記オプションを選択したとき、上記カスタムプリントプロセッサは、上記選択の指示を検出し、上記スプールファイルから上記指示を削除し、上記オプションに合った上記データを上記スプールファイル内にて再構成する。
【００５３】
これまで述べてきた、実施の各形態は、幾つかのカスタムアクション（または、後の各カスタムアクションのために必要とされる何らかの設定）は、スプーラからプリントプロセッサへのそれぞれの呼び出しからの結果として得られるものでもよい。
【００５４】
上述したプリントプロセッサの機能のために、上記カスタムプリントプロセッサは、呼び出しにおいて、各引数を上記デフォルトプリントプロセッサへ引き渡し、上記デフォルトプリントプロセッサの結果を呼び出しにより上記スプーラにリターンするだけのものでもよいことが想定される。そのようなケースでは、上記カスタムプリントプロセッサの特定の機能は、必要に応じて、上記ライブラリから削除されてもよい。
【００５５】
ControlPrintProcessor()の機能のための図７に示されるように、上記カスタムInitializePrintProcessor()の機能は、データ構造内にて、上記デフォルトプリントプロセッサのControlPrintProcessor()の機能のアドレスを単にリターンするものでもよい。上記スプーラが、次に、ControlPrintProcessor()を呼び出すとき、上記カスタムプリントプロセッサは、上記呼び出しのためにバイパス（迂回）される。
【００５６】
上記の実施の各形態によれば、コンピュータのオペレーティングシステム上にポストスクリプトプリンタをインストールするための新規な幾つかの方法についても検討されている。上記のベースＰＳドライバによりサポート可能な上記各方法の各プリンタ機能を規定するＰＰＤがインストールされる。上記各カスタムアクションを含む上記カスタムプリントプロセッサが、適切なディレクトリ（例えば、各ウィンドウズ 95/98/Meでは、C:\windows\systemであり、各ウィンドウズNT/2000においては、C:\windows\system32\spool\prtprocs\w32x86）にインストールされる。その後、上記オペレーティングシステムは、上記デフォルトプリントプロセッサに代えて、上記カスタムプリントプロセッサを呼び出すように設定される。
【００５７】
このステップは、幾つかの方法にて完了させることができる。
【００５８】
第一に、上記ＰＰＤに対応する上記インフォメーション（.inf）ファイルを直接的に修飾することができる。この修飾は、上記プリントプロセッサ領域を、上記カスタムプリントプロセッサを含む上記ライブラリを指定するように設定することを含む。
【００５９】
第二に、幾つかの各オペレーティングシステムにおいては、プリンタドライバのシステムの各プロパティ内にプリントプロセッサのセッティング（setting）がある（各プロパティ−＞アドバンスド−＞各ウィンドウズNT/2000/XP上のプリントプロセッサに配置される）。このセッティングは、上記カスタムプリントプロセッサを含む上記ライブラリにセットされてもよい。
【００６０】
第三に、動作時（at run time）、本方法が上記デフォルトプリントプロセッサに代えて上記カスタムプリントプロセッサを動的にロードするように方法にて、上記スプーラの実行可能なファイルのコピ−は、直接的に修飾されてもよい。このロードは、上記winprint.dll.のInitializePrintProcessor()機能のための再配置エントリの配置（locating）（バイナリーファイルに配置されるが、アスキー(ASCII)の各文字列の表内に載置される）と、上記カスタムプリントプロセッサのＤＬＬにて、代わりに上記初期化（Initialize）機能に上記ファイルを結合するように修飾することとを含む。
【００６１】
上記オペレーティングシステムに応じて、他の各方法も利用可能であるが、本明細書では詳細には説明しない。
【００６２】
当業者であれば、上記のバイナリーのカスタムプリントプロセッサのライブラリの各機能およびＰＰＤの各規定を保持できる種々な各媒体について認識できるであろう。上記各媒体としては、特に限定されないが、光学ディスク、磁気ディスク、スタティックやダイナミックの固体メモリデバイスが挙げられる。上記各ディスクや各デバイスは、ローカルでも、ネットワーク化されたものでもよく、また、据え付け、または着脱可能なものであってもよい。上記各機能や各規定は、インストールされた状態で配布されてもよく、動作時に、上記各媒体の種々な位置に存在していればよい。
【００６３】
上記の実施の各形態では、ポストスクリプトは、代表的なＰＤＬとして使用されているが、上述した追加のカスタムプリントプロセッサは、他のＰＤＬ、または全く異なるフォーマット等の他の表現のフォーマットに対しても同様に適用可能である。通常、プリンタ製造者は、プリンタが望む上記フォーマットを識別することにより、上記フォーマットにてプリントデータが読み取られ、修飾されるように上記の追加のカスタムプリントプロセッサを記述することが可能となる。上記プリンタドライバは、ＰＰＤドライバである必要はなく、プリンタ製造者により供給されるドライバであればよい。
【００６４】
当業者であれば、本発明にて教示される技術的思想を、多くの他の適切な方法にて、特定のアプリケーションに合うように変更することは理解されるであろう。特に、図示された本実施の各形態が本明細書の開示を読めば明白となる他の多くの実現方法の一部であることは当業者にとって認識されるであろう。「デフォルト」や「システム」のプリントプロセッサは、通常、上記ＯＳと共に供給されるプリントプロセッサであるが、デフォルトやシステムのプリントプロセッサは、カスタムプリントプロセッサにより置き換えられたものでもよい。プリントジョブデータや、各引数の修飾は、その場所での変更、追加または削除や、置き換えられたデータや各引数の置き換えを含むことができる。
【００６５】
本明細書では、「サブルーティン」、「機能」および「エントリポイント」の各語句の間には意味の上での区別はない。上記の実施の各形態は、上記カスタムプリントプロセッサを単一のＤＤＬとして実現しているが、上記カスタムプリントプロセッサの機能性は、複数のＤＬＬのそれぞれ分散させてもよく、および／または、幾つかの各オペレーティングシステムにおいて、上記カスタムプリントプロセッサは、別々の実行可能なプログラムであってもよい。
【００６６】
上記カスタムプリントプロセッサは、提供されたタイプのプリンタに合うように記述されるが、上記プリンタは、所定の場合には、各プリンタ群（クラスタ）であってもよい。各プリンタ群では、それら全てが同じプリンタでなくともよく、また、それら全てが上記カスタムプリントプロセッサにより管理されるものである必要はない。
【００６７】
上記のようなマイナーな修飾は、本発明の範囲内に包含され、本願の各請求項に記載の各発明の権利内となるように意図されるものである。
【００６８】
上述した実施の各形態は代表例である。本明細書は、本実施の形態を幾つかの箇所にて参照しているが、その参照は、その示した実施の形態のみを必ずしも示すものでは無く、また、その特徴が単一の実施に形態のみに適用されることを必ずしも意味するものでは無い。
【００６９】
本発明は、以下の各図面を参照しながら、本開示を読むことにより最もよく理解されるであろう。
【図面の簡単な説明】
【００７０】
【図１】従来技術の、モノリシックＰＳドライバのためのウィンドウズＯＳでのプリント環境を示すブロック図である。
【図２】従来技術の、カスタマイズされた一般のＰＳドライバのためのウィンドウズＯＳでのプリント環境を示すブロック図である。
【図３】従来技術の、ＰＰＤを備えたＰＳドライバのためのウィンドウズＯＳでのプリント環境を示すブロック図である。
【図４】本発明の実施の形態に係る、ＰＰＤを備えたＰＳドライバと、スプーラとシステムプリントプロセッサとの間に挿入されたカスタムプリントプロセッサとを用いる、ウィンドウズＯＳでのプリント環境を示すブロック図である。
【図５】従来技術の、スプーラと、システムプリントプロセッサの動的リンクライブラリとの間の関係を示す図である。
【図６】本発明の実施の形態を示すものであり、スプーラと、カスタムプリントプロセッサと、システムプリントプロセッサとの間の関係を示す図である。
【図７】本発明の実施の他の形態を示すものであり、スプーラと、カスタムプリントプロセッサと、システムプリントプロセッサとの間の関係を示す図である。
【図１】
2004157998.tif 000003
【図２】
2004157998.tif 000004
【図３】
2004157998.tif 000005
【図４】
2004157998.tif 000006
【図５】
2004157998.tif 000007
【図６】
2004157998.tif 000008
【図７】
2004157998.tif 000009
【外国語明細書】
１    Title of Invention
PRINTER DRIVER CUSTOMIZATION USING INCREMENTAL CUSTOM PRINT PROCESSOR
２    Detailed Description of Invention
FIELD OF THE INVENTION
The present invention relates generally to printing, and more particularly to printer drivers, spoolers, print processors, and related processes.
BACKGROUND OF THE INVENTION
In many computer operating systems, printing tasks are divided between several well-known processes or functions.  Figure 1 shows the relationship between these processes for an exemplary PostScript driver 22 in a Microsoft Windows-type operating system (OS) environment.  A printer driver 22 accepts operating-system-specific printing instructions, from applications (or, more generally, other processes) 20, and converts these instructions to a rendered format or to a metafile (i.e., the driver journals the printing instructions for delayed background rendering).  Rendered/journaled print data is combined with other information (e.g., printer job language commands) to form a print job.  The print job is spooled to a spooler 24, which implements a queue for the print data from driver 22, and therefore allows the driver to generate multiple print jobs while a first job is pending on the printer.  Either immediately or delayed, the spooler despools the print job to a print processor 26.  Print processor 26 performs different functions depending on the operating system.  Generally, if the print data is journaled (e.g., Extended MetaFile or EMF) data, print processor 26 passes the journaled data back through the printer driver 22.  Otherwise, in the case of rendered print data, print processor 26 despools the print data to a port manager 28 that actually performs data communication with the printer.
Printer drivers are generally printer specific and operating-system specific, as these drivers must convert the operating system printing instructions to a Page Description Language (PDL) or raster format understandable by the particular printer they are supporting, and may encapsulate that data in a specific Printer Job Language (PJL) to implement other printer functions (e.g., stapling, sorting).  Hewlett Packard PCL (Printer Control Language) and Adobe PS (PostScript) are two prevalent formats for printer communications, although different printers may provide different levels of support for these formats, and/or additional features not directly supported by these standard formats.
In Figure 1, PostScript driver 22 is described as a monolithic PS driver, meaning that this driver is written to implement PS functionality specifically for the printer (or group of printers with common features) that this driver supports.  A monolithic driver would include, e.g., a printer-specific menu to allow a user to control the available print options, a Microsoft OS Device Driver Interface (OSDDI) to process printing instructions received from applications, a renderer to generate PS print data specific to the printer, and a PJL generator to actuate the printer's special features.
A monolithic driver requires a one-time cost to design and develop the driver from scratcha cost that may be significant.  Rivaling this cost is the additional cost to test and debug the driver, and then package it.  The driver must then be maintained.  Although historically many printer drivers were implemented this way, monolithic drivers are generally no longer cost effective given the regular introduction of new operating systems and printer models with different feature sets, and the complexity of both.  Each supported operating system requires its own test and debug procedure, each time an incremental modification is made to the existing driver.  Thus the ongoing costs to a printer manufacturer from such an approach are significant.
Figure 2 shows an alternate approach that saves some development costs.  Source code for a generic PS driver 34 is purchased from a vendor (e.g., Adobe PostScript 3.0).  The printer manufacturer then adds customizations 36 to the driver source code that are appropriate for the specific printer to be supported, to create a driver 32.  The generic driver vendor generally charges a royalty for each copy of the driver distributed.  Thus although this approach saves some money upfront, it requires that one learn the source code for the existing driver, integrate patches and updates from the vendor into the driver, and maintain the customizations.  Further, this approach does not decrease test, debug, and packaging costs or alleviate costs associated with revisions and updates, and adds an additional fixed cost to every printer sold.
Both Apple and Microsoft supply configurable PS printer drivers free of charge, as part of their operating systems, which read PPD (PostScript Printer Definition) files (use of PPD files is not limited to these operating system families, however).  Taking the Microsoft driver as an example (see Figure 3), a printer manufacturer can use the Microsoft OS base PS driver 42 by describing and storing the specifics of the manufacturer's printer in PPD file 40.  The base PS driver 42 reads the PPD file when it is called upon to render a print job for the corresponding printer.
The PPD is a text file, with each non-comment line having a *feature:value format such as: *DefaultFont: Courier (setting the printer's default font); *ImageableArea A3/A3: "14 14 828 1178" (setting the printable area for A3 paper); *DefaultResolution: 600dpi (printer resolution).  Various toolkits are available to generate a PPD file from a menu-driven interface.
The PPD approach has some appealit does not require that a printer driver be written from scratch or maintained, it allows for customization, it is generally portable, and does not require royalties.  Also, although each time the PPD is changed it must be tested, in general it need not be tested for each operating system. 
The PPD approach also has a few drawbacks.  Although a rich set of PPD predefined features and options are available, this set is nevertheless limited and would not include new features that a manufacturer might develop.  The manufacturer cannot add such features to the PPD, and cannot modify the corresponding "free" driver since no source code is supplied.  Thus with a PPD PS driver there is no way to configure the driver to take advantage of newly discovered features that might set a manufacturer apart from the competition.
SUMMARY OF THE INVENTION
It is recognized herein that it would be desirable to a printer manufacturer if there were a way to enjoy the advantages of a PPD driver, and yet still be able to offer non-PPD features on a printer.  One method that the present inventor has considered is replacing the OS default print processor with a custom print processor that acts like the default print processor, but also implements custom printer features that cannot be implemented by PPDin essence moving part of the operability of the driver to the print processor.  Although this can work, it has several drawbacks.  The default print processor is not generally portable between different operating systems, and thus a custom print processor is required for each supported OS.  For example, the Windows NT default print processor reads EMF data as a single file per job, whereas the Windows 98 default print processor reads EMF data as an index file and separate data file for each page.  Also, the Windows 2000 default print processor includes some features not found in Windows NT and 98, such as various sheet assembly emulation options.  And, if a third-party custom replacement print processor is already installed to perform some required printing function, such as job accounting, the user would likely not want that print processor replaced. Thus although some of the difficulties present with a monolithic driver are avoided in the custom print processor approach, some are just replaced with similar difficulties for what is now a monolithic custom print processor.
A custom replacement print processor is assumed to conform to the system print processor in both interface and functionality.  In contrast to the custom replacement print processor approach, some embodiments described herein present an "incremental" approach that can allow both an existing printer driver and the OS-supplied default print processor (or other third-party custom replacement print processor) to be retained.  Briefly, a custom print processor is placed in the data path between the print spooler and the default or "system" print processor.  The custom print processor appears to the print spooler as the print processor.  In actuality, the custom print processor merely accepts subroutine call arguments from the spooler and passes these arguments through to the default print processor subroutine calls.  But in addition to this pass-through functionality, however, the custom print processor can perform a custom action in one or more of its subroutine calls before passing those calls through to the default print processor.  Thus although "custom", the print processor implements little more than the custom features, and relies on the default print processor to implement the rest.  This custom print processor can therefore remain fairly simple and portable across multiple operating systems, since it need only comprehend and retain the argument structure for a print processor subroutine call on each platform.
DETAILED DESCRIPTION OF THE EMBODIMENTS
The following embodiments are described in the context of various Microsoft Windows operating systems.  Although exemplary, these embodiments are not intended to be limiting, as the concepts illustrated can be applied in other vendors' operating systems, as well as in Microsoft Windows operating systems that are not specifically addressed.
Figure 4 shows the general print data flow for a first embodiment of the invention.  A PS driver is constructed using the OS built-in base PS driver 50 and a PPD 52.  Preferably, PPD 52 includes whatever printer features and options are specifiable by PPD (as will be discussed below, this may include features that can be specified by PPD but are not recognizable by the particular printerthese serve as instructions to a custom print processor to emulate the feature).  Once constructed, this PS driver is called whenever an application or process 20 desired to print to the corresponding printer.
Once, rendered or journaled, print data is spooled by base PS driver 50 to spooler 24, as is conventional.  By, e.g., one of the methods to be illustrated below, the spooler is configured to pass print job data to custom print processor 60.  Custom print processor 60 performs any custom actions that are appropriate, and then passes the print job data to the system print processor 70.  System print processor 70 continues processing, as is conventional and as it would if called directly from spooler 24.
As an aid in this illustration, it is instructive to examine how spooler 24 and system print processor 70 interact in the absence of custom print processor 60.  In a Microsoft OS, the default print processor subroutines are located in a Dynamic-Link Library (DLL), named winprint.dll.  As will be recognized by those skilled in the art, a DLL contains binary instructions that can be linked to a calling program at runtime instead of at compile time, using dynamic linking.
The default print processor DLL includes several external-referenced subroutines that are normally callable by the spooler, of the form <Entry>PrintProcessor( spooler:args ), where Entry is selected from the group [Enum, Open, Close, Control, PrintDocumentOn], and "spooler:args" represents the arguments expected from the spooler with that particular call.  Figure 5 illustrates the contents of winprint.dll conceptually (the actual file is of course a binary file), showing each of these subroutines with a corresponding entry point.
In addition to these external-referenced subroutines, the default print processor DLL includes an exported function InitializePrintProcessor( ).  After an operating system reboot, the first time a printer driver having a correspondence to winprint.dll is invoked, winprint.dll is dynamically loaded into the spooler.  After loading winprint.dll, the spooler uses the OS function GetProcAddress( ) to discover the address of InitializePrintProcessor( ).  The spooler calls InitializePrintProcessor( ), which returns a data structure containing the addresses of the remaining external-referenced, but not exported, functions in the print processor (the <Entry>PrintProcessor( ) functions described above).  The spooler can then call the <Entry>PrintProcessor( ) functions as they are needed.
In the present embodiment, a custom print processor DLL is dynamically linked to the spooler instead of the winprint.dll.  As shown in Figure 6, the custom print processor DLL contains external-referenced subroutine entry points, custom:<Entry>PrintProcessor( ), corresponding in type and arguments to the winprint.dll entry points, and an exported function InitializePrintProcessor( ).
When the custom print processor DLL is first loaded, it also loads winprint.dll.  When the custom function InitializePrintProcessor( ) is called by the spooler, it calls in turn the winprint.dll function InitializePrintProcessor( ) to discover the addresses for the winprint.dll functions <Entry>PrintProcessor( ).  The custom print processor then returns, to the spooler, a data structure indicating the addresses of the custom:<Entry>PrintProcessor( ) functions.
Referring back to Figure 6, a call to one of the print processor entry points is illustrated.  The spooler performs a subroutine call to custom:<Entry>PrintProcessor( args ) using the corresponding address that was returned during the InitializePrintProcessor( ) call.  The syntax of args depends on which subroutine is called.
The custom print processor function custom:<Entry>PrintProcessor( spooler:args ) performs any custom actions that are appropriate (some examples are included further along in this description).  The custom actions may, however, as one result modify the arguments received from the spooler.  After taking the custom actions, the subroutine custom:<Entry>PrintProcessor() calls its corresponding default print processor function <Entry>PrintProcessor( [modified]spooler:args ) from winprint.dll, with the (possibly modified) arguments passed in by the spooler.  The default print processor function performs whatever actions are conventional for the print processor to perform in that operating system, and returns the results to the custom print processor.  The custom print processor returns these default results to the spooler.  If the results of the custom print processor actions require, the default results may be merged or combined with the custom results as appropriate.
From this example, it can be appreciated that the functionality embedded in the custom print processor can be relatively small and focused almost exclusively on implementing the custom features.  By depending on the default print processor to do the work normally expected of a print processor, the custom print processor need not replicate that functionality or concern itself greatly with the idiosyncrasies of each platform (unless, of course, those idiosyncrasies are implicated in the custom features).  As such, test and debug procedures become relatively straightforward and development and maintenance costs are reduced.
There are several different broad categories of custom actions that may be implemented in the custom print processor.  For a given print job, none, one, some, or all of these categories of actions may be performed.
The first category of custom actions includes the set of actions that allow a user to actuate a non-PPD feature or option.  For instance, after a print job is despooled to the custom print processor (e.g., in the custom:PrintDocumentOnPrintProcessor( ) subroutine), a User Interface can be displayed that allows a user to select a custom feature.  Exemplary features could include a pool-printing feature (the user selects this feature to allow the print processor to select a printer from a group of printers, e.g., based on availability and/or a best capability match), a job-splitting feature that splits a print job into several sub-jobs and distributes these jobs to different printers, a sheet assembly or document-finishing feature that is not available in the PPD, etc.  Also included in the custom action could be a pop-up notification that a feature, such as a cluster-printing feature, has directed the print job to a specific printer or printers.
The second and third categories of custom actions are those that modify the print data stream, e.g., to add, delete, or modify print job language commands (category two) or modify the rendered data by adding or modifying PostScript directives (category three).  In a Microsoft OS the print data stream is not part of the Application Binary Interface (ABI) of the print processor, but is located in a spool data file associated with the print job.  Thus category two and three custom actions require that the custom print processor locate and modify the print job spool data file before the default print processor PrintDocumentOnPrintProcessor( ) function is called.  The spool file can be located using the print job ID ("jobID") passed from the spooler to the custom print processor OpenPrintProcessor( ) call as part of the Document Data argument.  Using jobID, the custom print processor can find the spool file at, e.g., C:\windows\system\spool\<jobID>.spl (Windows 95/98/Me) or C:\windows\system32\spool\printers\<jobID>.spl (Windows NT/2000).  Once this file is located, the custom print processor can open the spool data file for read/write and modify it in place, or read the spool data file, make modifications to the copy, and then replace the spool data file with a new spool data file.  For instance, a PJL command could be inserted in the spool file to activate a binding option that cannot be specified in the PPD.  A sheet assembly option, not available through the PPD, can be specified in the PostScript data.  Where a job is split between two printers, the spool file could be duplicated and one copy sent to each printer.  In each copy, the number of copies command would be located and modified to reflect the number of copies actually printed by that copier.
The last category of custom actions includes those that modify the arguments received from the spooler before passing those arguments to the default print processor.  For instance, if the custom action redirects the print job to a different printer, the spooler arguments can be modified accordingly to force this redirection in the default print processor.
Note that in order to fully implement a given custom feature, custom actions in two or more of these categories may be required.  It is also possible that a custom action could work in conjunction with the PPD to emulate a PPD-specifiable function that the print device itself does not support.  For instance, a given sheet assembly option can be indicated as supported in the PPD, even though the print device does not support this option directly.  When the user selects this option, the custom print processor detects the selection directive, removes the directive from the spool file, and rearranges the data in the spool file to match the option.
The preceding example assumes that some custom action (or some configuration needed for later custom actions) may result from each spooler call to a print processor function.  It is conceivable that for a given print processor function the custom print processor does nothing more than pass the arguments through in a call to the default print processor, and return the result of the default call to the spooler.  In such a case, that particular custom print processor function can optionally be removed from the library.  As illustrated in Figure 7 for the ControlPrintProcessor( ) function, the custom InitializePrintProcessor( ) function merely returns the address of the default print processor ControlPrintProcessor( ) function in the data structure.  When the spooler subsequently calls ControlPrintProcessor( ), the custom print processor is bypassed for that call.
In accordance with the preceding embodiments, several new methods for installing a PostScript printer on a computer operating system are also contemplated.  A PPD that defines those printer features supportable by the base PS driver is installed.  The custom print processor, including the custom actions, is installed in the proper directory (e.g., C:\windows\system for Windows 95/98/Me, or C:\windows\system32\spool\prtprocs\w32x86 for Windows NT/2000/XP).  Then the operating system is configured to call the custom print processor instead of the default print processor.  This step can be accomplished in several ways.  First, the information (.inf) file corresponding to the PPD can be modified directly.  This involves setting the PrintProcessor field to specify the library containing the custom print processor.  Second, in some operating systems there is a Print Processor setting in the printer driver's system properties (located at Properties->Advanced->Print Processor on Windows NT/2000/XP).  This setting can be set to the library containing the custom print processor.  Third, a copy of the spooler executable file can be modified directly in some instances such that at run time it dynamically loads the custom print processor instead of the default print processor.  This involves locating the relocation entry (although located in a binary file, these entries appear in a table of ASCII strings) for the winprint.dll InitializePrintProcessor( ) function, and modifying it to bind instead to the initialize function in the custom print processor DLL.  Depending on the operating system, other methods may be available, but are not discussed in detail herein.
Those skilled in the art recognize the various media capable of holding the binary custom print processor library functions and PPD definitions, including but not limited to optical and magnetic disks, and static or dynamic solid-state memory devices, any of which may be local, networked, fixed or removable, and understand that at distribution, after installation, and at run-time the functions and definitions can exist in various places on these media.
Although PostScript has been used as an exemplary PDL in the preceding embodiments, an incremental custom print processor as described can be equally applied to other rendering formats, whether they be another PDL or another format entirely.  In general, the printer manufacturer knows the format its printer expects, and thus can write the incremental custom print processor to read and modify print data in that format.  The printer driver need not be a PPD driver, and could even be a driver supplied by the printer manufacturer.
One of ordinary skill in the art will recognize that the concepts taught herein can be tailored to a particular application in many other advantageous ways.  In particular, those skilled in the art will recognize that the illustrated embodiments are but one of many alternative implementations that will become apparent upon reading this disclosure.  Although a "default" or "system" print processor is generally a print processor supplied with the OS, the default or system print processor can also be a custom replacement print processor.  "Modifying" print job data or arguments can include in-place alteration, additions, or deletions, or replacement with substitute data or arguments.  No distinction is drawn herein between the terms "subroutine", "function", and "entry point".  Although the embodiments described herein implement the custom print processor as a single DLL, the functionality could of course be distributed among multiple DLLs, and/or in some operating systems the custom print processor could be a separately executable program.
Note that although the custom print processor is sometimes described as associated with a "printer" of a given type, that "printer" can in some instances be a cluster of printers, which need not all be of the same type, administered by the custom print processor.  Such minor modifications are encompassed within the invention, and are intended to fall within the scope of the claims.
The preceding embodiments are exemplary.  Although the specification may refer to "an", "one", "another", or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment.
3    Brief Description of Drawings
The invention may be best understood by reading the disclosure with reference to the drawing, wherein:
Figures 1, 2, and 3 illustrate prior art Windows OS print environments for, respectively, a monolithic PS driver, a customized generic PS driver, and a PPD PS driver;
Figure 4 shows a Windows OS print environment according to an embodiment of the invention, using a PPD PS driver and a custom print processor inserted between the spooler and system print processor;
Figure 5 shows the prior art relationship between a spooler and a system print processor dynamic link library; and
Figures 6 and 7 illustrate relationships between a spooler, a custom print processor, and a system print processor for some embodiments of the invention.
1.     A method of configuring a computer's operating system to process print jobs for a first printer type, the operating system having a system print processor, the method comprising:
configuring a print spooler to pass print jobs for the first printer type to a custom print processor; and
configuring the custom print processor to accept print jobs from the print spooler, process print job custom aspects related to the first printer type, and pass the print job to the system print processor for default print processing.
2.     The method of claim 1, wherein a printer of the first printer type accepts print jobs in a page description language, the method further comprising supplying a printer definition for the first printer type to a generic page description language printer driver that supplies print data to the print spooler, the custom aspects of the print job comprising custom print options for printer features not supported by the generic printer driver printer definition.
3.     The method of claim 2, further comprising, for at least one of the custom print options, configuring the custom print processor to display that custom print option to a user as a selectable element of a graphical user interface.
4.     The method of claim 1, wherein configuring a custom print processor to process print job custom aspects comprises configuring the custom print processor to modify a section of the print job data containing print job command language.
5.     The method of claim 1, wherein configuring a custom print processor to process print job custom aspects comprises configuring the custom print processor to modify a section of the print job data containing printing data.
6.     The method of claim 1, wherein configuring a custom print processor to process print job custom aspects comprises configuring the custom print processor to modify spooler argument data before passing the spooler argument data to the system print processor.
7.     A custom print processor dynamic-link library comprising:
a set of external-referenced custom print processor subroutines that conform to the calling syntax of a set of external-referenced default print processor subroutines in a default print processor dynamic-link library, each custom print processor subroutine in the set including a call to the corresponding default print processor subroutine entry point, at least one of the custom print processor subroutines further comprising a custom action to be performed prior to calling the corresponding default print processor subroutine; and
an initialization subroutine that loads the default print processor dynamic-link library and retrieves the default print processor subroutine entry points, the initialization subroutine providing a set of print processor subroutines entry points to a calling process.
8.     The custom print processor dynamic-link library of claim 7, wherein the set of external-referenced custom print processor subroutines comprises one custom print processor subroutine entry point for each default print processor subroutine entry point.
9.     The custom print processor dynamic-link library of claim 7, wherein the set of external-referenced custom print processor subroutines includes one subroutine entry point for a subset of the default print processor subroutine entry points, the entry points supplied to a calling process by the initialization subroutine including default print processor subroutine entry points for those entry points not having a corresponding custom print processor subroutine entry point.
10.    The custom print processor dynamic-link library of claim 7, the custom action comprising a user interface display action, the user interface allowing a user to select from a set of custom print features not available with a corresponding printer driver.
11.    The custom print processor dynamic-link library of claim 10, the custom action further comprising, depending on the custom print features selected by a user, at least one action selected from the group of actions comprising modifying print job command language, modifying printing data, and modifying spooler argument data.
12.    The custom print processor dynamic-link library of claim 7, the custom action comprising at least one action selected from the group of actions comprising modifying print job command language, modifying printing data, and modifying spooler argument data.
13.    A method of installing a PostScript printer on a computer operating system, the method comprising:
installing a PostScript Printer Definition (PPD) to define printer features supported by a generic PostScript printer driver;
installing a custom print processor that defines and implements custom printer features not supported by the generic PostScript printer driver, the custom print processor dynamically linking to a default print processor to perform print processing other than the custom printer features; and
configuring the operating system to call the custom print processor instead of the default print processor for print jobs spooled for the printer.
14.    The method of claim 13, wherein configuring the operating system to call the custom print processor comprises setting an information file to indicate that the custom print processor is the print processor to be used for the printer.
15.    The method of claim 13, wherein configuring the operating system to call the custom print processor comprises setting an operating system property.
16.    The method of claim 13, wherein configuring the operating system to call the custom print processor comprises modifying a spooler relocation table entry to bind the spooler to the custom print processor.
17.    An apparatus comprising a computer-readable medium containing instructions and definitions that, when executed by a processor, cause that processor to perform a method comprising calling a custom print processor to process print job data produced by a page description language printer driver for a printer, the custom print processor:
enabling at least one custom printer feature that cannot be enabled through the page description language printer driver; and
calling a system print processor to perform default print processing.
18.    The apparatus of claim 17, the method further comprising operating the page description language printer driver according to a set of printer options and features, other than those enabled by the custom print processor, pertaining to the printer.
１    Abstract
An operating system alternate arrangement for a printer driver/spooler/print processor is disclosed.  Referring to one embodiment, although using a PPD-compatible printer driver is often desirable, such a driver includes no mechanism for implementing a printer feature that cannot be specified in a PPD.  The disclosed alternate arrangement uses the PPD for those printer options and features that can be specified by PPD.  The remaining options and features are classified as "custom actions" that are processed in a custom print processor that is bound to the spooler in place of the operating system's default print processor.  Preferably, however, the custom print processor does not implement any traditional print processor functionality.  Instead, after performing any custom actions, the custom print processor subroutines call the OS default print processor subroutines to perform traditional print processing.  This arrangement avoids the printer manufacturer having to duplicate and maintain functionality present in the driver and print processor maintained by the OS or custom replacement print processor vendor.
２    Representative Drawing
Fig. 4
2004157998.tif 000010
2004157998.tif 000011
2004157998.tif 000012
2004157998.tif 000013
2004157998.tif 000014
2004157998.tif 000015
2004157998.tif 000016