JP2007535751A - 文書マークアップ方法およびシステム - Google Patents

Abstract

モジュールコンテンツフレームワークおよび文書フォーマット方法およびシステムが説明される。説明されるフレームワークおよびフォーマットは、文書中心のコンテンツを構成し、パッケージングし、配布し、かつレンダリングするための、１組のビルディングブロックを定義する。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムが、高い信頼性および一貫性をもって、文書を生成し、交換し、かつ表示することを可能にする文書フォーマットのための、プラットフォーム独立のフレームワークを定義する。フレームワークおよびフォーマットは、柔軟性および拡張性に優れた方式で設計される。この汎用フレームワークおよびフォーマットに加えて、リーチパッケージフォーマットとして知られる特殊なフォーマットが、汎用フレームワークを使用して定義される。リーチパッケージフォーマットは、ページ付けされた文書を保存するためのフォーマットである。リーチパッケージのコンテンツは、様々な環境内の装置およびアプリケーションにおいて、様々なシナリオのもと、完全な忠実度で表示または印刷されることができる。

Description

本発明は、コンテンツフレームワーク（ｃｏｎｔｅｎｔ ｆｒａｍｅｗｏｒｋ）、文書フォーマット（ｄｏｃｕｍｅｎｔ ｆｏｒｍａｔ）、およびその両方を利用できる関連する方法およびシステムに関する。

今日、一般に、コンテンツを表すための多くの異なるタイプのコンテンツフレームワークが存在し、様々なタイプの文書を書式化するための多くの異なるタイプの文書フォーマットが存在する。多くの場合、これらのフレームワークおよびフォーマットの各々は、関連文書を組み立て、作成し、処理し、または消費する（consume）ために、それ独自の関連ソフトウェアを必要とする。適切な装置にインストールされた特定の関連ソフトウェアをもつ者にとって、関連文書を組み立て、作成し、処理し、または消費することは、大した問題ではない。適切なソフトウェアをもたない者にとって、関連文書を組み立て、作成し、処理し、または消費することは、一般に不可能である。

Sections 3.3 (Path Component) and 5 (Relative URI References) of RFC2396, (Uniform Resource Identifiers (URI: Generic Syntax) specification Sections 3 (URI Syntactic Components) and 3.4 (Query Component) of RFC2396, (Uniform Resource Identifiers (URI: Generic Syntax) specification Section 4.1 (Fragment Identifier) of RFC2396, (Uniform Resource Identifiers (URI: Generic Syntax) specification RFC2045 (Multipurpose Internet Mail Extensions; (MIME)) RFC2396

このことを背景として、文書の作成および消費に関する限り、依然としてユビキタス性（ｕｂｉｑｕｉｔｙ）が必要とされている。

モジュールコンテンツフレームワーク（ｍｏｄｕｌａｒ ｃｏｎｔｅｎｔ ｆｒａｍｅｗｏｒｋ）および文書フォーマット方法およびシステムが説明される。説明されるフレームワークおよびフォーマットは、文書中心のコンテンツを構成し、パッケージングし、配布し、かつレンダリングするための、１組のビルディングブロック（ｂｕｉｌｄｉｎｇ ｂｌｏｃｋ）を定義する。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムが、高い信頼性および一貫性をもって、文書を生成し、交換し、かつ表示することを可能にする文書フォーマットのための、プラットフォーム独立のフレームワークを定義する。フレームワークおよびフォーマットは、柔軟性および拡張性に優れた方式で設計される。

この汎用フレームワークおよびフォーマットに加えて、リーチパッケージフォーマット（ｒｅａｃｈ ｐａｃｋａｇｅ ｆｏｒｍａｔ）として知られる特殊なフォーマットが、汎用フレームワークを使用して定義される。リーチパッケージフォーマットは、ページ付けされた文書を保存するためのフォーマットである。リーチパッケージのコンテンツは、様々な環境内の装置およびアプリケーションにおいて、様々なシナリオのもと、完全な忠実度で表示または印刷されることができる。

概要
本文書は、モジュールコンテンツフレームワークおよび文書フォーマットについて説明する。フレームワークおよびフォーマットは、文書中心のコンテンツを構成し、パッケージングし、配布し、かつレンダリングするための、１組のビルディングブロックを定義する。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムが、高い信頼性および一貫性をもって、文書を生成し、交換し、かつ表示することを可能にする文書フォーマットのための、プラットフォーム独立のフレームワークを定義する。フレームワークおよびフォーマットは、柔軟性および拡張性に優れた方式で設計される。様々な実施形態において、含まれ得るコンテンツのタイプ、コンテンツが提示される方法、またはコンテンツを処理するためのクライアントをその上で構築するプラットフォームについて制約は存在しない。

この汎用フレームワークに加えて、特殊なフォーマットが、汎用フレームワークを使用して定義される。このフォーマットは、本文書では、リーチパッケージフォーマットと呼ばれ、ページ付け（ｐａｇｉｎａｔｅｄ）または事前ページ付け（ｐｒｅ−ｐａｇｉｎａｔｅｄ）された文書を保存するためのフォーマットである。リーチパッケージのコンテンツは、様々な環境内の装置およびアプリケーションにおいて、様々なシナリオのもと、完全な忠実度で表示または印刷されることができる。

以下で説明されるフレームワークの目標の１つは、以下で説明されるフレームワークおよびフォーマットに従って作成されるコンテンツを読みまたは書く、独立して書かれたソフトウェアおよびハードウェアシステムの相互運用性を保証することである。この相互運用性を達成するため、説明されるフォーマットは、コンテンツを読みまたは書くシステムが満足しなければならない形式的要件を定義する。

以下の説明は、以下に示す流れに沿って進められ、２つの主要セクション、すなわち、「フレームワーク」と題するセクションと、「リーチパッケージフォーマット」と題するセクションにおいて提示される。

「フレームワーク」と題するセクションは、説明的なパッケージングモデルを提示し、フレームワークパッケージを作り上げる様々なパーツ（Ｐａｒｔ）と関係について説明する。フレームワークパッケージにおける記述的メタデータ（ｄｅｓｃｒｉｐｔｉｖｅ ｍｅｔａｄａｔａ）の使用に加え、物理コンテナ（ｐｈｙｓｉｃａｌ ｃｏｎｔａｉｎｅｒ）へのマッピングプロセス、フレームワークマークアップ（ｆｒａｍｅｗｏｒｋ ｍａｒｋｕｐ）の拡張、およびフレームワークバージョニングメカニズム（ｆｒａｍｅｗｏｒｋ ｖｅｒｓｉｏｎｉｎｇ ｍｅｃｈａｎｉｓｍ）についての情報が説明される。

「リーチパッケージフォーマット」と題するセクションは、リーチパッケージと呼ばれる１つの特殊なタイプのフレームワーク構築パッケージ（ｆｒａｍｅｗｏｒｋ ｂｕｉｌｔ ｐａｃｋａｇｅ）の構造について探求する。このセクションは、固定ペイロード（ｆｉｘｅｄ ｐａｙｌｏａｄ）に特有なパッケージパーツについても説明し、リーチパッケージのマークアップモデルおよび描画モデルを定義する。このセクションは、説明的なサンプルが添えられた、例示的なリーチマークアップ要素およびそれらのプロパティで締めくくられる。

以下に続く説明の高水準な概要として、図１について考察すると、図１は、全体が１００で指示される本発明のフレームワークおよびフォーマットの態様を示している。フレームワークのいくつかの例示的なコンポーネントは１０２で示され、リーチパッケージフォーマットのいくつかの例示的なコンポーネントは１０４で示されている。

フレームワーク１０２は、関係コンポーネント（ｒｅｌａｔｉｏｎｓｈｉｐ ｃｏｍｐｏｎｅｎｔ）、プラグ可能コンテナコンポーネント（ｐｌｕｇｇａｂｌｅ ｃｏｎｔａｉｎｅｒｓ ｃｏｍｐｏｎｅｎｔ）、インタリービング／ストリーミングコンポーネント（ｉｎｔｅｒｌｅａｖｉｎｇ／ｓｔｒｅａｍｉｎｇ ｃｏｍｐｏｎｅｎｔ）、およびバージョニング／拡張性コンポーネント（ｖｅｒｓｉｏｎｉｎｇ／ｅｘｔｅｎｓｉｂｉｌｉｔｙ ｃｏｍｐｏｎｅｎｔ）を含むが、これらに限定されない、例示的なコンポーネントを備え、その各々が、以下でより詳しく探求される。リーチパッケージフォーマット１０４は、セレクタ／シーケンサコンポーネント（ｓｅｌｅｃｔｏｒ／ｓｅｑｕｅｎｃｅｒ ｃｏｍｐｏｎｅｎｔ）、およびパッケージマークアップ定義コンポーネント（ｐａｃｋａｇｅ ｍａｒｋｕｐ ｄｅｆｉｎｉｔｉｏｎ ｃｏｍｐｏｎｅｎｔ）を含むコンポーネントを備える。

以下に続く説明では、説明されるコンポーネントがフレームワークおよびパッケージフォーマットのどこに当てはまるかに関する全体像を読者が維持できるように、図１を反復的に参照し返すことになろう。

フレームワーク
以下に続く説明では、汎用フレームワークについての説明が提供される。独立した１次副見出しは、「パッケージモデル」、「構成パーツ（Ｃｏｍｐｏｓｉｔｉｏｎ Ｐａｒｔｓ）：セレクタおよびシーケンス」、「記述的メタデータ」、「物理モデル」、「物理マッピング」、および「バージョニングおよび拡張性」を含む。各１次副見出しは、１つまたは複数の関連副見出しを有する。

パッケージモデル
このセクションは、パッケージモデルについて説明し、パッケージおよびパーツ、ドライバ、関係、パッケージ関係、ならびに開始パーツ（ｓｔａｒｔ ｐａｒｔ）について説明する副見出しを含む。

パッケージおよびパーツ
例示および説明されるモデルでは、コンテンツは、パッケージ内に保持される。パッケージは、関連パーツの集まりを保持する論理エンティティである。パッケージの目的は、文書（または他のタイプのコンテンツ）のピース（ｐｉｅｃｅ）をすべて寄せ集めて、プログラマおよびエンドユーザが作業し易い１つのオブジェクトにすることである。例えば、図２について考察すると、図２は、複数のパーツを含む文書を保持する例示的なパッケージ２００を示しており、複数のパーツは、文書を表すＸＭＬマークアップパーツ２０２、文書で使用されるフォントについて記述するフォントパーツ２０４、文書のページについて記述する複数のページパーツ２０６、および文書内のピクチャを表すピクチャパーツを含む。文書を表すＸＭＬマークアップパーツ２０２は、パッケージのコンテンツ全体が解析されることは必要としない、容易な検索性（ｓｅａｒｃｈａｂｉｌｉｔｙ）および参照性（ｒｅｆｅｒｅｎｃｉｎｇ）を可能にし得る点で有利である。このことは、以下でより明白になるであろう。

この文書全体にわたって、（コンシューマとも呼ばれる）リーダおよび（プロデューサとも呼ばれる）ライタという概念が、導入され、説明される。本文書で使用されるリーダという用語は、モジュールコンテンツフォーマットベースのファイルまたはパッケージを読むエンティティのことを指す。本文書で使用されるライタという用語は、モジュールコンテンツフォーマットベースのファイルまたはパッケージに書くエンティティのことを指す。一例として、図３について考察すると、図３は、パッケージを作成するライタと、パッケージを読むリーダを示している。一般に、ライタおよびリーダは、ソフトウェアとして実施される。少なくとも１つの実施形態では、パッケージの作成および書式化に関連する処理上のオーバヘッドおよび複雑性の多くは、ライタが引き受ける。こうすることによって、処理上の複雑性およびオーバヘッドの多くが、リーダから取り除かれ、これは、当業者であれば理解されるように、多くの現行モデルからの脱却である。この態様は、以下で明白になるであろう。

少なくとも１つの実施形態では、単一のパッケージは、パッケージ内に保持されるコンテンツの１つまたは複数の表現を含む。しばしば、パッケージは、本出願においてコンテナと呼ばれる単一のファイルである。これは、エンドユーザに、例えば、文書をその文書のすべての構成要素ピース（イメージ、フォント、データなど）と共に配布する便利な方法を提供する。パッケージは、しばしば、単一のファイルに直接対応するが、必ずしも常にそうである必要はない。パッケージは、物理的に様々な方法（例えば、単一のファイル、ルースファイル（ｌｏｏｓｅ ｆｉｌｅ）の集まり、データベース、ネットワーク接続を介する一時的な伝送路など、ただしこれらに限定されない）で表され得る論理エンティティである。したがって、コンテナは、パッケージを保持するが、すべてのパッケージが、コンテナ内に保存されるわけではない。

抽象モデルは、どのような物理的記憶メカニズムからも独立して、パッケージを記述する。例えば、抽象モデルは、「ファイル」、「ストリーム」、またはパッケージが配置される物理的世界に関係する他の物理的用語に言及しない。以下で説明されるように、抽象モデルは、様々な物理フォーマットおよび通信プロトコルなどのためのドライバをユーザが作成することを可能にする。類推によれば、アプリケーションは、イメージの印刷を望む場合、（特定の種類のプリンタを理解するドライバによって提供される）プリンタの抽象概念を使用する。したがって、アプリケーションは、特定の印刷装置について、またはその印刷装置とどのように通信するかについて知る必要はない。

コンテナは、コンテナ化しない場合のルースな非接続ファイルの集まりにまさる、多くの利点を提供する。例えば、類似の構成要素は、集約されることができ、コンテンツは、インデックスが付けられ、圧縮されることができる。加えて、構成要素間の関係が、識別されることができ、権利管理、デジタル署名、暗号化、およびメタデータが、構成要素に適用されることができる。もちろん、コンテナは、上で具体的に列挙されていない他の機能のために使用されることができ、他の機能を実施することができる。

共通パーツプロパティ
例示および説明される実施形態では、パーツは、共通プロパティ（例えば、名前）と、バイトのストリームとを含む。これは、ファイルシステム内のファイル、またはＨＴＴＰサーバ上のリソースに類似している。そのコンテンツに加えて、各パーツは、いくつかの共通パーツプロパティ（ｃｏｍｍｏｎ ｐａｒｔ ｐｒｏｐｅｒｔｙ）を有する。これらは、パーツの名前である名前（ｎａｍｅ）と、パーツ内に保存されるコンテンツのタイプであるコンテンツタイプ（ｃｏｎｔｅｎｔ ｔｙｐｅ）とを含む。パーツは、以下で説明されるように、１つまたは複数の関連する関係も有することができる。

パーツ名（ｐａｒｔ ｎａｍｅ）は、何らかの方法でパーツを参照する必要がある場合に常に使用される。例示および説明される実施形態では、名前は、ファイルシステム上のパスまたはＵＲＩ内のパスと同様、階層に組織される。以下はパーツ名の例である。

上に見られるように、この実施形態では、パーツ名は以下の特徴を有する。
・パーツ名は、従来のファイルシステム内のファイル名と同様である。
・パーツ名は、前方スラッシュ（「/」）で開始する。
・ファイルシステム内のパスまたはＵＲＩ内のパスと同様、パーツ名は、１組のディレクトリライクな名前（上の例のtickets、images/march、およびpages）によって、階層に組織されることができる。
・この階層は、スラッシュによって線引きされたセグメントから成る。
・名前の最終セグメントは、従来のファイルシステムのファイル名と同様である。

パーツを命名するための規則、特にパーツ名のために使用され得る有効な文字は、本文書で説明されるフレームワークに特有であることに留意することが重要である。これらのパーツ名規則は、インターネット標準ＵＲＩ命名規則に基づいている。この実施形態によれば、この実施形態においてパーツ名を指定するために使用される文法は、文献（例えば、非特許文献１参照）で定義されるabs_pathシンタックスに正確に一致する。

以下の追加制限が、有効なパーツ名としてのabs_pathに適用される。
・文献（例えば、非特許文献２参照）で定義されるようなクエリコンポーネント（Ｑｕｅｒｙ Ｃｏｍｐｏｎｅｎｔ）は、パーツ名に適用可能ではない。
・文献（例えば、非特許文献３参照）に記述されるようなフラグメント識別子（Ｆｒａｇｍｅｎｔ ｉｄｅｎｔｉｆｉｅｒ）は、パーツ名に適用可能ではない。
・既存パーツのパーツ名に* ("/" segment)を追加することによって生成される名前を有するどのようなパーツをもつことも規則に反する。
パーツ名の文法が以下に示されている。

パッケージ内のすべてのパーツの名前のセグメントがツリーを形成することが理解され得る。これは、ツリー内のすべての非リーフノードはフォルダであり、リーフノードはコンテンツを格納する実際のファイルである、ファイルシステムで起こることと類似している。名前ツリー内のこれらフォルダライクのノード（すなわち、非リーフノード）は、パッケージ内でパーツを組織するという類似の機能を果たす。しかし、これらの「フォルダ」は概念としてのみ命名階層内に存在し、持続的形式での他の発現（ｏｔｈｅｒ ｍａｎｉｆｅｓｔａｔｉｏｎ ｉｎ ｔｈｅ ｐｅｒｓｉｓｔｅｎｃｅ ｆｏｒｍａｔ）をもたないことを忘れないことが重要である。

パーツ名は、「フォルダ」レベルに存在することはできない。具体的には、パーツ命名階層内の非リーフノード（「フォルダ」）は、同じ名前をもつパーツとサブフォルダを格納することはできない。

例示および説明される実施形態では、あらゆるパーツは、どのタイプのコンテンツがパーツ内に保存されているかを識別するコンテンツタイプを有する。コンテンツタイプの例は以下のものを含む。

コンテンツタイプは、文献（例えば、非特許文献４参照）で定義されるような例示的なフレームワークで使用される。具体的には、各コンテンツタイプは、メディアタイプ（例えば、text）、サブタイプ（例えば、plain）、およびキー＝値（例えば、charset=“us-ascii”）形式の１組のオプションパラメータを含み、複数のパラメータは、セミコロンによって分割される。

パーツアドレッシング
しばしば、パーツは、他のパーツへの参照を含む。簡単な一例として、マークアップファイルとイメージの２つのパーツを有するコンテナを想像する。マークアップファイルは、マークアップファイルが処理されるとき、関連イメージが識別され、その場所が特定され得るように、イメージへの参照を保持することを望む。コンテンツタイプおよびＸＭＬスキーマの設計者は、これらの参照を表すためにＵＲＩを使用することができる。これを可能にするため、パーツ名の世界とＵＲＩの世界の間のマッピングが定義される必要がある。

パッケージ内でＵＲＩの使用を可能にするには、パッケージベースのコンテンツ内のＵＲＩを評価する場合、パッケージ自体はＵＲＩ参照のための「オーソリティ（ａｕｔｈｏｒｉｔｙ）」として扱われるべきであり、ＵＲＩのパス構成要素がパッケージ内のパーツ名階層をナビゲートするために使用されるという、特別なＵＲＩ解釈規則が使用されなければならない。

例えば、http://www.example.com/foo/something.packageというパッケージＵＲＩが与えられた場合、/abc/bar.xmlへの参照は、ＵＲＩのhttp://www.example.com/abc/bar.xmlではなく、/abc/bar.xmlと呼ばれるパーツを意味すると解釈される。

コンテナ内の１つのパーツから別のパーツを参照する必要がある場合、相対ＵＲＩが使用されるべきである。相対ＵＲＩを使用することで、参照の重なり合う部分を修正することなく、コンテナのコンテンツを異なるコンテナに（または例えばファイルシステムからコンテナに）一緒に移動することが可能になる。

パーツからの相対参照は、その参照を含むパーツの「ベースＵＲＩ（ｂａｓｅ ＵＲＩ）」に対して解釈される。デフォルトでは、パーツのベースＵＲＩは、パーツ名である。

以下に示す名前を有するパーツを含むコンテナについて考察する。

「/markup/page.xml」パーツが「../images/picture jpeg」へのＵＲＩ参照を含む場合、この参照は、上の規則に従って、パーツ名「../images/picture jpeg」を参照するものとして解釈されなければならない。

いくつかのコンテンツタイプは、コンテンツ内で異なるベースを指定することによって、デフォルトのベースＵＲＩをオーバライドする方法を提供する。これらのオーバライドの１つが存在する場合、明示的に指定されたベースＵＲＩが、デフォルトの代わりに使用されるべきである。

時には、パーツ内の部分または特定の地点を「アドレッシングする」ことが役に立つ。ＵＲＩの世界では、フラグメント識別子が使用される［例えば、非特許文献５を参照］。コンテナでは、そのメカニズムが同じ方法で機能する。具体的には、フラグメントは、アドレッシングされるパーツのコンテンツタイプに関連して理解される追加情報を含む文字列である。例えば、ビデオファイルでは、フラグメントは、フレームを識別することができ、ＸＭＬファイルでは、フラグメントは、ｘｐａｔｈを介してＸＭＬファイルの一部分を識別することができる。

フラグメント識別子は、アドレッシングされるパーツのフラグメントを識別するため、パーツをアドレッシングするＵＲＩと併せて使用される。フラグメント識別子は、オプションであり、クロスハッチ（「＃」）文字によってＵＲＩから分離される。すなわち、フラグメント識別子は、ＵＲＩの一部ではないが、しばしば、ＵＲＩと併せて使用される。

パッケージおよびパーツ命名モデルはきわめて柔軟であるので、以下の説明は、パーツ命名にいくつかのガイダンスを提供する。この柔軟性は、フレームワークパッケージの様々な応用を可能にする。しかし、複数の無関係なソフトウェアシステムが、パッケージの「独自の」パーツを互いに衝突することなく操作できるというシナリオを可能にするため、フレームワークが設計されたことを認識することが重要である。これを可能にするため、遵守されればこれを可能にする一定のガイドラインが提供される。

ここで与えられるガイドラインは、パーツ命名衝突の発生を最低限に抑え、または少なくとも減少させ、衝突が発生した場合、それに対処するためのメカニズムについて説明する。パッケージ内のパーツを作成するライタは、パッケージ内の既存パーツとの衝突を検出し、それに対処するステップを踏まなければならない。名前衝突が発生した場合、ライタは、むやみに既存パーツを置き換えることはできない。

パッケージが単一のライタによって操作されることが保証されている状況では、そのライタは、これらのガイドラインから逸脱することができる。しかし、複数の独立したライタがパッケージを共有する可能性がある場合、すべてのライタは、これらのガイドラインを遵守しなければならない。しかし、どのような場合でも、すべてのライタがこれらのガイドラインを遵守することが推奨される。

・既存のコンテナにパーツを追加するライタは、パーツをルートまたは既存フォルダに直接置くのではなく、命名階層の新規「フォルダ」にパーツを追加する。こうすることで、名前衝突の可能性は、パーツ名の最初のセグメントに限定される。この新規フォルダ内で生成されるパーツは、既存パーツと衝突するおそれなしに、命名されることができる。
・フォルダにとって「好ましい」名前が既存パーツによってすでに使用されている場合、ライタは、代替フォルダ名を選択するためのいくつかの戦略を採用しなければならない。ライタは、利用可能なフォルダ名が見出されるまで、好ましい名前に数字を追加する戦略を使用すべきである（数回繰り返しても成功しない場合、おそらくＧＵＩＤを用いる）。
・この方針の１つの帰結は、リーダが「マジック（ｍａｇｉｃ）」または「周知（ｗｅｌｌ ｋｎｏｗｎ）」パーツ名を介してパーツを見つけようと試みてはならないことである。代わりに、ライタは、自らが作成した各フォルダ内の少なくとも１つのパーツとのパッケージ関係を作成しなければならない。リーダは、パーツを見つけるために、周知の名前に依存するのではなく、これらのパッケージ関係を使用しなければならない。
・リーダは、（前述のパッケージ関係の１つを介して）フォルダ内の少なくとも１つのパーツを見つけた後、他のパーツを見つけるため、そのフォルダ内で周知パーツ名についての規約を使用することができる。

ドライバ
本明細書で説明されるファイルフォーマットは、異なるアプリケーション、異なる文書タイプによって使用されることができ、それらの多くは、衝突する使用法や、衝突するフォーマットなどを有する。１つまたは複数のドライバ（ｄｒｉｖｅｒ）は、ファイルフォーマットの差や、異なる通信プロトコルなど、様々な衝突を解決するために使用される。例えば、異なるファイルフォーマットは、ルースファイルおよび複合ファイル（ｃｏｍｐｏｕｎｄ ｆｉｌｅ）を含み、異なる通信プロトコルは、ｈｔｔｐ、ネットワーク、および無線プロトコルを含む。ドライバのグループは、様々なファイルフォーマットおよび通信プロトコルを単一のモデルに抽象化する。複数のドライバが、異なるシナリオ、異なる顧客要求、異なる物理構成などに対して提供されることができる。

関係
パッケージ内のパーツは、そのパッケージ内の他のパーツへの参照を含むことができる。しかし、一般に、これらの参照は、パーツのコンテンツタイプに特有の方法で、すなわち、恣意的なマークアップまたはアプリケーション特有の符号化で、参照側パーツの内部で表現される。これは事実上、そのような参照を含むパーツのコンテンツタイプを理解しないリーダから、パーツ間の内部リンケージを隠蔽する。

（リーチパッケージセクションで説明される固定ペイロードマークアップなどの）共通コンテンツタイプであっても、リーダは、他のパーツへの参照を発見し解決するため、パーツ内のすべてのコンテンツを解析する必要がある。例えば、文書を１度に１ページ印刷する印刷システムを実装する場合、特定のページ内に含まれるピクチャおよびフォントを識別することが望ましいことがある。既存システムは、ページ毎にすべての情報を解析しなければならないが、それだと時間の浪費になり得るうえ、各ページの言語も理解しなければならず、（例えば、ある装置に到る途中にあるプロセッサのパイプラインを文書が通過する際に文書に対して中間処理を実行する）ある種の装置またはリーダを用いる場合、そのような状況にはなり得ない。代わりに、本明細書で説明されるシステムおよび方法は、パーツ間の関係を識別し、それらの関係の性質を記述するため、関係（ｒｅｌａｔｉｏｎｓｈｉｐ）を使用する。関係言語（ｒｅｌａｔｉｏｎｓｈｉｐ ｌａｎｇｕａｇｅ）は、複数の異なる言語の知識を必要とせずにリーダが関係を理解できるように、単純であり、１度だけ定義される。一実施形態では、関係は、個々のパーツとしてＸＭＬで表現される。各パーツは、そのパーツがソースである関係を含む関連する関係パーツを有する。

例えば、表計算アプリケーションは、このフォーマットを使用し、異なる表計算をパーツとして保存する。表計算言語について何も知らないアプリケーションでも、依然として、表計算に関連する様々な関係を発見することができる。例えば、アプリケーションは、表計算内のイメージおよび表計算に関連するメタデータを発見することができる。例示的な関係スキーマが以下に提示される。

このスキーマは、「relationships」と呼ばれる要素と、「relationship」と呼ばれる要素の、２つのＸＭＬ要素を定義する。この「relationship」要素は、本明細書で説明されるような単一の関係を記述するために使用され、以下のアトリビュート、すなわち、（１）ソースパーツが関係するパーツを表す「target」と、（２）関係のタイプまたは性質を表す「name」を有する。「relationships」要素は、０またはより多くの「relationship」要素を保持できるように定義され、単純にこれらの「relationship」要素を一緒に集めてユニットにするのに役立つ。

本明細書で説明されるシステムおよび方法は、「関係」と呼ばれるこれらの問題を解決するためのより高水準のメカニズムを導入する。関係は、パッケージ内のソースパーツとターゲットパーツの間のコネクションの種類を表すための追加の方法を提供する。関係は、コンテンツ特有のスキーマから独立し、解決がより高速になるように、パーツ内のコンテンツを調べることなく直接「発見可能な」パーツ間のコネクションを作成する。加えて、これらの関係は、プロトコル独立である。様々な異なる関係が、特定のパーツに関連付けられることができる。

関係は、パーツを修正することなくパーツを関係付けることを可能にするという、第２の重要な機能を提供する。時には、この情報は、「注釈付けされる」パーツのコンテンツタイプが与えられた情報をアタッチ（ａｔｔａｃｈ）する方法を定めない場合、「アノテーション（ａｎｎｏｔａｔｉｏｎ）」の形式で提供される。潜在的な例は、アタッチされる記述的メタデータ、プリントチケット（ｐｒｉｎｔ ｔｉｃｋｅｔ）、および真のアノテーションを含む。最後に、いくつかのシナリオは、例えば、パーツが暗号化され、復号できない場合、またはパーツがデジタル的に署名され、パーツを変更すると署名が無効になる場合に、特に既存パーツを修正することなく、既存パーツに情報がアタッチされることを必要とする。別の例では、ユーザが、ＪＰＥＧイメージファイルにアノテーションをアタッチしたいと望むこともあろう。ＪＰＥＧイメージフォーマットは、現在、アノテーションを識別するためのサポートを提供しない。このユーザの望みを受け入れるようＪＰＥＧフォーマットを変更することは、実際的ではない。しかし、本明細書で説明されるシステムおよび方法は、ＪＰＥＧイメージファイルを修正することなく、ユーザがＪＰＥＧファイルにアノテーションを提供することを可能にする。

一実施形態では、関係は、関係パーツ内でＸＭＬを使用して表される。１つまたは複数の関係のソースであるコンテナ内の各パーツは、関連する関係パーツを有する。この関係パーツは、（コンテンツタイプapplication/PLACEHOLDERを使用してＸＭＬで表現される）そのソースパーツ用の関係の一覧を保持する。

添付の図４は、（FixedPanelと類似する）「スパイン（ｓｐｉｎｅ）」パーツ４０２が３つのページ４０６、４０８、および４１０を一緒にバインドする環境４００を示している。スパインによって一緒にバインドされる１組のページは、関連する「プリントチケット」４０４を有する。加えて、ページ２は、独自のプリントチケット４１２を有する。スパインパーツ４０２からそのプリントチケット４０４へのコネクション、およびページ２からそのプリントチケット４１２へのコネクションは、関係を使用して表される。図４の構成では、スパインパーツ４０２は、以下の例に示されるように、スパインをticket1に結び付ける関係を含む関連する関係パーツを有する。

関係は、単一の<Relationships>要素内にネストされた<Relationship>要素を使用して表される。これらの要素は、http://mmcfrels (PLACEHOLDER)名前空間内で定義される。上の例示的なスキーマ、および関連する説明、例えば関係を参照されたい。

relationship要素は、以下の追加のアトリビュートを有する。

Nameアトリビュートは、必ずしも実際のアドレスである必要はない。異なるタイプの関係は、それらの名前によって識別される。これらの名前は、ＸＭＬ名前空間用に名前空間が定義されるのと同じ方法で定義される。具体的には、インターネットドメイン名空間にならって付けられた名前を使用することによって、非連携当事者は、ＸＭＬ名前空間の場合に可能なように、非衝突の関係名を安全に作成することができる。

関係パーツは、他の関係に参加することを許可されない。しかし、それは、他のすべての意味において、第１のクラスのパーツである（例えば、それは、ＵＲＩアドレッシング可能であり、オープン、リード、デリートされ得るなど）。関係は、通常、パッケージ外部のものを指さない。関係ターゲットを識別するために使用されるＵＲＩは、一般に、ＵＲＩスキームを含まない。

パーツおよび関連する関係パーツは、命名規約によって結び付けられる。この例では、スパイン用の関係パーツは、/content/_rels/spine.xml.relsに保存され、ページ２用の関係パーツは、/content/_rels/p2.xml.relsに保存される。ここでは、２つの特別な命名規約が使用されることに留意されたい。第１に、名前階層内の与えられた「フォルダ」内のいくつかの（他の）パーツ用の関係パーツは、（関係を識別するための）_relsと呼ばれる「サブフォルダ」内に保存される。第２に、この関係保持パーツの名前は、元のパーツの名前に.rels拡張子を追加することによって形成される。特定の実施形態では、関係パーツは、コンテンツタイプapplication/xml+relationshipsPLACEHOLDERに属する。

関係は、２つのパーツ間の有向コネクション（ｄｉｒｅｃｔｅｄ ｃｏｎｎｅｃｔｉｏｎ）を表す。関係が表される方法のため、（任意の与えられたパーツ用の関係パーツを見つけるのはきわめて容易なので）ソースパーツから関係を辿る（ｔｒａｖｅｒｓｅ）ことが効率的になる。しかし、（パーツへのすべての関係を見つける方法は、コンテナ内のすべての関係を調べることであるので）関係のターゲットから関係を辿って戻ることは効率的にならない。

関係の後方への辿りを可能にするため、新しい関係が、他の（辿り得る）方向を表すために使用される。これは、関係のタイプの設計者が使用できるモデル化技法である。上記の例に従うと、ticket1がアタッチされたスパインを見つることができることが重要である場合、以下のような、チケットからスパインを結び付ける第２の関係が使用される。

パッケージ関係
「パッケージ関係」は、パッケージ内の周知パーツを見つけるために使用される。この方法は、パッケージ内のパーツを見つけるのに命名規約に依存することを回避し、異なるペイロード内の同一パーツ名の間で衝突が起こらないよう保証する。

パッケージ関係は、そのターゲットはパーツであるが、そのソースはパーツではなく、ソースは全体としてのパッケージである特殊な関係である。「周知」パーツを有することは、実際には、そのパーツを見つけるのに役立つ「周知」関係名を有することである。これは、関係が非連携当事者によって命名されることを可能にする明確に定義されたメカニズムが存在するために機能するが、一方、ある実施形態は、パーツ名用のそのようなメカニズムを含まず、それらの実施形態は、１組のガイドラインに制限される。パッケージ関係は、パッケージ関係パーツ内で見つけられ、関係パーツ用の標準的な命名規約を使用して命名される。したがって、それは「/_refs/.rels」と命名される。

このパッケージ関係内の関係は、周知パーツを見つける際に役に立つ。

開始パーツ
パッケージレベルの周知のパーツの一例は、パッケージ「開始」パーツである。これは、パッケージがオープンされるときに一般に処理されるパーツである。それは、パッケージ内に保存される文書コンテンツの論理的ルートを表す。パッケージの開始パーツは、周知のパッケージ関係を辿ることによって探し出される。一例では、この関係は、http://mmcf-start-part-PLACEHOLDERという名前を有する。

構成パーツ：セレクタおよびシーケンス
説明されるフレームワークは、パーツからより高次の構造を構築するための２つのメカニズム、セレクタ（ｓｅｌｅｃｔｏｒ）およびシーケンス（ｓｅｑｕｅｎｃｅ）を定める。

セレクタは、複数の他のパーツから「選択する」パーツである。例えば、セレクタパーツは、文書の英語版を表現するパーツと文書のフランス語版を表現するパーツのどちらかを「選択する」ことができる。シーケンスは、複数の他のパーツを「順序付ける」パーツである。例えば、シーケンスパーツは、５ページ分の文書を表現するパーツと１０ページ分の文書を表現するパーツの２つのパーツを（線形に順序付けて）組み合わせることができる。

これら２つのタイプの構成パーツ（ｃｏｍｐｏｓｉｔｉｏｎ ｐａｒｔ）（シーケンスおよびセレクタ）、ならびにそれらをまとめる規則は、構成モデル（ｃｏｍｐｏｓｉｔｉｏｎ ｍｏｄｅｌ）を構成する。構成パーツは、例えば、２つの構成のどちらかを選択するセレクタを有することができるように、他の構成パーツを構成することができる。一例として、図５について考察すると、図５は、英語表現とフランス語表現の両方を含む財務報告書の一例を示している。これらの表現は各々、序文（カバーページ）と、それに続く財務（表計算）からさらに構成される。この例では、セレクタ５００は、報告書の英語表現とフランス語表現のどちらかを選択する。英語表現が選択された場合、シーケンス５０２が、英語の序文パーツ５０６と英語の財務パーツ５０８とを順序付ける。あるいは、フランス語表現が選択された場合、シーケンス５０４が、フランス語の序文パーツ５１０とフランス語の財務パーツ５１２とを順序付ける。

構成パーツＸＭＬ
例示および説明される実施形態では、構成パーツは、すべてが共通構成名前空間から引き出される僅かな数のＸＭＬ要素を使用して記述される。一例として、以下のものについて考察する。

一例として、以下に示すのは、上の図５の例に対するＸＭＬである。

このＸＭＬでは、MainDocument.xmlが、パッケージ内のパーツ全体を表現し、「item」タグによってカプセル化される異なるアイテム、すなわち、「EnglishRollup.xml」と「FrenchRollup.xml」の間で選択が行われることを、「selection」タグによって示す。

EnglishRollup.xmlおよびFrenchRollup.xmlは、「sequence」タグがあることによって、それぞれの「item」タグによってカプセル化されるそれぞれのアイテムを互いに順序付けるシーケンスである。

したがって、簡単なＸＭＬ文法が、セレクタおよびシーケンスを記述するために提供される。この構成ブロック内の各パーツは、組み立てられて、選択または順序付けのどちらか一方の操作を実行する。パーツの階層を使用することによって、選択およびシーケンスの異なる堅牢な集まりが構築され得る。

構成ブロック
パッケージの構成ブロック（ｃｏｍｐｏｓｉｔｉｏｎ ｂｌｏｃｋ）は、パッケージの開始パーツから到達可能なすべての構成パーツ（セレクタまたはシーケンス）の組を含む。パッケージの開始パーツが、セレクタでもシーケンスでもない場合、構成ブロックは、空と見なされる。パッケージの開始パーツが、構成パーツである場合、それらの構成パーツ内の子<item>は、構成パーツの有向非循環グラフ（ｄｉｒｅｃｔｅｄ， ａｃｙｃｌｉｃ ｇｒａｐｈ）を生成するため、再帰的に辿られる。このグラフが構成ブロックである（そして、この実施形態によれば、パッケージが有効であるためには、それは非循環でなければならない）。

構成セマンティクスの決定
上で相対的に分かり易いＸＭＬ文法を確立したので、以下の説明は、コンテンツタイプに基づいて選択が行われ得るように情報を表す方法について説明する。すなわち、上で説明されたＸＭＬは、リーダが構成内に一緒にまとめられたパーツを探し出せるようにする十分な情報を提供するが、リーダが構成の性質についてより多くを知るのに役立つ十分な情報を提供しない。例えば、２つのパーツを構成する選択が与えられた場合、どの基準（例えば、言語、用紙サイズなど）に基づいて選択を行うべきかを、リーダはどのように知るのだろう？ 答えは、これらの規則は、構成パーツのコンテンツタイプに関連付けられるというものである。したがって、言語に基づいて表現の間で選択するために使用されるセレクタパーツは、用紙サイズに基づいて表現の間で選択するセレクタパーツとは異なる関連コンテンツタイプを有する。

汎用フレームワークは、これらのコンテンツタイプのために汎用形式を定義する。

これらのコンテンツタイプ内のSOMETHINGは、例えば、ページサイズ、色、言語、リーダ装置上の常駐ソフトウェアなど、選択または順序付けの性質を表す語によって置き換えられる。このフレームワークでは、その場合、すべての種類のセレクタおよびシーケンスを作り出すことができ、各々は、非常に異なるセマンティクスを有することができる。

説明されるフレームワークは、すべてのリーダまたは読み取り装置が理解しなければならないセレクタおよびシーケンスのための以下の周知のコンテンツタイプも定める。

一例として、以下について考察する。パッケージがページを有する文書を含み、そのページの中ほどにビデオが現れるエリアがあると仮定する。この例では、ページのビデオパーツは、Ｑｕｉｃｋｔｉｍｅビデオの形式のビデオを含むことができる。このシナリオでの１つの問題は、Ｑｕｉｃｋｔｉｍｅビデオが普遍的には理解されないことである。しかし、このフレームワークおよびより詳細には以下で説明されるリーチパッケージフォーマットによれば、普遍的に理解されるイメージフォーマットのＪＰＥＧが存在すると仮定する。上で説明された文書を含むパッケージを生成する場合、プロデューサは、ビデオをパッケージの一部として定義することに加えて、ユーザのコンピュータがＱｕｉｃｋｔｉｍｅビデオを理解するソフトウェアを有する場合にはＱｕｉｃｋｔｉｍｅビデオが選択され、それ以外の場合にはＪＰＥＧイメージが選択されるように、ページ用のＪＰＥＧイメージを定義し、SupportedContentTypeセレクタを差し挟む。

したがって、上で説明されたように、フレームワークレベルのセレクタおよびシーケンスコンポーネントは、この例ではＸＭＬで定義される堅牢な階層が構築されることを可能にする。加えて、セレクタおよびシーケンスの挙動をコンテンツタイプを使用して識別する明確に定義された方法が存在する。加えて、一実施形態によれば、汎用フレームワークは、コンシューマ（例えば、リーダまたは読み取り装置）が何を理解し、何を理解しないかに基づいたパッケージの処理および利用を可能にする、事前定義された１つの特殊なコンテンツタイプを含む。

他の構成パーツのコンテンツタイプは、その例が以下で説明される類似の規則を使用して定義されることができる。

記述的メタデータ
一実施形態によれば、記述的メタデータパーツは、パッケージのリーダがプロパティの値を高い信頼度で発見することを可能にするプロパティの値を保存する方法を、パッケージのライタまたはプロデューサに提供する。これらのプロパティは、一般に、全体としてのパッケージについて、およびコンテナ内の個別パーツについての追加情報を記録するために使用される。例えば、パッケージ内の記述的メタデータパーツは、パッケージの作成者、キーワード、要約などの情報を保持することができる。

例示および説明される実施形態では、記述的メタデータは、ＸＭＬで表現され、周知のコンテンツタイプを有するパーツ内に保存され、周知の関係タイプを使用して見出されることができる。

記述的メタデータは、メタデータプロパティ（ｍｅｔａｄａｔａ ｐｒｏｐｅｒｔｙ）を保持する。メタデータプロパティは、プロパティ名と、１つまたは多くのプロパティ値とによって表現される。プロパティ値は、各データタイプが単一のＸＭＬ ｑｎａｍｅによって記述されるように、単純なデータタイプを有する。記述的メタデータが単純なタイプを有するという事実は、パッケージ内に複雑なＸＭＬタイプを有するデータを保存できないことを意味しない。この場合、完全なＸＭＬパーツとして情報を保存しなければならない。これが行われる場合、単純なタイプだけを使用することに関するすべての制約は取り除かれるが、「フラットな」記述的メタデータプロパティ値モデルの単純性は失われる。

プロパティ値の組を定義する汎用メカニズムに加えて、このメカニズムを使用して保存される、特別な明確に定義された文書コアプロパティ（ｄｏｃｕｍｅｎｔ ｃｏｒｅ ｐｒｏｐｅｒｔｙ）の組が存在する。これらの文書コアプロパティは、普通は文書を記述するために使用され、タイトル、キーワード、作成者などのようなプロパティを含む。

最後に、これらの文書コアプロパティを保持するメタデータパーツは、文書コアプロパティに加えて、追加のカスタム定義されたプロパティも保持することができる。

メタデータフォーマット
一実施形態によれば、記述的メタデータパーツは、コンテンツタイプを有し、以下の規則に従って関係によってターゲットとされる。

以下のＸＭＬパターンは、一実施形態による記述的メタデータを表すために使用される。マークアップの各構成要素についての詳細は、サンプルに関する表に与えられている。

文書コアプロパティ
以下は、プロパティの名前、プロパティタイプ、および説明を含む文書コアプロパティの表である。

物理モデル
物理モデルは、パッケージがライタおよびリーダによって使用される様々な方法を定める。このモデルは、ライタ（ｗｒｉｔｅｒ）、リーダ（ｒｅａｄｅｒ）、およびそれらの間のパイプ（ｐｉｐｅ）という、３つの構成要素に基づいている。図６は、パッケージについて通信するために協働するライタとリーダのいくつかの例を示している。

パイプは、ライタからリーダまでデータを伝送する。多くのシナリオでは、パイプは、ローカルファイルシステムからパッケージを読むためにリーダが行うＡＰＩコールを含むだけとすることができる。これは直接アクセス（ｄｉｒｅｃｔ ａｃｃｅｓｓ）と呼ばれる。

しかし、しばしば、リーダとライタは、何らかのタイプのプロトコルを介して、互いに通信しなければならない。この通信は、例えば、プロセス境界を越えて、またはサーバとデスクトップコンピュータの間で発生する。これはネットワークアクセス（ｎｅｔｗｏｒｋｅｄ ａｃｃｅｓｓ）と呼ばれ、パイプの通信特性（具体的には、速度および要求待ち時間）のため重要である。

最大性能を可能にするため、物理パッケージ設計は、アクセススタイル（ａｃｃｅｓｓ ｓｔｙｌｅ）、レイアウトスタイル（ｌａｙｏｕｔ ｓｔｙｌｅ）、および通信スタイル（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｔｙｌｅ）という、３つの重要な領域におけるサポートについて考察しなければならない。

アクセススタイル
ストリーミング消費
ネットワークアクセスを使用するライタとリーダの間の通信は瞬時的ではないので、パッケージの漸進的な生成と消費を可能にすることが重要である。特に、パッケージのすべてのビットがパイプを介して送り届けられる前に、リーダが受信したデータ（例えば、パーツ）の解釈および処理を開始することができるように、どの物理パッケージフォーマットも設計されることが、この実施形態によれば推奨される。この機能は、ストリーミング消費（ｓｔｒｅａｍｉｎｇ ｃｏｎｓｕｍｐｔｉｏｎ）と呼ばれる。

ストリーミング生成
ライタは、パッケージの生成を開始したとき、パッケージ内に何を入れるかについて常に知っているわけではない。一例として、アプリケーションは、プリントスプールファイルパッケージを構築し始めたとき、ページがいくつパッケージ内に入れられる必要があるかについて知ることはできない。別の例として、報告書を動的に生成するサーバ上のプログラムは、報告書を完全に生成するまで、報告書がどれだけの長さであるか、または報告書がピクチャをいくつ有するかについて理解することはできない。このようなライタを可能にするため、物理パッケージは、他のパーツがすでに追加された後で、ライタがパーツを動的に追加できるようにすべきである（例えば、ライタは、書き込みを開始したとき、パーツをいくつ生成するかについて前もって明示するよう要求されてはならない）。加えて、物理パッケージは、パーツの最終的な長さを知らなくても、ライタがそのパーツのコンテンツを書き始めることができるようにすべきである。これらの要件は、一緒になって、ストリーミング生成（ｓｔｒｅａｍｉｎｇ ｃｒｅａｔｉｏｎ）を可能にする。

同時的な生成および消費
高度にパイプライン化されたアーキテクチャでは、ストリーミング消費およびストリーミング生成は、特定のパッケージに対して同時に行うことができる。物理パッケージを設計する場合、ストリーミング生成とストリーミング消費のサポートは、設計を逆方向に押しやることがあり得る。しかし、両方をサポートする設計を見出すことはしばしば可能である。パイプライン化アーキテクチャにおける利点のため、物理パッケージが同時的な生成および消費（ｓｉｍｕｌｔａｎｅｏｕｓ ｃｒｅａｔｉｏｎ ａｎｄ ｃｏｎｓｕｍｐｔｉｏｎ）をサポートすることが推奨される。

レイアウトスタイル
物理パッケージは、パーツの集まりを保持する。これらのパーツは、単純順序およびインタリーブという２つのスタイルの一方でレイアウトされることができる。単純順序を用いる場合、パッケージ内のパーツは、定められた順序でレイアウトされる。パッケージ内の第１バイトから開始し順繰りに最終バイトに到る純粋な線形方式でパッケージが送り届けられる場合、第１のパーツのすべてのバイトが最初に到着し、第２のパーツのすべてのバイトが次に到着し、以下も同様に続く。

インタリーブレイアウトを用いる場合、複数のパーツのバイトがインタリーブされ、あるシナリオにおいて、改善された性能を可能にする。インタリーブから著しい利益を得る２つのシナリオは、マルチメディア再生（例えば、映像と音声を同時に送り届ける）と、インラインリソース参照（例えば、マークアップファイルの中におけるイメージへの参照）である。

インタリーブは、インタリーブされるパーツのコンテンツを組織するための特別の規約によって処理される。パーツをピースに分割し、これらのピースをインタリーブすることによって、元のより大きなパーツを容易に再構成することを依然として可能にしながら、インタリーブの所望の結果を達成することが可能である。インタリーブがどのように機能するかを理解するため、図７は、content.xml ７０２とimage.jpeg ７０４という２つのパーツを含む簡単な例を示している。第１のパーツcontent.xmlは、ページのコンテンツを記述し、そのページの中に、ページ上に現れるべきイメージ（image.jpeg）への参照が存在する。

インタリーブがなぜ有益なのかを理解するため、図８に示されるように、単純順序を使用してこれらのパーツがパッケージ内でどのように配置されるかについて考察する。このパッケージを処理（およびバイトを順次受信）するリーダは、image.jpegだけでなく、すべてのcontent.xmlパーツを受信するまで、ピクチャを表示することができない。状況によっては（例えば、小規模もしくは簡単なパッケージ、または高速通信リンク）、これは問題ではないかもしれない。他の状況では（例えば、content.xmlが非常に大きい、または通信リンクが非常に低速である場合）、イメージを取得するためにすべてのcontent.xmlパーツを読み通す必要があると、許容し得ないパフォーマンスになったり、またはリーダシステムに過度のメモリ要求が行われたりする。

理想的性能により近い性能を達成するため、content.xmlパーツを分割し、その間のピクチャが参照される場所の直後にimage.jpegパーツを挿入できることが好ましい。リーダが参照に遭遇した後すぐに、イメージデータが続くのであれば、こうすることで、リーダはより早くイメージを処理し始めることができるようになる。これは、例えば、図９に示されるパッケージレイアウトを生成する。性能上の利益のため、物理パッケージがインタリーブをサポートすることがしばしば望ましい。使用される物理パッケージの種類に応じて、インタリーブはサポートされても、されなくてもよい。異なる物理パッケージは、インタリーブの内部表現を異なるように処理することができる。物理パッケージがどのようにインタリーブを処理するかに関わらず、インタリーブは物理レベルで生じる最適化であり、物理ファイル内の複数のピースに分割されたパーツは依然として１つの論理パーツであり、ピースそれ自体はパーツでないことを忘れないことが重要である。

通信スタイル
ライタとリーダの間の通信は、パーツの順次送達（ｓｅｑｕｅｎｔｉａｌ ｄｅｌｉｖｅｒｙ）に基づくことができ、またはパーツが無秩序にアクセスされることを可能にする、パーツへのランダムアクセス（ｒａｎｄｏｍ−ａｃｃｅｓｓ）によることができる。これらの通信スタイルのどちらが利用されるかは、パイプと物理パッケージフォーマットの両方の能力に依存する。一般に、すべてのパイプは、順次送達をサポートする。物理パッケージは、順次送達をサポートしなければならない。ランダムアクセスシナリオをサポートするには、使用されるパイプと物理パッケージの両方が、ランダムアクセスをサポートしなければならない。いくつかのパイプは、ランダムアクセスを可能にし得るプロトコル（例えば、バイトレンジをサポートするＨＴＴＰ １．１）に基づいている。これらのパイプが使用されるときに最大性能を可能にするため、物理パッケージがランダムアクセスをサポートすることが推奨される。このサポートがないと、リーダは、必要なパーツが順次送り届けられるまで単純に待機する。

物理マッピング
論理パッケージングモデルは、パッケージ抽象化を定義するが、パッケージの実際のインスタンスは、パッケージのいくつかの特定の物理表現に基づいている。パッケージングモデルは、様々なトランスポート（例えば、ネットワークベースのプロトコル）にばかりでなく、物理的持続フォーマットにもマッピングされることができる。物理パッケージフォーマットは、抽象パッケージングモデルの構成要素から特定の物理フォーマット特徴へのマッピングとして記述されることができる。パッケージングモデルは、パッケージをアーカイブ、配布、またはスプールするために、どの物理パッケージフォーマットが使用されるべきかを指定しない。一実施形態では、論理構造だけが指定される。パッケージは、ルースファイル、．ＺＩＰファイルアーカイブ、複合ファイル、または他の何らかのフォーマットの集まりによって「物理的に」実施されることができる。選択されたフォーマットは、ターゲットの消費装置、または装置のドライバによってサポートされる。

マッピングされる構成要素
各物理パッケージフォーマットは、以下の構成要素のためのマッピングを定義する。いくつかの構成要素は、任意選択であり、特定の物理パッケージフォーマットは、これらの任意選択構成要素をサポートしなくてもよい。

共通マッピングパターン

その特徴が部分的にパッケージングモデル構成要素と一致する多くの物理記憶フォーマットが存在する。パッケージングモデルからそのような記憶フォーマットへのマッピングを定義する際、パッケージングモデルと物理記憶媒体の間の機能の類似性を利用する一方で、物理記憶媒体に本来存在しない追加機能を提供するためにマッピングのレイヤを使用することが望ましいことがある。例えば、いくつかの物理パッケージフォーマットは、個々のパーツをファイルシステム内の個々のファイルとして保存することができる。そのような物理フォーマットでは、多くのパーツ名を直接的に同じ物理ファイル名にマッピングするのが自然である。ファイルシステムの有効なファイル名にならない文字を使用するパーツ名は、何らかの種類の回避メカニズムを必要とすることがある。

多くの場合、異なる物理パッケージフォーマットの設計者は、１つの共通のマッピング問題に直面する。共通のマッピング問題の２つの例は、任意のコンテンツタイプをパーツに関連付けるとき、およびインタリーブレイアウトスタイルをサポートするときに生じる。本明細書は、そのような共通のマッピング問題に対する共通の解決策を提案する。特定の物理パッケージフォーマットの設計者は、ここで定められる共通のマッピング解決策を使用するよう奨励されるが、それを要求されることはない。

パーツのコンテンツタイプの識別
物理パッケージフォーマットマッピングは、各パーツのコンテンツタイプを保存するためのメカニズムを定める。いくつかの物理パッケージフォーマットは、コンテンツタイプを表すためのネイティブメカニズムを有する（例えば、ＭＩＭＥの「Content-Type」ヘッダ）。そのような物理パッケージの場合、パーツのコンテンツタイプを表すため、マッピングがネイティブメカニズムを使用することが推奨される。他の物理パッケージフォーマットの場合、コンテンツタイプを表すため、他の何らかのメカニズムが使用される。これらのパッケージ内でコンテンツタイプを表すための推奨メカニズムは、ｔｙｐｅｓストリーム（ｔｙｐｅｓ ｓｔｒｅａｍ）として知られる特別に命名されたＸＭＬストリームをパッケージ内に含むことによる。このストリームはパーツではく、したがって、それ自体はＵＲＩアドレッシング可能ではない。しかし、このストリームは、パーツをインタリーブするのに使用されるのと同じメカニズムを使用して、物理パッケージ内にインタリーブされることができる。

ｔｙｐｅｓストリームは、トップレベルの「Types」要素と、１つまたは複数の「Default」および「Override」サブ要素とを有するＸＭＬを含む。「Default」要素は、パーツ名拡張子からコンテンツタイプへのデフォルトマッピングを定める。これは、ファイル拡張子はしばしばコンテンツタイプに対応するという事実を利用している。「Override」要素は、デフォルトマッピングによってカバーされない、またはデフォルトマッピングに一致しないパーツのコンテンツタイプを指定するために使用される。パッケージライタは、パーツ毎の「Override」要素の数を減らすために「Default」要素を使用することができるが、そうするよう要求はされない。

「Default」要素は、以下のアトリビュートを有する。

「Override」要素は、以下のアトリビュートを有する。

以下は、ｔｙｐｅｓストリーム内に含まれるＸＭＬの一例である。

以下の表は、パーツのサンプルリストと、上記のｔｙｐｅｓストリームによって定義された対応するコンテンツタイプを示している。

パッケージ内のあらゆるパーツについて、ｔｙｐｅｓストリームは、（ａ）１つの一致する「Default」要素、（ｂ）１つの一致する「Override」要素、または（ｃ）一致する「Default」要素と一致する「Override」要素（この場合、「Override」要素が優先される）の両方を含む。一般に、任意の与えられた拡張子に対してたかだか１つの「Default」要素と、任意の与えられたパーツ名に対してたかだか１つの「Override」要素が存在するに過ぎない。

ｔｙｐｅｓストリーム内での「Default」要素と「Override」要素の順序は重要ではない。しかし、インタリーブパッケージでは、「Default」要素と「Override」要素は、物理パッケージ内で、それらが対応するパーツの前に出現する。

インタリーブ
すべての物理パッケージが、パーツのデータストリームのインタリーブをネイティブにサポートするわけではない。一実施形態では、そのような物理パッケージへのマッピングは、パーツのインタリーブを可能にするため、このセクションで説明される汎用メカニズムを使用する。汎用メカニズムは、パーツのデータストリームを複数のピースに分割し、それらが他のパーツのピースまたはパーツ全体とインタリーブされ得ることによって機能する。パーツの個々のピースは、物理マッピング内に存在し、論理パッケージングモデルではアドレッシング可能ではない。ピースは、０サイズを有することができる。

パーツ名からパーツの個々のピースの名前への以下の一意マッピングは、リーダがピースを元の順序につなぎ合わせて、パーツのデータストリームを形成できるように定義される。

以下は、与えられたパーツ名に関するピース名を導出するための文法である。

本文法によって生成されるピース名に関して、以下の有効性制約が存在する。

・ピース番号は、０から開始する正の連続的な整数である。ピース番号は、左ゼロ詰めされることができる。
・パーツの１組のピースのうちの最後のピースは、ピース名の中で「.piece」の前に「.last」を含む。
・ピース名は、物理パッケージ内の名前へのマッピングの前に、論理パーツの名前から生成される。

必ずしもピースをその自然な順序で保存する必要はないが、そのような保存は、最適な効率性を提供することができる。インタリーブされた（ピース分割）パーツを含む物理パッケージは、非インタリーブの（１ピース）パーツも含むことができるので、以下の例は有効である。

特殊マッピング
以下は、以下の物理フォーマット、すなわち、Ｗｉｎｄｏｗｓ（登録商標）ファイルシステム内のルースファイルのための特殊マッピングを定める。

Ｗｉｎｄｏｗｓ（登録商標）ファイルシステム内のルースファイルへのマッピング
論理モデルの要素を物理フォーマットにどのようにマッピングするかをより良く理解するため、Ｗｉｎｄｏｗｓ（登録商標）ファイルシステム内のルースファイルの集まりとしてＭｅｔｒｏパッケージを表す基本的事例について考察する。論理パッケージ内の各パーツは、別個のファイル（ストリーム）に含まれる。論理モデル内の各パーツ名は、ファイルの名前に対応する。

パーツ名は、以下の表によって示されるように、有効なＷｉｎｄｏｗｓ（登録商標）ファイル名に変換される。

論理パーツ名セグメント（ＵＲＩセグメント）およびＷｉｎｄｏｗｓ（登録商標）ファイル名にとって有効な２つの文字セットが以下に与えられる。この表は、２つの重要なことを明らかにしている。

ＵＲＩをファイル名に変換する場合にエスケープする必要がある２つの有効なＵＲＩシンボルであるコロン（:）およびアスタリスク（*）が存在する。

ＵＲＩ内に存在することができない有効なファイル名シンボルである^{}[]#が存在する（それらは、インタリーブのような特殊マッピング目的で使用されることができる）。

「エスケープ」は、ファイル名で使用されることができない文字をパーツ名が含む場合に有効なファイル名文字を生成するための技法として使用される。文字をエスケープするため、カレットシンボル（＾）が使用され、その後に文字の１６進表現が続く。

abs_path（パーツ名）をファイル名にマッピングするには、
先頭の/を取り除き、
すべての/を\に変換し、
コロンおよびアスタリスク文字をエスケープする。

例えば、パーツ名/a:b/c/d*.xamlは、以下のファイル名a^25b\c\d^2a.xamlになる。

逆マッピングを実行するには、
すべての\を/に変換し、
文字列の先頭に/を追加し、
^[１６進コード]を対応する文字で置換することによって文字をアンエスケープする。

バージョニングおよび拡張性
他の技術仕様と同様に、本明細書に含まれる仕様は、将来の機能強化と共に進化することができる。この仕様の第１版の設計は、第１版に基づいて書かれたソフトウェアシステムと将来版用のソフトウェアシステムとの間での将来における文書の相互交換のための計画を含む。同様に、この仕様は、サードパーティが仕様に対する拡張機能を作成することを可能にする。そのような拡張機能は、例えば、ある特定のプリンタの機能を利用しながら、そのプリンタの存在を知らない他のリーダとの互換性を依然として保持する文書の作成を可能にする。

新しいバージョンの固定ペイロードマークアップ、またはマークアップに対するサードパーティの拡張機能を使用する文書は、リーダが挙動（例えば、あるものを視覚的にどうレンダリングするか）について適切な決定を下すことを要求する。リーダにガイダンスを与えるため、文書の作成者（または文書を生成したツール）は、それがなされなければ認識不可能な要素またはアトリビュートに遭遇するリーダのために適切な挙動を識別すべきである。リーチ文書にとって、このタイプのガイダンスは重要である。

新しいプリンタ、ブラウザ、およびその他のクライアントは、将来の機能のために様々なサポートを実装することができる。新しいバージョンまたは拡張機能を利用する文書作成者は、拡張機能のそれらのバージョンについて知らないリーダの挙動を慎重に考察しなければならない。

バージョニング名前空間
ＸＭＬマークアップ認識は、名前空間ＵＲＩに基づいている。ＸＭＬ名前空間の場合、リーダは、その名前空間で定義されたＸＭＬ要素およびＸＭＬアトリビュートのすべてを認識するか、またはすべてを認識しないことを期待される。リーダは、新しい名前空間を認識しない場合、文書内で指定されたフォールバックレンダリング（ｆａｌｌｂａｃｋ ｒｅｎｄｅｒｉｎｇ）動作を実行する必要がある。

ＸＭＬ名前空間ＵＲＩ「http://PLACEHOLDER/version-control」は、バージョン適応的（ｖｅｒｓｉｏｎ−ａｄａｐｔｉｖｅ）かつ拡張機能適応的（ｅｘｔｅｎｓｉｏｎｓ−ａｄａｐｔｉｖｅ）な固定ペイロードマークアップを作成するために使用されるＸＭＬ要素およびアトリビュートを含む。固定ペイロードは、その中にバージョニング要素を有することを要求されない。しかし、適応的コンテンツを構築するには、<ver:Compatibility.Rules>ＸＭＬ要素と<ver:AlternativeContent>ＸＭＬ要素の少なくとも一方を使用しなければならない。

この固定ペイロードマークアップ仕様は、それに関連するｘｍｌｎｓ ＵＲＩである「http://PLACEHOLDER/pdl」を有する。この名前空間を固定ペイロードにおいて使用することで、この仕様で定義された要素のみが使用されることをリーダアプリケーションに知らせる。この仕様の将来のバージョンは、独自の名前空間を有する。新しい名前空間について知っているリーダアプリケーションは、以前のバージョンで定義されたアトリビュートの要素のスーパセットをどのようにサポートすべきかを知っている。新しい名前空間について知らないリーダアプリケーションは、新しいバージョンのＵＲＩを、ＰＤＬに対する未知の拡張機能のＵＲＩであるかのように見なす。これらのアプリケーションは、一方が他方のスーパセットであるという関係が名前空間の間に存在することを知ることができない。

上位および「下位」互換性
本明細書で説明されるシステムおよび方法をサポートするアプリケーションまたは装置との関連では、互換性は、以前のバージョンの仕様または未知の拡張機能もしくはバージョンを使用して作成された文書を解析し表示するクライアントの能力によって表される。様々なバージョニングメカニズムが、「上位互換性」に対処し、以下に示されるように、クライアントの将来の実装が、仕様の下位レベル（ｄｏｗｎ−ｌｅｖｅｌ）バージョンに基づいて文書をサポートできることを可能にする。

プリンタなどの実装クライアントは、マークアップ言語の将来バージョンを使用して構築された文書を受け取った場合、利用可能なレンダリングオプションを解析し理解することができる。より古いバージョンの仕様に従って書かれたクライアントソフトウェアの、より新しいバージョンの機能を使用する文書を処理する能力は、しばしば「下位互換性」と呼ばれる。下位互換性を可能にするように書かれた文書は、「バージョン適応的」と呼ばれる。

さらに、実装クライアントは、新しい要素またはプロパティを表す未知の拡張機能を有する文書をサポートできる必要もあるので、様々なセマンティクスは、「拡張機能適応的」である文書のより一般的なケースをサポートする。

プリンタまたはビューアは、未知の拡張機能に遭遇した場合、周囲コンテンツの適応的なレンダリングに関するガイダンスのための拡張機能の使用と並んで埋め込まれた情報を探す。この適応は、未知の要素またはアトリビュートを、理解できるコンテンツで置換することを含む。しかし、適応は、未知のコンテンツを純粋に無視することを含む他の形式をとることができる。明示的なガイダンスがない場合、リーダは、マークアップ内の認識不可能な拡張機能の存在をエラー状態として取り扱うべきである。ガイダンスが提供されない場合、拡張機能は、コンテンツの理解にとって必須なものと推定される。レンダリング失敗は捕捉され、ユーザに報告される。

このモデルをサポートするため、マークアップ言語の新しい拡張されたバージョンは、名前空間において関連拡張機能を論理的にグループ化すべきである。このようにすることで、文書作成者は、最低限の数の名前空間を使用して、拡張された機能を利用することができる。

バージョニングマークアップ
拡張機能適応的な挙動をサポートするためのＸＭＬボキャブラリは、以下の要素を含む。

<Compatibility.Rules>要素
Compatibility.Rulesは、Ｘａｍｌルート要素ばかりでなく、アタッチされたアトリビュートを保持できる任意の要素にアタッチされることができる。<Compatibility.Rules>要素は、パーサが未知の要素またはアトリビュートにどのように反応するかを制御する。通常、そのようなアイテムは、エラーとして報告される。Compatibilitiy.RulesプロパティにIgnorable要素を追加することで、ある名前空間からのアイテムが無視され得ることをコンパイラに通知する。

Compatibility.Rulesは、Ignorable要素とMustUnderstand要素を含むことができる。デフォルトでは、すべての要素およびアトリビュートは、MustUnderstandであると仮定される。要素およびアトリビュートは、そのコンテナのCompatibility.RulesプロパティにIgnorable要素を追加することによって、Ignorableにされることができる。要素およびプロパティは、ネストされたコンテナの１つにMustUnderstand要素を追加することによって、再びMustUnderstandにされることができる。１つのIgnorableまたはMustUnderstandは、同じCompatibility.Rules要素内の特定の名前空間ＵＲＩを参照する。

<Compatibility.Rules>要素は、コンテナ自体のタグまたはアトリビュートではなく、コンテナのコンテンツに影響を及ぼす。コンテナのタグまたはアトリビュートに影響を及ぼすには、それのコンテナが、互換性規則を含まなければならない。Ｘａｍｌルート要素は、それがなければルート要素になるCanvasなどの要素に互換性規則を指定するために使用されることができる。Compatibility.Rules複合アトリビュート（ｃｏｍｐｏｕｎｄ ａｔｔｒｉｂｕｔｅ）は、コンテナ内の最初の要素である。

<Ignorable>要素
<Ignorable>要素は、囲われた名前空間ＵＲＩが無視できることを宣言する。アイテムは、現在のブロックまたはコンテナブロックにおいてそのアイテムの前に<Ignorable>タグが宣言されており、その名前空間ＵＲＩがパーサに知られていない場合、無視できると見なされることができる。ＵＲＩが知られている場合、Ignorableタグは無視され、すべてのアイテムが理解される。一実施形態では、Ignorableとして明示的に宣言されていないすべてのアイテムは、理解されなければならない。Ignorable要素は、<ProcessContent>要素と<CarryAlong>要素を含むことができ、それらは、要素がどのように無視されるかを修正するため、およびそのようなコンテンツが編集文書内でどのように保存されるべきかについてのガイダンスを文書編集ツールに与えるために使用される。

<Process Content>要素
<Process Content>要素は、要素が無視された場合、その要素のコンテンツが、無視された要素のコンテナに含まれるかのように処理されることを宣言する。

<ProcessContent>アトリビュート

<CarryAlong>要素
任意指定の<CarryAlong>要素は、文書が修正される場合に無視可能コンテンツが保存されるべきかどうかを文書編集ツールに知らせる。編集ツールが無視可能コンテンツを保存または廃棄する方法は、編集ツールの領域にある。複数の<CarryAlong>要素が名前空間内の同じ要素またはアトリビュートに参照する場合、指定された最後の<CarryAlong>が優先される。

<CarryAlong>アトリビュート

<MustUnderstand>要素
<MustUnderstand>は、Ignorable要素の影響を取り消す要素である。この技法は、例えば、代替コンテンツと組み合わされる場合に有益である。<MustUnderstand>要素によって定義される有効範囲の外では、その要素はIgnorableであり続ける。

<MustUnderstand>アトリビュート

<AlternateContent>要素
<AlternateContent>要素は、指定されたコンテンツのいずれかのパーツが理解されない場合に、代替コンテンツが提供されることを可能にする。AlternateContentブロックは、<Prefer>ブロックと<Fallback>ブロックの両方を使用する。<Prefer>ブロック内の何かが理解されない場合、<Fallback>ブロックのコンテンツが使用される。名前空間は、フォールバックが使用されることを示すため、<MustUnderstand>と宣言される。名前空間がIgnorableと宣言され、かつその名前空間が<Prefer>ブロック内で使用される場合、<Fallback>ブロック内のコンテンツは使用されない。

バージョニングマークアップ例
<Ignorable>の使用
この例は、初期バージョンで要素Circleを定義し、マークアップの将来バージョン（バージョン２）で導入されたCircleのOpacityアトリビュートと、マークアップのさらに後のバージョン（バージョン３）で導入されたLuminanceプロパティとを使用する、架空のマークアップ名前空間http://PLACEHOLDER/Circleを使用する。このマークアップは、バージョン１および２、さらに３以降のバージョンでロード可能である。加えて、<CarryAlong>要素は、エディタがv3:Luminanceを理解しない場合であっても、編集時にv3:Luminanceが保存されなければならないことを指定する。

<MustUnderstand>の使用
以下の例は、<MustUnderstand>要素の使用について説明する。

<MustUnderstand>要素の使用は、ルート要素内でIgnorableと宣言されていたとしても、v3:Luminanceへの参照がエラーとなる原因になる。この技法は、例えば、バージョン２で追加されたCanvasのLuminanceプロパティを代わりに使用する代替コンテンツと組み合わされる場合に有益である（以下を参照）。Canvas要素の有効範囲の外では、CircleのLuminanceプロパティは再びIgnorableになる。

<AlternateContent>の使用
要素またはアトリビュートが、<MustUnderstand>として宣言されたにもかかわらず、<AlternateContent>ブロックの<Prefer>ブロック内で理解されない場合、<Prefer>ブロックはその全体がスキップされ、<Fallback>ブロックが通常のように処理される（すなわち、遭遇されるMustUnderstandアイテムは、エラーとして報告される）。

リーチパッケージフォーマット
以降の説明では、特殊なファイルフォーマットの説明が提供される。このセクション内の個々の１次副見出しは、「リーチパッケージフォーマット概論」、「リーチパッケージ構造」、「固定ペイロードパーツ」、「FixedPageマークアップの基本」、「固定ペイロード要素およびプロパティ」、および「FixedPageマークアップ」を含む。各１次要副見出しは、１つまたは複数の関連副見出しを有する。

リーチパッケージフォーマット概論
上では例示的なフレームワークについて説明したが、以降の説明は、上で説明されたツールを利用して提供される特殊なフォーマットについての説明である。以下の説明は、１つの例示的なフォーマットを構成するに過ぎず、特許請求される主題の用途を限定する意図はないことを認識および理解されたい。

この実施形態によれば、単一のパッケージは、複数のペイロードを含むことができ、各ペイロードは、文書の異なる表現として機能する。ペイロード（ｐａｙｌｏａｄ）は、パーツの集まりであり、識別可能な「ルート」パーツと、そのルートパーツの有効な処理のために必要とされるすべてのパーツとを含む。例えば、ペイロードは、文書の固定表現、リフロー可能（ｒｅｆｌｏｗａｂｌｅ）表現、または任意の表現とすることができる。

以下の説明は、固定ペイロード（ｆｉｘｅｄ ｐａｙｌｏａｄ）と呼ばれる特定の表現を定義する。固定ペイロードは、FixedPanelマークアップを含むルートパーツであり、FixedPanelマークアップは、FixedPageパーツを参照する。一緒になって、これらは、複数ページ文書の正確なレンダリングについて記述する。

少なくとも１つの固定ペイロードを保持し、以下で説明される他の規則に従うパッケージは、リーチパッケージ（ｒｅａｃｈ ｐａｃｋａｇｅ）と呼ばれることが知られている。リーチパッケージのリーダおよびライタは、リーチパッケージフォーマットの仕様に基づく独自のパーサおよびレンダリングエンジンを実装することができる。

リーチパッケージの特徴
説明される実施形態によれば、リーチパッケージは、文書の配布、アーカイブ、およびレンダリングに関して情報作業者が有する要件に対処する。知られたレンダリング規則を使用して、リーチパッケージは、クライアント装置またはアプリケーションを特定のオペレーティングシステムまたはサービスライブラリに結び付けることなく、それらが保存されたフォーマットから明確かつ正確に再生または印刷されることができる。加えて、リーチペイロードは、中立的なアプリケーション独立の方法で表現されるので、文書は、一般に、パッケージを作成するのに使用されたアプリケーションを用いずに、見られかつ印刷されることができる。この能力を提供するため、固定ペイロードという概念が、リーチパッケージに導入され、含まれる。

説明される実施形態によれば、固定ペイロードは、一定数のページを有し、改ページは、常に同じである。固定ペイロード内のページ上のすべての要素のレイアウトは、事前に決定される。各ページは、固定のサイズと向きを有する。したがって、レイアウト計算が消費側で実行される必要はなく、コンテンツは、単純にレンダリングすることができる。これは、グラフィックスばかりでなく、正確な印刷配置を用いて固定ペイロード内で表現されるテキストにも同様に適用される。ページのコンテンツ（テキスト、グラフ、イメージ）は、強力ではあるが単純なビジュアルプリミティブ（ｖｉｓｕａｌ ｐｒｉｍｉｔｉｖｅ）の組を使用して記述される。

リーチパッケージは、ページを組織するための様々なメカニズムをサポートする。１グループのページは、一緒に次々と「接着（ｇｌｕｅ）」されて「FixedPanel」にされる。このページのグループは、従来の複数ページ文書におおよそ等しい。FixedPanelは、その後さらに、構成（ｃｏｍｐｏｓｉｔｉｏｎ）、すなわち、「複合」文書を組み立てるために順序および選択を構築するプロセスに参加することができる。

例示および説明される実施形態では、リーチパッケージは、例えば、１組のFixedPanelを一緒に接着して単一のより大きな「文書」にするために使用され得る、FixedPanel順序と呼ばれる特別な種類の順序をサポートする。例えば、２ページ分のカバーメモ（FixedPanel）と２０ページ分の報告書（FixedPanel）という異なる出所をもつ２つの文書を一緒に接着することを想像されたい。

リーチパッケージは、「同じ」コンテンツの代替表現を含む文書パッケージを構築するときに使用され得る複数の特殊なセレクタをサポートする。特に、リーチパッケージは、言語、色機能、およびページサイズに基づいた選択を可能にする。したがって、例えば、文書の英語表現とフランス語表現の間で選択を行うセレクタを使用する２カ国語文書を有することができる。

リーチパッケージにおける構成のためのセレクタおよびシーケンスのこれらの簡単な使用に加えて、セレクタおよびシーケンスが、さらなるセレクタおよびシーケンスを参照することもでき、その結果、強力な集団的階層（ａｇｇｒｅｇａｔｅ ｈｉｅｒａｒｃｈｉｅｓ）が構築され得ることに留意することが重要である。この実施形態による、何ができ、何ができないのかについての正確な規則は、以下の「リーチパッケージ構造」と題するセクションで詳述される。

加えて、リーチパッケージは、固定ペイロードではないが、その代わり、文書のより機能豊富でおそらく編集可能な表現である追加のペイロードを含むことができる。これは、パッケージが、視覚的に正確で、編集アプリケーションを用いなくても見られ得る表現だけでなく、エディタアプリケーション内で適切に働く機能豊富で編集可能な文書を含むことを可能にする。

最後に、この実施形態によれば、リーチパッケージは、プリントチケット（ｐｒｉｎｔ ｔｉｃｋｅｔ）として知られるものをサポートする。プリントチケットは、パッケージが印刷されるときに使用されるべき設定を提供する。これらのプリントチケットは、十分な柔軟性を達成するため、様々な方法でアタッチされることができる。例えば、プリントチケットは、パッケージ全体に「アタッチ」されることができ、その設定は、パッケージ全体に影響を及ぼす。プリントチケットはさらに、構造内のより低いレベルで（例えば、個々のページに）アタッチされることができ、これらのプリントチケットは、それらがアタッチされたパーツを印刷するときに使用されるオーバライド設定を提供する。

リーチパッケージ構造
上で説明されたように、リーチパッケージは、「固定」ページ、FixedPanel、構成、プリントチケットなどを含む１組の機能をサポートする。これらの機能は、パッケージモデルの中核コンポーネントであるパーツおよび関係を使用して、パッケージ内で表される。このセクションおよび関連副セクションでは、これらのパーツおよび関係のすべてがどのように組み立てられ、関係付けられなければならないかなどについての説明を含む、「リーチパッケージ」の完全な定義が提供される。

リーチパッケージ構造の概要
図１０は、例示的なリーチパッケージと、この実施形態における、パッケージを構成でき、またはパッケージ内で見出され得る各有効タイプのパーツとを示している。すぐ下に与えられた表は、各有効パーツタイプを列挙し、各々の説明を提供する。

リーチパッケージは、「ビューアンドプリントエニフェア（ｖｉｅｗ ａｎｄ ｐｒｉｎｔ ａｎｙｗｈｅｒｅ）」文書となるように設計されるので、リーチパッケージのリーダおよびライタは、何が「有効な」リーチパッケージを構成するかについての共通の明確に定義された予想を共有しなければならない。「有効な」リーチパッケージの定義を提供するため、少数の概念が最初に以下で定義される。

リーチ構成パーツ
リーチパッケージは、構成ブロックをパッケージの開始パーツから辿ることによって「発見可能」である少なくとも１つのFixedPanelを含まなければならない。説明される実施形態によれば、発見プロセスは、以下のアルゴリズムに従う。

・パッケージの開始パーツから始めて、構成パーツのグラフを再帰的に辿る。
・この辿りを実行しているとき、（以下で説明される）リーチ構成パーツ（ｒｅａｃｈ ｃｏｍｐｏｓｉｔｉｏｎ ｐａｒｔ）である構成パーツに１度だけ入る。
・グラフの辺においてすべての終端節点（出て行く弧のない節点）を見つけ出す。

これらの終端節点は、リーチペイロードルート（ｒｅａｃｈ ｐａｙｌｏａｄ ｒｏｏｔ）と呼ばれる１組のパーツを（その<item>要素を介して）参照する。

固定ペイロード
固定ペイロードは、そのルートパーツがFixedPanelパーツであるペイロードである。例えば、図１０の固定ペイロードの各々は、そのルートパーツとして、関連するFixedPanelパーツを有する。ペイロードは、FixedPanelの有効な処理にとって必要なすべてのパーツの完全な閉包（ｆｕｌｌ ｃｌｏｓｕｒｅ）を含む。これらは、
・FixedPanel自体、
・FixedPanel内から参照されるすべてのFixedPage、
・ペイロード内のいずれかのFixedPageによって（直接またはセレクタを介して間接に）参照されるすべてのイメージパーツ、
・ペイロード内のいずれかのFixedPage内で使用されるイメージブラシから直接または間接に参照される（以下で説明される）リーチセレクタ（ｒｅａｃｈ ｓｅｌｅｃｔｏｒ）、
・ペイロード内のいずれかのFixedPageによって参照されるすべてのフォントパーツ、
・固定ペイロード内のいずれかのパーツにアタッチされるすべての記述的メタデータパーツ、および
・固定ペイロード内のいずれかのパーツにアタッチされる任意のプリントチケットを含む。

リーチパッケージのための有効性規則
説明される実施形態に従って「有効な」リーチパッケージを記述する適合規則が、上の定義を適所で用いて、今から説明される。

・リーチパッケージは、上で説明されたパッケージ関係の標準メカニズムを使用して定義された開始パーツをもたなければならない。

・リーチパッケージの開始パーツは、セレクタまたはシーケンスのどちらかでなければならない。
・リーチパッケージは、FixedPanelである少なくとも１つのリーチペイロードルートをもたなければならない。
・PrintTicketパーツは、任意の構成パーツ、FixedPanelパーツ、またはFixedPanel内で識別可能な任意のFixedPageパーツにアタッチされることができる。現在の例では、これは、http://PLACEHOLDER/HasPrintTicketRel関係を介して行われる。
・PrintTicketは、これらのパーツのいずれかまたはすべてにアタッチされることができる。
・任意の与えられたパーツは、たかだか１つのPrintTicketしかアタッチされてはならない。
・記述的メタデータパーツは、パッケージ内の任意のパーツにアタッチされることができる。
・FixedPayload内のあらゆるFontオブジェクトは、「Fontパーツ」セクションで定義されるフォントフォーマット規則を満たさなければならない。
・固定ペイロード内の任意のFixedPage内からのイメージへの参照は、レンダリングされる実際のイメージパーツを見つけるために（潜在的には他のセレクタを再帰的に介して）選択を行うことができるセレクタを指し示さなければならない。
・固定ペイロード内で使用されるあらゆるImageオブジェクトは、「Imageパーツ」セクションで定義されるフォントフォーマット規則を満たさなければならない。
・FixedPageから（直接またはセレクタを介して間接に）参照される任意のフォント、イメージ、またはセレクタパーツの場合、参照元FixedPageから参照先パーツへの「必須パーツ」関係（関係名＝http://mmcf-fixed-RequiredResource-PLACEHOLDER）がなければならない。

リーチ構成パーツ
リーチパッケージは、多くのタイプの構成パーツを含むことができるが、明確に定義された１組の構成パーツタイプだけが、本文書によって明確に定義された挙動を有する。明確に定義された挙動を有するこれらの構成パーツは、リーチ構成パーツと呼ばれる。これら以外のパーツは、リーチパッケージの有効性を決定する場合に関係がない。

構成パーツの以下のタイプが、リーチ構成パーツとして定義される。

リーチセレクタ
リーチ構成パーツとして定義されるセレクタ構成パーツは、リーチセレクタ（ｒｅａｃｈ ｓｅｌｅｃｔｏｒ）と呼ばれる。上で述べられたように、言語セレクタ（ｌａｎｇｕａｇｅ ｓｅｌｅｃｔｏｒ）は、英語またはフランス語など自然言語に基づいて、表現の中から選択する。この言語を発見するため、セレクタは、そのアイテムの各々を検査する。ＸＭＬであるアイテムだけが検討される。ＸＭＬアイテムの場合、各アイテムのルート要素が、その言語を決定するために検査される。xml:langアトリビュートが存在しない場合、そのパーツは無視される。セレクタは、次に、これらのパーツの各々について検討し、その言語がシステムのデフォルト言語と一致する最初のパーツを選択する。

色セレクタ（ｃｏｌｏｒ ｓｅｌｅｃｔｏｒ）は、単色かカラーかに基づいて、表現の中から選択する。ページサイズセレクタ（ｐａｇｅ ｓｉｚｅ ｓｅｌｅｃｔｏｒ）は、ページサイズに基づいて、表現の中から選択する。コンテンツタイプセレクタ（ｃｏｎｔｅｎｔ ｔｙｐｅ ｓｅｌｅｃｔｏｒ）は、コンテンツタイプがシステムによって理解され得るかどうかに基づいて、表現の中から選択する。

リーチシーケンス
リーチ構成パーツとして定義されるシーケンス構成パーツは、リーチシーケンス（ｒｅａｃｈ ｓｅｑｕｅｎｃｅ）と呼ばれる。固定シーケンス（ｆｉｘｅｄ ｓｅｑｕｅｎｃｅ）は、固定コンテンツである子を組み合わせてシーケンスにする。

固定ペイロードパーツ
固定ペイロードパーツは、以下の種類のパーツ、すなわち、FixedPanelパーツ、FixedPageパーツ、Imageパーツ、Fontパーツ、プリントチケットパーツ、および記述的メタデータパーツを含むことができ、その各々が、以下でその副見出しの下において説明される。

FixedPanelパーツ
固定ペイロードの文書構造は、以下で示されるように、FixedPageをスパイン（ｓｐｉｎｅ）のパーツとして識別する。スパインパーツとページパーツの間の関係は、スパイン用の関係ストリーム内で定義される。FixedPanelパーツは、コンテンツタイプapplication/xml+PLACEHOLDERに属する。

固定ペイロードコンテンツのスパインは、<Document>要素内に<FixedPanel>要素を含むことによってマークアップにおいて識別される。以下の例では、<FixedPanel>要素は、スパイン内に保持されるページのソースを識別する。

<Document>要素
<Document>要素は、アトリビュートをもたず、子<FixedPanel>を１つもつだけでなければならない。

<FixedPanel>要素
<FixedPanel>要素は、文書のスパインであり、順序付けられたページを互いに論理的にバインドして、単一の複数ページ文書にする。ページは常に、独自の幅および高さを指定するが、<FixedPanel>要素も、高さおよび幅を任意的に指定することができる。この情報は、例えば、ページサイズに基づく代替表現の間での選択を含む、様々な目的で使用されることができる。<FixedPanel>要素が高さおよび幅を指定する場合、それは通常、<FixedPanel>内のページの幅および高さに揃えられるが、これらの寸法は、個々のページの高さおよび幅を指定しない。

以下の表は、説明される実施形態によるFixedPanelアトリビュートを要約したものである。

<PageContent>要素は、<FixedPanel>要素の唯一許容可能な子要素である。<PageContent>要素は、文書のページ順と一致する順次的マークアップ順をとる。

<PageContent>要素
<PageContent>要素は、単一のページに関するコンテンツのソースを参照する。文書内のページ数を決定するには、<FixedPanel>内に含まれる子<PageContent>の数をカウントする。

<PageContent>要素は、許容可能な子をもたず、ページのコンテンツに関するFixedPageパーツを参照する、単一の必須アトリビュートSourceを有する。

<FixedPanel>要素のように、<PageContent>要素は、ここでは単一ページのサイズを反映するPageHeightおよびPageWidthアトリビュートを任意的に含むことができる。必須のページサイズは、FixedPageパーツで指定され、<PageContent>における任意指定のサイズは、助言的なものに過ぎない。<PageContent>のサイズアトリビュートは、文書ビューアなどのアプリケーションが、文書の視覚的レイアウト推定を、個々のFixedPageパーツをすべてロードし解析することなく、素早く行うことを可能にする。

すぐ下に提供される表は、<PageContent>アトリビュートを要約したものであり、アトリビュートの説明を提供する。

ページコンテンツのＵＲＩ文字列は、パッケージを基準にしてコンテンツのパーツロケーションを参照するものでなければならない。

FixedPageパーツ
<FixedPanel>内の各<PageContent>要素は、名前（ＵＲＩ）によってFixedPageパーツを参照する。各FixedPageパーツは、コンテンツの単一パーツのレンダリングを記述するFixedPageマークアップを含む。FixedPageパーツは、コンテンツタイプapplication/xml+PLACEHOLDER-FixedPageに属する。

マークアップにおけるFixedPageの記述
以下は、ソースコンテンツのマークアップが、上記のサンプルのスパインマークアップ内で参照されるページ（<PageContent Source="p1.xml"/>）をどのように探すことができるかについての一例である。

以下の表は、FixedPageプロパティを要約したものであり、プロパティの説明を提供する。

FixedPageマークアップにおける読み取り順序
一実施形態では、FixedPage内に含まれるGlyphs子要素のマークアップ順序は、ページのテキストコンテンツの所望の読み取り順序と同じでなければならない。この読み取り順序は、ビューアにおけるFixedPageからの順次テキストの対話的選択／コピーのためと、アクセシビリティテクノロジ（ａｃｃｅｓｓｉｂｉｌｉｔｙ ｔｅｃｈｎｏｌｏｇｙ）によって順次テキストへのアクセスを可能にするための両方で使用されることができる。マークアップ順序と読み取り順序の間のこの一致を保証することは、FixedPageマークアップを生成するアプリケーションの責任である。

Imageパーツ
サポートされるフォーマット
説明される実施形態によれば、リーチパッケージ内のFixedPageによって使用されるImageパーツは、例えば、ＰＮＧまたはＪＰＥＧなど、一定の数のフォーマットをとることができるが、他のフォーマットが使用されることもできる。

Fontパーツ
説明される実施形態によれば、リーチパッケージは、限られた数のフォントフォーマットをサポートする。例示および説明される実施形態では、サポートされるフォントフォーマットは、ＴｒｕｅＴｙｐｅフォーマットおよびＯｐｅｎＴｙｐｅフォーマットを含む。

当業者であれば理解されるように、ＯｐｅｎＴｙｐｅフォントフォーマットは、ＰｏｓｔＳｃｒｉｐｔフォントデータおよび複雑な印刷レイアウト用のサポートを追加したＴｒｕｅＴｙｐｅフォントフォーマットの拡張である。ＯｐｅｎＴｙｐｅフォントファイルは、ＴｒｕｅＴｙｐｅアウトラインフォントまたはＰｏｓｔＳｃｒｉｐｔアウトラインフォントのどちらかを含むデータをテーブルフォーマット内に含む。

説明される実施形態によれば、以下のフォントフォーマット、すなわち、Ａｄｏｂｅタイプ１、ビットマップフォント、（それを列挙するかどうかを決定するためシステムフラグを使用する）隠されたアトリビュートを有するフォント、ベクトルフォント、および（そのフォントファミリ名がＥＵＤＣである）ＥＵＤＣフォントはリーチパッケージ内でサポートされない。

フォントのサブセット化
固定ペイロードは、以下で詳しく説明されるGlyphs要素を使用して、すべてのテキストを表現する。この実施形態では、フォーマットは固定なので、FixedPayloadによって必要とされるグリフだけを含むようにフォントをサブセット化することが可能である。したがって、リーチパッケージ内のフォントは、グリフ使用に基づいてサブセット化されることができる。サブセット化されたフォントは、元のフォントのグリフをすべては含まないが、有効なＯｐｅｎＴｙｐｅフォントファイルでなければならない。

プリントチケットパーツ
プリントチケットパーツは、パッケージを印刷するときに使用されることができる設定を提供する。これらのプリントチケットは、十分な柔軟性を達成するため、様々な方法でアタッチされることができる。例えば、プリントチケットは、パッケージ全体に「アタッチ」されることができ、その設定は、パッケージ全体に影響を及ぼす。プリントチケットはさらに、構造の低レベルに（例えば、個々のページに）アタッチされることができ、これらのプリントチケットは、それがアタッチされたパーツを印刷するときに使用されるオーバライド設定を提供する。

記述的メタデータ
上で述べられたように、記述的メタデータパーツは、パッケージのリーダがプロパティの値を高い信頼度で発見することを可能にするプロパティの値を保存する方法を、パッケージのライタまたはプロデューサに提供する。これらのプロパティは、一般に、全体としてのパッケージについて、およびコンテナ内の個別パーツについての追加情報を記録するために使用される。

FixedPageマークアップの基本
このセクションは、FixedPageマークアップに関連するいくつかの基本情報について説明し、以下のセクション、すなわち、「固定ペイロードおよびその他のマークアップ標準」、「FixedPageマークアップモデル」、「リソースおよびリソース参照」、および「FixedPage描画モデル」を含む。

固定ペイロードおよびその他のマークアップ標準
リーチパッケージ内の固定ペイロード用のFixedPanelおよびFixedPageマークアップは、Ｗｉｎｄｏｗｓ（登録商標） ＬｏｎｇｈｏｒｎのＡｖａｌｏｎ ＸＡＭＬマークアップからのサブセットである。すなわち、固定ペイロードマークアップは、（本文書に記述されるように）独立のＸＭＬマークアップフォーマットとして単独でも有効であるが、元の複数ページ文書のＷＹＳＩＷＹＧ再生をＬｏｎｇｈｏｒｎシステムと同じ方法でロードし、それをレンダリングする。

ＸＡＭＬマークアップのいくつかの背景として、以下のことを検討する。ＸＡＭＬマークアップは、ユーザが、ＸＭＬベースのマークアップ言語として、オブジェクトの階層とオブジェクトの背後のプログラミングロジックとを指定することを可能にするメカニズムである。これは、オブジェクトモデルがＸＭＬで記述されることを可能にする。これは、マイクロソフトコーポレーションによる．ＮＥＴフレームワークの共通言語ランタイム（ＣＬＲ：Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）内のクラスなど、拡張可能なクラスが、ＸＭＬでアクセスされることを可能にする。ＸＡＭＬメカニズムは、ＸＭＬタグのＣＬＲオブジェクトへの直接マッピング、および関連コードをマークアップで表す能力を提供する。様々な実装がＸＡＭＬのＣＬＲベースの実装を特に利用する必要がないことを認識および理解されたい。むしろ、ＣＬＲベースの実装は、本文書で説明される実施形態に関連してＸＡＭＬが利用され得る１つの方法を構成するに過ぎない。

より具体的には、ＣＬＲ概念（左側コンポーネント）のＸＭＬ（右側コンポーネント）への例示的なマッピングを示す図１１に関連して、以下について検討する。名前空間は、リフレクションと呼ばれるＣＬＲ概念を使用して、ｘｍｌｎｓ宣言内に見出される。クラスは、ＸＭＬタグに直接的にマッピングされる。プロパティおよびイベントは、アトリビュートに直接的にマッピングされる。これらの階層を使用して、ユーザは、ＸＭＬマークアップファイル内で任意のＣＬＲオブジェクトの階層木を指定することができる。ｘａｍｌファイルは、.xaml拡張子と、application/xaml+xmlというメディアタイプを有するｘｍｌファイルである。ｘａｍｌファイルは、一般にｘｍｌｎｓアトリビュートを使用して名前空間を指定する１つのルートタグを有する。名前空間は、その他のタイプのタグで指定されることもできる。

続けると、ｘａｍｌファイル内のタグは、一般にＣＬＲオブジェクトにマッピングされる。タグは、element、compound property、definition、またはresourceとすることができる。要素は、一般に実行中にインスタンス化され、オブジェクトの階層を形成するＣＬＲオブジェクトである。compound propertyタグは、親タグ内でプロパティを設定するために使用される。definitionタグは、ページにコードを追加し、リソースを定義するために使用される。resourceタグは、単にオブジェクト木をリソースとして指定することによって、オブジェクト木を再使用する能力を提供する。definitionタグは、別のタグ内でｘｍｌｎｓアトリビュートとして定義されることもできる。

文書が（一般にはライタによって）マークアップで適切に記述されると、マークアップは、（一般にはリーダによって）解析され、処理されることができる。適切に構成されたパーサは、タグを見つけるためにどのＣＬＲアセンブリ（ＣＬＲ ａｓｓｅｍｂｌｙ）および名前空間が探索されるべきかを、ルートタグから決定する。多くの場合、パーサは、ｘｍｌｎｓアトリビュートによって指定されるＵＲＬで名前空間定義ファイルを探して見つける。名前空間定義ファイルは、アセンブリの名前およびそれらのインストールパス、およびＣＬＲ名前空間の一覧を提供する。パーサは、タグに遭遇した場合、タグのｘｍｌｎｓおよびそのｘｍｌｎｓ用のｘｍｌｎｓ定義ファイルを使用して、タグがどのＣＬＲクラスを参照するかを決定する。パーサは、アセンブリおよび名前空間が定義ファイル内で指定された順序で探索する。一致するものを見つけた場合、パーサは、そのクラスのオブジェクトをインスタンス化する。

したがって、すぐ上で説明され、上で参照により組み込まれたアプリケーションにおいてより十分に説明されるメカニズムは、マークアップタグを使用してＸＭＬベースのファイル内でオブジェクトモデルが表されることを可能にする。マークアップタグとしてオブジェクトモデルを表すこの能力は、ベクトルグラフィック描画、固定フォーマット文書、適応的フロー文書、およびアプリケーションＵＩを、非同期的または同期的に作成するために使用されることができる。

例示および説明される実施形態では、固定ペイロードマークアップは、Ａｖａｌｏｎ ＸＡＭＬレンダリングプリミティブの非常に小さいほぼ全面的に貧弱なサブセットである。固定ペイロードマークアップは、完全な忠実度でもって、Ａｖａｌｏｎで表現され得るものは何でも視覚的に表現する。固定ペイロードマークアップは、Ａｖａｌｏｎ ＸＡＭＬと比較すると、追加規約、基準形式、または使用制限を加えた、Ａｖａｌｏｎ ＸＡＭＬ要素およびプロパティのサブセットである。

定義された極端に小さい固定ペイロードマークアップセットは、プリンタＲＩＰまたは対話的ビューアアプリケーションなど、リーチパッケージのリーダの実装および試験に関連するコストを低減すると共に、関連パーサの複雑さおよびメモリフットプリント（ｍｅｍｏｒｙ ｆｏｏｔｐｒｉｎｔ）を低減する。貧弱なマークアップセットは、サブセット化、エラー、またはリーチパッケージのライタとリーダの間の不整合の機会も最低限に抑え、フォーマットおよびそのエコシステム（ｅｃｏｓｙｓｔｅｍ）を本質的により堅牢にする。

最小限の固定ペイロードマークアップに加えて、リーチパッケージは、ハイパーリンク、セクション／アウトライン構造およびナビゲーション、テキスト選択、ならびに文書アクセシビリティなどの機能を有するリーチパッケージ文書のビューアまたはプレゼンテーションをサポートするため、追加のセマンティック情報のためのマークアップを規定する。

最後に、上で説明されたバージョニングおよび拡張性メカニズムを使用して、特定の目標消費アプリケーション、ビューア、または装置のためのより豊富な要素の組で、最小限の固定ペイロードマークアップを補足することが可能である。

FixedPageマークアップモデル
例示および説明される実施形態では、FixedPageパーツは、ＸＭＬ要素、ＸＭＬアトリビュート、およびＸＭＬ名前空間に基づいたＸＭＬベースのマークアップ言語で表現される。３つのＸＭＬ名前空間が、FixedPageマークアップに含まれるため、本文書で定義される。そのような名前空間の１つは、本明細書の別のところで定義されたバージョニング要素およびアトリビュートを参照する。FixedPageマークアップ内の要素およびアトリビュートのために使用される原則名前空間（ｐｒｉｎｃｉｐｌｅ ｎａｍｅｓｐａｃｅ）は、「http://schemas.microsoft.com/MMCF-PLACEHOLDER-FixedPage」である。最後に、FixedPageマークアップは、以下で説明される第３の名前空間を必要とする「リソース」という概念を導入する。

FixedPageマークアップは、ＸＭＬ要素およびＸＭＬアトリビュートを使用して表現されるが、その仕様は、「コンテンツ」および「プロパティ」というより高レベルの抽象モデルに基づいている。FixedPage要素はすべて、ＸＭＬ要素として表現される。一握りのFixedPage要素だけが、子ＸＭＬ要素として表現される「コンテンツ」を保持することができる。しかし、プロパティ値は、ＸＭＬアトリビュートまたは子ＸＭＬ要素を使用して表現されることができる。

FixedPageマークアップは、リソースディクショナリ（Ｒｅｓｏｕｒｃｅ−Ｄｉｃｔｉｏｎａｒｙ）およびリソース参照（Ｒｅｓｏｕｒｃｅ−Ｒｅｆｅｒｅｎｃｅ）という１対の概念にも依存する。リソースディクショナリと複数のリソース参照の組み合わせは、単一のプロパティ値が、複数のFixedPageマークアップ要素の複数のプロパティによって共有されることを可能にする。

FixedPageマークアップ内のプロパティ
例示および説明される実施形態では、FixedPageマークアッププロパティの値を指定するために使用され得る３つの形式のマークアップが存在する。

プロパティがリソース参照を使用して指定された場合、プロパティ名は、ＸＭＬアトリビュート名として使用され、アトリビュート値のための特別なシンタックスが、リソース参照の存在を表す。リソース参照を表現するためのシンタックスは、「リソースおよびリソース参照」と題するセクションで説明される。

リソース参照として指定されないプロパティ値はどれも、その値が設定されるプロパティを識別するネストされた子ＸＭＬ要素を使用して、ＸＭＬで表現されることができる。この「複合プロパティシンタックス」は、以下で説明される。

最後に、いくつかの非リソース参照プロパティ値は、単純なテキスト文字列として表現されることができる。そのようなプロパティ値はすべて、複合プロパティシンタックスを使用して表現されることができるが、単純なＸＭＬアトリビュートシンタックスを使用して表現されることもできる。

任意の与えられた要素に対して、どのプロパティも、値を指定するために使用されるシンタックスに関わらず、たかだか１度だけ設定されることができる。

単純アトリビュートシンタックス
単純な文字列として表現可能なプロパティ値の場合、プロパティ値を指定するため、ＸＭＬアトリビュートシンタックスが使用されることができる。例えば、「Color」と呼ばれるプロパティを有する「SolidColorBrush」と呼ばれるFixedPageマークアップ要素が与えられた場合、プロパティ値を指定するため、以下のシンタックスが使用されることができる。

複合プロパティシンタックス
いくつかのプロパティ値は、単純な文字列として表現されることができず、例えば、ＸＭＬ要素が、プロパティ値を記述するために使用される。そのようなプロパティ値は、単純アトリビュートシンタックスを使用して表現されることができない。しかし、それらは、複合プロパティシンタックスを使用して表現されることができる。

複合プロパティシンタックスでは、子ＸＭＬ要素が使用されるが、ＸＭＬ要素名は、ドットで分離された親要素名とプロパティ名の組み合わせから導出される。<SolidColorBrush>に設定されることができるプロパティ「Fill」を有するFixedPageマークアップ要素<Path>が与えられた場合、<Path>要素の「Fill」プロパティを設定するため、以下のマークアップが使用されることができる。

複合プロパティシンタックスは、プロパティ値を表現するのに単純アトリビュートシンタックスで十分な場合であっても使用されることができる。そのため、前のセクションの例

は、代わりに複合プロパティシンタックスで、以下のように表現されることができる。

複合プロパティシンタックスを使用してプロパティ値を指定する場合、「プロパティ」を表す子ＸＭＬ要素は、「コンテンツ」を表す子ＸＭＬ要素の前に出現しなければならない。個々の複合プロパティ子ＸＭＬ要素の順序は重要でなく、親要素のどの「コンテンツ」よりも前に一緒に出現することだけが重要である。

例えば、（以下で説明される）<Canvas>要素のClipおよびRenderTransformプロパティの両方を使用する場合、両方とも、<Canvas>要素の<Path>および<Glyphs>コンテンツの前に出現しなければならない。

リソースおよびリソース参照
リソースディクショナリは、各々がリソースと呼ばれる共有可能なプロパティ値を保持するために使用されることができる。それ自体がFixedPageマークアップ要素であるプロパティ値はどれも、リソースディクショナリ内に保持されることができる。リソースディクショナリ内の各リソースは名前を保有する。リソースの名前は、プロパティのＸＭＬアトリビュートからリソースを参照するために使用されることができる。

例示および説明される実施形態では、<Canvas>および<FixedPage>要素は、リソースディクショナリを保有することができる。リソースディクショナリは、<Canvas>および<FixedPage>要素のプロパティの、「Resources」と呼ばれるプロパティとして、マークアップで表現される。しかし、個々のリソース値は、<FixedPage.Resources>または<Canvas.Resources>ＸＭＬ要素内に直接埋め込まれる。構文的には、<Canvas.Resources>および<FixedPage.Resource>用のマークアップは、「コンテンツ」を有するマークアップ要素のためのそれと類似している。

この実施形態によれば、<Canvas.Resources>または<FixedPage.Resources>は、<Canvas>または<FixedPage>のどの複合プロパティシンタックスプロパティ値よりも先行しなければならない。それらは同様に、<Canvas>または<FixedPage>のどの「コンテンツ」よりも先行しなければならない。

固定ペイロードリソースディクショナリの定義
どの<FixedPage>または<Canvas>も、<Canvas.Resources>ＸＭＬ要素を使用して表現されたリソースディクショナリを保有することができる。単一のリソースディクショナリ内の各要素は、一意名を与えられ、要素に関連するＸＭＬアトリビュートを使用して識別される。この「Name」アトリビュートをプロパティに対応するそれらのアトリビュートから区別するため、Nameアトリビュートは、FixedFormat要素の名前空間以外の名前空間から取られる。そのＸＭＬ名前空間用のＵＲＩは、「http://schemas.microsoft.com/PLACEHOLDER-for-resources」である。以下の例では、２つの幾何形状が、一方は長方形用に、もう一方は円用に定義される。

リソースの参照
上で定義されたリソースの１つにプロパティ値を設定するため、リソース名を{}で囲ったＸＭＬアトリビュート値を使用する。例えば、「{Rectangle}」は、使用される幾何形状を表す。以下のマークアップサンプルでは、ディクショナリ内で幾何形状オブジェクトによって定義される長方形領域は、SolidColorBrushによって塗りつぶされる。

この実施形態によれば、リソース参照は、リソースディクショナリにおけるリソースの定義の中で行われてはならない。

リソース参照を解決するための有効範囲規則
１つの名前は、同じリソースディクショナリ内で２度使用されることはできないが、１つのFixedPageパーツ内の２つの異なるリソースディクショナリ内では、同じ名前が使用されることができる。さらに、内側の<Canvas>のリソースディクショナリは、外側の<Canvas>または<FixedPage>のリソースディクショナリ内で定義された名前を再使用することができる。

要素のプロパティを設定するためにリソース参照が使用される場合、様々なリソースディクショナリが、与えられた名前のリソースを求めて探索される。プロパティを保有する要素が<Canvas>である場合、その<Canvas>のリソースディクショナリが（存在するならば）、所望の名前のリソースを求めて探索される。要素が<Canvas>ではない場合、最も近い包含<Canvas>または<FixedPage>から探索が開始される。所望の名前が最初に探索されたリソースディクショナリ内で定義されていない場合、次に最も近い包含<Canvas>または<FixedPage>が調査される。探索がルート<FixedPage>要素まで続けられ、所望の名前のリソースがその<FixedPage>に関連するリソースディクショナリ内で見つからない場合、エラーが発生する。

以下の例は、これらの規則を示している。

FixedPage描画モデル
FixedPage（またはネストされた子Canvas）要素は、その上で他の要素がレンダリングされる要素である。コンテンツの配置は、FixedPage（またはCanvas）用に指定されたプロパティ、FixedPage（またはCanvas）上の要素用に指定されたプロパティ、および固定ペイロード名前空間用に定義された構成規則によって制御される。

要素を位置付けるためのCanvasの使用
固定マークアップでは、すべての要素は、座標系の現在の原点（０，０）に対して位置付けられる。現在の原点は、要素を含むFixedPageまたはCanvasの各要素にRenderTransformアトリビュートを適用することによって移動されることができる。

以下の例は、RenderTransformによる要素の位置付けを示している。

座標系および単位
例示および説明される実施形態によれば、座標系の１単位が、浮動小数点値として表現される１インチの１／９６（約０．２６５ｍｍ）に等しく、座標系の原点（０，０）が、FixedPage要素の左上隅となるように、座標系が最初に設定される。

RenderTransformアトリビュートは、現在の座標系にアフィン変換を施すため、任意の子要素上で指定されることができる。

ページ寸法
ページ寸法は、FixedPage要素上の「PageWidth」および「PageHeight」パラメータによって指定される。

構成規則
FixedPageは、アルファチャネル（ａｌｐｈａ ｃｈａｎｎｅｌ）を有するペインタのモデルを使用する。説明される実施形態によれば、構成は、これらの規則に従って、以下の順序で行われなければならない。

・FixedPage（または任意のネストされたCanvas）は、子要素がマークアップ内に出現した順序でそれに描画される無境界面（ｕｎｂｏｕｎｄｅｄ ｓｕｒｆａｃｅ）と考えられる。この面のアルファチャネルは「０．０」に初期化される（全透明）。実際には、理想的な無境界面は、すべての子要素をレンダリングすることによって生成されるすべてのマーク（ｍａｒｋ）を保持するのに十分な大きさをもつビットマップバッファと考えられることができる。

・面のコンテンツは、FixedPage（またはCanvas）のRenderTransformプロパティによって指定されるアフィン変換を使用して変換される。

・すべての子要素は、FixedPage（またはCanvas）の（やはりRenderTransformプロパティを使用して変換される）Clipプロパティによってクリップされる面上にレンダリングされる。FixedPageはさらに、（０，０，PageWidth，PageHeight）によって指定される長方形にクリップされる。子要素がOpacityプロパティまたはOpacityMaskプロパティを有する場合、それは、子要素が面上にレンダリングされる前に子要素に適用される。

・最後に、FixedPage（またはCanvas）のコンテンツが、その包含要素（ｃｏｎｔａｉｎｉｎｇ ｅｌｅｍｅｎｔ）上にレンダリングされる。FixedPageの場合、包含要素は、物理画像面（ｐｈｙｓｉｃａｌ ｉｍａｇｉｎｇ ｓｕｒｆａｃｅ）である。

レンダリングは、以下の規則に従って行われる。
・面上にマークを生成する要素は、「Glyphs」と「Path」だけである。
・他のすべてのレンダリング効果は、「Glyphs」および「Path」要素を「Canvas」上に位置付け、それらの様々な有効アトリビュートを適用することによって達成されることができる。

固定ペイロード要素およびプロパティ
例示および説明される実施形態によれば、固定ペイロードは、ページおよびそれらのコンテンツを表すためにマークアップで使用されるＸＭＬ要素からなる小さな集合を含む。FixedPanelパーツ内のマークアップは、<Document>、<FixedPanel>、および<PageContent>要素を使用して、文書のページをインデックス付けが容易な共通ルートに結び付ける。各FixedPageパーツは、（一緒になって描画のすべてを行う）<Path>および<Glyphs>要素と、それらをグループ化する<Canvas>要素とだけを有する、<FixedPage>要素内のページのコンテンツを表す。

固定ペイロードマークアップの要素階層は、「最上位レベル要素」、「Path、Clip用の幾何形状」、「Path、Glyphs、またはOpacityMaskを塗りつぶすために使用されるブラシ」、「FixedPageまたはCanvas用のリソースディクショナリ」、「アルファ透明度用の不透明マスク」、「クリッピングパス」および「変換」と題する以下のセクションに要約されている。

最上位レベル要素

Path、Clip用の幾何形状

Path、Glyphs、またはOpacityMaskを塗りつぶすために使用されるブラシ

FixedPageまたはCanvas用のリソースディクショナリ

これらの要素は、上でリソースディクショナリについて説明するセクションにおいて説明された。

アルファ透明度用の不透明マスク

クリッピングパス

変換

FixedPageマークアップ
各FixedPageパーツは、<FixedPage>要素に植えつけ（ｒｏｏｔ）られるＸＭＬマークアップでページのコンテンツを表す。このFixedPageパーツは、要素とプロパティの小さな集合、すなわち、（一緒になって描画のすべてを行う）<Path>および<Glyphs>要素と、それらをグループ化する<Canvas>要素だけを用いて、ライタとリーダの間における文書のＷＹＳＩＷＹＧ忠実性（ＷＹＳＩＷＹＧ ｆｉｄｅｌｉｔｙ）を提供する。

共通要素プロパティ
FixedPage内の各要素に特有のアトリビュートについて説明する前に、描画およびグループ化要素、すなわち、Opacity、Clip、RenderTransform、およびOpacityMaskに共通のアトリビュートについて検討する。これらは、最上位レベル要素に共通な唯一のプロパティであるばかりでなく、上の構成規則セクションで説明されたように、それらの結果を親から子要素に「蓄積する（ａｃｃｕｍｕｌａｔｅ）」唯一のプロパティでもある。蓄積は、構成規則の適用の結果である。以下の表は、これらの共通アトリビュートの概要説明を提供し、その後、各アトリビュートについてのより完全な説明が行われる。

Opacityアトリビュート
Opacityは、レンダリング時に２つの要素を透明的に混合するために使用される（アルファブレンディング（Ａｌｐｈａ Ｂｌｅｎｄｉｎｇ））。Opacityアトリビュートは、０（完全に透明）から１（完全に不透明）の範囲を有する。この包含範囲外の値は、マークアップ解析時にこの範囲内に押し込まれる。そのため、事実上、［−∞．．．０］は透明であり、［１．．．∞］は不透明である。

Opacityアトリビュートは、以下の計算を介して適用される（共にｓｃＲＧＢとして指定される、非プリマルチプライ済（ｎｏｎ−ｐｒｅｍｕｌｔｉｐｌｉｅｄ）ソースカラーおよびデスティネーションカラーを仮定する）。
Ｏ_Ｅ：要素のOpacityアトリビュートまたはOpacityMask内の対応する位置のアルファ値
Ａ_Ｓ：ソース面に存在するアルファ値
Ｒ_Ｓ：ソース面に存在する赤値
Ｇ_Ｓ：ソース面に存在する緑値
Ｂ_Ｓ：ソース面に存在する青値
Ａ_Ｄ：デスティネーション面にすでに存在するアルファ値
Ｒ_Ｄ：デスティネーション面に存在する赤値
Ｇ_Ｄ：デスティネーション面に存在する緑値
Ｂ_Ｄ：デスティネーション面に存在する青値
Ａ^＊：デスティネーション面のための結果のアルファ値
Ｒ^＊：デスティネーション面のための結果の赤値
Ｇ^＊：デスティネーション面のための結果の緑値
Ｂ^＊：デスティネーション面のための結果の青値
下付き文字Ｔを伴って示されるすべての値は、一時的な値である（例えば、Ｒ_Ｔ１）。

ステップ１：ソースアルファ値にOpacity値を乗じる
Ａ_Ｓ＝Ａ_Ｓ×Ｏ_Ｅ
ステップ２：ソースアルファにプリマルチプライを施す
Ａ_Ｔ１＝Ａ_Ｓ
Ｒ_Ｔ１＝Ｒ_Ｓ×Ａ_Ｓ
Ｇ_Ｔ１＝Ｇ_Ｓ×Ａ_Ｓ
Ｂ_Ｔ１＝Ｂ_Ｓ×Ａ_Ｓ
ステップ３：デスティネーションアルファにプリマルチプライを施す
Ａ_Ｔ２＝Ａ_Ｄ
Ｒ_Ｔ２＝Ｒ_Ｄ×Ａ_Ｄ
Ｇ_Ｔ２＝Ｇ_Ｄ×Ａ_Ｄ
Ｂ_Ｔ２＝Ｂ_Ｄ×Ａ_Ｄ
ステップ３：混合
Ａ_Ｔ２＝（１−Ａ_Ｔ１）×Ａ_Ｔ２＋Ａ_Ｔ１
Ｒ_Ｔ２＝（１−Ａ_Ｔ１）×Ｒ_Ｔ２＋Ｒ_Ｔ１
Ｇ_Ｔ２＝（１−Ａ_Ｔ１）×Ｇ_Ｔ２＋Ｇ_Ｔ１
Ｂ_Ｔ２＝（１−Ａ_Ｔ１）×Ｂ_Ｔ２＋Ｂ_Ｔ１
ステップ４：プリマルチプライをリバースする
Ａ_Ｔ２＝０ならば、すべてのＡ^＊、Ｒ^＊、Ｇ^＊、Ｂ^＊を０に設定し、
それ以外なら
Ａ^＊＝Ａ_Ｔ２
Ｒ^＊＝Ｒ_Ｔ２／Ａ_Ｔ２
Ｇ^＊＝Ｇ_Ｔ２／Ａ_Ｔ２
Ｂ^＊＝Ｂ_Ｔ２／Ａ_Ｔ２

Clipプロパティ
Clipプロパティは、幾何形状要素<GeometryCollection>または<PathGeometry>の一方として指定される（詳細についてはPath.Dataを参照）。
Clipプロパティは、以下の方法で適用される。
・Clip子要素によって記述される幾何要素内に包含されるすべてのレンダリングコンテンツは、可視である。
・Clip子要素によって記述される幾何要素内に包含されないすべてのレンダリングコンテンツは、非可視である。

RenderTransform子要素
MatrixTransformは、要素が利用可能な唯一の変換アトリビュートである。MatrixTransformは、アフィン変換を表現する。シンタックスは、以下の通りである。

Matrixアトリビュートで指定される６つの数は、ｍ００、ｍ０１、ｍ１０、ｍ１１、ｄｘ、ｄｙである。
完全な行列は、以下のようになる。

ｍ００ ｍ０１ ０
ｍ１０ ｍ１１ ０
ｄｘ ｄｙ １
与えられた座標Ｘ、Ｙは、RenderTransformを用いて変換され、以下の計算を適用することによって、結果の座標Ｘ’、Ｙ’を生成する。
Ｘ’＝Ｘ×ｍ００＋Ｙ×ｍ１０＋ｄｘ
Ｙ’＝Ｘ×ｍ０１＋Ｙ×ｍ１１＋ｄｙ

OpacityMask子要素
OpacityMaskは、ブラシを指定するが、Fillブラシとは対照的に、ブラシのアルファチャネル（上のOpacityアトリビュートを参照）だけが、要素をレンダリングするための追加パラメータとして使用される。要素の各ピクセルの各アルファ値は、その後さらに、OpacityMaskブラシの対応する位置におけるアルファ値を乗じられる。

<Canvas>要素
<Canvas>要素は、要素を一緒にグループ化するために使用される。一般に、FixedPage要素は、構成共通アトリビュート（すなわち、Opacity、Clip、RenderTransform、またはOpacityMask）を共有する場合、<Canvas>内に一緒にグループ化される。これらの要素をCanvas上に一緒にグループ化することによって、共通アトリビュートは、個々の要素の代わりに、しばしばCanvasに適用されることができる。

<Canvas>のアトリビュートおよび子要素
<Canvas>要素は、先に説明された共通アトリビュート、すなわち、Opacity、Clip、RenderTransform、およびOpacityMaskだけを有する。それらは、以下の表で説明されるように、<Canvas>要素と共に使用される。

以下のマークアップ例は、<Canvas>の使用法を示している。

Canvasマークアップの読み取り順序に関して、以下のことを検討する。FixedPageのように、Canvas内に含まれるGlyphs子要素のマークアップ順序は、テキストコンテンツの所望の読み取り順序と同じでなければならない。この読み取り順序は、ビューアにおけるFixedPageからの順次テキストの対話的選択／コピーのためと、アクセシビリティテクノロジによって順次テキストへのアクセスを可能にするための両方で使用されることができる。マークアップ順序と読み取り順序の間のこの一致を保証することは、FixedPageマークアップを生成するアプリケーションの責任である。

ネストされたCanvas内に含まれる子Glyphs要素は、Canvasの前後に存在する兄弟Glyphs要素の間に一列に並べられる。

例：

<Path>要素
<Path>要素は、幾何学的領域を記述するＸＭＬベースの要素である。幾何学的領域は、塗りつぶされること、またはクリッピングパスとして使用されることができる形状である。長方形および楕円などの共通幾何形状タイプは、Path幾何形状を使用して表されることができる。Pathは、必須Geometry.Data子要素と、FillまたはOpacityなどのレンダリングアトリビュートを指定することによって記述される。

<Path>のプロパティおよび子要素
以下のプロパティは、以下で説明されるように<Path>要素に適用可能である。

<Path.Data>子要素の幾何形状によって記述される領域をどのようにペイントするかを記述するため、Fillプロパティを使用する。<Path.Data>形状が描画され得る領域を制限するため、Clipプロパティを使用する。

幾何形状を記述するための<Path>の使用
Pathの幾何形状は、以下に示されるように、一連のネストされた<Path.Data>の子要素として指定される。幾何形状は、１組の<PathGeometry>子要素を含む<GeometryCollection>、または<PathFigures>を含む単一の<PathGeometry>子要素のどちらかを用いて表されることができる。

同じ<GeometryCollection>または<PathGeometry>要素は、Canvas、Path、またはGlyphsのClipプロパティで使用されるクリッピングパス用の幾何形状を定義する。

以下の表は、Path幾何形状を定義する子要素の階層を導入する。

GeometryCollection
GeometryCollectionは、ブールCombineModeオプションに従ってレンダリングするために一緒に組み合わされる幾何オブジェクトからなる組である。GeometryCollection要素は、幾何形状の視覚的組み合わせを構築するためのFixedPageマークアップにおけるメカニズムである。

CombineModeアトリビュートは、GeometryCollection内の１組の幾何形状を組み合わせるために使用されるブール演算を指定する。モードに応じて、異なる領域が含められ、または排除される。

CombineModesは、以下のように処理される。

非可換（Ｎｏｔ Ｃｏｍｍｕｔａｔｉｖｅ） ComplementおよびExcludeは非可換であり、したがって、GeometryCollection内の第１の幾何形状と残りの各個々の幾何形状の間で定義される。例えば、集合｛ｇ１，ｇ２，ｇ３｝の場合、ExcludeのCombineModeは、（（ｇ１ exclude ｇ２） and （ｇ１ exclude ｇ３））として適用される。

可換（Ｃｏｍｍｕｔａｔｉｖｅ） ブール演算のUnion、Xor、Intersectは可換であり、したがって、順序に関係なく幾何形状に適用される。

PathGeometry
PathGeometry要素は、PathFigure要素からなる組を含む。PathFigureのunionは、PathGeometryの内部を定義する。

FillRuleアトリビュートに関して、以下のことを検討する。PathGeometryの塗りつぶされる領域は、含まれるPathFigureのうちFilledアトリビュートがtrueに設定されたものすべてを取り、囲われた領域を決定するためにFillRuleを適用することによって定められる。FillRuleオプションは、Geometry内に含まれるFigure要素の交わり領域をどのように組み合わせて、Geometryの結果領域を形成するかを指定する。

説明される実施形態によれば、ＥｖｅｎＯｄｄ塗りつぶしおよびＮｏｎＺｅｒｏ塗りつぶしアルゴリズムが提供される。

ＥｖｅｎＯｄｄ塗りつぶしアルゴリズムは、Canvas上の点の「内側性（ｉｎｓｉｄｅｎｅｓｓ）」を、その点からあらゆる方向に無限遠まで半直線を引き、次に形状のセグメントが半直線を横切る場所を調べることによって決定する。０からカウントを開始し、セグメントが半直線を左から右に横切るたびに１を加算し、パスセグメントが半直線を右から左に横切るたびに１を減算する。横断をカウントした後、結果が０であれば、点はPathの外側にある。そうでなければ、点は内側である。

ＮｏｎＺｅｒｏ塗りつぶしアルゴリズムは、Canvas上の点の「内側性」を、その点からあらゆる方向に無限遠まで半直線を引き、半直線が横切る与えられた形状からのパスセグメントの数をカウントすることによって決定する。この数が奇数であれば、点は内側であり、偶数であれば、点は外側である。

PathFigure
PathFigure要素は、１つまたは複数の直線または曲線セグメントからなる組から構成される。セグメント要素は、PathFigureの形状を定義する。PathFigureは、常に閉じた形状でなければならない。

Figureは、開始点を必要とし、その後、最後に追加された点から各直線または曲線セグメントが続く。PathFigureセット内の最初のセグメントは、StartSegmentでなければならず、CloseSegmentが、最後のセグメントでなければならない。StartSegmentは、Pointアトリビュートをもつ。CloseSegmentは、アトリビュートをもたない。

Path.Data幾何形状用の固定ペイロードマークアップ
以下は、Canvas上にPathを描画し、それを塗りつぶすためのマークアップを提供する。以下の具体例では、長方形Pathが、Canvas上に描画され、無地緑色のブラシで塗りつぶされる。

以下のマークアップは、３次ベジェ曲線（ｃｕｂｉｃ Ｂｅｚｉｅｒ ｃｕｒｖｅ）の描画を記述する。すなわち、PolyLineSegmentに加えて、固定ペイロードマークアップは、３次ベジェ曲線を描画するためのPolyBezierSegmentを含む。

ブラシ
ブラシは、<Path>要素によって定義された幾何形状の内部をペイントするため、および<Glyphs>要素を用いてレンダリングされる文字ビットマップを塗りつぶすために使用される。ブラシは、<Canvas.OpacityMask>、<Path.OpacityMask>、および<Glyphs.OpacityMask>においてアルファ透明度マスクを定義する際にも使用される。FixedPageマークアップは、以下のブラシを含む。

アトリビュートは、ブラシによって様々であるが、すべてのブラシは、Opacityアトリビュートをもつ。ImageBrushおよびDrawingBrushは、タイリング機能を共有する。２つのグラデーション塗りつぶしブラシも同様に、共通のアトリビュートをもつ。
マークアップにおけるブラシ子要素の使用法が、以下に示されている。

ブラシ用の共通プロパティ
説明される実施形態では、以下のプロパティが、より少数の任意指定の子要素を有する単純なブラシであるSolidColorBrushを除いて、すべてのブラシに適用可能である。

DrawingBrushおよびImageBrush用の共通アトリビュート

Horizontal Alignmentアトリビュートは、塗りつぶす領域内でブラシがどのように水平位置を調整されるかを指定する。Vertical Alignmentアトリビュートは、塗りつぶす領域内でブラシがどのように垂直位置を調整されるかを指定する。ViewBoxアトリビュートは、未設定と解釈されるデフォルト値の（０，０，０，０）を有する。未設定の場合、調整は行われず、Stretchアトリビュートは無視される。ViewBoxは、コンテンツ用の新しい座標系を指定し、すなわち、ViewPortの範囲および原点を再定義する。Stretchアトリビュートは、それらのコンテンツがどのようにViewPortにマッピングされるかを指定するのを助ける。ViewBoxアトリビュートの値は、空白および／またはカンマによって分離された４つの「無単位」数<min-x>、<min-y>、<width>、および<height>からなるリストであり、タイプRectに属する。ViewBox Rectは、バウンディングボックス（ｂｏｕｎｄｉｎｇ ｂｏｘ）にマッピングされるユーザ空間内の長方形を指定する。ViewBox Rectは、scaleXおよびscaleYを挿入するのと同じように機能する。Stretchアトリビュートは（オプションがnone以外の場合）、グラフィックスのアスペクト比を保存するための追加制御を提供する。追加の変換は、指定された効果を達成するため、与えられた要素のすべての子孫に適用される。ブラシ上で変換がある場合、それはViewBoxへのマッピングの「上に」適用される。

Stretchアトリビュートは、以下のモード、すなわち、None、Fill、Uniform、UniformToFillを有する。

単純なブラシおよびそれらのアトリビュート
Path.BrushおよびCanvas.Brush子要素は、以下のもの、すなわち、SolidColorBrush、ImageBrush、およびDrawingBrushを含む。

SolidColorBrushは、幾何学的領域を無地色で塗りつぶす。色のアルファ成分がある場合、それはBrushの対応するOpacityアトリビュートと乗算的方法で組み合わされる。

以下の例は、ColorアトリビュートがSolidColorBrushのためにどのように表現されるかを示している。

ImageBrushは、空間をイメージで塗りつぶすために使用されることができる。ImageBrushのためのマークアップは、ＵＲＩが指定されることを可能にする。他のすべてのアトリビュートがデフォルト値に設定される場合、イメージは、領域のバウンディングボックス一杯に引き延ばされる。

ImageSourceアトリビュートは、サポートされるリーチイメージフォーマット、またはこれらのタイプの１つのイメージに導くセレクタのどちらか一方を参照しなければならない。

DrawingBrushは、空間をベクトル描画で塗りつぶすために使用されることができる。DrawingBrushは、Drawing子要素を有し、マークアップにおけるその使用法が、以下に示されている。

グラデーションブラシおよびそれらのアトリビュート
グラデーションは、グラデーションブラシのＸＭＬ子要素として１組のグラデーションストップ（ｇｒａｄｉｅｎｔ ｓｔｏｐ）を指定することによって描画される。これらのグラデーションストップは、何らかの種類の数列に従って色を指定する。このフレームワークにおいてサポートされる２つのタイプのグラデーションブラシ、すなわち、リニアおよびラジアルが存在する。

グラデーションは、指定された色空間においてグラデーションストップ間の補完を行うことによって描画される。LinearGradientBrushおよびGradientBrushは、以下の共通アトリビュートを共有する。

SpreadMethodアトリビュートに関して、以下のことを検討する。SpreadMethodオプションは、空間をどのように塗りつぶすかを指定する。デフォルト値はPadである。

MappingModeアトリビュート
LinearGradientBrushに関して、以下のことを検討する。LinearGradientBrushは、ベクトルに従ってリニアグラデーションブラシを指定する。

以下のマークアップ例は、LinearGradientBrushの使用法を示している。長方形パスを有するページが、リニアグラデーションを用いて塗りつぶされる。

以下の例は、リニアグラデーションを用いて塗りつぶされる長方形パスを有するページを示している。Pathは、それをクリップする８角形の形状のClipプロパティも有する。

RadialGradientは、プログラミングモデルにおいてリニアグラデーションと類似している。しかし、リニアグラデーションが、グラデーションベクトルを定義する開始点と終了点を有するのに対して、ラジアルグラデーションは、グラデーション挙動を定義する焦点を伴う円を有する。円がグラデーションの終了点を定義し、言い換えると、１．０におけるグラデーションストップが、円の円周における色を定義する。焦点が、グラデーションの中心を定義する。０．０におけるグラデーションストップが、焦点における色を定義する。

アルファおよび透明度
例示および説明される実施形態によれば、各要素の各ピクセルは、０．０（完全に透明）から１．０（完全に不透明）までの範囲にわたるアルファ値を保有する。アルファ値は、透明性の視覚効果を達成するために要素を混合するときに使用される。

各要素は、要素の各ピクセルのアルファ値がそれと均一に乗算されるOpacityアトリビュートをもつことができる。

加えて、OpacityMaskは、レンダリングコンテンツがそのレンダリング先の中にどのように混合されるかを制御するピクセル毎の不透明度の指定を可能にする。OpacityMaskによって指定される不透明度は、コンテンツのアルファチャネルにすでにたまたま存在していることのある不透明度と乗算的に組み合わされる。OpacityMaskによって指定されるピクセル毎の不透明度は、マスクの各ピクセルのアルファチャネルを調べることによって決定され、色データは無視される。

OpacityMaskのタイプは、Brushである。これは、Brushのコンテンツがどのようにコンテンツの領域にマッピングされるかを様々な異なる方法で指定することを可能にする。幾何形状を塗りつぶすために使用される場合と同様に、Brushは、デフォルト設定では、コンテンツ領域全体を塗りつぶし、必要に応じてコンテンツを引き延ばしまたは繰り返す。これは、ImageBrushが、コンテンツを完全に覆うように、そのImageSourceを引き延ばし、GradientBrushが、縁から縁まで延び広がることを意味する。

アルファブレンディングのために必要な計算は、先のセクション「Opacityアトリビュート」で説明された。

以下の例は、OpacityMask が、Glyphs要素上で「フェード効果」を生み出すためにどのように使用されるかを示している。この例におけるOpacityMaskは、不透明黒から透明黒までフェーディングするリニアグラデーションである。

リーチ文書におけるイメージ
FixedPage上で、イメージは、囲われた領域を塗りつぶす。FixedPage上にイメージを配置するため、最初に領域が、ページ上に指定されなければならない。領域は、Path要素の幾何形状によって定義される。

Path要素のFillプロパティは、記述された領域のために塗りつぶしコンテンツを指定する。イメージは、１つのタイプの塗りつぶしであり、ImageBrushによって領域に描画される。すべてのブラシは、必要に応じてブラシコンテンツを引き延ばすか、または繰り返す（タイリングする）ことによって領域全体を塗りつぶすデフォルト挙動を有する。ImageBrushの場合、ImageSourceプロパティによって指定されたコンテンツは、領域を完全に覆うように引き延ばされる。

以下のマークアップは、イメージをどのようにCanvasに配置するかを示している。

多くのイメージは長方形なので、リソースディクショナリ内に長方形のPath要素を含むことは、マークアップを簡潔にする上で有益であろう。その場合、Pathは、RenderTransformアトリビュート（上を参照）を使用して位置付けられることができる。

色
色は、ｓｃＲＧＢまたはｓＲＧＢ記法を使用して、例示および説明されるマークアップ内で指定されることができる。ｓｃＲＧＢ仕様は、「ＩＥＣ ６１９６６−２−２ ｓｃＲＧＢ」として知られており、www.iec.chから取得されることができる。

ＡＲＧＢパラメータが、以下の表で説明されている。

色マッピング
現在、カラーコンテキストを指定するメタデータによって色付けられる要素のタグ付けについて検討が行われている。そのようなメタデータは、ＩＣＣカラープロファイル（ＩＣＣ ｃｏｌｏｒ ｐｒｏｆｉｌｅ）またはその他のカラー定義データを含むことができる。

<Glyphs>要素
テキストは、固定ペイロードにおいて、Glyphs要素を使用して表される。Glyphs要素は、印刷およびリーチ文書のための要件を満たすように設計される。

Glyphs要素は、以下のプロパティの組み合わせを有することができる。

テキストマークアップの概要
グリフメトリック
各グリフは、それがどのように他のグリフと整列するかを指定するメトリックを定義する。一実施形態による例示的なメトリックが、図１２に示されている。

アドバンス幅および組み合わせマーク
一般に、フォント内のグリフは、ベースグリフまたはベースグリフにアタッチされ得る組み合わせマークのどちらかである。ベースグリフは通常、非０のアドバンス幅と、０，０のオフセットベクトルを有する。組み合わせマークは通常、０のアドバンス幅を有する。オフセットベクトルは、組み合わせマークの位置を調整するために使用されることができ、そのため、組み合わせマークの場合は非０，０の値をもつことができる。

グリフラン内の各グリフは、その位置を制御する３つの値を有する。その値は、始点、アドバンス幅、およびグリフオフセットを表し、その各々が以下で説明される。

・始点：各グリフは、公称始点を与えられると仮定され、ラン内の第１のグリフの場合、これがそのランの始点である。
・アドバンス幅：各グリフのアドバンス幅は、このグリフ始点を基準として次のグリフの始点を提供する。アドバンスベクトルは、常にラン連鎖の方向に引かれる。
・グリフオフセット（ベースまたはマーク）：グリフオフセットベクトルは、公称始点を基準としてこのグリフ位置を調整する。

文字、グリフ、およびクラスタマップ
クラスタマップは、Ｕｎｉｃｏｄｅコードポイント毎に１つのエントリを含むことができる。エントリ内の値は、このコードポイントを表すGlyphIndices配列内の第１のグリフのオフセットである。代替として、コードポイントが分割不能な文字クラスタを表すコードポイントのグループの部分である場合、GlyphIndices配列内の第１のグリフは、そのクラスタ表す第１のグリフのオフセットである。

クラスタマッピング
クラスタマップは、１対１、多対１、１対多、または多対多の、コードポイントからグリフへのマッピングを表すことができる。１対１マッピングは、各コードポイントが正確に１つのグリフによって表される場合であり、図１３のクラスタマップエントリは、０，１，２，．．．である。

多対１マッピングは、２以上のコードポイントが１つのグリフにマッピングされる場合である。それらのコードポイントのエントリは、グリフインデックスバッファ内のそのグリフのオフセットを指定する。図１４の例では、「f」と「i」の文字が、多くのセリフフォントの植字実施で一般的なように、合字によって置換されている。

１対多マッピングに関して、図１５に関連して以下のことを検討する。「Sara Am」は、前のベース文字の上にある部分（リング）と、ベース文字の右にある部分（フック）とを含む。タイ語のテキストが位置を微調整される場合、フックはベース文字から離して配置されるが、リングはベース文字の上にあり続け、したがって、多くのフォントは、リングとフックを別々のグリフとして符号化する。１つのコードポイントが２以上のグリフにマッピングされる場合、そのコードポイントのためのClusterMap内の値は、そのコードポイントを表すGlyphIndeces配列内の第１のグリフを参照する。

多対多マッピングに関して、図１６に関連して以下のことを検討する。いくつかのフォントでは、文字クラスタのための分割不能なコードポイントのグループが、２以上のグリフにマッピングされる。例えば、これはインド系文字をサポートするフォントで一般的である。分割不能なコードポイントのグループが１つまたは複数のグリフにマッピングされる場合、各コードポイントのためのClusterMap内の値は、そのコードポイントを表すGlyphIndeces配列内の第１のグリフを参照する。

以下の例は、タミル語の□□□□のＵｎｉｃｏｄｅとグリフ表現を示している。最初の２つのコードポイントが組み合わされて、３つのグリフを生成する。

クラスタの指定
クラスタ指定は、非１：１クラスタの第１のグリフのためのグリフ指定に先立つ（マッピングは、１文字対１グリフよりも複雑である）。

各クラスタ指定は、以下の形式を有する。

(ClusterCodepointCount [:ClusterGlyphCount])

<Glyphs>マークアップ
Glyphs要素は、ＵＲＩ、字体インデックス（ｆａｃｅ ｉｎｄｅｘ）、および上で説明されたその他のアトリビュートの組としてフォントを指定する。例えば、以下のようである。

各グリフ指定は、以下の形式を有する。

[GlyphIndex] [,[Advance] [,[uOffset] [,[vOffset] [,[Flags]]]]]
グリフ指定の各部分は、任意指定である。

丸め誤差が累積しないようにアドバンスを計算することに関して、以下のことを検討する。各アドバンス値は、正確な丸められていない後続グリフの始点から、先行グリフの計算された（すなわち丸められた）アドバンス幅の総和を減算することによって計算されなければならない。このようにすることで、各グリフは、その正確な位置から１ｅｍの０．５％以内に位置付けられる。

グリフマークアップ例

グリフマークアップのサイズの最適化
グリフインデックスおよびアドバンス幅などのマークアップ詳細は、目標クライアントがそれらを高い信頼度で再生成し得るならば、省略されることができる。以下のオプションは、普通に使用される単純なスクリプトの劇的な最適化を可能にする。

グリフインデックスのマークアップの最適化
グリフインデックスは、Ｕｎｉｃｏｄｅ文字列内の文字の位置とグリフ列内のグリフの位置の間に１対１マッピングが存在し、かつグリフインデックスがフォントのＣＭＡＰ（文字マッピング）テーブル内の値であり、かつＵｎｉｃｏｄｅ文字が明確なセマンティクスを有する場合、省略されることができる。

グリフインデックスは、文字のグリフへのマッピングが、
・２以上のコードポイントが単一のグリフ（合字）を形成するなど、非１対１であるか、または
・１つのコードポイントが複数のグリフを生成するか、または
・ＯｐｅｎＴｙｐｅフィーチャの利用によるなど、その他の任意の形式のグリフ交換が発生した場合、マークアップにおいて提供されるべきである。

グリフインデックスは、レンダリングエンジンがフォントのＣＭＡＰ（文字マッピング）テーブル内のものとは異なるグリフを交換できる場合、マークアップにおいて提供されるべきである。グリフインデックスは、所望のグリフ表現がフォントのＣＭＡＰテーブル内のものではない場合に提供されるべきである。

グリフ位置のマークアップの最適化
グリフのアドバンス幅は、必要とされるアドバンス幅がまさにフォントのＨＭＴＸ（水平メトリック）またはＶＭＴＸ（垂直メトリック）テーブル内のグリフのためのものである場合、マークアップから省略されることができる。

グリフの水平オフセットは、それが０である場合、マークアップから省略されることができる。これは、ベース文字の場合、ほとんど常に当てはまり、より単純なスクリプト体の組み合わせマークの場合、普通は当てはまる。しかし、これは、アラビア系およびインド系などより複雑なスクリプト体の組み合わせマークの場合、しばしば当てはまらない。

グリフフラグのマークアップの最適化
グリフフラグは、通常の位置調整優先度を有するベースグリフの場合、省略されることができる。

結論
上で説明されたモジュールコンテンツフレームワークおよび文書フォーマット方法およびシステムは、文書中心のコンテンツを構成し、パッケージングし、配布し、かつレンダリングするための、１組のビルディングブロックを提供する。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムが、高い信頼性および一貫性をもって、文書を生成し、交換し、かつ表示することを可能にする文書フォーマットのための、プラットフォーム独立のフレームワークを定義する。例示および説明されたリーチパッケージフォーマットは、リーチパッケージのコンテンツが、様々な環境内の装置およびアプリケーションにおいて、様々なシナリオのもと、完全な忠実度で表示または印刷されることができる方法で、ページ付けまたは事前ページ付けされた文書を保存するためのフォーマットを提供する。本発明は構造的特徴および／または方法論的ステップに特有の言語で説明されたが、添付の特許請求の範囲において確定される本発明は、必ずしも説明された特定の特徴またはステップに限定されないことを理解されたい。むしろ、特定の特徴およびステップは、特許請求される発明を実施する好ましい形態として開示されている。

一実施形態による、例示的なフレームワークおよびフォーマットのコンポーネントのブロック図である。 一実施形態による、複数のパーツを含む文書を保持する例示的なパッケージのブロック図である。 一実施形態による、パッケージを作成する例示的なライタと、パッケージを読むリーダとを説明するブロック図である。 ３つの別個のページを一緒にバインドした例示的なパーツを示す図である。 一実施形態による、英語で表現された報告書とフランス語で表現された報告書の両方を含む財務報告書を作成するように構成された例示的なセレクタとシーケンスを示す図である。 一実施形態による、パッケージについて通信するために協働するライタとリーダのいくつかの例を示す図である。 文書の複数のパーツをインタリーブする一例を示す図である。 図７に示された文書の複数のパーツをパッケージングする異なる例を示す図である。 図７に示された文書の複数のパーツをパッケージングする異なる例を示す図である。 一実施形態による、例示的なリーチパッケージと、パッケージを構成でき、またはパッケージ内で見出され得る各有効タイプのパーツとを示す図である。 一実施形態による、共通言語ランタイム概念のＸＭＬへの例示的なマッピングを示す図である。 一実施形態による、縦方向および横方向グリフメトリックを共に示す図である。 一実施形態による、１対１のクラスタマップを示す図である。 一実施形態による、多対１のクラスタマップを示す図である。 一実施形態による、１対多のクラスタマップを示す図である。 一実施形態による、多対多のクラスタマップを示す図である。

Claims (45)

1. １つまたは複数のコンピュータ可読媒体と、
   実行時に文書をマークアップ表現を用いて表すことが可能な、前記媒体上に常駐するソフトウェア命令であって、
   ページの順序付けられたシーケンスを一緒に論理的にバインドして単一の複数ページ文書にする第１の要素と、
   各々が前記第１の要素の子であり、前記文書の単一ページのコンテンツのソースを参照する１つまたは複数の第２の要素とを含むソフトウェア命令とを含むことを特徴とするシステム。
2. 前記諸要素は、共同で固定ペイロードを記述することを特徴とする請求項１に記載のシステム。
3. 前記要素は、関連するオブジェクトクラスにマッピング可能なことを特徴とする請求項１に記載のシステム。
4. 前記第１の要素は、ページ高さとページ幅とを含むアトリビュートをもち得ることを特徴とする請求項１に記載のシステム。
5. 前記第２の要素は、前記単一ページのページ高さとページ幅とを含むアトリビュートをもち得ることを特徴とする請求項１に記載のシステム。
6. 前記第２の要素は、前記文書のレンダリングに関連するプロパティと追加要素とを記述する固定ページマークアップを含む固定ページパーツを参照することを特徴とする請求項１に記載のシステム。
7. 前記第２の要素は、前記文書のレンダリングに関連するプロパティと追加要素とを記述する固定ページマークアップを含む固定ページパーツを参照し、前記固定ページマークアップは、必須のページ高さプロパティと、必須のページ幅プロパティとを含むことを特徴とする請求項１に記載のシステム。
8. 前記第２の要素は、前記文書のレンダリングに関連するプロパティと追加要素とを記述する固定ページマークアップを含む固定ページパーツを参照し、前記固定ページマークアップのプロパティは、複数の方法で表現され得ることを特徴とする請求項１に記載のシステム。
9. プロパティが表現され得る１つの方法は、ＸＭＬアトリビュートとして表現される方法であることを特徴とする請求項８に記載のシステム。
10. プロパティが表現され得る１つの方法は、リソースディクショナリ参照を介するものであることを特徴とする請求項８に記載のシステム。
11. プロパティが表現され得る１つの方法は、リソースディクショナリ参照を介するものであり、参照されるリソースディクショナリは、前記リソースディクショナリ参照によって参照される１つまたは複数の複合プロパティを保持することを特徴とする請求項８に記載のシステム。
12. プロパティが表現され得る１つの方法は、ＸＭＬ子要素として表現されるリソースディクショナリとして表現される方法であることを特徴とする請求項８に記載のシステム。
13. プロパティが表現され得る１つの方法は、ＸＭＬ子要素として表現される方法であることを特徴とする請求項８に記載のシステム。
14. 前記第２の要素は、前記文書のレンダリングに関連するプロパティと追加要素とを記述する固定ページマークアップを含む固定ページパーツを参照し、前記追加要素の少なくともいくつかは、描画がどのように実行されるかを記述する１つまたは複数の要素と、その他の要素をグループ化する少なくとも１つのグループ化要素とを含むことを特徴とする請求項１に記載のシステム。
15. 描画要素およびグループ化要素は、Opacityアトリビュートと、Clipアトリビュートと、RenderTransformアトリビュートと、OpacityMaskアトリビュートとを含む共通アトリビュートを有することを特徴とする請求項１４に記載のシステム。
16. 前記グループ化要素は、共通アトリビュートを共有する要素をグループ化することを特徴とする請求項１４に記載のシステム。
17. 前記グループ化要素は、複数の方法で表現され得るプロパティを有することを特徴とする請求項１４に記載のシステム。
18. グループ化要素プロパティが表現され得る１つの方法は、ＸＭＬアトリビュートとして表現される方法であることを特徴とする請求項１７に記載のシステム。
19. グループ化要素プロパティが表現され得る１つの方法は、リソースディクショナリ参照を介するものであることを特徴とする請求項１７に記載のシステム。
20. グループ化要素プロパティが表現され得る１つの方法は、ＸＭＬ子要素として表現されるリソースディクショナリとして表現される方法であり、リソースディクショナリエントリは、前記グループ化要素によってグループ化される要素によって参照され得ることを特徴とする請求項１７に記載のシステム。
21. グループ化要素プロパティが表現され得る１つの方法は、ＸＭＬ子要素として表現される方法であることを特徴とする請求項１７に記載のシステム。
22. 前記グループ化要素は、描画がどのように実行されるかを記述する子要素と、その他の要素をグループ化するグループ化要素とを含み得ることを特徴とする請求項１７に記載のシステム。
23. 描画がどのように実行されるかを記述する前記追加要素の１つは、幾何学的領域を記述する要素を含むことを特徴とする請求項１４に記載のシステム。
24. 前記１つの要素は、複数の方法で表現され得るプロパティを有することを特徴とする請求項２３に記載のシステム。
25. プロパティが表現され得る１つの方法は、ＸＭＬアトリビュートとして表現される方法であることを特徴とする請求項２４に記載のシステム。
26. プロパティが表現され得る１つの方法は、ＸＭＬアトリビュートとして表現される方法であり、プロパティは、テキストまたは幾何学的形状の外観を定義するために使用されることを特徴とする請求項２４に記載のシステム。
27. プロパティが表現され得る１つの方法は、リソースディクショナリ参照を介するものであることを特徴とする請求項２４に記載のシステム。
28. プロパティが表現され得る１つの方法は、リソースディクショナリ参照を介するものであり、プロパティは、テキストまたは幾何学的形状の外観を定義するために使用されることを特徴とする請求項２４に記載のシステム。
29. プロパティが表現され得る１つの方法は、ＸＭＬ子要素として表現される方法であることを特徴とする請求項２４に記載のシステム。
30. プロパティが表現され得る１つの方法は、ＸＭＬ子要素として表現される方法であり、プロパティは、テキストまたは幾何学的形状の外観を定義するために使用されることを特徴とする請求項２４に記載のシステム。
31. 描画がどのように実行されるかを記述する前記追加要素の１つは、幾何学的領域を記述する要素を含み、前記１つの要素は、複数の方法で表現され得るプロパティをもち、イメージが、幾何学的領域によって表され、ImageBrushプロパティが、複数の方法で表現され得ることを特徴とする請求項１４に記載のシステム。
32. 描画がどのように実行されるかを記述する前記追加要素の１つは、テキストを表す要素を含むことを特徴とする請求項１４に記載のシステム。
33. 前記１つの要素は、複数の方法で表現され得るプロパティを有することを特徴とする請求項３２に記載のシステム。
34. 前記１つの要素は、複数の方法で表現され得るプロパティをもち、プロパティは、テキストまたは幾何学的形状の外観を定義するために使用されることを特徴とする請求項３２に記載のシステム。
35. プロパティが表現され得る１つの方法は、ＸＭＬアトリビュートとして表現される方法であることを特徴とする請求項３３に記載のシステム。
36. プロパティが表現され得る１つの方法は、ＸＭＬアトリビュートとして表現される方法であり、プロパティは、テキストまたは幾何学的形状の外観を定義するために使用されることを特徴とする請求項３３に記載のシステム。
37. プロパティが表現され得る１つの方法は、リソースディクショナリ参照を介するものであることを特徴とする請求項３３に記載のシステム。
38. プロパティが表現され得る１つの方法は、リソースディクショナリ参照を介するものであり、プロパティは、テキストまたは幾何学的形状の外観を定義するために使用されることを特徴とする請求項３３に記載のシステム。
39. プロパティが表現され得る１つの方法は、ＸＭＬ子要素として表現される方法であることを特徴とする請求項３３に記載のシステム。
40. 文書をマークアップ表現を用いて表すステップであって、、
    ページの順序付けられたシーケンスを一緒に論理的にバインドして単一の複数ページ文書にする第１の要素と、
    各々が前記第１の要素の子であり、前記文書の関連ページのコンテンツのソースを参照する複数の第２の要素とを含むステップと、
    前記表現を同じ文書の異なる表現を含み得る単一のパッケージに組み入れるステップとを含むことを特徴とする方法。
41. 前記表現の１つは、固定ペイロードを含むことを特徴とする請求項４０に記載の方法。
42. 前記単一のパッケージは、少なくとも以下のパーツ、すなわち、固定ページパーツ、固定パネルパーツ、フォントパーツ、イメージパーツ、構成パーツ、記述的メタデータパーツ、またはプリントチケットパーツから選択されるパーツを含み得ることを特徴とする請求項４０に記載の方法。
43. 各々が文書の異なる表現を含み得る１つまたは複数のパッケージを受け取るステップであって、個々のパッケージはそれぞれマークアップ表現を含み、、
    ページの順序付けられたシーケンスを一緒に論理的にバインドして単一の複数ページ文書にする第１の要素と、
    各々が前記第１の要素の子であり、前記文書の関連ページのコンテンツのソースを参照する複数の第２の要素とを含むステップと、
    単一のパッケージを消費するステップとを含むことを特徴とする方法。
44. 前記表現の１つは、固定ペイロードを含むことを特徴とする請求項４３に記載の方法。
45. 前記１つまたは複数のパッケージの少なくともいくつかは、少なくとも以下のパーツ、すなわち、固定ページパーツ、固定パネルパーツ、フォントパーツ、イメージパーツ、構成パーツ、記述的メタデータパーツ、またはプリントチケットパーツから選択されるパーツを含み得ることを特徴とする請求項４３に記載の方法。

Images