<システム概要>
本発明の情報処理システムに好適な実施形態である文書処理システムの概要を、図10〜図23を参照して説明する。この文書処理システムでは、一般アプリケーションにより作成されたデータファイルが、電子原稿ライタによって電子原稿ファイルに変換される。製本アプリケーションはその電子原稿ファイルを編集する機能を提供している。以下、その詳細は説明する。
<システム構成及び動作>
図10は、本実施形態の文書処理システムのソフトウェア構成を示す図である。文書処理システムは、本発明の印刷制御装置に好適な実施形態であるデジタルコンピュータ1000によって実現されている。一般アプリケーション1010は、ワードプロセシングやスプレッドシート、フォトレタッチ、ドローあるいはペイント、プレゼンテーション、テキスト編集などの機能を提供するアプリケーションプログラムであり、OSに対する印刷機能を有している。これらアプリケーションは、作成された文書データや画像データなどのアプリケーションデータを印刷するにあたって、オペレーティングシステム(OS)により提供される所定のインターフェース(一般に、GDIと呼ばれる)を利用する。
すなわち、アプリケーション1010は、作成したデータを印刷するために、前記インターフェースを提供するOSの出力モジュールに対して、あらかじめ定められる、OSに依存する形式の出力コマンド(GDI関数と呼ばれる)を送信する。出力コマンドを受けた出力モジュールは、プリンタ等の出力デバイスが処理可能な形式にそのコマンドを変換し、変換されたコマンド(DDI関数と呼ばれる)を出力する。出力デバイスが処理可能な形式はデバイスの種類やメーカ、機種などによって異なる。そのために、デバイスごとにデバイスドライバが提供されており、OSではそのデバイスドライバを利用してコマンドの変換を行い、印刷データを生成し、JL(Job Language)でくくることにより印刷ジョブが生成される。OSとしてマイクロソフト社のウインドウズを利用する場合には、前述した出力モジュールとしてはGDIと呼ばれるモジュールが相当する。
電子原稿ライタ1020は、前述のデバイスドライバを改良したものであり、本文書処理システム実現のために提供されるソフトウェアモジュールである。ただし、電子原稿ライタ1020は特定の出力デバイスを目的としておらず、後述の製本アプリケーション1040やプリンタドライバ1060により処理可能な形式に出力コマンドを変換する。この電子原稿ライタ1020による変換後の形式(以後電子原稿形式と呼ぶ)は、ページ単位の原稿を詳細な書式をもって表現可能であれば特に問わない。実質的な標準形式のうちでは、例えばアドビシステムズによるPDF形式や、SVG形式などが電子原稿形式として採用できる。アプリケーション1010により電子原稿ライタ1020を利用させる場合には、出力に使用するデバイスドライバとして電子原稿ライタ1020を指定してから印刷を実行させる。
ただし、電子原稿ライタ1020によって作成されたままの電子原稿ファイルは、電子原稿ファイルとして完全な形式を備えていない。そのため、デバイスドライバとして電子原稿ライタ1020を指定するのは製本アプリケーション1040であり、その管理下でアプリケーションデータの電子原稿ファイルへの変換が実行される。製本アプリケーション1040は、電子原稿ライタ1−2が生成した新規の不完全な電子原稿ファイルを後述する形式を備えた電子原稿ファイルとして完成させる。以下では、この点を明瞭に識別する必要がある際には、電子原稿ライタ1020によって作成されたファイルを電子原稿ファイルと呼び、製本アプリケーションによって構造を与えられた電子原稿ファイルをブックファイルと呼ぶ。また、特に区別する必要がない場合は、アプリケーションにより生成されるドキュメントファイル、電子原稿ファイル、及びブックファイルをいずれも文書ファイル(または文書データ)と呼ぶ。
デバイスドライバとして電子原稿ライタ1020を指定し、一般アプリケーション1010によりそのデータを印刷させる。これにより、アプリケーションデータはアプリケーション1010によって定義されたページ(以後論理ページあるいは原稿ページと呼ぶ)を単位とする電子原稿形式に変換され、電子原稿ファイル1030としてハードディスクなどの記憶媒体に格納される。なお、ハードディスクは、本実施形態の文書処理システムを実現するコンピュータが備えているローカルドライブであってもよいし、ネットワークに接続されている場合にはネットワーク上に提供されるドライブであっても良い。
製本アプリケーション1040は電子原稿ファイルあるいはブックファイル1030を読み込み、それを編集するための機能を利用者に提供する。ただし製本アプリケーション1040は、各ページの内容を編集する機能は提供しておらず、ページを最小単位として構成される、後述する章やブックの構造を編集するための機能を提供している。
製本アプリケーション1040によって編集されたブックファイル1030を印刷する際には、製本アプリケーション1040によって電子原稿デスプーラ1050が起動される。電子原稿デスプーラ1050は、指定されたブックファイルをハードディスクから読み出し、ブックファイルに記述された形式で各ページを印刷するために、前述したOSの出力モジュールに適合する出力コマンドを生成し、不図示の出力モジュールに出力する。その際に、出力デバイスとして使用されるプリンタ1070のドライバ1060がデバイスドライバとして指定される。出力モジュールは、指定されたプリンタ1070のデバイスドライバ1060を用いて受信した出力コマンドを、プリンタ1070で解釈実行可能なデバイスコマンドに変換する。そしてデバイスコマンドはプリンタ1070に送信され、プリンタ1070によってコマンドに応じた画像が印刷される。
図11は、コンピュータ1000のハードウエアブロック図である。図11において、CPU2010は、ROM2030のプログラム用ROMに記憶された、あるいはハードディスク2110からRAM2020にロードされたOSや一般アプリケーション、製本アプリケーションなどのプログラムを実行する。CPU2010は、図10のソフトウェア構成や、後述するフローチャートの手順を実現する。RAM2020は、CPU2010の主メモリ、ワークエリア等として機能する。キーボードコントローラ(KBC)2050は、キーボード2090や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラ(CRTC)2060は、CRTディスプレイ2100の表示を制御する。ディスクコントローラ(DKC)2070はブートプログラム、種々のアプリケーション、フォントデータ、ユーザファイル、後述する編集ファイル等を記憶するハードディスク(HD)2110やフレキシブルディスク(FD)等とのアクセスを制御する。PRTC2080は、接続されたプリンタ1070との間の信号の交換を制御する。NC2120はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。
<電子原稿データの形式>
編集アプリケーション1040の詳細に言及する前に、ブックファイルのデータ形式を説明する。ブックファイルは紙媒体の書物を模した3層の層構造を有する。上位層は「ブック」と呼ばれ、1冊の本を模しており、その本全般に係る属性が定義されている。その下の中間層は、本でいう章に相当し、やはり「章」と呼ばれる。各章についても、章ごとの属性が定義できる。下位層は「ページ」であり、アプリケーションプログラムで定義された各ページに相当する。各ページついてもページごとの属性が定義できる。ひとつのブックは複数の章を含んでいてよく、また、ひとつの章は複数のページを含むことができる。
図12(A)は、ブックファイルの形式の一例を模式的に示す図である。この例のブックファイルは、ブック,章,ページは、それぞれに相当するノードにより示されている。ひとつのブックファイルはひとつのブックを含む。ブック,章は、ブックとしての構造を定義するための概念であるから、定義された属性値と下位層へのリンクとをその実体として含む。ページは、アプリケーションプログラムによって出力されたページごとのデータを実体として有する。そのため、ページは、その属性値のほか、原稿ページの実体(原稿ページデータ)と各原稿ページデータへのリンクを含む。なお、紙媒体等に出力する際の印刷ページは複数の原稿ページを含む場合がある。この構造に関してはリンクによって表示されず、ブック、章、ページ各階層における属性として表示される。
図12において、ブック3010には、ブック属性が定義されているとともに、2つの章3020A,3020Bがリンクされている。このリンクにより、章3020A,3020Bがブック3010に包含されていることが表示される。章3020Aには、ページ3030A,3030Bがリンクされ、これらページが含まれることが示されている。各ページ3030A,3030Bにはそれぞれ属性値が定義され、その実体である原稿ページデータ(1)、(2)へのリンクが含まれる。これらリンクは、図12(B)に示す原稿ページデータ3040のデータ(1)、(2)を指し示し、ページ3030A、3030Bの実体が、原稿ページデータ(1)、(2)であることを表示する。
図13は、ブック属性のリストである。下位層と重複して定義可能な項目に関しては、下位層の属性値が優先採用される。そのため、ブック属性にのみ含まれる項目に関しては、ブック属性に定義された値はブック全体を通して有効な値となる。しかし、下位層と重複する項目については、下位層において定義されていない場合における既定値としての意味を有する。なお、図示された各項目は具体的に1項目に対応するのではなく、関連する複数の項目を含むものもある。
図14は章属性の、図15はページ属性のリストである。章属性とページ属性との関係もブック属性と下位層の属性との関係と同様である。
ブック属性に固有の項目は、印刷方法、製本詳細、表紙/裏表紙、インデックス紙、合紙、章区切りの6項目である。これらは、ブックを通して定義される項目である。印刷方法属性としては、片面印刷、両面印刷、製本印刷の3つの値を指定できる。製本印刷とは、別途指定する枚数の用紙を束にして2つ折りにし、その束をつづり合わせることで製本が可能となる形式で印刷する方法である。製本詳細属性としては、製本印刷が指定されている場合に、見開き方向や、束になる枚数等が指定できる。
表紙/裏表紙属性は、ブックとしてまとめられる電子原稿ファイルを印刷する際に、表紙および裏表紙となる用紙を付加することの指定、及び付加した用紙への印刷内容の指定を含む。インデックス紙属性は、章の区切りとして、印刷装置に別途用意される耳付きのインデックス紙の挿入の指定およびインデックス(耳)部分への印刷内容の指定を含む。この属性は、印刷用紙とは別に用意された用紙を所望の位置に挿入するインサート機能を持ったインサータが使用する印刷装置に備えられている場合か、あるいは、複数の給紙カセットを使用可能である場合に有効となる。これは合紙属性についても同様である。
合紙属性は、章の区切りとして、インサータからあるいは給紙カセットから供給される用紙の挿入の指定、および、合紙を挿入する場合には、給紙元の指定などを含む。
章区切り属性は、章の区切り目において、新たな用紙を使用するか、新たな印刷ページを使用するか、特に何もしないか等の指定を含む。片面印刷時には新たな用紙の使用と新たな印刷ページの使用とは同じ意味を持つ。両面印刷時には、「新たな用紙の使用」を指定すれば連続する章が1枚の用紙に印刷されることは無いが、「新たな印刷ページの使用」を指定すれば、連続する章が1枚の用紙の表裏に印刷されることがあり得る。
章属性に関しては、章に固有の項目はなく、すべてブック属性と重複する。したがって、章属性における定義とブック属性における定義とが異なれば、章属性で定義された値が優先する。ブック属性と章属性とにのみ共通する項目は、用紙サイズ、用紙方向、N−up印刷指定、拡大縮小、排紙方法の5項目である。このうち、N−up印刷指定属性は、1印刷ページに含まれる原稿ページ数を指定するための項目である。指定可能な配置としては、1×1や1×2、2×2、3×3、4×4などがある。排紙方法属性は、排出した用紙にステイプル処理を施すか否かを指定するための項目であり、この属性の有効性は使用する印刷装置がステイプル機能を有するか否かに依存する。
ページ属性に固有の項目には、ページ回転属性、ズーム、配置指定、アノテーション、ページ分割などがある。ページ回転属性は、原稿ページを印刷ページに配置する際の回転角度を指定するための項目である。ズーム属性は、原稿ページの変倍率を指定するための項目である。変倍率は、仮想論理ページ領域のサイズを100%として指定される。仮想論理ページ領域とは、原稿ページを、Nup等の指定に応じて配置した場合に、1原稿ページが占める領域である。例えば1×1であれば、仮想論理ページ領域は1印刷ページに相当する領域となり、1×2であれば、1印刷ページの各辺を約70パーセントに縮小した領域となる。
ブック、章、ページについて共通な属性として、ウォーターマーク属性およびヘッダ・フッタ属性がある。ウォーターマークとは、アプリケーションで作成されたデータに重ねて印刷される、別途指定される画像や文字列などである。ヘッダ・フッタは、それぞれ各ページの上余白および下余白に印刷されるウォーターマークである。
ただし、ヘッダ・フッタには、ページ番号や日時など、変数により指定可能な項目が用意されている。なお、ウォーターマーク属性およびヘッダ・フッタ属性において指定可能な内容は、章とページとは共通であるが、ブックはそれらと異なっている。ブックにおいてはウォーターマークやヘッダ・フッタの内容を設定できるし、また、ブック全体を通してどのようにウォーターマークやヘッダ・フッタを印刷するかを指定することができる。一方、章やページでは、その章やページにおいて、ブックで設定されたウォーターマークやヘッダ・フッタを印刷するか否かを指定できる。
<ブックファイルの生成手順>
ブックファイルは上述したような構造および内容を有している。次に、製本アプリケーション1040および電子原稿ライタ1020によってブックファイルを作成する手順を説明する。ブックファイルの作成は、製本アプリケーション1040によるブックファイルの編集操作の一環として実現される。図16は、製本アプリケーション1040によりブックファイルを開く際の手順である。
まず、製本アプリケーション1040は、開こうとするブックファイルが、新規作成すべきものであるか、それとも既存のものであるか判定する(ステップS7010)。新規作成の場合には、製本アプリケーション1040は、章を含まないブックファイルを新規に作成する(ステップS7020)。新規に作成されるブックファイルは、図12の例で示せば、ブックノード3010のみ有し、章のノードに対するリンクが存在しないブックのノードとなる。ブック属性は、新規作成用としてあらかじめ用意された属性のセットが適用される。そして、新規ブックファイルを編集するためのユーザインターフェース(UI)画面を表示する(ステップS7040)。図20は、新規にブックファイルが作成された際のUI画面の一例である。この場合には、ブックファイルは実質的な内容を持たないために、UI画面11000には何も表示されない。
一方、既存のブックファイルがあれば、製本アプリケーション1040は、指定されたブックファイルを開き(ステップS7030)、そのブックファイルの構造、属性、内容に従ってユーザインターフェース(UI)画面を表示する。図19は、このUI画面の一例である。UI画面11000は、ブックの構造を示すツリー部11010と、印刷された状態を表示するプレビュー部11020とを含む。ツリー部11010には、ブックに含まれる章、各章に含まれるページが、図12(A)のような木構造で表示される。ツリー部11010に表示されるページは原稿ページである。プレビュー部11020には、印刷ページの内容が縮小されて表示される。その表示順序は、ブックの構造を反映したものとなっている。
さて、開かれたブックファイルには、電子原稿ライタによって電子原稿ファイルに変換されたアプリケーションデータを、新たな章として追加することができる。この機能を電子原稿インポート機能と呼ぶ。図16の手順によって新規に作成されたブックファイルに電子原稿インポートすることで、そのブックファイルには実体が与えられる。この機能は、図19の画面にアプリケーションデータをドラッグアンドドロップ操作することで起動される。図17に電子原稿インポートの手順を示す。
まず、指定されたアプリケーションデータを生成したアプリケーションプログラムを起動し、デバイスドライバとして電子原稿ライタ1020を指定してアプリケーションデータを印刷出力させることで、電子原稿データに変換する(ステップS8010)。変換を終えたなら、変換されたデータが画像データであるか否かを判定する(ステップS8020)。この判定は、ウインドウズOSの下であれば、アプリケーションデータのファイル拡張子に基づいて行える。例えば、拡張子が「bmp」であればウインドウズビットマップデータであり、「jpg」であればjpeg圧縮された画像データ、「tiff」であればtiff形式の画像データであると判定できる。また、このような画像データの場合はS8010のようにアプリケーションを起動せずに、画像データから直接電子原稿ファイルを生成することが可能であるため、S8010の処理を省略することも可能である。
画像データでなかった場合には、製本アプリケーション1040は、ステップS8010で生成された電子原稿ファイルを、現在開かれているブックファイルのブックに、新たな章として追加する(ステップS8030)。章属性としては、ブック属性と共通するものについてはブック属性の値がコピーされ、そうでないものについては、あらかじめ用意された規定値に設定される。
画像データである場合には、原則として新たな章は追加されず、指定されている章に、ステップS8010で生成された電子原稿ファイルに含まれる各原稿ページが追加される(ステップS8040)。
ただし、ブックファイルが新規作成されたファイルであれば、新たな章が作成されて、その章に属するページとして電子原稿ファイルの各ページが追加される。ページ属性は、上位層の属性と共通のものについてはその属性値が与えられ、アプリケーションデータにおいて定義された属性を電子原稿ファイルに引き継いでいるもにについてはその値が与えられる。例えば、Nup指定などがアプリケーションデータにおいてされていた場合には、その属性値が引き継がれる。このようにして、新規なブックファイルが作成され、あるいは、新規な章が追加される。
図18は、図17のステップS8010において、電子原稿ライタ1020により電子原稿ファイルを生成させる手順のフローチャートである。まず、新たな電子原稿ファイルを作成してそれを開く(ステップS9010)。指定したアプリケーションデータに対応するアプリケーションを起動し、電子原稿ライタをデバイスドライバとして、OSの出力モジュールに対して出力コマンドを送信させる。出力モジュールは、受信した出力コマンドを電子原稿ライタによって電子原稿形式のデータに変換し、出力する(ステップS9020)。出力先はステップS9010で開いた電子原稿ファイルである。電子原稿ライタ1020は、指定されたデータすべてについて変換が終了したか判定し(ステップS9030)、終了していれば電子原稿ファイルを閉じる(ステップS9040)。電子原稿ライタ1020によって生成される電子原稿ファイルは、図12(B)に示した、原稿ページデータの実体を含むファイルである。
<ブックファイルの編集>
以上のようにして、アプリケーションデータからブックファイルを作成することができる。生成されたブックファイルについては、章及びページに対して次のような編集操作が可能である。
(1)新規追加
(2)削除
(3)コピー
(4)切り取り
(5)貼り付け
(6)移動
(7)章名称変更
(8)ページ番号名称振り直し
(9)表紙挿入
(10)合紙挿入
(11)インデックス紙挿入
(12)各原稿ページに対するページレイアウト。
このほか、いったん行った編集操作を取り消す操作や、さらに取り消した操作をやり直す操作が可能である。これら編集機能により、例えば複数のブックファイルの統合、ブックファイル内で章やページの再配置、ブックファイル内で章やページの削除、原稿ページのレイアウト変更、合紙やインデックス紙の挿入などといった編集操作が可能となる。これらの操作を行うと、図13乃至18に示す属性に捜査結果が反映されたり、あるいはブックファイルの構造に反映される。たとえば、ブランクページの新規追加操作を行えば、指定された箇所にブランクページが挿入される。このブランクページは原稿ページとして扱われる。また、原稿ページに対するレイアウトを変更すれば、その変更内容は、印刷方法やN−up印刷、表紙/裏表紙、インデックス紙、合紙、章区切りといった属性に反映される。
<ブックファイルの出力>
以上のように作成・編集されるブックファイルは印刷出力を最終目的としている。利用者が図19に示す製本アプリケーションのUI画面11000からファイルメニューを選択し、そこから印刷を選択すると、指定した出力デバイスにより印刷出力される。この際、まず製本アプリケーション1040は、現在開かれているブックファイルからジョブチケットを作成して電子原稿デスプーラ1050に渡す。電子原稿デスプーラ1050は、ジョブチケットをOSの出力コマンド、例えばウインドウズのGDIコマンドに変換し、それを出力モジュール、例えばGDIに送信する。出力モジュールは、指定されたプリンタドライバ1060によってデバイスに適したコマンドを生成し、そのデバイスに送信する。
ジョブチケットは原稿ページを最小単位とする構造を有するデータである。ジョブチケットにおける構造は、用紙上における原稿ページのレイアウトを定義している。ジョブチケットは1ジョブにつき1つ発行される。そのため、まず最上位にドキュメントというノードがあり、文書全体の属性、例えば両面印刷/片面印刷などが定義されている。その下には、用紙ノードが属し、用いるべき用紙の識別子や、プリンタにおける給紙口の指定などの属性が含まれる。各用紙ノードには、その用紙で印刷されるシートのノードが属する。1シートは1枚の用紙に相当する。各シートには、印刷ページ(物理ページ)が属する。片面印刷ならば1シートには1物理ページが属し、両面印刷ならば1シートに2物理ページが属する。各物理ページには、その上に配置される原稿ページが属する。また物理ページの属性として、原稿ページのレイアウトが含まれる。
電子原稿デスプーラ1050は、上述のジョブチケットを、出力モジュールへの出力コマンドに変換する。
<そのほかのシステム構成>
本実施形態の文書処理システムの概要は以上のようなものである。これはスタンドアロン型のシステムであるが、これを拡張したサーバクライアントシステムでもほぼ同様の構成・手順でブックファイルが作成・編集される。ただし、ブックファイルや印刷処理はサーバによって管理される。
図21はサーバクライアント型文書処理システムの構成を示すブロック図である。クライアント文書処理システムは、スタンドアロン型システムに、クライアントモジュールであるDOMS(Document Output Management Service:文書出力管理サービス)ドライバ1090を有する。また、クライアント文書処理システムは、DOMSプリントサービスモジュール(プリントサービス提供プログラム)1100、DS(文書サービス)クライアントモジュール1080を加えた構成を有する。このクライアント文書処理システム12000に、文書管理サーバ12010および印刷集中管理サーバ12020およびプリントサーバ12030が接続されている。これらサーバは、通常ネットワークによってクライアント文書処理システムと接続されるが、サーバが同時にクライアントとしても機能する場合には、ネットワーク間の通信をシミュレートするプロセス間通信によって接続される。なお図21では文書管理サーバ12010と印刷集中管理サーバ12020の両サーバがクライアントに接続されているが、いずれか一方のみがネットワーク上に存在する場合もあり得る。接続されているサーバが文書管理サーバであれば、そのクライアントモジュールを含む文書管理サーバクライアントシステム12010SCがスタンドアロン型文書管理システムに追加される。印刷集中管理サーバ12020であれば、そのクライアントモジュールを含む印刷管理サーバクライアントシステム12020SCが、スタンドアロン型文書管理システムに追加される。
文書管理サーバ12010は、製本アプリケーション1040により作成・編集されたブックファイルを格納するサーバである。文書管理サーバ12010によってブックファイルを管理する場合、ブックファイルは、クライアントPCのローカルHDに代わって、あるいはそれに加えて、文書管理サーバ12010のデータベース12110に保存される。製本アプリケーション1040と文書管理サーバ12010との間のブックファイルの保存および読み出しは、DSクライアント1080及びDSコア12120を介して行われる。
印刷集中管理サーバ12020は、クライアント文書管理システム12000に格納された、あるいは文書管理サーバ12010に格納されたブックファイルの印刷を管理するサーバである。クライアントにおける印刷要求は、DOMSドライバ1090およびDOMSプリントサービスモジュール1100を介して印刷集中管理サーバ12020のDOMSWGサーバモジュール12210に送信される。集中印刷管理サーバ12020は、クライアントのプリンタで印刷する場合にはクライアントのDOMSプリントサービスモジュール1100を介して電子原稿デスプーラ1050に電子原稿データを渡す。そして、プリントサーバ12030により印刷する場合には、プリントサーバ12030のDOMSプリントサービスモジュール12030に送信する。集中印刷管理サーバは、例えば保存されているブックファイルに対して印刷要求を発行した利用者の資格などについてセキュリティチェックを行ったり、印刷処理のログを保存したりする。このように、文書処理システムは、スタンドアロンとしても、クライアントサーバシステムとしても実現できる。
<プレビュー表示の内容>
すでに説明したとおり、ブックファイルが製本アプリケーションによって開かれると、図19に示すユーザインターフェース画面11000が表示される。ツリー部11010には、開いているブック(以下、注目ブックと呼ぶ)の構造を示すツリーが表示される。プレビュー部には、利用者の指定に応じて、3通りの表示方法が用意されている。第1は原稿ページをそのまま表示する原稿ビューと呼ばれるモードである。原稿ビューモードでは、注目ブックに属する原稿ページの内容が縮小されて表示される。プレビュー部の表示にレイアウトは反映されない。第2は印刷ビューモードである。印刷ビューモードでは、プレビュー部11020には、原稿ページのレイアウトが反映された形で原稿ページが表示される。第3は簡易印刷ビューモードである。簡易印刷ビューモードでは、各原稿ページの内容はプレビュー部の表示には反映されず、レイアウトのみが反映される。
以下、電子原稿デスプーラー1050に関連した実施形態を説明する。
<第1実施形態>
<装置の説明>
以下、図面を用いて本発明にかかる実施形態を詳細に説明する。
図1は第1実施形態にかかる印刷制御装置(情報処理装置)及びその関連機器より構成されるシステムのブロック図である。同図において、1はシステム・バスであり、これから説明する各構成ブロックはこのシステム・バスに接続している。2はCPU(Central Processing Unit)である。3はプログラム・メモリ(以下、「PMEM」という。)で、印刷制御のためのプログラムを適宜、ハードディスク10から選択し、読込みし、CPU2にてそのプログラムは実行される。
また、キーボード12から入力されたデータはテキスト・メモリでもあるPMEMにコード情報として格納される。4は通制御部であり、5の通信ポートに於ける入出力データの制御を行う。通信ポート5から出力された信号は、通信回線6を経由して、ネットワーク上の他の装置の通信ポートに伝えられる。ネットワーク上で共有されているプリンタや、画像読取装置とのデータの授受は、この通信制御部4を介して行われる。
また、本実施形態ではLANなどのネットワークに関して記述するが、この通信制御部4に接続される通信ポート5及び通信回線6が一般の公衆回線であっても本発明にかかる実施形態が適応できることは言うまでもない。
8は外部記憶制御部であり、9及び10はデータファイル用のディスクで、例えば9は、フレキシブルディスク(FD)であり、10はハードディスク(HD)である。11は入力制御部であり、12のキーボード、13のマウス等の入力装置が接続する。操作者は、このキーボード11を操作することによりシステムの動作指令等を入力する。
また、マウス13はCRT16上で画像情報を加工指示するためのポインティングデバイス(以下、「PD」と称す。)として機能する。これによりCRT16上のカーソルをX,Y方向任意に移動してコマンドメニュー上のコマンド・アイコンを選択して処理の指示を行なうほか編集対象の指示、描画位置の指示等を行なうことができる。14はビデオ・イメージ・メモリ(以下、「VRAM」と称す。)であり、15は表示出力制御部、16はCRTである。CRT16に表示されるデータはVRAM14上にビットマップデータとして展開されている。17はプリンタ制御部であり、接続しているプリンタ18に対するデータの出力制御を行う。1Aは、画像読取機器制御部であり、接続している画像読取機器1Bの制御を行う。
本発明における実施形態において、画像読取サーバ装置には、1A、1Bの構成要素が必須であるが、クライアント側装置では、前述のように通信制御部4及び通信ポート5を介してサーバ側で共有している構成要素を使用することができる。
更に、図1の構成は、画像読取機器と画像読取機器制御部が物理的に別々のコンポーネントであっても、画像読取機器制御部が、画像読取機器を含む1つのコンポーネントであっても同様な機能を有することとする。
なお、本実施形態でPMEMに記憶しているプログラムは、装置に直接接続されているハードディスク(HD)10やフレキシブルディスク(FD)9などの記憶媒体にも記憶されていてもよい。さらに、ネットワークで接続されている他の装置上に記憶されていてもよい。また、本実施形態において使用するプログラムは、FDやHDなどの記憶媒体やネットワークを介してシステムや印刷制御装置に供給することができる。
図2は本実施形態にかかる印刷制御の処理を説明するフローチャートである。
まず、ステップS201で、ユーザの指示により、印刷制御装置は印刷するべき対象となる印刷文書データ(以下、「印刷文書」という。)と、その印刷文書データを出力制御するための印刷指示文書データ(以下、「印刷指示文書」という。)の両方を受け取る。印刷指示文書は、印刷対象となる印刷文書に付随するデータであり、印刷対象の印刷文書をどのように印刷制御すべきかの情報が記述された電子文書データである。印刷文書と印刷指示文書は、場合により、統合されて一つの文書ファイルとなっている場合でも同様に、処理が可能である。
印刷指示文書の全体構造は、図5に示すようなデータ格納部を有するデータ構造を備える。印刷指示文書は、出力対象となるプリンタデバイス名(501)、印刷対象となる印刷文書名(502)、出力先の対象となるプリンタへの指示を記述する、プリンタへの指示情報部(503)を有する。また、印刷指示文書は、出力対象プリンタのDEVMODE格納部(504)、印刷文書の各頁をどのような配置、順序で印刷するかを記述するページ配置情報部(505)を有する。また、印刷指示文書はプリンタデバイスとしてネットワーク上において分散して接続する分散プリンタが指定されている場合に、メンバプリンタ名を格納するメンバプリンタ名称格納部(506)を有する。更に、印刷指示文書は、各メンバプリンタに対応するDEVMODEを格納するメンバDEVMODE格納部(507)を有する。
ここで、DEVMODEとは、デバイス、ここでは、プリンタに設定可能な設定情報の構造体である。この構造体には、基本部分と、拡張部分がある。この基本部分のデータ構造は一般に公開されている。このため、基本部分は、テキスト化して可視的にプログラミングすることも可能である。そして、拡張部分とは、各社が機能を比較的自由に拡張可能なフィールドである。例えば、拡張部分のうち、自社開発の部分などの予めデータ構造の定義を入手可能な部分は、データ構造ツールで解析することにより、DEVMODEの拡張部分の中身を知ることができる。しかし、拡張部分のうち、例えば、他社開発部分など、予めデータ構造を入手不能な部分は、データ構造が不明のため、解析不能であり内容を理解して設定することは一般にはできない。そこで、予めデータ構造を入手不能なDEVMODEの構造体であっても、そのDEVMODE構造体のデータを使用することができる仕組みが求められている。DmCopyieには、デバイスが複数部数のコピーをサポートしているときは、印刷するコピー部数を指定できる。
図22はOSが標準DEVMODEとして提供しているデータ構造の一部を示す図である。このDEVMODEの標準部分は、マイクロソフト社が提供するOSの仕様の一部として盛り込まれている。以下、構造体の各メンバについて説明する。DmDeviceNameにおいては、ドライバがサポートするデバイス名を指定する。各デバイス ドライバは、重複しない文字列を持つ。DmSpecVersionでは、構造体の基準になった初期化データ仕様のバージョン番号を指定する。DmDriverVersionは、プリンタ ドライバの開発者が割り当てたプリンタ ドライバのバージョン番号を指定する。DmSizeは、dmDriverData (デバイス固有の情報) のメンバを除いたDEVMODE構造体のサイズをバイト単位で指定する。
各社は、図22のこの標準部分の構造体のメンバの値を設定することができる。ただし、図22に図示されていない拡張部分については、拡張部分として一般には公開されない。DmDriverExtraは、この構造体に続くプライベートなドライバデータ(拡張DEVMODE、以下、拡張部分という。)のバイト長を保持する。デバイスドライバがデバイス固有の情報を使わないときは、このメンバに 0 を設定する。DmOrientationは、用紙の方向を指定できる。拡張部分は、本発明の拡張領域の好適な一例である。このメンバHADMORIENT_PORTRAIT (ポートレイト) または 、DMORIENT_LANDSCAPE(ランドスケープ) のどちらかになる。DmPaperSizeには、印刷する用紙のサイズを指定する。用紙の高さと幅がそれぞれ、dmPaperLength と dmPaperWidth メンバに対応するが、これらの値が設定されているときは、このメンバには 0 を設定することができる。以上が標準部分の説明である。
図23は、標準領域の好適な一例であるDEVMODEの標準部分2301と、拡張部分2302のメモリマップを示す図である。標準部分2301は、予めDEVMODEのデータ構造が分かっているので、開発ツールを用いて、図22に示すようなテキスト形式で表すことも出来る。例えば、DmDeviceName2304は図22の同じメンバに対応する。2305乃至2307及び図示を省略する他のメンバも同様に対応する。一方、拡張部分は仕様が入手できない場合が多く、この場合にはどのような設定が格納されているのかを窺い知ることができない。図23では、DEVMODEの標準部分と、拡張部分が連続的にメモリに配置されている例を示しているが、連続的に配置されていなくてもよい場合も有る。拡張部分には、N-Up,ポスター印刷モード、ステイプルの有無など、レイアウトに関連する設定情報をはじめ、その他印刷に関する設定情報が格納される。
プリンタへの指示情報部503には、プリンタへ指示するための共通の情報である、一般的な指示情報(一般指示情報)が格納されている。例えば、ステイプル位置、パンチ種類、両面印刷する/しない、給紙口の指定、などである。通常では、このような一般指示情報をもとに、対象となるプリンタのプリンタドライバの固有の印刷設定(DEVMODE)を作成し、その作成したDEVMODEを使用してプリンタへ指示情報を送る。
DEVMODE格納部504において、DEVMODEがすでに指示されている場合は、プリンタへの指示情報部503の記述にかかわらず、指示されているDEVMODEにより、プリンタへ指示を送る。DEVMODEの内容が不明なプリンタの場合、一般的な印刷指示からDEVMODEを作成することが不可能であり、そのため、ユーザがプリンタのプロパティで指定した印刷指示をそのまま 印刷指示文書中に含んで使用することを想定したものである。ただし、DEVMODEのうち、構造が明確になっている共通部分については、プリンタへの指示情報部503の印刷指示を反映させて、新しいDEVMODEを作成しても良いこととする。
本実施形態で使用するプリンタが、複数の分散プリンタとして指定されている場合の印刷指示文書の内容は、図6に示すようになる。プリンタデバイス名格納部(601)には、分散プリンタが指定されており、名称として、"プリンタセット1(分散用)"(602)、分散印刷実行の対象は3つのプリンタであることが記述されている(603)。
メンバプリンタ格納部(607)では、メンバプリンタ名として、"レーザプリンタ1"(608)、"レーザプリンタ2"(609)、" レーザプリンタ3"(610)等、複数のプリンタが設定されている。それぞれのメンバプリンタに対応するプリンタドライバの固有の印刷設定情報として、DEVMODE1(612),DEVMODE2(613)、DEVMODE3(614)がDEVMODE格納部(611)に格納されている。
あらかじめ、ユーザは、図4のダイアログ画面により、分散プリンタの設定を行う。図4のダイアログにおける出力方法401で設定されている「割合分散」とは、一つの印刷指示を指定された複数のプリンタへ、指定された割合で分割して印刷を実行させる指示である。複数のプリンタをメンバプリンタとして有し、これらを仮想プリンタ群として指定することにより、これら仮想プリンタ群を所定の割合分散に従って動作させる。図4において、分散プリンタを選択した場合、分散させるプリンタをメンバプリンタとして登録する。そして、各プリンタのプロパティで、印刷指示を設定することにより、各プリンタに応じたDEVMODEが作成され、その操作により、図6に示すような印刷指示文書を作成することができる。
具体的には、図4で分散プリンタの設定を行なった後、製本アプリケーションにてユーザが分散プリンタを出力先に指定した場合、対応するDOMSドライバが、分散プリンタの各メンバプリンタのDEVMODEを取得して、製本アプリケーションに伝える。これにより、製本アプリケーションはDOMSドライバから渡された、メンバプリンタのDEVMODEを印刷指示文書に格納する。処理を次のステップに進め、ステップS202で印刷指示文書をオープンする。
そして、DOMSプリントサービスにて、ステップS203で印刷指示文書に指定されたプリンタデバイス名を読み込み、印刷指示文書に、プリンタデバイス名が指定されているかどうかを調べる(S204)。プリンタデバイス名が指定されていない場合は(S204−なし)、システムに登録されているデフォルトプリンタ名を取得し、そのプリンタデバイスを出力対象とする(S205)。
次に、DOMSプリントサービスにて、プリンタデバイス名に対するドライバがシステムにインストールされているかどうかをチェックする(S206)。ドライバがインストールされていない場合(S207−No)、エラーとし、プリンタが使用不可能であることをユーザに通知する(S208)。
プリンタドライバがインストールされている場合には(S207−Yes)、詳細を後述するステップS209に処理を進め、該当プリンタでの印刷処理を行う。
図3は、図2のステップS209における、プリンタへの印刷指示処理の流れを説明するフローチャートである。
DOMSプリントサービスにて、指定されているプリンタが、分散用プリンタかどうかチェックし(S301)、分散プリンタの場合は(S301−Yes)、分散プリンタとしてメンバプリンタに指定されているプリンタの名称を読み込む(S302)。そして、そのプリンタへの出力の分散割合を読み込み(S303)、その分散割合に応じて、印刷指示文書の内容を書き換える(S304)。
電子原稿デスプーラにて、設定したプリンタに対応するプリンタドライバの固有の印刷設定情報(DEVMODE)が、印刷指示文書に含まれるか否かを調べる(S305)。印刷指示文書に含まれている場合は(S305−Yes)、それを読み込む(S307)。印刷指示文書に含まれていない場合は(S305−No)、図5における印刷指示文書に格納されているプリンタへの指示情報部503の内容(一般指示情報)であって、プリンタへの印刷指示部分の設定内容から、対象となるプリンタに対応するプリンタドライバの固有に印刷設定情報(DEVMODE)を作成する(S306)。このとき、実装によっては、DEVMODEが含まれている場合でも、プリンタへの指示情報部503の印刷指示を組合わせて設定したDEVMODEを作成しても良い。
続いて、読み込んだ、または、作成したDEVMODEにより、プリンタへ通知するべき指示をプリンタへ送る(S308)。具体的には、DOMSシステムに組み込まれた印刷処理モジュールであるデスプーラが、作成されたDEVMODEを用いて、OSのAPIである、CreateDC()を呼び出すことにより、印刷指示をプリンタへ通知する。そして、印刷文書の内容を、印刷指示文書に含まれるデータの展開指示情報に基づき展開し、プリンタへ展開したデータを送出し(S309)、ステップS309の処理の後、プリンタに全ての印刷データを送出したことを通知する(S310)。
具体的には、OSが提供するアプリケーション・プログラミング・インタフェースであるCreateDC()には、引数として、所望の記憶領域のポインタを与えることができる。デスプーラが、CreateDC()に引数として拡張DEVMODEを指し示すポインタを与え、ポインタが指し示す所望の記憶領域から、DEVMODEの構造体を取得し、ドライバモジュールに送るようにOSを制御する。CreateDC()を用いて、DEVMODEの構造体を得たドライバは、得た情報に基づいて、印刷対象となるプリンタに対して命令を送信する。DEVMODEに記述された内容に基づいて発行された命令がプリンタに送信され、プリンタはその命令に従って動作する。これにより、仕様を別途入手しなければDEVMODEの構造を窺い知ることができない拡張部分に設定されている印刷設定であっても、該設定を活用することができる。
DOMSプリントサービスにて、分散すべきメンバプリンタがまだ残っているかどうかを調べ(S311)、残っている場合には、ステップS302に戻り、続いて第2メンバプリンタ以降の候補プリンタに対し、同様に処理を行う。全ての印刷が終了したら、その旨をユーザに通知し(S312)、印刷を終了する。
本実施形態によれば、印刷指示文書に含まれる共通の設定だけでは、印刷処理ができない場合でも、印刷指示文書に含まれる共通の一般指示情報に基づいてプリンタ固有の印刷設定情報を生成し、その情報に基づき印刷文書の処理を実行することが可能となる。
また、印刷文書の処理を複数のプリンタにより分散して行なう場合であっても、共通となる一般指示情報に基づいて、固有の印刷設定情報が必要なプリンタに対しては、その情報を生成し、印刷文書の分散処理の実行が可能となる。
<第2実施形態>
第1実施形態では、割合分散により複数のプリンタをそれぞれ制御する内容を説明した。本実施形態では、出力先として指示した第1のプリンタが使用不可能な状態にある時や、印刷が失敗した場合に、予め設定してある第2、第3のプリンタへ、その指示内容を代行させる代行印刷において、複数のメンバプリンタを制御する内容を説明するものである。
本実施形態で使用するプリンタとして、代行用のプリンタが指定されている場合の印刷指示文書の内容は、図9に示すようなデータ構造となる。プリンタデバイス名格納部(901)では、代行用のプリンタが指定されており、名称として、"プリンタセット2(代行用)"(902)、代行する対象は3つのプリンタであることが記述されている(903)。
メンバプリンタ格納部(907)では、メンバプリンタ名として、"レーザプリンタ1"(908)、"レーザプリンタ2"(909)、" レーザプリンタ3"(910)等、複数のプリンタが設定されている。それぞれのメンバプリンタに対応するプリンタドライバの固有の印刷設定情報として、DEVMODE1(912),DEVMODE2(913)、DEVMODE3(914)がDEVMODE格納部(911)に格納されている。
予め、ユーザは、図8のダイアログにより、代行用プリンタを選択した場合、代行させるプリンタをメンバプリンタとして登録する。各プリンタのプロパティで、印刷指示を設定することにより、DEVMODEが作成され、その操作により、図9に示す印刷指示文書を作成できる。
具体的には、図8で代行プリンタの設定を行なった後、製本アプリケーションにてユーザが代行プリンタを出力先に指定した場合、対応するDOMSドライバが、代行プリンタの各メンバプリンタのDEVMODEを取得して、製本アプリケーションに伝える。これにより、製本アプリケーションはDOMSドライバから渡された、メンバプリンタのDEVMODEを印刷指示文書に格納する。代行は、メンバプリンタ名格納部に記述された順序で行われる。
図7の処理の流れは、図2で示した、プリンタへの印刷指示処理S209の部分の詳細である。まず、DOMSプリントサービスにて、指定されているプリンタが、代行用プリンタかどうかチェックし(S701)、代行用プリンタの場合は、代行用プリンタのメンバプリンタに指定されている第1のプリンタの名称を読み込む(S702)。
ここで、第1のプリンタが使用可能であるかどうかをチェックする(S704)。使用可能ではない場合(S704−No)、代行用プリンタに設定されている第2のメンバプリンタを読み込み(S703)、そのプリンタに対して処理を行う。
電子原稿デスプーラにて、設定したプリンタに対応するDEVMODEが、印刷指示文書に含まれるか否かを調べ(S705)、含まれている場合は、それを読み込む(S706)。含まれていない場合は、図5のプリンタへの指示情報部503の内容であって、プリンタへの印刷指示部分の設定内容から対象となるプリンタのDEVMODEを作成する(S707)。
このとき、実装によっては、DEVMODEが含まれている場合でも、プリンタへの指示情報部503の印刷指示を重ねて設定したDEVMODEを作成しても良い。
続いて、読み込んだ、または、作成したDEVMODEにより、プリンタへ通知するべき指示をプリンタデバイスへ送る(S708)。具体的には、DOMSシステムに組み込まれた印刷処理モジュールであるデスプーラが、作成されたDEVMODEを用いて、Windows(登録商標)APIである、CreateDC()を呼び出すことにより、印刷指示をプリンタへ通知する。CreateDC()には、引数として、所望の記憶領域のポインタを与えることができ、そのポインタが指す記憶領域から、DEVMODEの構造体を取得し、ドライバモジュールに送るものである。
CreateDC()から、DEVMODEの構造体を得たドライバは、印刷対象となるプリンタに対して命令を送信する。DEVMODEに記述された内容に基づいて発行された命令がプリンタに送信され、プリンタはその命令に従って動作する。従って、内容が不明な拡張DEVMODEであっても、そのDEVMODEを指し示すポインタをOSに渡すと、OSはポインタが指し示すアドレスからDEVMODEを読み出してドライバに送ることができる。
プリンタ全体の制御を統括するプリンタコントローラは、プリンタエンジン、ソータやステイプラなどのオプションを、該DEVMODEが示す設定情報に従って制御する。そして、印刷文書の内容を、印刷指示文書に含まれているデータの展開指示情報に基づき展開し、プリンタへ展開したデータを送出し(S709)、ステップS709の処理の後、プリンタに全ての印刷データを送出したことを通知する(S710)。
ここで、DOMSプリントサービスにて、印刷が成功したか否かをチェックし(S711)、成功していない場合は、代行用プリンタに設定されている次のメンバプリンタを読み込んで(S703)、そのプリンタについて、処理を続行する。全ての印刷が終了したら、その旨をユーザに通知し(S712)、印刷を終了する。
本実施形態によれば、印刷文書の処理を複数のプリンタの代行順位に従い、処理する場合であっても、共通となる一般指示情報に基づいて、代行順位に該当するプリンタであり、固有の印刷設定情報が必要なプリンタに対しては、その情報を生成し、印刷文書の代行順位に従った処理の実行が可能となる。
すなわち、本実施形態によれば、印刷すべき第1のプリンタで印刷が不可能となっていても、第1のプリンタの代行印刷によりメンバープリンタとして設定されている第2、第3のプリンタのDEVMODEにより、印刷文書データを出力することが可能となる。
<他の実施形態>
本発明は、複数の機器(例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど)から構成されるシステムに適用しても、一つの機器からなる装置(複写機、プリンタ、ファクシミリ装置など)に適用してもよい。
本発明の目的は前述した機能を実現するソフトウェアを記憶したコンピュータ可読の記憶媒体を、システムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成される。
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えば、フロッピー(登録商標)ディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、ROMなどを用いることができる。
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(オペレーティングシステム)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
更に、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。