JPH07121478A - ジョブ前処理装置及びジョブ前処理方法 - Google Patents

Abstract

(57)【要約】 【目的】 目的のサーバーについて、ユーザがいちいち
その仕様に神経を使う必要がなく、夫々のサーバーの特
長を十分活かすことが出来、且つネットワークにも負担
を掛けない、ジョブ前処理装置及びジョブ前処理方法を
提供する。 【構成】 判断手段１２、１４は、指定されたジョブ
が、指定された転送先、例えばプリントサーバー（Ｃ）
に於て、その儘のデータ形式で、処理が可能か否かを判
断する。その儘の形式では処理出来ない場合、変換手段
１６、１７は、そこで処理可能となるように当該ジョブ
の形式を変換する（例えば日本語フォントを含むＰｏｓ
ｔｓｃｒｉｐｔファイルをビットマップだけからなるＰ
ｏｓｔｓｃｒｉｐｔファイルへ）。転送手段１５は、指
定された転送先で処理可能と判断されたジョブについて
は、その儘、また処理不可能と判断されたジョブについ
ては前記変換された形式のものを指定された転送先に転
送する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はジョブ前処理装置及びジ
ョブ前処理方法に関し、詳しくはクライアントからサー
バーに送られるジョブに対し、必要な前処理を実施する
為の前処理装置及び前処理方法に関する。

【０００２】

【従来の技術】ネットワークシステムでは、同種のサー
バーでも、仕様が異なっているという例が少なくない。
例えばプリントサーバーの場合、或るものは、処理可能
なＰＤＬがＰｏｓｔｓｃｒｉｐｔで通信プロトコルがＴ
ＣＰ／ＩＰであるのに対し、他のものは、処理可能なＰ
ＤＬがＩｎｔｅｒｐｒｅｓｓで通信プロトコルがＸＮＳ
プロトコルである、といった具合である。（ＰＤＬ＝ペ
ージ記述言語。Ｐｏｓｔｓｃｒｉｐｔ＝米国Ａｄｏｂｅ
ｓｙｓｔｅｍｓ社提唱のＰＤＬ。ＴＣＰ／ＩＰ＝コンピ
ュータネットワークＡｒｐａｎｅｔの通信プロトコル。
Ｉｎｔｅｒｐｒｅｓｓ＝米国ゼロックス社提唱ＰＤＬ。
ＸＮＳプロトコル（同）。）

【０００３】このような例は、ネットワークの規模が大
きくなるにつれ、或いはネットワーク間接続が進むにつ
れ多くなる。従って、今後益々このような例は増えると
予想される。またネットワークには元々拡張性があり、
それ故に広汎に採用されて来たというところがある。従
って単独のネットワークシステムでも、処理される業務
量や業務種類が増大し、或いはハードやソフトのバージ
ョンアップ、新製品の開発などが行なわれれば、これを
契機に仕様の異なるサーバーが順次追加されていく、と
いう場面も少なくない。ネットワークシステムがこれか
らも更に普及するであろうことを考慮すれば、このよう
な例も又、益々増えていくと予想される。このように、
仕様の異なるサーバーが次々と接続されていくこと自体
は、ユーザにとってメリットがある。何故なら、同一仕
様のサーバーしか接続されていなかった場合に比べ、処
理可能なジョブの種類が増え、その分、バリエーション
に富んだ業務処理が出来るようになるからである。

【０００４】

【発明が解決しようとする課題】その反面、従来のシス
テムでは、このメリットを十分に活かすことが出来なか
った。何故なら、夫々のサーバーを利用するには夫々の
仕様に合致した操作をする必要があり、一般のユーザが
それを使いこなすのが難しかったからである。例えば或
るプリントサーバーが、或るＰＤＬをサポートしていた
とする。そうすると、同じＰＤＬをサポートしたワープ
ロソフトを選択し、そのワープロソフトの操作方法に従
って文書を作成しないとそのプリントサーバーでは処理
が出来ない。また或るサーバーが、或る通信プロトコル
をサポートしていたとする。そうすると、そのプロトコ
ルをサポートした通信ソフトを選択し、その通信ソフト
の操作方法でデータを送信しないと、そのサーバーにジ
ョブを渡すことが出来ない。

【０００５】即ち、仕様の異なるサーバーが複数個存在
する場合、各サーバーやソフトの仕様をそれなりに理解
し、複数個存在するワープロソフトや通信ソフトの中か
ら、当該サーバーに合致したものを選択して使用しない
とその処理をすることが出来ない。一般のユーザがこれ
らをいちいち判断するのはなかなかに難しい。更に上述
のように、今後益々、サーバーやクライアントについ
て、ソフトやハードの追加或いは更新、更にはネットワ
ーク間接続拡大や変更等が行なわれていくとしたら、こ
れら新しく追加されたものなどについて、全てのユーザ
がその仕様を理解し、それに適するワープロソフト、通
信ソフトなどを選択するという作業をするのは一層難し
くなると考えられる。

【０００６】なお参考になる従来技術として、特開平４
−２５７９１４号公報記載のものがある。図１０を引用
してその概略を説明すると、このシステムでは、文書処
理装置１０１に印刷イメージデータの展開機能が備えら
れている。他の文書処理装置１０２〜１０６が、展開し
たい文書のデータと展開後の印刷イメージデータの送付
先のデータとをこの文書処理装置１０１に送信すると、
該文書処理装置１０１は、供給された文書データを自己
の展開機能を使用して印刷イメージデータに展開し、指
定された文書処理装置１０２〜１０６に送信する。これ
により、印刷イメージデータへの展開機能を備えていな
い各文書処理装置１０２〜１０６に於ても実際の印刷出
力イメージの確認が出来る。この従来技術を、上記課題
解決の為に利用することが考えられる。即ち文書処理装
置１０２〜１０６は、文書処理装置１０１から印刷イメ
ージデータを受け取っているから、これら文書処理装置
１０２〜１０６を一種のサーバーと見立てることとす
る。そして先の文書処理装置１０１に相当する中間的な
装置に於て、例えば文書データを印刷イメージデータ等
に展開し、該展開後のものをこれら文書処理装置１０２
〜１０６へ供給する、という構成を考えてみる。

【０００７】しかしこの構成では上記課題の解決は困難
と考えられる。何故なら、この従来システムには、各サ
ーバー（１０２〜１０６）の仕様の違いを吸収する為の
構成が備えられていないからである。即ちこのシステム
では、供給された印刷データは、文書処理装置１０１に
於て、一律に所定データフォーマットの印刷イメージデ
ータに展開されるだけであり、この為、展開された印刷
イメージデータの形式が、当該サーバーの仕様に一致し
ていなかった場合は、当該送信されたジョブはそのサー
バーでは処理することが出来ない。仮にその問題がない
としても、このように、何でもかんでも一律に印刷イメ
ージデータに展開してしまったのでは、夫々のサーバー
が持っている折角の特長、例えばＰＤＬの展開速度が早
いなど、その特長を全然活かすことが出来ない。更に、
一律に印刷イメージデータに展開してしまうと、データ
量が多くなり、ネットワークの負担も増える。本発明の
目的はこのような従来技術の欠点を解消し、目的のサー
バーについて、ユーザがいちいちその仕様に神経を使う
必要がなく、しかも夫々のサーバーの特長を十分活かす
ことが出来、且つネットワークにも負担を掛けることが
ない、ジョブ前処理装置及びジョブ前処理方法を提供す
ることにある。

【０００８】

【課題を解決するための手段】上記目的達成のため請求
項１の発明では、指定されたジョブが指定された転送先
でその儘の形式で処理可能か否かを判断する判断手段
と、その儘の形式では処理不可能と判断されたとき、指
定されたジョブの形式を指定された転送先で処理可能と
なるように変換する変換手段と、処理可能と判断された
ジョブについてはその儘の形式のものを、処理不可能と
判断されたジョブについては変換された形式のものを、
指定された転送先に転送する転送手段とを備える。また
請求項２の発明では、指定されたジョブが指定された転
送先でその儘の形式で処理可能か否かを判断する手順
と、その儘の形式では処理不可能と判断されたとき、指
定されたジョブの形式を指定された転送先で処理可能と
なるように変換する手順と、処理可能と判断されたジョ
ブについてはその儘の形式のものを、処理不可能と判断
されたジョブについては変換された形式のものを、指定
された転送先に転送する手順とを備える。

【０００９】

【作用】判断手段は、ユーザによって指定されたジョブ
が、ユーザに指定された転送先、例えば或るプリントサ
ーバーに於て、その儘の形式で（クライアントから送信
された儘のデータ形式で）処理が可能か否か（例えばビ
ットマップデータに展開し、用紙上に印刷出力が可能か
否か）を判断する。一例を挙げれば、指定されたサーバ
ーがプリントサーバーであって、Ｉｎｔｅｒｐｒｅｓｓ
の解釈が可能であり、搭載フォントがＡｌｐｈａｂｅ
ｔ、という仕様のものであったとする（Ｉｎｔｅｒｐｒ
ｅｓｓ＝米国ゼロックス社提唱のＰＤＬ）。又このとき
指定されたジョブが、プリント出力であって、出力対象
文書がＩｎｔｅｒｐｒｅｓｓで記述されており、日本語
フォントを含んでいるものであったとする。この場合、
その儘の形式では日本語フォントの部分が指定されたプ
リントサーバーで出力不可能である。変換手段は、指定
されたジョブの形式を指定された転送先で処理可能とな
るように変換する。この例の場合は、例えば日本語フォ
ントの部分をビットマップデータに展開し、このビット
マップをＩｎｔｅｒｐｒｅｓｓに定められているビット
マップデータ記述形式で表現して文書データに組み込
む。転送手段は、指定された転送先で処理可能と判断さ
れたジョブについては、その儘手を加えないで転送先に
ジョブを転送する。一方、そのサーバーでは処理不可能
と判断されたジョブについては、変換された形式のも
の、例えば上記のように日本語フォントの部分をビット
マップデータに展開した文書データを、指定された転送
先に転送する。

【００１０】請求項２の発明も同様で、指定されたジョ
ブが指定された転送先でその儘の形式で処理可能か否か
を判断し、その儘の形式では処理不可能と判断されたと
きは、指定されたジョブの形式を指定された転送先で処
理可能となるように変換する。そして処理可能と判断さ
れたジョブについてはその儘の形式のものを指定された
転送先に転送し、処理不可能と判断されたジョブについ
ては変換された形式のものを指定された転送先に転送す
る。これによりユーザが転送先の仕様についていちいち
神経を使わずともジョブ処理を要求することが出来るよ
うになる。即ち仕様の異なる各サーバーを十分使いこな
すことが出来るようになる。また転送先の仕様に合わせ
て必要な前処理のみを行なうから、一律にビットマップ
データに展開した場合に比べ、各サーバーの特長、例え
ばＰＤＬの展開速度が早い、などの利点を十分に活かす
ことが出来る。更に処理が必要でないものはその儘の形
式でジョブを送るので、ネットワークの負担も小さくな
る。

【００１１】

【実施例】以下本発明の詳細を図示実施例に基いて説明
する。図２に全体構成を示す。図に於て１と２はネット
ワークで、ネットワーク１はＸＮＳプロトコル、ネット
ワーク２はＴＣＰ／ＩＰプロトコルが使用されている。
（ＸＮＳプロトコル＝米国ゼロックス社ネットワークシ
ステムのプロトコル。ＴＣＰ／ＩＰ＝コンピュータネッ
トワークＡＲＰＡＮＥＴで使用されているプロトコ
ル）。３はクライアントで、クライアント（Ａ）、
（Ｂ）はネットワーク１に、またクライアント（Ｃ）〜
（Ｅ）はネットワーク２に接続されている。４はプリン
トサーバーで、プリントサーバー（Ｂ）はネットワーク
１に、プリントサーバー（Ａ）、（Ｃ）、（Ｄ）はネッ
トワーク２に接続されている。なおクライアント、プリ
ントサーバー何れについても、特定のものを指すとき
は、図のブロック内に表示した符号（Ａ）〜（Ｅ）また
は（Ａ）〜（Ｄ）を使用し、そうでないときは符号３ま
たは４を使用する。５はメインサーバーで、ＴＣＰ／Ｉ
ＰとＸＮＳプロトコルの双方をサポートしており、請求
項１のジョブ前処理装置として、或いは請求項２のジョ
ブ前処理方法を実行する装置として機能する。

【００１２】メインサーバー５の構成を図１に示す。図
に於て１１はスプーリング装置で、ＴＣＰ／ＩＰまたは
ＸＮＳプロトコルをサポートしており、これらプロトコ
ルに則って各クライアント３から送信されて来るジョブ
を受信し、蓄積する。なおジョブは、ユーザが指定した
プリントサーバーの名称（Ａ〜Ｄ）、プリントアウトし
たい文書の文書データ、出力枚数などのデータで構成さ
れる。１２は要求内容処理装置で、スプーリング装置１
１に蓄積されたジョブを順に取り出してその内容をスキ
ャンし、使用されているＰＤＬは何か？、日本語のフォ
ントが含まれているか？など、その文書データの内容等
を検査する。なお例えば使用されているＰＤＬの種類
は、当該文書ファイルのヘッダー内容等で判断する。例
えば、ヘッダー部に「％！ＰＳ−Ａｄｏｂｅ−２．０Ｅ
ＰＳＦ−２．０」と記述されていたら、これはＰｏｓｔ
ｓｃｒｉｐｔの文書ファイルである。また「Ｉｎｔｅｒ
ｐｒｅｓｓ／Ｘｅｒｏｘ／２．２」と記述されていた
ら、これはＩｎｔｅｒｐｒｅｓｓの文書ファイルであ
る。

【００１３】１３はサーバー情報保存装置で、図３に例
示したような、各プリントサーバー（Ａ）〜（Ｄ）の仕
様のデータを保持している。１４は処理可否判断装置
で、ユーザが指定したプリントサーバー（Ａ〜Ｄ）に於
て、処理対象のジョブがその儘のデータ形式で処理可能
か否かを判断する。処理可否判断装置１４は要求内容処
理装置１２を経由して供給されてくる上記ジョブの中か
ら、ユーザが指定したプリントサーバーの名称（Ａ〜
Ｄ）を抽出し、サーバー情報保存装置１３からそのプリ
ントサーバー（Ａ〜Ｄ）の仕様を読み出す。そしてこの
仕様と要求内容処理装置１２による検査の結果（使用し
ているＰＤＬの名称、日本語フォント使用の有無等のデ
ータ）を参照し、前述のとおり、そのプリントサーバー
（Ａ〜Ｄ）で、そのときの処理対象ジョブが、その儘の
データ形式で処理可能か否かを判断する。

【００１４】処理可能と判断された場合、処理可否判断
装置１４はそのときのジョブを転送装置１５に供給す
る。転送装置１５は転送先のプリントサーバー（Ａ〜
Ｄ）の仕様に合わせ、ＴＣＰ／ＩＰまたはＸＮＳプロト
コルの何れかで、このジョブを当該指定されたプリント
サーバー（Ａ〜Ｄ）に転送する。その儘の形式では指定
されたプリントサーバー（Ａ〜Ｄ）で処理不可能と判断
された場合、例えばそのプリントサーバー（Ａ〜Ｄ）に
は日本語のフォントが備えられていないのに、ジョブの
中に日本語の文書データが含まれていたような場合、処
理可否判断装置１４はその文書データをビットマップデ
ータ展開装置１６に供給する。ビットマップデータ展開
装置１６は、供給された文書データを全てビットマップ
データに展開し、ビットマップデータ処理装置１７に供
給する。

【００１５】ビットマップデータ処理装置１７は供給さ
れたビットマップデータを、例えば図４に示すＰｏｓｔ
ｓｃｒｉｐｔ形式の文書ファイル２１に組み込む（なお
文書ファイル２１の左側の数字は行番号）。この文書フ
ァイル２１はヘッダー部（１〜２０行目）と、実データ
部（２２〜３１行目）と、テイラー部（３３〜３７行
目）とで構成される。ヘッダー部とテイラー部は固定、
実データ部は可変とされており、この可変の実データ部
にビットマップデータ展開装置１６から供給された文書
のビットマップデータが嵌め込まれる。これにより文書
ファイル２１はビットマップデータだけから成るＰｏｓ
ｔｓｃｒｉｐｔの文書ファイルとなり、日本語フォント
を持たないＰｏｓｔｓｃｒｉｐｔのプリントサーバーか
ら印刷出力することが出来るようになる。なおＰｏｓｔ
ｓｃｒｉｐｔの仕様は公開されており、既に当業者に知
られている。そこで文書ファイル２１の内容について
は、図５に各行の記述の意味を簡単に表現するだけに留
める（図５左端の数字が図４の行番号に対応）。

【００１６】このようにしてビットマップデータ処理装
置１７で生成された文書ファイルは、転送装置１５に供
給される。転送装置１５は前述したように、転送先のプ
リントサーバー（Ａ〜Ｄ）の仕様に合わせ、ＴＣＰ／Ｉ
ＰまたはＸＮＳプロトコルの何れかで、このジョブを当
該指定されたプリントサーバー（Ａ〜Ｄ）に転送する。
これにより指定されたプリントサーバー（Ａ〜Ｄ）が日
本語のフォントを備えていなくても、そのプリントサー
バー（Ａ〜Ｄ）で指定された文書データの印刷出力が出
来るようになる。なおソフト、ハードの対応がまだとれ
ていなかったなどの理由で、指定されたプリントサーバ
ー（Ａ〜Ｄ）で当該ジョブの処理が出来ない場合があ
る。この場合、処理可否判断装置１４はその旨をサーバ
ー指定装置１８に通知する。サーバー指定装置１８はこ
れに応動して不図示ディスプレイに図６のウィンドウ３
１を表示する。このウィンドウ３１は、ユーザに新たな
プリントサーバー（Ａ〜Ｄ）を指定させる為のもので、
各プリントサーバー（Ａ〜Ｄ）の仕様が図のように表示
される。不図示カーソルを所望のプリントサーバー（Ａ
〜Ｄ）の枠の中に置いて不図示マウスのボタンクリック
でそれを選択する。

【００１７】なお図ではこの実施例に備えられているプ
リントサーバー全てを表示した。しかし、処理可否判断
装置１４により、そのときのジョブが処理出来ないと判
断されたものをここで表示するのは意味が無い。従っ
て、そのようなプリントサーバーのデータはここでは表
示しないこととする。同様にこのときのジョブが処理出
来ないプリントサーバーについてもそのデータを表示す
るのは意味が無い。そこで、このとき処理可否判断装置
１４で行なったジョブの内容の検査結果を、サーバー情
報保存装置１３に保存されている他の各プリントサーバ
ー（Ａ〜Ｄ）の仕様と照合し、このようなものについて
もそのデータを表示しないこととする。

【００１８】また図６では、プリントサーバの仕様の例
を示すという意味で、又このような仕様が理解できるユ
ーザにとってはこの表示の意味があるということで、プ
リントサーバーの仕様の一部を表示した。しかしユーザ
にとっては、プリントサーバー（Ａ〜Ｄ）の設置場所、
例えば同じフロアにあるとか、文書を送る相手方のフロ
アにあるとかいうことや、或いはどの大きさ迄の用紙が
出力可能か、カラーかモノクロか、といったことの方が
プリントサーバー選択の判断材料になることもある。従
って、このウィンドウ３１に表示するデータの内容は具
体的なユーザ層に対応して定めるのが良い。なおサーバ
ー指定装置１８はプリントサーバー（Ａ〜Ｄ）の仕様登
録の為のウィンドウをも備える。本実施例では、このウ
ィンドウは図３に示したテーブルと同じ内容とする。徒
に紙面を増やすことになるから、この図３のテーブルが
不図示ディスプレイに表示されているものとし、この仕
様登録の為のウィンドウの図示は行なわない。なおこの
仕様の登録操作は、図７に示すステップＳ１、Ｓ２で行
なう。具体的にはテーブルにデータを書き込んでいくの
と同じ要領で、図３のテーブルの各項目の欄に不図示カ
ーソルを置いて不図示マウスのボタンをクリックし、次
いでその項目（仕様）のデータを不図示キーボード等か
ら入力する。なお「ステップ」の語は以後省略する。

【００１９】次に図８、図９を引用して本実施例システ
ムで実行される処理の詳細を説明する（図８と図９は各
端子で接続される）。先ず、ＴＣＰ／ＩＰまたはＸＮＳ
プロトコルプロトコルに則って各クライアント３から送
信されて来るジョブはスプーリング装置１１に蓄積され
る（Ｓ１１）。このジョブには、ユーザが指定したプリ
ントサーバーの名称（Ａ〜Ｄ）、プリントアウトしたい
文書のデータ、出力枚数などの各データが含まれる。要
求内容処理装置１２はスプーリング装置１１に蓄積され
たこのジョブを順に取り出す（Ｓ１２）。そしてその内
容をスキャンし、「使用されているＰＤＬは何か？、日
本語のフォントが含まれているか？」など、そのジョブ
の内容を検査する（Ｓ１３）。処理可否判断装置１４
は、要求内容処理装置１２を経由して供給されてくる上
記ジョブの中から、ユーザが指定したプリントサーバー
の名称（Ａ〜Ｄ）を抽出し、サーバー情報保存装置１３
からそのプリントサーバー（Ａ〜Ｄ）の仕様を読み出
す。

【００２０】そしてこの仕様と、要求内容処理装置１２
による検査の結果（使用しているＰＤＬの名称、日本語
フォント使用の有無等のデータ）とを参照し、ユーザが
指定したそのプリントサーバー（Ａ〜Ｄ）に於て、処理
対象のジョブがその儘のデータ形式で処理（プリントア
ウト）可能か否かを判断する（Ｓ１４）。処理可能と判
断された場合（Ｓ１４「その儘転送すれば処理可
能」）、処理可否判断装置１４はそのときのジョブを転
送装置１５に供給する。転送装置１５は転送先のプリン
トサーバー（Ａ〜Ｄ）の仕様に合わせ、ＴＣＰ／ＩＰま
たはＸＮＳプロトコルの何れかで、このジョブを当該指
定されたプリントサーバー（Ａ〜Ｄ）に転送する（Ｓ１
５）。なお転送が完了しない場合は再度この作業を行な
う（Ｓ１６→Ｓ１５）。

【００２１】その儘の形式では指定されたプリントサー
バー（Ａ〜Ｄ）で処理不可能と判断された場合（Ｓ１４
「サーバーの望む形に前処理すれば処理可能」）、処理
可否判断装置１４はその文書データをビットマップデー
タ展開装置１６に供給する。例えば指定されたプリント
サーバーが「Ｃ」であり、このときのジョブの文書デー
タがＰｏｓｔｓｃｒｉｐｔで記述され、日本語が含まれ
ていたとする。プリントサーバー（Ｃ）は日本語のフォ
ントを備えてはいないものの、Ｐｏｓｔｓｃｒｉｐｔ自
体は処理可能である。従って前処理としてこの日本語の
フォントの展開を実行すれば、このときのジョブは処理
可能ということになる。ビットマップデータ展開装置１
６は、このようにして供給されてきた文書データを全て
ビットマップデータに展開し、ビットマップデータ処理
装置１７に供給する（Ｓ１７）。ビットマップデータ処
理装置１７は供給されたビットマップデータを、前述の
ように図４に示すＰｏｓｔｓｃｒｉｐｔ形式の文書ファ
イル２１に組み込む（Ｓ１８）。これにより文書ファイ
ルはビットマップデータだけから成るＰｏｓｔｓｃｒｉ
ｐｔの文書ファイルとなり、日本語フォントを持たない
プリントサーバー（Ｃ）からでも印刷出力することが出
来るものとなる。

【００２２】このようにしてビットマップデータ処理装
置１７で生成された文書ファイルは、転送装置１５に供
給される。転送装置１５は、転送先のプリントサーバー
（Ａ〜Ｄ）の仕様に合わせ、ＴＣＰ／ＩＰまたはＸＮＳ
プロトコルの何れかで、このジョブを当該プリントサー
バー（Ａ〜Ｄ）に転送する（Ｓ１５、Ｓ１６）。これに
より指定されたプリントサーバー（Ａ〜Ｄ）が例えば日
本語のフォントを備えていなくても、そのプリントサー
バー（Ａ〜Ｄ）で指定された文書データの印刷出力等が
出来るようになる。なおソフト、ハードの対応がまだと
れていなかったなどの理由で、指定されたプリントサー
バー（Ａ〜Ｄ）で当該ジョブの処理が出来ない場合があ
る（Ｓ１４「処理不可能」）。この場合、処理可否判断
装置１４はその旨をサーバー指定装置１８に通知する。
サーバー指定装置１８はこれに応動して、不図示ディス
プレイに図６のウィンドウ３１を表示する。このウィン
ドウ３１により、ユーザに新たなプリントサーバー（Ａ
〜Ｄ）を指定したら、処理可否判断装置１４は、該新た
に指定されたプリントサーバー（Ａ〜Ｄ）の仕様をサー
バー情報保存装置１３から読み出し、Ｓ１４からの処理
を再実行する。

【００２３】なお上述した実施例では、前処理として、
日本語を含む文書データのビットマップデータへの展開
と、プロトコルの変換とを行なった。これ以外にも、サ
ーバーの仕様の違いをカバーするための他の種々の前処
理について、これら実施例と同様の形での実施が可能で
ある。最後に実施例の構成と請求項の構成の対応を述べ
る。要求内容処理装置１２、処理可否判断装置１４が請
求項１にいう判断手段にあたる。ビットマップデータ展
開装置１６、ビットマップデータ処理装置１７が変換手
段にあたる。転送装置１５が同じく転送手段にあたる。
メインサーバー５が前処理装置にあたる。Ｓ１３、Ｓ１
４が請求項２にいう「指定されたジョブが指定された転
送先でその儘の形式で処理可能か否かを判断する手順」
にあたる。Ｓ１６、Ｓ１７が「その儘の形式では処理不
可能と判断されたとき、指定されたジョブの形式を指定
された転送先で処理可能となるように変換する手順」に
あたる。Ｓ１５が「処理可能と判断されたジョブについ
てはその儘の形式のものを、処理不可能と判断されたジ
ョブについては変換された形式のものを、指定された転
送先に転送する手順」にあたる。

【００２４】

【発明の効果】以上説明したように、本発明では指定さ
れたジョブが指定された転送先でその儘の形式で処理可
能か否かを判断し、その儘の形式では処理不可能と判断
されたとき、指定された転送先で処理可能となるように
指定されたジョブの形式を変換し、処理可能と判断され
たジョブについてはその儘の形式のものを、処理不可能
と判断されたジョブについては変換された形式のもの
を、指定された転送先に転送するようにした。従って目
的のサーバーについて、ユーザがいちいちその仕様に神
経を使う必要は無くなる。また転送先がその儘で処理可
能であればその儘転送し、必要なものだけビットマップ
データに展開するので、即ち転送先の仕様を判断した上
で必要とされる前処理を行なうので、例えばＰｏｓｔｓ
ｃｒｉｐｔの処理が早いものはそれを活かすなど、夫々
のサーバーの特長を十分活かすことが出来るようにな
る。更に一律にビットマップに展開する等しないことか
ら、ネットワークにも負担が掛からないシステムを構築
することが出来るようになる。

【図面の簡単な説明】

【図１】 実施例のメインサーバーの構成を示すブロッ
ク図。

【図２】 実施例のシステム構成を示すブロック図。

【図３】 各プリントサーバーの仕様の例を示す線図。

【図４】 Ｐｏｓｔｓｃｒｉｐｔで記述された文書ファ
イルの例を示す線図。

【図５】 図４の文書ファイルの各行の意味を示す線
図。

【図６】 ユーザがプリントサーバーの再指定を行なう
為のウィンドウ表示を示す線図。

【図７】 プリントサーバーの仕様を設定する為の手順
を示すフローチャート。

【図８】 実施例のメインサーバーによる処理の内容を
示すフローチャート（その１）。

【図９】 実施例のメインサーバーによる処理の内容を
示すフローチャート（その２）。

【図１０】 従来技術の構成を示すブロック図。

【符号の説明】

５ 前処理装置 １２、１４ 判断手段 １５ 転送手段 １６、１７ 変換手段

Claims (2)

【特許請求の範囲】
1. 【請求項１】 指定されたジョブが指定された転送先で
   その儘の形式で処理可能か否かを判断する判断手段と、 その儘の形式では処理不可能と判断されたとき、指定さ
   れたジョブの形式を指定された転送先で処理可能となる
   ように変換する変換手段と、 処理可能と判断されたジョブについてはその儘の形式の
   ものを、処理不可能と判断されたジョブについては変換
   された形式のものを、指定された転送先に転送する転送
   手段とを備えたことを特徴とするジョブ前処理装置。
2. 【請求項２】 指定されたジョブが指定された転送先で
   その儘の形式で処理可能か否かを判断する手順と、 その儘の形式では処理不可能と判断されたとき、指定さ
   れたジョブの形式を指定された転送先で処理可能となる
   ように変換する手順と、 処理可能と判断されたジョブについてはその儘の形式の
   ものを、処理不可能と判断されたジョブについては変換
   された形式のものを、指定された転送先に転送する手順
   とを備えたことを特徴とするジョブ前処理方法。