JP4536441B2

JP4536441B2 - ファイル変換装置、ファイル変換方法およびファイル変換プログラム

Info

Publication number: JP4536441B2
Application number: JP2004203314A
Authority: JP
Inventors: 真玄飯塚; 昌俊白崎
Original assignee: Skycom Corp
Current assignee: Skycom Corp
Priority date: 2004-07-09
Filing date: 2004-07-09
Publication date: 2010-09-01
Anticipated expiration: 2024-07-09
Also published as: JP2006024108A

Description

この発明は、アプリケーションなどで作成された文書データを、ＰＤＦなどの電子文書ファイルに変換するファイル変換装置、ファイル変換方法およびファイル変換プログラムに関する。

オフィスのネットワーク化が進むにつれて、従来の紙の書類や申請書、マニュアル、カタログなどの電子文書化が盛んに行われている。電子文書化を行うことで、ファイル容量が極めて小さくなり、ネットワークを介して手軽に配布でき、またＯＳやネットワーク環境に依存せずオリジナルのレイアウトなどがそのまま残されるので、利用者は近年拡大してきている。その中で、国際的に最も多くのユーザに利用されている電子文書のファイル形式として、ＰＤＦ（ＰｏｒｔａｂｌｅＦｉｌｅＦｏｒｍａｔ）がある。

電子文書の作成にあたって、変換ソフトウェアが用いられる。その１つでは、スタンドアロンのコンピュータにそれぞれ電子文書への変換ソフトウェアをインストールし、必要に応じてアプリケーションソフトで作成したデータを、インストールされたプログラムを用いて電子文書に変換していた（たとえば、非特許文献１参照。）。

これに対し、サーバで変換ソフトウェアを共有することにより、クライアント端末に集中する負荷を分散する方法がある。この例として共有フォルダ方式がある。共有フォルダ方式では、サーバに監視フォルダを用意し、クライアントはこの監視フォルダに変換が必要なデータを入れておく。変換ソフトウェアは、この監視フォルダ内を監視する。変換が必要なデータを見つけた場合、変換ソフトウェアは電子文書への変換を行い、出力フォルダに変換後の電子文書を出力する。ユーザはこの出力ファイルを見に行くことにより、変換後の電子文書を取得することができる（たとえば、非特許文献２参照。）。

ここで変換ソフトウェアの、プリンタのしくみとの違いを説明する。プリンタはアプリケーションで作成したデータをプリンタドライバでプリンタに送るべきデータに変換して送信し、プリンタはデータを受信してから解析を行い、印刷処理を行う。プリンタドライバで変換されたデータは、ＥＭＦ（ＥｎｈａｎｃｅｄＭｅｔａＦｉｌｅ、拡張メタファイル）形式であったり、ＰＤＬ（ページ記述言語）で作成されたものであったり、いずれにしても圧縮されていないデータ形式である。プリンタ側に処理負担をかける圧縮形式のデータを送ることは基本的には好まれないからである。

アプリケーションで作成されたデータをプリンタドライバ、そしてプリンタのラスタライザと複数の箇所で変換していくが、基本的に処理の流れに沿って、プリンタで処理しやすい方向に変換されていく。従ってＰＤＦなど電子文書ファイルフォーマットで用いられる、オブジェクトの集合で記述された圧縮データへの変換は、印刷処理のプロセスでは本来は考えられない。

アプリケーションからプリンタまでの間でプリンタサーバをはさむこともあるが、処理の流れそのものは基本的には同じで、プリンタサーバは、ネットワークを介して処理するための、クライアント端末とプリンタとの間の仲介役に過ぎず、原則としては受け取ったデータは受け取ったまま保持しておく。データ変換を行うことはあるが、受け取ったＥＭＦファイルをＰＤＬまたはイメージデータに変換するなど、あくまでプリンタで解釈しやすい方向へと行うものしか従来は存在しなかった。

なおＰＤＦなどの電子文書ファイルは、印刷そのものには必ずしも適したコマンドで記述されてはいない。所定のビュワーなどで見るのに適しかつデータ量を最小にするように、対話的閲覧のためのハイパリンクを含んだり、圧縮などの処理がなされていたりする。従ってプリンタおよびプリンタサーバと、電子文書ファイルへの変換ソフトウェアの機能とは、変換という観点でのみ見れば表面的には同じであるものの、本来まったく異なるものである。

アドビシステムズ株式会社著、「ＡｄｏｂｅＡｃｒｏｂａｔ６．０Ｓｔａｎｄａｒｄ」添付マニュアルアドビシステムズ株式会社著、「ＡｄｏｂｅＡｃｒｏｂａｔＤｉｓｔｉｌｌｅｒＳｅｒｖｅｒ５．０」添付マニュアル

しかし、スタンドアロンで上述の処理を行う場合、電子文書ファイルへの変換は負荷の大きい処理であり、変換処理中は、コンピュータが拘束される。変換処理と並行してコンピュータを使用しても、処理のリソースの大半を変換処理に取られてしまい他の処理を行うのに支障が出ることがあり、他の処理を優先して行おうとすると、変換処理が終わらないという問題があった。

また、フォントや外字などの共通ファイルに追加・変更があった場合、個々に更新することになり、外字などのコードの割り当てがバラバラになるという問題があった。また、ＰＣごとに変換ソフトウェアをインストール・バージョンアップする必要があった。

共有フォルダ方式の場合、電子文書ファイルへの変換処理が終わったかどうか、定期的にフォルダを監視しなくてはいけないので、監視間隔分だけ電子文書ファイルへの変換処理が遅くなっていた。従って処理の開始や終了と同時に次の動作へ移行できなかった。また、排他制御の問題上、フォルダ内にあるファイルを一度に並行処理することができなかった。またフォルダ内のデータの処理であるので、アプリケーション側に情報が伝わらなかった。このため、出力メディアの容量不足などエラーが発生してもフォルダ内を見なければ知ることができず、ジョブ待ち状態などのリアルタイムな処理状況を知ることができなかった。

この方式の問題点は、あくまでスタンドアロン用の変換ソフトウェアを拡張してネットワーク上で用いられるようにしているに過ぎないという点である。通常のネットワークの機能の範囲内でのファイルの受け取りおよび出力にとどまり、ネットワーク上のユーザの用途に適したユーザインターフェースになっていない。

上述のように、電子文書変換ソフトウェアはスタンドアロンで用いることが前提とされていた。電子文書変換ソフトウェアをネットワーク対応としたものはあったが、スタンドアロン用のものをネットワークでも使用できるようにしたに過ぎず、ネットワーク上で利用する電子文書変換ソフトウェアという発想で開発されたものは存在しなかった。スタンドアロン用の電子文書変換ソフトウェアをネットワーク上で用いる場合に、特にユーザインターフェースにおいては、使い勝手が悪いという問題があった。

これらの状況に鑑み、本発明は、ネットワーク上のユーザの用途に適した形での電子文書ファイルへの変換処理を行うファイル変換装置、ファイル変換方法およびファイル変換プログラムを提供することを目的としている。

上述した課題を解決し、目的を達成するため、請求項１の発明にかかるファイル変換装置では、外部端末のアプリケーションにより入力された出力指示に応答して、前記外部端末のデバイスドライバにより作成され出力先情報を含む印刷用データを受信し、受信した印刷用データを、グラフィックスおよびテキストのオブジェクトの圧縮データで記述された電子文書ファイルに変換し、変換された電子文書ファイルを、前記出力先情報により指定される出力先に出力する。

この請求項１の発明によれば、ユーザは、デバイスドライバで作成できる印刷用データを、ファイル変換装置に送るだけでよく、アプリケーションから直接に、プリンタでの印刷処理を指示するような簡単な操作で、ファイル変換装置に対して電子文書ファイルへの変換処理を指示することができ、これにより電子文書ファイルを得ることができる。つまり、ファイル変換装置で受け取るのが印刷用データなので、送受信にあたり特別な形式のデータ形式にするための、特別なデータ作成のプログラムを外部端末側で用意する必要がない。

その一方でファイル変換装置側では、デバイスドライバにより作成された印刷用のデータを受け取ることにより電子文書ファイルへの変換処理を行うことができる。従ってクライアント端末には、改めてファイル変換装置に送るべきデータを作成するためのソフトウェアを組み込む必要がない。そしてファイル変換装置側のみが変換処理のための構成を備えることにより、クライアント端末から変換のためのデータを受け取り、スムーズに変換処理を行うことができる。

また、請求項２の発明にかかるファイル変換装置では、請求項１の発明において、印刷用データに基づいてグラフィックスおよびテキストのオブジェクトの圧縮データにより構成されるオブジェクト情報を作成し、印刷用データに基づいて、出力する電子文書ファイルのファイル構造および文章構造を記述する構造データを作成し、オブジェクト情報および構造データを含む電子文書ファイルを作成する。

この請求項２の発明によれば、通常のプリンタに対して送信される印刷用データを受け取ることにより、オブジェクト情報およびそのオブジェクト情報の構成を記述する構造データを作成することができ、その結果電子文書ファイルを作成することができる。電子文書ファイルのオブジェクト情報だけでなく構造データも作成されるので、作成された電子文書ファイルを取得したあと閲覧するときに、構造データに基づいてオブジェクト情報が電子文書全体の中でレイアウトされる。従って閲覧に適した電子文書ファイルを印刷用データから作成することができる。

以上の処理は、クライアント端末自身で行うか、またはクライアント端末からサーバのディレクトリを操作するなどの特別な操作を要していたが、本発明によれば、外部端末側では、デバイスドライバで作成できる印刷用データを、ファイル変換装置に送るだけでよく、アプリケーションから直接に、プリンタでの印刷処理を指示するような簡単な操作で、上述の処理がされた電子文書ファイルを得ることができる。その一方でファイル変換装置側では、デバイスドライバにより作成された印刷用のデータを受け取ることにより、上述の処理がされた電子文書ファイルへの変換処理を行うことができる。

また、請求項３の発明にかかるファイル変換装置では、請求項１または２に記載の発明において、アクセス制限情報を検出し、印刷用データは、このアクセス制限情報に基づいてアクセス制限された電子文書ファイルに変換される。

この請求項３の発明によれば、クライアント端末で通常のプリンタに対して行うのと同様の操作により、アクセス制限された電子文書ファイルを、例えばネットワーク接続された先のファイル変換装置側で得ることができる。電子文書ファイルにアクセス制限することにより、許可されていないユーザは作成された電子文書ファイルを閲覧することができないので、限られたユーザのみが閲覧することのできる機密書類として電子文書ファイルを配布することができる。

また外部端末側では、デバイスドライバで作成できる印刷用データを、ファイル変換装置に送るだけでよく、アプリケーションから直接に、プリンタでの印刷処理を指示するような簡単な操作で、上述の処理がされた電子文書ファイルを得ることができる。その一方でファイル変換装置側では、デバイスドライバにより作成された印刷用のデータを受け取ることにより、上述の処理がされた電子文書ファイルへの変換処理を行うことができる。

特に外部の端末から送られてきたデータを電子文書ファイルに変換する場合、ファイル変換装置は外部端末を使用していたユーザからは離れているので、電子文書ファイルに対し、不特定多数のユーザがアクセスする恐れがある。これに対し、作成する電子文書ファイルにアクセス制限がされるので、機密を保護することができる。

また請求項４の発明にかかるファイル変換装置では、請求項１〜３のいずれか一つに記載の発明において、受信された印刷用データに基づいて出力先のパスを判定し、変換された電子文書ファイルは、判定された出力先のパスに出力する。

この請求項４の発明によれば、クライアント端末では通常のプリンタに対して行うのと同様の操作により、電子文書ファイルを所望のパスから得ることができる。例えば、出力先のパスとして外部メディアを指定した場合は外部メディアから、ファイル変換装置内やクライアント端末のフォルダのパスを指定した場合は、そのフォルダで電子文書ファイルを取得することができる。

こうした出力先のパスの指定を印刷用データの中で行うことができるので、例えば外部端末においてあらかじめパスの設定をしておいて、デバイスドライバが設定されたパスの情報を含めて印刷用データを作成するようにしておけば、ユーザは出力指示以外の操作を特に必要とすることなく、アプリケーションからの出力指示を行ったら変換処理が済み次第、電子文書ファイルを取得することができる。

また請求項５の発明にかかるファイル変換装置では、請求項１〜４のいずれか一つに記載の発明において、出力先情報で指定される出力先媒体の記録容量の不足を検出し、記録容量の不足が検出される場合、外部端末のアプリケーションに通知を行う。

この請求項５の発明によれば、クライアント側の端末からの指示によりファイル変換装置でファイルへの変換処理を行う場合の、出力先の媒体で容量の不足を、ユーザ自身でネットワークを介してファイル変換装置内の状態を調べることなく、容量の不足が判明した時点でユーザが知ることができる。

また請求項６の発明にかかるファイル変換装置では、請求項５の発明において、記録容量の不足が検出される場合、変換された電子文書ファイルを一時的に記憶し、外部端末から送られた再保存要求に基づいて、一時的に記憶された電子文書ファイルを、再保存要求で指定された出力先に保存する。

この請求項６の発明によれば、クライアント側の端末からの指示によりファイル変換装置でファイルへの変換処理を行う場合の、出力先の媒体で容量の不足に対し、変換結果は一時的に記憶しておくので、再度の保存要求に対してデータを破棄して再び再変換処理を行うという手間をかける必要がなくなる。

また請求項７の発明にかかるファイル変換装置では、請求項６の発明において、電子文書ファイルの再保存を行った場合、一時的に記憶されたデータは消去される。

この請求項７の発明によれば、ユーザの指示を特に必要とせずに、一時的に記憶されていただけの不要なデータを消去し、ファイル変換装置上の記憶領域を確保することができる。

また請求項８の発明にかかるファイル変換装置では、請求項１〜７のいずれか一つに記載の発明において、出力先のパスを設定し、設定された出力先のパスを、出力先情報が指定する出力先とする。

この請求項８の発明によれば、電子文書ファイルの変換結果を、例えばフレキシブルディスクやＭＯディスク、ファイル変換装置内のフォルダや外部端末装置内のフォルダなど、出力先情報の指定により所望の出力先に出力することができる。

また請求項９の発明にかかるファイル変換装置では、請求項８の発明において、出力先情報が電子文書ファイルの出力先を指定しない場合に、設定された出力先のパスを、出力先情報が指定する出力先とする。

この請求項９の発明によれば、電子文書ファイルの出力先を特に外部端末で指定しておくことなく、ファイル変換装置側で出力先を設定してその設定先に、電子文書ファイルを出力することができる。特に外部端末側の指定に左右されずに、特定の出力先に出力させたい場合に有用である。

また請求項１０の発明にかかるファイル変換装置では、請求項１〜９のいずれか一つに記載の発明において、印刷用データを変換処理の順番に記憶し、記憶手段に記憶される順番で前記印刷用データの変換を行う。

この請求項１０の発明によれば、複数の印刷用データを受信して記憶しておくことができ、また記憶した印刷用データを変換すべき順序で変換処理することができる。

また請求項１１の発明にかかるファイル変換装置では、請求項１０の発明において、記憶手段は複数の記憶部により構成され、変換手段は、前記複数の記憶部のそれぞれに対応した複数の変換部により構成され、記憶部と変換部を１つの組とした仮想変換部が、複数で並行動作する。

この請求項１１の発明によれば、１つのファイル変換装置内に仮想的に複数の変換部を持つことができ、複数のファイル変換装置を有しているものとして、外部から変換処理を指示することができる。

また請求項１２の発明にかかるファイル変換装置では、請求項１１の発明において、前記印刷用データに含まれる指定情報に基づいて、前記印刷用データの変換を行う仮想変換部を指定し、指定された仮想変換部に前記印刷用データの変換を行わせる。

この請求項１２の発明によれば、ファイル変換装置内に仮想的に備えられた複数の変換部に対し、どの仮想変換部で処理を行うのかを指示することができる。

請求項１３の発明にかかるファイル変換方法では、外部端末のアプリケーションにより入力された出力指示に応答して、前記外部端末のデバイスドライバにより作成され出力先情報を含む印刷用データを受信し、受信した印刷用データを、グラフィックスおよびテキストのオブジェクトの圧縮データで記述された電子文書ファイルに変換し、変換された電子文書ファイルを、前記出力先情報により指定される出力先に出力する。

この請求項１３の発明によれば、ユーザは、デバイスドライバで作成できる印刷用データを、ファイル変換装置に送るだけでよく、アプリケーションから直接に、プリンタでの印刷処理を指示するような簡単な操作で、ファイル変換装置に対して電子文書ファイルへの変換処理を指示することができ、これにより電子文書ファイルを得ることができる。つまり、ファイル変換装置で受け取るのが印刷用データなので、送受信にあたり特別な形式のデータ形式にするための、特別なデータ作成のプログラムを外部端末側で用意する必要がない。

また、請求項１４の発明にかかるファイル変換方法では、請求項１３の発明において、印刷用データに基づいてグラフィックスおよびテキストのオブジェクトの圧縮データにより構成されるオブジェクト情報を作成し、印刷用データに基づいて、出力する電子文書ファイルのファイル構造および文章構造を記述する構造データを作成し、オブジェクト情報および構造データを含む電子文書ファイルを作成する。

この請求項１４の発明によれば、通常のプリンタに対して送信される印刷用データを受け取ることにより、オブジェクト情報およびそのオブジェクト情報の構成を記述する構造データを作成することができ、その結果電子文書ファイルを作成することができる。電子文書ファイルのオブジェクト情報だけでなく構造データも作成されるので、作成された電子文書ファイルを取得したあと閲覧するときに、構造データに基づいてオブジェクト情報が電子文書全体の中でレイアウトされる。従って閲覧に適した電子文書ファイルを印刷用データから作成することができる。

また、請求項１５の発明にかかるファイル変換方法では、請求項１３または１４に記載の発明において、アクセス制限情報を検出し、印刷用データは、このアクセス制限情報に基づいてアクセス制限された電子文書ファイルに変換される。

この請求項１５の発明によれば、クライアント端末で通常のプリンタに対して行うのと同様の操作により、アクセス制限された電子文書ファイルを、例えばネットワーク接続された先のファイル変換装置側で得ることができる。電子文書ファイルにアクセス制限することにより、許可されていないユーザは作成された電子文書ファイルを閲覧することができないので、限られたユーザのみが閲覧することのできる機密書類として電子文書ファイルを配布することができる。

また請求項１６の発明にかかるファイル変換方法では、請求項１３〜１５のいずれか一つに記載の発明において、受信された印刷用データに基づいて出力先のパスを判定し、変換された電子文書ファイルは、判定された出力先のパスに出力する。

この請求項１６の発明によれば、クライアント端末では通常のプリンタに対して行うのと同様の操作により、電子文書ファイルを所望のパスから得ることができる。例えば、出力先のパスとして外部メディアを指定した場合は外部メディアから、ファイル変換装置内やクライアント端末のフォルダのパスを指定した場合は、そのフォルダで電子文書ファイルを取得することができる。

また請求項１７の発明にかかるファイル変換方法では、請求項１３〜１６のいずれか一つに記載の発明において、出力先情報で指定される出力先媒体の記録容量の不足を検出し、記録容量の不足が検出される場合、外部端末のアプリケーションに通知を行う。

この請求項１７の発明によれば、クライアント側の端末からの指示によりファイル変換装置でファイルへの変換処理を行う場合の、出力先の媒体で容量の不足を、ユーザ自身でネットワークを介してファイル変換装置内の状態を調べることなく、容量の不足が判明した時点でユーザが知ることができる。

また請求項１８の発明にかかるファイル変換方法では、請求項１７の発明において、記録容量の不足が検出される場合、変換された電子文書ファイルを一時的に記憶し、外部端末から送られた再保存要求に基づいて、一時的に記憶された電子文書ファイルを、再保存要求で指定された出力先に保存する。

この請求項１８の発明によれば、クライアント側の端末からの指示によりファイル変換装置でファイルへの変換処理を行う場合の、出力先の媒体で容量の不足に対し、変換結果は一時的に記憶しておくので、再度の保存要求に対してデータを破棄して再び再変換処理を行うという手間をかける必要がなくなる。

また請求項１９の発明にかかるファイル変換方法では、請求項１８の発明において、電子文書ファイルの再保存を行った場合、一時的に記憶されたデータは消去される。

この請求項１９の発明によれば、ユーザの指示を特に必要とせずに、一時的に記憶されていただけの不要なデータを消去し、ファイル変換装置上の記憶領域を確保することができる。

また請求項２０の発明にかかるファイル変換方法では、請求項１３〜１９のいずれか一つに記載の発明において、出力先のパスを設定し、設定された出力先のパスを、出力先情報が指定する出力先とする。

この請求項２０の発明によれば、電子文書ファイルの変換結果を、例えばフレキシブルディスクやＭＯディスク、ファイル変換装置内のフォルダや外部端末装置内のフォルダなど、出力先情報の指定により所望の出力先に出力することができる。

また請求項２１の発明にかかるファイル変換方法では、請求項２０の発明において、出力先情報が電子文書ファイルの出力先を指定しない場合に、設定された出力先のパスを、出力先情報が指定する出力先とする。

この請求項２１の発明によれば、電子文書ファイルの出力先を特に外部端末で指定しておくことなく、ファイル変換装置側で出力先を設定してその設定先に、電子文書ファイルを出力することができる。特に外部端末側の指定に左右されずに、特定の出力先に出力させたい場合に有用である。

また請求項２２の発明にかかるファイル変換方法では、請求項１３〜２１のいずれか一つに記載の発明において、印刷用データを変換処理の順番に記憶し、記憶手段に記憶される順番で前記印刷用データの変換を行う。

この請求項２２の発明によれば、複数の印刷用データを受信して記憶しておくことができ、また記憶した印刷用データを変換すべき順序で変換処理することができる。

また請求項２３の発明にかかるファイル変換方法では、請求項２２の発明において、記憶手段は複数の記憶部により構成され、変換手段は、前記複数の記憶部のそれぞれに対応した複数の変換部により構成され、記憶部と変換部を１つの組とした仮想変換部が、複数で並行動作する。

この請求項２３の発明によれば、１つのファイル変換装置内に仮想的に複数の変換部を持つことができ、複数のファイル変換装置を有しているものとして、外部から変換処理を指示することができる。

また請求項２４の発明にかかるファイル変換方法では、請求項２３の発明において、前記印刷用データに含まれる指定情報に基づいて、前記印刷用データの変換を行う仮想変換部を指定し、指定された仮想変換部に前記印刷用データの変換を行わせる。

この請求項２４の発明によれば、ファイル変換装置内に仮想的に備えられた複数の変換部に対し、どの仮想変換部で処理を行うのかを指示することができる。

また、請求項２５の発明にかかるファイル変換プログラムでは、外部端末のアプリケーションにより入力された出力指示に応答して、前記外部端末のデバイスドライバにより作成され出力先情報を含む印刷用データを受信し、受信した印刷用データを、グラフィックスおよびテキストのオブジェクトの圧縮データで記述された電子文書ファイルに変換し、変換された電子文書ファイルを、前記出力先情報により指定される出力先に出力する。

この請求項２５の発明によれば、ユーザは、デバイスドライバで作成できる印刷用データを、ファイル変換装置に送るだけでよく、アプリケーションから直接に、プリンタでの印刷処理を指示するような簡単な操作で、ファイル変換装置に対して電子文書ファイルへの変換処理を指示することができ、これにより電子文書ファイルを得ることができる。つまり、ファイル変換装置で受け取るのが印刷用データなので、送受信にあたり特別な形式のデータ形式にするための、特別なデータ作成のプログラムを外部端末側で用意する必要がない。

また、請求項２６の発明にかかるファイル変換プログラムでは、請求項２５の発明において、印刷用データに基づいてグラフィックスおよびテキストのオブジェクトの圧縮データにより構成されるオブジェクト情報を作成し、印刷用データに基づいて、出力する電子文書ファイルのファイル構造および文章構造を記述する構造データを作成し、オブジェクト情報および構造データを含む電子文書ファイルを作成する。

この請求項２６の発明によれば、通常のプリンタに対して送信される印刷用データを受け取ることにより、オブジェクト情報およびそのオブジェクト情報の構成を記述する構造データを作成することができ、その結果電子文書ファイルを作成することができる。電子文書ファイルのオブジェクト情報だけでなく構造データも作成されるので、作成された電子文書ファイルを取得したあと閲覧するときに、構造データに基づいてオブジェクト情報が電子文書全体の中でレイアウトされる。従って閲覧に適した電子文書ファイルを印刷用データから作成することができる。

また、請求項２７の発明にかかるファイル変換プログラムでは、請求項２５または２６に記載の発明において、アクセス制限情報を検出し、印刷用データは、このアクセス制限情報に基づいてアクセス制限された電子文書ファイルに変換される。

この請求項２７の発明によれば、クライアント端末で通常のプリンタに対して行うのと同様の操作により、アクセス制限された電子文書ファイルを、例えばネットワーク接続された先のファイル変換装置側で得ることができる。電子文書ファイルにアクセス制限することにより、許可されていないユーザは作成された電子文書ファイルを閲覧することができないので、限られたユーザのみが閲覧することのできる機密書類として電子文書ファイルを配布することができる。

また請求項２８の発明にかかるファイル変換プログラムでは、請求項２５〜２７のいずれか一つに記載の発明において、受信された印刷用データに基づいて出力先のパスを判定し、変換された電子文書ファイルは、判定された出力先のパスに出力する。

この請求項２８の発明によれば、クライアント端末では通常のプリンタに対して行うのと同様の操作により、電子文書ファイルを所望のパスから得ることができる。例えば、出力先のパスとして外部メディアを指定した場合は外部メディアから、ファイル変換装置内やクライアント端末のフォルダのパスを指定した場合は、そのフォルダで電子文書ファイルを取得することができる。

また請求項２９の発明にかかるファイル変換プログラムでは、請求項２５〜２８のいずれか一つに記載の発明において、出力先情報で指定される出力先媒体の記録容量の不足を検出し、記録容量の不足が検出される場合、外部端末のアプリケーションに通知を行う。

この請求項２９の発明によれば、クライアント側の端末からの指示によりファイル変換装置でファイルへの変換処理を行う場合の、出力先の媒体で容量の不足を、ユーザ自身でネットワークを介してファイル変換装置内の状態を調べることなく、容量の不足が判明した時点でユーザが知ることができる。

また請求項３０の発明にかかるファイル変換プログラムでは、請求項２９の発明において、記録容量の不足が検出される場合、変換された電子文書ファイルを一時的に記憶し、外部端末から送られた再保存要求に基づいて、一時的に記憶された電子文書ファイルを、再保存要求で指定された出力先に保存する。

この請求項３０の発明によれば、クライアント側の端末からの指示によりファイル変換装置でファイルへの変換処理を行う場合の、出力先の媒体で容量の不足に対し、変換結果は一時的に記憶しておくので、再度の保存要求に対してデータを破棄して再び再変換処理を行うという手間をかける必要がなくなる。

また請求項３１の発明にかかるファイル変換プログラムでは、請求項３０の発明において、電子文書ファイルの再保存を行った場合、一時的に記憶されたデータは消去される。

この請求項３１の発明によれば、ユーザの指示を特に必要とせずに、一時的に記憶されていただけの不要なデータを消去し、ファイル変換装置上の記憶領域を確保することができる。

また請求項３２の発明にかかるファイル変換プログラムでは、請求項２５〜３１のいずれか一つに記載の発明において、出力先のパスを設定し、設定された出力先のパスを、出力先情報が指定する出力先とする。

この請求項３２の発明によれば、電子文書ファイルの変換結果を、例えばフレキシブルディスクやＭＯディスク、ファイル変換装置内のフォルダや外部端末装置内のフォルダなど、出力先情報の指定により所望の出力先に出力することができる。

また請求項３３の発明にかかるファイル変換プログラムでは、請求項３２の発明において、出力先情報が電子文書ファイルの出力先を指定しない場合に、設定された出力先のパスを、出力先情報が指定する出力先とする。

この請求項３３の発明によれば、電子文書ファイルの出力先を特に外部端末で指定しておくことなく、ファイル変換装置側で出力先を設定してその設定先に、電子文書ファイルを出力することができる。特に外部端末側の指定に左右されずに、特定の出力先に出力させたい場合に有用である。

また請求項３４の発明にかかるファイル変換プログラムでは、請求項２５〜３３のいずれか一つに記載の発明において、印刷用データを変換処理の順番に記憶し、記憶手段に記憶される順番で前記印刷用データの変換を行う。

この請求項３４の発明によれば、複数の印刷用データを受信して記憶しておくことができ、また記憶した印刷用データを変換すべき順序で変換処理することができる。

また請求項３５の発明にかかるファイル変換プログラムでは、請求項３４の発明において、記憶手段は複数の記憶部により構成され、変換手段は、前記複数の記憶部のそれぞれに対応した複数の変換部により構成され、記憶部と変換部を１つの組とした仮想変換部が、複数で並行動作する。

この請求項３５の発明によれば、１つのファイル変換装置内に仮想的に複数の変換部を持つことができ、複数のファイル変換装置を有しているものとして、外部から変換処理を指示することができる。

また請求項３６の発明にかかるファイル変換プログラムでは、請求項３５の発明において、前記印刷用データに含まれる指定情報に基づいて、前記印刷用データの変換を行う仮想変換部を指定し、指定された仮想変換部に前記印刷用データの変換を行わせる。

この請求項３６の発明によれば、ファイル変換装置内に仮想的に備えられた複数の変換部に対し、どの仮想変換部で処理を行うのかを指示することができる。

本発明によれば、ユーザは、デバイスドライバで作成できる印刷用データを、ファイル変換装置に送るだけでよく、アプリケーションから直接に、プリンタでの印刷処理を指示するような簡単な操作で、ファイル変換装置に対して電子文書ファイルへの変換処理を指示することができ、これにより電子文書ファイルを得ることができる。つまり、ファイル変換装置で受け取るのが印刷用データなので、送受信にあたり特別な形式のデータ形式にするための、特別なデータ作成のプログラムを外部端末側で用意する必要がない。その一方でファイル変換装置側では、デバイスドライバにより作成された印刷用のデータを受け取ることにより電子文書ファイルへの変換処理を行うことができる。

以下に添付図面を参照して、この発明にかかるファイル変換装置、ファイル変換方法およびファイル変換プログラムの好適な実施の形態を詳細に説明する。図１は、本発明の一実施形態が適用されるネットワークの構成図である。ネットワーク上でクライアント１１０およびクライアント１２０が、ネットワークを介して変換サーバ１３０に接続されている。クライアント１１０、１２０の他にもさらに接続することができる。クライアント１１０上では、アプリケーション１１１およびＯＳ（オペレーティングシステム）１１２が動作している。

文書データはまずアプリケーション１１１上で作成される。作成された文書データはＯＳ１１２上で処理され、ＥＭＦ（ＥｎｈａｎｃｅｄＭｅｔａＦｉｌｅ、拡張メタファイル）形式により記述されたＥＭＦファイル１１３として、変換サーバ１３０に送られる。クライアント１２０でもクライアント１１０と同様に、アプリケーション１２１およびＯＳ１２２が動作しており、ＥＭＦファイル１１３が、変換サーバ１３０に送られる。

変換サーバ１３０は、送られてきたＥＭＦファイル１１３を受け取り、データスプーラ１３１でスプーリングする。スプールされたデータは、順番がきたらデータ変換部１３２に送られ、データ変換部１３２は、スプールされたデータを電子文書ファイル１３３に変換して出力する。

図２は、クライアント１１０のソフトウェア上の構成を示すブロック図である。アプリケーション１１１には、ワープロ２０１および表計算２０２などが含まれる。

ユーザがアプリケーション１１１で作ったデータは、アプリケーション１１１上での出力指示を受けてＯＳ１１２に送られる。出力指示には、ストレージ、ネットワーク、メディアなどの、電子文書ファイルの出力先のパスも含む。ユーザがサーバ上の電子文書ファイルへの変換処理を要求する場合、デバイスドライバ２１１はＧＤＩ関数で表現されたデータを、サーバに送り出せるようにＥＭＦファイル１１３にする。ＥＭＦファイル１１３は、ＧＤＩ関数とデータの実体はほぼ同じだが、印刷ジョブとしてサーバに送り出すのに必要なヘッダなどを付加したものである。

アプリケーション１１１は、特定のプリンタやプロッタに出力を描画するとき、デバイス固有のコマンドを発行せずに、グラフィックデバイスインターフェース（ＧＤＩ）の高レベル関数を呼び出す。たとえば、ビットマップイメージを印刷するには、ビットマップの座標と転送元と転送先のデバイスコンテキストを識別するハンドルを指定して、ＢｉｔＢｌｔ関数を呼び出す。

ＯＳ１１２は、ＡＰＩと呼ばれる数多くのソフトウェアにより構成される。例えばＭＩＣＲＯＳＯＦＴ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）では、レーザープリンタ、インクジェットプリンタ、ファックスなどさまざまなデバイスにアプリケーションで作成された文書が印刷できるようにするための関数のセットが用意されている。この関数の大きな特徴の１つは、デバイスに依存しないことである。ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）用に作成されたアプリケーションは、さまざまなデバイスに出力を表示したり印刷したりできる。このデバイスに依存しない出力をサポートするソフトウェアは、ダイナミックリンク・ライブラリとして提供される。

デバイスドライバ２１１は、プリンタドライバと同様のデバイスドライバであり、ＷＩＮＤＯＷＳ（登録商標）デバイスドライバ・インターフェース（ＤＤＩ）をサポートするダイナミックリンク・ライブラリ（ＤＬＬ）である。デバイスドライバ２１１は、ＢｉｔＢｌｔ関数を低レベルのデバイスコマンドに変換する。デバイスドライバ２１１は、グラフィックエンジン２１４からのＤＤＩ関数呼び出しを処理するとき、低レベルのデバイスコマンドを生成する。また、デバイスドライバ２１１は、元々クライアント１１０で使用しているものを用いることもできるが、クライアント１１０と変換サーバ１３０との接続設定を行うときに、変換サーバ１３０から自動でアップロードされる構成にすることもできる。

デバイスドライバ２１１を用いた処理を行うに当たり、特定のデバイスドライバ２１１をメモリにロードしなければならない。また、デバイスドライバ２１１がロードされたら、描画操作のためのデバイスの準備（線の色と幅、ブラシのパターンと色、フォントの書体、クリッピング・リージョンなどの選択）を行わなければならない。このような作業は、デバイスコンテキストを作成して管理することによって行う。

ここでデバイスコンテキストについて説明する。デバイスコンテキストとは、グラフィック・オブジェクトとそれに関連する属性、出力に影響するグラフィックモードを定義する構造体である。ＷＩＮＤＯＷＳ（登録商標）では、ディスプレイ、プリンタ、メモリ（互換）、情報の４種類のデバイスコンテキストを用意している。ディスプレイは、ビデオディスプレイに対する描画操作をサポートする。プリンタはプリンタやプロッタに対する描画操作をサポートする。メモリはビットマップに対する描画操作をサポートする。情報はデバイスデータの取得をサポートする。

プリンタ・デバイスコンテキストを作成するには、適切な引数（デバイスドライバの名前、プリンタの名前、物理出力メディアのファイル名またはデバイス名などの初期化データ）を指定してＣｒｅａｔｅＤＣ関数を呼び出す。印刷が終わったら、ＤｅｌｅｔｅＤＣ関数を呼び出してプリンタ・デバイスコンテキストを削除する。

デバイスコンテキストに対する操作には、既存のグラフィック・オブジェクトの列挙、新しいグラフィック・オブジェクトの選択、既存のグラフィック・オブジェクトの削除、現在のグラフィック・オブジェクトとその属性、グラフィックモードの保存、以前に保存した現在のグラフィック・オブジェクトとその属性およびグラフィックモードの復元、がある。さらに、デバイスコンテキストを使って、グラフィック出力の変更方法の判断、（マルチスレッドアプリケーションのスレッドで開始した）時間のかかる描画操作の取り消し、プリンタの特定の状態へのリセットなどを行うことができる。

さらに、グラフィック・オブジェクトについても説明する。グラフィック・オブジェクトには、線描画用のペン塗りつぶし用のブラシ、利用可能な色のセットを定義するブラシ、画面のコピーやスクロールで使われるビットマップ、クリッピングなどの操作で使われるリージョン、描画操作で使われるパスなどがある。多くのＷｉｎ３２構造体とは異なり、アプリケーション１１１はデバイスコンテキストを直接アクセスすることはなく、さまざまな関数を呼び出して間接的に構造体を操作する。

デバイスコンテキストに関連付けられているペン、ビットマップ、ブラシ、パレット、リージョン、パスは、デバイスコンテキストのグラフィック・オブジェクトと呼ばれる。アプリケーション１１１がデバイスコンテキストを作成すると、ＷＩＮＤＯＷＳ（登録商標）は、デフォルトのオブジェクトをそのデバイスコンテキストに自動的に作成する。

ディスプレイ・デバイスコンテキストやプリンタ・デバイスコンテキストを作成したら、対応するデバイスへの描画を開始できる。このとき、デフォルトオブジェクトが選択されている。しかし、デフォルトオブジェクトを置き換えなければならないときがあり、この場合、作成関数を使って新しいオブジェクトに置き換える。

印刷スプーラ２１２は、印刷処理を管理するＷＩＮＤＯＷＳ（登録商標）実行可能ファイルである。印刷処理には、適切なデバイスドライバ２１１の位置の取得、デバイスドライバ２１１のロード、高レベル関数呼び出しからジャーナルレコードへの変換、ジャーナルレコードのディスク上の印刷ジョブとしての格納などがある。印刷スプーラ２１２は起動時にロードされ、ＯＳ１１２がシャットダウンするまで動作し続ける。

印刷スプーラ２１２は、プリンタＤＣ（デバイスコンテキスト）を作成する。アプリケーション１１１がプリンタＤＣを作成すると、印刷スプーラ２１２は、必要なデバイスドライバ２１１の特定やメモリへのロードなど、必要な作業を実行する。また、印刷スプーラ２１２は、印刷ジョブの記録に使われるデータ型を判断する。サポートされているデータ型には、ジャーナルレコード、ＡＳＣＩＩテキスト、ＰｏｓｔＳｃｒｉｐｔがある。

印刷ジョブは、（サポートされているデータ型のいずれかで）内部的に格納される文書で、出力ページを含む。印刷ジョブは、複数のページで構成される場合もある。たとえば、封筒１つとＡ４用紙３枚で構成される。印刷ジョブは、ＳｔａｒｔＤｏｃとＥｎｄＤｏｃの２つの関数で囲まれる。

印刷ジョブのデフォルトのデータ型はジャーナルレコードである。ジャーナルレコードとは、テキスト出力コマンドやラスタグラフィックコマンドなどを格納するのに使われる小さなデータ構造体である。アプリケーション１１１がＳｔａｒｔＤｏｃ関数を呼び出すと、印刷スプーラ２１２は、ジャーナルファイルとデータファイルを作成し、ジャーナルファイルにジャーナルレコードを格納し始める。

アプリケーション１１１がＧＤＩ描画関数を１つ呼び出すごとに、新しいジャーナルレコードが１つ以上作成され、ジャーナルファイルに格納される。ジャーナルファイルとデータファイルは、ＯＳ１１２のディレクトリに作成される。印刷スプーラ２１２は、ジャーナルファイルにジャーナルレコードを格納し、用紙の種類や印刷ジョブのデータ型、出力先プリンタなどをデータファイルに記録する。ジョブが正常に印刷されると、スプーラはこの２つのファイルを削除する。

次に、印刷プロセッサ２１３について説明する。印刷プロセッサ２１３は、印刷スプーラ２１２が現在の印刷ジョブと出力先プリンタを監視して、ジョブを印刷する時期を判断し、ジョブを印刷すべきだと判断したときに呼び出される。なお印刷プロセッサ２１３は、ジャーナルレコードを読み取ってＤＤＩ呼び出しに変換するＷＩＮＤＯＷＳ（登録商標）ＤＬＬである。

次に、グラフィックエンジン２１４について説明する。グラフィックエンジン２１４は、印刷プロセッサ２１３の出力を、デバイスドライバ２１１の関数呼び出しに変換する。デバイスドライバ２１１は、この呼び出しを処理して、デバイスが処理できる低レベルのデバイスコマンドに変換する。グラフィックエンジン２１４は、印刷プロセッサ２１３の出力をデバイスドライバ関数の呼び出しに変換するＷＩＮＤＯＷＳ（登録商標）ＤＬＬである。プリンタは、低レベルのデバイスコマンドを処理してイメージを印刷する。デバイスコマンドの構文、個数、種類は、デバイスによって異なる。

次に、モニタ２１５について説明する。デバイスドライバ２１１がジャーナルファイル全体を低レベルのデバイスコマンドに変換すると、変換されたコマンドのファイルが印刷スプーラ２１２に渡される。印刷スプーラ２１２は、この低レベルのコマンドをモニタ２１５に送る。モニタ２１５とは、ネットワークやパラレルポート、シリアルポートなどを通じてデバイスに低レベルのデバイスコマンドを渡すＷＩＮＤＯＷＳ（登録商標）ＤＬＬである。

図３は、電子文書ファイルへの変換指示を行うときのユーザインターフェースの画面を示した図である。このユーザインターフェースの画面は、クライアント１１０、１２０の画面において表示される。図３で示すように、出力指示は、通常プリンタに対して行うものと同じである。出力先３０１により、プリンタで印刷を行うのか、または出力先を変換サーバにするのかが特定される。出力先３０１に出力する場合はＯＫ３０２をクリックすると出力のための処理が行われ、キャンセル３０３がクリックされるとキャンセルになる。

電子文書ファイルの出力に関しては、あらかじめ設定しておくことができる。例えば、出力パスをプロパティの画面から指定しておくことができる。出力先のパスは、あらかじめデフォルトで設定されている。たとえば、￥￥ｋｉｓｓｖ０３￥ＰＤＦｏｕｔというフォルダを出力先のパスとして設定しておくことができる。

これに対して、出力先のパスを変更することができる。出力先のパスの変更は、クライアント１１０、１２０上で行われる。出力先のパスの変更は次の方法がある。（１）あらかじめ用意されているラジオボタンを選択する。ラジオボタンにより指定される出力先は、サーバ自身、ユーザのコンピュータ、フレキシブルディスクドライブやＭＯディスクドライブが用意されている。（２）パス名をユーザ自身で入力する。このとき、すべての文字列をユーザ入力で受け付けることができるが、フォルダの参照ダイアログからフォルダを１つ選択するようにすることもできる。

なお、この出力先のパスの設定画面において、電子文書ファイルの保存結果のメッセージを、クライアント端末の画面に表示するか否かを設定することができる。この設定はチェックボックスにより指定することができ、指定されている場合は変換・保存に成功したことが表示され、指定されていない場合は表示されない。またエラーが発生した場合は、どちらが指定されていても表示される。

例えば出力先としてリムーバブルディスクが指定されている場合に、そのリムーバブルディスクの容量が十分でない場合、保存できないので保存できない旨が表示される。なお容量が十分でない場合は、変換サーバ１３０は、データスプーラ１３１に保存しておいた上でクライアント端末に保存先を再度指示させる。そして保存先が指示を受け取りその保存先が保存を行ってから、再度クライアント端末に保存が成功したことを通知する。指定の保存先への保存が成功したら、内部の一時フォルダ内に一時記憶していた電子文書ファイルは消去する。

図４は、変換サーバ１３０の構成を示すブロック図である。変換サーバ１３０は、変換依頼受信部４１０と変換データ管理部４２０、データスプーラ１３１、パラメータ管理部４４０、データ変換部１３２、出力部４６０を具備して構成される。なお、これらの各部は、実際には、コンピュータ装置を構成するハードウェアおよびソフトウェアにより構成される。データスプーラ１３１とパラメータ管理部４４０は、いずれもハードディスク装置等の記憶装置により構成されるが、これらは、物理的には１つの記憶装置で構成され、論理的に別の構成部として利用することが可能である。また、パラメータ管理部４４０をデータスプーラ１３１の一部に含めるように構成することもできる。

変換依頼受信部４１０は、クライアント１１０または１２０からの、ＥＭＦファイル１１３を受信する。つまり、ＥＭＦファイル１１３を受信するネットワークのインターフェース部として動作する。

変換データ管理部４２０は、変換依頼受信部４１０が受け付けたＥＭＦファイル１１３をデータスプーラ１３１に蓄え、変換時のパラメータをパラメータ管理部４４０に蓄える。変換時のパラメータには、出力先のパスも含む。変換データ管理部４２０は、受信されたＥＭＦファイル１１３のヘッダ部を読み、出力先のパスがどこになるのかを判定する。判定された出力先のパスは、変換時のパラメータとして、パラメータ管理部４４０に蓄えられる。

また変換データ管理部４２０は、変換されたデータの保存に成功したか否かについての状態の管理も行い、保存に成功した場合、または保存に成功しなかった場合に、その旨をクライアント１１０、１２０に通知する。変換データ管理部４２０は、出力部４６０での保存に成功しなかった場合、クライアント１１０、１２０への通知に応答する再度の保存指示を受けて、出力部４６０に再度の保存処理を行うように指示する。この再度の保存処理とは、たとえばエラーが発生した場合、そのエラーの要因を除去した後で、再度同じ保存先に保存することができる。一方、別の保存先を指定して保存することもできる。

データスプーラ１３１は、ＥＭＦファイル１１３を記憶する。データスプーラ１３１は、ＥＭＦファイル１１３を、受け取った順に変換ジョブとしてキューの形で記憶しておく。先に受け取った変換ジョブが先の順位になり、後に受け取った変換ジョブは後に処理されるように後の順位となる。なおクライアントごと、アプリケーションごとに優先順位を設定しておき、優先順位の高い変換ジョブを先の順位にするように変えるようにすることもできる。

またデータスプーラ１３１は、データ変換部１３２で変換された電子文書ファイルの保存も行う。電子文書ファイルが出力部４６０から出力されたら、データスプーラ１３１内に保存されていた電子文書ファイルは消去される。ただし上述の、保存に成功しなかった場合でクライアント１１０、１２０からの指示を待つ場合、変換された電子文書ファイルは、再度の出力部４６０からの出力を行うまでデータスプーラ１３１に保存しておく。

パラメータ管理部４４０は、変換時のパラメータを蓄える。データスプーラ１３１に蓄えられるＥＭＦファイル１１３と、パラメータ管理部４４０に蓄えられるパラメータは、変換データ管理部４２０により関連付けられて蓄えられる。

データ変換部１３２は、データスプーラ１３１に蓄えられている、処理の順番が回ってきたＥＭＦファイル１１３を電子文書ファイルに変換するために、パラメータ管理部４４０に蓄えられているパラメータ等を参照して、電子文書ファイルへと変換を行う。変換された電子文書ファイルは、データスプーラ１３１に戻す。

出力部４６０は、データスプーラ１３１に蓄えられている変換済みのデータ（電子文書ファイル）を指定されたパスに出力する。パスの指定先は、フレキシブルディスクドライブでもよく、またＭＯドライブ、クライアント１１０または１２０内のディレクトリ、もしくは変換サーバ１３０自身のディレクトリを指定することもできる。出力にあたって出力部４６０は、生成された電子文書ファイルを、パスで指定された出力先に応じたデータ形式で出力を行う。

図５は、変換サーバ１３０を複数の仮想変換サーバとした場合を示すブロック図である。変換サーバ１３０は、仮想変換サーバ５１０〜５３０の３つにより構成されるものとして示しているが、２つであっても、４つ以上であってもよい。仮想変換サーバ５１０〜５３０の構造は、図４で説明した変換サーバと同じであるので、図４を参照しながら説明する。

仮想変換サーバ５１０〜５３０は、仮想的に複数の装置として動作するが、単一の変換サーバ１３０内で動作するので、共通のハード的ソフト的な資源を利用した、並行処理の形で動作することになる。このように共通の資源を利用するのであるが、外部に対しては複数の変換装置として動作し、クライアント１１０、１２０からは別個の装置として変換要求が出される。

例えば仮想変換サーバ５１０にＥＭＦファイル１１３が送られた場合、仮想変換サーバ５１０に対応する、変換依頼受信部４１０がＥＭＦファイル１１３を受信し、仮想変換サーバ５１０に対応する、データスプーラ１３１に順次ＥＭＦファイル１１３が蓄積されて、変換処理がなされていく。ただし上述のように仮想変換サーバ５１０は、単独で変換サーバ１３０の資源を占有するのではなく、仮想変換サーバ５２０および５３０と共有する形で、並行処理することにより上記動作を実行する。

なお、変換依頼受信部４１０は、仮想変換サーバ５１０〜５３０にそれぞれ対応付けるのではなく、共通の変換依頼受信部４１０とすることができる。この場合共通の変換依頼受信部４１０は、ＥＭＦファイル１１３を受信した場合、仮想変換サーバ５１０〜５３０のそれぞれに対応する変換データ管理部４２０にＥＭＦファイル１１３を送り、処理を行う構成になる。

図６は、電子文書ファイルの構成を示すブロック図である。電子文書ファイルは以下の４つのブロックにより構成される。第１の構成要素はオブジェクト６０１であり、オブジェクト６０１を表現するための基本オブジェクト型の集合である。これらの型は、少数の例外を除き、ＰｏｓｔＳｃｒｉｐｔ言語で使用するデータ型に対応する。第２の構成要素は、ファイル構造６０２である。ファイル構造６０２は、電子文書ファイルでオブジェクト６０１が格納される方法、アクセスされる方法および更新される方法を決定する。この構造は、オブジェクト６０１のセマンティクスとは独立とする。

第３の構成要素は、文書構造６０３である。文書構造６０３は、ページ、注記、ハイパテキストリンク、フォントなどの電子文書の構成要素を表現するために、基本オブジェクト型が使用される方法を規定する。第４の構成要素は、ページ記述６０４である。電子文書のページ記述６０４は、電子文書のページオブジェクトの一部だが、他の構成要素とは独立に示すことができる。電子文書のページ記述６０４は、電子文書の他の部分とは限られた相互作用だけをもつ。

以上の電子文書ファイルについて、さらに詳細に説明を行う。電子文書ファイルでは、最初にファイル情報が指定され、それから図形情報やテキスト情報などの文書データが記述される。図形は、四角なら四角であることを指定する命令と、開始点や終了点などの引数の組み合わせで記述される。テキストの場合、種類やサイズなどのフォントの情報の指定と、実際に出力するテキストにより記述される。

電子文書ファイルのフォーマットとして、ＰＤＦが挙げられる。ＰＤＦでは、Ａｄｏｂｅ（登録商標）作画モデルを使って、テキストおよびグラフィックスを表現する。これは、ＰｏｓｔＳｃｒｉｐｔ（登録商標）言語で使用される作画モデルと同じものである。ＰｏｓｔＳｃｒｉｐｔ言語（登録商標）プログラムと同様に、ＰＤＦのページ記述は、選択された領域に、ペイント（ｐａｉｎｔ）を配置することによって、ページを描画する。

ペイントされた図は、字の形状、直線および曲線の組合せによって定義された領域、又はデジタル的に取り込まれた写真表現などの取込み画像でもよい。ペイントは、いかなるカラーでもよい。いかなる図も、他の形状にクリップできる。こうすることで、その図の、その形状の内側だけがページ上に現れる。ページ記述が開始する時には、そのページは、完全に空白となる。そのページ記述における様々な演算子が、ページ上にマークを配置する。ページ上に置かれた各々の新しいマークは、そのマークが覆うかもしれないマークを完全に見えなくする。

ＰＤＦページマーク付け演算子は、ＰｏｓｔＳｃｒｉｐｔ言語のマーク付け演算子と類似している。ＰＤＦマーク付け演算子がＰｏｓｔＳｃｒｉｐｔ言語と異なる主たる理由は、ＰＤＦはプログラミング言語ではなく、手続き処理、変数又は制御構造をもたないことにある。ＰＤＦは、柔軟性に劣るが、その代わりに効率性を改善している。典型的なＰｏｓｔＳｃｒｉｐｔ言語プログラムは、ＰｏｓｔＳｃｒｉｐｔ言語のマーク付け演算子を使って、高水準な演算子の集合を定義する。

ＰＤＦは、大部分のページを記述するのに十分な高水準演算子の独自の集合を定義する。これらの演算子は、ＰｏｓｔＳｃｒｉｐｔ言語コードではなく機械語で直接に実装されているので、ＰＤＦのページ記述は、よりすばやく描画できる。ＰＤＦでは、任意のプログラム要素は許されないので、アプリケーションは、より効率的により信頼性が高く、ＰＤＦ文書でのテキスト列の配置が可能となる。電子文書ファイルは、バイナリファイルとする。すなわち、文字の８ビット範囲全体を使用する。

電子文書ファイルで用いられる圧縮形式について説明する。電子文書ファイルは、次の圧縮フィルタをサポートする。
（１）カラーおよびグレースケールの画像のＪＰＥＧ圧縮
（２）モノクローム画像の、ＣＣＩＴＴグループ３、ＣＣＩＴＴグループ４、ＬＺＷ（Ｌｅｍｐｅｌ−Ｚｉｖ−Ｗｅｌｃｈ）およびランレングス圧縮
（３）テキスト、グラフィクスおよびインデクス付き画像データのＬＺＷおよびＦｌａｔｅの圧縮

ＪＰＥＧ圧縮を使うことにより、カラーおよびグレースケールの画像を１０倍以上圧縮できる。モノクローム画像の効率的な圧縮は、使用する圧縮フィルタおよび画像の特性に依存するが、通常は、２：１〜８：１に圧縮される。文書のバランスが取られた、テキストおよびグラフィクスのＬＺＷ又はＦｌａｔｅの圧縮は、およそ２：１の圧縮率となる。

上述の電子文書の例であるＰＤＦは、ＰｏｓｔＳｃｒｉｐｔ言語と同じ作画モデルをもつ一方で、次の点で異なる。電子文書ファイルは、対話的閲覧にだけ有用なハイパリンクなどのオブジェクトを含む。ページ記述の処理を簡素化したため、ＰＤＦはプログラム言語構造を提供しない。ＰＤＦは、アプリケーションが文書の部分をランダムにアクセスできる、厳密に定義されたファイル構造を強化している。電子文書ファイルは、フォントメトリクスなどのビューの忠実性を確実にする情報を含む。

図７は、本実施形態のクライアント側の処理を示すフローチャートである。本処理においては、図２を参照しながら説明する。

まず、アプリケーション１１１において、文書データが作成される。文書データを作成するソフトウェアはワープロ２０１、表計算２０２など、さまざまなものが考えられる。文書データを作成したところで、文書データを作成したアプリケーション１１１上のツールバーから、印刷の欄が指示され、そこでの指定により変換指示される（ステップＳ７０１）ことにより、処理が開始される。

次に、アプリケーション１１１で作成された文書データはＯＳ１１２に渡されるとともに、変換サーバ１３０についてのクライアント１１０上での設定事項の読み込みを行う（ステップＳ７０２）。設定事項については、図３の説明に関連して行ったように、出力先のパスが含まれる。また、ＩＰアドレスなどの、変換サーバ１３０自身についての情報もこの設定事項には含まれる。

次に、ＯＳ１１２上で送信するＥＭＦファイル１１３を作成する（ステップＳ７０３）。ＥＭＦファイル１１３の作成にあたり、ＯＳ１１２上では主としてデバイスドライバ２１１が処理を行うが、その他の各機能とも連携して処理を行う。詳細は上述した通りである。

ＥＭＦファイル１１３が作成されたら、ＯＳ１１２は、変換サーバ１３０に対してＥＭＦファイルを送信する（ステップＳ７０４）。ＥＭＦファイル１１３に送信することにより、処理は変換サーバ１３０に渡されるが、その結果無事変換処理を行い、保存を行うことができたか、もしくはエラーが発生したかの通知が行われ、これに対して処理を行うことになる。ステップＳ７０５以降は以上の処理を説明している。

次に、変換サーバ１３０からエラー通知が行われたかどうかが判定される（ステップＳ７０５）。エラー通知がない場合は（ステップＳ７０５：Ｎｏ）、終了通知がなされたかどうかが判定される（ステップＳ７０６）。終了通知がなされた場合は（ステップＳ７０６：Ｙｅｓ）、変換が終了し電子文書ファイルが無事保存されたことをディスプレイ上に表示し（ステップＳ７０７）、処理を終了する。

エラー通知がなされた場合は（ステップＳ７０５：Ｙｅｓ）、再度の保存要求の受付を行い、保存要求が行われたかどうかを判定する（ステップＳ７０８）。たとえば保存先のメモリ容量が足りない場合であれば、保存する媒体のデータを消したり、媒体そのものを入れ替えたりすればよい。または出力先のパスを、例えばフレキシブルディスクを指定していたのを、変換サーバ１３０内のフォルダにしておけば問題は解消する。従ってこうした処理を行ってから保存要求を行えばよい。

保存要求が行われた場合は（ステップＳ７０８：Ｙｅｓ）、再度保存を行う旨の要求を変換サーバ１３０に対して送信し（ステップＳ７０９）、変換サーバ１３０に処理を渡す。そしてステップＳ７０５に戻る。

保存要求が行われなかった場合は（ステップＳ７０８：Ｎｏ）、保存処理そのものが不要な場合がある。従って処理の終了が指示されたか否かを判定する（ステップＳ７１０）。処理の終了が指示された場合は（ステップＳ７１０：Ｙｅｓ）、処理を終了する。処理の終了が指示されなかった場合は（ステップＳ７１０：Ｎｏ）、ステップＳ７０８に戻り、保存要求の受付を行う。

図８は、本発明の変換サーバ側の処理を示すフローチャートである。本処理においては、図４を参照しながら説明する。変換依頼受信部４１０がＥＭＦファイル１１３を受信する（ステップＳ８０１）ことにより処理が開始する。

ＥＭＦファイル１１３は、変換データ管理部４２０を介してデータスプーラ１３１に記憶される（ステップＳ８０２）。データスプーラ１３１は、ＥＭＦファイル１１３を受け取った順に記憶し、受け取った順に出力できるようにするが、優先順位が高く設定されているＥＭＦファイル１１３は、変換データ管理部４２０が区別することにより、優先して処理すべき順番として記憶する。

次に、変換データ管理部４２０は、次の順番のＥＭＦファイル１１３に対する変換の順番が来たかを判定し（ステップＳ８０３）、順番が来るまで待機する。順番が来たと判定された場合（ステップＳ８０３：Ｙｅｓ）、データ変換部１３２は、データスプーラ１３１に記憶される、次の順番のＥＭＦファイル１１３の変換処理を実行する（ステップＳ８０４）。これにより電子文書ファイルが作成される。

作成された電子文書ファイルは、指定されたパスに出力される（ステップＳ８０５）。出力先は上述のように、外部の媒体であっても、変換サーバ１３０自身であっても、クライアント１１０であってもよい。次に指定されたパスへの出力が成功したかどうかが判定される（ステップＳ８０６）。出力が成功した場合（ステップＳ８０６：Ｙｅｓ）、媒体への出力が成功したことを出力結果としてクライアント１１０に通知し（ステップＳ８０７）、処理を終了する。

出力が失敗した場合（ステップＳ８０６：Ｎｏ）、出力が失敗した旨をクライアント１１０に通知する（ステップＳ８０８）。そしてクライアント１１０からの指示を待ち、再出力指示が行われたかどうかを判定する（ステップＳ８０９）。再出力指示が行われた場合（ステップＳ８０９：Ｙｅｓ）、ステップＳ８０５に戻って再度の出力処理を行う。再出力指示がなかった場合は（ステップＳ８０９：Ｎｏ）、処理そのものの終了指示が行われたか否かを判定する（ステップＳ８１０）。終了指示が行われていた場合は（ステップＳ８１０：Ｙｅｓ）処理を終了し、終了指示が行われていない場合は（ステップＳ８１０：Ｎｏ）ステップＳ８０９に戻ってクライアント１１０からの指示を待つ。

図９は、本発明の実施形態にかかる変換処理の詳細を示すフローチャートである。図８のステップＳ８０４で変換処理の実行を行うときの処理内容をここで説明する。次の処理はフローチャートで示される順に説明するが、処理の順番は入れ替えても同時並行で行ってもよい。処理の順番は、以下の処理を行うことを説明するために、便宜的に順番に並べたものに過ぎない。作成されるデータは図６で示されるものであるので、図６を参照して説明する。

まず、受信したＥＭＦファイル１１３に基づいて、オブジェクト６０１を作成する（ステップＳ９０１）。オブジェクト６０１は、文字や図形の実際のデータであるので、ＥＭＦファイル１１３中の該当する箇所を参照しながらこれに基づいてオブジェクト６０１を作成する。

次に、受信したＥＭＦファイル１１３に基づいて、ファイル構造６０２を作成する（ステップＳ９０２）。ファイル構造６０２は、オブジェクト６０１との関連に基づいて作成される。次に、受信したＥＭＦファイル１１３に基づいて、文書構造６０３を作成する（ステップＳ９０３）。文書構造６０３は、オブジェクト６０１との関連に基づいて作成される。次に、受信したＥＭＦファイル１１３に基づいて、ページ記述６０４を作成する（ステップＳ９０４）。ページ記述６０４は、ページオブジェクトの一部ではあるが、他の構成要素とは独立した形で作成される。

次に、オブジェクト６０１の圧縮を行い、圧縮方法についての記述を作成する（ステップＳ９０５）。用いられる圧縮形式については上述の通りである。そしてクライアント１１０の情報に基づいて、アクセス制限情報を作成する（ステップＳ９０６）。アクセス制限情報は、予め設定されたパスワードとすることができ、パスワードの入力によらなければデータへのアクセスができないような構造にすることができる。またアクセス制限情報は、ＥＭＦファイル１１３中に含まれる他のデータに基づいて作成することもできる。

以上のように、ユーザはサーバに対してデバイスドライバで作成できるデータをサーバに送ることで処理することができるので、アプリケーションから直接に、プリンタでの印刷処理を指示するような簡単な操作で電子文書ファイルへの変換処理を指示することができる。

つまり、デバイスドライバにより作成された印刷用データを受け取ることにより、電子文書ファイルへの変換処理を行うことができるので、サーバにデータを送るためのソフトウェアを、改めてクライアント端末に組み込むことなく、サーバ装置にのみソフトウェアを組み込むことにより、クライアント端末から変換のためのデータを受け取り、スムーズに変換のための処理に移行することができる。

また、ファイル変換装置側での電子文書ファイルへの変換処理は、通常のプリンタの印刷処理と同様の手順で行われるので、処理の状況に合わせてユーザに対してリアルタイムな処理状況を知らせることができる。例えば、電子文書ファイルの出力メディアが容量不足であるなどのエラーが発生するような場合でも、エラー発生をクライアント側に知らせることができ、またジョブ待ち状態などを知ることもできる。

この発明は、アプリケーションなどで作成された文書データを、ＰＤＦなどの電子文書ファイルに変換するファイル変換装置、ファイル変換方法およびファイル変換プログラムにおいて有用である。

本発明の実施の形態が適用されるネットワークの構成を示す図である。クライアントのソフトウェア上の構成を示すブロック図である。電子文書ファイルへの変換指示を行うときのユーザインターフェースの画面を示す図である。変換サーバの構成を示すブロック図である。変換サーバを複数の仮想変換サーバとした場合を示すブロック図である。電子文書ファイルの構成を示すブロック図である。本実施形態のクライアント側の処理を示すフローチャートである。本発明の変換サーバ側の処理を示すフローチャートである。本発明の実施の形態にかかる変換処理の詳細を示すフローチャートである。

符号の説明

１１０、１２０クライアント
１１１、１２１アプリケーション
１１３ＥＭＦファイル
１３０変換サーバ
１３１データスプーラ
１３２データ変換部
１３３電子文書ファイル
２１１デバイスドライバ
２１２印刷スプーラ
２１３印刷プロセッサ
２１４グラフィックエンジン
２１５モニタ
４１０変換依頼受信部
４２０変換データ管理部
４３０データスプーラ
４４０パラメータ管理部
４６０出力部
５１０〜５３０仮想変換サーバ

Claims

外部端末のアプリケーションにより入力された出力指示に応答して、前記外部端末のデバイスドライバにより作成され出力先情報を含む印刷用データを受信する受信手段と、
前記印刷用データを、グラフィックスおよびテキストのオブジェクトの圧縮データで記述された電子文書ファイルに変換する変換手段と、
前記変換手段により変換された電子文書ファイルを、前記出力先情報により指定される出力先に出力する出力手段と、
を備えることを特徴とするファイル変換装置。
前記変換手段は、
前記印刷用データに基づいてグラフィックスおよびテキストのオブジェクトの圧縮データにより構成されるオブジェクト情報を作成するオブジェクト作成手段と、
前記印刷用データに基づいて、出力する電子文書ファイルのファイル構造および文章構造を記述する構造データを作成する構造データ作成手段と、
前記オブジェクト情報および構造データを含む電子文書ファイルを作成するファイル作成手段と、
を備えることを特徴とする請求項１に記載のファイル変換装置。
前記電子文書ファイルの閲覧者を制限するためのアクセス制限情報を検出する検出手段をさらに備え、
前記変換手段は、前記印刷用データを、前記アクセス制限情報に基づいてアクセス制限された電子文書ファイルに変換することを特徴とする請求項１または２に記載のファイル変換装置。
前記受信手段で受信された印刷用データに基づいて出力先のパスを判定する判定手段をさらに備え、
前記出力手段は、前記変換手段により変換された電子文書ファイルを、前記判定手段で判定された出力先のパスに出力することを特徴とする請求項１〜３のいずれか一つに記載のファイル変換装置。
前記出力先情報で指定される出力先媒体の記録容量の不足を検出する容量検出手段と、
前記容量検出手段が記録容量の不足を検出する場合、前記外部端末のアプリケーションに通知を行う通知手段と、
をさらに備えることを特徴とする請求項１〜４のいずれか一つに記載のファイル変換装置。
前記容量検出手段が記録容量の不足を検出する場合、前記変換手段で変換された電子文書ファイルを記憶する一時記憶手段と、
前記通知手段による通知に応答して前記外部端末から送られた再保存要求に基づいて、前記一時記憶手段に記憶された電子文書ファイルを、前記再保存要求で指定された出力先に保存する再保存手段と、
を備えることを特徴とする請求項５に記載のファイル変換装置。
前記再保存手段が前記電子文書ファイルの保存を行った場合、前記一時記憶手段に記憶されたデータを消去することを特徴とする請求項６に記載のファイル変換装置。
出力先のパスを設定する設定手段をさらに備え、前記出力手段は、前記設定手段により設定された出力先のパスを、前記出力先情報が指定する出力先であることを特徴とする請求項１〜７のいずれか一つに記載のファイル変換装置。
前記出力手段は、前記出力先情報が前記電子文書ファイルの出力先を指定しない場合、前記設定手段により設定された出力先のパスを、前記出力先情報が指定する出力先とすることを特徴とする請求項８に記載のファイル変換装置。
前記印刷用データを変換処理の順番に記憶する記憶手段をさらに備え、
前記変換手段は、前記記憶手段に記憶される順番で前記印刷用データの変換を行うことを特徴とする請求項１〜９のいずれか一つに記載のファイル変換装置。
前記記憶手段は複数の記憶部により構成され、
前記変換手段は、前記複数の記憶部のそれぞれに対応した複数の変換部により構成され、
前記記憶部と前記変換部を１つの組とした仮想変換部が、複数で並行動作することを特徴とする請求項１０に記載のファイル変換装置。
前記印刷用データに含まれる指定情報に基づいて、前記印刷用データの変換を行う仮想変換部を指定する指定手段と、
前記指定手段で指定される仮想変換部に前記印刷用データの変換を行わせる制御手段と、
をさらに備えることを特徴とする請求項１１に記載のファイル変換装置。
外部端末のアプリケーションにより入力された出力指示に応答して、前記外部端末のデバイスドライバにより作成され出力先情報を含む印刷用データを受信する受信工程と、
前記印刷用データを、グラフィックスおよびテキストのオブジェクトの圧縮データで記述された電子文書ファイルに変換する変換工程と、
前記変換工程により変換された電子文書ファイルを、前記出力先情報により指定される出力先に出力する出力工程と、
を含むことを特徴とするファイル変換方法。
前記変換工程は、
前記印刷用データに基づいてグラフィックスおよびテキストのオブジェクトの圧縮データにより構成されるオブジェクト情報を作成するオブジェクト作成工程と、
前記印刷用データに基づいて、出力する電子文書ファイルのファイル構造および文章構造を記述する構造データを作成する構造データ作成工程と、
前記オブジェクト情報および構造データを含む電子文書ファイルを作成するファイル作成工程と、
を含むことを特徴とする請求項１３に記載のファイル変換方法。
前記電子文書ファイルの閲覧者を制限するためのアクセス制限情報を検出する検出工程をさらに含み、
前記変換工程は、前記印刷用データを、前記アクセス制限情報に基づいてアクセス制限された電子文書ファイルに変換することを特徴とする請求項１３または１４に記載のファイル変換方法。
前記受信工程で受信された印刷用データに基づいて出力先のパスを判定する判定工程をさらに含み、
前記出力工程は、前記変換工程により変換された電子文書ファイルを、前記判定工程で判定された出力先のパスに出力することを特徴とする請求項１３〜１５のいずれか一つに記載のファイル変換方法。
前記出力先情報で指定される出力先媒体の記録容量の不足を検出する容量検出工程と、
前記容量検出工程が記録容量の不足を検出する場合、前記外部端末のアプリケーションに通知を行う通知工程と、
をさらに含むことを特徴とする請求項１３〜１６のいずれか一つに記載のファイル変換方法。
前記容量検出工程が記録容量の不足を検出する場合、前記変換工程で変換された電子文書ファイルを記憶する一時記憶工程と、
前記通知工程による通知に応答して前記外部端末から送られた再保存要求に基づいて、前記一時記憶工程に記憶された電子文書ファイルを、前記再保存要求で指定された出力先に保存する再保存工程と、
を含むことを特徴とする請求項１７に記載のファイル変換方法。
前記再保存工程が前記電子文書ファイルの保存を行った場合、前記一時記憶工程に記憶されたデータを消去することを特徴とする請求項１８に記載のファイル変換方法。
出力先のパスを設定する設定工程をさらに含み、前記出力工程は、前記設定工程により設定された出力先のパスを、前記出力先情報が指定する出力先であることを特徴とする請求項１３〜１９のいずれか一つに記載のファイル変換方法。
前記出力工程は、前記出力先情報が前記電子文書ファイルの出力先を指定しない場合に、前記設定工程により設定された出力先のパスを、前記出力先情報が指定する出力先とすることを特徴とする請求項２０に記載のファイル変換方法。
前記印刷用データを変換処理の順番に記憶する記憶工程をさらに含み、
前記変換工程は、前記記憶工程に記憶される順番で前記印刷用データの変換を行うことを特徴とする請求項１３〜２１のいずれか一つに記載のファイル変換方法。
前記記憶工程は複数の記憶部への記憶を行い、
前記変換工程は、前記複数の記憶部のそれぞれに対応した複数の変換部への変換を行い、
前記記憶部と前記変換部を１つの組とした仮想変換部を、複数で並行動作させることを特徴とする請求項２２に記載のファイル変換方法。
前記印刷用データに含まれる指定情報に基づいて、前記印刷用データの変換を行う仮想変換部を指定する指定工程と、
前記指定工程で指定される仮想変換部に前記印刷用データの変換を行わせる制御工程と、
をさらに含むことを特徴とする請求項２３に記載のファイル変換方法。
外部端末のアプリケーションにより入力された出力指示に応答して、前記外部端末のデバイスドライバにより作成され出力先情報を含む印刷用データを受信させる受信工程と、
前記印刷用データを、グラフィックスおよびテキストのオブジェクトの圧縮データで記述された電子文書ファイルに変換させる変換工程と、
前記変換工程により変換された電子文書ファイルを、前記出力先情報により指定される出力先に出力させる出力工程と、
をコンピュータに実行させることを特徴とするファイル変換プログラム。
前記変換工程は、
前記印刷用データに基づいてグラフィックスおよびテキストのオブジェクトの圧縮データにより構成されるオブジェクト情報を作成させるオブジェクト作成工程と、
前記印刷用データに基づいて、出力する電子文書ファイルのファイル構造および文章構造を記述する構造データを作成させる構造データ作成工程と、
前記オブジェクト情報および構造データを含む電子文書ファイルを作成させるファイル作成工程と、
を含むことを特徴とする請求項２５に記載のファイル変換プログラム。
前記電子文書ファイルの閲覧者を制限するためのアクセス制限情報を検出させる検出工程をさらに含み、
前記変換工程は、前記印刷用データを、前記アクセス制限情報に基づいてアクセス制限された電子文書ファイルに変換させることを特徴とする請求項２５または２６に記載のファイル変換プログラム。
前記受信工程で受信された印刷用データに基づいて出力先のパスを判定させる判定工程をさらに含み、
前記出力工程は、前記変換工程により変換された電子文書ファイルを、前記判定工程で判定された出力先のパスに出力させることを特徴とする請求項２５〜２７のいずれか一つに記載のファイル変換プログラム。
前記出力先情報で指定される出力先媒体の記録容量の不足を検出させる容量検出工程と、
前記容量検出工程が記録容量の不足を検出させる場合、前記外部端末のアプリケーションに通知させる通知工程と、
をさらに含むことを特徴とする請求項２５〜２８のいずれか一つに記載のファイル変換プログラム。
前記容量検出工程が記録容量の不足を検出する場合、前記変換工程で変換された電子文書ファイルを記憶させる一時記憶工程と、
前記通知工程による通知に応答して前記外部端末から送られた再保存要求に基づいて、前記一時記憶工程に記憶された電子文書ファイルを、前記再保存要求で指定された出力先に保存させる再保存工程と、
を含むことを特徴とする請求項２９に記載のファイル変換プログラム。
前記再保存工程が前記電子文書ファイルを保存させた場合、前記一時記憶工程に記憶されたデータを消去させることを特徴とする請求項３０に記載のファイル変換プログラム。
出力先のパスを設定させる設定工程をさらに含み、前記出力工程は、前記設定工程により設定された出力先のパスを、前記出力先情報が指定する出力先であることを特徴とする請求項２５〜３１のいずれか一つに記載のファイル変換プログラム。
前記出力工程は、前記出力先情報が前記電子文書ファイルの出力先を指定しない場合に、前記設定工程により設定された出力先のパスを、前記出力先情報が指定する出力先とすることを特徴とする請求項３２に記載のファイル変換プログラム。
前記印刷用データを変換処理の順番に記憶させる記憶工程をさらに含み、
前記変換工程は、前記記憶工程に記憶される順番で前記印刷用データを変換させることを特徴とする請求項２５〜３３のいずれか一つに記載のファイル変換プログラム。
前記記憶工程は複数の記憶部への記憶を行わせ、
前記変換工程は、前記複数の記憶部のそれぞれに対応した複数の変換部への変換を行わせ、
前記記憶部と前記変換部を１つの組とした仮想変換部を、複数で並行動作させることを特徴とする請求項３４に記載のファイル変換プログラム。
前記印刷用データに含まれる指定情報に基づいて、前記印刷用データの変換を行う仮想変換部を指定させる指定工程と、
前記指定工程で指定される仮想変換部に前記印刷用データの変換を行わせる制御工程と、
をさらに含むことを特徴とする請求項３５に記載のファイル変換プログラム。