JP4585039B2 - アプリケーションからの視覚的形式の情報をデータベースに格納しデータベースから検索する情報格納および検索システム - Google Patents

Description

本発明は、情報格納および検索システムに関するものであり、特に、アプリケーションからの視覚的形式の情報をデータベースに格納しデータベースから検索する情報格納および検索システムに関する。

一般に、コンピュータプログラムは、多種のフォーマットでデータを保持する。通常、生データが永続的に格納される各コンピュータプログラムに対し、一意の、一般にプロプラエタリ（proprietary）の一つのフォーマットがある。このフォーマットは、通常、実際に格納される情報の量を低減するよう、場合によっては、第三者がデータにアクセスする能力を制限するよう設計されている。このフォーマットのデータは、概して、コンピュータプログラムの「保存（save、セーブ）」ファンクションによって生成される。セーブファンクションは、生データをフォーマットし、そのフォーマットされた生データは、コンピュータプログラムが設計されている対象のオペレーティングシステムによって定義される「ファイル（file）」と呼ばれる更に他のフォーマットで、格納される。コンピュータプログラムによって処理されているデータは、「データ構造（data structure）」と呼ばれる一般にプロプラエタリの別のフォーマットで格納され、このデータは概してそのコンピュータプログラムの実行中に揮発性または作業メモリに格納される。通常、データ構造は、データを表現するために必要なメモリの量を最小限にする一方で、データがコンピュータプログラムによって効率的に処理されることができるように設計されている。

多くのコンピュータプログラムを用いるとき、ユーザの立場から最も有用なデータの形式は、その視覚的形式、例えば、コンピュータディスプレイに表示されるものまたは印刷されるもの等である。しかしながら、このデータの形式はしばしば、それがプリントされそのプリントされた形式が電子的に走査されない限り、永久的または永続的な記憶装置に取込まれない。特に、コンピュータプログラムによって使用されるファイルフォーマットは、いくつかの理由によりしばしば視覚的形式でデータを保持しない。概して、視覚的形式のデータは、より多くの情報を表現する必要があり、表現する必要のある情報が少ない生データから再構成することができる。従って、概して、視覚的形式のデータを保存する必要は不要であると考えられている。

コンピュータプログラムによって生成される視覚的形式のデータの一部は、例えば、環境データ（日付および時間等）から又は処理中のユーザ選択のデータから生成され、ファイルフォーマットからは回復不可能であり、コンピュータプログラムのデータ構造からのみ回復可能である。データ構造によっては視覚的形式のデータを表すが、しばしば、プリント以外の方法で視覚的形式のデータを保持する機構が無い。オペレーションシステムによっては、「カット・アンド・ペースト（cut-and-paste）」オペレーションを用いて、表示されたデータを１つのコンピュータプログラムから他のコンピュータプログラムにコピーすることができるものもあるが、このオペレーションは概して、他のコンピュータプログラムが同じマシン上で動作中であることを必要とする。また、コンピュータプログラムによっては、ユーザが利用可能なこれらオペレーションを有していないものもある。いくつかのコンピュータプログラムについては、表示データではなくプリント形式のデータが最も有用であり、このオペレーションは、プリントされたデータに対するアクセスを提供しない。

コンピュータプログラムからの視覚的形式のデータが格納される場合であっても、コンピュータプログラムの新たなバージョンが使用される場合や、あるいはコンピュータプログラムがもはや使用できない場合には、そのデータへのアクセスが妨げられる。また、そのデータがプロプラエタリフォーマットで格納されている場合、他のコンピュータプログラムもそのデータにアクセスすることができない。

このようにコンピュータプログラムからの視覚的形式のデータにアクセスすることができないことにより、この形式のデータが複数のデータ源から複合文書を作成するために要求される時、特に、データが、複数の異なるユーザによって地理的に分散している複数の異なるコンピュータプログラムを用いてある期間にわたって生成され、使用され、共有されている場合に、多種の問題が発生する。特定の例として、製薬業界において、データが、非常に長い期間にわたって、地理的に分散した研究所の多くの実験器械から取得され、その後、例えば法規遵守に対しての報告書を作成するために組み合わされる場合がある。中央で、これら器械からの電子的な視覚的形式のデータにアクセスすることができないことにより、法規遵守に対してのかなりのコストが加わることになる。

かかる文書（ドキュメント）に対する共有される電子的なアクセスを提供するための電子的に走査するプリントされた文書には、いくつかの欠点がある。第１に、走査は、時間と人員の努力を含むかなりの資源を消費する。第２に、文書の生成と、他者が利用可能となるまでの間にかなりの時間的遅延が発生する可能性がある。第３に、走査によって作成されるビットマップ画像は、スケーリングされるか、回転されるか、または他の方法で変換される場合に、ゆがむことになる。第４に、走査された文書においてテキストのサーチを可能にするために、走査された文書を光学式文字認識（ＯＣＲ）ソフトウェアによって処理しなければならない。

データの格納に伴う他の問題は、データが格納された時と、データが使用される時との間で、故意にまたは偶発的にデータの完全性が損なわれる（折衷される）場合があるということである。規制または行政の認可を得るためにデータが使用されている場合、そのデータの完全性はある程度保証されることが要求される。

視覚的形式のデータは、コンピュータプログラムから受取られ、データベースに格納されることが可能である。視覚的形式のデータは、例えば、コンピュータプログラムまたはオペレーションのカット・アンド・ペーストシーケンス等の他のオペレーションまたは他のアプリケーションへのデータの送出によるプリントオペレーションに応答して、受取ることが可能である。視覚的形式のデータは、スケーラビリティ（スケーリング性）を可能にするベクトル画像として格納することができる。視覚的形式のデータは、データベースのサーチを容易にするために、他の識別情報またはタグと共にデータベースに格納される。データベース内のデータは、データの完全性を保証し、データが折衷にされた時の検出を可能にする方法で符号化されることが可能である。１つの実施の形態では、データベースのデータの符号化および復号化を実行することによりデータベースへのアクセスを制御するためにサービスレイヤアプリケーションが提供される。サービスレイヤは、多くのアプリケーションがデータベースにアクセスすることができるようにするアプリケーションプログラミングインタフェースを有することができる。データベースからの視覚的形式のデータにアクセスするため、および他のコンピュータプログラムへこのデータを提供するために、別のアプリケーションが提供されてもよい。かかるアプリケーションにより、ユーザは、他のコンピュータプログラムを使用してデータベース内のデータから複合文書を作成することができる。

従って、以下では、本発明の態様のいくつかを単独であるいは或る組合せで表している。本発明の多種の態様は、コンピュータが実現するプロセス、コンピュータシステム、または具体的な情報記録または送信媒体に符号化されたコンピュータ読出し可能コードを備えたコンピュータプログラム製品とすることができる。本発明の更に他の態様は、一例としての実現方法の以下の詳細な説明およびそれに対する変更態様から明らかとなろう。

一態様において、視覚的形式の情報は、コンピュータ上で実行されるアプリケーションからデータベースに取込まれる。視覚的形式のデータは、アプリケーションから受取られる。その視覚的形式のデータに対応するタグもまた受取られる。ベクトル画像としての視覚的形式のデータおよびタグは、データベースに格納される。

他の態様において、コンピュータ上で実行されるアプリケーションからの視覚的形式のデータを格納するデータベースは、視覚的形式のデータに対応するタグとその視覚的形式のデータに対する参照を格納する第１のテーブルと、視覚的形式のデータをベクトル画像としてその視覚的形式のデータに対する参照と共に格納する第２のテーブルとを含むことができる。

他の態様において、１または複数のコンピュータ上で実行されるアプリケーションからの視覚的形式のデータがベクトル画像として格納されるデータベースが、アクセスされる。このデータベースは、１または複数のベクトル画像を識別するためにサーチすることができるものである。識別されたベクトル画像は、その識別されたベクトル画像に関連するタグに従ってソートされる。ユーザは、識別されたベクトル画像のうちの１または複数を選択することができ、それらはその後表示される。表示されたベクトル画像はスケーリングされることができ、そのスケーリングされたベクトル画像が表示される。選択されたベクトル画像内のテキストもまた、サーチすることができる。

他の態様において、視覚的形式のデータの選択された部分は、第１のアプリケーションから第２のアプリケーションにへ送られる。視覚的形式のデータの選択された領域の指示は、第１のアプリケーションにおいて受取られる。第２のアプリケーションの指示もまた、受取られる。データを第２のアプリケーションにペーストするための第２のアプリケーションにおけるキーストロークが、決定される。視覚的形式のデータの選択された領域を表すデータが決定され、第２のアプリケーションがデータをペーストするメモリ領域へ転送される。その決定されたキーストロークは、第２のアプリケーションへ送出される。

他の態様において、視覚的形式のテキストデータが、表形式構造に挿入するために、文字区切りされた（character delimited）テキストデータに変換される。視覚的形式のデータの選択された領域の指示が受取られる。テキストのすべての行に対しての水平方向の範囲に沿っての選択された領域内のテキストの存在を表すデータが、初期設定される。初期設定されたデータは、テキストのすべての行についての水平方向の範囲に沿っての選択された領域内のテキストの存在を示すよう変更される。文字区切りデータ（文字区切りされたデータ）は、行におけるテキストとその行において識別されたカラムの境界とに従って生成される。

他の態様において、テキストとそのテキストを配置するための水平座標および垂直座標とを識別するコマンドを含むベクトル画像内のテキストが、サーチされる。ベクトル画像におけるコマンドは、垂直座標に従ってソートされ、次に水平座標に従ってソートされる。順序付けられたコマンドからのテキストの順序付けを表すリスト構造が生成される。このリスト構造は、二重連係リストであってもよい。このリスト構造は、互いに近接するテキストストリングを組合せ、それによって、テキストが複数のテキストレコードにわたって分割されていても、そのテキストを配置することができる。選択された各メタファイルのテキストは処理されて順序付けされたリストとなり、それによってワードを、各メタファイル内にそれらが現れる順序でサーチすることが可能となる。また、かかる順序付けによって、メタファイル内およびメタファイルのセット間で、前の又は次のワード又は他の文字（キャラクタ）ストリングの発生を識別することが可能となる。この技術を用いて、多くの異なるアプリケーションからの文書（ドキュメント）を一緒にサーチすることができる。

他の態様において、サービスレイヤによってデータベースへのアクセスが制御される。データベースにデータを格納するための要求に応答して、データが符号化され、そのデータに対してエラーチェック計算が実行される。その符号化されたデータおよびエラーチェック計算の結果は、データベースに格納される。データベースからデータを読出すための要求に応答して、読出されたデータが復号化され、その読出されたデータに対してエラーチェック計算が実行される。その読出されたデータのエラーチェック計算の結果は、格納されたデータに対して実行されたエラーチェック計算の格納された結果と比較されることにより、あらゆる不一致が識別される。復号化された読出しデータと、格納されたデータと読出されたデータとの間で識別されるあらゆる不一致の指示とが提供される。

他の態様では、視覚的形式のデータをその視覚的形式のデータを識別する対応するタグと共に格納するデータベースである。アプリケーションを実行する複数のコンピュータの各々は、複数の異なるアプリケーションのうちの１つからの視覚的形式のデータと、その視覚的形式のデータに対応するタグとを受取る。ベクトル画像としての視覚的形式のデータと対応するタグとは、データベースに格納される。複数のコンピュータのうちの１つにおけるアプリケーションは、データベースに対するクエリに応答して、データベースからのタグおよび視覚的形式のデータにアクセスする。別のアプリケーションを用いて、データベースから検索された視覚的形式のデータを含む文書を生成し、それをデータベースに格納してもよい。

他の態様において、ベクトル画像が処理されることにより、ベクトル画像のテキストのスケーリングが可能となる。テキストに対応するベクトル画像のコマンドが識別される。識別されたコマンドにおける指定されたフォントを、拡大縮小可能（スケーラブル）フォントに変更することができる。文字間余白（文字間スペース）もまた付加することができる。テキストの回転およびスケーリング（拡大縮小）もまた変更することができる。

他の態様において、データベースに格納されたコンピュータ上で実行されるアプリケーションからの視覚的形式のデータから、複合文書を生成することができる。アプリケーションからの視覚的形式の情報は、アプリケーションから視覚的形式のデータを受取り、視覚的形式のデータに対応するタグを受取り、ベクトル画像としての視覚的形式のデータとタグとをデータベースに格納することにより、データベースに取込まれる。アプリケーションからの視覚的形式の情報は、データベースから検索される。複合文書は、データベースから検索される視覚的形式の情報から生成される。視覚的形式の複合文書は、アプリケーションから視覚的形式の複合文書を受取り、視覚的形式の複合文書に対応するタグを受取り、ベクトル画像としての視覚的形式の複合文書とタグとをデータベースに格納することにより、データベースに取込まれる。

図１は、アプリケーションからの視覚的形式のデータをデータベースに格納するための情報格納および検索システムを示すブロック図である。 図２は、Ｗｉｎｄｏｗｓ（登録商標）環境におけるプリントプロセスのオペレーションを示すブロック図である。 図３は、データベースに対するデータベーステーブル構造の略図である。 図４は、データベースに対する他のデータベーステーブル構造の略図である。 図５は、データベースに対する他のデータベーステーブル構造の略図である。 図６は、データベースに対する他のデータベーステーブル構造の略図である。 図７は、データベースへのアクセスを調整するサービスレイヤを有する図１の情報格納および検索システムを示すブロック図である。 図８は、データベースのソートおよびフィルタリングを示すデータフロー図である。 図９は、データベースにおけるレコードのコピーを示すデータフロー図である。 図１０は、データベースからのレコードの削除を示すデータフロー図である。 図１１は、クエリインタフェースからのレポートの印刷、プレビューまたは送出を示すデータフロー図である。 図１２は、レポートのプレビューを示すデータフロー図である。 図１３は、他のアプリケーションへのレポートの送出を示すデータフロー図である。 図１４は、スプールファイルの処理を説明するフローチャートである。 図１５Ａ〜図１５Ｂはスプールファイルのフォント処理を説明するフローである。 図１５Ａ〜図１５Ｂはスプールファイルのフォント処理を説明するフローである。 図１６は、スプールファイルのテキスト処理を説明するフローチャートである。 図１７は、テキストデータをいかに、文字区切りデータ、特にスプレッドシート用のテーブルに挿入するためのタブ区切りデータに変換することができるかを説明するフローチャートである。

コンピュータプログラムから視覚的形式のデータを受取ることにより、およびそれをデータベースに格納することにより、多くの利点を得ることができる。アプリケーションまたはコンピュータプログラムからの視覚的形式のデータは、表示または印刷のために、アプリケーションまたはコンピュータプログラムによってデータから生成されるあらゆる画像またはその一部である。画像は、あらゆる表示または印刷装置において表示または印刷されるピクチャエレメント（画素）のマトリクスを定義するあらゆるデータである。概して、各画素は、グレイスケールまたはカラーパレットのいずれかからデータにより定義される。ベクトル画像は、描画コマンドによって指定される画像である。形状の例には、ライン、ポリゴン、オブジェクトおよびテキストがある。描画コマンドが目的の表示または印刷装置に関して解釈されることにより、画素のマトリクスに対して値が生成される。概して、ベクトル画像は、例えばスケーリング、回転またはフリップ等のような変換を施すことができる。ビットマップ画像は、画像の各画素を指定するマトリクス値によって指定された画像である。また、ビットマップ画像は、ラスタ画像としても知られている。ビットマップ画像は、ベクトル画像内に含まれることができる。

概して、大抵のアプリケーションは、データを、表示装置に表示するためにベクトル画像またはビットマップ画像のいずれかとして視覚的形式に変換する。また、アプリケーションは、オペレーティングシステムに対するファンクションコールを用いて、視覚的形式のデータを印刷する。これらファンクションコールに応答して、一般に、オペレーティングシステムは、プリンタを制御するためにプリンタによってビットマップ画像に翻訳されるベクトル画像を生成する。

ここで図１を参照して、アプリケーションからの視覚的形式のデータをデータベースに取込む情報格納および検索システムについて説明する。図１において、アプリケーション５０は、汎用コンピュータ上で実行され、ユーザにより、表示または印刷することができる視覚的形式を有する情報を生成するために使用される。この視覚的形式は、汎用コンピュータのオペレーティングシステム５４によって定義されるフォーマットで、情報格納および検索システムにおいてデータベース６４に取込まれる。アプリケーション５０は、オペレーティングシステム５４に対し、視覚的形式（ビジュアルフォーム）のデータを表すデータ５６を生成させるファンクションコール５２を行う。概して、かかるデータ５６は、ベクトル画像の形式である。概して、かかるファンクションコールは、オペレーティングシステム５４によって、アプリケーション５０等のアプリケーションがプリンタに対してデータを印刷することができるようにするために提供される。それにより、データベース格納モジュール５８によってデータ５６が読出され、レポート６０としてタグ６２と共にデータベース６４に格納される。タグ６２は、以下により詳細に述べるように、レポートに対する識別情報を含み、該レポートはユーザ入力５７によって提供される情報を含むことも可能である。

印刷などの一般的なオペレーションを実行するプロセスにおいて、アプリケーションによって作成されるファンクションコールからウインドウズ（Ｗｉｎｄｏｗｓ（登録商標））オペレーティングシステムへの出力により、データベース格納モジュールは、複数のアプリケーションからのプロプラエタリ（proprietary）データフォーマットを処理するよう設計される必要はない。概して、いかなるオペレーティングシステムに対しても、印刷などの標準フォーマットにおいて、あるアプリケーションから他のアプリケーションへのオペレーションの出力を取込んで標準形式でデータベースに格納することができる。アプリケーション５０等のアプリケーションは、視覚的形式のデータをデータベースに格納するためにデータベースとの通信を処理するよう設計される必要はない。

レポート６０がデータベースに格納された後、データベース検索モジュール６６は、クエリ６８を通してデータベースにアクセスすることにより、１つまたは複数のレポート７０と１つまたは複数のタグ７２を検索する。データベース検索モジュール６６は、後により詳細に説明するように、データベースレコードの変更、コピー、移動、削除、読出、および他の方法での処理等の、任意の数のデータベース管理タスクをサポートするよう実現することができる。クエリインタフェース７６により、ユーザは、データベースにおいてレポートをサーチ、ソート、フィルタリングするためのパラメータを入力することができる。フィルタリングされたまたはソートされたレポートに関連するタグの集合は、ユーザがレビューするためにクエリインタフェース７６に供給される。選択されたレポートは、クエリインタフェース７６を通して使用可能なコマンドにより、レポートプレビューワ８０または他のアプリケーション８４に供給することができる。

レポートプレビューワ８０は、データベース検索モジュール６６を介して、ユーザに対してレポートを表示するためのレポート７８およびタグ７４を受取る。後により詳細に説明するように、レポートプレビューワ（previewer）により、ユーザは、他のアプリケーション８４に伝達または送信されるレポートまたはレポートの一部８２を選択するために入力８１を与えることができる。この他のアプリケーション８４を使用することにより、データベースに格納されデータベースから検索される多くのレポートから、複合ドキュメント（文書）をコンパイルすることができる。また、この複合文書も、アプリケーション５０がデータベースにデータを格納するのと同じ方法でデータベース６４に格納することができる。

図１に示すような情報格納および検索システムの多種の構成要素は、汎用コンピュータシステムを用いるコンピュータプログラムとして実現することができる。一般に、かかるコンピュータシステムは、ユーザに情報を表示する出力装置とユーザから入力を受取る入力装置との両方に接続されたメインユニットを有する。概して、メインユニットは、相互接続機構を介してメモリシステムに接続されたプロセッサを有している。また、入力装置および出力装置も、相互接続機構を介してプロセッサおよびメモリシステムに接続されている。

なお、コンピュータシステムには、１つまたは複数の出力装置を接続することができる。出力装置の例には、陰極線管（ＣＲＴ）ディスプレイ、液晶ディスプレイ（ＬＣＤ）および他のビデオ出力装置、プリンタ、モデム等の通信装置、ディスクまたはテープ等の記憶装置がある。なお、コンピュータシステムには１つまたは複数の入力装置を接続することができる。入力装置の例には、キーボード、キーパッド、トラックボール、マウス、ペンおよびタブレット、通信装置、データ入力装置がある。

コンピュータシステムは、「Ｃ＋＋」、Ｖｉｓｕａｌ Ｂａｓｉｃ、ＪＡＶＡ（登録商標）、あるいはスクリプト言語またはアセンブリ言語等の他の言語等のコンピュータプログラミング言語を用いてプログラム可能な汎用コンピュータシステムとすることができる。汎用コンピュータシステムにおいて、プロセッサは、一般に、Ｉｎｔｅｌ（登録商標）（インテル）から入手可能なｘ８６シリーズ、Ｐｅｎｔｉｕｍ（登録商標）（ペンティアム）およびＣｅｒｅｌｏｎ（登録商標）（セルロン）プロセッサ、ＡＭＤおよびＣｙｒｉｘ（サイリックス）からの同様の装置、Ｍｏｔｏｒｏｌａ（登録商標）（モトローラ）から入手可能な６８０Ｘ０シリーズのマイクロプロセッサ、ＩＢＭ（登録商標）からのＰｏｗｅｒＰＣ（登録商標）マイクロプロセッサ等の、商業的に入手可能なプロセッサである。多くの他のプロセッサが使用可能である。かかるマイクロプロセッサは、オペレーティングシステムと呼ばれるプログラムを実行する。Ｗｉｎｄｏｗｓ（登録商標）ＮＴ、Ｗｉｎｄｏｗｓ（登録商標）９５または９８、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ、Ｓｏｌａｒｉｓ、ＯＳ／２、ＤＯＳ、ＶＭＳ、ＭａｃＯＳ（登録商標）およびＯＳ８がその例であり、これは他のコンピュータプログラムの実行を制御し、スケジューリング、デバッギング、入力／出力制御、アカウンティング、コンパイル、記憶域割当て、データ管理およびメモリ管理、通信制御および関連するサービスを提供する。プロセッサおよびオペレーティングシステムは、高水準プログラミング言語のアプリケーションプログラムが書かれている対象であるコンピュータプラットフォームを定義する。

一般に、メモリシステムには、コンピュータ読出し可能および書込み可能の不揮発性記録媒体があり、磁気ディスク、フラッシュメモリおよびテープがその例である。ディスクは、フロッピディスクとして知られるように取り外し可能でもよく、ハードドライブとして知られるように常置でもよい。ディスクは、信号が一般にバイナリ形式、すなわち１および０のシーケンスとして解釈される形式で格納される多くのトラックを有している。かかる信号は、マイクロプロセッサによって実行されるアプリケーションプログラムか、またはアプリケーションプログラムによって処理されるディスクに格納される情報を定義することができる。一般に、動作中、プロセッサは、不揮発性記録媒体から、一般にダイナミックランダムアクセスメモリ（ＤＲＡＭ）またはスタティックメモリ（ＳＲＡＭ）等の揮発性ランダムアクセスメモリである集積回路メモリ素子にデータが読出されるようにする。集積回路メモリ素子は、プロセッサにより、ディスクよりも高速に情報へアクセスすることができるものである。概して、プロセッサは、集積回路メモリ内のデータを処理した後、処理が完了した時にそのデータをディスクにコピーする。ディスクと集積回路メモリ素子との間のデータの移動を管理するための多種の機構が知られており、本発明はそれに限定されるものではない。また、本発明は、特定のメモリシステムに限定されるものでもない。

かかるシステムは、ソフトウェア、ハードウェア、ファームウェア、またはその３つの組合せで実現することができる。システムの多種の要素は、個々にあるいは組合せで、コンピュータプロセッサによって実行されるために機械読出し可能記憶装置に具体的に実現されたコンピュータプログラム製品として実現することができる。プロセスの多種のステップは、コンピュータ読出し可能媒体で具体的に実現されたプログラムを実行するコンピュータプロセッサにより実行して、入力に処理を行い、出力を生成することによりファンクションを実行する。かかるシステムを実現するために適したコンピュータプログラミング言語には、手続き型プログラミング言語と、オブジェクト指向プログラミング言語と、その２つの組合せとがある。

なお、本発明は、特定のコンピュータプラットフォーム、特定のプロセッサまたは特定のプログラミング言語に限定されるものではない。更に、コンピュータシステムは、マルチプロセッサコンピュータシステムであってもよく、あるいはコンピュータネットワークを介して接続された複数のコンピュータを含むものでもよい。なお、図１に示す構成要素および残りの図面に示すそれらの副構成要素は、コンピュータプログラムの個別のモジュールであってもよく、あるいは別個のコンピュータ上で動作可能な別個のコンピュータプログラムであってもよい。これら構成要素によって生成されるデータは、メモリシステムに格納されてもよく、あるいはコンピュータシステム間で送信されてもよい。

図１に示すシステムはコンピュータネットワークを用いて実現することができ、それによってアプリケーション５０、オペレーティングシステム５４およびデータベース格納モジュール５８が１つのコンピュータ上で実行され、データベース６４が他のコンピュータ上で実行され、データベース検索モジュール６６、リポートプレビューワ８０および他のアプリケーション８４が更に別のコンピュータ上で実行されるようにできる。データベース検索モジュール６６を備えた多くのコンピュータ、データベース格納モジュール５８を備えた多くのコンピュータおよび多くのデータベース６４がある。１つのコンピュータが、そのアプリケーション５０、８４と共に使用するためのデータベース検索モジュールとデータベース格納モジュールとの両方を有することができる。また、１つのコンピュータが、アプリケーション５０、８４と共に、データベース検索モジュールとデータベース格納モジュールとデータベースとを有することができる。ネットワークにおける多種の可能なコンピュータの構成により、データが、複数の異なるユーザにより地理的に分散された複数の異なるコンピュータプログラムを用いてある期間にわたって生成され、使用され、共有される場合であっても、多くのユーザが複数のデータ源から複合文書を生成することができる。

ここで、図１の多種のモジュールをより詳細に説明する。アプリケーション５０、８４は、汎用コンピュータのオペレーティングシステム５４によって実行することができるいかなるアプリケーションともすることができる。アプリケーションの種類の例には、限定されないが、研究所の器械制御およびデータ分析プログラム、ワードプロセシングプログラム、グラフィクスプログラム、スプレッドシートプログラムがある。

データベース６４は、リレーショナルデータベース、オブジェクト指向データベース、非構造化データベースまたは他のデータベースを含むあらゆる種類のデータベースとすることができる。リレーショナルデータベースの例には、カリフォルニア州レッドウッドシティのオラクル社（Ｏｒａｃｌｅ（登録商標） Ｃｏｒｐｏｒａｔｉｏｎ）からのＯｒａｃｌｅ（登録商標） ８ｉ、カリフォルニア州メンロパークのインフォミックスソフトウエア社（Ｉｎｆｏｒｍｉｘ Ｓｏｆｔｗａｒｅ，Ｉｎｃ．）からのＩｎｆｏｒｍｉｘ Ｄｙｎａｍｉｃ Ｓｅｒｖｅｒ、ニューヨーク州ヨークタウンハイツのインターナショナルビジネスマシンズ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ）からのＤＢ２、ワシントン州レッドモンドのマイクロソフトコーポレーション（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）からのＡｃｃｅｓｓがある。オブジェクト指向データベースの例は、マサチューセッツ州バーリントンのオブジェクトデザイン（Ｏｂｊｅｃｔ Ｄｅｓｉｇｎ）からのＯｂｊｅｃｔＳｔｏｒｅである。非構造化データベースの例は、マサチューセッツ州ケンブリッジのロータスコーポレーション（Ｌｏｔｕｓ Ｃｏｒｐｏｒａｔｉｏｎ）からのＮｏｔｅｓである。また、データベースは、フラットファイルシステムを用いて、例えば、以前はボーランドインターナショナル社（Ｂｏｒｌａｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｒｐ．）であるカリフォルニア州スコッツバレーのインプライズ社（Ｉｎｐｒｉｓｅ Ｃｏｒｐ．）からのＶｉｓｕａｌ ｄＢＡＳＥとして現在知られているｄＢＡＳＥの初期のバージョンにおけるような、文字区切り（character-delimited）フィールドを有するファイルを用いることにより、構成することもできる。

オペレーティングシステム５４は、例えば、マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８またはＷｉｎｄｏｗｓ（登録商標）ＮＴとすることができる。このオペレーティングシステムを用いて、データベース６４は、オープン・データベース・コネクション（ＯＤＢＣ）プロトコルを通してアクセスすることができる。他のオペレーティングシステムの例は上述されている。本発明は、いかなる特定のオペレーティングシステムにも、本明細書で述べられたものにも限定されない。いかなる特定の実施形態で使用されるオペレーティングシステムも、オペレーティングシステムがプリントドライバまたは他のアプリケーションによってアクセスされるための視覚的形式のデータを生成するようにいずれのコマンドをアプリケーションが使用するかに、影響を与える。以下の説明において、Ｗｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８およびＷｉｎｄｏｗｓ（登録商標）ＮＴオペレーティングシステムは単に例示的なものである。他のオペレーティングシステムを、それらの出力がどのように使用されるか、およびオペレーティングシステムの仕様に従ってシステムのモジュール間でどのように制御が調整されるかに対する対応する変更を行って使用してもよい。以下の説明は、アプリケーションからＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムへのファンクションコール、例えば、プリントコマンドをいかに使用して、アプリケーションからデータベースにデータを転送するかを示す。オペレーティングシステムに対する他のファンクションコールもまた、使用することができる。視覚的形式のデータを、標準形式で、あるアプリケーションから他のアプリケーションに転送する他の機構もまた使用することができる。

Ｗｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８およびＷｉｎｄｏｗｓ（登録商標）ＮＴオペレーティングシステムを用いて、データをプリントするためのアプリケーションからのファンクションコールに応答してオペレーティングシステムによって出力される視覚的形式のデータを表すデータ５６は、マイクロソフトによるＷｉｎｄｏｗｓ（登録商標） Ｍｅｔａｆｉｌｅ（ウインドウズメタファイル）フォーマットである。メタファイルは、ベクトル画像か、または、コマンド、描画オブジェクト、テキストおよびスタイルを制御するコマンドのリストである。理論上、メタファイルはいかなるＷｉｎｄｏｗｓ（登録商標）アプリケーションにおいても使用することができる。Ｗｉｎｄｏｗｓ（登録商標）メタファイル（ＷＭＦ）は、Ｗｉｎｄｏｗｓ（登録商標）３．１によってサポートされる１６ビットメタファイルである。エンハンスドメタファイル（ＥＭＦ）は、Ｗｉｎｄｏｗｓ（登録商標）９５、Ｗｉｎｄｏｗｓ（登録商標）９８およびＷＭＦコマンドのスーパセットを有するＷｉｎｄｏｗｓ（登録商標）ＮＴによってサポートされる３２ビットエンハンスドメタファイルである。

ここで図２を参照すると、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムにおけるプリントのオペレーションと、アプリケーションからデータベースへの視覚的形式のデータを取込むためのその使用とが説明される。Ｗｉｎｄｏｗｓ（登録商標）環境においてプリンタでプリントするために、そのプリンタは関連するプリントドライバ９０を有している。プリンタがインストールされると、オペレーティングシステムには、プリントドライバの位置、すなわちそのファイル名が通知される。プリントドライバは、プリンタの特性をオペレーティングシステムに指定する。

アプリケーション５０（図１におけるような）により、ユーザは、メニューを有するグラフィカルユーザインタフェース等のユーザインタフェースを通してプリンタを選択することができる。また、選択されたプリンタは、選択が可能な多種のプリントオプションを有していてもよい。ユーザ入力に応じてアプリケーションによって作成されるファンクションコールを介して、ユーザは、ユーザに対しユーザ情報およびプリントプリファレンスの指定を可能にするプリントドライバについてのユーザインタフェース９４を呼び出すことができる。選択されたプリンタ、プリファレンスおよびプリント（印刷）対象の情報が与えられると、アプリケーション５０は、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムの一部であるグラフィクス・デバイス・インタフェース（Ｇｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）（ＧＤＩ−３２）９２へファンクションコールを発行する。ＧＤＩ−３２は、選択されたプリントドライバ９０およびそのユーザインタフェスに対しプリンタに関する情報を要求し、その情報はアプリケーション５０に戻され、ＧＤＩ−３２によって保持されることにより、選択された情報を印刷するためにオペレーティングシステムに対するファンクションコールの正確なシーケンスを生成する処理を補助する。

ＧＤＩ−３２は、スプールファイル９８にデータを出力し、スプールファイルの名前を含むファンクションコールをスプーラプロセス９６に対して行うことにより、それら指定されたプリンタに印刷するためにスプールファイルを待ち行列に入れる。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムにおけるスプールファイルは、マイクロソフトによりＷｉｎｄｏｗｓ（登録商標）メタファイルとして設計されている。しかしながら、実際には、プリンタスプールファイルは、あらゆる参照されたまたは組込まれたメタファイルに加えてプリンタセットアップデータを含むため、真のメタファイルではない。Ｗｉｎｄｏｗｓ（登録商標）９５では、スプールファイルは、あらゆるメタファイルのファイル名を含む。Ｗｉｎｄｏｗｓ（登録商標）ＮＴでは、メタファイルはスプールファイルに組込まれる。両方の場合において、印刷文書毎に１つのスプールファイルがあり、文書の各ページは別個のメタファイルを有している。

スプーラプロセス９６には、選択されたプリンタドライバ９０に関連するプリントプロセッサ１００の位置に関して通知がなされる。スプーラプロセス９６はプリントプロセッサを呼出すことにより、スプーラプロセスがプリントプロセッサに対して待ち行列に入れた何れのスプールファイルも処理する。概して、一般的なプリントプロセッサは、スプーラプロセス９６からスプールファイル９８を受取り、それを、プリンタ制御言語（ＰＣＬ）、ＰｏｓｔＳｃｒｉｐｔ等のプリンタによって使用されるフォーマット、一般にプロプラエタリフォーマットに変換する。印刷の代りに、図２のプリントプロセッサ１００により、オペレーティングシステムによって作成されたベクトル画像データがフォーマットされ、タグに関連付けられ、データベースに格納されるようにする。

メタファイル、プリントドライバ、プリントプロセッサ、スプーラプロセスおよびスプールファイルに関する更なる詳細は、インターネットを介してアクセス可能なマイクロソフトデベロッパネットワーク（Ｍｉｃｒｏｓｏｆｔ Ｄｅｖｅｌｏｐｅｒ Ｎｅｔｗｏｒｋ）およびマイクロソフトデベロップメントネットワークライブラリ（Ｍｉｃｒｏｓｏｆｔ Ｄｅｖｅｌｏｐｍｅｎｔ Ｎｅｔｗｏｒｋ Ｌｉｂｒａｒｙ）を通して入手することができる。

図２に示す１つの実現例では、プリントプロセッサ１００は、２つのプロセスをもたらす。第１のプロセスは、タグデータ獲得（取得）プロセス１０４であり、図７に関連して詳細は後述するが、データベースに格納されているレポートについてユーザからタグ情報を獲得する。このプロセスは、ユーザに対してユーザインタフェースを提供することにより、ユーザがタグについてデータを入力することができるようにし、そのタグを予め決められた名前を有するファイル１０５に格納する。ユーザは、各レポートについてタグを入力してもよく、またはバッチ印刷に対する要求を示してもよい。この場合、タグデータ取得プロセスは、タグの初期セットを用いて、ユーザとの対話無しでデータベースに格納される各レポートに対するタグを計算する。第２のプロセスは、データベースアクセスプロセス１０６であり、図７に関連して詳細は後述するが、ファイル１０５を通してタグデータ取得プロセス１０４からタグ情報を取得すると共に、格納されたメタファイル１０８の名前も取得する。タグおよびメタファイルは処理されてデータベース６４に送信される。

プリントプロセッサ１００はスプールファイルからデータを読出してそのデータをタグと共にデータベースに格納するが、或る場合によっては、スプールファイルのベクトル画像、例えばＷｉｎｄｏｗｓ（登録商標）メタファイルはスケーリング可能(scalable)でないことが知られている。上述した他の方法では、スプールファイルはまた真のＷｉｎｄｏｗｓ（登録商標）メタファイルではない。従って、メタファイルプロセッサ１０２は、図１４乃至図１６に関連してより詳細に後述するが、プリントプロセッサ１００からのファンクションコールに応答して、スプールファイルを処理してメタファイル１０８にし、それらのスケーラビリティを向上させ、さもなければスプールファイルを再フォーマットして、印刷されるレポートまたは文書の各ページに対して１づつの１つまたは複数のＷｉｎｄｏｗｓ（登録商標）メタファイルにする。スプールファイルの処理の結果得られるメタファイル１０８のファイル名は、プリントプロセッサ１００を介するかまたはメタファイルプロセッサ１０２により直接に、データベースアクセスプロセス１０６に対して利用可能となる。

プリントドライバ９０、プリントドライバユーザインタフェース９４、プリントプロセッサ１００、メタファイルプロセッサ１０２、タグデータ取得プロセス１０４およびデータベースアクセスプロセス１０６は、図１におけるデータベース格納モジュール５８を形成する。

ここではプリントドライバとプリントプロセッサが、アプリケーションから視覚的形式のデータをいかにしてデータベースに格納するかを説明したが、次に、このデータが格納されるデータベースについてより詳細に説明する。データベースは、選択されたデータベースのタイプに適当な構成を用いてレポートおよびタグを格納する。格納される情報の種類、すなわちタグには、例えば、レポートに関する情報、コンピュータ環境情報、ユーザ情報、編成情報、日付および時間情報などのいかなる組合せをも含むことができる。また、多種の他の情報も、所望されるように、データベース構成に適当な変更を行って格納することができる。レポートに関する情報の例には、レポート名、ページ数およびそのレポートが準備されるプロジェクトと、ユーザコメントと、ソースアプリケーションと、あらゆるバッチ識別子とがある。コンピュータ環境情報の例には、レポートを生成したアプリケーションの名前および／またはバージョン、マシン識別子、マシン位置、オペレーティングシステム、マシンについてのあらゆるグループ名またはドメイン名がある。ユーザ情報の例には、ログイン名等のユーザ識別子、コンタクト情報がある。編成情報の例には、ユーザのタイトル、そのユーザが所属するグループ名がある。

図３乃至図６は、リレーショナルデータベースにレポートおよびタグを格納するデータベース方式の例を示す。なお、他のいかなるデータベース方式を使用してもよく、以下の例は単に例示的なものである。オラクル（Ｏｒａｃｌｅ（登録商標））およびマイクロソフトアクセス（Ｍｉｃｒｏｓｏｆｔ（登録商標） Ａｃｃｅｓｓ）のデータベースに対して変数型が指定されている。なお、他のデータベースを使用することも可能であり、これら変数型は他のデータベースの仕様および動作に従って定義されるものである。

図３は、各レポートに対するタグ情報を有するレコードを含むメインテーブル３００を示す。このテーブルにおいて、各レポートは、データベースにプリントされ、レコードとして付加される。各レコードには、一意の識別子ＬＴＩｄが割当てられている。ＬＴＩｄは、以下に説明する図６のフィールド６０２に格納された値、ＬＴＬａｓｔＩｄを増分し更新することにより生成される。メインテーブル３００は、フィールド１、３０２、ＬＴＩｄに、Ａｃｃｅｓｓ（登録商標）（アクセス）およびＯｒａｃｌｅ（登録商標）（オラクル）の両方においてレポート識別番号である整数型の変数を含む。フィールド２、３０４において、ＬＴＶｅｒｓｏｎは、アクセスおよびオラクルの両方において整数型変数であり、レコードがデータベースに挿入された時に使用されるデータベース方式のバージョンである。フィールド３、３０６において、ＬＴＰｒｊＤｅｓｃは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（５０）型の変数であり、プロジェクトの５０文字記述である。フィールド４、３０８において、ＬＴＲｅｐＮｍｅは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（３０）型変数であり、レポート名の３０文字記述である。フィールド５、３１０において、ＬＴＲｅｐＩｄは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（１５０）型変数であり、レポート識別名の１５０文字記述である。フィールド６、３１２において、ＬＴＢｔｃｈＩｄは、アクセスおよびオラクルの両方において、Ｖａｒｃｈａｒ（３０）型変数であり、バッチ識別の３０文字記述である。フィールド７、３１４において、ＬＴＵｓｒＮｍｅは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（３０）型変数であり、ユーザ名の３０文字記述である。フィールド８、３１６において、ＬＴＵｓｒＣｍｎｔは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（２５４）型変数であり、あらゆるユーザコメントの２５４文字記述である。ユーザは、後の検索を容易にするために、このフィールドにキーワードまたは他の情報を挿入することができる。フィールド９、３１８において、ＬＴＰｒｔＤａｔは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（３０）型変数であり、プリント日付を識別する３０までの文字である。フィールド１０、３２０において、ＬＴＰｒｔＴｉｍは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（３０）型変数であり、プリント時間を識別する３０までの文字である。フィールド１１、３２２において、ＬＴＰｒｔＡｐｐは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（５０）型変数であり、ソースアプリケーションの名前の５０文字記述である。フィールド１２、３２４において、ＬＴＭａｃｈＮｍｅは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（５０）型変数であり、ソースアプリケーションが実行されたマシン名の５０文字記述である。フィールド１３、３２６において、ＬＴＤｏｍｎＮｍｅは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（５０）型変数であり、マシンが位置しているドメイン名またはワークグループ名の５０文字記述である。フィールド１４、３２８において、ＬＴＬｏｇＮｍｅは、アクセスおよびオラクルの両方におけるＶａｒｃｈａｒ（５０）型変数であり、ソースアプリケーションのユーザのログイン名の５０文字記述である。フィールド１５、３３０において、ＬＴＸＥｘｔｎｔは、アクセスおよびオラクルの両方における整数変数型であり、レポートにおけるページのＸエクステントである。フィールド１６、３３２において、ＬＴＹＥｘｔｎｔは、アクセスおよびオラクルの両方において整数変数であり、レポートにおけるページのＹエクステントである。フィールド１７、３３４において、ＬＴＮｕｍＯｆＰｇは、アクセスおよびオラクルの両方において整数型変数であり、レポートのページの数である。１つの実施形態において、このフィールドがブランクのままである場合、ページの数は、図４のテーブルからＬＴＩｄについて計算される。フィールド１８、３３６において、ＬＲＣＲＣ３２は、アクセスとオラクルの両方において整数型変数であり、レコードのタグおよび数値データのＣＲＣである。１つの実施形態において、ＣＲＣの計算された値が格納された値と一致しない場合、これは、データが破壊されていることを示す。

図４はページテーブル４００を示す。ページテーブル４００は、レポートにおけるページの数の識別を助けるレコードを含む。１つの実施形態において、各ページはページ番号を用いて識別される。この場合、ページ番号のシーケンスは１から始まる。１つの実施形態において、テーブルは、ＬＴＩｄ、レコード１、３０２とページ番号とを組合せることによってインデクスされる。フィールド１、３０２において、ＬＴＩｄは、アクセスおよびオラクルの両方において整数型変数であり、レポート識別番号である。フィールド２、４０２において、ＬＴＰｇＮｕｍは、アクセスおよびオラクルの両方において整数変数型であり、レコードのページ番号を表す。１つの実施形態において、ＬＴＩｄおよびＬＴＰｇＮｕｍは一意のレコード識別子を構成する。フィールド３、４０４において、ＬＴＰｇＩｎｆｏは、アクセスおよびオラクルの両方においてＶａｒｃｈａｒ（１００）型変数であり、ページ情報の５０文字記述である。このレコードは省略してもよい。

図５は、メタファイルデータテーブル５００を示す。メタファイルデータテーブル５００は、メタファイルを保持するレコードを含む。１つの実施形態において、プリントされた各ページは、このテーブルに格納されるメタファイルである。１つの実施形態において、メタファイルは、圧縮され符号化されることが可能であり、これは、バッファタイプを識別する特定のレコードによって識別される。データテーブル５００は、フィールド１、３０２、ＬＴＩｄにおいて、アクセスおよびオラクルの両方において整数型変数を含むことができ、これはレポート識別番号である。フィールド２、４０２において、ＬＴＰｇＮｕｍは、アクセスおよびオラクルの両方において整数変数型であり、レコードのページ番号を表す。フィールド３、５０２において、ＬＴＭＦＲＮｕｍは、Ａｃｃｅｓｓ（登録商標）とＯｒａｃｌｅ（登録商標）の両方において整数変数型であり、メタファイルレコード番号を表す。１つの実施形態において、ＬＴＩｄ、ＬＴＰｇＮｕｍおよびＬＴＭＦＲＮｕｍは、一意のレコード識別子を構成する。フィールド４、５０４において、ＬＴＭＦＢｆＴＹは、アクセスおよびオラクルの両方において整数変数型であり、メタファイルバッファ型を表す。１つの実施形態において、バッファ型は、特に、格納されたメタファイルレコードの型を識別するために使用され、１つの実施形態では、メタファイルレコードの、標準、エンハンスド、ベース６４符号化、または他の形式とすることができる。フィールド５、５０６において、ＬＴＭＦＢｆＬｎは、アクセスおよびオラクルの両方において整数変数型であり、ＬＴＭＦＢｕｆｒ、フィールド６、５０８におけるデータの長さを表す。フィールド６、５０８において、ＬＴＭＦＢｕｆｒは、アクセスではメモ(memo)変数型であり、オラクルでは長変数型であり、ブロックに格納されたメタファイルレコードの一片を含む。各ブロックは１６Ｋバイト等のサイズを有する。

図６は、コントロールテーブル６００を示す。コントロールテーブル６００は、フィールド１、６０２において、ＬＴＬａｓｔＩｄを含み、それは、アクセスおよびオラクルの両方において整数変数であり、データベースに挿入された最後のＬＴＩｄを表す。この値は、レコードが減分されずに削除される場合に、同じまま保持される。この値は、新たなエントリが１から開始するようにすべてのレコードが削除される場合に、０にリセットされる。この値は、４，２９４，９６７，２９５等の最大値を有することができる。

ここでは、データベースおよびそれがいかに構成されているかを説明したが、次に、情報を格納および検索するためのデータベースへのアクセスについて説明する。いくつかの理由により、「サービスレイヤ」と呼ばれるプログラムが提供され、これを通して他のアプリケーションがデータベースをアクセスする。例えば、サービスレイヤは、多種のデータベースオペレーションを実行するためにサービスレイヤに対して他のアプリケーションが行う単純なファンクションコールを提供することにより、アプリケーションをデータベースの複雑性から分離する。サービスレイヤは、アプリケーションからのファンクションコールに応答して、例えばＯＤＢＣコールを介して、データベースに対するオペレーションを実行する。また、サービスレイヤにおいてエラーチェックおよびデータ符号化を提供することにより、データベースにおける変更されたデータを検出することができる。

図７は、図７において「プリントドライバ」２０４として示されている、図２のプリントドライバ９０、プリントプロセッサ１００、メタファイルプロセッサ１０２、プリントドライバユーザインタフェース９４が、どのようにサービスレイヤ２００と対話するかをより詳細に示している。データベースから情報を検索する時のサービスレイヤ２００のオペレーションは、図８乃至図１３に関連してより詳細に述べる。図７において、サービスレイヤ２００は、プリントドライバ２０４が生成するレポート（メタファイル１０８）と、レポートに対するメタファイルデータを含むファイル１０８のタグと名前とを指定するファイル１０５からデータベースアクセスプロセス１０６を介してタグデータとを受取る。このデータは、ＯＤＢＣレイヤ２０６へのコールを介してサービスレイヤによりデータベース６４に格納される。ここで、プリントドライバ２０４、データベースアクセスプロセス１０６およびタグデータ取得１０４のサービスレイヤ２００との対話についてより詳細に説明する。

概して、上述したように、プリントドライバ２０４により、メタファイル１０８は、スプールファイル９８から生成され、メタファイル名はファイル１０５に格納される。また、タグデータは、タグデータ取得プロセス１０４によってファイル１０５に格納される。タグデータ取得プロセスは、プリントドライバ２０４によって、このレポートに対しユーザからタグデータを取得するために発生される。タグデータ取得モジュールは、２つのオペレーションモード、すなわちバッチとマニュアルとを有する。このオペレーションモードは、所定のアプリケーションかまたはすべてのアプリケーションに対し、プリントドライバユーザインタフェース９４を介してユーザが設定することができる。このセットアップ情報はファイル１０５に格納される。タグデータ取得プロセスが発生されると、プリント状態がセットアップパラメータから検索される。このアプリケーションに対するプリント状態がバッチプリントである場合、タグのセットは、このアプリケーションに対して予め格納されたタグから計算される。それ以外の場合は、ユーザに対してダイアログボックスが表示され、ユーザに対してタグ情報の入力が要求される。ユーザがタグ情報を入力した後、または、タグ情報が計算された後、このアプリケーションに対するタグ情報はファイル１０５に格納される。

プリントドライバ２０４により、タグおよびメタファイルをデータベースに格納するためにデータベースアクセスモジュール１０６が発生（スポーン（spawn））される。特に、データベースアクセスモジュール１０６は、データベースをオープンし、データベースによって要求されるあらゆる認証を処理する。このオペレーションを実行するために、データベースアクセスプロセス１０６は、サービスレイヤ２００に対して要求を発行し、それによりサービスレイヤ２００は、ＯＤＢＣレイヤ２０６を介して、データベースに対し、オープンしユーザをそのデータベースに対し認証して、データベーストランザクションを開始するための要求を発行する。適切にオープンして認証した後、データベースアクセスプロセス１０６は、サービスレイヤ２００に対して、ファイル１０５からのメタファイル名によって指定されるメタファイルを格納するためのリクエスト（要求）を発行する。この要求に応答して、サービスレイヤは、データベースアクセスプロセス１０６から受取ったメタファイル名に対応するメタファイル１０８を検索し、ＯＤＢＣレイヤ２０６を介して要求を発行することにより、データベースのメタファイルテーブルにそれらを格納する。データベースアクセスプロセス１０６は、サービスレイヤに対し、そのサービスレイヤ２００にタグを供給することにより、タグ情報を格納するよう要求する。サービスレイヤ２００は、ＯＤＢＣレイヤ２０６を介して要求を発行することにより、データベースのメインテーブルにタグ情報を書込む。データベースアクセスプロセス１０６は、サービスレイヤ２００に対して要求を発行することにより、データベースをクローズする。そして、サービスレイヤ２００は、データベースのトランザクションを実行し、ＯＤＢＣレイヤ２０６に対する要求を介してデータベースをクローズする。

また、サービスレイヤ２００は、データベースにレポートおよびタグを格納する一方で、より有効な格納とデータ完全性チェックとの両方も提供することができる。例えば、図７に示すように、入力される視覚的形式のデータは、データ圧縮アルゴリズムを用いて圧縮することができる。このアルゴリズムのいくつかは、本技術分野において周知である。例えばＤＣマイクロデベロップメント（ＤＣ Ｍｉｃｒｏ Ｄｅｖｅｌｏｐｍｅｎｔ）からのクラッシャ（Ｃｒｕｓｈｅｒ）ソフトウェアライブラリにおいて入手可能であるもののような無損失圧縮アルゴリズムが好ましい。循環冗長検査（ＣＲＣ）オペレーション等のエラーチェック計算を用いて、圧縮データに対するＣＲＣ値を計算することができる。データベースからデータを読出す時、読出されたデータについてのＣＲＣ値を計算し、格納された値と比較することにより、そのデータが破壊されているか否かを検出することができる。また、タグデータを処理することにより、タグデータに対してＣＲＣ値を計算することができる。データベースからタグデータを読出す時、ＣＲＣ値が検査されることにより、そのタグデータの完全性が検証される。また、圧縮された視覚的形式のデータを符号化して、８ビットバイナリデータの格納をサポートしていないデータベースに格納することができる。符号化技術の例は、ベース（ｂａｓｅ）６４符号化である。符号化されたデータは１６キロバイトのブロックに分割される。データベースレコードは、符号化されたデータの各ページの各ブロックに対して書込まれる。

また、サービスレイヤは、アプリケーションとデータベースとの間の中間物として作用することにより、アプリケーションが、ユーザのクエリに応じてデータベースを探索し、データベースからデータを検索するようにすることができる。ここで、サービスレイヤを用いる２つの他のアプリケーションに関連するサービスレイヤのオペレーションを、図８乃至図１３に関連してより詳細に説明する。

概して、サービスレイヤ２００は、データがデータベースに書込まれた時にデータに対して実行されるオペレーションを逆に行う。例えば、サービスレイヤは、データを復号化し、データ完全性を確実にするためにＣＲＣ値を検査し、データを他のアプリケーションに渡す前に圧縮解除する。同様に、タグデータが検索され、ＣＲＣ値が、タグデータが他のアプリケーションに渡される前に検査される。また、サービスレイヤは、他のアプリケーションから提供されるクエリに従ってデータベースに問合せる。

図８は、ユーザが見るデータベースを選択してそのデータベースレコードに対して適用されるソートまたはフィルタオペレーションを指定する時の、クエリインタフェース７６（図１）とサービスレイヤ２００（図７）とデータベースとの間のインタラクション（対話）を示している。クエリ（問合せ）インタフェース７６は、ユーザからデータベースをオープンするための要求を受取る。これに応答して、クエリインタフェース７６は、サービスレイヤにそのリクエスト（要求）を渡す。サービスレイヤは、ＯＤＢＣレイヤに対して、各々が名前を有するデータベースのリストを取得するための要求を発行する。サービスレイヤはこのリストを受取り、それをユーザに表示しユーザが選択するためにディスプレイに提示する。

ユーザがデータベースを選択し、オプションでフィルタまたはソートオペレーションを指定した後、クエリインタフェースは、サービスレイヤに対してデータベースをオープンするための要求を発行する。データベース構成およびデータベースにアクセスするために使用されるクエリ言語に従って、あらゆるフィルタまたはソートオペレーションが定義されることが可能である。サービスレイヤは、ＯＤＢＣレイヤ２０６を介してデータベースに対し、このユーザに対してデータベースをオープンするための要求を発行する。データベースはユーザに対し、ユーザ名とパスワードとの入力を促すことができる。サービスレイヤは、ユーザによって指定されるソートまたはフィルタパラメータに基づいてクエリを準備する。このクエリはデータベースに対して発行され、メインテーブルに適用される。レコードのセットは、サービスレイヤによってデータベースから受取られ、タグのＣＲＣ値が検証される。レコードのセットがリストに配置される。ここで、各エントリは、更に、レコードに対するタグのＣＲＣ値が適切であったか否かを示すフラグを有している。このリストは、ユーザに提示するためにクエリインタフェースに戻される。表示される時、クエリインタフェースは、ユーザに対し、ＣＲＣフラグに基づいていずれかのレコードが変更されたかを示す視覚的指示を与える。このリストは、限られた数のエントリを有していてもよく、その場合、サービスレイヤは、データベースからのレコードの読出しを停止し、リストが一杯になった時にカーソルをセーブする。

ユーザは、例えば、リストをスクロールすることにより、あるいは、リストのページをスクロールすることにより、リストをナビゲートすることができる。ユーザからのスクロールコマンドに応じて、クエリインタフェースは、サービスレイヤに対し、必要に応じてデータベースから更なるレコードをアクセスするよう要求する。また、ユーザは、リストをリフレッシュするよう決定することができる。クエリインタフェースは、リフレッシュコマンドに応じて、サービスレイヤに対しリフレッシュコマンドを発行する。これにより、サービスレイヤは、セーブされたカーソルを無効にし、上述した方法と同じようにレコードの新たなリストを生成する。

また、ユーザは、ソートまたはフィルタパラメータを変更するよう決定することができる。ソートまたはフィルタパラメータの変更に応答して、クエリインタフェースは、新たなパラメータをサービスレイヤに送信し、サービスレイヤはパラメータを格納する。そして、クエリインタフェースは、サービスレイヤに対してリフレッシュコマンドを発行し、新たなタグのセットを受取る。

ユーザは、データベースをクローズすることによりクエリインタフェースの使用を終了することができ、それによってサービスレイヤに対してクエリインタフェースにより要求が送信される。次に、サービスレイヤは、格納されたカーソルを無効にし、ＯＤＢＣレイヤを介してデータベースに対してクローズコマンドを発行する。

ソートおよびフィルタコマンドを用いてデータベースを探索するだけでなく、ユーザは、他のデータベース管理機能を実行することができる。かかる機能には、或るデータベースから他のデータベースへのレコードのコピー、データベースからのレコードの削除、１つのデータベースから他のデータベースへのレコードの移動（レコードをコピーし、それらを削除することにより実行される）、およびデータベースのマージ（すべてのレコードを複数のデータベースから他のデータベースにコピーすることによって実行される）がある。

ここで、図９に関連して、或るデータベースから他のデータベースへのレコードのコピーについて説明する。ユーザはすでにデータベースをオープンしており、レポートのセットを表示しているものと仮定する。クエリインタフェース７６は、１つまたは複数のレコードのユーザの選択と、ユーザからの選択されたレコードをデータベースにコピーするというコマンドとを受取る。選択されたレコードは、クエリインタフェースによりサービスレイヤに示される。そして、ディスプレイは、上述した方法により、ユーザに対してオープンするデータベース名を催促する。レコードがコピーされるデータベースはサービスレイヤを介してオープンされ、そのデータベースは、ユーザに対し認証を催促する。

クエリインタフェースは、サービスレイヤに対し、選択されたレコードをコピーするための要求を発行する。それに応じて、サービスレイヤは、セーブされたカーソルを無効にし、フィルタとして選択されたレポートおよびページに基づいてクエリステートメントを準備する。クエリは、データベースのメタファイル、ページおよびメインテーブルに対して実行される。メインテーブルにおける各レコードに対し、新たなレポート識別子が、そのコントロールテーブルを用いて宛先データベースに対して計算される。データベースから検索されるレコードは、宛先データベースの対応するメインテーブル、ページテーブルおよびメタファイルページテーブルにコピーされる。処理時間を節約するために、メタファイルは圧縮解除も復号化もされない。新たなタグを宛先データベースに送信する前に、レポートに対する新たな識別子を考慮するために、タグフィールドに対し新たなＣＲＣ値が計算される。現データベースからのレポートリストは、上述した方法によりクエリインタフェースにおいてリフレッシュされる。

ここで、図１０に関連して、データベースからのレコードの削除について説明する。ユーザはすでにデータベースをオープンしており、レポートのセットを表示しているものと仮定する。クエリインタフェース７６は、１つまたは複数のレコードのユーザの選択と、ユーザからの現在オープンしているデータベースから選択されたレコードを削除するというコマンドとを受取る。選択されたレコードは、クエリインタフェースによりサービスレイヤに示される。データベースがオープンされた時にユーザによって使用された認証は、ユーザにより検証される。データベースは、ユーザに対し、新たな認証を催促することができる。

クエリインタフェースは、サービスレイヤに対し、選択されたレコードを削除するための要求を発行する。これに応じて、サービスレイヤは、セーブされたカーソルを無効にし、フィルタとして選択されたレポートおよびページに基づいてデータベースに対して発行される削除ステートメントを準備する。クエリが、データベースのメタファイルおよびページテーブルに対して実行されることによりレコードが削除される。削除ステートメントは、フィルタとして選択されたレポートを用いてデータベースのメインテーブルに対して用意される。このステートメントがメインテーブルに対して実行されることにより、レポートについてのレコードが削除される。次に、現データベースからのレポートリストが、上述した方法でクエリインタフェースにおいてリフレッシュされる。

ユーザがデータベースを既にオープンした後にレポートのセットを表示しているとき、ユーザは、プリントするか、プレビューするかまたは他のアプリケーションに送信する１つまたは複数のレポートを選択することができる。ここで、かかるデータベースからのレポートのプリント、プレビューおよび送信について、図１１乃至図１３に関連して説明する。クエリインタフェース７６は、１つまたは複数のレコードのユーザの選択と、ユーザからの選択されたレコードに関連するレポートをプリント、プレビューまたは送信するためのコマンドとを受取る。選択されたレコードは、クエリインタフェースによりサービスレイヤに示される。そして、選択されたレコードに対するメタファイルが、クエリインタフェースによりサービスレイヤから要求される。

サービスレイヤは、セーブされたカーソルを無効にし、フィルタとして、選択されたレポートとページとを用いてクエリステートメントを準備する。クエリは、データベースのメタファイルテーブルに対して実行される。ページに対するレコードのすべてが読出されると、レコードの何片かが再アセンブルされ、復号化され、圧縮解除され、ページに対するＣＲＣ値が検証される。各レポートの各ページに対するメタファイルは、７８で示されるような名前付きテンポラリファイルに格納される。レポート識別子、ページ番号およびメタファイル名のリストが構成され、クエリインタフェースに戻される。クエリインタフェースは、コマンドが、ここで説明される方法によって、印刷か、プレビューかまたは送信かに従ってリストを処理する。

コマンドがプリントであった場合、ディスプレイは、オペレーティングシステムを用いて指定されたプリンタに対してのデバイスコンテキストに対しテンポラリメタファイル（１または複数）を単にプレイ（play）する。

コマンドがプレビューであった場合、クエリインタフェースは、図１２に関連してより詳細に説明する方法で動作する。特定的には、予め決められた名前を有するコントロールファイル１２００が生成され、それはプレビューされる各レポートの各ページに対してのメタファイルを含むテンポラリファイルの名前およびタグを含む。クエリインタフェースは、レポートプレビューワ８０という別個のプログラムをもたらし、そのプログラムは、次に、レポートを読出し表示するためにコントロールファイルにアクセスする。レポートプレビューワ８０は、ディスプレイのためにデバイスコンテキストに対してメタファイルをプレイすることにより、すなわち、オペレーティングシステムにプレイメタファイルコマンドを発行することにより、レポートを表示する。

プレビューワは、ユーザがディスプレイをスクロールしてレポートの異なるページを表示することができるようにすることを含む、プレイされたメタファイルデータに対する多くの種類のオペレーションを実行することができる。また、プレビューワは、ユーザがレポート内の指定されたテキストのインスタンスを見付けることができるようにすることができる。しかしながら、メタファイルにおけるＴＥＸＴＯＵＴコマンドが、表示時に対応するテキストが現れる順序と同じ順序でメタファイル内で発生しない場合があるという事実のため、メタファイルにおいて特定の順序のテキストを探索することが複雑化する。従って、レポートプレビューワは、選択された夫々のメタファイルのテキストを処理して順序付けされたリストとすることにより、各メタファイル内に現れる順序でワードをサーチすることができるようになる。また、かかる順序付けにより、メタファイル内およびメタファイルのセット間で、ワードまたは他の文字列の前の又は次の発生を識別することが可能となる。この技術を用いて、多くの異なるアプリケーションからの文書を同時にサーチすることができる。

メタファイルにおけるテキストの順序付けは、以下の方法で実行される。各ＴＥＸＴＯＵＴコマンドがメタファイルにおいて識別され、その対応する座標が取得される。そして、種々のＴＥＸＴＯＵＴコマンドが、ページ（すなわち、メタファイル）により、その後ディスプレイ領域におけるＹ位置により、更にディスプレイにおけるＸ位置によりソートされる。ソートされたコマンドは、ディスプレイにおけるテキストストリングとテキストストリングの位置のレコードの二重連係リストに変換される。テキスト高さの或るパーセンテージ内で互いに近接しているテキストストリングが、この構造において一繋がりになることができる。このソート情報を実行するために、あらゆる有効なソートアルゴリズムを使用することができる。例えば、挿入(insertion)ソートを使用することができる。

クエリインタフェースとレポートプレビューワとの両方により、ユーザはメタファイル７８（またはプレビューワの場合、メタファイル８２の選択された部分）を他のアプリケーション８４へ送信することができる。また、送信オペレーションは、すべてグラフィクスを含むか、テキストのみを含むか、またはテーブルに変換されるテキストを含むレポートを送信することができる（図１７に関連してより詳細は後に説明する）。ここで、このオペレーションについて、図１３に関連して説明する。このオペレーションにより、データを選択し、他のアプリケーションを用いて書かれている文書に挿入することができる。

クエリインタフェースから、レポートを送信するプロセスは、プレビューと同様である。更に、ユーザは、メタファイルが送信される宛先アプリケーションの名前を催促される。コントロールファイル１３００は、メタファイル名と、宛先アプリケーションの名前と、宛先アプリケーションにおいていかにペーストが実行されるかを定義するキーストロークのセットとを用いて生成される。レポートプレビューワの代りに、「送出（Send）」と呼ばれる別のコンピュータプログラム１３０２が実行される。これは、上述したような方法でコントロールファイル１３００に作用することにより、宛先アプリケーション８４において現在オープンされている文書中のレポートをペーストする。

また、「送出」プログラムは、レポートプレビューワ８０によって実行することも可能である。ユーザは、宛先アプリケーションの名前を供給する。レポートプレビューワは、上述した方法で、ユーザの選択に基づいて新たなテンポラリメタファイル８２を生成する。クエリインタフェースによって生成されるコントロールファイル１３００と同様のコントロールファイル１３０４が生成され、「送出」プログラム１３０２が同様に実行される。

宛先アプリケーションへ発行するための送出プログラムに対しての適当なキーストロークは、多くの方法で決定することができる。例えば、アプリケーションのメニューのコマンド「ペースト（Paste）」をサーチすることにより、対応するキーストロークを識別してもよい。あるいは、多種のアプリケーションに対するキーストロークを前もって決定し、送出プログラムによってアクセス可能なファイルに保存してもよい。デフォルトとして、標準Ｗｉｎｄｏｗｓ（登録商標）アプリケーションのユーザインタフェースにおけるペースト機能のキーストロークがＣｔｒｌ−Ｖであるため、このキーストロークもまた使用することもできる。

ここで、レポートプレビューワがメタファイルの一部のユーザの選択に基づいて、どのようにして新たなメタファイルを生成するかを説明する。一般に、ユーザの選択は、メタファイルが表示される領域における矩形を定義する座標によって表される。そして、メタファイルの各コマンドは、定義された座標と比較される。関連した座標を有していないコマンドは全て、自動的に新たなメタファイルに配置される。指定された座標の外側で表示情報を生成するコマンドはすべて破棄される。指定された座標内で表示情報を生成するコマンドはすべて保持される。場合によっては、コマンドは、指定された座標の内側と外側との両方の表示情報を生成することがある。ラインセグメントおよびビットマップ等のようなこれらコマンドは、周知の技術を用いて、指定された座標内に入るように容易に変更することができる。結果としてのメタファイルコマンドのセットは、ファイル名がコントロールファイルにリストされている名前付きテンポラリファイルに格納される。

ここで、「送出」プログラムについて説明する。まず、このプログラムは、その予め決められた名前を用いてコントロールファイル１３００または１３０４を読出す。「送出」プログラム１３０２は、それがクエリインタフェース７６によって呼出されたかレポートプレビューワ８０によって呼出されたかを知る必要はない。コントロールファイルにおいて指定された３２ビットメタファイル（ＥＭＦ）はすべて、メタファイルプロセッサ１３０６に対する要求を介して１６ビットメタファイル（ＷＭＦ）１３１０に変換することができる。また、変換は、ＥＭＦファイルのみがクリップボードに配置されている場合には、自動的にＷｉｎｄｏｗｓ（登録商標）のＧＤＩ−３２によって実行することができる。メタファイルプロセッサ１３０６によって実行される変換は、「色空間（カラースペース）」レコードと、「ＴＥＸＴＯＵＴ」レコード（後述する）における全ての文字間余白と、不法パラメータ値を含む「モディファイワールドトランスフォーム（modify world transform）」レコードとを削除する。

また、Ｗｉｎｄｏｗｓ（登録商標）９５によって生成されるクリッピングレコードも変更することができる。特に、ビューポートおよびウインドウの原点は、現在値を維持するために追跡される。クリッピング領域の境界は、現在のビューポイントおよびウインドウの原点を考慮するために、周知の技術を用いて調整される。また、クリッピングレコードによっては、メタファイルがプレイされる時にテキストが不適当に隠されるようにされる場合もある。テキストレコードに影響するクリッピングレコードは、テキストが不適切に隠されないようにするために、必要である場合には、変更されるかまたは取り除かれる。

１６ビットメタファイルおよび３２ビットメタファイルは共に、オペレーティングシステムに対するファンクションコールを行うクリップボード配置１３１２を通じて「クリップボード（Clipboard）」１３０８に配置される。クリップボードは、データを一時的に格納することができ、いかなるアプリケーションによってもデータを読出すことができるメモリの領域である。クリップボードにデータを配置するために、「カット（cut）」または「コピー（copy）」等のコマンドが使用される。「ペースト」ファンクションは、概して、大抵のアプリケーションにより提供され、そのアプリケーションによって現在処理されている文書の現位置にデータを配置するようクリップボードからデータを読み出す。

送出プログラムは、次に、オペレーティングシステムを介して宛先アプリケーションへキーストロークを送出し、それによってアプリケーションが、キーボードからその現文書にデータをペーストする。

図１３に関連して説明する送出オペレーションは、示される実現例に限定されず、多くの方法によって提供することができる。例えば、クエリインタフェースおよびレポートプレビューワは、所定のアプリケーションに対してキーストロークのセットを決定するものとして上述されている。また、これらキーストロークを、送出プログラムにより直接に、コントロールファイル１３００または１３０４を介さずに、決定またはアクセスすることができる。あるいは、送出プログラム１３０２のすべてを、クエリインタフェース７６およびレポートプレビューワ８０において実現するようにしてもよい。また、ソースアプリケーションにより、第三者が、ソースアプリケーションのメニューまたはツールバーに新たな機能を追加するために「プラグイン（plug-in）」のマクロまたはライブラリを開発することができる場合、或るソースアプリケーションから他の宛先アプリケーションへメタファイルを送出すために、送出オペレーションを提供するようにしてもよい。かかる能力を有するソースアプリケーションの例には、マイクロソフト社からのＷｏｒｄ（ワード）がある。かかるアプリケーションでは、プレビューワまたはクエリインタフェースと送出プログラムとの組合された機能性が、ソースアプリケーションによって呼出されることにより、メタファイルデータが宛先アプリケーションへ直接に送信される。

上述したように、スプールファイル９８は真のメタファイルではない。アプリケーションに応答してオペレーティングシステムによって提供される視覚的形式のデータもまた、例えば印刷を通してのものも、変換される場合、例えば、スケーリングまたは回転される場合には、ゆがめられる可能性がある。一般に、かかるゆがみは、例えばプリントコマンドに応答してのオペレーティングシステムの出力は一般に変換されることを意図されていない、という事実に要因がある。一般に、アプリケーションは、オペレーティングシステムの出力に応答してのプリンタの出力が視覚的形式のデータに一致するよう実現されている。概して、アプリケーションは、プリンタに送信されるコマンドがゆがみ無しにスケーリングすることができるか否かについてテストされない。従って、オペレーティングシステム５４によって出力される視覚的形式のデータ５６（図１を参照）は、ゆがみを発生することなく変換されることができるメタファイルの適切な形式に変換される必要があり得る。

ここで、再び例としてＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムおよびＷｉｎｄｏｗｓ（登録商標） Ｍｅｔａｆｉｌｅを用いて、かかる変換について図１４乃至図１６に関連して説明する。ここで図１４を参照すると、ステップ８００において、スプールファイル９８がメタファイルプロセッサ１０２によって受取られる。ステップ８０２において、メタファイルプロセッサは、新たなメタファイル（１または複数）が格納されるスプールファイルにおける各ページに対し新たなファイルをオープンする。ステップ８０４においてこの新たなファイルにプライベートレコードを挿入し、バージョン情報を供給する。例えば、アプリケーションがプリントされたオペレーティングシステムとメタファイルプロセッサプログラムのバージョンとを格納することができる。この情報により、バージョン情報に従ってメタファイルを種々に処理することができる。

ステップ８０６において、Ｗｉｎｄｏｗｓ（登録商標）において入手可能な「ＤＥＶＭＯＤＥ」構造が、メタファイルのプライベートレコードにコピーおよび格納される。このデータ構造は、プリンタの特徴と、ページサイズ、解像度および方向付けを含むプリントジョブとのすべてを記述する。他のオペレーティングシステムから入手可能なあらゆる同様の情報もまた、格納することができる。このレコードは、情報が、スプーラプロセスから受取られるメタファイル（１または複数）のヘッダに正確にかつ完全に供給される場合には、省略することも可能である。

ステップ８０８において、スプールファイルから取得されるページのメタファイルは、後に詳述する方法で、マイクロソフト社によって提供されるこれらデータフォーマットの仕様に従ってそのスケーラビリティを向上させるために、ページに対しての修正されたメタファイルに変換される。このステップの間、メタファイルプロセッサは、変更された又は新たなコマンドが後に続くオリジナルのコマンドを含むコメントレコードを、出力ファイル中に挿入する。オリジナルコマンドを保持することにより、他のフォーマットへの変換のためにオリジナルを再構成することが容易となる。

ステップ８１０において、メタファイルプロセッサは、エンハンスドメタファイルデータの終端において、エンド−オブ−ファイル・コメントレコードを挿入する。エンド−オブ−ファイル・コメントレコードは、他のメタファイル内に含まれるメタファイル間の境界を明確に示すために使用される。かかるメタファイルは、「ネストされたメタファイル」として考えることができる。処理される時に、メタファイルは、それが生成されたオペレーティングシステムのプラットフォームおよびアプリケーションに応じて、異なるプロパティおよび特徴を有することができる。例えば、Ｗｉｎｄｏｗｓ（登録商標） ＮＴで生成されるメタファイルは、Ｗｉｎｄｏｗｓ（登録商標） ９５で生成されるものと異なる特徴を有することができる。適当な処理を保証するために、ネストされた各ファイルの開始点および終了点は、ステップ８０４および８１０で挿入されるレコードによって提供される。

ステップ８１２において、メタファイルプロセッサは、新たなメタファイルファイルをクローズし、ファイル１０５のファイル名を格納するファイルを提供する。

ここで、ステップ８０８において実行されるメタファイルにおけるコマンドの変換について詳細に説明する。異なるオぺレーティングシステムに対するメタファイルタイプ間の違いにより、および異なるアプリケーションによるプリントによって生成されるメタファイルが一般にスケール化が可能なようには設計されず、従って、時としてスケール化されないため、多種の変更が行われる。

フォント作成または他の作成コマンド等のメタファイルがプレイされている時にリソースの漏れを発生する可能性のあるコマンドが識別される。これらコマンドは、リソースが適正に自由にされる（フリーアップ、free up）されることを保証するよう処理されることができる。

アプリケーションによっては、負のＹ軸方向や互換性の無いマッピングモード等のような、スケーリング、回転、又はその他の変換されたテキストの適当な表示とは互換性の無い座標変換空間において、テキストの表示を試みるメタファイルを生成する。その結果、テキストは、垂直および／または水平方向に不適当に方向付けされるか不適当にスケーリングされる。メタファイルプロセッサは、負のＹ軸または互換性の無いマッピングモードを含むコマンドを識別することによって、この状態を検出する。テキストを表示するレコードの前に、メタファイルレコードが付加されることにより、座標変換空間が一時的に変更される。新たな座標変換は、周知の技術を用いて、指定された変換、配置されるテキストの座標、指定されるフォント方向付け、アスペクト比およびマッピングモードから決定される。座標変換空間は、意図された位置、方向およびアスペクト比を保存するように変更される。テキストを表示するレコードの後に他のメタファイルレコードが付加されることにより、座標変換空間がその元の状態にリセットされる。

Ｗｉｎｄｏｗｓ（登録商標） ＮＴで実行されるアプリケーションによって生成されるメタファイルによっては「マイタリミット（miter limits）をセットする」レコードを含む。メタファイルプロセッサはこれらのレコードを取り除く。なぜなら、それらはＷｉｎｄｏｗｓ（登録商標）９５のＧＤＩ−３２によって認識されないからである。結果としての画像に対する影響は無視できる程度である。

メタファイルによっては、カラーパレットを含む１６、２４または３２ビットのカラービットマップを含む。メタファイルプロセッサは、カラーパレットを取除くことによってビットマップレコードを変更する。なぜなら、それらは必要とされないためであり、また、それらは表示された時にビットマップのゆがみをもたらすためである。

メタファイルによっては、現カーソル位置に対して位置合せされたテキストを表示する。それにより、そのテキスト位置がビューワプログラムにおいて誤って判定されることとなり、テキストがいくつかの装置でプリントされるときに消えることとなる。メタファイルプロセッサは、相対座標ではなく絶対座標に基づいて、アライメントを指定するテキストアラインメントレコードを変更し、テキストを表示する各メタファイルレコードを変更して、正確な絶対座標を含むようにする。これは、現カーソル位置から周知の技術を用いて決定することができ、これはＷｉｎｄｏｗｓ（登録商標）に対するファンクションコールを介して取得することができる。

また、概して、フォントおよびテキストコマンドは、図１５Ａ〜Ｂおよび図１６に関連して以下に説明する方法で、それらのスケーラビリティを向上するよう処理される。

フォント処理は、図１５Ａおよび図１５Ｂにおいて説明されている。アプリケーションによっては、非スケーラブル（スケーリングできない）フォントを用いるメタファイルを生成する。これらメタファイルは、１枚の用紙に印刷される場合には正確に見えるが、プリンタのそれと異なるスケーリングで表示される場合、またはプリンタ以外の装置で表示される場合にゆがめられる。メタファイルプロセッサは、メタファイルレコードを付加することにより、このゆがみを防ぐためにスケーラブル（スケーリングできる）フォントを指定する。ステップ１６０２〜１６０８において、一連の判断ポイントは、メタファイルにおいてＴｒｕｅＴｙｐｅフォントが使用されたか否かを判断する。ステップ１６０２において、メタファイルにおいてフォントが指定されていない場合、ステップ１６１０において、デフォルトのＴｒｕｅＴｙｐｅフォントが選択される。ステップ１６０４において、Ｓｙｓｔｅｍフォントが選択されている場合、ステップ１６１０において、それに取って代るためにＴｒｕｅＴｙｐｅフォントが選択される。ステップ１６０６において、ビットマップフォントが選択されている場合、ステップ１６１０において、ビットマップフォントに取って代るためにＴｒｕｅＴｙｐｅフォントが選択される。ステップ１６０８において、アプリケーションがＷｉｎｄｏｗｓ（登録商標）のＳｅｌｅｔＯｂｊｅｃｔファンクションを通じてフォント（時に、ストックフォント（stock fonts）と呼ばれる）を選択する場合、ステップ１６１０において、ＳｅｌｅｃｔＯｂｊｅｃｔを通じて選択されたフォントに取って代るためにＴｒｕｅＴｙｐｅフォントが選択される。ステップ１６０２〜１６１０の完了後、メタファイルの２つのフラグが真にセットされ、ステップ１６１２においてプルーフ品質（proof quality）のＴｒｕｅＴｙｐｅフォントのみが使用されるべきであることを示す。ステップ１６１４において、フォントサイズが指定されていなかった場合、ステップ１６１６において、デフォルトのフォントサイズが選択される。ユーザは、予め、デフォルト値以外のフォントサイズおよび字体名を選択しておいてもよい。それらの値をデフォルト値の代りに使用することができる。ステップ１６１８において、ゆがんだ出力グラフィックをもたらす可能性のある軸回転またはフォント回転が行われる場合、ステップ１６２０において、回転（１または複数）の新たな値が上述した方法で計算される。

ここで、図１６に関連してテキスト処理について説明する。アプリケーションによっては、文字間余白を指定しないテキストレコードを含むメタファイルを生成する。メタファイルプロセッサは、適当な文字間余白値を計算し、このプロセスを用いてテキストレコードを変更する。各メタファイルコマンドが評価されることにより、それがＴＥＸＴＯＵＴレコードであるか否かが判断される。ＴＥＸＴＯＵＴレコードは、文字余白値のアレイを含むものとして指定される。すなわち、プリントされるストリングの各文字に対し、それと次の文字との間に残す余白の量を示す値が供給される。この距離値は無い場合がある。従って、距離値無しのＴＥＸＴＯＵＴレコードに遭遇した場合、ステップ１７０４において、例えばＧＤＩ−３２に対するファンクションコールにより、適切な距離値が取得される。ステップ１７１２において、古いＴＥＸＴＯＵＴレコードが、新たに計算されたデータと置換えられる。この新たなレコードは追加のフィールドを含みそれが付加されたレコードであることを示す。

また、メタファイルのテキストをインデクスし、かかるインデクスをレポートの追加のタグ情報としてデータベースに格納するために、追加のテキスト処理を実行してもよい。このインデクスもまた、二重連係リストとして表すことができ、それが上述したレポートプレビューワ８０によって使用されることにより、プレビューワ内でのテキストのサーチが可能になる。

この場合にはレポートプレビューワ８０により実行されるものであるが、実行可能なテキスト処理の他の形態は、メタファイルからＴＥＸＴＯＵＴによって生成されるようなテキストデータの、タブ区切りデータ等の文字区切りデータへの変換である。これは次に、テーブルまたはスプレッドシートに変換される。この処理は、図１７に関連して述べられているが、限定する訳ではないが、ＴＥＸＴＯＵＴコマンド内のメタファイルからのテキストデータを含む、任意の形式のテキストデータに対しても使用することができる。このプロセスは、ユーザによって指定されるもの、例えば、ディスプレイ上に表示されるテキストを選択するときにユーザによって生成されるような、選択座標を受取ることを含む。概して、選択座標は、表示領域内の矩形を定義する。ステップ１８００において選択座標が受取られた後、ステップ１８０２において、選択された座標内のテキストコンテントが識別される。このステップは、各メタファイルコマンドをプレイして各コマンドの座標を選択矩形と比較することにより、あるいは、以下に説明する二重連係リスト等の或るデータ構造内の座標を検査することにより、実行することができる。

次に、選択されたテキストによって定義されるカラムが検出される。これらカラムは、まず、例えばブール値のアレイであり得る選択された矩形に対するカラム検出データ構造を初期設定することにより検出される。ここで、各ブール値は、ディスプレイ上の水平論理座標または文字ストリングの１文字に対応する。このアレイは、概して、テーブルの水平寸法を表す。このアレイは、選択された矩形の頂部から底部までの「余白（white space）」またはテキストが存在しないことを検出するために使用される。ステップ１８０６において、選択座標内の各コマンドまたはテキストストリングに対し、このカラム検出データ構造が変更される。特に、ブール値のアレイにおける各座標または文字に対するブール値は、テキストが、選択矩形内で識別されるテキストコンテントの何れかからのその座標において存在する場合に、真にセットされる。ステップ１８０６の最終的な結果は、１つまたは複数の隣接する偽の値が現れるとそのそれぞれがカラム境界を示す、ということである。ステップ１８０８において、各テキストアイテムのＹ座標を用いて、各行のテキストが識別される。次に、テーブルの各行の終端においてキャリッジリターンを有し、タブ文字によって分離されたセル値のストリング、例えばＡＳＣＩＩストリング等のストリング、が構築される。所定の行の各テキストアイテムに対し、そのＸ座標がカラム検出構造と比較され、それが属するカラムが判定される。各行について挿入されるタブの数の現カウントが保持される。各セルが付加される際に、それに先行するタブ文字の正確な数を計算することができる。このオペレーションは、必要に応じて余分のタブを挿入することにより、空のセルを正確に考慮する。ステップ１８１０において、このオペレーションを用いてテキストコマンドからタブ区切りテキストが生成される。タブ区切りテキストから、他のアプリケーションがかかるテキストをテーブルに容易に変換することができ、あるいは、スプレッドシートアプリケーションがスプレッドシートの個々のセルに値を挿入することができる。

アプリケーションからの視覚的形式のデータの標準フォーマットがデータベースに取込まれる上述したシステムを提供することにより、地理的に分散されている複数の異なるコンピュータプログラムを用いて複数の異なるユーザによってある期間にわたって生成され、使用され、共有されたデータが、それらデータを生成するアプリケーションとは無関係の方法で、中央で編成され、管理され、アクセスされることが可能となる。また、データベースは、データが、他のアプリケーションに対し表示、プリントまたはコピーのためにサーチおよび読出されることが可能な単一のフォーマットである、中央のリポジトリ（貯蔵場所）も提供する。単一の標準フォーマットを使用することにより、データを表示した元のアプリケーションが無くてもデータを表示することができる。また、ユーザは、データが最初に生成されたアプリケーションにアクセスする必要なく、複数のデータ源から複合文書を生成することができる。

ここでは、いくつかの実施形態を説明したが、当業者には、上述したことが単に例示的なものであり、単に例として提示されたものであり、この限りではないことが明らかである。多くの変更を行うことができる。

例えば、上述した例においてプリントコマンドが使用される。なぜなら、大抵のアプリケーションが少なくともそれらが処理し表示する視覚的形式のデータをプリントする能力を有しているためである。「カット・アンド・ペースト（cut and paste）」シーケンス等の一般にアプリケーションで使用される他のファンクションもまた、例えばＷｉｎｄｏｗｓ（登録商標）の「クリップボード（Clipboard）」や「オブジェクトのリンクおよび埋め込み（Object linking and embedding(OLE)）サーバ」のような一時記憶手段において、１つのアプリケーションから異なる標準フォーマットへとデータを翻訳するために、オペレーティングシステムへのファンクションコールが関与する。このデータは、他のアプリケーションにより一時記憶手段から検索されることが可能である。これらおよび他のオペレーティングシステムのファンクションを用いて、標準フォーマットデータへのアクセスを提供することができ、その後そのデータはデータベースに格納することができる。

また、クエリインタフェースまたはレポートプレビューワから他のアプリケーションへレポートを転送する上述した送出オペレーションを用いて、ソースアプリケーションからのデータを、データをデータベースに取り込む宛先アプリケーションへ配置することも可能である。

また、他のオペレーティングシステムを使用することも可能である。例えば、Ｕｎｉｘ（登録商標）（ユニックス）、ＰｏｓｔＳｃｒｉｐｔ（ポストスクリプト）データをアプリケーションから取り込み、データベースに格納してもよい。ＰｏｓｔＳｃｒｉｐｔデータは、メタファイルフォーマットに変換してもよい。あるいは、プリントドライバは、いかなるオペレーティングシステムに対しても準備することができる。

これらおよび他の実施形態は、本技術分野における通常の技術の１つの範囲内にあり、本発明の範囲内にあるものと考えられる。

Claims (10)

1. タグと関連する視覚的形式のデータを見るための、コンピュータにより行われる方法であって、
   複数のレポートを含むデータベースを選択するステップであって、各レポートは、プリント形式のデータ又は表示形式のデータの１つに対応する視覚的形式のデータの表現を含むものであり、各レポートは、１又は複数の関連するタグを有するものであり、前記関連するタグのそれぞれは、それぞれの前記レポートに対する識別情報を含むものであり、前記タグの少なくとも１つのタグは、前記視覚的形式のデータに含まれるものであり、水平座標および垂直座標が、前記視覚的形式のデータにおける少なくとも１つのテキスト・エレメントの位置を特定するものである、ステップと、
   １又は複数のページを含む少なくとも１つのレポートを選択するステップと、
   前記少なくとも１つのレポートの各ページについて、前記各ページに対応するメタファイル・データを含むメタファイルのための名前付きテンポラリ・ファイルを構築するステップと、
   前記各ページに対応する前記名前付きテンポラリ・ファイルに含まれる前記メタファイル・データにより表される前記視覚的形式のデータを見るためにコントロール・ファイルへアクセスするプレビューワ・プログラムを実行するステップであって、前記コントロール・ファイルは、前記少なくとも１つのタグと、前記少なくとも１つのレポートの１つのページに対応するメタファイルに対する前記名前付きテンポラリ・ファイルの名前とを含むものであり、前記プレビューワ・プログラムは、前記各ページに対応する前記メタファイルに含まれる前記メタファイル・データをプレイすることにより、前記少なくとも１つのレポートの各ページに対する前記視覚的形式のデータを得るものであり、前記プレビューワ・プログラムは、プレイされたメタファイル・データに対してオペレーションを行うことにより、前記少なくとも１つのレポートにおける指定されたテキストのインスタンスについてのサーチを行うステップを行うように動作するものである、ステップと、
   を備え、前記サーチを行うステップは、
   前記少なくとも１つのレポートの１又は複数のメタファイルにおける各テキスト・コマンドと、前記各テキスト・コマンドと関連するテキスト・ストリングにおけるテキストの位置を特定する座標とを、特定するステップと、
   テキスト・コマンドを、ページにより、ディスプレイ内のＹ座標位置により、および前記ディスプレイ内のＸ座標位置により、ソートするステップと、
   ソートされた前記テキスト・コマンドからレコードのリストを形成するステップであって、各レコードは、テキスト・ストリングと、前記ディスプレイにおける前記テキスト・ストリングの位置とに関連するものである、ステップと、
   前記リストからの前記テキスト・ストリングのうちの第１のテキスト・ストリングと、前記リストからの前記テキスト・ストリングのうちの第２のテキスト・ストリングとが、テキスト高さの所定のパーセンテージ内にある場合に、前記第１のテキスト・ストリングと前記第２のテキスト・ストリングとを連結するステップと
   を備える、
   方法。
2. 請求項１に記載の方法であって、オペレーティンク・システムへ、メタファイルをプレイするためのプレイ・メタファイル・コマンドを発行することにより、前記視覚的形式のデータを見るために、前記名前付きテンポラリ・ファイルをプレイするステップを更に備える方法。
3. 請求項１に記載の方法であって、少なくとも１つのレポートを選択する前記ステップの後に、
   前記少なくとも１つのレポートを、プリントするか、プレビューするか、又は他のアプリケーションへ送信するかのうちの１つを選択するステップを更に備え、
   前記プリントすることは、前記名前付きテンポラリ・ファイルをプリンタ・デバイスへ送ることを含み、前記少なくとも１つのレポートを他のアプリケーションへ前記送信することは、
   １又は複数のタグと、メタファイル名と、宛先アプリケーションと関連する名前と、前記宛先アプリケーションにおいていかにペースト・オペレーションが実行されるかを定義するキーストロークのセットとを含む送出コントロール・ファイルを作るステップと、
   前記宛先アプリケーションにおける予め定めた位置に前記少なくとも１つのレポートをペーストするために前記送出コントロール・ファイルを用いる別のプログラムを、実行するステップと
   を含む、
   方法。
4. 請求項１に記載の方法であって、
   前記レポートのリストと関連する前記データベースのレコードに対して適用されるソートおよびフィルタのオペレーションの１つを選択するステップと、
   表示される各レコードに対して、前記各レコードに対するタグの循環冗長コードに基づいて前記各レコードが変更されているを示す視覚的指示を決定するステップと
   を更に備える方法。
5. 請求項１に記載の方法であって、
   フィルタ・パラメータに従って選択された前記データベースへクエリを行うステップと、
   クエリ・インターフェースからサービス・レイヤへ少なくとも１つの選択されたレコードを示すステップであって、少なくとも１つの選択された前記レコードは、選択された前記少なくとも１つのレポートに対応するものである、ステップと、
   前記サービス・レイヤに、少なくとも１つの選択された前記レコードと関連するメタファイルを要求するステップと、
   前記サービス・レイヤで、少なくとも１つの選択された前記レコードと関連する前記少なくとも１つのレポートおよび前記少なくとも１つのレポートのページをフィルタとして用いて、クエリ・ステートメントを準備するステップと、
   前記データベースと関連するメタファイル・テーブルで前記クエリ・ステートメントを実行するステップと、
   テンポラリ・ファイル内の前記少なくとも１つのレポートの各ページに対するメタファイルを記憶するステップと、
   レポート識別子、ページ番号、およびメタファイル名のうちの１又は複数のものを含むリストを構築するステップと、
   前記少なくとも１つのレポートをプリントするかプレビューするか又は他のアプリケーションへ送信するかのうちの１つを選択することに従って所定の様式で前記リストを処理するために、前記リストを前記クエリ・インターフェースへ提供するステップと
   を更に備える方法。
6. 請求項１に記載の方法であって、選択された前記データベースを開いた後に、選択された前記データベースから別のデータベースへレコードをコピーするステップを更に含み、前記コピーするステップは、
   クエリ・インターフェースで１又は複数のレコードのユーザ選択を受け取るステップと、
   前記クエリ・インターフェースでコピー・コマンドを受け取るステップと、
   宛先のデータベースが開かれるように促すステップと、
   前記１又は複数のレコードを前記宛先のデータベースにコピーするステップと
   を更に含む、
   方法。
7. 請求項１に記載の方法であって、
   前記プレビューワ・プログラムを用いて、選択されたメタファイルの一部を選択するステップと、
   前記の選択されたメタファイルの一部を選択することに従って、新たなメタファイルを形成するステップと、
   矩形状の形状を定める座標を用いて、前記選択されたメタファイルの前記一部の選択を表すステップと、
   前記選択されたメタファイルの各コマンドと前記座標とを比較するステップであって、前記各コマンドが、関連する座標を持たず、前記座標により形成される形状内に表示情報を作り出すものの１つである場合、前記各コマンドは前記新たなメタファイルに含まれるものである、ステップと、
   前記各コマンドが、前記座標により形成される前記形状の内側および外側の双方にある表示情報を作り出す場合、前記座標内に制限されるように前記各コマンドを変更するステップと
   を更に備える方法。
8. 請求項１に記載の方法であって、前記複数のレポートのうちの少なくとも１つのレポートは、オブジェクトを描くため、線を描くため、形状を描くため、テキストを描くため、およびレポートに含まれる少なくとも１つのエレメントのスタイルを制御するため、のうちの少なくとも１つのためのコマンドを含み、前記コマンドは、表示又はプリントのエリアの一部と関連する、方法。
9. 請求項１に記載の方法であって、前記視覚的形式のデータはベクトル画像又はメタファイルとして表される、方法。
10. コンピュータ読取可能な記録媒体であって、請求項１ないし９の何れかに記載の方法の処理をコンピュータに実行させるプログラムを記録した記録媒体。

Images