(57)【特許請求の範囲】
【請求項１】
複数のアプリケーションプログラムと、前記アプリケーションプログラムから伝達される印刷用の描画情報に基づいて電子ファイリングを行なうためのプリントドライバと、前記アプリケーションプログラム及び前記プリントドライバを実行するコンピュータとを有する電子ファイリング装置であって、
前記コンピュータは、前記アプリケーションプログラムからの印刷指示に応じて起動される前記プリントドライバを実行することによって、当該アプリケーションプログラムから伝達される印刷用の描画情報を受信し、当該受信した印刷用の描画情報を複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換し、当該変換された前記共通文書ファイル形式の描画情報を電子ファイリング用のデータベースに蓄積することを特徴とする電子ファイリング装置。
【請求項２】
前記プリントドライバは汎用ドライバであり、前記データベースに蓄積された共通文書ファイル形式の描画情報を前記プリントドライバを介して検索する検索ドライバを更に有することを特徴とする請求項１記載の電子ファイリング装置。
【請求項３】
前記印刷用の描画情報は描画コマンドで構成され、
前記コンピュータは、前記プリントドライバを実行することによって、当該アプリケーションプログラムから伝達される前記印刷用の描画情報の各描画コマンドを解析して、複数の部分に分割し、当該分割した複数の部分に基づいて前記印刷用の描画情報を前記共通文書ファイル形式の描画情報に変換することを特徴とする請求項１記載の電子ファイリング装置。
【請求項４】
前記分割される複数の部分は、文字部分とベクトル描画部分と画像部分であることを特徴とする請求項３記載の電子ファイリング装置。
【請求項５】
前記プリントドライバは、プリントドライバをエミュレートしたファイリングドライバであって、
前記コンピュータは、前記アプリケーションプログラムからの印刷指示に応じて起動される前記ファイリングドライバを実行することによって、前記変換された描画情報を前記電子ファイリング用のデータベースに蓄積すると、印刷完了メッセージを送ることを特徴とする請求項１記載の電子ファイリング装置。
【請求項６】
前記コンピュータは、前記プリントドライバを実行することによって、前記分割された画像部分を解析して当該画像部分に含まれる文字情報を認識して抽出する光学文字認識処理を実行し、当該抽出された文字情報を蓄積することを特徴とする請求項４記載の電子ファイリング装置。
【請求項７】
複数のアプリケーションプログラムと、前記アプリケーションプログラムからの印刷指示に応じて起動されるプリントドライバと、前記アプリケーションプログラム及び前記プリントドライバを実行するコンピュータとを有する装置において、前記コンピュータが、前記プリントドライバを実行することにより、前記アプリケーションプログラムから伝達される印刷用の描画情報に基づいて電子ファイリングを行なうように制御する電子ファイリング方法であって、
前記アプリケーションプログラムからの印刷指示に応じて起動されたプリントドライバを前記コンピュータに実行させることによって、前記コンピュータが、当該アプリケーションプログラムから伝達される印刷用の描画情報を受信し、前記受信した印刷用の描画情報を複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換し、当該変換された前記共通文書ファイル形式の描画情報を電子ファイリング用のデータベースに蓄積するように制御することを特徴とする電子ファイリング方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子ファイリングを行なうためのプリントドライバを有する電子ファイリング装置および電子ファイリング方法に関するものである。
【０００２】
【従来の技術】
従来、ＤＴＰアプリケーションは、それを開発するメーカ毎にバラバラのフォーマットでデータを保存していたので、異なるメーカ間のファイルのやり取りは困難であった。この問題を解決するツールとして、各種のフィルタが提供されていた。
【０００３】
【発明が解決しようとする課題】
上記フィルタの必要個数は、使用するアプリケーションの数によって変化し、例えば１０種類のアプリケーションが必要とするフィルタの組合せの個数は、１０Ｃ２通りになるので、膨大なフィルタ処理が必要となる。
【０００４】
ただし、一旦中間ファイルに落すやり方をすれば、その数は１０通りで済むが、それでもアプリケーションの数分まで必要となる。
【０００５】
また、小形で安価な電子ファイリング装置を実現するためには、必然的に市販のパーソナルコンピュータ（以下パソコン）をベースにしたファイリング装置を実現することになる。
【０００６】
そして、電子ファイリングに必須の機能要素としては、スキャナ，ＯＣＲ，キーワード検索機能，（光磁気）ディスク装置等を備えている。「紙」に印刷された文書をスキャナで読んで保存するのが基本である。その際、検索を容易にするためにＯＣＲ処理部で文字情報をコード化し、キーワードを自動的に拾い出して一緒に保存する訳である。
【０００７】
専用機であれば、これだけの機能で十分であるが、パソコンをベースに電子ファイリングを行うためには、対象とする文書は「紙」に印刷された文書だけでは不十分で、キーボードから入力して作成したようなＤＴＰ文書も統一的に扱う必要性が出てくる。
【０００８】
ところが、ＤＴＰ文書というのは、作成したアプリケーションによってファイルフォーマットが全く異なり、それらをファイルの形で保存すると以下（１）〜（４）のような問題が生じる。
【０００９】
（１）ネットワーク上にあるサーバに保存したＤＴＰ文書を複数のパソコンからアクセスする場合、全てのパソコンに作成時に用いたアプリケーションと同じアプリケーションが存在するという保証は無い。バージョンが違うだけでも問題である。
【００１０】
（２）ネットワーク上にアーキテクチャーの異なるパソコンが存在する場合、たとえ同一アプリケーションの作成したファイルでもファイル形式が異なるのが普通なので、相互にアクセスできない。
【００１１】
（３）市販のアプリケーションには、キーワードを抽出する機能など無いのが普通であるから、電子ファイリングをする場合、ファイルを媒介するか、カット＆ペースト機能を媒介して文書情報を伝送するわけだが、操作手順が繁雑で時間がかかり、自動化も困難であるから実用にならない。
【００１２】
また、市販のアプリケーション、例えばスキャナアプリ，ワープロ，表計算アプリ等のように非常に正確が異なるアプリケーション間でのデータ交換を考えてみる。これらのアプリケーション間でデータのやり取りをするには、ファイルを介して行うのは非常に困難である。
【００１３】
なぜなら、スキャナアプリ，ワープロ，表計算アプリ等のように性格が異なるアプリケーションが生成するファイルのフォーマットはそれぞれのベンダーが独自に定めたものなので、互換性は全く無いからである。
【００１４】
また、アプリケーションに依存しないファイルフォーマットとして「ＴＩＦＦ」「ＰＩＣＴ」「ＥＰＳ」「ＧＩＦ」「ＴＧＡ」等の業界標準フォーマットはアプリケーションに向き／不向きがあり万能ではない。
【００１５】
さらに、コンピュータがMacintosh （商品名）やWindows （商品名）の場合には、「カット＆ペースト」の機能を用いてやり取りする仕組が用意されているが、フォーマットは「ＰＩＣＴ」か「ＧＩＦ」に限定される。
【００１６】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、アプリケーションプログラムとプリンタドライバを実行するコンピュータを有する電子ファイリング装置において、コンピュータが前記プリントドライバを実行して、各アプリケーションプログラムにより伝達される印刷用の描画情報を複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換して電子ファイル用のデータベースに蓄積することにより、各アプリケーションプログラムからプリンタドライバに伝達された描画情報を各アプリケーションプログラムに共有できる文書ファイルとして管理することができる電子ファイリング装置および電子ファイリング方法を提供することである。
【００１７】
【課題を解決するための手段】
本発明に係る第１の発明は、複数のアプリケーションプログラムと、前記アプリケーションプログラムから伝達される印刷用の描画情報に基づいて電子ファイリングを行なうためのプリントドライバと、前記アプリケーションプログラム及び前記プリントドライバを実行するコンピュータとを有する電子ファイリング装置であって、
前記コンピュータは、前記アプリケーションプログラムからの印刷指示に応じて起動される前記プリントドライバを実行することによって、当該アプリケーションプログラムから伝達される印刷用の描画情報を受信し、当該受信した印刷用の描画情報を複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換し、当該変換された前記共通文書ファイル形式の描画情報を電子ファイリング用のデータベースに蓄積することを特徴とする。
【００１８】
本発明に係る第２の発明は、前記プリントドライバは汎用ドライバであり、前記データベースに蓄積された共通文書ファイル形式の描画情報を前記プリントドライバを介して検索する検索ドライバを更に有することを特徴とする。
【００１９】
本発明に係る第３の発明は、前記印刷用の描画情報は描画コマンドで構成され、
前記コンピュータは、前記プリントドライバを実行することによって、当該アプリケーションプログラムから伝達される前記印刷用の描画情報の各描画コマンドを解析して、複数の部分に分割し、当該分割した複数の部分に基づいて前記印刷用の描画情報を前記共通文書ファイル形式の描画情報に変換することを特徴とする。
【００２０】
本発明に係る第４の発明は、前記分割される複数の部分は、文字部分とベクトル描画部分と画像部分であることを特徴とする。
【００２１】
本発明に係る第５の発明は、前記プリントドライバは、プリントドライバをエミュレートしたファイリングドライバであって、
前記コンピュータは、前記アプリケーションプログラムからの印刷指示に応じて起動される前記ファイリングドライバを実行することによって、前記変換された描画情報を前記電子ファイリング用のデータベースに蓄積すると、印刷完了メッセージを送ることを特徴とする。
【００２２】
本発明に係る第６の発明は、前記コンピュータは、前記プリントドライバを実行することによって、前記分割された画像部分を解析して当該画像部分に含まれる文字情報を認識して抽出する光学文字認識処理を実行し、当該抽出された文字情報を蓄積することを特徴とする。
【００２３】
本発明に係る第７の発明は、複数のアプリケーションプログラムと、前記アプリケーションプログラムからの印刷指示に応じて起動されるプリントドライバと、前記アプリケーションプログラム及び前記プリントドライバを実行するコンピュータとを有する装置において、前記コンピュータが、前記プリントドライバを実行することにより、前記アプリケーションプログラムから伝達される印刷用の描画情報に基づいて電子ファイリングを行なうように制御する電子ファイリング方法であって、
前記アプリケーションプログラムからの印刷指示に応じて起動されたプリントドライバを前記コンピュータに実行させることによって、前記コンピュータが、当該アプリケーションプログラムから伝達される印刷用の描画情報を受信し、前記受信した印刷用の描画情報を複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換し、当該変換された前記共通文書ファイル形式の描画情報を電子ファイリング用のデータベースに蓄積するように制御することを特徴とする。
【００２９】
【実施例】
以下、図示の実施例に基づき詳細に説明する。
〔第１実施例〕
図１は本発明の第１実施例を示す電子ファイル装置の構成を説明するブロック図である。
【００３０】
図において、１，２，３は市販のアプリケーションであり、例えばスキャナアプリ，ワープロ，表計算アプリ等を示している。これらのアプリケーション間でデータのやり取りをするには、ファイル４，５を介して行うのは非常に困難である。なぜなら、スキャナアプリ，ワープロ，表計算アプリ等が生成するファイルのフォーマットはそれぞれのベンダが独自に定めたものなので、互換性は全くない。
【００３１】
ところが、これらのアプリケーションが印刷する際にプリンタドライバに引き渡すデータは、Macintosh （第１のコンピュータ系）の場合はQuickDraw （第１の出力データ）、Windows （第２のコンピュータ系）の場合はＧＤＩ（第２の出力データ）に統一されている。
【００３２】
図１に示す様に、第１のコンピュータ系のアプリケーション１，２，３がプリンタドライバ６に印刷データを渡す際、Postscriptアプリケーションの一部に例外はあるが、ほとんどのアプリケーションがQuickDraw の描画コマンド７，８，９をプリンタドライバ６に渡している。
【００３３】
本発明はこの特徴に着目し、プリンタドライバ６の中に文書変換／蓄積機能を実現した。すなわち、QuickDraw の描画コマンドはコンピュータに依存した描画コマンドであり、Macintosh のみに限定すればほとんどのアプリケーションに共通の言語があるが、Windows ではＧＤＩコマンドが用いられており、互換性はない。
そこで、QuickDraw −共通文書変換装置１０−１により、データベース１３にセーブしやすい一般的なドキュメントの形のデータ、すなわち、共通文書１２，１４に変換を行う。
【００３４】
なお、共通文書１２，１４はドローであってもペイントであっても、また混在していても構わない。ドローとは、描画の線の太さ，色，座標点を指定する数値で表現する描画方法で、それを受け取った側もその数値をデコードする機能がなければならない。
【００３５】
一方、ペイントとは、ビットマップ画像のことであり、データのサイズは大きくなるが、受け取った側のデコード機能は不要である。
【００３６】
１０−２はＯＣＲ装置で、ビットマップ画像をコード化する場合に用いるが、ドロー系の情報の場合には処理はバイパスする。
【００３７】
１０−３はキーワード抽出装置で、QuickDraw から変換された共通文書の中から、検索に使えそうな単語を拾いだし、その共通文書とセットでアクセスするためのものである。
【００３８】
１０−４はデータベースＡＰＩで、ローカルまたはネットワーク（ＬＡＮ）１１を介して接続されているリモートのデータベース１３に接続するためのものである。
【００３９】
プリンタドライバ６は、システムが提供するものに合わせるが、プリンタドライバ６は印刷だけを想定しているので、通常はデータの流れは一方通行であり、データベース１３から引き出した文書をQuickDraw コマンドに逆変換してアプリケーション１，２，３側に送ることはできない。
【００４０】
この問題を解決するために、本発明のプリンタドライバ６は汎用ドライバの形式になっている。プリンタドライバ６を介して双方向の文書変換をするためには、ＯＳやアプリケーションの変更が必要であるが、専用の文書検索ソフトウェアを用いた場合には双方向の文書変換が実現できる。共通文書１２はＬＡＮ１１を介してデータベース１３に送られる。
【００４１】
この装置を文書のファイリングシステムとして用いるには、通常スキャナ１５で原稿を読み取る。その制御はスキャナアプリ１が行うが、そのアプリが印刷する場合にはやはりQuickDraw ７に変換されてプリンタドライバ６に伝達される。
【００４２】
QuickDraw ７とはいっても、スキャン画像の場合には中身はビットマップであるから、QuickDraw −共通文書変換装置１０−１でビットマップに戻し、必要に応じて図示しない圧縮回路によって画像圧縮を行う。
【００４３】
プリンタドライバ６は、パソコンのＯＳがサポートするすべてのQuickDraw コマンドをサポートする必要がある。さもないと、あらゆるアプリケーションからの印刷要求に応えられない。
【００４４】
一方、アプリケーション１，２，３は自分の都合により一部のQuickDraw コマンドしかサポートしなくても何ら問題はなかった。ところが、プリンタドライバ６を双方向性にし、QuickDraw −共通文書変換装置１０−１が出力するQuickDraw コマンドを表示可能にするためには、やはりすべてのQuickDraw コマンドをサポートする必要がある。
【００４５】
なぜなら、その文書は自分より高機能なアプリケーションが作成したものかもしれないからである。
【００４６】
そのためプリンタドライバ６は、アプリケーションに伝達しようとしたドロー系のコマンドがアプリケーションドライバに理解できないと拒絶された場合には、それをペイント系のデータに変換して再度伝達しなおす。
【００４７】
これらの誤り制御機能のないアプリケーションのために、QuickDraw 運用に水準を設け、例えばＪＩＳの漢字コードの如く、第１，第２，第３水準に分類し、伝達しても理解されないことが分かっている場合には、あらかじめ低レベルのQuickDraw コマンドに変換して伝達してもよい。
〔第２実施例〕
図２は本発明の第２実施例を示す電子ファイル装置の構成を説明するブロック図であり、図１と同一のものには同一の符号を付してある。
【００４８】
なお、図１では市販のアプリケーション１，２，３からデータベース１３への文書蓄積を説明したが、市販のアプリケーションはやはり文書蓄積／検索用に設計されている訳ではないから、スピーディーな検索には専用の検索アプリ（アプリケーションプログラム）１６が必要となる。この検索アプリ１６はQuickDraw −共通文書変換装置１０−１と直接接続する。データフォーマットはQuickDraw ではなく共通文書フォーマット１７である。QuickDraw −共通文書変換装置１０−１は汎用ドライバとして構築されている。
〔第３実施例〕
図３は本発明の第３実施例を示す電子ファイル装置の構成を説明するブロック図であり、図１と同一のものには同一の符号を付してある。
【００４９】
なお、図３は、ＯＣＲアクセラレータ１０−５を使う場合の実施例である。
【００５０】
ＯＣＲアクセラレータ１０−５は、ＯＣＲには変換時間がかかるので、専用のハードウェアに処理を代行させることにより高速化を図るため、通常ハードウェアで実現される。
【００５１】
また、QuickDraw −共通文書変換装置１０−１はプリンタドライバ／汎用ドライバとしてソフトウェアで実現する。
【００５２】
一方、ＯＣＲ１０−２，キーワード抽出装置１０−３，データベースＡＰＩ１０−４はバックグラウンドで走る汎用ドライバとしてソフトまたはハードで実現し、これらが処理しているときでも、オペレータの他の操作を中断しない。
【００５３】
図４は、図３に示した電子ファイル装置におけるデータ処理系を説明する図である。
【００５４】
図において、１０−６はプリントキュー、１０−７はバッファメモリである。
【００５５】
QuickDraw −共通文書変換装置１０−１はもっぱらプリンタドライバ６と一体で動作し、プリントキュー１０−６への出力はフォアグランドで行う。
【００５６】
一方、ＯＣＲ１０−２以下はプリントキュー１０−６から文書データをバックグランドで受取り、アプリケーション１，２，３，１６と同時並行的に処理する。メモリ１０−７は、プリントキュー１０−６が一時的に文書データを蓄えておくためのものである。
〔第４実施例〕
図５は本発明の第４実施例を示す電子ファイルシステムの構成を説明するブロック図であり、図１と同一のものには同一の符号を付してある。
【００５７】
図において、左半分は図１のパソコンと同じものであり、説明上必要な番号には「ａ」の枝番を付けてある。
【００５８】
一方、右半分は第２のパソコンで「ｂ」の枝番を付けたものは、「ａ」の枝番の付いた同じ番号の要素と同じものである。第１のパソコン（左）にはスキャナ１５をそのまま残して説明してあるが、第２のパソコン（右）にスキャナがない場合の状態を説明している。
【００５９】
この場合、ＯＣＲ，キーワード検索，データベースＡＰＩ機能は不要なので、図示される傾斜線で示した様に機能を止めて使う。ネットワーク上を流れるデータが共通文書である限りは、アプリケーションとのインタフェースは共通文書であっても他のフォーマット、すなわち、QuickDraw であっても構わない。
【００６０】
スキャナ１５からのデータは、プリンタドライバ６が共通文書に変換するので、何ら問題なく相互通信が可能である。
〔第５実施例〕
図６は本発明の第４実施例を示す電子ファイル装置の構成を説明するブロック図であり、図１と同一のものには同一の符号を付してある。
【００６１】
図において、２０−１はQuickDraw −共通文書変換ドライバインタフェース、２０−２はユニットで、ＯＣＲユニット，構文解析ユニット，逆ＰＤＬユニットの集合である。２０−３はファイル構築ルーチンである。２０−１で印刷時の描画コードはQuickDraが解析され、文字部分，ベクトル描画コード部分，ビットマップ画像部分，中間調画像部分に分けられる。ビットマップ画像部分と中間調画像部分はＯＣＲに掛けられ、文字部分がコードとして抽出される。
【００６２】
ベクトル描画コード部分は、いくつかの描画コードの集合の単位で逆ＰＤＬユニットで処理され、「表」，「画」，「マーク」，「閉曲線」等の機能要素に区分される。機能要素に入らないものは、「線」，「円」，「四角」，「楕円」，「円弧」，「自由曲線」等に分類する。
【００６３】
ユニット２０−２の構文解析ユニットは、主にテキスト部分の構文を解析して、それを「タイトル」，「章」，「節」，「段落」，「ヘッダ」，「文」，「フッタ」，「ページ」，「日付」等に区分する。それらの区分に入らないものは、「テキスト」として扱われる。そのようにして分類解析された共通文書は、ファイル構築ルーチン２０−３で共通文書１２に落とされる。
【００６４】
一旦、共通文書１２に落とされれば、該ファイルフォーマットを理解できる編集アプリ１９で標準のＯＳのインタフェース１８を介して再編集が可能となる。
【００６５】
以下、本実施例と第１〜第６の発明の各手段との対応及びその作用について図１〜図６を参照して説明する。
【００６６】
第１の発明は、所定のオペレーティングシステム（ＤＯＳ／Ｖ，漢字トーク等，ＵＮＩＸ）に準拠する複数のアプリケーションプログラム（アプリケーションプログラム１，２，３）を起動して作成編集される文書，表組，画像のファイル情報を処理可能なコンピュータシステムと、このコンピュータシステムで起動可能な各アプリケーションプログラムから伝達される各描画情報を前記所定のオペレーティングシステムが規定する所定の印刷データ形式に変換するプリントドライバ手段（プリンタドライバ６）と、このプリントドライバ６により所定の印刷データ形式に変換された印刷データを前記複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換する変換手段（本実施例では、プリントドライバ６のサブドライバとして組み込む構成となっているQuickDraw −共通文書変換装置１０−１）と、この変換手段に変換された前記共通文書ファイル形式に従う共有ファイルを記憶する記憶手段（データベース１３）とを有し、コンピュータシステムで起動可能な各アプリケーションプログラムから伝達される各描画情報がプリントドライバ６により前記所定のオペレーティングシステムが規定する所定の印刷データ形式に変換されると、QuickDraw −共通文書変換装置１０−１が所定の印刷データ形式に変換された印刷データを前記複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換し、該変換された前記共通文書ファイル形式に従う共有ファイル（共通文書１２）を記憶媒体に記憶して、各アプリケーションプログラムからプリントドライバに伝達された描画情報を各アプリケーションプログラムに共有できるファイルとして管理することを可能とする（図１，図２，図３等参照）。
【００６７】
第２の発明は、各アプリケーションプログラムの汎用ドライバとしてコンピュータシステムに組み込まれる検索ドライバ（検索アプリケーション１６等（図３参照）が記憶手段（データベース１３）に記憶された共通文書ファイル形式に従う共有ファイルをQuickDraw −共通文書変換装置１０−１を介して検索して、共有ファイルを各アプリケーションプログラムで直接的に処理可能とする。
【００６８】
第３の発明は、プリントドライバ６は、各アプリケーションプログラムから伝達される各描画情報を解析して、文字部分，ベクトル描画部分，ビットマップ画像部分，中間調画像部分とに分割して、該分割された文字部分，ベクトル描画部分，ビットマップ画像部分，中間調画像部分に圧縮処理した圧縮データを生成し、記憶媒体に登録するデータボリュームをできるだけ小さくすることを可能とする。
【００６９】
第４の発明は、変換手段（QuickDraw −共通文書変換装置１０−１）は、プリントドライバにより所定の印刷データ形式に変換された圧縮データを前記複数のアプリケーションプログラムが直接参照可能な共通文書ファイル形式に変換して、各アプリケーションプログラムからプリントドライバに伝達された描画情報を圧縮した圧縮データを各アプリケーションプログラムに共有できるファイルとして管理することを可能とする。
【００７０】
第５の発明は、プリントドライバ６により分割されたビットマップ画像部分，中間調画像部分を光学文字認識処理手段が解析して文字情報をＯＣＲ装置１０−２により（本実施例ではプリントドライバ６のサブドライバとして構成される）認識して抽出し、該抽出された文字情報を既に分割された文字部分に追加して、画像情報中の文字画像を文字情報として利用可能とする。
【００７１】
第６の発明は、所定のネットワークを介して各電子ファイル装置間で共有ファイルを転送可能（図５等参照）とし、ネットワーク上で各アプリケーションプログラム（アプリケーションプログラム１，２，３）でにより生成されたファイルを共有ファイルとして処理可能とする。
【００７２】
上記各実施例によれば、アプリケーションが印刷する場合に出力するデータ形式はＯＳ毎に標準化されているという点に着目し、プリンタドライバの部分に「統一したファイル形式への変換機能」，「ＯＣＲ機能」，「キーワード検索機能」を構築することにより、パソコンのアーキテクチャーの違いによらず、あらゆる市販アプリで作成した文書を、統一した１種類のフォーマットで保存することができた。
【００７３】
また、本実施例によれば、従来ハード／ソフト共にスタンドアロンの機械として提供されていた文書蓄積／検索装置を、市販されているコンピュータをベースにし、市販されている幾多のアプリケーションをフロントエンドとする文書蓄積／検索機能を自在に組み込むことでできる安価なシステムを提供できる。
【００７４】
なお、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器から成る装置に適用しても良い。また、本発明はシステムあるいは装置にプログラムを供給することによって達成させる場合にも適用できることは言うまでもない。
【００７５】
以下、図７〜図１１等を参照して本発明に係る電子ファイルシステムにおけるファイル処理方法について説明する。
【００７６】
図７は本発明に係る電子ファイルシステムにおけるファイル処理方法のメイン処理手順の一例を示すフローチャートである。なお、（１）〜（５）はアプリケーション側のステップを示し、（６）〜（１３）はＯＳ側のステップを示し、（１４）〜（１９）はファイリングドライバ側のステップを示す。
【００７７】
なお、本実施例では、ＯＳがマルチタスクのものならもちろんのこと、シングルタスクの場合でも、アプリケーションとＯＳ，ドライバの処理動作は見かけ上独立したタスクのように振舞うから、図７に示すように、３種の独立タスクのように記載することは何ら問題とはならない。また、図中の点線の矢印で示してある部分は、実際には関数コールであるが、プログラム言語（Ｃ＋＋）やクラス定義の中では「メッセージ」という表現を用いることが一般的であり、ここではその例に習うものとする。
【００７８】
まず、アプリケーションがドキュメントを作成して（１）、それを本発明に係る電子ファイルシステムにファイルする時、通常の印刷動作と全く同じ操作を行う。印刷メニューを選択すると（２）、ＯＳに対して印刷開始メッセージが送られる。ＯＳはこの時種々のＯＳサービスを実行しながら（６）、イベントループに入っていて（７）、印刷開始メッセージを受け付けると、ドライバを起動する（８）。
【００７９】
ファイリングドライバは、レジスタセットやメモリ空間の確保等の初期化処理を実行した後（１４）、初期化完了メッセージをＯＳに返す。この間、ＯＳはドライバからの返事をループで待っている（９）。
【００８０】
そして、アプリケーションに対し、ドライバの準備が整ったことを示すメッセージを送る（１０）。これを受けて、アプリケーションはステップ（３）のループから抜け出し、プリンタに描画すべきＧＤＩコードを出力する（４）。該ＧＤＩコードを受け取ったＯＳは、プリンタ（ドライバ）がＧＤＩプリンタならば、ＧＤＩコードのままで、また、ビットマッププリンタならば、ＯＳの中でＧＤＩコードをラスタライズしてプリンタドライバに渡す（１１）。ファイルドライバば、プリンタドライバをエミュレートしており、ＧＤＩプリンタかビットマッププリンタのどちらかであることを宣言する必要がある。そのどちらでも実現可能である。
【００８１】
もし、ＧＤＩプリンタであると宣言すると、ＯＳからはＧＤＩコードがそのままの形で送られて来るので、ドライバの中では容易にＧＤＩコードの解析ができるし、ビットマップが必要なら、ＯＳのシステムコールを呼んで、ラスタライズすることができる。
【００８２】
もし、ビットマッププリンタであると宣言すると、ＯＳの中でＧＤＩをビットマップに変換するＧＤＩサービスが実行され（１１）、ファイリングドライバにはビットマップが渡される（１５）。
なお、ＯＳがWindows の場合、たとえビットマップにしても、ビットマップコードの片隅に元のＧＤＩコードが記載されているから、本発明ではビットマップを宣言することにする。
【００８３】
ファイリングドライバは、受け取ったＧＤＩコードを解析して（１６）、原稿に書かれている内容の特徴を抽出し（１７）、それをデータベースに保存する（１８）。ファイリングドライバからＯＳに対し、印刷完のメッセージが届いたら、ドライバの処理待ちになっているループ（１２）から抜け出し、印刷完了メッセージをアプリケーションに送るとともに（１３）、ファイリングドライバを終了させ、メモリ空間からスワップアウトする。アプリケーションは、ＯＳからの印刷完了メッセージを受けて、印刷シーケンスを終了する（５）。なお、ファイリングドライバは、ステップ（１８）でデータベースに保存したら、メモリ空間を解放する（１９）。
【００８４】
図８は、図７に示したファイリングドライバによるＧＤＩコード解析および特徴抽出処理の詳細手順を示すフローチャートである。なお、（２０）〜（２９）は各ステップを示す。
【００８５】
ＯＳ経由でアプリケーションから渡されたＧＤＩコードを取得したら（２０）、該ＧＤＩコードを解析し（２１）、画像か、文字か、ドローかを区別する（２１）〜（２３）。なお、本実施例において、ドローとは、ベクトル情報の集合による線図形，面図形を用いた描画をいう。
【００８６】
そして、ステップ（２１）でＹＥＳの場合は、画像を表すＧＤＩコードを、ＪＢＩＧ，ＪＰＥＧ，ＭＭＲ等の圧縮アルゴリズムを用いて圧縮され、画像バッファに保存される（２４）。
【００８７】
一方、ステップ（２２）でＹＥＳの場合は、文字を表すＧＤＩコードは文字バッファに蓄えられ、文字バッファの処理でタイトルであるかどうかの判定を受けた後、文字に関する各種の情報（文字コード，スタイル，文字色）を保存し、キーワードとして登録する（２５）。
【００８８】
一方、ステップ（２３）でＹＥＳの場合は、ドロー部分のＧＤＩコードは、ドロー情報の処理ルーチン（詳細は後述する）において、表，図形の判定を受け、さらに統計処理を受ける（２７）。
【００８９】
一方、ステップ（２３）でＮＯすなわち、ＧＤＩコードが上記のいずれでもない時は、制御コードであるから、ステップ（２６）において、制御コードの処理を行う。制御コードの中身は、例えば紙サイズ指定であり、また、紙方向指定，解像度指定，余白指定，頁番号指定，印刷枚数指定，改頁であるかもしれない。
【００９０】
次いで、すなわち、ステップ（２４），（２５），（２６），（２７）の後は、次のＧＤＩコードを取得するための準備に入る（２８）。もし、制御コードが終了コードであった時は、ＧＤＩコードの解析は終了するが、そうでない場合には次のＧＤＩコードを取得するためにステップ（２）にループする。
【００９１】
図９は、図８に示した文字バッファの処理ルーチンの詳細手順を示すフローチャートである。なお、（３０）〜（３８）は各ステップを示し、該ステップにより、文字バッファに蓄えられた文字情報を解析して、タイトル文字かどうかの判定を行い、キーワードとして登録する処理を行う。
【００９２】
なお、ＧＤＩコードの場合、文字コードは一連のストリング（文章）になって表現されるとは限らない。ストリングのＧＤＩコードを吐き出すアプリケーションは、エディタと呼ばれるソフトウエア程度で、高級なＤＴＰアプリケーションになればなるほど、むしろ１文字１文字描画する場合が多い。高級なＤＴＰアプリケーションは、ＧＤＩコードの表現能力を越えた高度の文章表現をするので、１文字１文字の描画になることが多い。
【００９３】
先ず、１個前の文字との距離を計算し（３０）、文字の高さの１／２より狭いかどうかを判定し（３１）、ＮＯならば、すなわち、文字の高さの１／２より以上であれば単語の区切りと判定して（３２）、キーワード登録する。
【００９４】
その中でも、タイトルと思われる文字は、特別に保存し、タイトル文字として検索の用に供する。タイトルと判定するアルゴリズムは、対象とする文字が原稿の縦寸法の上から１／４以内にあり（３３）、かつ、原稿中で最大サイズの文字ならタイトルと判定する（３４），（３５）。それ以外の文字は、タイトル以外の文字としてキーワード登録する（３６）。なお、タイトル自身もキーワードであることはいうまでもない。  一方、ステップ（３１）の判定でＹＥＳの場合は、すなわち、文字の高さの１／２より狭い場合は、前の文字ととともに単語を構成していると判定し（３７）、該単語の区切りを見つけるために、文字情報を文字バッファに書き込み（３８）、該ルーチンを終了する。
【００９５】
図１０は、図８に示したドロー情報の処理ルーチンの詳細手順を示すフローチャートである。なお、（４０〜（５０）は各ステップを示す。また、図１１に示すドロー情報例を参照して処理動作を説明する。
【００９６】
先ず、ＧＤＩコードが直線かどうかを判定し（４０）、直線であれば、さらに表であるかどうかを判別するルーチンに入るが、直線以外の円，楕円，四角，ポリゴン，斜め線，曲線等であり、単純にドロー画グループに加え（４９）、保存する。
【００９７】
一方、ステップ（４０）で、直線と判別された場合、既に登録済みの直線グループの中の線と接するかどうかを判定する（４１）。判定方法は、直線の持つ２点（始点，終点）の持つＸ座標とＹ座標のどれが直線グループの中の線の持つ２点の座標のどれかと１つでも一致し、かつ、他の座標が所定範囲内であれば接していると判別できる。例えば図１１に示すように、２本の線Ａ，Ｂが接しているとかどうかを判別する場合、Ｘ１＝Ｘ３であるかどうかをチェックするだけで良い。
【００９８】
また、線Ａ，Ｂも斜め線でないことは解っているので、Ｘ１＝Ｘ３＝Ｘ４でもある。さらに、線ＢのＹ座標は、Ａの始点と終点の間になければならないから、Ｙ４≦Ｙ１≦Ｙ３でなければならない。すなわち、２本の直線を有する４種類のＸ，Ｙ座標の内、３つが一致する成分を調べ、もし一致する場合には、２つとも一致する成分を持つ直線の他方の成分の間に他の線分の同じ座標が入っていれば、接していると判別できる。これが、Ｘ座標，Ｙ座標ともに成立するときは、ｔ２本の直線Ａ，Ｂは直角を形成する。
【００９９】
そこで、ステップ（４１）で、どの直線グループとも接しないと判別された直線は、それ自身が新たな直線グループを形成するものとして登録する（５０）。
【０１００】
一方、接することが解った直線については、その直線グループの一員として加える（４２）。
【０１０１】
ある直線グループを有するＸ座標，Ｙ座標のうち、最大，最小の４つを、その直線グループの矩形領域と定める。この矩形領域は、新たな直線が加わる毎に再計算する（４３）。その直線グループの構成するＸ座標だけまたはＹ座標だけの種類の数を求め、それから「１」を引いた数がセル数として導出される（４４）。
【０１０２】
また、同様に、Ｘ座標の成分と、Ｙ座標の成分を別々に大きさ順に並べ、互いに接近する座標同志の差分がセルサイズとなる（４５）。
【０１０３】
この直線グループの矩形領域の中に、文字が入るかどうかを判定し（４６）、文字が入る場合には、その文字を表中の文字として特別に登録し（４７）、かつ、その直線グループを表と判定する（４８）。なお、文字を全く含まない直線グループは表とは見做さない。
【０１０４】
【発明の効果】
以上説明したように、本発明によれば、アプリケーションとプリンタドライバを実行するコンピュータが各アプリケーションプログラムからプリンタドライバに伝達された描画情報を各アプリケーションプログラムに共有できる文書ファイルとして管理することができる。
また、共有できる文書ファイルを各アプリケーションプログラムが直接的に処理できる。
さらに、データベースに蓄積する共通文書ファイル形式の描画情報のデータボリュームをできるだけ小さくできる等の効果を奏する。
【図面の簡単な説明】
【図１】本発明の第１実施例を示す電子ファイル装置の構成を説明するブロック図である。
【図２】本発明の第２実施例を示す電子ファイル装置の構成を説明するブロック図である。
【図３】本発明の第３実施例を示す電子ファイル装置の構成を説明するブロック図である。
【図４】図３に示した電子ファイル装置におけるデータ処理系を説明する図である。
【図５】本発明の第４実施例を示す電子ファイルシステムの構成を説明するブロック図である。
【図６】本発明の第５実施例を示す電子ファイル装置の構成を説明するブロック図である。
【図７】本発明に係る電子ファイルシステムにおけるファイル処理方法のメイン処理手順の一例を示すフローチャートである。
【図８】図７に示したファイリングドライバによるＧＤＩコード解析および特徴抽出処理の詳細手順を示すフローチャートである。
【図９】図８に示した文字バッファの処理ルーチンの詳細手順を示すフローチャートである。
【図１０】図８に示したドロー情報の処理ルーチンの詳細手順を示すフローチャートである。
【図１１】図１０に示したドロー情報の処理ルーチンで使用するドロー情報の一例を示す図である。
【符号の説明】
１  アプリケーション
２  アプリケーション
３  アプリケーション
６  プリンタドライバ
１０−１  QuickDraw −共通文書変換装置
１０−２  ＯＣＲ装置
１０−３  キーワード抽出装置
１０−４  データベースＡＰＩ（アプリケーション・プログラム・インタフェース）
１２  共通文書
【図１】
0003689441.tif 000002
【図２】
0003689441.tif 000003
【図３】
0003689441.tif 000004
【図４】
0003689441.tif 000005
【図５】
0003689441.tif 000006
【図６】
0003689441.tif 000007
【図１１】
0003689441.tif 000008
【図７】
0003689441.tif 000009
【図８】
0003689441.tif 000010
【図９】
0003689441.tif 000011
【図１０】
0003689441.tif 000012