(57)【要約】【課題】中間ファイルの可読性とサイズの抑制とを両立させる。【解決手段】クライアント６０１は、所定のＵＲＬを指定してサーバ６０８のアプリケーションデータファイルを獲得できる。その際に、クライアント６０１はその言語を示すLanguageIDをサーバ６０１に送信する。サーバ６０１は、ファイル変換部６１２により、クライアント６０１から受信したLanguageIDと、指定されたアプリケーションデータファイルで使用されている言語のLanguageIDとを比較し、一致しなければそのアプリケーションデータファイルを中間ファイルに変換する際に、使用されているフォントを埋め込む。一致すれば、フォントを埋め込むことはしない。変換後の中間ファイルは、サーバ６０８からクライアント６０１に送信される。【選択図】図５
2005332088.tif 000002
【特許請求の範囲】
【請求項１】
元文書データに基づいて、文字フォントを含み得るフォント付き文書データを生成する文書生成装置であって、
前記元文書データの言語の種類と、前記元文書データを再生する再生端末において提供される言語の種類とを比較する比較手段と、
前記比較手段による比較の結果、両言語の種類が一致した場合、前記元文書に基づいて文字フォントを含まないフォント付き文書データを生成し、両言語の種類が一致しない場合、前記元文書に基づいて、前記元文書データにおいて使用される文字フォントを含むフォント付き文書データを生成する生成手段と
を備えることを特徴とする文書生成装置。
【請求項２】
端末装置と接続するための通信手段を更に備え、
前記比較手段は、前記元文書データの言語として前記文書生成装置の使用言語を用い、前記再生端末において提供される言語の種類として、前記通信手段を介して前記端末から受信した言語識別情報により特定される言語の種類を用いて比較を行うことを特徴とする請求項１に記載の文書生成装置。
【請求項３】
前記通信手段により接続された端末より、元文書データと、該元文書データを作成した端末において提供される言語の種類を示す言語識別情報とを受信して保存するアップロード手段を更に備え、
前記比較手段は、前記元文書データが前記アップロード手段により保存した元文書データである場合、該元文書データの言語の種類として、前記文書生成装置の使用言語の種類に代えて、前記アップロード手段により保存した言語識別情報により特定される言語の種類を用いて比較を行うことを特徴とする請求項２に記載の文書生成装置。
【請求項４】
前記元文書データは、電子メールに添付される添付データであり、前記比較手段は、前記元文書データを再生する再生端末において提供される言語の種類として、前記電子メールの宛先ドメイン名のトップレベルドメインが国コードである場合には、該国コードに対応する言語の種類を用いることを特徴とする請求項１に記載の文書生成装置。
【請求項５】
前記比較手段は更に、前記元文書データの言語の種類として、前記電子メールの送信元ドメイン名のトップレベルドメインが国コードである場合には、該国コードに対応する言語の種類を用いることを特徴とする請求項４に記載の文書生成装置。
【請求項６】
前記比較手段は、前記元文書データの言語の種類として、該元文書データを作成した端末において提供されるフォントの種類を、前記元文書データを再生する再生端末において提供される言語の種類として、前記再生端末において提供されるフォントの種類を用いることを特徴とする請求項１に記載の文書生成装置。
【請求項７】
サーバ装置とクライアント装置とを接続したファイル変換システムであって、
前記クライアント装置は、中間ファイルを再生する再生クライアント装置のフォント環境を取得する取得手段と、
アプリケーションプログラムで作成されたアプリケーションファイルを所定形式の中間ファイルへ変換するための変換要求および当該再生クライアント装置のフォント環境を前記サーバ装置へ送信するフォント環境送信手段とを有し、
前記サーバ装置は、前記クライアント装置から受信した変換要求およびフォント環境を基に、前記アプリケーションファイルを中間ファイルに変換する変換手段と、
中間ファイルに変換する際、前記フォント環境に応じてフォント埋め込みを行う埋め込み手段と、
中間ファイルを前記クライアント装置へ送信するファイル送信手段とを有することを特徴とするファイル変換システム。
【請求項８】
前記フォント環境としては、前記クライアント装置の言語識別情報が用いられることを特徴とする請求項７に記載のファイル変換システム。
【請求項９】
前記フォント環境としては、ユーザにより指定される前記再生クライアント装置の言語識別情報が用いられることを特徴とする請求項７に記載のファイル変換システム。
【請求項１０】
前記フォント環境としては、前記クライアント装置が使用可能なすべてのフォントが用いられることを特徴とする請求項７に記載のファイル変換システム。
【請求項１１】
前記アプリケーションファイルは、前記サーバ装置に予め保持されていることを特徴とする請求項７に記載のファイル変換システム。
【請求項１２】
前記アプリケーションファイルは、前記サーバ装置に接続されたクライアント装置から前記サーバ装置にアップロードされることを特徴とする請求項７に記載のファイル変換システム。
【請求項１３】
元文書データに基づいて、文字フォントを含み得るフォント付き文書データを生成する文書生成方法であって、
前記元文書データの言語を示す第１の言語識別情報を、通信により接続された端末から、あるいは、前記文書生成方法を実行する装置において所定の記憶場所から取得して記憶する工程と、
前記元文書データを再生する再生端末において提供される言語を示す第２の言語識別情報と、通信により接続された端末から取得してメモリに記憶する記憶工程と、
前記メモリに記憶された前記第１の言語識別情報と前記第２の言語識別情報とを比較する比較工程と、
前記比較工程による比較の結果、両言語識別情報が一致した場合、前記元文書に基づいて文字フォントを含まないフォント付き文書データを生成し、両言語識別情報が一致しない場合、前記元文書に基づいて、前記元文書データにおいて使用される文字フォントを含むフォント付き文書データを生成して保存する生成工程と
を備えることを特徴とする文書生成方法。
【請求項１４】
アプリケーションプログラムで作成されたアプリケーションファイルを所定形式の中間ファイルへ変換するためのファイル変換方法であって、
クライアント装置において中間ファイルを再生する再生クライアント装置のフォント環境を取得する取得工程と、
前記アプリケーションファイルを前記中間ファイルへ変換するための変換要求および前記再生クライアント装置のフォント環境を前記クライアント装置から前記サーバ装置へ送信するフォント環境送信工程と、
前記サーバ装置において前記クライアント装置から受信した変換要求およびフォント環境を基に前記アプリケーションファイルを中間ファイルに変換する変換工程と、
前記サーバ装置において前記アプリケーションファイルを前記中間ファイルに変換する際、前記フォント環境に応じてフォント埋め込みを行う埋め込み工程と、
前記中間ファイルを前記サーバ装置から前記クライアント装置へ送信するファイル送信工程と
を有することを特徴とするファイル変換方法。
【請求項１５】
請求項１３または１４に記載された方法をコンピュータにより実行させるためのコンピュータプログラムを記録したことを特徴とするコンピュータ可読記録媒体。
【請求項１６】
フォント環境を認識する認識手段と、
前記認識手段により認識されたフォント環境に基づき、元文書に基づいて文字フォントを埋め込まないで文書データを生成するか、元文書に基づいて元文書データにおいて使用される文字フォントを埋め込んで文書データを生成する生成手段と
を備えることを特徴とする文書生成装置。
【請求項１７】
フォント環境を認識する認識ステップと、
前記認識ステップにより認識されたフォント環境に基づき、元文書に基づいて文字フォントを埋め込まないで文書データを生成するか、元文書に基づいて元文書データにおいて使用される文字フォントを埋め込んで文書データを生成する生成ステップと
を備えることを特徴とする文書生成方法。
【請求項１８】
フォント環境を認識する認識ステップと、
前記認識ステップにより認識されたフォント環境に基づき、元文書に基づいて文字フォントを埋め込まないで文書データを生成するか、元文書に基づいて元文書データにおいて使用される文字フォントを埋め込んで文書データを生成する生成ステップと
を備えることを特徴とするコンピュータ可読の文書生成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、たとえばＰＤＦ形式など、フォントを持たせることのできる文書ファイルを作成するための文書生成装置に関し、特にクライアント−サーバシステムに実装されるファイル変換システムに関する。
【背景技術】
【０００２】
＜Ｗｅｂ技術＞
まずＷｅｂに関する従来技術について説明する。インターネットの急速な発展とＷｅｂサーバの林立に伴い、業務処理のＷｅｂ化が推進されている。Ｗｅｂサーバとは、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）等をサポートする、ネットワークに接続されたコンピュータなどを指し、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）で指定された、ＨＴＭＬ（Ｈｙｐｅｒ  ｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）などで記述された文書データファイル等を、要求に応じてネットワーク上のクライアントに送信することができる。一方、パーソナルコンピュータ等のクライアントコンピュータでは、ＨＴＭＬで記述されたデータ（ＨＴＭＬ文書）を表示する機能を持つＷｅｂブラウザと呼ばれるアプリケーションプログラム（単にブラウザとも呼ぶ）を実行して、Ｗｅｂサーバから受信したＨＴＭＬ文書を表示する。Ｗｅｂブラウザ（以下単にブラウザと呼ぶ。）は、単にＨＴＭＬ文書を表示するのみならず、ＨＴＭＬの記述に従って、画面上でデータを入力させ、それをＷｅｂサーバに返送する機能を持つのが普通である。なお、Ｗｅｂ化とは、クライアントからＵＲＬを指定してサーバとのデータ交換を行えるようにすることを指す。
【０００３】
Ｗｅｂ化された業務システムでは、クライアントコンピュータは情報の表示及び入力が可能なブラウザを搭載し、オペレータはブラウザをユーザインターフェースとして表示及び入力等の業務処理を遂行する。この際には、クライアント上のブラウザから入力された情報をＷｅｂサーバが受け取り、ＷｅｂサーバやＷｅｂサーバに接続されたその他のサーバにより情報の加工等を行って、得られた結果を示す情報をクライアントのブラウザに送信する。クライアントでは、サーバから受信した情報の表示を行う等の動作を必要に応じて行う。このような手順で業務が遂行され、オペレータは結果物（情報）を得ることができる。
【０００４】
このように、Ｗｅｂブラウザにサーバからドキュメントや画像等のデータを渡す場合には、Ｗｅｂサーバのファイルシステムにおける、クライアントからアクセス可能な特定のディレクトリ（ＨＴＴＰ用語でのドキュメントルートを指す。以下ディレクトリと呼ぶ。）にこれらのデータファイル等のファイルを置く。そのファイルをクライアントが要求したなら、クライアントにはそのファイルのＵＲＬを渡す。クライアントではそのＵＲＬを指定してＦＴＰなどを用いれば、サーバ上で加工が施された、所望のファイルがクライアントに送信される。
【０００５】
サーバにおける情報の加工の一つとして、クライアントからの要求に応じて行われる、文書や表、画像、図形等を作成するためのアプリケーションプログラムで作成されたアプリケーションファイルからＰＤＦ等の中間フォーマットのファイル（中間ファイル）への変換が知られている（例えば、特許文献１参照）。その変換の結果得られた中間ファイルを再生した場合、クライアントとサーバとのフォント環境の違いから、文字描画が意図どおりに行われない場合がある。なお、中間ファイルの再生とは、中間ファイルの内容たる文書を表示したりあるいは印刷することで、中間ファイルから文書を再生することをいう。また、フォント環境とは、コンピュータの資源を管理するオペレーティングシステムにおいて、資源のひとつとして管理される使用言語の種類や、コンピュータにおいて利用可能なフォントの種類を含む。オペレーティングシステムの使用言語は、たとえば英語版のオペレーティングシステムであれば英語であるし、日本語版のオペレーティングシステムであれば日本語である。オペレーティングシステムの種類によっては使用言語を切り換えられるものもあろうが、そのようなものであっても、一定の使用言語が指定されるのが普通であろう。
【０００６】
中間ファイルは、文書を構成するオブジェクトを記述する描画コマンドと、オブジェクトの位置やサイズ等を示すオペランドとを含む。描画コマンドは通常、オブジェクトの種類に応じて、文字の出力をする「文字系」、ビットマップ等の画像を出力する「イメージ系」、直線や、円、四角形等の図形を出力する「グラッフィクス系」の３種類に大別される。
【０００７】
ここでＭｉｃｒｏＳｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）システムの「文字系」描画コマンドについて説明を行う。図３は、文字描画に必要な情報を表す模式図である。図３は一例であるが、一般的にも文字描画コマンドにはオペランドとして以下の４つのフォント情報が必要である。
（１）文字コード３０１：
文字を特定するための情報である。ＡＳＣＩＩ、ＳｈｉｆｔＪＩＳ、Ｕｎｉｃｏｄｅ等、予め定められたコード体系に従った文字コードが用いられる。
（２）フォント属性３０２：
文字描画に適応するフォントフェース名、グリフへの修飾を表すイタリック／ボールド指定有無、文字の大きさを表すポイント数等の情報を含む。
（３）描画属性３０３：
文字の描画位置や、色、クリップの状態等を表す情報を含む。
（４）フォント形状情報３０４：
ゴシックや明朝等のフェース名で指定される文字描画形状を表す情報を含む。文字毎の描画形状情報（グリフと呼ぶ。）を有する。フォントの情報形式としては、大きくビットマップフォントとアウトラインフォントとに分かれ、ＴｒｕｅＴｙｐｅ（登録商標）、ＯＰＥＮＴＹＰＥ（登録商標）等の各種フォーマットが定義されている。
【０００８】
そして、これらの情報全てが揃わなければ、ユーザが意図した通りの文字描画は成立しない。中間ファイル内の文字描画データには、文字コード、フォント属性、描画属性の３つのフォント情報を用いた文字描画コマンドが含まれるのが普通である。そしてコンピュータ等において文字描画を実行する際、すなわち中間ファイルを再生する際には、文字描画コマンドに含まれるフォントフェース名をもとに、当該コンピュータを管理するＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）が保持している同じフォントフェース名のフォント形状情報を参照して文字を描画するのが普通である。
【０００９】
しかし、指定されたフォント形状情報が、すべてのコンピュータ環境（ＯＳにより提供される資源と言うこともできる。）に存在するとはかぎらない。言い換えると、ユーザが中間ファイルを作成したコンピュータ環境（中間ファイル作成環境と呼ぶ。）に存在したフォント形状情報が、文字描画が行われるコンピュータ環境（文字描画実行環境という。）では存在していない場合もあり得る。描画が行われるコンピュータ環境に、アプリケーションデータを作成したユーザが意図したフォントが存在しない場合でも、ユーザが意図したフォントもしくはそれに近い形状のフォントで文字描画を行うために、従来、（１）フォント置き換え、（２）ビットマップ置き換え及び、（３）フォント埋め込みという仕組みが知られている。以下、それぞれの仕組みを用いた場合の描画結果を示す図４を参照して、それぞれの仕組みについて説明する。
【００１０】
（１．フォント置き換え）
文字描画実行環境において、文字描画データ（中間ファイル）中のフォント属性に近い別のフォントを用いて描画を行う方法である。別のフォントを指定する方法としては、文字描画を行うアプリケーションが予め定義した変換テーブルを用いる方法や、ＯＳが予め定義した変換テーブルを用いる方法が一般的である。文字描画データを作成する際に、通常どおりの文字描画コマンド（文字コード、フォント属性、描画属性）を作成するが、最もデータ量の多いフォント形状情報は必要ないため文字描画データ量が小さいという利点がある。欠点としては、別のフォントを用いるため、図４の文字パターン４０１のようにユーザが意図していたものとは全く違った形状の文字描画が行われる可能性がある。意図した文字コードに対応したフォントが文字描画実行環境において存在しない場合には、文字として識別不可能な描画が行われることもある。例えば、一般的に欧米で用いられているコンピュータ環境には日本語フォントは存在しない。そのため、中間ファイルが一般的な日本語対応のＯＳの下で作成され、中間ファイルの再生が一般的な欧米のたとえば英語対応のＯＳの下で行われる場合、中間ファイル作成環境における文字コードに対応したフォントが文字描画実行環境には存在せず、結果として識別不可能な文字の描画が行われてしまう。
【００１１】
（２．ビットマップ置き換え）
文字描画データ（中間ファイル）を作成する時点で文字描画をビットマップに変換して、文字描画をビットマップ描画に変換する方法である。通常の見た目はユーザが意図した文字描画と同じになる。しかしビットマップであるために図４の文字パターン４０２に示すように拡大／縮小時にビットマップの解像度の影響で文字品位が落ちる場合がある。
【００１２】
（３．フォント埋め込み）
文字描画データ（中間ファイル）内に、文字描画コマンド（文字コード、フォント属性、描画属性）以外に、フォント形状情報を埋め込ませ、文字描画データで使用されるフォント形状情報を文字描画実行環境に持ち込む方法である。文字描画データに埋め込まれたフォント形状情報は、文字描画実行環境において、当該環境により提供されるフォントとして登録され、文字描画データはそのフォントを用いて文字描画される。このため、フォント埋め込みは、文字描画データ内の文字描画コマンドで指定されたフォントが描画実行環境に存在しなくてもユーザが意図した出力を得られるという利点がある。しかし、フォント形状情報を文字描画データに内に埋め込むため、文字描画データ量が大きくなる傾向にある。特に日本語フォントのような文字種の多いフォントを埋め込む場合にこの問題が顕著である。
【００１３】
上記３つの仕組みのうち、（１）のフォント置き換えは、文字描画実行環境で為される処理である。一方、（２）のビットマップ置き換え、（３）のフォント埋め込みは、文字描画データ作成時に為される処理である。また、上記３つの仕組みのうち、どの方法を用いるかは、例えば、ユーザインターフェース（以下、ＵＩ）上で文字描画データ作成側のユーザがフォント毎に指定するのが普通である。
【００１４】
上記３つの仕組みのうち、文字描画データ作成側のユーザが意図したフォントを、文字描画実行環境において忠実に描画するには、（３）のフォント埋め込みを用いることが望ましい。なぜなら（３）のフォント埋め込みは、前述したように、埋め込まれたフォント情報を文字描画前に文字描画実行環境へ登録するため、確実に文字描画データ作成側ユーザが意図した形式で文字描画されるからである。
【特許文献１】特開２０００−２８４９３７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
このように、文字描画データ作成側が意図したフォントを、文字描画実行環境で忠実に描画するには、文字描画データへのフォント埋め込みを用いることが望ましい。しかし文字描画データにフォントを埋め込むと、文字描画データのサイズが大きくなってしまうという問題点がある。つまり、データサイズの観点からは、文字描画実行環境に存在するフォントは埋め込まず、文字描画データで使用されており、しかも文字描画実行環境には存在しないフォントのみを埋め込むことが望ましいと言える。そのためには、文字描画データ作成側ユーザは文字描画実行環境にどのフォントが含まれているか事前に知る必要がある。しかしながら、数多く存在するフォントの中から埋め込むべきフォントを調べることは、文字描画データを作成するユーザにとって大きな負担となっている。
【００１６】
また、上記３つの仕組みのうちどの方法を使用するかは、変換処理をする際に、例えば変換処理を実行するプログラムのユーザインターフェース（ＵＩ）上でフォント毎に指定するのが普通である。しかしながら、数多く存在するフォントの中から埋め込むべきフォントを文字描画データ作成側ユーザが指定すること自体も作成側にとっては大きな負担である。特に、文字描画データを作成したフォント環境と文字描画を行うフォント環境が大きく異なる場合に、この問題は顕著となる。
【００１７】
また、文字フォントの埋め込みを行ってもなお、文字描画実行時に、文字描画データ内の文字描画コマンドで指定されたフォントが文字描画実行環境に存在しないこともあり得る。このような場合には、中間ファイルを再生するコンピュータにおいて、前述した（１）のフォント置き換え処理を行う。しかし、前述したように、フォントの置き換えによって元データを作成した際に意図した文字と異なる形状の文字が再生されることもある。そこで、文字描画実行環境において確実に意図通りに中間ファイルを再生させるために、文字描画を実行するコンピュータのフォント環境を取得し、文字描画データ作成環境において埋め込むべきフォントを自動的に決定する機能が望まれている。
【００１８】
本発明は上記従来例に鑑みてなされたもので、ユーザが自らのフォント環境を意識することなく、フォント埋め込みを最適化した中間ファイルを生成することができる文書生成装置及びファイル変換システムを提供することを目的とする。
【００１９】
また、元データから中間ファイルを生成する際に、中間ファイルの再生を行う端末のフォント環境をユーザが指定することなく、そのフォント環境において元データ通りに再生可能な中間ファイルを作成する文書生成装置及びファイル変換システムを提供することを目的とする。
【００２０】
また、元データから電子メールの添付ファイルとして送信される中間ファイルを生成する際に、宛先のフォント環境において元データ通りに再生可能な中間ファイルを作成する文書生成装置及びファイル変換システムを提供することを目的とする。
【００２１】
また、中間ファイルの可読性とサイズの抑制と、オペレータの操作性をすべて満たすことを目的とする。
【課題を解決するための手段】
【００２２】
本発明は上記問題点に鑑みてなされたもので、次のような構成からなる。
【００２３】
すなわち、元文書データに基づいて、文字フォントを含み得るフォント付き文書データを生成する文書生成装置であって、
前記元文書データの言語の種類と、前記元文書データを再生する再生端末において提供される言語の種類とを比較する比較手段と、
前記比較手段による比較の結果、両言語の種類が一致した場合、前記元文書に基づいて文字フォントを含まないフォント付き文書データを生成し、両言語の種類が一致しない場合、前記元文書に基づいて、前記元文書データにおいて使用される文字フォントを含むフォント付き文書データを生成する生成手段とを備える。
【００２４】
あるいは、本発明は以下の構成を備える。
【００２５】
すなわち、サーバ装置とクライアント装置とを接続したファイル変換システムであって、
前記クライアント装置は、中間ファイルを再生する再生クライアント装置のフォント環境を取得する取得手段と、
アプリケーションプログラムで作成されたアプリケーションファイルを所定形式の中間ファイルへ変換するための変換要求および当該再生クライアント装置のフォント環境を前記サーバ装置へ送信するフォント環境送信手段とを有し、
前記サーバ装置は、前記クライアント装置から受信した変換要求およびフォント環境を基に、前記アプリケーションファイルを中間ファイルに変換する変換手段と、
中間ファイルに変換する際、前記フォント環境に応じてフォント埋め込みを行う埋め込み手段と、
中間ファイルを前記クライアント装置へ送信するファイル送信手段とを有する。
【発明の効果】
【００２６】
本発明によれば、ユーザが自らのフォント環境を意識することなく、自動的にフォント埋め込みを最適化した中間ファイルを生成することができる。
【００２７】
また、ファイル変換はサーバ上で行われるため、クライアントに存在しないフォントを含んだアプリケーションファイルであっても、サーバにそのフォントがあれば、フォント埋め込みを最適化した中間ファイルを生成し、クライアントへ提供することができる。
【００２８】
また、中間ファイルはサーバにより生成されるため、クライアントでは特別な処理を行うためのプログラムを用意する必要がない。このため、クライアントの処理性能は低くてもかまわず、安価にクライアントを提供することができる。
【００２９】
また、元データから中間ファイルを生成する際に、中間ファイルの再生を行う端末のフォント環境をユーザが指定することなく、そのフォント環境において元データ通りに再生可能な中間ファイルを作成することができる。
【００３０】
また、元データから電子メールの添付ファイルとして送信される中間ファイルを生成する際に、宛先のフォント環境において元データ通りに再生可能な中間ファイルを作成することができる。
【発明を実施するための最良の形態】
【００３１】
［第一の実施形態］
図５に第一の実施形態の概要を示す。クライアント６０１は、クライアント６０１のフォント環境を自動的に取得し、また、中間フォーマットへ変換したいサーバ上のアプリケーションデータファイル（元データ）を指定し、その情報をサーバ６０８に送信する。サーバ６０８では指定されたアプリケーションデータファイルを、受信したフォント環境に適したフォント埋め込みを行った中間ファイル（フォント付き文書データ）に変換し、クライアントに送信する。また本実施形態では、クライアントがサーバから受信した中間ファイルは、そのクライアント自身が再生するためのものである。以下に本実施形態の詳細を示す。
【００３２】
＜ネットワークシステムの構成例＞
図５は、本発明の第一実施形態に係るファイル変換システムのソフトウェアブロック図である。ここでは、サーバ、クライアントともに１台ずつ示している。しかしクライアントおよびサーバの両方もしくは何れかが複数存在するシステムであっても本発明は適用できる。
【００３３】
図５において、クライアント６０１は、パーソナルコンピュータ等の情報処理装置である。クライアント６０１には、Ｗｅｂブラウザ６０２、ディスプレイ６１３が接続された画像表示部６０３、フォント環境取得部６０４、データ入出力部６０５、中間フォーマット解析部６０６等が含まれる。さらに、不図示の文書処理アプリケーションなどのアプリケーションプログラムにより作成されたアプリケーションデータファイルや、サーバから受信したＰＤＦファイル等の中間ファイルを格納するためのデータ格納部６１４等が含まれる。データ格納部６１４には、このほかクライアントのオペレーティングシステムが保持するＬａｎｇｕａｇｅＩＤやフォントファイルなどのシステム情報が保存されている。またクライアントの有するこれらソフトウエア資源およハードウエア資源のデータベースや、本実施形態においてクライアントが参照するデータも保存されている。
【００３４】
Ｗｅｂブラウザ６０２は、データ入出力部６０５を介してサーバから受信したＨＴＭＬ文書を、画像表示部６０３を介してディスプレイ６１３で表示する。通常のＷｅｂブラウザは、サーバから受信したＨＴＭＬ文書を表示することができ、また、表示しているＨＴＭＬ文書データに、画面上で何らかのデータを入力する旨の記述が含まれれば、ユーザにその記述に相当する欄への入力を行わせることができる。また、それを入力されたデータをサーバに送信する旨の記述をすることができ、その記述に従ってユーザが操作を行えば、入力されたデータをサーバに送信することができる。なおこれらの記述は、一般に入手可能な代表的なＷｅｂブラウザによりサポートされている。
【００３５】
フォント環境取得部６０４は、ＯＳからフォント環境の取得を行う。本実施形態では、フォント環境として、ＬａｎｇｕａｇｅＩＤ（すなわち言語識別情報）を用いる。ＯＳはそのシステムの、現在の国設定情報を保持している。例えばＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムであれば、ＯＳはシステムロケールを必ず保持している。このロケールには、言語環境のほか、日付や時刻などの表記方法、通貨の単位などが含まれている。このロケール情報の一つとして国・地域毎に一意に与えられたＩＤがある。これを本発明ではＬａｎｇｕａｇｅＩＤと呼ぶ。本実施形態ではＬａｎｇｕａｇｅＩＤを用いるが、クライアント６０１のフォント環境を取得することができる手段であれば、その手段は問わない。また、中間ファイルを再生するコンピュータのＬａｎｇｕａｇｅＩＤをＷｅｂブラウザ上でユーザが指定すれば、中間ファイルの作成を要求するクライアント自身のフォント環境ではなく、指定された国・地域のフォント環境に適した中間ファイルを作成することも可能である（詳細は第三の実施形態で述べる）。
【００３６】
データ入出力部６０５は、電話回線やＬＡＮ等の６０７を介してサーバ６０８と通信し、データを交換する処理を行う。また、図５ではキーボードやポインティングデバイス等の入出力デバイスもデータ入出力部６０５に接続されるものとしている。
【００３７】
中間フォーマット解析部６０６は、サーバから受信したＨＴＭＬ文書が中間フォーマットのファイルすなわち中間ファイルであった場合、中間ファイルを解析し、画像表示部６０３を介してディスプレイ６１３に表示する。あるいは、クライアントに接続されたプリンタから印刷出力させる。具体的には、中間ファイルとしてＰＤＦファイルを用いた場合におけるアドビ社のアドビリーダなどが中間フォーマット解析部６０６に相当する。
【００３８】
クライアント６０１とサーバ６０８とを接続するネットワーク６０７の形態としては、ＬＡＮ、インターネットあるいは無線等、Ｗｅｂ環境の通信手順に対応するものであれば、その種類は問わない。
【００３９】
サーバ６０８は、少なくともＨＴＴＰをサポートするＷｅｂサーバであり、クライアント６０１と同様、パーソナルコンピュータ等の情報処理装置である。サーバ６０８はさらにＦＴＰあるいはＷｅｂＤＡＶなどのファイル転送のためのプロトコルをサポートする必要がある。サーバ６０８には、ネットワーク通信制御部６０９、データ格納部６１０、ファイル変換管理部６１１、ファイル変換部６１２等が含まれる。
【００４０】
サーバ６０８では、Ｗｅｂブラウザ６０２からのデータの受付、解析、また場合によっては、受付データに応じてデータ格納部６１０からのデータ検索、結果のＷｅｂブラウザ６０２への返信などの処理が行われる。この時、ＨＴＭＬ文書に、Ｗｅｂブラウザ６０２からボタンによる入力を行わせてその結果をサーバ６０８に送信するよう記述しておけば、Ｗｅｂブラウザ６０２はボタンを表示し、ユーザがＷｅｂブラウザ６０２のボタンを押す等の操作をした時に、サーバ６０８へのデータの送信を行う。サーバ６０８では、クライアント６０１に送信したＨＴＭＬ文書に基づいて受信データを解析し、必要があればＷｅｂブラウザ６０２へ応答する。
【００４１】
ネットワーク通信制御部６０９は、サーバ６０８がＷｅｂサーバとして機能するために、クライアント６０１へデータを送信、あるいはクライアント６０１からデータを受信する処理を行う。
【００４２】
データ格納部６１０はデータベース等であり、変換の元データとなる変換対象のアプリケーションデータファイルが格納されている。アプリケーションデータファイルは、たとえば文書作成プログラム等のアプリケーションプログラムで作成されたデータファイルである。本実施形態では、この変換対象のアプリケーションデータファイルは予めサーバ６０８に格納されているものとして説明を進めるが、Ｗｅｂブラウザ６０２を介してクライアント６０１から入力されたものであってもよい。
【００４３】
ファイル変換管理部６１１では、クライアント６０１から変換対象のアプリケーションデータファイルを受信した場合に、そのアプリケーションデータファイルを扱えるアプリケーションプログラムがサーバ６０８にあるかどうかの判断を行い、該当するアプリケーションプログラムがあればファイル変換部６１２へ変換指示を行う。この判断は、ウインドウズ（登録商標）のファイルシステムであれば、たとえばアプリケーションデータファイルの拡張子に基づいて行うことができるし、ファイルに対応するアプリケーション名等を属性として持つならば、その属性に基づいて判断できる。ファイル変換部６１２は、変換対象のアプリケーションデータファイルを、クライアントから受け取った、中間ファイルを再生するコンピュータのフォント環境（本実施形態ではＬａｎｇｕａｇｅＩＤ）に則して埋め込みフォントを最適化した中間フォーマットへ変換する処理を行う。ファイル変換部６１２は、図６に示すように、アプリケーションデータファイルを印刷処理可能なアプリケーション６１２−１、グラフィックエンジン６１２−２、プリンタドライバ６１２−３から構成される。ここでプリンタドライバは、物理的なデバイスとしてのプリンタを制御するドライバではなく、グラフィックエンジン６１２−２から入力されるデータ（コマンド）を中間フォーマットのコマンド列に変換して中間ファイルとして出力するソフトウエアである。
【００４４】
＜ハードウェアの構成例＞
図７はクライアント及びサーバとして使用可能な情報処理装置の構成を示すハードウェア構成図である。図５のクライアント６０１及びサーバ６０８の構成は、図７の構成において、メモリ６０１ｂに格納されたプログラムを、ＣＰＵ６０１ａにより実行することで実現される。また、図７の構成を実現するためのプログラムは、ハードディスク等の外部メモリ６０１ｃに格納される。外部メモリ６０１ｃは、フレキシブルディスクやＣＤＲＯＭ等の取り外し可能な記憶媒体を用いるものであっても良い。また、データ格納部６１０，６１４は、外部メモリ６０１ｃの一部領域として実現することができる。
【００４５】
ディスプレイ６１３（クライアント６０１の場合）には画像が表示され、Ｉ／Ｏインターフェース６０１ｄを介してネットワーク６０７等に接続される。また、キーボードやポインティングデバイス６０１ｅにより、オペレータは必要な入力を行う。
【００４６】
＜ネットワーク変換システムの処理手順＞
次に図８に示したフローチャートを用いて、本システムの概要を説明する。クライアント６０１からサーバ６０８の文書（アプリケーションデータファイル）を読み出す場合、まずステップＳ８０１にて、クライアントでブラウザプログラム６０２を起動する。このブラウザは一般的に用いられているＷｅｂブラウザ等でよい。
【００４７】
図９は、ブラウザ６０２により表示されたファイル変換処理に係るＨＴＭＬ文書の一例である。図９において、ウインドウ９０１は、ディスプレイ６１３に表示されるブラウザ６０２のウインドウである。タイトルエリア９０２には表示される文書に付されたタイトルが表示される。エリア９０３および９０４にはブラウザ６０２のコマンドがツールバーやボタン等の形式で表示されている。ブラウザに表示されている内容を印刷する為のコマンドも通常これらエリアに表示される。エリア９０５は、接続するＷｅｂサーバのアドレスや文書のＵＲＬ等を入出力するＵＲＬフィールドである。ＨＴＭＬ文書はここで入力されるＵＲＬにより指定される。Ｗｅｂブラウザ６０２が起動されると、タイトルエリア９０２〜ＵＲＬフィールド９０５までが表示され、その他の欄には予めブラウザに設定されたＵＲＬで指定される文書が表示される。
【００４８】
次にステップＳ８０２にて、ユーザがキーボード等によって本システムのサービスを実行するＵＲＬをエリア９０５に入力する。ＵＲＬが入力されると、入力されたＵＲＬに応じたＨＴＭＬ文書が読み出されて表示される。本実施形態では、入力されるＵＲＬはサーバ６０８により中間フォーマットの文書を提供するためのアドレスである。そしてそのＵＲＬが指定されると、サーバ６０８に接続され、欄９０６〜９０７を含むＨＴＭＬ文書がサーバ６０８から読み出されて表示される。選択欄９０６は、サーバ６０８が提供するアプリケーションデータファイルの一覧が表示されるフィールドである。クライアントのユーザはこの一覧の中から所望のアプリケーションデータファイルを選択可能である。サーバ６０８のデータ格納部６１０には、例えば、図１０に示すようなファイルＩＤ１００２とファイル名１００３とを対応付けたデータベーステーブル１００１を保持させておく。そしてサーバ６０８がクライアント６０１に送信するＨＴＭＬ文書には、選択欄９０６にデータベーステーブル１００１内のファイル名１００３をすべてファイル選択ボタンとして表示されるような記述が含まれている。そのＨＴＭＬ文書を受信したブラウザ６０２は、その記述に従って、ファイル選択ボタン９０６ａ〜９０６ｃを表示する。すなわち、ファイル選択ボタン９０６ａ〜９０６ｃは、エリア９０５に入力されたアドレス（ＵＲＬ）に応じたアプリケーションデータファイル名がボタン化されたもので、サーバのデータ格納部６１０から読み出されたファイル名が一覧表示されたものである。また、クライアント６０１で表示されるＨＴＭＬ文書には、選択欄９０６の他、変換処理をスタートさせるための変換ボタン９０７が含まれている。
【００４９】
次にステップＳ８０３にて、ユーザがポインティングデバイスやキーボードによって選択欄９０６に表示されたいずれかのファイル名選択ボタンを押す。ファイル名選択ボタンが押されると、ステップＳ８０４にて選択されたファイル名に対応するファイルＩＤ１００２を、例えば図１１に示すようなクライアント要求テーブル１１０１のファイルＩＤ欄１１０３に格納するよう記述されている。
【００５０】
同様に、ステップＳ８０５にてユーザがポインティングデバイスやキーボードによって変換ボタン９０７を押す。サーバから送信されたＨＴＭＬ文書には、変換ボタンが押されると以下のような処理を行うよう記述しておく。
【００５１】
変換ボタンが押されるとまず、ステップＳ８０６にてブラウザは、フォント環境取得部６０４へフォント環境の取得要求を行う。本実施形態ではフォント環境としてＬａｎｇｕａｇｅＩＤを用いる。通常、ＬａｎｇｕａｇｅＩＤはＯＳが保持しているため、ＯＳに問い合わせることで取得可能である。取得したＬａｎｇｕａｇｅＩＤは、クライアント要求テーブル１１０１内のＬａｎｇｕａｇｅＩＤ１１０２に格納する。
【００５２】
次にステップＳ８０７にて、保持しておいたクライアント要求テーブル１１０１をサーバ６０８へ送信する。次のステップ８０８からステップ８１１（図８における点線枠）はサーバ６０８により実行される。
【００５３】
次にステップＳ８０８にて、サーバ６０８では、受け取ったクライアント要求テーブル１１０１内のエントリーであるファイルＩＤ１１０３をキーとして、データ格納部６１０内に格納されているデータベーステーブル１００１を検索する。そして、ファイルＩＤの一致するファイルを取得する。次にステップＳ８０９にて、ファイル変換管理部６１１は、対象ファイルを扱えるアプリケーションに対して、対象ファイルの変換命令を出す。対象ファイルとは、クライアント要求テーブル１１０１のファイルＩＤ１１０３に記録されたＩＤに対応するファイルである。対象ファイルを扱えるアプリケーションの特定は、通常ＯＳに備わっている機能である。たとえばウインドウズ（登録商標）であれば、ファイルの拡張子とアプリケーションとを対応付ける情報がオペレーティングシステムにより保存されており、ファイルのオープンが指示されると、対応付けられたアプリケーションが実行される。次にステップＳ８１０にて、ファイル変換管理部６１１からの変換命令を受けたファイル変換部６１２が中間ファイルを生成する。中間ファイルの変換についての詳細な処理は図８の説明の直後に述べる。次にステップＳ８１１にて、サーバ６０８は、作成した中間ファイルをクライアント６０１へ送信する。ここでは説明を簡単にするために中間ファイルをクライアント６０１に送信するとしているが、実際には作成された中間ファイルそのものをクライアント６０１に送信せず、作成された中間ファイルのＵＲＬをクライアント６０１に送ることが望ましい。
【００５４】
次にステップＳ８１２にて、クライアント６０１は、Ｗｅｂブラウザ６０２で受信した中間ファイル、または受信したＵＲＬに保持されている中間ファイルをダウンロードして中間フォーマット解析部６０６で解析し、表示可能なビットマップデータ等に変換して画像表示部６０３を介してディスプレイ６１３上に表示する。そしてさらに、ユーザ操作に応じて、その中間ファイルを保存したり、あるいは中間フォーマット解析部６０６で解析してプリンタに対応したＰＤＬ等の印刷可能なデータ形式に変換し、プリンタで印刷させることもできる（ステップＳ８１３）。
【００５５】
ステップＳ８１２およびステップＳ８１３において、中間ファイルの文字オブジェクトのオペランドで指定されたフォントフェースがクライアント６０１に備えられていない場合には、代替フォントを用いて表示または印刷を行う。代替フォントは、予め指定されている代替関係にあるフォントを用いる。あるいは、デフォルトのフォントを決めておき、指定されたフォントが存在しない場合にはデフォルトフォントを用いて文書を再生する。
【００５６】
＜中間ファイルへの変換＞
次にファイル変換部６１２による中間ファイルへの変換の手順について詳しく説明する。本実施形態では、ファイル変換の手段として、ＯＳに備わっている印刷機能を利用する。まず、印刷機能の仕組みについて説明する。
【００５７】
図１は従来、直接、あるいはネットワーク経由で接続されているプリンタ１０４に対して印刷指示を行う印刷制御装置としてのパーソナルコンピュータ等の汎用情報処理装置（以下、ホストコンピュータ）において、印刷処理に関わる機能構成を大まかに示した図である。
【００５８】
ホストコンピュータ１０１では、ワードプロセッサや表計算のようなアプリケーションソフトウェア１０１（以下、アプリケーション）がＷｉｎｄｏｗｓ（登録商標）のようないわゆる基本ソフト（オペレーティングシステム、以下、ＯＳ）の上で動作している。アプリケーション１０１において印刷を行う場合は、そのプログラム内から、基本ソフトが提供するいくつかのサブシステムのうち、グラフィックエンジン１０１の機能を用いて行う。グラフィックエンジン１０２は、例えばＷｉｎｄｏｗｓ（登録商標）では、ＧＤＩ（Ｇｒａｐｈｉｃ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ）と呼ばれており、ディスプレイやプリンタに対する画像情報の処理を司っている。ＧＤＩは、ディスプレイやプリンタといった各デバイスの依存性を吸収するためにデバイスドライバと呼ばれるモジュールを動的にリンクし、それぞれのデバイスに対する出力処理を行う。プリンタ１０４に対するこのモジュールはプリンタドライバ１０３と呼ばれる。プリンタドライバ１０３では、その能力や機能などに応じてあらかじめデバイスドライバに実装することが決められているＤＤＩ（Ｄｅｖｉｃｅ  Ｄｒｉｖｅｒ  Ｉｎｔｅｒｆａｃｅ）と呼ばれる関数群を用意する必要がある。アプリケーション１０１のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）コールをＧＤＩがデバイスドライバ用にデータ変換を行い、このＤＤＩ関数群が適宜ＧＤＩからコールされ所定の印刷処理が実行されるような仕組みになっている。グラフィックエンジン１０２では、このようにプリンタドライバ１０３を介してアプリケーション１０１からの印刷要求をシーケンシャルに処理している。
【００５９】
プリンタドライバ１０３はその使用用途によりプリンタ出力系とファイル出力系に大別できる。プリンタ出力系とは、システムからＤＤＩ関数を介して渡される描画命令を、ＰＤＬ（Ｐｒｉｎｔｅｒ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）とよばれる中間フォーマットに変換するものである。プリンタ出力系の中間フォーマット（ＰＤＬ）は、印刷装置側にＰＤＬの制御コマンドを処理可能なコントローラを搭載するもの向けで、印刷装置側のプリンタ機器で印刷を行う。
【００６０】
一方、ファイル出力系では、印刷装置側にデータを送ることが直接的な目的ではなく、ＤＤＩ関数から受け取った描画命令を予め定義された中間フォーマットに変換し、ホストコンピュータのディスクシステム上に中間ファイルとして蓄積するものである。この代表的な中間フォーマットにはＰＤＦ（Ｐｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ）やＳＶＧ（Ｓｃａｌａｂｌｅ  Ｖｅｃｔｏｒ  Ｇｒａｐｈｉｃｓ）等が存在する。中間ファイルはホストコンピュータ上のファイルシステム上に保存され、中間フォーマットを解釈可能な特定のアプリケーション１０１によりホストコンピュータ上で表示され、ユーザの指示により再びグラフィックエンジン１０２を介して印刷装置に印刷を行うことが可能である。
【００６１】
前述したＤＤＩ関数には、印刷の開始を宣言する「ジョブ開始要求」、ページの開始を宣言する「ページ開始要求」、ページ内に記述された文字、図形等を表す「論理描画要求」、ページの終了を宣言する「ページ終了要求」等がある。複数ページの印刷の場合、ページ数の分だけ「ページ開始要求」、「ページ終了要求」が出され、ページ内に含まれる論理描画の分だけ「論理描画要求」が出される。プリンタドライバ１０３は各要求に対して、ＰＤＬ，ＰＤＦ等の中間フォーマット形式に沿ったコマンドを生成する。
【００６２】
＜ファイル変換処理＞
ファイル変換管理部６１１からの変換命令を受けたファイル変換部６１２内の処理の流れについて図２を用いて詳しく説明する。ファイル変換命令をうけてファイル変換部６１２では、まず、アプリケーション６１２−１が、グラフィックエンジン６１２−２を介してプリンタドライバ６１２−３に、対象ファイルを中間フォーマットへ変換する要求を出すことによって変換を開始する（Ｓ２００）。
【００６３】
アプリケーション６１２−１は、変換ジョブを開始することを、ＧＤＩ関数を介してグラフィックエンジン６１２−２に通知する。グラフィックエンジン６１２−２は通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ６１２−３へ引き渡す（Ｓ２０１）。プリンタドライバ６１２−３はジョブ開始コマンドを生成する（Ｓ２０２）。
【００６４】
アプリケーション６１２−１はページが開始することを、ＧＤＩ関数を介してグラフィックエンジン６１２−２に通知する。グラフィックエンジン６１２−２は通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ６１２−３へ引き渡す（Ｓ２０３）。プリンタドライバ６１２−３は、ページ開始コマンドを生成する（Ｓ２０４）。
【００６５】
アプリケーション６１２−１は論理描画要求を、ＧＤＩ関数を介してグラフィックエンジン６１２−２に通知する。グラフィックエンジン６１２−２は通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ６１２−３へ引き渡す（Ｓ２０５）。プリンタドライバ６１２−３は、論理描画コマンドを生成する（Ｓ２０６）。
【００６６】
ステップＳ２０５，Ｓ２０６は、アプリケーション６１２−１からのページの終了要求が通知されるまで繰り返される。アプリケーション６１２−１がページが終了することを、ＧＤＩ関数を介してグラフィックエンジン６１２−２に通知し、グラフィックエンジン６１２−２が通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ６１２−３へ引き渡すと、プリンタドライバ６１２−３は、ページ終了コマンドを生成する（Ｓ２０８）。
【００６７】
また、ステップＳ２０３〜Ｓ２０８は、アプリケーション６１２−１からのジョブの終了要求が通知されるまで繰り返される。アプリケーション６１２−１がジョブが終了することを、ＧＤＩ関数を介してグラフィックエンジン６１２−２に通知し、グラフィックエンジン６１２−２が通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ６１２−３へ引き渡すと、プリンタドライバ６１２−３は、ジョブ終了コマンドを生成する（Ｓ２１０）。
【００６８】
＜文字描画の処理手順＞
次にステップＳ２０５における論理描画処理の内、文字描画コマンドについて図１２に示したフローチャートを用いて説明する。図１２において、ステップＳ１２０１はアプリケーションおよびグラフィクスエンジンで行われる図２のステップＳ２０５の一部であり、ステップＳ１２０２〜Ｓ１２０６はプリンタドライバで行われるステップＳ２０６の一部である。グラフィクスやイメージについても同様に描画処理が行われるが、図１２ではそれらは省略した。
【００６９】
アプリケーション６１２−１は文字描画要求を出す際、文字コード、フォント属性、描画属性を、ＧＤＩ関数を介してグラフィックエンジン６１２−２に通知する。グラフィックエンジン６１２−２は通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ６１２−３へ引き渡す（Ｓ１２０１）。
【００７０】
次に、プリンタドライバ６１２−３は、ＧＤＩ関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントＬａｎｇｕａｇｅＩＤをグラフィックエンジン６１２−２に問い合わせる。フォントＬａｎｇｕａｇｅＩＤは、例えば、ＴｒｕｅＴｙｐｅ（登録商標）フォントであれば、ＴｒｕｅＴｙｐｅ（登録商標）フォントテーブル内のｎａｍｅテーブルに格納されている。Ｗｉｎｄｏｗｓ（登録商標）でいえば、Ｗｉｎｄｏｗｓ（登録商標）で利用できるフォントの表である、フォントテーブル内にＴｒｕｅＴｙｐｅフォントテーブルがあり、それを参照することで取得可能である（Ｓ１２０２）。
【００７１】
次にプリンタドライバ６１２−３は、データ格納部６１０内に保持されている、クライアント要求テーブル１１０１内のＬａｎｇｕａｇｅＩＤ１１０２を参照し、ＬａｎｇｕａｇｅＩＤを取得する（Ｓ１２０３）。
【００７２】
フォントＬａｎｇｕａｇｅＩＤとＬａｎｇｕａｇｅＩＤとは、ロケールが一致していれば同一の値となる。例えば、日本を示すＬａｎｇｕａｇｅＩＤの値は１０４１であり、日本語フォントを示すフォントＬａｎｇｕａｇｅＩＤも同様に１０４１と定められている。そして、ＬａｎｇｕａｇｅＩＤの値とフォントＬａｎｇｕａｇｅＩＤの値とを比較し、両者が一致していなければ、フォント形状情報の埋め込み処理を行うためステップＳ１２０５へ移行し、一致していればステップＳ１２０６へ移行する（Ｓ１２０４）。
【００７３】
プリンタドライバ６１２−３は、フォント属性のフェース名および文字コードを基に、フォント形状情報をグラフィックエンジン６１２−２に問い合わせ取得する（Ｓ１２０５）。
【００７４】
プリンタドライバ６１２−３は、取得した文字コード、フォント属性、描画属性とフォント形状情報を用いて中間フォーマットに沿った文字描画コマンドを生成する。一方、埋め込み処理の必要がないと判断されたフォントの場合、上記フォント形状情報の取得の必要がないため、文字コード、フォント属性、描画属性を用いて中間フォーマットに沿った文字描画コマンドを生成する（Ｓ１２０６）。
【００７５】
以上のようにして、本実施形態の文書処理システムでは、クライアントで文書ファイルを再生する場合、文書ファイル（中間ファイル）を構成するフォントのフォントＬａｎｇｕａｇｅＩＤとクライアントのＬａｎｇｕａｇｅＩＤとが一致していれば、クライアントが備えているフォントのフォント形状情報を用いて再生することとして、フォント形状情報は当該文書ファイルには埋め込まない。これにより、中間ファイルのサイズを小さく抑えることができる。
【００７６】
また、文書ファイルで用いられるフォントと同一のフォントをその文書を再生するクライアントが備えていないとしても、再生するクライアントでは文書で用いられているフォントと類似するフォントを用いる。このため、再生される書体等が作成された文書本来の書体と異なるものとなる場合であっても、同一言語の文字で再生されるために、再生された文書の内容を読み取ることは可能である。
【００７７】
また、文書ファイルにフォントを組み込むかあるいは組み込まないかの判定および組み込むフォントの決定に際してオペレータを煩わせることがないために、オペレータはコンピュータシステムやフォントに関する知識が必要とされず操作性が向上する。また、指定のための手続きが不要なので、ファイル生成の生産性も向上する。また、あやまってフォントを埋め込んだり、あるいは埋め込み損ねるという事態を防止できる。
【００７８】
［第二の実施形態］
フォント環境取得部６０４において、第一の実施形態ではＬａｎｇｕａｇｅＩＤを取得したが、第二の実施形態においては、クライアント６０１が保持するフォントをＯＳに問い合わせ、クライアント６０１が使用可能なすべてのフォントのフェース名をフォント環境として、サーバ６０８に送信し、フォント環境に適した中間ファイルをサーバ６０８で作成する。そして、作成された中間ファイルをクライアント６０１へ送信する。以下に詳細を述べる。
【００７９】
＜第二の実施形態の処理手順＞
次に前述した第一の実施形態との相違点に着目して、第二の実施形態について説明する。第二の実施形態では、図８に示したフローチャートにおいて、ステップＳ８０１からＳ８０５までの操作・処理は第一の実施形態と同様である。第二の実施形態では、ステップＳ８０６でフォント環境を取得する際、クライアント６０１が保持するフォントをＯＳに問い合わせ、クライアントが使用可能なすべてのフォントのフェース名を図１４に示したクライアント要求テーブル１４０１内のフォント一覧１４０２へ格納する。なお、第一の実施形態で用いたクライアント要求テーブル１１０１は第二の実施形態では用いない。
【００８０】
次に第一の実施形態同様に、ステップＳ８０７からＳ８１２までの処理を行うが、中間フォーマットへの変換処理（Ｓ８１０）が、第一の実施形態と異なる。
【００８１】
＜文字描画の処理手順＞
次に第二の実施形態における、中間フォーマットへの変換の手順について詳しく説明する。基本的には、第一の実施形態に示した手順と同様であるが、文字描画に関する手順が前述した第一の実施形態の手順と異なる。ここでは、文字描画に関する手順を、図１５を用いて説明する。図１５は第１実施形態の図１２に代えて図２のステップＳ２０５，Ｓ２０６としてサーバ６０８で実行される手順である。
【００８２】
図１５において、アプリケーション６１２−１は文字描画要求を出す際、文字コード、フォント属性、描画属性を、ＧＤＩ関数を介してグラフィックエンジン６１２−２に通知する。グラフィックエンジン６１２−２は通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ６１２−３へ引き渡す（Ｓ１５０１）。
【００８３】
次に、プリンタドライバ６１２−３は、受け取ったフォントのフェース名と同一のフォントが、クライアント要求テーブル１４０１内のフォント一覧１４０２に存在するかどうか調べる（Ｓ１５０２）。フォント一覧１４０２に該当するフォントがなければ、そのフォントを埋め込む処理を行うためにＳ１５０４へ移行し、該当するフォントがあれば、Ｓ１５０５へ移行する（Ｓ１５０３）。プリンタドライバ６１２−３は、フォント属性のフェース名、文字コードを基に、前述のフォント形状情報をグラフィックエンジン６１２−２に問い合わせ取得する（Ｓ１５０４）。プリンタドライバ６１２−３は、取得した文字コード、フォント属性、描画属性とフォント形状情報を用いて中間フォーマットに沿った文字描画コマンドを生成する。一方、埋め込み処理の必要がないと判断されたフォントの場合、上記フォント形状情報の取得の必要がないため、文字コード、フォント属性、描画属性を用いて中間フォーマットに沿った文字描画コマンドを生成する（Ｓ１５０５）。
【００８４】
このほかは第１の実際形態と同様の構成及び手順となる。以上の構成及び手順により、本実施形態の文書処理システムでは、文書ファイル（中間ファイル）を再生する端末（コンピュータ）が備えているフォント形状情報については当該文書ファイルに埋め込まないために、不要なフォント形状情報により文書ファイルのサイズの拡張を防止できる。さらに、文書ファイルに埋め込まれないフォント形状情報は、当該文書ファイルを再生する端末が確実に備えているので、作成された元文書が、文字の書体も含めてそのまま再生される。
【００８５】
また、文書ファイルにフォントを組み込むかあるいは組み込まないかの判定および組み込むフォントの決定に際してオペレータを煩わせることがないために、オペレータはコンピュータシステムやフォントに関する知識が必要とされず操作性が向上する。また、指定のための手続きが不要なので、ファイル生成の生産性も向上する。また、あやまってフォントを埋め込んだり、あるいは埋め込み損ねるという事態を防止できる。
【００８６】
［第三の実施形態］
第一の実施形態では、フォント環境として、自動的にクライアントのＬａｎｇｕａｇｅＩＤを用いたが、第三の実施形態においては、クライアントが指定したＬａｎｇｕａｇｅＩＤを用いる。
【００８７】
＜第三の実施形態の処理手順＞
第三の実施形態では、フォント環境取得方法が前述した第一の実施形態と異なる。ここでは、フォント環境取得方法に関する手順のみ説明する。第三の実施形態では、第１実施形態のＳ８０２において図９のような画面を表示する代わりに、図１６のような画面をブラウザに表示する。図１６は図９に国・地域選択ボタン９０８を付け加えたものである。国・地域選択ボタン９０８をユーザがポインティングデバイスやキーボードによって押すと、選択欄９０９に示したような国・地域一覧を表示する。データ格納部６１０には、例えば図１８に示したようなＬａｎｇｕａｇｅＩＤ一覧テーブル１８０１を用意し、選択欄９０９には、図１８に示したＬａｎｇｕａｇｅＩＤ一覧テーブル１８０１内の国名１８０２をすべて選択ボタンとして表示するように記述されている。
【００８８】
それぞれの国名１８０２には、ＬａｎｇｕａｇｅＩＤ１８０３が対応付けられており、この画面上でポインティングデバイスやキーボードによってＨＴＭＬ文書の選択欄９０９に表示された国・地域を指定すると、図１１に示したクライアント要求テーブルのＬａｎｇｕａｇｅＩＤ１１０３に、ＬａｎｇｕａｇｅＩＤ一覧テーブル１８０１内の、選択された国名に対応するＬａｎｇｕａｇｅＩＤ１８０３を格納するように記述されている。
【００８９】
以降、図８のステップＳ８０３からＳ８１３の処理の内、第一の実施形態では、ステップＳ８０６にて、クライアントのＬａｎｇｕａｇｅＩＤをフォント環境取得部６０４において自動的に取得したが、第三の実施形態においては上記の手段（すなわちオペレータによる入力）でＬａｎｇｕａｇｅＩＤを取得するので、Ｓ８０６の処理は行わない。残りの処理は、第一の実施形態と同様の処理であるため省略する。
【００９０】
このように構成することで、本実施形態の文書処理システムでは、文書ファイル（中間ファイル）をサーバに要求する端末（コンピュータ）と、その文書ファイルを再生する端末とが異なる場合であっても、文書ファイルを再生する端末のＬａｎｇｕａｇｅＩＤと文書ファイルのフォントＬａｎｇｕａｇｅＩＤとが一致する場合には、フォント形状情報を当該文書ファイルに埋め込まないために、不要なフォント形状情報による文書ファイルのサイズの拡張を防止できる。すなわち、仕向地に対応した必要最小限のサイズの文書ファイルを作成できる。
【００９１】
また、文書ファイルで用いられるフォントと同一のフォントをその文書を再生する端末が備えていないとしても、再生する端末では文書で用いられているフォントと類似するフォントを用いる。このため、再生される書体等が作成された文書本来の書体と異なるものとなる場合であっても、同一言語の文字で再生されるために、再生された文書の内容を読み取ることは可能である。
【００９２】
また、文書ファイルにフォントを組み込むかあるいは組み込まないかの判定および組み込むフォントの決定に際してオペレータを煩わせることがないために、オペレータはコンピュータシステムやフォントに関する知識が必要とされず操作性が向上する。また、指定のための手続きが不要なので、ファイル生成の生産性も向上する。また、あやまってフォントを埋め込んだり、あるいは埋め込み損ねるという事態を防止できる。
【００９３】
［第四の実施形態］
第４の実施形態では、第１の実施形態または第３の実施形態において、中間ファイルをサーバ６０８から取得するのみならず、クライアント６０１からサーバ６０８にアプリケーションデータファイルをアップロードする機能を併せ持つ文書処理システムについて説明する。図１９は、第１及び第３実施形態の図８に代わって本実施形態で実行される手順であり、図２０は図９に代わってクライアントに表示されるＨＴＭＬ文書の一例である。図２０において、符号９０１〜９０７については図９と同様である。図２０にはそれらに加えてアップロードボタン２００１が含まれている。
【００９４】
また図１９においては、ステップ８０２で表示されるＨＴＭＬ文書が図２０に示すものであること、ステップＳ８０２とステップＳ８０３との間にアップロードのための手順を含むことが、図８と相違している。そこで、図８と共通する部分については説明を省略する。
【００９５】
ステップＳ８０２において図２０の画面が表示されると、ステップＳ１９０１において、アップロード操作が行われたか判定される。アップロード操作とは以下の通りである。アップロードボタン２００１が押されると、図１９（Ｂ）に示すポップアップウインドウ２０１０が表示される。これはＨＴＭＬ文書に記述されたもので良い。そしてその中で、アップロードするファイル名２０１１が既述された後、ＯＫボタン２０１２が押されることをアップロード操作とする。なおキャンセルボタン２０１３によりアップロードボタン２００１を押したことを取り消すことができる。また参照ボタン２０１４を押すことで、当該クライアント端末におけるファイルシステムを表示し、オペレータにその中から所望のファイルをアップロード対象のファイルとして選択させることができる。
【００９６】
ステップＳ１９０１でアップロード操作が行われたと判定された場合には、ステップＳ１９０２において指定されたファイル（すなわちファイル名２０１１に指定されたファイル名を持つファイル）を、ＦＴＰ等によりクライアントからサーバ６０８に送信する。このとき、ファイルに加えて、そのファイルが文字オブジェクトを含む場合には、その中で使用されているフォントもアップロードしてもよい。これは、ファイルを作成したクライアントが備えているフォントをサーバが備えているとは限らないからである。そしてこれを受信したサーバ６０８は、受信したファイルを、クライアントに提供するアプリケーションデータファイルとともにデータ格納部６１０に格納する。またフォントを同時に受信した場合には、そのフォントをサーバが備えていなければ、新たなフォントとしてシステム資源のデータベースに登録する。
【００９７】
のこりは第１実施形態及び第３実施形態と同様である。このように構成することで、本実施形態の文書処理システムは、クライアントからアップロードした文書を、サーバにより配布することができる。このほか、第１実施形態及び第３実施形態と同様の効果も奏する。
【００９８】
［第５実施形態］
第５の実施形態として、メール送信時における添付ファイルについて中間ファイルに変換する実施形態を示す。図２１にメール端末のブロック図を示す。図５と共通するコンポーネントには同一の符号を付した。この端末は、クライアントの構成に加えて、ファイル変換部、ファイル変換管理部を備えている。さらに本実施形態に特有の構成要素として、クライアント６０１のメール処理部６１６がある。メール処理部６１６は、メッセージハンドリングシステムにおけるユーザエージェント（ＵＡ）に相当するもので、電子メールクライアントソフトウエアである。ただし、後述の図２３の処理を行える点が一般のメールソフトウエアと異なる。このほかの構成については、第１実施形態のクライアント６０１またはサーバ６０８が備えている構成要素と同じものであるため、個々の要素について説明は省略する。次にまずこのようなシステムにおける本実施形態における処理の概略を説明する。
【００９９】
（０）メール処理部が起動される。
（１）電子メールの宛先をオペレータに指定させる。
（２）本文をオペレータに記入させる。
（３）添付ファイルの有無及び有る場合にはＰＤＦ化するか否かをオペレータにＵＩから指定させる。
（４）オペレータにより送信指示が出されたなら、宛先のドメイン名から宛先の国や地域を特定する。
（５）特定した国や地域で、仕向地用データベースからＬａｎｇｕａｇｅＩＤを獲得する。
（６）添付ファイルのフォントＬａｎｇｕａｇｅＩＤを獲得する。
（７）添付ファイルを中間ファイルに変換する。その際、フォントＬａｎｇｕａｇｅＩＤと宛先のＬａｎｇｕａｇｅＩＤとが一致していなければ、添付文書で使用されているフォントのフォント形状情報を中間ファイルに埋め込む。
（８）電子メールを送信する。
【０１００】
図２２に本実施形態の仕向地データベースの一例を示す。図２２は上記（４）と（５）とを同時に行える構成としている。もちろん分離したテーブルであっても良い。図２２では、仕向地データベース２２０１に、トップレベルドメイン名と、それに対応したＬａｎｇｕａｇｅＩＤとが登録されている。たとえば、トップレベルドメイン名がｊｐであれば、宛先はわが国のドメインであるから、対応するＬａｎｇｕａｇｅＩＤは１０４１である。
【０１０１】
図２３に、メールの送信指示を受けた際のメール処理部６１６による処理手順を示す。ただし、この中にはプリンタドライバにより行われる処理を含む。図２３において、まず添付ファイルが有るか判定する（Ｓ２３０１）。添付ファイルがあれば添付ファイルの中間ファイル化が指定されているか判定する（Ｓ２３０２）。この指定は、メール処理部のメール作成時のＵＩから行われる。次に、指定されている宛先ドメインのうち、トップレベルドメイン名を図２２のデータベースから検索し、対応するＬａｎｇｕａｇｅＩＤ（これをメールＬａｎｇｕａｇｅＩＤと呼ぶ。）を取得する。取得したメールＬａｎｇｕａｇｅＩＤはメモリの所定アドレスのロケーションに格納しておく（Ｓ２３０３）。
【０１０２】
この後、メール処理部６１６から、ファイル変換部に対して添付ファイルを中間ファイルへ変換する要求を発行する。ファイル変換部６１２は、アプリケーション６１２−１を起動してステップＳ２３０５を行う。アプリケーション６１２−１は、添付ファイルで使用される文字オブジェクトについて、文字コード、フォント属性、描画属性をプリンタドライバに通知する（Ｓ２３０５）。ステップＳ２３０６〜ステップＳ２３０９は、それを受けたプリンタドライバにより行われる。プリンタドライバは、ＧＤＩ関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントＬａｎｇｕａｇｅＩＤをグラフィックエンジンに問い合わせる。フォントＬａｎｇｕａｇｅＩＤは、例えば、ＴｒｕｅＴｙｐｅ（登録商標）フォントであれば、ＴｒｕｅＴｙｐｅ（登録商標）フォントテーブル内のｎａｍｅテーブルに格納されている。Ｗｉｎｄｏｗｓ（登録商標）でいえば、Ｗｉｎｄｏｗｓ（登録商標）で利用できるフォントの表である、フォントテーブル内にＴｒｕｅＴｙｐｅフォントテーブルがあり、それを参照することで取得可能である（Ｓ２３０５−１）。
【０１０３】
次に、所定のアドレスに格納されたメールＬａｎｇｕａｇｅＩＤとフォントＬａｎｇｕａｇｅＩＤとを比較する。一致していなければ、添付ファイルで使用されているフォント形状情報をオペレーティングシステムから取得する（Ｓ２３０７）。そして、フォント形状を埋め込んだ文字描画コマンドすなわち中間ファイルを作成する（Ｓ２３０８）。また、文字以外のオブジェクトのためにその他の描画コマンドを作成する（Ｓ２３０９）。
【０１０４】
こうして添付ファイルが中間ファイルに変換されたなら、メール処理部６１６は、添付ファイルをメールに添付する符号化処理を行って（Ｓ２３１０）、ネットワークに送信する（Ｓ２３１１）。
【０１０５】
ステップＳ２３０６において一致すると判定されれば、フォント形状情報は埋め込まずに添付ファイルを中間ファイル化する。また、ステップＳ２３３０２で中間ファイルかが不要と判定された場合には、添付ファイルはアプリケーションデータファイルのまま添付される。また、ステップＳ２３０１で添付ファイルがないと判定されれば、添付ファイル無しでメールは送信される。
【０１０６】
なお、ステップＳ２３０３において宛先のトップレベルドメイン名がデータベースに登録されていない場合、たとえばトップレベルドメイン名が、たとえばｎｅｔやｃｏｍなど国名でない場合には、ＵＩを介してユーザにメールＬａｎｇｕａｇｅＩＤを入力させる。
【０１０７】
以上のようにして本実施形態のメール端末によれば、電子メールの添付ファイルの中間ファイル変換処理時に、宛先ドメイン名に応じてフォント形状情報の埋め込みの有無を判定するために、添付ファイルが必要以上のサイズに拡張することを防止できる。また、添付ファイルの内容を宛先の端末（コンピュータ）において確実に再生することができる。また、フォントの埋め込みの有無をオペレータが判断する必要がなく、オペレータによる操作性を向上させることができる。また、あやまってフォントを埋め込んだり、あるいは埋め込み損ねるという事態を防止できる。
【０１０８】
［第５実施形態の変形例１］
フォントを埋め込むか否かの判定処理を更に簡略化することもできる。図２４にその手順を示す。図２４のステップＳ２４０１〜Ｓ２４０４は、図２３のステップＳ２３０１〜Ｓ２３０６に代わるものである。
【０１０９】
ステップＳ２４０１およびステップＳ２４０２はそれぞれステップＳ２３０１およびステップＳ２３０２と同様である。ステップＳ２４０３では、送信元のトップレベルドメインと宛先のトップレベルドメインとを比較する。一致していなければ、文字コードやフォント属性、描画属性をグラフィカルエンジンに通知して、文字描画を行わせる。これをグラフィカルエンジンを介して受けたプリンタドライバは、図２３のステップＳ２３０７以降の変換処理を実行する。
【０１１０】
以上のように、ドメイン名を直接比較することで、第５実施形態のメール端末におけるフォント埋め込みの判定処理を簡略化することができる。この形態では、送信元のトップレベルドメインと、宛先のトップレベルドメインが一致していた場合は、すべてのフォントを埋め込まない中間ファイルを生成する。逆に一致しなかった場合は、すべてのフォントを埋め込んだ中間ファイルを生成する。
【０１１１】
［第５実施形態の変形例２］
本実施形態は単独の端末で処理を行うものとしたが、第１実施形態のようにサーバ−クライアントシステムとすることもできる。この場合、クライアントが宛先のドメイン名から特定した国に対応するＬａｎｇｕａｇｅＩＤを、図１１のクライアント要求テーブル１１０１に登録してサーバに送信する。サーバは第１実施形態と同じ要領で処理を行い、中間ファイルをクライアントに返す。クライアントはその中間ファイルを添付ファイルとして電子メールを送信する。
【０１１２】
このようにして、クライアント−サーバシステムにおいても、添付ファイルの可読性を維持しつつ、そのサイズを必要最上限に抑制することができる。なお、本変形例は、第５実施形態の変形例１と組み合わせることもできる。
【０１１３】
なお、上記実施形態では、アプリケーション、グラフィカルエンジン、プリンタドライバの役割分担も合わせて示しているが、役割分担に関しては各実施形態に示した例に限るものではない。すなわち、各実施形態は既存のオペレーティングシステムを前提としているために一定の役割分担をさせているが、各実施形態においてプリンタドライバが行っているとしている処理手順をアプリケーションやグラフィカルエンジンにより行うことや、あるいは、その逆を行うことなどは、論理的には可能である。
【０１１４】
また、第１乃至第４実施形態はサーバ−クライアントシステムであったが、単独のコンピュータにより文書処理システムを構成することもできる。その場合、ひとつのコンピュータに、図５のクライアント６０１とサーバ６０８とを併せ持つ。
【０１１５】
また、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体およびプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１１６】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【図面の簡単な説明】
【０１１７】
【図１】従来の、アプリケーションからの印刷命令をプリンタ制御コマンドへ変換する形式の印刷制御装置の代表的な機能ブロック図である。
【図２】従来のアプリケーションからの印刷処理の一連の流れを示すフローチャートを示す図である。
【図３】文字描画に必要な情報と、印刷結果一例を示す図である。
【図４】文字描画においてフォント置き換え処理、ビットマップ置き換え処理が生じた場合の印刷結果の例を示した図である。
【図５】本発明の実施形態におけるネットワークシステムのソフトウェアブロック図である。
【図６】本発明の実施形態における、図５に示したファイル変換部内部のソフトウェアブロック図である。
【図７】クライアント及びサーバとして使用可能な情報処理装置のハードウェア構成例を示した図である。
【図８】本発明の実施形態における、ネットワークファイル変換システムの一連の流れを示すフローチャートを示す図である。
【図９】本発明の第一の実施形態における、クライアントのＷｅｂブラウザの表示画面例を示す図である。
【図１０】本発明の実施形態において用いた、データベーステーブルの一例を示す図である。
【図１１】本発明の第一の実施形態において用いた、クライアント要求テーブルの一例を示す図である。
【図１２】本発明の第一の実施形態における、アプリケーションから文字描画要求があった時の、プリンタドライバにおける処理について示したフローチャートである。
【図１３】従来の印刷システムにおいて、フォント毎にＵＩ上で設定された文字描画方法を格納するフォント設定テーブルの一例を示す図である。
【図１４】本発明の第二の実施形態において用いた、クライアント要求テーブルの一例を示す図である。
【図１５】本発明の第二の実施形態における、アプリケーションから文字描画要求があった時の、プリンタドライバにおける処理について示したフローチャートである。
【図１６】本発明の第三の実施形態における、クライアントのＷｅｂブラウザの表示画面例を示す図である。
【図１７】図１６の国・地域選択ボタン９０８が押されると表示される、国・地域一覧を示した例を示す図である。
【図１８】本発明の第三の実施形態において用いた、ＬａｎｇｕａｇｅＩＤ一覧テーブルの一例を示す図である。
【図１９】第四実施形態におけるネットワークファイル変換システムの一連の流れを示すフローチャートを示す図である。
【図２０】本発明の第四の実施形態における、クライアントのＷｅｂブラウザの表示画面例を示す図である。
【図２１】本発明の第５実施形態におけるメール端末のソフトウェアブロック図である。
【図２２】本発明の第５実施形態におけるドメイン名とＬａｎｇｕａｇｅＩＤとの対応を示す仕向地ＤＢの一例を示す図である。
【図２３】本発明の第５実施形態におけるメール端末による添付ファイル変換の流れを示すフローチャートを示す図である。
【図２４】本発明の第５実施形態の変形例１における添付ファイル変換の流れを示すフローチャートを示す図である。
【図１】
2005332088.tif 000003
【図２】
2005332088.tif 000004
【図３】
2005332088.tif 000005
【図４】
2005332088.tif 000006
【図５】
2005332088.tif 000007
【図６】
2005332088.tif 000008
【図７】
2005332088.tif 000009
【図８】
2005332088.tif 000010
【図９】
2005332088.tif 000011
【図１０】
2005332088.tif 000012
【図１１】
2005332088.tif 000013
【図１２】
2005332088.tif 000014
【図１３】
2005332088.tif 000015
【図１４】
2005332088.tif 000016
【図１５】
2005332088.tif 000017
【図１６】
2005332088.tif 000018
【図１７】
2005332088.tif 000019
【図１８】
2005332088.tif 000020
【図１９】
2005332088.tif 000021
【図２０】
2005332088.tif 000022
【図２１】
2005332088.tif 000023
【図２２】
2005332088.tif 000024
【図２３】
2005332088.tif 000025
【図２４】
2005332088.tif 000026