JP2010517174A - ストリーミング可能な対話的レンダリング非依存のページレイアウト - Google Patents

Abstract

コンピュータ出力表示システムが提供される。前記システムは、表示出力コントロールのサブセットに対して適用可能な１つまたは複数のレンダリングルールを判定するためのレイアウトコンポーネントを含む。形式コンポーネントは、表示をレンダリングするために、表示出力コントロールのサブセットにより使用される汎用プロトコルを介して、前記レンダリングルールを伝達する。

Description

情報の消費者が、動的に生成される情報を、使用されるツールまたはデバイスに応じた異なる技法に従ってレンダリングするように要求することは一般的である。これらの技法中には、コンピュータ画面へのダイレクトドローイング（direct drawing）、印刷、ＨＴＭＬ命令、ＰＤＦ形式、Ｗｏｒｄ形式などがある。一部の既存のシステム（特に、レポーティングシステム）は、複数のレンダリングターゲットに対して核となるデータ計算を一度に行うことができるが、諸形式にわたって、レイアウト／ページ付け計算を行う、または共用するという問題をうまく扱うシステムはなかった。例えば、各出力形式は、現在、別個のレンダラを必要とし、それが、計算されたデータをレイアウトおよびページ付けし、さらに、従来技術の図面である図８で示すように所望の形式を生成する。

図８を参照すると、従来技術のレンダリングシステム８００が示されており、データ８１０およびレポート定義情報８２０が８３０で処理されて、この例では、８４０の５つの異なるレンダラに対する５つの異なるレンダリング形式を生成する（例えば、ＨＴＭＬ、ＲＧＤＩ、画像、Ｅｘｃｅｌ、ＰＤＦ）。レンダラ８４０からの出力は、次に表示するための様々な表示コントロール８５０に送られる。システム８００は、従来技術のレンダリングアーキテクチャの簡単化した図を示している。８５０のクライアントアプリケーションが、レポートの１つまたは複数のページをターゲット形式で要求した場合、レポート処理モジュール８３０は、レポート定義８２０に含まれる命令に基づいて、データ８１０に対して働く。その結果処理されたレポートデータは、８５０のクライアントアプリケーションによって要求されたもの、すなわち、ＨＴＭＬ、ＲＧＤＩ（ｒｅｍｏｔｅ ｄｒａｗｉｎｇ ｉｎｓｔｒｕｃｔｉｏｎｓ ｓｔｒｅａｍ：遠隔描画命令ストリーム）、画像、Ｅｘｃｅｌ、ＰＤＦなどに応じて、８４０のいくつかのレンダリングモジュールのうちの１つに提供される。

各レンダラ８４０は、ターゲット出力形式を生成するために、それ自体のページ付けおよびレイアウト論理を利用する。得られたファイルまたはストリームは、次いで、８５０のクライアントアプリケーションに渡される。Ｗｅｂｆｏｒｍコントロールの場合、ＨＴＭＬは、ウェブブラウザでユーザに表示される生成されたウェブページ中に埋め込まれる。Ｗｉｎｆｏｒｍコントロールの場合、ＲＧＤＩストリームは、ユーザの画面上にページを直接描画するための描画命令として解釈される。印刷コントロールの場合、画像ファイルは、レポートの要求されたページをすべて含み、プリンタに渡される。他の場合では、出力ファイルは、クライアントマシンに単にダウンロードされる。

システム８００で示される現在の手法は、いくつかの望ましくない限界がある。１つの側面では、システム８００は、様々な出力表示形式にわたりレイアウト／ページ付けの整合性（consistency）に欠ける。各レンダラは、それ自体のレイアウト／ページ付け論理を実装するので、その論理における不一致が必然的に生じ、選択された出力タイプに応じて、微妙に（または、時には劇的に）異なるレイアウト／ページ付けをまねくことになる。システム８００における別の欠陥は、要求される形式ごとに、レイアウト／ページ付けが冗長的に再計算されるので、不必要な計算負荷のあることである。負荷の問題に加えて、様々な形式を適切にサポートするために、アプリケーション間で渡される冗長な初期接続手順および制御が存在する。

以下では、本明細書で述べるいくつかの態様の基本的な理解を提供するために、簡略化した概要を提示する。この概要は、広範囲に概観するものではなく、または鍵となる要素／重要な要素を特定すること、もしくは本明細書で述べる様々な態様の範囲を概説することを意図するものでもない。その唯一の目的は、後に提示されるより詳細な説明の前置きとして、簡略化した形で、いくつかの概念を示すことである。

処理負荷を軽減し、システム間の通信を簡単化する汎用（ｇｅｎｅｒｉｃ）プロトコルにより、様々な表示形式を処理するためにレンダリングアーキテクチャが提供される。レイアウトコンポーネントは、コンピュータにおける望ましい表示出力のためにレイアウトおよびページ付けルールを判定する。そのルールは、次いで、１つまたは複数の表示コントロールを介して遠隔的に処理できる汎用プロトコルにより書式設定される。例えば、汎用プロトコルは、そのプロトコルを使用するウェブ表示コントロールによりレンダリングされ、次いでＨＴＭＬコードを出力することができる。プリンタコントロールの場合、汎用プロトコルを、それぞれの表示用のプリンタアプリケーションに送ることができる。１組の表示ルールを判定し、次いで、汎用プロトコルによりそのルールを移送することにより、以前のシステムにおけるプロトコルのタイプごとの並列処理を、汎用プロトコルの計算へと低減できるので、表示生成側の並列処理が軽減される。以前のシステムにおけるように、各表示形式に対してプロトコルのタイプごとに命令を送信するのではなく、システム間（例えば、表示データを生成するサーバとそのデータをレンダリングするクライアントとの間）のネットワーク通信を改善する、単一の組（または低減された組）の命令を送信することができる。

レンダリングアーキテクチャおよび汎用プロトコルは、表示プロトコルのタイプごとに並列処理コンポーネントを本質的に使用する以前のシステムについて、多くの利益を提供する。例えば、７つの異なるプロトコルがサポートされる場合、７つの異なる表示コントロールがクライアントエンドで使用されながら、次いで７つの異なるレンダリングジェネレータがサーバエンドで使用された。したがって、そのような並列アーキテクチャについて、レンダリングアーキテクチャおよび汎用プロトコルによって実現されるいくつかの利点がある。一態様では、本アーキテクチャにより、サーバとクライアント間（または他の構成）で計算を分散させることができる。以前のレンダリングタスクを少なくとも２つの別個のサブタスク（例えば、レイアウト／ページ付けおよびターゲット出力生成）に分割することにより、２つのモジュールをクライアント−サーバアーキテクチャで使用することができ、クライアントは最終的なターゲット出力生成を行う。以前には、クライアントで生じる出力生成のために、レイアウトおよびページ付けもまた、クライアントで生じる必要があったはずである。これは、データの全体の組を即座にクライアントに渡すことを必要とし、ページ付けの性能およびスケールの利点をなくすことになる。

レンダリングアーキテクチャの別の特徴は、リッチクライアントにおける編集能力を可能にすることである。従来技術の手法では、特有のターゲット形式をクライアントアプリケーションへと渡していた。例えば、ＨＴＭＬを、ウェブベースのアプリケーションへ送ることができ、画像描画命令（例えば、遠隔ＧＤＩ（ＲＧＤＩ）またはＥＭＦ）を、Ｗｉｎｄｏｗｓ（登録商標）ベースのアプリケーションに送ることができる。これらの形式は、クライアントが、出力を生成するために使用された元の定義に戻って、レンダリングされたオブジェクトをマップできるようにする十分なメタデータを含んでいない。したがって、汎用プロトコルにより提供されるレンダリング非依存の形式は、そのような追加的なメタデータを含むことができる。

さらに別の特徴は、独立して持続可能なレンダリング非依存のページを提供する。レイアウト／ページ付けモジュールの出力を、ストリームとして公開することにより、各ページ（またはページの組）は、セーブ、共用、電子メール、およびその後に続いて任意の所望の出力形式でそれをレンダリングするための能力を失わないドキュメントとしてその他の形で扱うことができる、独立して持続可能なオブジェクトとなる。別の特徴は、クライアント側の性能に基づいて、よりロバストなレンダリングを可能にすることを含む。出力の生成がクライアントで処理される場合、そのクライアント側のアプリケーションは、全サーバ側レンダリングによって処理することのできない、クライアント環境における変動を負うことができる。例えば、所望のフォントがクライアントマシン上に存在しない場合、出力生成モジュールは、代用フォントのフォントメトリックにおける差異を考慮するように、出力に対してわずかな調整を行うことができる。これは、以前の統合されたサーバ側レンダリングでは不可能であった。

前述の関連する目的を達成するために、以下の説明および添付の図面と併せて、いくつかの例示的な態様を本明細書で述べる。これらの態様は、実行することのできる様々な方法を示しており、そのすべてを、本明細書に含めることが意図されている。他の利点および新規な特徴は、図面と併せて検討される場合に、以下の詳細な説明から明らかになるであろう。

コンピュータ化された表示システムを示す概略ブロック図である。 グラフィカル表示システムに対する例示的なクライアント／サーバアーキテクチャを示す概略ブロック図である。 グラフィカル表示システムを駆動するプロセスを示す流れ図である。 遠隔ページレイアウトストリーム形式もしくはプロトコルの例示的な部分または断片を示す図である。 遠隔ページレイアウトストリーム形式もしくはプロトコルの例示的な部分または断片を示す図である。 遠隔ページレイアウトストリーム形式もしくはプロトコルの例示的な部分または断片を示す図である。 遠隔ページレイアウトストリーム形式もしくはプロトコルの例示的な部分または断片を示す図である。 従来技術のレンダリングシステムの例を示す図である。 適切な動作環境を示す概略ブロック図である。 サンプルのコンピューティング環境の概略ブロック図である。

共通の、または汎用のレンダリングプロトコルおよび形式に従って遠隔位置でデータを表示するためにコンピュータ化されたシステムが提供される。一態様では、コンピュータ出力表示システムが提供される。システムは、表示出力コントロールのサブセットに適用可能な１つまたは複数のレンダリングルールを判定するためのレイアウトコンポーネントを含む。形式コンポーネントは、表示をレンダリングするために表示出力コントロールのサブセットによって使用される汎用プロトコルを介してレンダリングルールを伝達する。

本出願で使用されるとき、用語「コンポーネント」、「プロトコル」、「レイアウト」、「ストリーム」などは、コンピュータに関連するエンティティを指し、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行時のソフトウェアを指すことが意図されている。例えば、コンポーネントは、これだけに限らないが、プロセッサ上で動作するプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／またはコンピュータとすることができる。例として、サーバ上で動作するアプリケーションとサーバとの両方はコンポーネントになりうる。１つまたは複数のコンポーネントは、プロセスおよび／または実行のスレッド内に存在することができ、コンポーネントは、１つのコンピュータ上に局在することができ、および／または２つ以上のコンピュータ間で分散することができる。また、これらのコンポーネントは、様々なデータ構造がその上に記憶された様々なコンピュータ可読媒体から実行することができる。コンポーネントは、１つまたは複数のデータパケットを有する信号によるなど、ローカルおよび／または遠隔のプロセスを介して通信することができる（例えば、１つのコンポーネントからのデータが、信号を介して、ローカルシステム、分散システム中の別のコンポーネントと対話し、および／またはインターネットなどのネットワークを越えて他のシステムと対話する）。

初めに図１を参照すると、データのレンダリングを容易にするためのコンピュータ化された表示システム１００が示されている。システム１００は、レポートデータ１２０を処理し、ディスプレイまたは他の出力装置１３０（例えば、プリンタ、ＬＣＤディスプレイ、ＣＲＴ）のためにデータを書式設定するのに使用される１つまたは複数のルールを判定するレイアウトコンポーネント１１０を含む。例えば、ルールは、表示のためのページ付け選択肢、または以下でより詳細に述べる他のレイアウト検討事項を指定することができる。レイアウトコンポーネント１１０の一部であることができる形式コンポーネント１４０は、出力装置１３０を駆動するための遠隔マシン１６０により使用される汎用プロトコル１５０を生成する。一例では、レイアウトコンポーネント１１０および形式コンポーネント１４０は、クライアントマシンとして働く遠隔マシン１６０に汎用プロトコル１５０を送信するサーバ側アーキテクチャの一部とすることができる。

図示のように、遠隔マシン１６０は、出力装置１３０を駆動する１つまたは複数の出力コントロールを含む。例えば、１つの出力コントロールは、出力装置１３０で、データを、汎用プロトコル１５０を介して第１の出力形式（例えば、ＨＴＭＬ）でレンダリングするために使用することができるが、別の出力コントロールは、汎用プロトコルを用いて、異なる出力形式（例えば、プリンタプロトコル）を出力することになる。先に進む前に、レイアウトコンポーネント１１０を、機能的に、示されたような１つのコンポーネントより多い数で提供することができることに留意されたい。

システム１００は、図８で示されたものなどの以前のレンダリングシステムに対して、いくつかのアーキテクチャ的な態様、機能的な態様、および性能／スケーリング態様を提供する。アーキテクチャに関して、システム１００は、ターゲット出力生成からのレイアウト／ページ付けの分離を提供し、形式コンポーネント１４０の出力１５０は、ターゲットのレンダリング形式とは独立している。これは、アーキテクチャに依存しないモデルを提供し、それにより、形式コンポーネント１４０の出力を、オブジェクトモデルまたはストリームのいずれか経由で使用することができ、インメモリアーキテクチャとクライアント−サーバアーキテクチャとの両方を可能にする。加えて、オブジェクトモデルを、ストリームの最上位にレイヤ化することができ、オブジェクトモデルの完全な取込みがメモリを多用し過ぎることになる場合は、増分的に（ｉｎｃｒｅｍｅｎｔａｌｌｙ）取り込むことができる。これは、望ましい場合に、何らかの性能とのトレードオフで、より大きなスケーラビリティを可能にする。本アーキテクチャはまた、任意選択の帯域外の資源を容易にする。例えば、クライアント−サーバのストリーミングの場合、大きい資源（例えば、画像）を、ストリーム中のメタデータにより参照することができ、サーバから効率的な帯域外コールで取り出すことができる。

システム１００の機能に関して、エンドユーザの対話性を高めることができる。例えば、利用可能な事前定義のエンドユーザのアクション（例えば、ソートおよびドリルダウン）を記述するメタデータが、ターゲットに依存しない方法で記述される。また、ページの全構造はクライアントまたは遠隔マシン１６０にとって利用可能であるため、いくつかの、以前には利用できない形の対話性（非事前定義の視覚的なソートなど）を、クライアント上で実装することができる。他の機能的な態様は、改良された編集能力を含む。したがって、レンダリングされたオブジェクトを元の出力／レイアウト定義に戻ってリンクさせるメタデータが、任意選択で提供され、リッチクライアントが、定義に対して実行時編集を提供できるようにする。構成可能なページ付けモデルもまた、システム１００によって提供され、その場合、複数のページ付けモデルに対して、共通の手法を使用することができる。具体的には、それを、厳しい物理的なページ制限（例えば、ＰＤＦ）を有するターゲットをレンダリングすることと、柔軟で物理的なページ制限（例えば、ＨＴＭＬ）を有するターゲットをレンダリングすることとの両方のために使用することができる。同様に、それを、すべてのページが一度にレンダリングされる場合（例えば、ＭＨＴＭＬ）、またはページは一度に１つレンダリングされる場合（例えば、直接の画面描画）で使用することができる。

性能およびスケーリングを高めることに関して、メモリの使用量を制限し、サーバまたは他のエンジン上の性能を最適化するために、シングルパス生成を使用することができる。クライアント−サーバの例では、ページレイアウトストリームは、データに対して、シングルパスで生成することができ、それにより、メモリの使用量を（メモリを多用するおそれのあるオペレーションをクライアントへと延期して）厳しく抑制し、コストのかかるマルチパス、またはレポートデータに対するシーク（ｓｅｅｋ）オペレーションを回避することができる。したがって、以下でより詳細に述べるストリーム構造は、クライアント上の効率的なレンダリングを可能にする。

他の性能態様は、クライアントがメモリを多用する計算と処理を多用する計算とを比較することのできるストリーミング形式内の内部ポインタの使用を含む。これは、最終的なサイズが、サーバ上で計算されるか、またはクライアント上で計算されるかどうかに関する構成可能な選択肢を含む。また、増加する項目（例えば、可変長テキストを有するテキストボックス、または可変サイズの画像を有する画像コントロール）による最終的なレイアウト変更は、サーバ上で計算することができ、または、クライアントまで遅らせることができる。先に進む前に、システム１００は、グラフィカル表示システムまたはアーキテクチャの一部として提供できることに留意されたい。これは、遠隔出力装置１３０を駆動するためのグラフィカルルールを判定する手段（レイアウトコンポーネント１１０）を含む。これはまた、汎用プロトコル１５０に従ってグラフィカルルールを伝える手段も含むことができ、その場合、汎用プロトコルは、遠隔マシン１６０により提供される１組の出力コントロールコンポーネントに対する入力として使用することができる。

ここで図２を参照すると、システム２００は、データのグラフィカル表示のための例示的なクライアント／サーバアーキテクチャを示す。システム２００は、例示的なレンダリングアーキテクチャの簡略化された図を示している。複数の他の構成が可能であることが理解されるべきである。クライアントアプリケーションが、レポートの１つまたは複数のページをターゲット形式で要求した場合、レポート処理モジュール２１０は、レポート定義２３０に含まれる命令に基づいて、データ２２０に対して働く。その結果処理されたレポートデータは、共通のレイアウトおよびページ付けモジュール２４０に提供され、レイアウトおよびページ付けモジュール２４０は、クライアント２５０における出力生成モジュールにより提供される選択肢に基づいて、レイアウトおよびページ付け計算を実行する。例えば、Ｗｅｂｆｏｒｍコントロール２６０が、レポートの単一のページを要求する場合、それは、ＨＴＭＬジェネレータコンポーネント２６２により処理することができるように、ページ長さに関して柔軟であって、変化するテキストおよび画像サイズを無視するレイアウト／ページ付けモジュール２４０に命令することができる。別の例では、画像ジェネレータ２６８を有する印刷コントロール２６６は、レイアウト／ページ付けモジュール２４０に、ページ長さに関して厳密であるように、また正確なテキストおよび画像サイズを計算するように命令することができる。図示のように、別のコントロールは、ＧＤＩジェネレータ２７２を有する別の選択肢であるＷｉｎｆｏｒｍコントロール２７０を含む。

クライアントコントロールが存在する場合、レイアウト／ページ付けモジュール２４０は、要求されたページ（複数可）に対して、２７６のレポートページレイアウト（ＲＰＬ）ストリームを生成し、それは次いで、それぞれのクライアントアプリケーションへと渡される。ＲＰＬストリーム２７６の構造は、図４〜７に関して以下でより詳細に述べることに留意されたい。クライアントアプリケーションは、次いで、この形式に依存しないストリーム２７６を、ターゲット形式（例えば、Ｗｅｂｆｏｒｍコントロール２６０の場合はＨＴＭＬ、Ｗｉｎｆｏｒｍコントロール２７０の場合は直接の画面描画命令、印刷コントロール２６６の場合は画像ファイル）に変換する。クライアントコントロールのない場合、レイアウト／ページ付けモジュール２４０は、レポートページレイアウトを、ストリームではなくオブジェクトモデル（２８０のＲＰＬ ＯＭ）を介して公開する。このオブジェクトモデルにより、選択されたレンダラ（例えば、Ｅｘｃｅｌジェネレータ２８２、ＰＤＦジェネレータ２８４）は、ＲＰＬをターゲット出力形式に変換し、それは、次いで、クライアントマシンへとダウンロードされる。

ページの視覚的なレイアウトおよびコンテンツの記述に加えて、様々な形のメタデータを、ＲＰＬストリーム２７６またはＲＰＬ ＯＭ２８０内に埋め込むことができる。これは、利用可能なエンドユーザのアクション（例えば、ソートおよびドリルダウン）を記述するメタデータ、（ストリーム中に埋め込むのではなく）サーバから画像を取り出す命令、表示されるオブジェクトをレポート定義に戻ってマップする定義情報（クライアントコントロールがランタイム編集機能を提供できるようにする）、および最初には表示されないが、クライアント側のアクションに基づいて視認可能になりうるオブジェクト（クライアント側のドリルダウンとしてそのような態様を可能にする）を含む。

ＲＰＬストリーム２７６は、データに対するトップトゥボトム（ｔｏｐ−ｔｏ−ｂｏｔｔｏｍ）のシングルパスで生成することができ、ページ上のオブジェクトの階層的構造を保持する。この手法は、サーバ上のメモリ効率はよいが、クライアント出力生成モジュールによる単一の順方向パスで（一般に）解釈することができないＲＰＬ構造をもたらす。効率的なクライアント側計算を容易にするために、ＲＰＬ２７６はまた、ストリーム内に数多くのオフセット／ポインタを含むことができ、クライアントが必要な情報を求めてストリーム内を「シーク」（ｓｅｅｋ）することを可能にする。ＲＰＬストリーム形式は、図４〜７に関して以下でより詳細に述べるものとする。

図３は、グラフィカル表示システムを駆動する例示的なプロセス３００を示す。説明の簡単のために、プロセスは、一連の、またはいくつかの行為として示され、記述されているが、本プロセスは、行為の順序により限定されるものではなく、いくつかの行為は、本プロセスに従って、本明細書に示されかつ述べられたものとは異なる順序で、および／または他の行為と同時に発生することができることが、理解されおよび認識されるべきである。例えば、当業者は、方法を、代替的に、状態図などの相互に関係付けられた一連の状態またはイベントとして表すことが可能であることを、理解し認識することだろう。さらに、例示された行為のすべてが、本明細書に記載の本プロセスによる方法を実施する必要がない可能性がある。

図３の３０４に進むと、レポート定義が生成される。３１０で、レイアウトを求める要求が生成される。そのような要求は、例えば、クライアント側アプリケーションが、データをコンピュータ出力装置で表示するように要求することから生成することもできる。３２０でレポート処理が行われる。これは、閲覧可能な形式（例えば、表形式）に編成するために、例えば、行と列を処理するクエリを含むことができる。３３０で、レイアウトおよびページ付けルールが、３２０で処理されたデータに適用される。これは、フォントサイズ、改ページ、色、ページ当たりの行数等を判定するなど、どのようにページが編成され、閲覧されるかを判定することを含むことができる。３４０で、ターゲットに依存しない形式が、３３０で判定されたレイアウトおよびページ付けルールから生成される。そのような独立した形式は、ターゲット特有のプロトコルを使用することなく、どのようにページを表示すべきかを指定する。例えば、ページビューを、ＨＴＭＬまたは他の形式などターゲット特有のプロトコルとは反対に、以下で述べるレポートページレイアウトストリームに従って、汎用的に指定することができる。３５０で、ターゲット非依存のプロトコルにより指定された命令に従って表示がレンダリングされる。ターゲット非依存のプロトコルにより提供される命令に従ってレンダリングするために、１つまたは複数の出力コントロールまたは他のアプリケーションを提供することができる。

図４〜７は、本明細書に述べられた特許請求される諸態様に関連する可能なデータストリーム形式からの例示的な部分または断片を示す。実際のストリームは、図示された例示的なデータ構造よりも多くのまたは少ない数のものを含むことができること、かつ他のストリーム構造および組合せが可能であることが、理解されるべきである。図４を参照すると、例示的なレポートページレイアウト（ＲＰＬ）ストリーム４００が示されている。ＲＰＬストリーム４００は、レポートＲＰＬストリーム構造４１０およびレポートＲＰＬストリーム構造セマンティック４２０を含む。以下のストリームおよびプロトコルの例は、性質において例示的あり、可能な書式設定変数、または他のタイプのデータの包括的なリストであることは意図されていないことに留意されたい。同様に、示された例よりも少ないものを有するストリームを生成することができる。

ＲＰＬストリーム４００に関して、これは、ページを記述するためのレポートメタデータを含むバイナリストリームとして提供することができる。ストリーム４００は、レポート階層を保存しており、その場合、項目の左で最上位のプロパティは、ペアレントに関連している。レポート項目測定値は、ペアレントレベルで保存され、そのデータ型は、「ｓｉｎｇｌｅ」であり、値をミリメートルで表す。ストリーム４００は、読み手にペアレントからチャイルドにジャンプできるようにし、かつすべてのプロパティを読み取ることなくレンダリングの実行時間サイズを読み取ることを可能にする構築されたオフセットベースの階層を有することができる。オフセットは、６４ビットで記憶することができる。スペースを最適化するために、いくつかの構造を、レポート項目間で共用することができ、したがって、それらは一度に書き込まれるようになる。その構造は、例えば、一定のスタイル、複数回埋め込まれる画像、一定のレポート項目プロパティなどである。その他の形で指定されない限り、数値はＩｎｔ３２とすることができる。日付時間値は、ｌｏｎｇ値と同様に記述されるが、Ｂｏｏｌｅａｎは偽の場合０に、真の場合１と定義される。概して、ＲＰＬストリーム４００は、少なくとも３つの目的で働く。
１）非常に大きなレポートに対してメモリ消費量を制御する。
２）レンダラからページ付けを切り離して、レンダリングタスクをサーバ／クライアントベースで実施できるようにする。
３）クライアント編集を可能にする。

ＲＰＬ形式のセマンティック include（Ａ）＝structure Ａ は任意選択であり、ここで、要素のうちの１つだけ｛Ａ｜Ｂ｝＝が存在すべきである。以下の表は例示的なレポートＲＰＬストリーム構造４１０を示す。

以下は、例示的なＲＰＬストリーム構造セマンティック４２０を示す。

図５を参照すると、例示的なＲＰＬストリーム部分５００および５１０が示されている。ＲＰＬストリーム５００は、項目プロパティＲＰＬストリーム構造５２０、および項目プロパティストリーム構造セマンティック５３０を含む。以下の表は、項目プロパティＲＰＬストリーム構造５２０の例である。

以下は、項目プロパティストリーム構造セマンティック５３０の例である。

図５のＲＰＬストリーム５１０に関して、以下の表は、画像プロパティＲＰＬストリーム構造５４０の例である。

以下は、画像プロパティＲＰＬストリーム構造セマンティック５５０の例である。

図６を参照すると、例示的なＲＰＬストリーム部分６００および６１０が示されている。ＲＰＬストリーム６００は、アクション情報プロパティＲＰＬストリーム構造６２０およびアクション情報プロパティストリーム構造セマンティック６３０を含む。以下の表は、アクション情報プロパティＲＰＬストリーム構造６２０の例である。

以下の表は、アクション情報プロパティＲＰＬストリーム構造セマンティック６３０の例である。

図６のＲＰＬストリーム６１０に関して、以下の表は、スタイルプロパティＲＰＬストリーム構造６４０の例である。

図７を参照すると、例示的なＲＰＬストリーム部分７００および７１０が示されている。ＲＰＬストリーム７００は、ｔａｂｌｉｘ測定ＲＰＬストリーム構造７２０、およびｔａｂｌｉｘ測定ＲＰＬストリーム構造セマンティック７３０を含む。以下の表は、ｔａｂｌｉｘ測定ＲＰＬストリーム構造７２０の例である。

以下は、ｔａｂｌｉｘ測定ＲＰＬストリーム構造セマンティック７３０の例である。

図７のＲＰＬストリーム７１０に関して、以下の表は、ｔａｂｌｉｘセルプロパティＲＰＬストリーム構造７４０の例である。

以下は、ｔａｂｌｉｘセルプロパティＲＰＬストリーム構造セマンティック７５０の例である。

開示される主題の様々な態様に対するコンテキストを提供するために、図９および１０ならびに以下の論議では、開示される主題の様々な態様を実装することができる適切な環境の、簡単かつ概略の説明を提供することが意図される。主題は、１つおよび／または複数のコンピュータ上で動作するコンピュータプログラムのコンピュータ実行可能命令の一般的なコンテキストにより上記で述べられてきたが、当業者であれば、本発明はまた、他のプログラムモジュールと組み合わせて実装できることが認識されよう。一般に、プログラムモジュールは、特定のタスクを行い、および／または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者は、本発明の方法は、単一プロセッサもしくはマルチプロセッサのコンピュータシステム、ミニコンピューティング装置、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティング装置（例えば、ＰＤＡ（携帯情報端末）、電話、時計など）、マイクロプロセッサベースのまたはプログラム可能な家庭用または業務用電子機器などを含む、他のコンピュータシステム構成を用いて実施できることを理解するであろう。例示された態様はまた、通信ネットワークを通じてリンクされた遠隔処理装置によってタスクが実行される分散コンピューティング環境中で実施することもできる。しかし、本発明のすべてではないがいくつかの態様は、スタンドアロンのコンピュータ上で実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルと遠隔との両方のメモリ記憶装置中に位置することができる。

図９を参照すると、本明細書で述べる様々な態様を実装する例示的な環境９１０は、コンピュータ９１２を含む。コンピュータ９１２は、処理装置９１４、システムメモリ９１６、およびシステムバス９１８を含む。システムバス９１８は、これだけに限らないが、システムメモリ９１６を含むシステムコンポーネントを処理装置９１４に結合する。処理装置９１４は、任意の様々な利用可能なプロセッサとすることができる。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャも、処理装置９１４として使用することができる。

システムバス９１８は、メモリバスもしくはメモリ制御装置、周辺バスもしくは外部バス、および／または、これだけに限らないが、１１ビットバス、ＩＳＡ（Ｉｎｄｕｓｔｒｉａｌ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＭＳＡ（Ｍｉｃｒｏ−Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）、ＥＩＳＡ（Ｅｘｔｅｎｄｅｄ ＩＳＡ）、ＩＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ）、ＶＬＢ（ＶＥＳＡ Ｌｏｃａｌ Ｂｕｓ）、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＡＧＰ（Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ ｂｕｓ）、およびＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ）を含む任意の様々な利用可能なバスアーキテクチャを用いるローカルバスを含むいくつかのタイプのバス構造（複数可）のうちの任意のものとすることができる。

システムメモリ９１６は、揮発性メモリ９２０および不揮発性メモリ９２２を含む。起動中など、コンピュータ９１２内のエレメント間で情報を転送するための基本ルーチンを含むＢＩＯＳ（基本入出力システム）は、不揮発性メモリ９２２中に格納される。例示のためであり、限定するものではないが、不揮発性メモリ９２２は、ＲＯＭ（読取り専用メモリ）、ＰＲＯＭ（プログラム可能ＲＯＭ）、ＥＰＲＯＭ（電気的にプログラム可能ＲＯＭ）、ＥＥＰＲＯＭ（電気的に消去可能なＲＯＭ）、またはフラッシュメモリを含むことができる。揮発性メモリ９２０は、外部のキャッシュメモリとして働くＲＡＭ（ランダムアクセスメモリ）を含む。例示のためであり、限定するものではないが、ＲＡＭは、ＳＲＡＭ（同期型ＲＡＭ）、ＤＲＡＭ（ダイナミックＲＡＭ）、ＳＤＲＡＭ（同期型ＤＲＡＭ）、ＤＤＲ ＳＤＲＡＭ（２倍データレート型ＳＤＲＡＭ）、ＥＳＤＲＡＭ（ｅｎｈａｎｃｅｄ ＳＤＲＡＭ）、ＳＬＤＲＡＭ（シンクリンクＤＲＡＭ）、およびＤＲＲＡＭ（ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＲＡＭ）などの多くの形態で利用可能である。

コンピュータ９１２はまた、取外し可能／取外し不能、揮発性／不揮発性のコンピュータ記憶媒体を含む。図９は、例えば、ディスクストレージ９２４を示している。ディスクストレージ９２４は、これだけに限らないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックなどのデバイスを含む。加えて、ディスクストレージ９２４は、これだけに限らないが、ＣＤ−ＲＯＭ（コンパクトディスクＲＯＭデバイス）、ＣＤ−Ｒドライブ（ＣＤ記録可能ドライブ）、ＣＤ−ＲＷドライブ（ＣＤ書換え可能ドライブ）、またはＤＶＤ−ＲＯＭ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ ＲＯＭドライブ）などの光ディスクドライブを含む、他の記憶媒体とは別個に、または他の記憶媒体と組み合わせた記憶媒体を含むことができる。ディスクストレージデバイス９２４のシステムバス９１８への接続を容易にするために、インターフェース９２６など、取外し可能または取外し不能のインターフェースが典型的には使用される。

図９は、適切な動作環境９１０中で記述される、ユーザと基本的なコンピュータ資源との間の中間物（ｉｎｔｅｒｍｅｄｉａｒｙ）として働くソフトウェアを説明していることが理解されるべきである。そのようなソフトウェアは、オペレーティングシステム９２８を含む。ディスクストレージ９２４上に格納することができるオペレーティングシステム９２８は、コンピュータシステム９１２の資源を制御し、割り振るように働く。システムアプリケーション９３０は、システムメモリ９１６中に、またはディスクストレージ９２４上のいずれかに格納されたプログラムモジュール９３２およびプログラムデータ９３４を介して、オペレーティングシステム９２８による資源の管理を利用する。本明細書で述べた様々なコンポーネントは、様々なオペレーティングシステム、またはオペレーティングシステムの組合せを用いて実装できることが理解されるべきである。

ユーザは、入力装置（複数可）９３６を介して、コマンドまたは情報をコンピュータ９１２に入力する。入力装置９３６は、これだけに限らないが、マウス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどのポインティング装置を含む。これらの、および他の入力装置は、インターフェースポート（複数可）９３８を経由し、システムバス９１８を介して処理装置９１４と接続する。インターフェースポート（複数可）９３８は、例えば、シリアルポート、パラレルポート、ゲームポート、およびＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）を含む。出力装置（複数可）９４０は、入力装置（複数可）９３６と同じタイプのいくつかのポートを使用する。したがって、例えば、ＵＳＢポートは、コンピュータ９１２への入力を提供するために、またコンピュータ９１２からの情報を出力装置９４０に出力するために使用することができる。出力アダプタ９４２は、他の出力装置９４０の中で、特別のアダプタを必要とするモニタ、スピーカ、およびプリンタなどのいくつかの出力装置９４０が存在することを示すために提供される。出力アダプタ９４２は、例示のためであり、限定するものではないが、出力装置９４０とシステムバス９１８との間の接続の手段を提供するビデオおよびサウンドカードを含む。遠隔コンピュータ（複数可）９４４など、他の装置および／または装置のシステムは、入力および出力機能の両方を提供することに留意すべきである。

コンピュータ９１２は、遠隔コンピュータ（複数可）９４４などの１つまたは複数の遠隔コンピュータに対する論理接続を用いてネットワーク化環境で動作することができる。遠隔コンピュータ（複数可）９４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイスまたは他の共通のネットワークノードなどとすることができ、典型的には、コンピュータ９１２に関連して述べたエレメントの多くまたはすべてを含む。簡単化のために、メモリ記憶装置９４６だけが、遠隔コンピュータ（複数可）９４４と共に示されている。遠隔コンピュータ（複数可）９４４は、ネットワークインターフェース９４８を介して、コンピュータ９１２に論理的に接続され、次いで、通信接続９５０を介して物理的に接続される。ネットワークインターフェース９４８は、ＬＡＮ（ローカルエリアネットワーク）、およびＷＡＮ（広域ネットワーク）などの通信ネットワークを包含する。ＬＡＮ技術は、ＦＤＤＩ（Ｆｉｂｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）、ＣＤＤＩ（Ｃｏｐｐｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）、イーサネット（登録商標）／ＩＥＥＥ８０２．３、トークンリング／ＩＥＥＥ８０２．５などを含む。ＷＡＮ技術は、これだけに限らないが、ポイントツーポイントのリンク、ＩＳＤＮ（総合ディジタル通信網サービス）およびその変形形態などの回線交換網、パケット交換網、およびＤＳＬ（デジタル加入者線）を含む。

通信接続（複数可）９５０は、ネットワークインターフェース９４８をバス９１８に接続するために使用されるハードウェア／ソフトウェアを指す。通信接続９５０が、説明を明確にするために、コンピュータ９１２の内側に示されているが、コンピュータ９１２の外部とすることもできる。ネットワークインターフェース９４８に接続するために必要なハードウェア／ソフトウェアは、例示のために過ぎないが、通常の電話グレードのモデム、ケーブルモデム、およびＤＳＬモデムを含むモデム、ＩＳＤＮアダプタ、ならびにイーサネット（登録商標）カードなど、内部および外部の技術を含む。

図１０は、使用することのできるサンプルのコンピューティング環境１０００の概略ブロック図である。システム１０００は、１つまたは複数のクライアント１０１０を含む。クライアント（複数可）１０１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。システム１０００はまた、１つまたは複数のサーバ１０３０を含む。サーバ（複数可）１０３０はまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ１０３０は、例えば、本明細書で述べたコンポーネントを使用することにより変換を実行するためのスレッドを収容することができる。クライアント１０１０とサーバ１０３０との間の１つの可能な通信は、２つ以上のコンピュータプロセス間で送信されるように適合されたデータパケットの形であってよい。システム１０００は、クライアント（複数可）１０１０とサーバ（複数可）１０３０との間の通信を容易にするために使用することができる通信フレームワーク１０５０を含む。クライアント（複数可）１０１０は、クライアント（複数可）１０１０にとってローカルな情報を格納するために使用することができる１つまたは複数のクライアントデータストア（複数可）１０６０に動作可能に接続される。同様に、サーバ（複数可）１０３０は、サーバ１０３０にとってローカルな情報を格納するために使用することができる１つまたは複数のサーバデータストア（複数可）１０４０に動作可能に接続される。

上で述べてきたものは、様々な例示的な態様を含む。これらの諸態様を述べるために、コンポーネントまたは方法の考えられるあらゆる組合せを述べることは不可能であるのは当然であるが、当業者は、多くのさらなる組合せおよび置換が可能であることを認識することができる。したがって、本明細書で述べた態様は、添付の請求項の趣旨および範囲に含まれるそのような改変、修正、および変形をすべて含むことが意図される。さらに、用語「含む（ｉｎｃｌｕｄｅｓ）」が、詳細な説明または特許請求の範囲のいずれかで使用される限りにおいて、そのような用語は、「含む／備える（ｃｏｍｐｒｉｓｉｎｇ）」が特許請求の範囲で移行語として使用される場合に解釈されるように、用語「含む／備える（ｃｏｍｐｒｉｓｉｎｇ）」と同様に包含的であることが意図される。

Claims (20)

1. １組の表示出力コントロールに適用可能な１つもしくは複数のレイアウトまたはページ付けルールを判定するレイアウトコンポーネントと、
   前記表示出力コントロールのサブセットに前記レイアウトまたはページ付けルールを適用することの結果としてデータを伝達するための形式コンポーネントであって、前記データは、表示をレンダリングする汎用プロトコルと関連付けられている形式コンポーネントと
   を備えることを特徴とするコンピュータ出力表示システム。
2. 前記レイアウトコンポーネントは、インメモリ構成、またはクライアント／サーバ構成をサポートするストリームまたはオブジェクトモデルを生成することを特徴とする請求項１に記載のシステム。
3. 前記オブジェクトモデルは、前記ストリームの最上位にレイヤ化され、増分的に取り込まれることを特徴とする請求項２に記載のシステム。
4. 前記クライアントサーバ構成は、前記ストリーム中のメタデータを介して資源を参照することを特徴とする請求項２に記載のシステム。
5. エンドユーザのアクションを記述するメタデータをさらに含むことを特徴とする請求項１に記載のシステム。
6. 予め定義されていない視覚的なソートオペレーションをサポートするコンポーネントをさらに備えることを特徴とする請求項５に記載のシステム。
7. レンダリングされたオブジェクトを、元のデータ定義にリンクさせるメタデータをさらに備えることを特徴とする請求項１に記載のシステム。
8. グラフィカルなレンダリングを容易にする構成可能なページ付けモジュールをさらに備えることを特徴とする請求項１に記載のシステム。
9. 前記構成可能なページ付けモジュールは、厳しい物理的なページ制限を有するレンダリングターゲット、柔軟な物理的なページ制限を有するレンダリングターゲット、またはすべてのページが同時にレンダリングされるレンダリングターゲットに関連付けられていることを特徴とする請求項８に記載のシステム。
10. メモリの使用量を制限し、サーバの性能を最適化するために、シングルパスを実施するコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
11. メモリを多用する計算間、または処理を多用する計算間のスケーリングを容易にするために、１つまたは複数の内部ポインタを含む汎用プロトコルをさらに備えることを特徴とする請求項１に記載のシステム。
12. サイズ計算をサーバ上で行うか、またはクライアント上で行うかを構成することを判定するコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
13. 前記汎用プロトコルは、レポートページレイアウト（ＲＰＬ）ストリーム、またはＲＰＬオブジェクトモデルであることを特徴とする請求項１に記載のシステム。
14. 前記ＲＰＬストリームは、ＲＰＬストリーム構造、およびＲＰＬストリーム構造セマンティックを含むことを特徴とする請求項１３に記載のシステム。
15. 前記ＲＰＬストリームは、項目プロパティストリーム、画像プロパティストリーム、アクション情報プロパティストリーム、スタイルプロパティストリーム、ｔａｂｌｉｘ測定ストリーム、またはｔａｂｌｉｘセルプロパティストリームを含むことを特徴とする請求項１３に記載のシステム。
16. グラフィカルデータをレンダリングする方法であって、
    レポート定義を生成するステップと、
    データを取り出すステップと、
    前記レポート定義からの命令に従って、前記データにレイアウトおよびページ付けルールを適用するステップと、
    表示をレンダリングするためのターゲット非依存の形式を生成するステップと
    を含むことを特徴とする方法。
17. 少なくとも１つのページをレンダリングするための遠隔要求を生成するステップをさらに含むことを特徴とする請求項１６に記載の方法。
18. 前記遠隔要求に応じて、ストリームまたはオブジェクトモデルを生成するステップをさらに含むことを特徴とする請求項１７に記載の方法。
19. 前記ストリームまたは前記オブジェクトモデルに対するメタデータを生成するステップを特徴とする請求項１８に記載の方法。
20. 遠隔の出力装置を駆動するためのグラフィカルルールを判定する手段と、
    汎用プロトコルに従って前記グラフィカルルールを伝達する手段であって、前記汎用プロトコルは、１組の出力制御コンポーネントに対する入力として使用することができる手段と
    を備えることを特徴とするグラフィカル表示システム。

Images