JP2012059275A - デジタルドキュメント処理のためのシステム及び方法 - Google Patents

Abstract

【課題】表示のためのグラフィカルユーザーインターフェースのツール及び制御を提供するアプリケーションの必要をなくし、あるいは減じる表示技術。
【解決手段】デジタルドキュメント内のコンテンツを基本構造の内部表示を表すドキュメントオブジェクトのセットに変換するドキュメントエージェントと、前記デジタルコンテンツを表すディスプレイを生成するために、前記ドキュメントオブジェクトをレンダリングするコアドキュメントエンジンと、前記デジタルドキュメントのコンテンツを修正するための入力を表す入力信号を検出するユーザーインターフェースと、前記デジタルコンテンツのディスプレイを修正するために、前記入力信号のファンクションとして、前記コンテンツの前記内部表示を変更させるプロセスと、を含むことを特徴とする。
【選択図】図２

Description

本発明は、データ処理システムに、より詳しくは、画像表示、ハードコピーとして、あるいは幾つかの他の表示形式で、ソースドキュメントの出力表示を生成するためにデジタルドキュメントを処理するための方法及びシステムに関する。

本出願は、先に出願された、２０００年４月１４日出願の英国特許出願０００９１２９．８号及び２０００年１０月３１日出願の米国特許出願０９／７０３，５０２号に優先権を主張しており、両方とも発明者としてマジッド アンワーを有し、その内容が参考のためこの明細書に組み入れられる。

ここで用いられるような用語「デジタルドキュメント（ｄｉｇｉｔａｌ ｄｏｃｕｍｅｎｔ）」は、典型的には、視覚的に表示又は再生されることにより（例えば、画像表示装置又はプリンタにより）、あるいはテキスト音声変換によるなどして、全部又は一部が最終的には人間のユーザーへの幾つかの形式の出力になることを意図されたデータ処理システムにより処理されるいずれかのタイプのデータのデジタル表現を示すのに用いられる。デジタルドキュメントは、表示可能ないずれかの特徴を含んで良く、これらに制限されないが、テキスト、グラフィックイメージ、動画のグラフィックイメージ、フルモーションのビデオ画像、インタラクティブアイコン（ｉｎｔｅｒａｃｔｉｖｅ ｉｃｏｎ）、ボタン、メニュー、あるいはハイパーリンクを含む。デジタルドキュメントは、聴覚（音）の要素のように視覚でない要素を含んでも良い。

パーソナルコンピューターシステムのようなデータ処理システムは、幾つかのローカル又はリモートソースのいずれか一つからもたらされ、また幅広い種類のデータ形式（「ファイル形式」）のいずれか一つで存在し得る「デジタルドキュメント」を処理することを要求されるのが典型的である。画像表示としてであろうと、プリントコピーとしてであろうと、このドキュメントを出力したものを生成するためには、例えば、コンピューターシステムが元のデータファイルを翻訳し、関連する出力装置（例えば、モニター、あるいは他の画像表示装置又はプリンタ）と互換性のある出力を生成する必要がある。通常、この処理は、データファイルを翻訳するのに適合したアプリケーションプログラム、コンピューターのオペレーティングシステム、所望の出力装置に特有のソフトウェア「ドライバ」、そして場合によっては（特に、モニター、又は他の画像表示装置のために）、拡張カードの形態の追加のハードウェアを含むことになる。

出力を生成するためのデジタルドキュメントの処理に対するこの従来のアプローチは、ハードウェア資源、ソフトウェアのオーバーヘッド、ならびに処理時間の点で不十分であり、ワイヤレス電気通信システムを含む低電力のポータブルデータ処理システム、あるいはネットワーク端末のような低コストのデータ処理システム等に対しては、完全には適合しない。従来のデジタルドキュメント処理システムでは、（ハードウェアとソフトウェアの両方の構成要素を含む）複数のシステム構成要素を構成して所望の手段で対話する必要性と、異なるシステム（例えば、フォーマティング、色再生等の違い）による同一のソースマテリアルの処理の不一致とを含む他の問題に直面した。加えて、デジタルドキュメント処理に対するこの従来のアプローチは、ファイル形式の構成要素の共通性及び／又は再利用性を利用することができない。

従来の方法及びシステムの前記不都合を回避しあるいは減じる、デジタルドキュメントの処理方法及びシステム、ならびにこのような方法及びシステムに組み込む装置を提供することが本発明の目的である。

ここで記載されるシステム及び方法は、アプリケーションプログラムの基礎的機能をグラフィック表示処理から切り離し、これにより、装置の表示を制御し、ならびに表示のためのグラフィカルユーザーインターフェースのツール及び制御を提供するアプリケーションの必要をなくし、あるいは減じる表示技術を提供する。さらに、このようなシステムは、アプリケーションプログラムにより、又はために作成された、ドキュメント又はビデオストリームのようなデータを表示する時に処理システムにあるべきアプリケーションプログラムの必要を減じ、あるいはなくす。したがって、ある態様では、ここに記載されるシステム及び方法は、コンテンツを表示するシステムにあるべき基礎的なアプリケーションの必要なしで、ドキュメント、ビデオストリーム、又は他のコンテンツを含むコンテンツを表示することができ、そしてその表示されたドキュメントを見るために、ズーム、パン、あるいは他のそのような機能のようなグラフィカルユーザー機能を提供することが理解される。ここに記載されるシステム及び方法の従来技術を超える利点は、異なるアプリケーションプログラムからの異なるタイプのコンテンツが、同じ作業領域内で同じ表示上に示されることを可能にする利点を含む。多くのそれ以上の利点が、当業者には明らかであり、また、当業者は、追加のシステム、装置、及びアプリケーションを作成するために、本発明の基礎をなす技術を用いる多くの手段を見抜くことができる。これらの改変したシステム、ならびに代わりのシステム及び実施が、本発明の範囲内に入ることが理解される。

より詳しくは、ここで記載されるシステム及び方法は、複数ある所定データ形式の一つでソースデータを表している入力バイトストリームを受け取るため、そして該入力バイトストリームを所定データ形式の一つと結び付けるためのアプリケーションディスパッチャを含むデジタルコンテンツ処理システムを含む。また、このシステムは、前記入力バイトストリームを、前記結び付けた所定データ形式のファンクションとして翻訳するため、そしてその入力バイトストリームを、入力バイトストリーム内の基本構造の内部表現を提供するドキュメントオブジェクトのストリームに解析するためのドキュメントエージェントを含んでも良い。また、このシステムは、前記ドキュメントオブジェクトを、前記内部表現データ形式に変換するため、そしてその内部表現データを、表示上の位置にマッピングするためのコアドキュメントエンジン（ｃｏｒｅ ｄｏｃｕｍｅｎｔ ｅｎｇｉｎｅ）も含む。このシステム内の形状プロセッサは、前記内部表現データを処理して、内部表現により表わされるようなコンテンツを表示すべく出力装置を動作する。

本発明の態様が、単なる一例として、添付の図面を参照して以下に記載される。

本発明の前記及び他の目的ならびに利点が、以下のそのさらなる記載から、添付の図面を参照して、さらに十分に理解される。

本発明によるデジタルドキュメント処理システムの一つの態様を説明するブロック線図である。 図１に描かれたシステムをより詳細に表すブロック線図である。 あるドキュメントエージェントのフローチャート図である。 図１のシステムにより処理できるタイプの例示的なドキュメントを模式的に描く。 ドキュメントの内部表現内での冗長を減じるのに用いられる２つの例示的な処理のフローチャート図を描く。 処理されるソースドキュメントの内部表現を格納するための例示的なデータ構造を描く。 処理されるソースドキュメントの内部表現を格納するための例示的なデータ構造を描く。 処理されるソースドキュメントの内部表現を格納するための例示的なデータ構造を描く。

幾つかの図示された態様の詳細な説明 ここに記載されるシステム及び方法は、ビデオディスプレイのような出力装置に出力を表示する目的でアプリケーションプログラムにより生成される出力ストリーム又は出力ファイルを処理すべく動作するコンピュータープログラムを含む。本発明によるアプリケーションは、これらのストリームを処理してその出力の内部表現を作成することができ、そして、この内部表現をさらに処理して、本発明によるアプリケーションにより生成される出力として出力装置に表示できる新しい出力ストリームを生成することができる。したがって、本発明のシステムは、アプリケーションプログラムを表示処理から切り離し、それ故に、アプリケーションプログラムを、特定の表示装置に出力を表示する必要があることから解放し、さらに、アプリケーションプログラムを、出力を表示する目的でアプリケーションの出力を処理する時に存在させる必要をなくす。

この動作を説明するのに、図１は、要素１３として集合的に示される複数のアプリケーションプログラムが、出力ストリームを処理しそして装置２６に表示するためにそのストリームにより作成される集合的な出力の表現を生成するコンピューター処理８に、出力ストリームを引き渡すことを可能にするシステム１０のハイレベル機能ブロック図を提供する。このアプリケーションプログラム１３の集合的な出力は、様々なアプリケーションプログラム１３により生成される出力コンテンツを表示する出力プリンタ装置２６により図１に描かれる。出力装置２６はコンピューター処理８により生成される出力を表していること、そしてこの出力は複数のアプリケーションプログラム１３のコンテンツを集合的に引き渡すことが、当業者により理解される。図１により提供される説明図では、表示されたコンテンツは、複数の画像からなり、出力装置２６はディスプレイである。しかし他の実施では、例えば聴覚、触覚、又はいずれか他の形式、あるいはユーザーに情報を伝えるのに適した形式を組合せたものといった、画像以外の形式で引き渡されてよいことが当業者には明らかである。さらに、当業者には、出力装置２６のタイプはアプリケーションにより変わり、音声のコンテンツ、ビデオのコンテンツ、印刷のコンテンツ、プロットのコンテンツ、あるいはいずれか他のタイプのコンテンツを表示するための装置を含んでよいことが理解される。説明するために、ここに記載されるシステム及び方法は、表示装置により画像を表示することとして概ね示されるが、これらの例示的なシステムは、単に説明のためであって、いずれかの手段に制限しているように理解されるべきではないことが理解される。したがって、アプリケーションプログラム１３により生成される出力は、コンピューター処理８により処理され、そして集合させられて、それぞれのアプリケーションプログラム１３により生成されるすべてのコンテンツを含む単一の表示を作成する。

描かれた態様では、ディスプレイ２６に現れるそれぞれの表現の出力は、ドキュメントと呼ばれ、それぞれの描かれたドキュメントはアプリケーションプログラム１３の一つと結び付けることができる。ここで用いられるような用語、ドキュメントは、ドキュメントと、ストリームビデオと、ストリーム音声と、ウェブページと、コンピューター処理８により処理及び表示されることができるいずれか他の形態のデータを含むことが理解される。コンピューター処理８は、その出力表示中に、アプリケーションプログラム１３から生成された一つ以上のドキュメントを含む単一の出力表示を生成する。表示されるドキュメントのこの集合体は、アプリケーションプログラム１３により生成されるコンテンツを表し、このコンテンツは、コンピューター処理８により生成されるプログラムウィンドウ内に表示される。コンピューター処理８のためのプログラムウィンドウは、グラフィカルユーザーインターフェースに具備され、しかもユーザーがプログラムウィンドウに現れるドキュメントの動作を、この場合は画面表示を、制御するのを可能にするツールを表す一連のアイコンを含んでも良い。

反対に、各アプリケーションプログラムが各自の表示を形成させるものである従来のアプローチは、複数のプログラムウィンドウを、典型的には各アプリケーションプログラム１３毎に一つを含んだ表示装置２６での表示に結果としてなる。加えて、それぞれ異なるタイプのプログラムウィンドウは、そのウィンドウで表示されるコンテンツを操作するために異なるセットのツールを含む。したがって、本発明のシステム１０は、一致したユーザーインターフェースを提供し、異なるドキュメントを表示及び制御するために一セットのツールの知識を必要とするだけである利点を有する。加えて、コンピューター処理８は、アプリケーションプログラム１３の出力で動作し、それ故に、プログラムウィンドウ内に現れるドキュメントを作成するためにはその出力を必要とするだけである。したがって、アプリケーションプログラム１３が処理８と同じマシンに常駐するか、あるいは、アプリケーションプログラム１３がコンピューター処理８に合わせて動作する必要がない。コンピューター処理８は、これらのアプリケーションプログラム１３からの出力のみを必要とし、この出力は、早いうちにアプリケーションプログラム１３により作成された格納データファイルから引き渡されることができる。しかし、ここに記載されるシステム及び方法は、アプリケーションプログラムが自身のコンテンツを表示でき、少なくともディスプレイ２６の一部を制御でき、そしてそのアプリケーションプログラムと結び付けられたプログラムウィンドウ内でそのコンテンツを表示できるシステムの一部として用いられて良い。これらの態様では、本発明のシステム及び方法は、使用するために提供されるディスプレイの一部の中でそのディスプレイに現れる別々のアプリケーションとして動作することができる。

より詳しくは、図１は複数のアプリケーションプログラム１３を描く。これらのアプリケーションプログラムは、例えば、ワード(Ｗｏｒｄ)、ワードパーフェクト(ＷｏｒｄＰｅｒｆｅｃｔ)、あるいはいずれか他の同様のワードプロセッシングプログラムといったワードプロセッシングプログラムを含むことができる。それは、さらに、例えば、ＨＴＭＬファイルを生成するネットスケープコンポーザー（Ｎｅｔｓｃａｐｅ Ｃｏｍｐｏｓｅｒ）や、ＰＤＦファイルを処理するアドビアクロバット（Ａｄｏｂｅ Ａｃｒｏｂａｔ）や、ＸＭＬ又はＨＴＭＬを引き渡すウェブサーバーや、音声映像データのストリームを生成するストリーミングサーバーや、電子メールクライアント又はサーバーや、データベースや、表計算や、あるいはファイル、データストリームとして、又はコンピューター処理による使用に適した幾つかの他の形式でのいずれかで出力を引き渡すいずれか他の種類のアプリケーションといったプログラムを含む。図１の態様では、それぞれのアプリケーションプログラム１３は、コンピューター処理８にその出力コンテンツを提示する。動作において、これは、アプリケーション処理１３に、その出力ストリームをコンピューター処理８への入力バイトストリームとして導かせることにより起き得る。データストリームの使用は、当業者によく知られており、例えば、Ｓｔｅｐｈｅｎ Ｇ． Ｋｏｃｈａｎ， Ｐｒｏｇｒａｍｍｉｎｇ ｉｎ Ｃ， Ｈａｙｄｅｎ Ｐｕｂｌｉｓｈｉｎｇ （１９８３）を含む文献に記載されている。付随的に、アプリケーションプログラム１３は、別のアプリケーションによるかあるいはコンピューター処理８によるかのいずれかでコンピューター処理８に流される、例えばワードドキュメントといったデータファイルを作成できる。

コンピューター処理８は、表示装置２６に示される集合した表示を作成するために様々な入力ストリームを処理することができる。このために、そして以下により詳細に示されるように、コンピューター処理８は入力ストリームを処理して、これらの入力ストリームのそれぞれの内部表現を生成する。ある実施では、この内部表現はそれぞれのアプリケーションプログラム１３の出力ストリームに出来るだけ近づくように意図される。しかし、他の態様では、内部表現は、それぞれのアプリケーションプログラム１３により生成される出力ストリームに、選択的に、簡略的に、あるいは部分的に類似させるべく作成される。加えて、あるいは付随的に、ここに記載されるシステム及び方法は、翻訳されるコンテンツにフィルタを適用しても良く、それにより、そのコンテンツの一部が、表示されあるいは提示されるコンテンツから除去されるのを可能にする。さらに、ここに記載されるシステム及び方法は、ソースドキュメントの構造を変えることを可能にしてよく、ドキュメント内のコンテンツを再位置付けし、ドキュメントの構造を並べ換え、あるいはあるタイプのデータのみを選択することを可能にする。同様に、ある付随的な態様では、ウェブサイトへのリンクのようなアクティブコンテンツを含むコンテンツが、翻訳処理の間に付け加えられることができる。いずれにしても、コンピューター処理８により作成される内部表現は、コンピューター処理８によりさらに処理されて、図１に表される集合した画像を作成するために表示装置２６を動作することができる。

図２を参照すると、図１のシステムのより詳細な表現が提示される。特に、図２は、そのコンピューター処理８、ソースドキュメント１１、及び表示装置２６を含むシステム１０を描く。コンピューター処理８は、複数のドキュメントエージェント１２と、内部表現形式ファイル及び処理１４と、バッファ格納１５と、ジェネリックオブジェクトのライブラリ１６と、この態様では解析モジュール１８及びレンダリングモジュール１９からなるコアドキュメントエンジンと、内部ビュー２０と、形状プロセッサ２２と、最終出力２４とを含む。図２は、さらに、ユーザー入力４０をコンピューター処理８に伝えるための付随的な入力装置３０を描く。描かれた態様は、形状プロセッサ２２を含む処理８を含む。しかし、描かれた処理８は、単なる例示であり、代わりの処理及びアーキテクチャにより実現されて良いことが当業者には明らかである。例えば、形状プロセッサ２２は、処理８の他の要素の動作をサポートする半導体装置のようなハードウェア構成要素として付随的に実現されて良い。さらに、図２は単一のシステムを含む機能ブロック線図として処理８を示すが、処理８は幾つかの異なるプラットフォームに渡って分散されることが可能であり、そして付随的に、その要素が様々な時間で動作し、処理８の一つの要素からの出力が後の方の時間に処理８の次の要素への入力として引き渡されることが可能であることが理解される。

上記で議論したように、それぞれのソースドキュメント１１は、入力ドキュメントをそのソースドキュメント１１のコンテンツの内部表現に翻訳することができるドキュメントエージェント１２に結び付けられる。ソースドキュメント１１を処理するのに適当なドキュメントエージェント１２を同定するために、図１のシステム１０は、アプリケーションプログラムとシステム１０の間のインタフェースを制御するアプリケーションディスパッチャ（不図示）を含む。ある実施では、外部アプリケーションプログラミングインタフェース（ＡＰＩ）の利用は、データを渡すか、適当なドキュメントエージェント１２を呼び出すか、あるいはアプリケーションプログラムによりなされた要求を実行するかするアプリケーションディスパッチャにより取り扱われる。アプリケーションディスパッチャは、特定のソースドキュメント１１のために適当なドキュメントエージェント１２を選択するために、ソースドキュメント１１を全てのロードされたドキュメントエージェント１２に知らせる。その後、これらのドキュメントエージェント１２は、知らされたソースドキュメント１１のコンテンツを翻訳するための特定の適合性に関する情報で応答する。ドキュメントエージェント１２が応答すると、アプリケーションディスパッチャは、ドキュメントエージェント１２を選択し、その選択されたドキュメントエージェント１２に、ソースドキュメント１１のＵＲＩのようなポインタを渡す。

ある実施では、コンピューター処理８は、複数のスレッドが作成され、それにより、複数のドキュメントソース１１のマルチプロセッシングをサポートすることが可能であるサービスとして実行される。別の態様では、処理８は、複数のスレッド処理をサポートせず、そしてアプリケーションディスパッチャにより選択されるドキュメントエージェント１２は、今現在のスレッドで呼び出される。

図２の例示的な態様は、異なるファイル形式の入力データストリームを処理するために、融通がきき拡張可能な前部を提供することが理解される。例えば、付随的に、もし、システムがソースドキュメント１１を翻訳するのに適合したドキュメントエージェント１２を欠いていることをアプリケーションディスパッチャが決定するなら、そのアプリケーションディスパッチャは、それぞれのアプリケーションプログラム１３にそのソースドキュメント１１が認識されない形式であることを示す信号を送ることができる。付随的に、アプリケーションプログラム１３は、そのアプリケーションプログラム１３により作成されるソースドキュメント１１を、例えば現在の形式からアプリケーションプログラム１３によりサポートされる別の形式に変換するといったことにより、ソースドキュメント１１をリフォーマットすることを可能にすることを選んで良い。例えば、アプリケーションプログラム１３は、ソースドキュメント１１がそのファイル形式の以前のバージョンのような異なる形式で保存される必要があることを決定して良い。アプリケーションプログラム１３がその形式をサポートする範囲で、そのアプリケーションプログラム１３は、システム１０により提供されるドキュメントエージェント１２がソースドキュメント１１を翻訳できるように、このサポートされる形式でソースドキュメント１１を再保存できる。付随的に、アプリケーションディスパッチャは、システム１０が適切なドキュメントエージェント１２を欠くときには、特定のタイプの新しいドキュメントエージェントが現在のソースドキュメント１１を翻訳するために必要である可能性があることをユーザーに示すことができる。このために、コンピューター処理８は、新しいドキュメントエージェントがシステム１０にロードされる必要があることをユーザーに示して良く、その新しいドキュメントエージェント１２がダウンロードできるウェブサイトのような場所にユーザーを導いて良い。付随的に、システムは、ユーザーに尋ねないでドキュメントエージェントを自動的に取り込むことができ、あるいは、例えば、テキストを表すソースドキュメント１１の部分を抜き出すことの可能なジェネリックテキストエージェントといったジェネリックエージェント（ｇｅｎｅｒｉｃ ａｇｅｎｔ）１２を同定できる。さらに、翻訳処理の間に入力及び命令をユーザーに促すエージェントが提供されても良い。

さらなる付随的な態様では、ドキュメントエージェント１２と連動するアプリケーションディスパッチャは、例えば、ファイル名の拡張子を含むファイル名から、あるいは特定のファイルタイプのコンテンツの既知の特性から、ドキュメント内で明示のファイルタイプを同定するといった、いろいろな基準のいずれか一つに基づいてソースドキュメント１１のファイル形式を同定する入力モジュールとして動作する。そのバイトストリームは、ソースドキュメント１１のファイル形式に特有のドキュメントエージェント１２への入力である。

以上の記載は、ストリーム又はコンピューターファイルにより提供されている入力データを議論したが、システム１０は、例えばデジタルカメラ又はスキャナーといった入力装置から、またその出力を処理８に直接流すことができるか、あるいはその出力をオペレーティングシステムにより処理８に流させるかするアプリケーションプログラムから受け取った入力に適用されてもよいことが当業者により理解されるべきである。この場合、入力バイトストリームは、ソースドキュメント１１からよりもむしろ、入力装置から直接もたらされて良い。しかし、入力バイトストリームは、やはりシステム１０で処理されるのに適合したデータ形式であり、本発明の目的のために、このような入力装置から受け取った入力はソースドキュメント１１とみなされて良い。

図２に示されるように、ドキュメントエージェント１２は、ドキュメント内の様々なドキュメントオブジェクトの特定のインスタンスの特性を定義するパラメーターと、一般的なタイプはライブラリ１６で定義されるようなものであるドキュメントオブジェクトの集合とでソースドキュメントのコンテンツを記述する内部表現１４を生成するために、標準オブジェクトのライブラリ１６を用いる。したがって、ライブラリ１６は、ドキュメントエージェント１２と、パーサ１８と、システム１０とが認識する一連のタイプのオブジェクトを提供する。例えば、内部表現１４で用いられるドキュメントオブジェクトは、テキストと、動画化されてもされなくても良く、あるいは２次元でも３次元でも良いビットマップグラフィックス及びベクトルグラフィックスのドキュメントオブジェクトと、ビデオと、音声と、ボタンやアイコンのような様々なタイプの対話式オブジェクトとを含んで良い。ベクトルグラフィクスのドキュメントオブジェクトは、特定の塗り潰し及び透明性を有する、ポストスクリプトのようなパスであって良い。ビットマップグラフィックスのドキュメントオブジェクトは、例えばＪＰＥＧ、ＧＩＦ、及びＰＮＧのオブジェクトタイプといった一連のサブオブジェクトタイプを含んで良い。テキストのドキュメントオブジェクトは、スタイルの決められたテキストの範囲を宣言して良い。この範囲は、テキストのパラグラフを含んで良く、典型的には、１対のキャリッジリターンのような、２つの区切りの間にみられる一連の文字として理解される。それぞれのテキストオブジェクトは、一群の文字と、一つ以上結び付けられた書体、ポイント、及び他のそのようなスタイル情報を含むその文字群のためのスタイル情報とを含んで良い。

通常、ドキュメントオブジェクトの特定のインスタンスを決めるパラメーターは、ドキュメントオブジェクトの物理的形状、サイズ、及び位置を決める次元座標と、特性が時間で変化するドキュメントオブジェクトを規定するためのいずれか関連した時間的データとを含み、これにより、このシステムが動的ドキュメント構造及び／又は表示機能を扱うことを可能にする。例えば、ビデオ入力のストリームは、例えば、一秒あたり３０フレームの速度で変化している一連の画像としてシステム１０により処理されて良い。この場合には、この画像オブジェクトの時間的特性は一秒あたり３０回更新されるべきであることを指す。以上で議論したように、パラメーターは、テキストオブジェクトのために、通常、文字列に適用されるべきフォント及びサイズも含む。オブジェクトのパラメーターは、透明性のような他の特性を規定しても良い。内部表現は、そのシステムに固有のファイル形式で保存／格納されて良く、そしてシステム１０へ入力可能なソースドキュメント１１の範囲は、システム固有のファイル形式でのドキュメントを含んで良いことが理解される。内部表現１４は、必要であれば、適当な変換エージェントを用いて、いずれか他の範囲のファイル形式に変換することもできる。

図３は、ドキュメントエージェント１２により行われるある例示的な処理のフローチャート図を描く。特に、図３は、ドキュメントエージェント１２の一例の、この場合は、マイクロソフト ワードのドキュメントのコンテンツを内部表現の形式に翻訳するのに適したドキュメントエージェント１２の動作を表す処理５０を描く。特に、処理５０は、その処理５０がデータ構造と、メモリスペースと、その処理５０がソースドキュメント１１を翻訳している間に用いる他のリソースとを初期化する初期化ステップ５２を含む。ステップ５２の後に、処理５０は、ソースドキュメント１１が解析されそしてサブセクションに分けられる一連のステップ５４、５８、６０に進む。図３に描かれる処理５０では、ステップ５４、５８、６０は、ソースドキュメント１１を、それがドキュメントエージェント１２に流されると最初にセクションに細分し、それからこのセクションをパラグラフに細分し、その後、このパラグラフを、パラグラフを構成する個々の文字に細分する。ソースドキュメント１１内で同定されるセクション、パラグラフ、及び文字は、ソースドキュメント１１内で同定される異なるサブセクションに対するある種のポインタを含むピーステーブル（ｐｉｅｃｅ ｔａｂｌｅ）内で同定されて良い。図３に描かれるピーステーブルは、ドキュメントの異なるサブセクションにポインタを提供するための、ＭＳワードにより用いられる構成体を表すことが当業者により理解される。さらに、ピーステーブル又はピーステーブルのような構成体の使用は、付随的であり、そして即時にアプリケーションに依存し、処理されるドキュメントのタイプに依存することを含むことが理解される。

ステップ６０で処理５０が、特定のパラグラフ内で見られる異なる文字を同定し始めたら、この処理６０は、ステップ６０で同定された文字又は文字のセットにスタイルが適用されるステップ６２に進んで良い。スタイルの適用は、同定された文字を、これらの文字とともに用いられるスタイル表示と結び付けることと理解される。スタイル表示は、フォントタイプと、フォントサイズと、文字がボールドか、イタリックか、あるいは他のスタイルのものかといったこととを含む文字と結び付けられた特性を含んで良い。加えて、ステップ６２では、処理は、文字が回転するかどうか、あるいは曲線状のパス又は他の形状に従うために配置されるかどうかを決定できる。加えて、ステップ６２では、文字が生じるパラグラフと結び付けられたスタイルが、同定され、そしてその文字と結び付けられても良い。このような特性は、パラグラフと結び付けられた行間隔と、パラグラフと結び付けられたマージンと、文字の間の間隔と、他のそのような特性とを含むことができる。

ステップ６２の後で、処理５０は、内部表現が形成されるステップ７０に進む。ドキュメントの構造を記述するオブジェクトは、内部表現内のオブジェクトとしてステップ６４で作成され、そしてこのオブジェクトの結び付けられたスタイルが、オブジェクトが含む文字群とともに、ステップ６８で内部表現内に別々に作成される。以下により詳細に説明される図６、７、８は、ドキュメントの構造が一群のドキュメントオブジェクトにより捕捉され、そしてこのドキュメントオブジェクトと結び付けられたデータが別のデータ構造に格納されることを特徴とする、処理５０により作成されるファイル構造を図形的に描く。ステップ７０の後に、処理５０は、最後に処理された文字と結び付けられたパラグラフが完全かどうかを処理５０が決定する決定ブロック７２に進む。パラグラフが完全でないなら、処理５０は、パラグラフからの次の文字が読込まれるステップ６０に戻る。代わりに、パラグラフが完全であるなら、処理５０は、セクションが完全かどうかを処理５０が決める決定ブロック７４に進む。セクションが完全であるなら、処理は、ステップ５８に戻り、次のパラグラフがピーステーブルから読み込まれる。代わりに、セクションが完全であるなら、次のセクションがあれば、次のセクションがピーステーブルから読み込まれるステップ５４に進み、処理が続く。ドキュメントが処理されると、システム８は、次の利用のために、翻訳したドキュメントを送るか、保存するか、エクスポートするか、さもなくば格納することができる。このシステムは、翻訳したファイルを内部表現と互換性のある形式で格納でき、そして付随的に、（内部表現データを受け取ることができ、そしてソースドキュメントデータを作成できる不図示の「エクスポートドキュメントエージェント」を用いることが可能である）ソースドキュメント１１のファイル形式と互換性のある形式を同様に含む他の形式で、あるいは２進形か、テキストドキュメントの記述構造か、マークアップテキストか、いずれか他の適当な形式かで格納でき、それからユニコードと、シフトマッピング（Ｓｈｉｆｔｍａｐｐｉｎｇ）と、ビッグ５（ｂｉｇ−５）と、ルミナンス／クロミナンスモデルとを含むユニバーサルテキスト（ｕｎｉｖｅｒｓａｌ ｔｅｘｔ）のコード化モデルを用いて良い。

以上から見られるように、内部表現１４の形式は、オブジェクトのタイプ及びそのパラメーターにより記述されるようなドキュメントの「構造」（あるいは「レイアウト」）を、様々なオブジェクトの「コンテンツ」から切り離し、例えば、テキストオブジェクトの文字列（コンテンツ）が、オブジェクトの次元のパラメーターから切り離され、グラフィックオブジェクトの画像データ（コンテンツ）が、その次元のパラメーターから切り離される。これは、ドキュメント構造が圧縮手段で規定されるのを可能にし、そして遠隔で格納されるために、また必要な時にのみシステムにより取り出されるためにコンテンツデータのためのオプションを提供する。内部表現１４は、「高レベルの」記述で、ドキュメント及びその構成オブジェクトを記述する。

図３を参照して以上に記載されたドキュメントエージェント１２は、ＭＳワードのワードプロセッシングアプリケーションにより作成されるデータファイルを処理することができ、そのデータファイルを、ライブラリ１６から選択されるオブジェクトタイプのセットから形成される内部表現に翻訳することができ、そしてそれは処理されたドキュメントのコンテンツを表す。したがって、ドキュメントエージェント１２は、ワードのドキュメントを解析し、そのドキュメントの構造及びコンテンツを、コンピューター処理８にわかる内部表現に翻訳する。ドキュメントエージェント１２により処理され得るタイプのワードドキュメントの一例が、図４に描かれる。特に、図４は、ＭＳワードのアプリケーションプログラムにより作成されるタイプのワードドキュメント３２を描く。描かれたドキュメント３２は、一ページがテキストの二つの欄３４と一つの図３６を含む一ページの情報を含む。図４は、さらに、テキストの一つの欄がページ３８の上端からページ３８の下端まで走り、そしてテキストの第二の欄がページのおよそ中央からページの下端まで走り、また図３６がテキスト３４の第二の欄の上に配置されるようにテキストの欄３４及び図３６がページ３８に配置される。

図３を参照して以上で議論したように、ドキュメントエージェント１２は、ドキュメント３２が一つのページを含み、複数の異なるオブジェクトを含むことを決定することによりドキュメント３２を処理し始める。ドキュメントエージェント１２により見出された一つのページのために、ドキュメントエージェント１２は、そのページのスタイルを同定し、そして例えばそれは肖像画書式で８．５×１１のページのページスタイルになる。ドキュメントエージェント１２により同定されたページスタイルは、テキストを処理８により作成されるドキュメントにフォーマットし流す際に、パーサ１８による後の利用のために内部表現で表される。

図４に描かれるドキュメント３２のためには、一ページがあるのみである。しかし、ドキュメント１２は複数のページを含むワードドキュメントを処理して良いことが理解される。このような場合には、ドキュメントエージェント１２は、一つのページを作成しその後それをライブラリで見出されたタイプのオブジェクトで満たすことにより、それぞれのページを別々に処理する。このように、ページスタイル情報は、ドキュメントが複数のページを含むこと、及びそのページが所定サイズであることを含むことができる。他のページスタイル情報がドキュメントエージェント１２により同定されて良く、そしてその同定されたページスタイル情報はアプリケーションにより変わり得る。したがって、異なるページスタイル情報が、マイクロソフト エクセル（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ）のドキュメント又はリアルメディアのデータストリームを処理することのできるドキュメントエージェントにより同定されて良い。

図４を参照してさらに記載されるように、ドキュメントエージェント１２がページスタイルを同定したら、ドキュメントエージェント１２は、ドキュメント３２を、システムに認識されるドキュメントオブジェクトにマッピングでき、そして典型的にはライブラリ１６に格納できるオブジェクトに分解され始めて良い。例えば、ドキュメントエージェント１２は、テキストオブジェクト、ビットマップオブジェクト、及びベクトルグラフィックオブジェクトを見出すべくドキュメント３２を処理する。他のタイプのオブジェクトタイプは、付随的に、ビデオタイプ、動画タイプ、ボタンタイプ、及びスクリプトタイプを含んで提供されてよい。この実施では、ドキュメントエージェント１２は、結び付けられたスタイルが２つの欄を有するテキストオブジェクト３４を同定する。テキストオブジェクト３４内で生じるテキストのパラグラフは、それぞれ別のパラグラフでそれぞれの文字を同定するために解析されて良い。処理５０は、スタイル特性をそれぞれの同定された文字群に適用して良く、そしてドキュメント３２内で同定されたそれぞれの文字群は、ライブラリ１６内にリストされるタイプのテキストオブジェクトにマッピングされて良い。それぞれの文字群及び適用されたスタイルが、ドキュメント３２内で見出だされた、そしてドキュメントオブジェクトに、この場合はライブラリ１６内にリストされるタイプのテキストオブジェクトに翻訳されたようなドキュメントエージェント１２により同定されるオブジェクトとして理解されることができる。この内部表現オブジェクトは、ドキュメントエージェント１２から内部表現１４に流されて良い。ドキュメントエージェント１２は、ドキュメント３２内で見られるオブジェクトを、それぞれのオブジェクトが翻訳されるまで、システム１０に認識されるドキュメントオブジェクトに翻訳し続ける。そのオブジェクトタイプは、アプリケーションにとって適当なものであり、そしてデジタルドキュメントと、音声／映像表示と、音楽ファイルと、対話式スクリプトと、ユーザーインターフェースファイルと、画像ファイルと、さらにいずれか他のタイプのファイルとを表すソースデータを翻訳するのに適しているオブジェクトタイプを含んで良い。

図５を参照すると、図５に描かれる処理８０は、内部表現のサイズを減じるために、ソースドキュメント１１の内部表現内に現れる類似のオブジェクトを圧縮することを可能とすることが見られる。例えば図５は、ステップ８２が、処理される基本のライブラリオブジェクトＡを有し、ステップ８４において、その基本のオブジェクトを、ソースドキュメント１１の内部表現になるドキュメントに挿入する処理８０を描く。ステップ８８ではドキュメントエージェント１２により提供される別のオブジェクトＢが、内部表現ファイル処理１４に引き渡される。その後、この処理８０は、オブジェクトＡの特性がオブジェクトＢの特性と比較されて、その２つのオブジェクトが同じ特性かどうかを決める描かれた一連のステップ９２から９８を行う。例えば、オブジェクトＡ及びオブジェクトＢが、文字Ｐと文字Ｎのように２つの特性を表す場合に、もし、両方の特性Ｐ及びＮが同じ色で、同じフォントで、同じサイズで、そしてボールド体又はイタリック体のように同じスタイルであるなら、ステップ９４で処理８０は、２つのオブジェクトを内部表現内に格納される一つのオブジェクト分類内で結合させる。もし、これらの特性が一致しないなら、処理８０はそれらを２つの別のオブジェクトとして内部表現に加える。

図５は、内部表現ファイル１４が物理的に近いオブジェクトの類似のファンクションとしてオブジェクトを圧縮する処理８０を描く。当業者は、これが単にオブジェクトを圧縮するための処理の一つであり、他の技術が用いられて良いことを理解する。例えば、付随的な実施では、圧縮処理は視覚的に近いオブジェクトを圧縮するための処理を含んで良い。

図６、７、及び８は、図１及び２に描かれるシステムにより処理されたドキュメントの内部表現の構造を描く。ドキュメントの内部表現はコンピューターファイルとして、あるいはコアメモリに格納されたデータとして表されて良い。しかし、当業者には、内部表現を捕捉しあるいは移送するために選択されるデータ構造がアプリケーションにより変わり、そしていずれか適当なデータ構造がここに記載されたシステム及び方法とともに本発明の範囲から外れないで用いられてよいことが明らかである。

以下により詳細に記載されるように、処理されたドキュメントの内部表現の構造は、そのドキュメントの構造をドキュメントのコンテンツから切り離す。特に、ドキュメントの構造は、これらのドキュメントオブジェクトが互いに関連して配列される方法と同様に、ドキュメントを構成する異なるドキュメントオブジェクトを示すデータ構造により捕捉される。このコンテンツからの構造の分離は図６に示され、そこではデータ構造１１０が、処理されているドキュメントの構造を捕捉し、そしてその構造を、そのドキュメントと結び付けられた実際のコンテンツから独立したデータ形式で格納する。特に、データ構造１１０は、リソーステーブル（ｒｅｓｏｕｒｃｅ ｔａｂｌｅ）１１２とドキュメント構造１１４を含む。リソーステーブル１１２は、ドキュメントの内部表現を構築するためのリソースのリストを提供する。例えば、リソーステーブル１１２は、ドキュメント内で生じる、書体、リンク、及び色のリストのような共通の構造の一つ以上のテーブルを含むことができる。これらの共通の構造は、リソーステーブル１１２内で数値で参照されて良い。リソーステーブル１１２のリソースは、ドキュメント構造１１４内に配置されるドキュメントオブジェクトに関係する。図６が示すように、ドキュメント構造１１４は、ネストされたカッコのセットにより表された複数のコンテナ１１８を含む。複数のドキュメントオブジェクト１２０はコンテナ１１８内にある。図６に示されるように、コンテナ１１８は、処理されているドキュメント内に見られるドキュメントオブジェクトの集合を表す。図６によりさらに示されるように、コンテナ１１８はサブコンテナをもつこともできる。例えば、ドキュメント構造１１４は、符号１の外側カッコのセットで同定される一つのトップレベルのコンテナを含み、３つのネストされたコンテナ２、３、４を有する。加えて、コンテナ４は、コンテナ１とコンテナ３内に２重にネストされる。

それぞれのコンテナ１１８はドキュメント内の特徴を表し、そしてその特徴は、描かれたドキュメントオブジェクト１２０のように個々のドキュメントオブジェクトの集合であって良い。したがって、例えば、図４に描かれたドキュメント３２のようなドキュメントは、文字群を表すコンテナを含んで良く、そしてその文字群は欄３４内に見られるテキストを含む。文字群内で生じる異なるドキュメントオブジェクト１２０は、例えば、その文字群内で生じる異なるパラグラフを表して良い。この文字群のコンテナは、それと結び付けられたスタイルを有する。例えば、図４に描かれる文字群は、その文字群あるいはその文字群の少なくとも一部が生じる、文字のフォントタイプと、フォントサイズと、例えばボールド又はイタリックスタイルといったスタイルと、幅及び長さを含む欄のサイズを表すスタイル情報とを含むことができる。このスタイル情報は、コンテキストの特定ビュー２０内に、テキストをリフォーマットし、そして再び流すために、後でパーサ１８で用いられる。別の例のコンテナは、例えば、ドキュメント３２のテキストの欄３４内に見られるテーブルであって良い。このテーブルは、オブジェクトを有するコンテナであって良い。コンテナの他のタイプ及び利用はアプリケーションによりすぐに変わり、そして本発明のシステム及び方法は、いずれかの特定のセットのオブジェクトタイプ又はコンテナに制限されない。

したがって、ドキュメントエージェント１２がソースドキュメント１１を翻訳すると、それは、既知のオブジェクトタイプのものであるオブジェクトに出会い、そしてドキュメントエージェント１６は、適当なオブジェクトタイプのオブジェクトを作成することをライブラリ１６に要求する。このドキュメントエージェント１２は、その作成されたドキュメントオブジェクトをドキュメント構造１１４内の適当な位置に入れて、ソースドキュメント１１の全体構造を保存する。例えば、ドキュメントエージェント１２がソースドキュメント１１内の画像３６に出会うと、ドキュメントエージェント１２は、例えばＪＰＥＧ画像のような画像３６を、ビットマップのタイプの、あるいは付随的にＪＰＥＧのサブタイプのオブジェクトとして認識する。図３のステップ６４及びステップ６８に示されるように、このドキュメントエージェント１２は、適当なドキュメントオブジェクト１２０を作成でき、そしてこの作成したドキュメントオブジェクト１２０を構造１１４に入れることができる。加えて、ＪＰＥＧ画像のドキュメントオブジェクト１２０のためのデータは、あるいは他の例では、文字と、文字群のためのそれらの結び付けられたスタイルとのためのデータは、図８に描かれるデータ構造１５０内に格納されて良い。

ソースドキュメント１１が処理されている時に、ドキュメントエージェント１２は、文字群のような既存のコンテナ内で見られる下位の特徴を表す他のコンテナを同定してよい。例えば、これらの下位の特徴は、参照される材料へのリンクか、あるいは、ドキュメント内で見られ、そして個別のドキュメントオブジェクト１２０の集合を含む、クリップされた映像の範囲又は特徴かを含んで良い。ドキュメントエージェント１２は、これらのドキュメントオブジェクト１２０を、既存のコンテナ内にネストされた別のコンテナ内に置くことができる。これらのドキュメントオブジェクト１２０とコンテナ１１８の配列は、それぞれのコンテナ１、２、３、４がコンテナオブジェクト１３２、１３４、１３８、１４０としてそれぞれ示されるツリー構造１３０として、図７（Ａ）に示される。コンテナ１１８及びドキュメントオブジェクト１２０は、ドキュメント構造１１４と、コンテナ１１８内で生じるいろいろなドキュメントオブジェクト１２０とのネストされたコンテナ構造を示すツリー構造で配列される。図７（Ａ）のツリー構造は、ドキュメントオブジェクト１２０の階層としてソースドキュメントを示すソースドキュメント１１の構造を構造１１４が記録し保存することを説明し、そしてそのドキュメントオブジェクト１２０は、例えば文字群が見られる欄のサイズといったスタイル情報、あるいは、例えば、ストリームされるコンテンツのためのフレーム速度といった時間的情報を含む。従って、それぞれのドキュメントのグラフィック構造が一連のパラメーター要素により記述される。この一例が、以下に表１に表される。

示されるように、表１はドキュメントのグラフィック構造を記述するのに用いられるパラメーターの例を表す。表１は、例えば、この場合ではビットマップのオブジェクトタイプであるオブジェクトタイプといった、パラメーターの例である。バウンディングボックスのパラメーターが提供され、ソースドキュメント１１内のドキュメントオブジェクトの位置を与える。さらに、表１は、用いられる塗り潰し、及びオブジェクトの透明性の程度を表すアルファ要素を提供する。形状のパラメーターは、オブジェクトの形状にハンドルを与え、そしてそれは、この場合、不規則な形状のオブジェクトを含むオブジェクトのアウトラインを決めるパスになることができる。表１は、オブジェクトの時間的変化を表す時間パラメーターも表す。この例では、画像は固定しており、時間とともに変化しない。しかし、もし、画像オブジェクトがストリームされたメディアを表すなら、このパラメーターは、例えば、そのコンテンツのための所望のフレーム速度に相当する速度といった、オブジェクトが変化する速度を示す時間的特性を含むことができる。

したがって、この構造の要素は、流すことの可能なデータコンテンツを有するコンテナであって、この流すことの可能なデータは、分離して保持され、このコンテナからハンドルにより参照される。このように、いずれか又は全てのデータコンテンツがドキュメント構造から分離して保持される。これは、構内保持及び遠隔保持したデータコンテンツを混ぜてなされる手段でドキュメントをレンダリングすることを可能にする。加えて、このデータは、より広くより高いレベルのオブジェクトが最初に表示され、それからより細かい特徴が順次表示されることができるように、ソースドキュメント１１の内部表現を速い進み方でレンダリングすることを可能にする。このように、別個の構造及びデータは、コンテンツを「満たす」ためにデータを流しながら映像ドキュメントを表示することを可能にする。加えて、別個のコンテンツ及び構造は、ドキュメントのコンテンツが素早く編集され、変更されることを可能にする。ドキュメント構造はコンテンツから独立しているので、異なるコンテンツがそのドキュメント構造に置き換えられることができる。これは、コンテナごとに、あるいは全ドキュメントのために、コンテナで行われる。ドキュメントのこの構造は、そのコンテンツと後に提供されるコンテンツとから別々に引き渡されるか、あるいはその構造が引き渡されるプラットフォームに存在させられる。

加えて、図７（Ａ）は、ソースドキュメント１１の構造がツリー構造１３０として表されることができることを示す。ある実施では、このツリー構造は、ソースドキュメント１１の表示を変えるべく改変され、また編集されて良い。例えば、このツリー構造は、ツリー１３０に追加の構造及びコンテンツを付加すべく改変されて良い。これは、複製されそしてより高いレベルのコンテナの下に与えられた図７（Ａ）の元のツリー構造を示す図７（Ｂ）に描かれる。それ故に、図７（Ｂ）は、新しいドキュメント構造が、したがって新しい表現が、ドキュメントエージェント１２により作成されるツリー構造１３０を処理することにより作成されることを示す。これは、異なるオブジェクト１２０の相対的位置は同じままであるが、ドキュメント内でオブジェクトの視覚的位置が変わることを可能にする。ツリー構造１３０を調整することにより、ここに記載されるシステムはコンテンツを編集し、改変することができる。例えば、これらのアプリケーションでは、ツリー構造１３０内のコンテンツが、視覚のコンテンツを表す場合に、ここに記載されるシステムは、ツリー構造を編集してドキュメントの映像を複製し、そしてそのドキュメントの映像を並んで表示することができる。代わりに、このツリー構造１３０は、例えば、新しいドキュメント又はそのドキュメントの一部の映像を付加することにより、追加の視覚情報を付加すべく編集され、また補足されることができる。さらに、ツリー構造が変えられる速度を制御することにより、ここに記載されるシステムは、ドキュメントが、表示装置２６のようなディスプレイを横切って滑るようにゆっくりと変化していくか、あるいは新しいドキュメントにゆっくりと変わっていく錯覚を生み出すことができる。サムネイルビューの作成といった効果及び他の同様な結果が得られ、そしてここに記載されるシステム及び方法に対する改変をすることによる通常の技術のもの、及びこのように改変されたシステム及び方法が本発明の範囲内に入る。

ソースドキュメント１１のデータは、構造１１４から分離して格納される。このために、それぞれのドキュメントオブジェクト１２０は、そのオブジェクトと結び付いたデータに対するポインタを含み、この情報は、図８に描かれる間接リスト１６０のような間接リスト内に配列されて良い。この実施では、図８に示されるように、それぞれのドキュメントオブジェクト１２０が番号をふられ、そしてそれぞれのオブジェクトドキュメント番号１５４がオフセット値１５８と結び付けられる間接リスト１５２が作成される。例えば、参照番号１６０で同定されるドキュメントオブジェクトの１番は、参照番号１６２で同定されるオフセット７００と結び付けられることができる。したがって、間接リストは、オフセット７００とオブジェクトの１番を結び付ける。オフセット７００は、オブジェクト１と結び付けられたデータが存在するコアメモリでの位置又はファイルのオフセットを表すことができる。図８でさらに示されるように、データ構造１５０は、それぞれのドキュメントオブジェクト１２０と結び付けられたコンテンツを表すデータが格納される場所に存在して良い。したがって、例えば、ジャンプ位置７００の描かれたオブジェクト１は、図６に描かれたコンテナの文字群内で生じる文字を表すユニコードの文字を含んで良い。同様に、参照番号１７２で図８に描かれ、また参照番号１７０により同定されるコアメモリの位置８１０で結び付けられたオブジェクト２のデータは、図６のドキュメント構造１１４内で参照されるビットマップのドキュメントオブジェクト１２０と結び付けられたＪＰＥＧビットマップを表して良い。

データが構造から切り離されると、ソースドキュメントのコンテンツは一元化されたレポジトリに保持されることが当業者により注目される。したがって、ここに記載されるシステムは、様々なタイプのデータオブジェクトにわたって圧縮することを可能にする。このような処理は、制限されたリソースシステムの中で、より多く格納する柔軟性を提供する。

図２を参照すると、内部表現ファイルのコンテンツを圧縮するための処理が、様々なオブジェクトを圧縮し終えると、これらのオブジェクトはパーサ１８に渡されることが理解される。パーサ１８は、内部表現の構造セクションで同定されたオブジェクトを解析し、そしてこのオブジェクトと結び付けられたデータのコンテンツを参照して、それは、それぞれのオブジェクトに位置及びスタイル情報を再び適用する。レンダラー（ｒｅｎｄｅｒｅｒ）１９は、内部表現１４により表されるドキュメントのコンテキスト特有の表現又は「ビュー」２０を生成する。要求されるビューは、複数のドキュメントの全部、一つのドキュメントの全部、あるいは一つ又は複数のドキュメントの部分になって良い。レンダラー１９は、生成されるべき特定のドキュメントビューの表示コンテキストと、いずれか関連する時間的パラメーターとを規定するビュー制御入力４０を受け取る。例えば、システム１０は、ドキュメントの一部をズームしたビューを生成し、それからそのズームしたビューをドキュメントの隣接した部分を表示するためにパン又はスクロールすることを要求されて良い。このビュー制御入力４０は、レンダラー１９により解釈されて、内部表現のどの部分が特定のビューを要求されるのか、そしてどのように、いつ、どのくらいビューが表示されるべきなのかを決める。

コンテキスト特有の表現／ビュー２０は、基本の形状及びパラメーターで表される。

レンダラー１９は、ソースドキュメント１１の要求されたビュー２０を生成する時に、内部表現１４の関連部分に追加の前処理機能を果たしても良い。このビュー表現２０は、表示装置又はプリンタのような出力装置２６を動作するのに適した形式での出力を生成すべく処理するための形状プロセッサ２２への入力である。

レンダラー１９の前処理機能は、色補正、解像度の調整／向上、ならびにエイリアス除去を含むことができる。解像度の向上は、目標の出力装置により表示又は再生される時の、オブジェクトのコンテンツの読みやすさを保つスケーリング機能を含んで良い。解像度の調整は、コンテキスト依存であって、例えば、特定のオブジェクトの表示解像度は、表示ドキュメントのビューがパン又はスクロールされる間は減じられ、またドキュメントビューが静的である時は上げられて良い。

付随的に、例えば、内部表現により表されるソースドキュメント１１がマルチフレームの動画を含むような場合に、内部表現１４のコンテンツの更新をトリガする目的で、パーサ１８と内部表現１４の間にフィードバック経路４２があって良い。

レンダラー１９からの出力は基本のオブジェクトでドキュメントを表す。それぞれのドキュメントオブジェクトのために、レンダラー１９からの表現は、少なくとも、物理的に長方形のバウンディングボックスと、そのバウンディングボックスにより境界をつけられたオブジェクトの実際のアウトラインパスと、オブジェクトのデータコンテンツと、透明性とでオブジェクトを規定する。

形状プロセッサ２２は基本のオブジェクトを解釈し、それを、例えば、プリンタのためにドットマップ、プロッタのためにベクトル命令のセット、あるいは表示装置のためにビットマップといった、目標の出力装置２６に適切な出力のフレーム形式に変換する。形状プロセッサ２２への出力制御の入力４４は、特定の出力装置２６にとって適切な出力を生成すべく形状プロセッサ２２に情報を提供する。

形状プロセッサ２２は、「形状」（すなわち、オブジェクトのアウトラインの形）、「塗り潰し」（オブジェクトのデータコンテンツ）、及び「アルファ」（オブジェクトの透明性）でビュー表示２０により規定されるオブジェクトを完全に処理し、そして指定のビュー及び出力装置に適切なスケーリング及びクリッピングを行い、出力装置に適切なもので（典型的には、ほぼ全タイプの表示装置又はプリンタのために、走査変換等によりピクセルで）オブジェクトを表す。付随的に、形状プロセッサ２２は、走査変換したピクセルでオブジェクトの形状を決めるエッジバッファ（ｅｄｇｅ ｂｕｆｆｅｒ）を含み、好ましくは、アウトライン形状にエイリアス除去を適用する。エイリアス除去は、出力装置２６の特性により決められる手段で、オブジェクトの境界を横切るグレースケールランプを適用することにより行われる。このアプローチは、形状クリッピング処理及び形状交差処理に有効なメモリを可能とし、有効なメモリであると同時に有効なプロセッサである。ルックアップテーブル、あるいは他の技術が、多重トーン応答曲線を決めるのに用いられ、非線形のレンダリング制御を可能とする。形状プロセッサ２２により処理される個々の基本のオブジェクトが、合成出力フレームで結合される。ここに記載されたシステムとともに用いるのに適した一つの形状プロセッサの設計が、これと同日に出願され、形状プロセッサの名称を与えられた出願により詳細に示され、その内容が参照のために組み入れられる。しかし、いずれか適当な形状プロセッサのシステム又は処理が本発明の範囲から外れないで用いられて良い。

以上に記載したように、図１に描かれる処理８は、ハンドヘルドコンピューターか、携帯電話か、セットトップボックスか、ファクシミリ機、コピー機又は他の事務機器か、埋め込み型コンピューターシステムか、ウィンドウズ（登録商標）又はユニックスワークステーションか、あるいは、以上に記載したドキュメント処理システムを全部又は一部をサポート可能ないずれか他のタイプのコンピューター／プロセッシングプラットフォームかのようなデータ処理システムで動作するソフトウェア構成要素として実現できる。これらの態様では、システムは、Ｃ言語のコンピュータープログラム、又はＣ＋＋、フォートラン（Ｆｏｒｔｒａｎ）、ジャバ（Ｊａｖａ）（登録商標）、あるいはベイシック（Ｂａｓｉｃ）を含む高レベルの言語で記述されたコンピュータープログラムとして実行できる。加えて、マイクロコントローラあるいはＤＳＰが用いられる態様では、システムは、マイクロコードで記述されるか、あるいは高レベル言語で記述され、そして用いられるプラットフォームで実行できるマイクロコードにコンパイルされるコンピュータープログラムとして実現できる。このようなシステムの開発は、当業者に知られており、そして、このような技術は、インテル（Ｉｎｔｅｌ）（登録商標） ストロングアームプロセッサ（ＳｔｒｏｎｇＡＲＭ Ｐｒｏｃｅｓｓｏｒ） ＳＡ−１１１０ マイクロプロセッサ 上級デベロッパマニュアルに示される。加えて、高レベルのプログラミングのための通常の技術が知られおり、例えば、Ｓｔｅｐｈｅｎ Ｇ． Ｋｏｃｈａｎ， Ｐｒｏｇｒａｍｍｉｎｇ ｉｎ Ｃ， Ｈａｙｄｅｎ Ｐｕｂｌｉｓｈｉｎｇ（１９８３）に示される。特に、ＤＳＰは、例えば、コントラスト、エッジ解像力、及び輝度の調整による画像強調といった処理機能を含む信号処理機能を実行するのに適していることが注目される。ＤＳＰ及びマイクロコントローラシステムためにコードを開発することは、従来技術でよく知られた原理からできる。

したがって、図１及び２は、複数の機能ブロック要素を含むようにコンピューター処理８を図形的に描くが、これらの要素は、データ処理プラットフォーム上で実行して、それにより本発明によるシステムのようにデータ処理プラットフォームを構成できるコンピュータープログラグ又はコンピュータープログラムの部分として実現できることが当業者には明らかである。さらに、図１は、ドキュメント処理プロセス８と表示装置２６を統合した単位としてシステム１０を描くが、これは単なる一つの態様であり、ここに記載されるシステムは、処理８のドキュメント処理機能を、ディスプレイ２６により行われるドキュメントの表示動作から切り離すシステムアーキテクチャを含む他のアーキテクチャ及び配列により実現できることが当業者には明らかである。さらに、本発明のシステムは、表示又は出力装置を含むこれらのシステムに制限されないが、本発明のシステムは、一つ以上のデジタルドキュメントを処理して出力装置に表示される出力を作成するこれらの処理システムを含むことが理解される。しかし、その出力は、表示装置での次の表示のためか、長期間の保管のためか、ネットワークでの配信のためか、あるいは即時の表示以外の他の目的のためにデータファイルに格納されて良い。したがって、ここに記載されるシステム及び方法は、多くの異なるドキュメント及びコンテンツ処理アプリケーションをサポートでき、特定のアプリケーションのために用いられるシステム又はプロセスの構造は、アプリケーション及びデザイナーの選択により変わることが当業者には明らかである。

前記のものから、本発明のシステムは、例えば、ロム（ＲＯＭ）で実行され、及び／又はエイシック（ＡＩＳＩＣ）又は他のシングルチップシステムに集積されるといった「ハードワイヤード」になって良く、あるいは、ファームウェア（フラッシュ性イーピーロム（ｅＰＲＯＭ）のようなプログラム可能ＲＯＭ）として、又は、構内又は遠隔で格納され、特定の装置により要求されると取り出され、そして実行されるソフトウェアとして実行されて良いことが理解される。このような改良及び改変が、本発明の範囲から外れないで組み込まれて良い。

当業者は、ただの機械的作業の実験、この態様と同等な多くのもの、及びここに記載された実施を利用して、知り、あるいは突きとめることができる。例えば、ここに記載されるシステム及び方法は、ソースドキュメント１１を処理するためのシステムを独立型にして良いが、付随的に、これらのシステムは、多くの異なる方法で、様々なタイプのデータ処理システム及び装置に、また周辺装置に組み込まれて良い。通常の目的のデータ処理システム（「ホストシステム」）では、本発明のシステムは、オペレーティングシステム及びホストシステムのアプリケーションといっしょに組み込まれて良く、あるいは全体的又は部分的にホストオペレーティングシステムに組み込まれて良い。例えば、ここに記載されるシステムは、ブラウザ又はアプリケーションプログラムの利用を必要としないで、ＬＣＤディスプレイを有する携帯用データ処理装置の様々なタイプのデータファイルの即時の表示を可能にする。本システムを用いて良い携帯用データ処理装置の例には、「パルムトップ」コンピューター、携帯用デジタル補助装置（ＰＤＡ、主要なユーザーインターフェースが、スタイラス装置により直接ユーザーが対話するグラフィック表示を含むタブレットタイプのＰＤＡを含む）、インターネット可能な携帯電話、及び他の通信装置が含まれる。この種のデータ処理装置は、携帯性のために小型で、低電力のプロセッサを必要とする。典型的には、これらの装置は、エレクトロニクスパッケージが小さく集積されるように、エイシック（ＡＳＩＣ）（特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｕｉｒｃｉｔ））に設計された新型のＲＩＳＣタイプのコアプロセッサを用いる。また、このタイプの装置は、制限のあるランダムアクセスメモリを有し、典型的には、非揮発性データ記憶装置（例えば、ハードディスク）を有しない。標準のデスクトップ計算機システム（ＰＣ）に用いられるような従来のオペレーティングシステムモデルは、デジタルドキュメントを処理しまた有用な出力を生成するのに高出力の中央演算処理装置と大量のメモリを必要とし、このタイプのデータ処理装置には全く相応しくない。特に、従来のシステムは、統合された手段で、複数のファイル形式の処理を提供しない。反対に、ここに記載されるシステムは、全てのファイル形式のために共通の処理及びパイプラインを用いて、これにより、消費電力量及びシステムのリソースの用法に関して優れた効果がある高集積のドキュメント処理システムを提供する。

本発明のシステムは、従来のシステムモデルより少ないオーバーヘッドでのドキュメント処理及び出力を可能にするために携帯用データ処理装置のバイオス（ＢＩＯＳ）レベルで集積されて良い。代わりに、これらのシステムは、トランスポートプロトコルスタックのすぐ上の最も低いシステムレベルで実行されて良い。例えば、このシステムは、（例えば、ＴＣＰ／ＩＰシステムのパケットレベルで作業する）ネットワークトラフィックのインライン処理を提供するために、ネットワークデバイス（カード）又はシステムに組み込まれて良い。

ここでのシステムは、所定セットのデータファイル形式と、例えば、装置の映像表示部及び／又は少なくとも一つのタイプのプリンタといった所定の出力装置とで動作すべく構成されることができる。

ここに記載されるシステムは、例えば拡張された電話及び「シン」ネットワーククライアント端末（例えば、制限のある構内処理及び格納リソースのネットワーク端末）といった低費用のデータ処理端末と、対話式／インターネット可能ケーブルＴＶシステムでの利用のための「セットトップボックス」とに組み込まれても良い。そのシステムは、例えば、ハードコピー装置（プリンタ及びプロッタ）と、表示装置（例えば、デジタルプロジェクタ）と、ネットワーキング装置と、入力装置（カメラ、スキャナ等）と、また多機能周辺装置（ＭＦＰ）といったような周辺装置に組み込まれても良い。システムは、プリンタに組み込まれると、そのプリンタが、ホストシステムにより提供される特定のアプリケーション又はドライバを必要とせずに、生データファイルをホストデータ処理システムから受け取り、そして元のデータファイルのコンテンツを正確に再現することを可能にする。これは、特定のタイプのプリンタを動作するのにコンピューターシステムを構成する必要を避けるか、あるいは減じる。本システムは、プリンタによる出力に適したソースドキュメントのドットマップの画像を直接生成する（これは、システムがプリンタ自体に組み込まれるか、ホストシステムに組み込まれるかによる）。同様の検討が、プロッタのような他のハードコピー装置にあてはまる。

このシステムは、プロジェクタのような表示装置に組み込まれると、デバイスが、ホストシステムのアプリケーション又はドライバを利用せずに、そしてホストシステム及び／又は表示装置の特定の構成を必要とせずに正確に元のデータファイルのコンテンツを表示することも可能にする。これらのタイプの周辺装置が、本システムを備えると、いずれかのタイプのデータ通信ネットワークを経由して、いずれかのソースからデータファイルを受け取り、そして出力することが可能になる。

加えて、ここに記載されたシステム及び方法は、ドライバー情報又は娯楽のシステムを提供して、乗り物内あるいは乗り物を超えて通信するネットワークへの情報の配信を容易にするために車内のシステムに組み込まれて良い。さらに、ここに記載されるシステムは、単に制御パラメーターのみへの改変を利用して一貫した表示を維持するために、複数の出力ソースを有する装置を動作することができることが理解される。例としては、それに制限はされないが、画像表示を組み込むＳＴＢ又は車内システムと、プリントヘッドとが含まれ、これにより、ソースアプリケーション及びドライバの必要なしでドキュメントを見ること、あるいはプリントすることが可能になる。

前記のものから、本発明のシステムは、例えば、ロム（ＲＯＭ）で実行され、及び／又はエイシック（ＡＩＳＣ）か他のシングルチップシステムかに集積されるといったように「ハードワイヤード」されて良く、あるいはファームウェア（フラッシュ性イーピーロム（ｅＰＲＯＭ）のようにプログラム可能ロム（ＲＯＭ））として、又は、構内又は遠隔で格納され、特定の装置により要求されると取り出されそして実行されるソフトウェアとして実行されて良いことが理解される。

したがって、本発明はここに記載された態様に制限されないことが理解されるが、以下の請求項から、法律の定めるところにより、許される限り広く解釈されるべきであることが理解されるべきである。

８…コンピューター処理、
１０…システム
１１…ソースドキュメント
１２…ドキュメントエージェント
１３…アプリケーションプログラム
１４…内部表現
１５…バッファ格納
１６…ライブラリ
１８…パーサ
１９…レンダラー
２０…内部ビュー
２２…形状プロセッサ
２４…最終出力
２６…出力装置
３０…入力装置
３２…ドキュメント
３４…テキストオブジェクト
３６…図
３８…ページ
４０…入力
４２…フィードバック経路
５０、８０…処理
５２、５４、５８、６０、６２、６４、６８、７０、８２、８４、８８、９２、９４、９８…ステップ
７２、７４…決定ブロック
１１０…データ構造
１１２…リソーステーブル
１１４…ドキュメント構造
１１８…コンテナ
１２０…ドキュメントオブジェクト

Claims (2)

1. デジタルドキュメント内のコンテンツと対話するシステムであって,
   前記デジタルドキュメント内のコンテンツを基本構造の内部表示を表すドキュメントオブジェクトのセットに変換するドキュメントエージェントと、
   前記デジタルコンテンツを表すディスプレイを生成するために、前記ドキュメントオブジェクトをレンダリングするコアドキュメントエンジンと、
   前記デジタルドキュメントのコンテンツを修正するための入力を表す入力信号を検出するユーザーインターフェースと、
   前記デジタルコンテンツのディスプレイを修正するために、前記入力信号のファンクションとして、前記コンテンツの前記内部表示を変更させるプロセスと、を含むことを特徴とするデジタルドキュメント内のコンテンツと対話するシステム。
2. 前記ユーザーインターフェースが、マウス、タッチパッド、タッチスクリーン、ジョイスティク、リモートコントロール、及びキーパッドからなる群から選択される入力装置を含むことを特徴とする請求項２に記載のシステム。

Images