JP2007535747A - ドキュメントに選択可能なまたは／および順序付け可能なパーツを定義する方法およびシステム - Google Patents

Abstract

モジュール形式のコンテンツフレームワークおよびドキュメントフォーマットの方法およびシステムについて説明する。ドキュメント中心のコンテンツの構成、パッケージ化、配布、およびレンダリングのためのビルディングブロックを一式定義する。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムによりドキュメントの生成、交換、および表示を信頼性が高く一貫性のある形で行えるようにするドキュメントフォーマットのためのプラットフォーム依存性のないフレームワークを定義する。この一般的なフレームワークおよびフォーマットに加えて、一般的なフレームワークを使用してリーチパッケージフォーマットと呼ばれる特定のフォーマットが定義される。リーチパッケージのコンテンツは、様々な環境および様々なシナリオにおいて各種デバイスおよびアプリケーションに完全な忠実性を保ちながら表示または印刷をすることができる。

Description

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

今日では、コンテンツを表す様々な種類のコンテンツフレームワーク、および、様々な種類のドキュメントをフォーマットする様々な種類のドキュメントフォーマットがある。多くの場合、関連するドキュメントのビルド、作成、処理、または消費のために、これらのフレームワークおよびフォーマットのそれぞれが、専用の関連するソフトウェアを必要とする。しかるべきデバイスに特定の関連するソフトウェアをインストールしたことのある人にとっては、関連ドキュメントのビルド、作成、処理、または消費は、大きな問題ではない。しかるべきソフトウェアを所有していない人にとっては、関連ドキュメントのビルド、作成、処理、または消費は、通常、不可能である。

このような背景において、ドキュメントの作成と消費に関して、遍在性（Ｕｂｉｑｕｉｔｙあらゆるところで使用できること）に対する要求が絶えずある。モジュール形式のコンテンツフレームワークおよびドキュメントフォーマットの方法およびシステムについて説明する。

説明されるフレームワークおよびフォーマットでは、ドキュメント中心のコンテンツの構成、パッケージ化、配布、および表示のためのビルディングブロックの一式を定義する。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムによりドキュメントの生成、交換、および表示を信頼性が高く一貫性のある形で行えるようにするドキュメントフォーマットのためのプラットフォーム依存性のないフレームワークを定義する。このフレームワークおよびフォーマットは、自由度が高く、拡張性のある方式で設計されている。

この一般的なフレームワークおよびフォーマットに加えて、一般的なフレームワークを使用して「リーチパッケージ」フォーマット（ｒｅａｃｈ ｐａｃｋａｇｅ ｆｏｒｍａｔ）と呼ばれる特定のフォーマットが定義される。リーチパッケージフォーマットは、ページ付けされたドキュメントを保存するためのフォーマットである。リーチパッケージのコンテンツは、様々な環境および様々なシナリオにおいて各種デバイスおよびアプリケーションに完全な忠実性を保ちながら、表示または印刷することができる。

概要
本明細書では、モジュール形式のコンテンツフレームワークおよびドキュメントフォーマットについて説明する。フレームワークおよびフォーマットでは、ドキュメント中心のコンテンツの構成、パッケージ化、配布、および表示のためのビルディングブロックの一式を定義する。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムによるドキュメントの生成、交換、および表示を、信頼性が高く一貫性のある形で行えるようにするドキュメントフォーマットのための、プラットフォーム依存性のないフレームワークを定義する。このフレームワークおよびフォーマットは、自由度が高く、拡張性のある方式で設計されている。様々な実施形態においては、取り込めるコンテンツの種類、コンテンツの提示方法、またはコンテンツの取り扱いのためクライアントをビルドするプラットフォームに関して、なんら制約はない。

この一般的なフレームワークのほかに、一般的なフレームワークを使用して特定のフォーマットを定義する。このフォーマットは、本明細書ではリーチパッケージフォーマットと呼ばれ、ページ付けされたまたは事前ページ付けされたドキュメントの保存ためのフォーマットである。リーチパッケージのコンテンツは、様々な環境および様々なシナリオにおいて、各種デバイスおよびアプリケーションに完全な忠実性を保ちながら表示または印刷することができる。

後述のフレームワークの複数の目標のうちの１つは、後述のフレームワークおよびフォーマットにより作成されるコンテンツを読み書きする、独立して作成されたソフトウェアおよびハードウェアシステムの相互運用性を保証しようということである。この相互運用性を実現するために、説明されているフォーマットは、コンテンツを読み書きするシステムが満たしていなければならない正式な要求条件を定義する。

以下の説明は、以下の行に構成され、「フレームワーク」という表題のセクションと「リーチパッケージフォーマット」という表題のセクションの２つの主要セクションに分けられる。

「フレームワーク」という表題のセクションは、具体的なパッケージ化モデルを示し、フレームワークパッケージを構成する様々なパーツおよび関係を説明する。フレームワークパッケージにおける記述的メタデータ（ｄｅｓｃｒｉｐｔｉｖｅ ｍｅｔａｄａｔａ）の使用に関する情報を取りあげるとともに、物理的コンテナへのマッピング、フレームワークマークアップの拡張、およびフレームワークバージョン管理機構の使用のプロセスについても説明する。

「リーチパッケージフォーマット」という表題のセクションでは、リーチパッケージと呼ばれるある特定の種類のフレームワークビルドパッケージの構造を検討する。このセクションでは、さらに、固定ペイロードに特有のパッケージパーツについて説明し、リーチパッケージのマークアップモデルおよび描画モデルを定義する。このセクションでは、リーチマークアップ要素およびそのプロパティとさらに具体的なサンプルで締めくくる。

引き続く説明のハイレベルの概要として、図１を考察する。ここでは、一般的に１００で表される本発明のフレームワークおよびフォーマットのいくつかの態様を考察する。フレームワークのいくつかのコンポーネントの実施例が１０２に例示されており、リーチパッケージフォーマットのいくつかのコンポーネントが１０４に例示されている。

フレームワーク１０２は、関係コンポーネント、プラガブルコンテナコンポーネント、インタリービング／ストリーミングコンポーネント、およびバージョン管理／拡張性コンポーネントなどのコンポーネントの実施例を含み、それぞれを以下で詳しく調べる。リーチパッケージフォーマット１０４は、セレクタ／シーケンサコンポーネントおよびパッケージマークアップ定義コンポーネントを含むコンポーネントを含む。

以下の説明では、定期的に図１に戻り、説明されているコンポーネントが、このフレームワークおよびパッケージフォーマットのどこに適合するかを読者が常に概観できるようにする。

フレームワーク
以下の説明では、一般的フレームワークを取りあげる。独立した主要な小見出しは、「パッケージモデル」、「構成パーツ：セレクタおよびシーケンス」、「記述的メタデータ」、「物理的モデル」、「物理的マッピング」、および「バージョン管理および拡張性」である。それぞれの主要な小見出しは、１つまたは複数の関連する小見出しを持つ。

パッケージモデル
このセクションでは、パッケージモデルについて説明し、パッケージおよびパーツ、ドライバ、関係、パッケージ関係、および開始パーツを説明する小見出しが用意される。

パッケージおよびパーツ
例示され、説明されているモデルでは、コンテンツは１つのパッケージ内に保持される。パッケージは、関連するパーツのコレクションを保持する論理エンティティである。パッケージの目的は、ドキュメントのすべての断片（または他の種類のコンテンツ）を集めて、プログラマおよびエンドユーザが簡単に取り扱える１つのオブジェクトにまとめることである。例えば、図２を考察すると、これは、ドキュメントを表すＸＭＬマークアップパーツ２０２、ドキュメント内で使用されるフォントを記述するフォントパーツ２０４、ドキュメントのページを記述する多数のページパーツ２０６、およびドキュメント内の画像を表す画像パーツ２０８を含む多数のパーツからなる、ドキュメントを保持するパッケージ２００を例示している。ドキュメントを表すＸＭＬマークアップパーツ２０２は、パッケージのコンテンツ全体を解析することなく、検索および参照を容易に行えるという点で有益である。これは、以下においてさらに明白になる。

本明細書全体を通じて、リーダー（消費者ともいう）およびライター（作成者ともいう）という概念を導入し説明する。リーダーという用語は、本明細書で使用されているように、モジュール形式のコンテンツフォーマットベースのファイルまたはパッケージを読み込むエンティティを指す。ライターという用語は、本明細書で使用されているように、モジュール形式のコンテンツフォーマットベースのファイルまたはパッケージを書き込むエンティティを指す。例えば、図３を考察すると、これは、パッケージを作成するライターとパッケージを読み込むリーダーを示している。通常、ライターおよびリーダーは、ソフトウェアとして具体化される。少なくとも一実施形態においては、パッケージの作成およびフォーマットに関連する処理のオーバーヘッドおよび複雑さの大半を、ライター側に負わせる。こうすると、処理の複雑さおよびオーバーヘッドの多くがリーダー側から取り除かれ、当業者であれば理解できるように、これは、多くの現行のモデルからは、新機軸となっている。この側面は、以下においてさらに明らかになる。

少なくとも一実施形態によれば、単一パッケージは、パッケージに保持されているコンテンツの１つまたは複数の表現を含む。多くの場合、パッケージは単一ファイルであり、この明細書においては、コンテナと呼ばれるものである。これは、例えば、エンドユーザがドキュメントのコンポーネント断片（イメージ、フォント、データなど）をすべて付属させてドキュメントを配布する便利な手段となる。パッケージは直接単一ファイルに対応するが、これは必ずしも常にそうであるというわけではない。パッケージは、様々な方法（限定されないが、例えば、単一ファイル、バラバラのファイルのコレクション、データベース、ネットワーク接続を介した一時的移動など）で物理的に表現できる論理エンティティである。したがって、コンテナにパッケージが保持されるが、すべてのパッケージがコンテナの中に格納されるわけではない。

抽象モデルは、物理的な記憶機構とは無関係にパッケージを記述する。例えば、抽象モデルでは、「ファイル」、「ストリーム」、または、パッケージが置かれている物理的世界に関連する他の物理的な用語を参照しない。後述するように、抽象モデルを使用すると、ユーザは、様々な物理的フォーマット、通信プロトコルなどに対するドライバを作成することができる。類推により、アプリケーション側でイメージを印刷したい場合は、プリンタの抽象化を使用する（特定の種類のプリンタを認識するドライバにより与えられる）。したがって、アプリケーション側では、特定の印刷デバイスについて、または印刷デバイスとの通信方法について知る必要がない。

コンテナは、他の方法ではバラバラのファイルのコレクションになりうるものに比べて、多くの点で勝っている。例えば、類似のコンポーネントを集めて、コンテンツにインデックスを付け、圧縮することができる。さらに、コンポーネント間の関係を識別し、権利管理、電子署名、暗号化、およびメタデータをコンポーネントに適用することができる。もちろん、コンテナは、特に上で列挙していない他の機能についても使用することができ、またそれらの機能を実現することができる。

共通パーツプロパティ
例示され、説明されている実施形態では、パーツは、共通プロパティ（例えば、名前）および複数バイトからなるストリームを含む。これは、ファイルシステム内のファイル、またはＨＴＴＰサーバ上のリソースに類似している。コンテンツに加えて、それぞれのパーツは、いくつかの共通パーツプロパティを持つ。これらは、名前−パーツの名前と、コンテンツタイプ−パーツ内に格納されているコンテンツのタイプを含む。パーツは、さらに、後述するように、１つまたは複数の関連付けられた関係（ｒｅｌａｔｉｏｎｓｈｉｐ）を持つ。

パーツ名は、何らかの方法でパーツを参照する必要が生じたときに必ず使用される。例示され説明されている実施形態においては、名前は階層方式で構成され、ファイルシステム上のパスまたはＵＲＩによるパスに類似している。以下にパーツ名の例を示す。

上に示されているように、この実施形態では、パーツ名は以下の特性を持つ。

・パーツ名は、従来のファイルシステムのファイル名に類似している。

・パーツ名は、スラッシュ（「／」）で始まる。

・ファイルシステムのパスまたはＵＲＩのパスのように、パス名は一組のディレクトリ風の名前（上の例では、ｔｉｃｋｅｔｓ、ｉｍａｇｅｓ／ｍａｒｃｈ、およびｐａｇｅｓ）により階層形式で構成することができる。
・ この階層は、スラッシュで区切られた複数のセグメントからなる。

・名前の最後のセグメントは、従来のファイルシステムのファイル名と似ている。

パーツに名前を付ける規則、特にパーツ名に使用することができる有効な文字は、本明細書で説明されているフレームワークに固有のものであることに注意することが重要である。これらのパーツ名規則は、インターネット標準ＵＲＩ命名規則に基づいている。この実施形態においては、この実施形態でパーツ名を指定するために使用する文法はａｂｓ＿ｐａｔｈ構文と正確に一致する。ａｂｓ＿ｐａｔｈ構文は、ＲＦＣ２３９６のセクション３．３（パスコンポーネント）および（Uniform Resource Identifiers（ＵＲＩ：Generic Syntax）仕様の５（Relative URI References）で定義されている。

以下の追加制約事項が、ａｂｓ＿ｐａｔｈに有効なパーツ名として適用される。

・クエリコンポーネントは、セクション３（ＵＲＩ構文コンポーネント）および３．４（クエリコンポーネント）で定義されているように、パーツ名には適用できない。

・フラグメント識別子は、セクション４．１（フラグメント識別子）で説明されているように、パーツ名には適用できない。

・＊（「／」セグメント）を既存のパーツのパーツ名に付加することにより作成された名前を持つパーツがあるのは不正である。

パーツ名の文法は、以下のとおりである。

パッケージ内のすべてのパーツの名前のセグメントは、木を形成することがわかる。これは、ファイルシステム内で生じていることに類似しており、ファイルシステムにおいては、木の葉以外のすべての節点はフォルダであり、葉節点はコンテンツが含まれる実際のファイルである。名前の木のこれらのフォルダに似た節点（つまり、葉以外の節点）は、パッケージ内でパーツを編成する類似の機能に使用される。しかし、これらの「フォルダ」は命名階層内において、概念としてのみ存在する、つまり永続性フォーマットによる他の現れ方はないということを忘れないことが重要である。

パーツ名は、「フォルダ」レベルでは存続しえない。特に、パーツ命名階層（「フォルダ」）内の葉以外の節点は、パーツおよび同じ名前のサブフォルダを含むことはできない。

例示され説明されている実施形態においては、すべてのパーツは、パーツ内にどのようなタイプのコンテンツが格納されるかを識別するコンテンツタイプを持つ。コンテンツタイプの例には、以下のものがある。

image/jpeg
text/xml
text/plain;charset="us-ascii"

コンテンツタイプは、ＲＦＣ２０４５（Multipurpose Internet Mail Extensions；（ＭＩＭＥ））で定義されているように、例示されているフレームワーク内で使用される。特に、それぞれのコンテンツタイプは、媒体タイプ（例えば、text）、サブタイプ（例えば、plain）、およびｋｅｙ＝ｖａｌｕｅ形式の任意のパラメータ群（例えば、charset=“us-ascii”）を含み、パラメータが複数ある場合は、パラメータ同士をセミコロンで区切る。

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

パッケージ内でＵＲＩを使用できるようにするために、パッケージベースのコンテンツでＵＲＩを評価するときに、特別なＵＲＩ解釈規則を使用しなければならない。パッケージ自体はＵＲＩ参照に関する「権限」として処理されるべきであり、ＵＲＩのパスコンポーネントが、パッケージ内のパーツ名階層をナビゲートするのに使用される。

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

コンテナ内の一方のパーツから他方のパーツへの参照を設定する必要がある場合には、相対ＵＲＩを使用すべきである。相対参照を使用すると、コンテナのコンテンツをまとめて異なるコンテナに（または、例えばファイルシステムからコンテナ内に）移動することができ、相互パーツ参照を修正しなくて済む。

パーツからの相対参照は、その参照を含むパーツの「ベースＵＲＩ」に相対的に解釈される。デフォルトでは、パーツのベースＵＲＩはパーツの名前である。

以下の名前を持つパーツを含むコンテナを考察する。
/markup/page.xml
/images/picture.jpeg
/images/other_picture.jpeg

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

いくつかのコンテンツタイプは、コンテンツ内の異なるベースを指定することによりデフォルトのベースＵＲＩに優先する手段を提供する。これらの優先の１つが存在していれば、明示的に指定されたベースＵＲＩをデフォルトの代わりに使用しなければならない。

ときには、パーツ内の一部または特定のポイントを「アドレス指定」することが有用なこともある。ＵＲＩ世界では、フラグメント識別子が使用される［例えば、ＲＦＣ２３９６を参照］。コンテナでは、この機構は同じ働きをする。特に、フラグメントは、アドレス指定されたパーツのコンテンツタイプに関して理解されている追加情報を含む文字列である。例えば、ビデオファイルでは、フラグメントはフレームを識別し、ＸＭＬファイルでは、ｘｐａｔｈを介してＸＭＬファイルの一部を識別することができる。

フラグメント識別子を、パーツをアドレス指定するＵＲＩとともに使用して、アドレス指定されたパーツのフラグメントを識別する。フラグメント識別子はオプションであり、シャープ記号（「＃」）によりＵＲＩから区切られる。したがって、これはＵＲＩの一部ではないが、ＵＲＩとともに使用されることが多い。

以下の説明においては、パッケージおよびパーツの命名モデルはかなり自由度が大きいので、パーツ命名のためのある種のガイダンスを与える。このような自由度があるため、フレームワークパッケージを幅広く適用できるのである。しかし、フレームワークは、複数の無関係のソフトウェアシステムが互いに衝突せずにパッケージの「固有」パーツを操作できるシナリオを可能にする設計となっていることを認識することが重要である。これを可能にするため、いくつかの指針が用意されており、この指針に従えばこれが可能になる。

ここで与えた指針は、パーツ命名の衝突発生を最小にするか、または少なくとも減らし、発生した場合に対処するための機構について説明したものである。パッケージ内にパーツを作成するライターは、パッケージ内の既存のパーツとの命名の衝突を検出して対処するステップを実行しなければならない。名前の衝突が発生しても、ライターはむやみに既存のパーツを置き換えなくてよい。

パッケージが単一のライターにより操作されることが保証されている状況では、そのライターはこれらの指針から逸脱してもよい。しかし、複数の独立したライターが１つのパッケージを共有している可能性がある場合、すべてのライターがこれらの指示に従う必要がある。しかし、いずれにしてもすべてのライターがこれらの指針に従うことを推奨する。

・既存のコンテナにパーツを追加するライターは、パーツをルートまたは既存のフォルダ内に直接置くのではなく、命名階層の新しい「フォルダ」内でそうする必要がある。このようにして、名前の衝突の可能性は、パーツ名の第１のセグメントに限られる。この新しいフォルダ内に作成されたパーツは、既存のパーツとの衝突のリスクを犯さずに名前を付けることができる。

・フォルダの「好ましい」名前がすでに、既存のパーツにより使用されている場合、ライターは、他のフォルダ名を選択する何らかの戦略をとらなければならない。ライターは、使用可能なフォルダ名が見つかるまで好ましい名前に桁を付加して行く戦略をとらなければならない（何回か失敗を繰り返してからＧＵＩＤを使用することも考えられる）。

・このポリシーの１つの結果として、リーダーは「マジック」または「よく知られている」パーツ名を介してパーツを特定することを試みなくてよくなる。その代わりに、ライターは、作成されるフォルダ毎に少なくとも１つのパーツとのパッケージ関係を作成しなければならない。リーダーは、よく知られている名前に依存するのではなく、それらのパッケージ関係を使用してパーツを特定しなければならない。
・リーダーがフォルダ内に少なくとも１つのパーツを見つけると（前述のパッケージ関係の１つを介して）、そのフォルダ内でよく知られているパーツ名に関する規約を使用して、他のパーツを見つけることができる。

ドライバ
本明細書で説明されているファイルフォーマットは、異なるアプリケーション、異なるドキュメントタイプなどにより使用されることができ、そのうち多くのものが衝突する用途、衝突するフォーマットなどを持つ。１つまたは複数のドライバを使用して、ファイルフォーマットの相違、通信プロトコルの相違など様々な衝突を解決する。例えば、ばらばらのファイルおよび複合ファイルなど様々なファイルフォーマット、ｈｔｔｐ、ネットワーク、および無線プロトコルなど、様々な通信プロトコルがある。各種ドライバ群は、様々なファイルフォーマットおよび通信プロトコルを抽象化して、単一のモデルにまとめたものである。異なるシナリオ、異なる顧客要件、異なる物理的構成などに対し、複数のドライバを用意することができる。

関係（ｒｅｌａｔｉｏｎｓｈｉｐｓ）
パッケージ内のパーツは、そのパッケージ内の他のパーツへの参照を含むことができる。しかし、一般に、これらの参照は、参照する側のパーツ内で、そのパーツのコンテンツタイプに特有の方法で、つまり、任意のマークアップまたはアプリケーション固有の符号化によって表現される。これは、実際に、そのような参照を含むパーツのコンテンツタイプを認識しないリーダーからのパーツ間の内部リンクを非表示にする。

共通コンテンツタイプ（「リーチパッケージ」セクションで説明されている固定ペイロードマークアップなど）であっても、リーダーは、他のパーツへの参照を発見し解決するために、パーツ内のすべてのコンテンツを解析する必要があるであろう。例えば、ドキュメントを１度に１ページずつ印刷する印刷システムを実装する場合、特定のページに含まれる画像およびフォントを識別できることが望ましい。既存のシステムでは、各ページのすべての情報を解析しなければならず、これは時間のかかる作業である。また、それぞれのページの言語を認識しなければならず、これは特定のデバイスまたはリーダーによってはあり得ない状況である（例えば、デバイスに向かう途中でプロセッサのパイプラインを通るときにドキュメントに対し中間処理を実行しているもの）。その代わりに、本明細書で説明されているシステムおよび方法では、関係を使うことによって、パーツ間の関係を識別し、それらの関係の性質を記述する。この関係言語は単純であり、リーダーが複数の異なる言語を認識することなしに関係を認識できるように、一度だけ定義される。一実施形態においては、これらの関係は、ＸＭＬで個々のパーツとして表される。それぞれのパーツは、パーツがソースである関係を含む関連付けられた関係パーツを持つ。

例えば、スプレッドシートアプリケーションでは、このフォーマットを使用し、異なるスプレッドシートをパーツとして記憶する。スプレッドシート言語について何も認識しないアプリケーションであっても、そのまま、スプレッドシートに関連付けられている様々な関係を発見することができる。例えば、アプリケーションでは、スプレッドシート内のイメージおよびスプレッドシートに関連付けられているメタデータを発見することができる。関係スキーマの実施例を以下に示す。

このスキーマでは、２つのＸＭＬ要素、つまり「ｒｅｌａｔｉｏｎｓｈｉｐｓ」と呼ばれる要素と「ｒｅｌａｔｉｏｎｓｈｉｐ」と呼ばれる要素を定義している。「ｒｅｌａｔｉｏｎｓｈｉｐ」要素は、本明細書で説明されているような単一の関係を記述するために使用され、属性として（１）ソースパーツの関係先パーツを示す「ｔａｒｇｅｔ」、（２）関係のタイプまたは性質を示す「ｎａｍｅ」を持つ。「ｒｅｌａｔｉｏｎｓｈｉｐｓ」要素は、０または複数の「ｒｅｌａｔｉｏｎｓｈｉｐ」要素を保持できるように定義され、単純に、それらの「ｒｅｌａｔｉｏｎｓｈｉｐ」要素を集めて１つのユニットにまとめるために使用される。

本明細書で説明されているシステムおよび方法は、さらに高いレベルの機構を導入して、「関係（ｒｅｌａｔｉｏｎｓｈｉｐｓ）」と呼ばれるこれらの問題を解決する。関係は、パッケージ内のソースパーツとターゲットパーツとの間の接続の種類を表す追加的な手段を提供する。関係は、パーツ内のコンテンツを見ることなしに、直接的に、「発見可能」なパーツ間を接続する。それらはコンテンツ特有のスキーマとは無関係であり、解決が速い。さらに、これらの関係はプロトコルの依存性がない。様々な異なる関係を、特定のパーツに関連付けることができる。

関係は、第２の重要な機能を持ち、パーツを修正することなく関連付けことができる。ときには、この情報は、「注釈」という形で使用され、その場合「注釈付き」パーツのコンテンツタイプでは、与えられた情報を添付する手段を定義しない。実施例として可能なものには、添付された記述的メタデータ、プリントチケット、および実際の注釈がある。最後に、シナリオによっては、情報を既存のパーツに、特にそのパーツを修正せずに添付する必要があるものもある。例えば、パーツが暗号化されているときに解読できない場合や、パーツが電子署名されており、変更すると署名が無効になるような場合である。他の例では、ユーザはＪＰＥＧイメージファイルに注釈を添付したい場合がある。ＪＰＥＧイメージフォーマットは、現在のところ、注釈の識別をサポートしていない。ＪＰＥＧフォーマットを変更してこのユーザの希望をかなえるようにすることは、現実的ではない。しかし、本明細書で説明されているシステムおよび方法を使用することによって、ユーザはＪＰＥＧイメージフォーマットを修正せずに、ＪＰＥＧファイルに注釈を付加することができる。

一実施形態では、関係は、関係バーツ内においてＸＭＬを使用することで表される。１つまたは複数の関係のソースであるコンテナ内のそれぞれのパーツは、関係パーツが関連付けられている。この関係パーツは、そのソースパーツの関係のリストを保持する（コンテンツタイプａｐｐｌｉｃａｔｉｏｎ／ＰＬＡＣＥＨＯＬＤＥＲを使用してＸＭＬで表される）。

以下に示す図４は、「スパイン」パーツ４０２（ＦｉｘｅｄＰａｎｅｌに似ている）が３つのページ４０６、４０８、および４１０をバインドしてまとめる環境４００を示している。スパインによりバインドされまとめられたページ群は、「プリントチケット」４０４が関連付けられる。さらに、２ページ目には、専用のプリントチケット４１２がある。スパインパーツ４０２からプリントチケット４０４、および２ページ目からそのプリントチケット４１２までの接続は、関係を使って表される。図４の配置では、スパインパーツ４０２は、以下の実施例で示されているように、スパインをｔｉｃｋｅｔ１に接続する関係が含まれる関連付けられた関係パーツを持つ。

関係は、単一の＜Ｒｅｌａｔｉｏｎｓｈｉｐｓ＞要素内に入れ子になっている＜Ｒｅｌａｔｉｏｎｓｈｉｐ＞要素を使用して表される。これらの要素は、http://mmcfrels（ＰＬＡＣＥＨＯＬＤＥＲ）名前空間内で定義される。関係の実施例については、上のスキーマの実施例、および関連する説明を参照のこと。

関係（ｒｅｌａｔｉｏｎｓｈｉｐ）要素は、以下の追加属性を持つ。

Ｎａｍｅ属性は、必ずしも実際のアドレスではない。異なる種類の関係が、Ｎａｍｅｓにより識別される。これらの名前は、名前空間がＸＭＬ名前空間に対し定義されるのと同じようにして定義される。特に、インターネットドメイン名空間にならって付けられた名前を使用することにより、非調整パーティは衝突しない関係名を安全に−ＸＭＬ名前空間について作成するのとちょうど同じようにして−作成できる。

関係パーツは、他の関係に参加することは許されない。しかし、他のすべての意味において１級のパーツである（例えば、ＵＲＩアドレス指定可能である、開く、読む、削除するなどの操作を行えるなど）。関係は、通常、パッケージの外部にあるものは参照しない。関係ターゲットを識別するために使用されるＵＲＩは、一般に、ＵＲＩスキームを含まない。

パーツおよび関連付けられた関係パーツは、命名規約により接続される。この例では、スパインに対する関係パーツは、/content/_rels/spine.xml.relsに格納され、ページ２に対する関係は、/content/_rels/p2.xml.relsに格納される。ここでは２つの特別な命名規約が使用されていることに注意されたい。まず、名前階層内の与えられた「フォルダ」内のある（他の）パーツに対する関係パーツは、_relsと呼ばれる「サブフォルダ」内に格納される（関係を識別するために）。第２に、この関係保持パーツの名前は、.rels拡張子をオリジナルのパーツの名前に付加することにより形成される。特定の実施形態では、関係パーツは、コンテンツタイプａｐｐｌｉｃａｔｉｏｎ／ｘｍｌ＋ｒｅｌａｔｉｏｎｓｈｉｐｓＰＬＡＣＥＨＯＬＤＥＲである。

関係は、２つのパーツの間の有向接続を表す。関係を表す方法のため、ソースパーツから関係を行き来する（ｔｒａｖｅｒｓｅ）のが効率よい（任意に与えられたパーツに対する関係パーツを見つけることは自明であるので）。しかし、関係のターゲットから逆方向に関係を行き来するのは効率的ではない（パーツとのすべての関係を見つける方法はコンテナ内のすべての関係を探すことだからである）。

関係の逆方向トラバース（行き来する）を可能にするために、新しい関係を使用して、他の（トラバース可能な）方向を表す。これは、あるタイプの関係の設計者が使用できるモデリング手法である。上の例に従うと、ｔｉｃｋｅｔ１が添付されているスパインを見つけられることが重要であるとすれば、以下のようなチケットからスパインに接続する第２の関係を使用する。

パッケージ関係（Ｐａｃｋａｇｅ Ｒｅｌａｔｉｏｎｓｈｉｐｓ）
「パッケージ関係」は、パッケージ内のよく知られているパーツを見つけるために使用される。この方法を用いると、パッケージ内のパーツを見つける際に命名規約に依存しなくてすみ、異なるペイロードの同一のパーツ名の間で、衝突がないことが保証される。

パッケージ関係は、ターゲットはパーツであるが、ソースはパーツではない、つまりソースは全体としてパッケージである特別な関係である。「よく知られている」パーツを備えることは、実際には、そのパーツを見つけやすくする「よく知られている」関係名を持つことである。非調整パーティにより関係に名前を付けることができる明確に定義されている機構があるため、これらは機能するが、いくつかの実施形態においては、パーツ名に対するそのような機構がない。したがって、それらの実施形態においては、一組の指針に制限される。パッケージ関係は、パッケージ関係パーツ内に見つかり、関係パーツに対する標準命名規約を使用して名前が付けられる。そこで、名前は「/_rels/.rels」となる。

このパッケージ関係パーツ内の関係は、よく知られているパーツを見つける際に役立つ。

開始パーツ（Ｔｈｅ Ｓｔａｒｔ Ｐａｒｔ）
パッケージレベルの一例においては、よく知られているパーツはパッケージ「ｓｔａｒｔ」パーツである。これは、パッケージが開かれたときに通常処理されるパーツである。これは、パッケージに格納されているドキュメントコンテンツの論理ルートを表す。パッケージの開始パーツは、よく知られているパッケージ関係に従うことにより特定される。一実施例においては、この関係は、「http://mmcf-start-part-PLACEHOLDER」という名前を持つ。

構成パーツ（Ｃｏｍｐｏｓｉｔｉｏｎ Ｐａｒｔ）：セレクタおよびシーケンス
説明されているフレームワークでは、セレクタおよびシーケンスというパーツから高次の構造を構築するための２つの機構を定義する。

セレクタは、多数の他のパーツのうちから「選択する」パーツである。例えば、セレクタパーツは、英語版のドキュメントを表すパーツとフランス語版のドキュメントを表すパーツのいずれかを「選択する」ことができる。シーケンスは、多数の他のパーツを「順序付ける」パーツである。例えば、シーケンスパーツは、パーツの１つが５ページのドキュメントを表し、もう１つが１０ページのドキュメント表す２つのパーツを（線形的な順序で）組み合わせることができる。

これら２つのタイプの構成パーツ（シーケンスおよびセレクタ）およびそれらを組み立てる規則は、構成モデルからなる。構成パーツは、他の構成パーツを構成することができる。したがって、例えば、２つの構成のうちから選択するセレクタを備えることも可能である。例えば、図５を考察すると、これは、英語とフランス語の両方の表現を含む財務レポートの一例を示している。これらの表現はそれぞれ、さらに、序文（表紙）とそれに続く財務内容（スプレッドシート）からなる。この例では、セレクタ５００は、英語表現のレポートとフランス語表現のレポートのうちから選択する。英語表現が選択された場合、シーケンス５０２により、英語序文パーツ５０６、英語財務パーツ５０８と順序付けられる。あるいはその代わりに、フランス語表現が選択された場合、シーケンス５０４により、フランス語序文パーツ５１０、フランス語財務パーツ５１２と順序付けられる。

構成パーツＸＭＬ
例示され説明されている実施形態においては、構成パーツは、少数のＸＭＬ要素を使用して記述され、すべて共通構成名前空間（ｃｏｍｍｏｎ ｃｏｍｐｏｓｉｔｉｏｎ ｎａｍｅｓｐａｃｅ）から取り出される。例えば、以下を考察する。

例えば、上の図５の例に対するＸＭＬを以下に示す。

このＸＭＬでは、MainDocument.xmlは、パッケージ内のパーツ全体を表し、「ｓｅｌｅｃｔｉｏｎ」タグに基づいて、選択が、「ｉｔｅｍ」タグでカプセル化された異なるアイテム、つまり「EnglishRollup.xml」と「FrenchRollup.xml」との間で選択が行われることを示す。

EnglishRollup.xmlおよびFrenchRollup.xmlは、「ｓｅｑｕｅｎｃｅ」タグに基づき、それぞれの「ｉｔｅｍ」タグによりカプセル化されたそれぞれのアイテムを、順序付けしてまとめるシーケンスである。

したがって、単純なＸＭＬ文法が、セレクタおよびシーケンスの記述のため準備されている。この構成ブロック内のそれぞれのパーツが構築され、１つのオペレーション−選択または順序付けのいずれか−を実行する。パーツの階層を使用することにより、選択およびシーケンスの異なる堅牢なコレクションを構築することができる。

構成ブロック
パッケージの構成ブロック（Ｃｏｍｐｏｓｉｔｉｏｎ Ｂｌｏｃｋ）は、パッケージの開始パーツから到達可能なすべての構成パーツ（セレクタまたはシーケンス）の集合を含む。パッケージの開始パーツがセレクタでもシーケンスでもない場合、構成ブロックは空であると考えられる。開始パーツが構成パーツの場合、それらの構成パーツ内の複数の子＜ｉｔｅｍ＞が、再帰的にトラバースされて、構成パーツの有向非巡回グラフを生成する（非構成パーツに遭遇するとトラバースが停止する）。このグラフが、構成ブロックである（さらに、実施形態により、パッケージが有効であるためには、非巡回グラフでなければならない）。

構成の意味の決定
上で比較的簡単なＸＭＬ文法を確立したが、以下では、コンテンツタイプに基づき選択を行えるような情報を表す手段について説明する。つまり、上述のＸＭＬは、組み立てられ１つの構成にまとめられるパーツをリーダーが特定するのに十分な情報を与える。しかし、構成の性質に関する詳細をリーダーに知らせるほど十分ではない。例えば、２つのパーツを構成する選択が与えられたとすると、リーダーはどのような基準（例えば、言語、用紙サイズなど）に基づいてその選択を行うのか？その答えは、これらの規則は構成パーツのコンテンツタイプに関連付けられているということである。したがって、言語に基づいて表現を選択するのに使用されるセレクタパーツは、用紙サイズに基づいて表現を選択するセレクタパーツと異なる関連付けられたコンテンツタイプを持つ。

一般的なフレームワークでは、以下のコンテンツタイプの一般的形式を定義する。

Application/XML+Selector-SOMETHING
Application/XML+Sequence-SOMETHING
これらのコンテンツタイプの中のSOMETHINGは、選択またはシーケンスの性質、例えば、ページサイズ、色、言語、リーダーデバイス上の常駐ソフトウェアなどを示す単語で置き換えることができる。このフレームワークにおいては、こうすると、すべての種類のセレクタおよびシーケンスを創作することができ、それぞれ非常に異なる意味を持ち得る。

説明されているフレームワークは、さらに、すべてのリーダーまたは読み込みデバイスが認識しなければならない、以下のよく知られているコンテンツタイプを定義する。

例として、以下のような考察をしてみる。パッケージはページを持つドキュメントを含むと仮定し、ページの真ん中にビデオが現れる領域がある。この例では、ページのビデオパーツは、Ｑｕｉｃｋｔｉｍｅビデオの形式のビデオを含むことができる。このシナリオの問題の１つは、Ｑｕｉｃｋｔｉｍｅビデオは広く受け入れられているわけではないという点である。しかしながら、このフレームワーク、さらに具体的には後述のリーチパッケージフォーマットに従って、広く受け入れられているイメージフォーマット−ＪＰＥＧ−があると仮定する。上述のドキュメントを含むパッケージを作成するときに、作成者は、パッケージの一部としてビデオを定義することに加えて、そのページのＪＰＥＧイメージを定義し、ＳｕｐｐｏｒｔｅｄＣｏｎｔｅｎｔＴｙｐｅセレクタを挿入する。これによって、ユーザのコンピュータにＱｕｉｃｋｔｉｍｅビデオを認識するソフトウェアが装備されている場合は、Ｑｕｉｃｋｔｉｍｅビデオが選択され、そうでない場合には、ＪＰＥＧイメージが選択されるようにすることも可能である。

したがって、上述のように、フレームワークレベルのセレクタおよびシーケンスコンポーネントにより、この例では、ＸＭＬで定義されている堅牢な階層を構築できる。さらに、コンテンツタイプを使用して、セレクタおよびシーケンスの挙動を識別する明確に定義された手段もある。さらに、一実施形態においては、一般的なフレームワークは、定義済みで、消費者（例えば、リーダーまたは読み取りデバイス）が何を認識し何を認識しないかに基づいてパッケージの処理および利用を可能にする、１つの特定のコンテンツタイプを含む。

他の構成パーツコンテンツタイプも、類似の規則を使用して定義することができ、その実施例について以下で説明する。

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

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

記述的メタデータは、メタデータプロパティを保持する。メタデータプロパティは、プロパティ名および１つまたは複数のプロパティ値により表される。プロパティ値は、単純データ型を持ち、したがって、それぞれのデータ型は単一のＸＭＬ ｑｎａｍｅで記述される。記述的メタデータプロパティが単純な型を持つという事実は、複雑なＸＭＬの型を持つデータをパッケージに格納できないということを意味するわけではない。この場合、完全なＸＭＬパーツとして情報を保存しなければならない。これが行われると、単純な型のみの使用に関するすべての制約はなくなるが、「フラット」な記述的メタデータプロパティモデルの簡潔さは失われる。

プロパティの集まりを定義する汎用の機構に加えて、この機構を使用して格納される、特定の明確に定義されているドキュメントコアプロパティの集まりがある。これらのドキュメントコアプロパティは、通常、ドキュメントを記述するために使用され、タイトル、キーワード、著者などのプロパティを含む。

最後に、これらのドキュメントコアプロパティを保持するメタデータパーツは、さらに、ドキュメントコアプロパティのほかに、追加カスタム定義プロパティを保持することもできる。

メタデータフォーマット
一実施形態によれば、記述的メタデータパーツは、コンテンツタイプを持ち、以下の規則に従う関係の対象となる。

以下のＸＭＬパターンは、一実施形態により記述的メタデータを表す場合に使用される。マークアップの各コンポーネントに関する詳細は、サンプルの後の表にまとめた。

ドキュメントコアプロパティ
以下に、プロパティの名前、プロパティの型、および説明を含む、ドキュメントコアプロパティの表を示す。

物理的モデル
物理的モデルにより、ライターおよびリーダーによるパッケージの様々な使用法が定義される。このモデルは、ライター、リーダー、およびそれらの間のパイプの３つのコンポーネントに基づく。図６は、ライターおよびリーダーが連携してパッケージに関する通信を行ういくつかの実施例を示す図である。

パイプは、データをライターからリーダーに搬送する。多くのシナリオにおいて、パイプは、単に、ローカルファイルシステムからパッケージをリーダーに読み出させるＡＰＩ呼び出しを含むだけである。これは、直接アクセスと呼ばれる。

しかし、リーダーおよびライターは、ある種のプロトコルを介して互いに通信しなければならない。この通信は、例えば、プロセスの境界にまたがって、またはサーバとデスクトップコンピュータとの間で実行される。これは、ネットワーク接続アクセスと呼ばれ、パイプの通信特性（特に、速度と要求待ち時間）ゆえに重要なものである。

最大の性能を発揮させるために、物理パッケージ設計では、アクセススタイル、レイアウトスタイル、および通信スタイルの３つの重要な領域におけるサポートを考慮しなければならない。

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

ストリーミング作成
ライターがパッケージの作成を開始しても、パッケージに入れられるものを常に知っているとは限らない。一実施例では、アプリケーション側でプリントスプールファイルパッケージのビルドを開始する場合、アプリケーション側では、パッケージに入れる必要のあるページの数がわからない場合がある。他の実施例では、動的にレポートを生成しているサーバ上のプログラムには、レポートを完全に生成するまでは、レポートの長さまたはレポートに含まれる画像の数はわからない。このようなライターを許容するために、物理的パッケージにより、他のパーツがすでに追加されていた場合に、ライターがその後にパーツを動的に追加できるようにしなければならない（例えば、ライターは作成を開始するといくつのパーツが作成されるかをあらかじめ記述しておくように要求されてはならない）。さらに、物理的パッケージを使用することで、ライターはそのパーツの最終的な長さを知らなくてもパーツのコンテンツの書き込みを開始できなければならない。つまり、これらの要件によりストリーミング作成が可能になるのである。

同時作成および消費
高度にパイプライン化されているアーキテクチャでは、ストリーミング作成およびストリーミング消費は、特定のパッケージに対して同時に実行することが可能である。物理的パッケージを設計する際に、ストリーミング作成のサポートとストリーミング消費のサポートで、設計が反対方向に推し進められることがある。しかし、両方をサポートする設計を見つけられる場合も多い。パイプライン化アーキテクチャにはメリットがあるため、物理的パッケージで同時作成および消費をサポートすることを推奨する。

レイアウトスタイル
物理的パッケージは、パーツのコレクションを持つ。これらのパーツは、単純な順序付けとインタリーブの２つのスタイルのうちの１つでレイアウトすることができる。単純な順序付けでは、パッケージ内のパーツは、定められた順序によりレイアウトされる。そのようなパッケージが純粋に直線的な方法で送出される場合、パッケージ内の第１のバイトから始まり、最後のバイトへと続き、第１のパーツのすべてのバイトが最初に到着し、その後、第２のパーツのすべてのバイトが到着し、というように続く。

インタリーブされたレイアウトでは、複数のパーツのバイトがインタリーブされ、いくつかのシナリオではパフォーマンスを改善できる。インタリービングを著しく利用する２つのシナリオとしては、マルチメディアの再生（例えば、ビデオとオーディオを同時に送出する）およびインラインリソース参照（例えば、マークアップファイルの途中でのイメージへの参照）がある。

インタリービングは、インタリーブされたパーツのコンテンツを編成するための特別な規約を通じて処理される。パーツを断片に分け、それらの断片をインタリーブすることにより、元の大きなパーツをそのまま簡単に再構成することが可能としながら、インタリービングの所望の結果を得ることが可能である。インタリービングの仕組みを理解するために、図７では、content.xml ７０２およびimage.jpeg ７０４の２つのパーツを伴う単純な例を示している。第１のパーツ、content.xmlでは、ページのコンテンツを記述し、そのページの真ん中に、ページ上に現れなければならないイメージ（image.jpeg）への参照が置かれている。

インタリービングが価値ある理由を理解するために、図８に示されているように、これらのパーツが単純な順序付けを使用してパッケージ内にどのように配置されるかを考察する。このパッケージを処理している（かつ、バイトを順次受け取っている）リーダーは、content.xmlパーツだけでなくimage.jpegをもすべて受け取るまでは、画像を表示することができない。状況によっては（例えば、パッケージが小さく単純な場合、または通信リンクが高速な場合）、これは問題にならないであろう。他の状況では（例えば、content.xmlが非常に大きいか、または通信リンクは非常に低速だった場合）、content.xmlパーツをすべて読み切ってからでないとイメージを取得できないため、許容できないパフォーマンスとなるか、またはリーダーシステムに妥当とは思えないほどのメモリが要求されることになる。

理想的なパフォーマンスに近づけるためには、content.xmlパーツを分割し、image.jpegパーツを中間に、画像が参照された場所のすぐ後ろに、挿入できるとよいであろう。こうすると、リーダーは早い段階でイメージの処理を開始することができ、したがって、参照に出くわすとすぐに、イメージデータが後に続く。例えば、図９に示されているパッケージレイアウトが生成される。パフォーマンスのメリットがあるため、物理的パッケージがインタリービングをサポートするのが望ましい場合が多い。使用されている物理的パッケージの種類に応じて、インタリービングはサポートされる場合もされない場合もある。物理的パッケージが異なれば、インタリービングの内部表現の取り扱い方も異なる。物理的パッケージがインタリービングをどのように処理しようと、インタリービングは、物理的レベルで実行される最適化であり、１つのパーツが物理的ファイル内で複数の断片に分割されているとしても、それは１つの論理的パーツであり、断片自体はパーツでないことに留意することが重要である。

通信形式
ライターとリーダーとの間の通信は、パーツの順次配送に基づくか、または順序バラバラでアクセスできるパーツへのランダムアクセスにより行うことができる。これらの通信形式のうちのどれを使用するかは、パイプおよび物理的パッケージフォーマットの両方の機能に依存する。一般に、パイプはすべて順次配送をサポートする。物理的パッケージは、順次配送をサポートしなければならない。ランダムアクセスのシナリオをサポートするには、使用しているパイプと物理的パッケージの両方がランダムアクセスをサポートしていなければならない。ある種のパイプは、ランダムアクセスを使用可能にできるプロトコルに基づいている（例えば、バイトレンジのサポートがあるＨＴＴＰ１．１）。これらのパイプが使用されている場合に最大のパフォーマンスを引き出すためには、物理的パッケージでランダムアクセスをサポートすることが推奨される。このようなサポートが行われていないと、リーダーは、必要とするパーツが順次配送されてくるまでひたすら待つことになる。

物理的マッピング
論理パッケージングモデルでは、パッケージ抽象化を定義しており、パッケージの実際のインスタンスは、パッケージのなんらかの特定の物理的表現に基づく。パッケージングモデルは、物理的永続フォーマットだけでなく、様々なトランスポート（例えば、ネットワークベースのプロトコル）にもマッピングすることができる。物理的パッケージフォーマットは、抽象パッケージングモデルのコンポーネントから特定の物理的フォーマットの機能へのマッピングとして説明することができる。パッケージングモデルでは、パッケージのアーカイブ、配布、またはスプーリングに使用すべき物理的パッケージフォーマットを指定しない。一実施形態では、論理的構造のみが指定される。パッケージは、バラバラのファイルのコレクション、.ZIPファイルアーカイブ、複合ファイル、またはその他のフォーマットにより「物理的に」実現することができる。選択されたフォーマットは、ターゲットの消費デバイスまたはそのデバイス用のドライバによりサポートされる。

マッピングされるコンポーネント
それぞれの物理的パッケージフォーマットは、以下のコンポーネントのマッピングを定義する。いくつかのコンポーネントは、オプションであり、特定の物理的パッケージフォーマットではそれらのオプションコンポーネントをサポートしていない場合がある。

共通マッピングパターン

機能が部分的にパッケージングモデルコンポーネントと一致する物理的記憶フォーマットは多数存在する。パッケージングモデルからそのような記憶フォーマットへのマッピングを定義する際に、パッケージングモデルと物理的記憶媒体との間の機能の類似性を利用することが望ましい場合があるが、マッピングのレイヤを使用して追加機能を実現することは、物理的記憶媒体に本来的に持つ機能ではない。例えば、いくつかの物理的パッケージフォーマットは、個々のパーツをファイルシステム内の個別ファイルとして格納することができる。そのような物理的フォーマットでは、多くのパーツ名を直接同じ物理的ファイル名にマッピングするのが自然であろう。有効なファイルシステムファイル名でない文字を使用しているパーツ名は、何らかの種類の回避機構を必要とするかもしれない。

多くの場合、異なる物理的パッケージフォーマットの設計者は、単一の共通マッピング問題に直面する可能性がある。共通マッピング問題の例として、任意のコンテンツタイプをパーツに関連付ける場合と、インタリーブされたレイアウトスタイルをサポートする場合の２つがある。本明細書では、そのような共通マッピング問題に対する共通の解決策を提案する。特定の物理的パッケージフォーマットの設計者は、ここで定義されている共通マッピング解決策を使用するよう奨励されるが、必ずそうしなければならないわけではない。

パーツのコンテンツタイプの識別
物理的パッケージフォーマットのマッピングにより、それぞれのパーツのコンテンツタイプを格納するための機構が定義される。いくつかの物理的パッケージフォーマットは、コンテンツタイプを表すための固有の機構を備える（例えば、ＭＩＭＥによる「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ」ヘッダ）。このような物理的パッケージについては、マッピングにその固有の機構を使用してパーツのコンテンツタイプを表すよう推奨する。他の物理的パッケージフォーマットについては、他の何らかの機構を使用して、コンテンツタイプを表す。これらのパッケージ内でコンテンツタイプを表すための推奨される機構は、タイプストリームと呼ばれる特別な名前のＸＭＬストリームをパッケージに入れることである。このストリームは、パーツではなく、したがって、それ自体ＵＲＩアドレス指定可能ではない。しかし、パーツのインタリーブに使用されるのと同じ機構を使用して物理的パッケージ内でインタリーブすることができる。

タイプストリーム（ｔｙｐｅｓ ｓｔｒｅａｍ）は、最上位レベルの「Ｔｙｐｅｓ」要素、および１つまたは複数の「Ｄｅｆａｕｌｔ」および「Ｏｖｅｒｒｉｄｅ」子要素を持つＸＭＬを含む。「Ｄｅｆａｕｌｔ」要素は、パーツ名拡張子からコンテンツタイプへのデフォルトのマッピングを定義する。これは、ファイル拡張子は多くの場合、コンテンツタイプに対応しているという事実を利用している。「Ｏｖｅｒｒｉｄｅ」要素は、デフォルトのマッピングの対象になっていない、またはデフォルトのマッピングとは整合しないパーツ上で、コンテンツタイプを指定する場合に使用される。パッケージライターは、「Ｄｅｆａｕｌｔ」要素を使用して、パーツ毎の「Ｏｖｅｒｒｉｄｅ」要素の個数を減らすことができるが、必ずそうしなければならないわけではない。

「Ｄｅｆａｕｌｔ」要素は、以下の属性を持つ。

「Ｏｖｅｒｒｉｄｅ」要素は、以下の属性を持つ。

以下に、タイプストリームに含まれるＸＭＬの一実施例を示す。

以下の表は、パーツのサンプルリスト、および上述のタイプストリームにより定義されるような対応するコンテンツタイプをまとめたものである。

パッケージ内のすべてのパーツについて、タイプストリームは、（ａ）１つの一致する「Ｄｅｆａｕｌｔ」要素、（ｂ）１つの一致する「Ｏｖｅｒｒｉｄｅ」要素、または（ｃ）一致する「Ｄｅｆａｕｌｔ」要素および一致する「Ｏｖｅｒｒｉｄｅ」要素の両方（この場合「Ｏｖｅｒｒｉｄｅ」要素が優先する）のいずれかを含む。一般に、与えられた拡張子に対し、高々１つの「Ｄｅｆａｕｌｔ」要素と、与えられたパーツ名に対し、高々１つの「Ｏｖｅｒｒｉｄｅ」要素がある。

タイプストリーム内の「Ｄｅｆａｕｌｔ」要素および「Ｏｖｅｒｒｉｄｅ」要素の順序は、重要ではない。しかし、インタリーブされたパッケージでは、物理的パッケージ内において「Ｄｅｆａｕｌｔ」および「Ｏｖｅｒｒｉｄｅ」要素は、それらが対応するパーツの前に現れる。

インタリービング
すべての物理的パッケージが、本来含まれるものとしてパーツのデータストリームのインタリービングをサポートしているわけではない。一実施形態では、そのような物理的パッケージへのマッピングでは、このセクションで説明されている一般的な機構を使用してパーツのインタリービングを可能にする。この一般的な機構では、パーツのデータストリームを複数の断片に分割してから、他のパーツの断片、またはパーツ全体とインタリーブするという方法によって動作する。パーツの個々の断片は、物理的マッピング内に存在し、論理的パッケージングモデルではアドレス指定できない。断片のサイズは０であってもよい。

パーツ名からパーツの個々の断片の名前への以下の独特なマッピングが定義され、リーダーは断片を縫い合わせるようにして元の順序に戻し、パーツのデータストリームを形成することができる。

与えられたパーツ名の断片名を導出するための文法は、以下のとおりである。

この文法により生成されたｐｉｅｃｅ＿ｎａｍｅｓに対しては、以下の妥当性制約条件が存在する。

・断片番号は０から始まり、正の連続する整数である。断片番号は左側が０でパッディングされる。

・パーツの断片の集まりの中の最後の断片は、断片名の中で「.piece」の前に「.last」が付く。

・物理的パッケージ内で名前にマッピングされる前に、断片名は論理的パーツの名前から生成される。

断片を自然な順序で格納する必要はないが、そのような格納方法をとれば最適な効率が得られる可能性がある。インタリーブされた（断片化された）パーツを収めた物理的パッケージは、さらに、非インタリーブ（ワンピース）パーツを含むこともでき、したがって、以下の例は有効であろう。

特定のマッピング
「Ｗｉｎｄｏｗｓ（登録商標）ファイルシステム内のバラバラのファイル」では、次の物理的フォーマットの特定のマッピングを定義する。

Ｗｉｎｄｏｗｓ（登録商標）ファイルシステム内のバラバラのファイルへのマッピング
論理的モデルの要素を物理的フォーマットにマッピングする方法をよく理解できるように、ＭｅｔｒｏパッケージをＷｉｎｄｏｗｓ（登録商標）ファイルシステム内のバラバラのファイルのコレクションとして表す基本的な場合について考察する。論理的パッケージ内のそれぞれのパーツは、別々のファイル（ストリーム）に格納される。論理的モデル内のそれぞれのパーツ名は、ファイルの名前に対応している。

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

以下に、論理的パーツ名セグメント（ＵＲＩセグメント）およびＷｉｎｄｏｗｓ（登録商標）ファイル名に対し有効な２つの文字集合を示す。この表は、以下の重要な２つの事項を明らかにする。

ＵＲＩをファイル名に変換する際にはエスケープする必要がある、２つの有効なＵＲＩ記号であるコロン（：）とアスタリスク（＊）がある。

ＵＲＩ内に存在し得ない有効なファイル名の記号＾｛｝［］＃がある（これらは、インタリービングなどの特別のマッピング目的に使用することができる）。

「エスケープ」は、パーツ名にファイル名内で使用できない文字が含まれている場合に有効なファイル名文字を作り出すための一手法として使用される。文字をエスケープするには、キャレット記号（＾）の後にその文字の１６進数表現を続ける。

ａｂｓ＿ｐａｔｈ（パーツ名）からファイル名にマッピングするには、以下のようにする。

先頭の／を除去し、
すべての／を＼に変換し、
コロンとアスタリスク文字をエスケープする
例えば、パーツ名/a：b/c/d*.xamlはa^25b\c\d^2a.xamlにというファイル名になる。

逆のマッピングを実行するには、以下のようにする。

すべての＼を／に変換し、
／を文字列の先頭に追加し、
＾［１６進数コード］を対応する文字で置き換えることにより文字のエスケープを解除する

バージョン管理と拡張性
他の技術的仕様と同様、本明細書に含まれる仕様は、将来の技術的進歩とともに発展する可能性がある。この仕様の第１版の設計は、第１版に基づいて書かれたソフトウェアシステムと将来の版に合わせて書かれたソフトウェアシステムとの間でドキュメントを将来交換できるようにする計画を含んでいる。同様に、この仕様により、第三者が仕様に対する拡張機能を作成することができる。このような拡張により、例えば、ある特定のプリンタの存在を認識しない他のリーダーとの互換性を維持しつつ、そのプリンタの機能を利用するドキュメントを構成することができる。

新しいバージョンの固定ペイロードマークアップ、またはマークアップに対するサードパーティー拡張を使用するドキュメントでは、リーダー側で、挙動に関する適切な決定を下す必要がある（例えば、視覚的に表示する方法）。リーダーのガイドとなるように、ドキュメントの作成者（またはドキュメントを生成したツール）は、他の方法では認識されない要素または属性に出会ったリーダーの、適切な挙動を識別しなければならない。リーチドキュメントについては、このタイプのガイダンスが重要である。

新しいプリンタ、ブラウザ、およびその他のクライアントは、将来の機能に対する様々なサポートを実施することができる。新しいバージョンまたは拡張機能を利用するドキュメント作成者は、それらのバージョンの拡張を認識しないリーダーの挙動を慎重に検討しなければならない。

名前空間のバージョン管理
ＸＭＬマークアップ認識は、名前空間のＵＲＩに基づいている。ＸＭＬ名前空間については、リーダーはその名前空間内で定義されているＸＭＬ要素およびＸＭＬ属性の全部を認識するか、またはどれも認識しないことが予想される。リーダーが新しい名前空間を認識しない場合、リーダーはそのドキュメント内で指定されている通りフォールバックレンダリングオペレーション（ｆａｌｌｂａｃｋ ｒｅｎｄｅｒｉｎｇ ｏｐｅｒａｔｉｏｎｓ）を実行する必要がある。

ＸＭＬ名前空間ＵＲＩ「http://PLACEHOLDER/version-control」は、バージョン適応可能なおよび拡張適応可能な固定ペイロードマークアップを構成するために使用されるＸＭＬ要素および属性を含む。固定ペイロードは、中にバージョン管理要素が含まれている必要はない。しかし、適応可能コンテンツをビルドするには、＜ｖｅｒ：Ｃｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓ＞ および ＜ｖｅｒ：ＡｌｔｅｒｎａｔｉｖｅＣｏｎｔｅｎｔ＞ＸＭＬ要素のうちの、少なくとも１つを使用しなければならない。

固定ペイロードマークアップの指定には、ｘｍｌｎｓ ＵＲＩ「http://PLACEHOLDER/pdl」が関連付けられる。固定ペイロード内でこの名前空間を使用することによって、この仕様で定義されている要素のみが使用されることを、リーダーアプリケーションに通知する。この仕様の将来のバージョンには、それ独自の名前空間が付属する。新しい名前空間を知っているリーダーアプリケーションは、旧バージョンで定義されている属性の要素の上位集合をサポートする方法を認識する。新しいバージョンを知らないリーダーアプリケーションは、ＰＤＬへの何らかの未知の拡張であるかのように新しいバージョンのＵＲＩを検討する。これらのアプリケーションは、名前空間の間に関係が存在すること、一方は他方の上位集合であることを認識できない。

下位互換性と「上位」互換性
本明細書で説明されているシステムおよび方法をサポートしているアプリケーションまたはデバイスに関して、旧バージョンの仕様、または仕様の未知の拡張もしくはバージョンを使用してオーサリングされたドキュメントをクライアントが解析し表示することができるということによって、互換性があることが示される。様々なバージョン管理機構で「下位互換性」に対応しているため、後述のように、クライアントは将来の実装において、仕様のダウンレベルバージョンに基づきドキュメントをサポートできる。

プリンタなどの実装されたクライアントがマークアップ言語の将来のバージョンを使用してビルドされたドキュメントを受け取った場合、クライアントは使用可能なレンダリングオプションを解析し、理解することができる。仕様の旧バージョンに基づいて書かれたクライアントソフトウェアが、新しいバージョンの機能を使用したいくつかのドキュメントを処理できることを、「上位互換性」と呼ぶ。上位互換性を使用できるように書かれたドキュメントは、「バージョン適応可能（ｖｅｒｓｉｏｎ−ａｄａｐｔｉｖｅ）」と呼ばれる。

さらに、実装されたクライアントは新しい要素またはプロパティを表す未知の拡張機能を持つドキュメントをサポートできる必要もあるため、様々な意味を付加して「拡張適応可能（ｅｘｔｅｎｓｉｏｎ ａｄａｐｔｉｖｅ）」であるドキュメントのより一般的なケースをサポートする。

プリンタまたはビューアが未知の拡張機能に出会った場合、これは、周囲のコンテンツの適応レンダリングに関するガイダンスのための拡張機能を使用することにより埋め込まれている情報を探す。この適応は、未知の要素または属性を認識されているコンテンツで置き換えることを伴う。しかし、適応は、未知のコンテンツを純粋に無視することを含む他の形を取りうる。明示的なガイダンスがない場合、リーダーは、マークアップ内に認識されていない拡張機能が存在していることを、誤った状態として取り扱わなければならない。ガイダンスが提供されない場合、この拡張機能は、コンテンツを認識するための基本であるとみなされる。レンダリングの失敗が記録され、ユーザに報告される。

このモデルをサポートするために、新しいおよび拡張されたバージョンのマークアップ言語は、名前空間内において関連する拡張機能を論理的にグループ化しなければならない。このようにして、ドキュメント作成者は、最小限度の名前空間の数を使用して拡張機能を利用することができる。

マークアップのバージョン管理
拡張適応可能な挙動をサポートするためのＸＭＬ語彙は、以下の要素を含む。

＜Ｃｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓ＞要素
Ｃｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓは、添付属性を保持できる要素だけでなくＸａｍｌルート要素にも添付できる。＜Ｃｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓ＞要素は、パーサが未知の要素または属性にどのような反応をするかを制御する。通常、このようなアイテムはエラーとして報告される。無視可能な要素をＣｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓプロパティに追加することで、特定の名前空間からのアイテムを無視できることをコンパイラに通知できる。

Ｃｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓは、ＩｇｎｏｒａｂｌｅおよびＭｕｓｔＵｎｄｅｒｓｔａｎｄ要素を含むことができる。デフォルトでは、すべての要素および属性は、ＭｕｓｔＵｎｄｅｒｓｔａｎｄであると想定される。要素および属性は、Ｉｇｎｏｒａｂｌｅ要素をコンテナのＣｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓプロパティに追加することにより、Ｉｇｎｏｒａｂｌｅにできる。要素またはプロパティは、ＭｕｓｔＵｎｄｅｒｓｔａｎｄ要素を入れ子になっているコンテナの１つに追加することにより、これもまたＭｕｓｔＵｎｄｅｒｓｔａｎｄにできる。１つのＩｇｎｏｒａｂｌｅまたはＭｕｓｔＵｎｄｅｒｓｔａｎｄは、同じＣｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓ要素内の特定の名前空間ＵＲＩを参照する。

＜Ｃｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓ＞要素は、コンテナの自タグまたは属性ではなく、コンテナのコンテンツに影響を及ぼす。コンテナのタグまたは属性に影響を及ぼすには、コンテナに互換性規則が含まれていなければならない。Ｘａｍｌルート要素を使用することにより、Ｃａｎｖａｓなどの、この要素を使用しないとルート要素となる要素に対し互換性規則を指定することができる。Ｃｏｍｐａｔｉｂｉｌｉｔｙ．Ｒｕｌｅｓ複合属性は、コンテナ内の第１の要素である。

＜Ｉｇｎｏｒａｂｌｅ＞要素
＜Ｉｇｎｏｒａｂｌｅ＞要素は、囲まれている名前空間ＵＲＩが無視可能であることを宣言する。＜Ｉｇｎｏｒａｂｌｅ＞タグが現在のブロックまたはコンテナブロック内のアイテムの前で宣言され、名前空間ＵＲＩはパーサにとっては未知のものである場合、アイテムは無視可能であるとみなすことができる。ＵＲＩが知られている場合には、Ｉｇｎｏｒａｂｌｅタグは無視され、すべてのアイテムが認識される。一実施形態では、Ｉｇｎｏｒａｂｌｅと明示的に宣言されていないアイテムはすべて認識されなければならない。Ｉｇｎｏｒａｂｌｅ要素は、＜ＰｒｏｃｅｓｓＣｏｎｔｅｎｔ＞および＜ＣａｒｒｙＡｌｏｎｇ＞要素を含むことができ、これらは、要素の無視のされ方を修正するために使用されるだけでなく、ドキュメント編集ツールに、そのようなコンテンツを編集済みドキュメント内にどのように保存するかについてのガイダンスを与えるためにも使用される。

＜ＰｒｏｃｅｓｓＣｏｎｔｅｎｔ＞要素
＜ＰｒｏｃｅｓｓＣｏｎｔｅｎｔ＞要素は、要素が無視される場合に、その要素のコンテンツが、無視された要素のコンテナに含まれているかのように処理されることを宣言する。

＜ＰｒｏｃｅｓｓＣｏｎｔｅｎｔ＞属性

＜ＣａｒｒｙＡｌｏｎｇ＞要素
オプションの＜ＣａｒｒｙＡｌｏｎｇ＞要素は、ドキュメントが修正されたときに、無視可能なコンテンツを保存すべきかどうかをドキュメント編集ツールに通知する。編集ツールが無視可能なコンテンツを保存または破棄するために使用する方法は、編集ツールの領分である。複数の＜ＣａｒｒｙＡｌｏｎｇ＞要素が１つの名前空間内の同じ要素または属性を参照している場合、指定された最後の＜ＣａｒｒｙＡｌｏｎｇ＞が優先する。

＜ＣａｒｒｙＡｌｏｎｇ＞属性

＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞要素
＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞は、Ｉｇｎｏｒａｂｌｅ要素の効果を反転した要素である。この手法は、例えば、代替えコンテンツと組み合わせたときに、有用である。＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞要素により定義された範囲から外れている場合、要素はＩｇｎｏｒａｂｌｅのままである。

＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞属性

＜ＡｌｔｅｒｎａｔｅＣｏｎｔｅｎｔ＞要素
＜ＡｌｔｅｒｎａｔｅＣｏｎｔｅｎｔ＞要素を使用すると、指定されたコンテンツの一部が認識されない場合のための代替えコンテンツを用意できる。ＡｌｔｅｒｎａｔｅＣｏｎｔｅｎｔブロックでは、＜Ｐｒｅｆｅｒ＞および＜Ｆａｌｌｂａｃｋ＞の両方のブロックを使用する。＜Ｐｒｅｆｅｒ＞ブロック内に何か認識されないものがあれば、＜Ｆａｌｌｂａｃｋ＞ブロックのコンテンツが使用される。名前空間を＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞と宣言すれば、フォールバックを使用することを指示することになる。名前空間が無視できると宣言されていて、その名前空間が＜Ｐｒｅｆｅｒ＞ブロック内で使用されている場合、＜Ｆａｌｌｂａｃｋ＞ブロック内のコンテンツは使用されない。

マークアップのバージョン管理の例
＜Ｉｇｎｏｒａｂｌｅ＞の使用
この実施例では、架空のマークアップ名前空間http://PLACEHOLDER/Circleを使用する。この名前空間では、要素Ｃｉｒｃｌｅをその初期バージョンで定義し、将来のバージョンのマークアップ（バージョン２）で導入されるＣｉｒｃｌｅのＯｐａｃｉｔｙ属性、およびさらに後のバージョンのマークアップ（バージョン３）で導入されるＬｕｍｉｎａｎｃｅプロパティを使用する。このマークアップは、バージョン１および２、さらには３およびそれ以上のバージョンでもロード可能である。さらに、＜ＣａｒｒｙＡｌｏｎｇ＞要素により、エディタがｖ３：Ｌｕｍｉｎａｎｃｅを認識しない場合に、ｖ３：Ｌｕｍｉｎａｎｃｅを保存しなければならないことも指定する。

＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞の使用
以下の実施例は、＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞要素の使い方を説明している。

＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞要素を使用すると、ルート要素内でＩｇｎｏｒａｂｌｅと宣言されているとしても、ｖ３：Ｌｕｍｉｎａｎｃｅへの参照はエラーとなる。この手法は、例えば、代わりにバージョン２で追加されたＣａｎｖａｓのＬｕｍｉｎａｎｃｅプロパティを使用する代替コンテンツと組み合わせた場合に有用である。Ｃａｎｖａｓ要素の範囲から外れた場合、ＣｉｒｃｌｅのＬｕｍｉｎａｎｃｅプロパティは再び無視可能である。

＜ＡｌｔｅｒｎａｔｅＣｏｎｔｅｎｔ＞の使用
要素または属性が＜ＭｕｓｔＵｎｄｅｒｓｔａｎｄ＞と宣言されているが、＜ＡｌｔｅｒｎａｔｅＣｏｎｔｅｎｔ＞ブロックの＜Ｐｒｅｆｅｒ＞ブロックでは認識されない場合、＜Ｐｒｅｆｅｒ＞ブロックは丸ごとスキップされ、＜Ｆａｌｌｂａｃｋ＞ブロックがいつものように処理される（つまり、出会ったＭｕｓｔＵｎｄｅｒｓｔａｎｄアイテムはエラーとして報告される）。

リーチパッケージフォーマット
以下の説明では、特定のファイルフォーマットについて説明する。このセクションの個別の主要な小見出しとして、「リーチパッケージフォーマットの紹介」。「リーチパッケージの構造」、「固定ペイロードパーツ」、「ＦｉｘｅｄＰａｇｅマークアップの基本事項」、「Ｆｉｘｅｄ−Ｐａｙｌｏａｄ要素およびプロパティ」、および「ＦｉｘｅｄＰａｇｅマークアップ」がある。それぞれの主要な小見出しは、１つまたは複数の関連する小見出しを持つ。

リーチパッケージフォーマットへの序論
これまではフレームワークの実施例について説明したが、以下の説明は、上述のツールを利用して実現される特有のフォーマットの１つに関する。以下の説明は、１つのフォーマット例を取りあげているにすぎず、請求されている発明の対象の適用を制限する意図ではないことは評価され理解されるであろう。

この実施形態によれば、単一のパッケージに複数のペイロードを入れることができ、それぞれドキュメントの異なる表現として機能を果たす。１つのペイロードは、識別可能な「ルート」パーツ、およびそのルートパーツのその有効な処理に必要なすべてのパーツを含むパーツのコレクションである。例えば、ペイロードは、ドキュメントの固定表現、リフロー可能表現、または任意の表現とすることが可能である。

以下の説明では、固定ペイロードと呼ばれる特定の表現を定義する。固定ペイロードは、ＦｉｘｅｄＰａｎｅｌマークアップを含むルートパーツを持ち、ＦｉｘｅｄＰａｎｅｌマークアップはさらにＦｉｘｅｄＰａｇｅパーツを参照する。以上あわせて、マルチページドキュメントの正確な表示を記述する。

少なくとも１つの固定ペイロードを保持し、後述の他の規則に従うパッケージは、リーチパッケージと呼ばれる。リーチパッケージのリーダーおよびライターは、リーチパッケージフォーマットの仕様に基づいて、自前のパーサおよびレンダリングエンジンを実装することができる。

リーチパッケージの特徴
記載されている実施形態によれば、リーチパッケージでは、ドキュメントの配布、アーカイブ、および表示に関する情報作業者側の要求条件を扱う。知られている表示規則を使用することにより、リーチパッケージは、保存されているフォーマットからあいまいなところなくかつ正確に複製または印刷ができ、しかも、クライアントデバイスまたはアプリケーションは、特定のオペレーティングシステムまたはサービスライブラリに縛られない。さらに、リーチペイロードは中立の、アプリケーションに依存しない方法で表されるため、パッケージを作成するために使用されたアプリケーションがなくても、ドキュメントを普通に表示し、印刷することができる。このような機能を実現するために、固定ペイロードという概念を導入し、リーチパッケージに含める。

記載されている実施形態によれば、固定ペイロードは固定されたページ数を持ち、改ページは常に同じである。固定ペイロード内の１ページのすべての要素のレイアウトはあらかじめ設定される。それぞれのページは固定されたサイズと向きを持つ。したがって、消費側ではレイアウトの計算は一切行う必要はなく、コンテンツを単に表示するだけである。これは、グラフィックスのみならず、テキストにも適用され、これは正確な印刷上の配置で固定ペイロードにより表される。ページのコンテンツ（テキスト、グラフィックス、イメージ）は、強力な、しかし単純なビジュアルプリミティブを一式使用して説明される。

リーチパッケージでは、ページを構成するため様々な機構をサポートしている。ページの１グループを次から次へと「接着」し、「ＦｉｘｅｄＰａｎｅｌ」にまとめる。このページグループは、従来のマルチページドキュメントとほぼ等価である。ＦｉｘｅｄＰａｎｅｌは、その後、さらに、構成−「複合」ドキュメントを組み立てるためビルドシーケンスおよび選択のプロセス−に参加することができる。

例示され、説明されている実施形態では、リーチパッケージは、例えば、一組のＦｉｘｅｄＰａｎｅｌを接着して単一のより大きな「ドキュメント」に仕上げるために使用できる、ＦｉｘｅｄＰａｎｅｌシーケンスと呼ばれる特定の種類の順序列をサポートする。例えば、異なるソースを出所とする、２ページのカバーメモ（ＦｉｘｅｄＰａｎｅｌ）と２０ページのレポート（ＦｉｘｅｄＰａｎｅｌ）の２つのドキュメントを、接着してまとめることを考える。

リーチパッケージでは、「同じ」コンテンツの代替的な表現を含むドキュメントパッケージをビルドするときに使用できる、多数の特定のセレクタをサポートする。特に、リーチパッケージでは、言語、色表現能力、およびページサイズに基づいて選択を行うことができる。したがって、例えば、セレクタを使用してドキュメントの英語表現とフランス語表現のいずれかを選ぶバイリンガルドキュメントを用意することも可能である。

リーチパッケージに構成するためにセレクタおよびシーケンスを使用するこれらの単純な方法に加えて、セレクタおよびシーケンスで他のセレクタおよびシーケンスを参照することにより、強力な集合階層を構築できることに留意することが重要である。この実施形態では、何ができて何ができないかの正確な規則は、以下の「リーチパッケージの構造」という表題のセクションで規定される。

さらに、リーチパッケージは、固定ペイロードでない追加ペイロードを含むことができる。しかし、その代わりに、ドキュメントのよりリッチで、おそらく編集可能な表現となる。これにより、パッケージは、編集アプリケーションで正しく動作するリッチで編集可能なドキュメントだけでなく、視覚的に正確な、編集アプリケーションなしで表示できる表現をも含むことができる。

最後に、この実施形態によれば、リーチパッケージは、プリントチケットと呼ばれるものもサポートしている。プリントチケットは、パッケージが印刷されるときに使用すべき設定を提供するものである。これらのプリントチケットは様々な方法で添付することができ、かなり柔軟性が高い。例えば、プリントチケットをパッケージ全体に「添付」することができ、その設定はパッケージ全体に適用される。プリントチケットは、さらに、構造内の下位のレベル（例えば、個々のページ）に添付することもでき、それらのプリントチケットは、パーツを添付先に印刷するときに使用する優先（Ｏｖｅｒｒｉｄｅ）設定を備える。

リーチパッケージの構造
上で説明したように、リーチパッケージは、「固定」ページ、ＦｉｘｅｄＰａｎｅｌｓ、構成、プリントチケットなどを含む機能群をサポートする。それらの機能群は、パッケージモデルのコアコンポーネントであるパーツと関係とを使用してパッケージ内に表される。このセクションおよび関連する下位セクションでは、「リーチパッケージ」の完全な定義を与える。さらに、これらのパーツおよび関係すべての組み立て、関連付けなどの作業をどのように行わなければならないかを説明する。

リーチパッケージの構造の概要
図１０は、リーチパッケージの実施例および、この実施形態において、パッケージを構成し、またはパッケージ内に見出せる有効な種類の各パーツを示す図である。以下の表は、有効なそれぞれのパーツタイプの一覧であり、またそれぞれについての説明も載せてある。

リーチパッケージは、「どこでも表示して印刷」ドキュメントとなるように設計されているため、リーチパッケージのリーダーおよびライターは、「有効な」リーチパッケージを構成するものについての共通の明確に定義された予測を共有しなければならない。以下では、「有効な」リーチパッケージの定義を与えるために、いくつかの概念を先に定義しておく。

リーチ構成パーツ（Ｒｅａｃｈ Ｃｏｍｐｏｓｉｔｉｏｎ Ｐａｒｔｓ）
リーチパッケージは、パッケージの開始パーツから構成ブロックをトラバースすることにより「発見可能」である少なくとも１つのＦｉｘｅｄＰａｎｅｌを含んでいなければならない。説明されている実施形態によれば、発見プロセスは以下のアルゴリズムに従う。

・パッケージ開始パーツから始めて、構成パーツのグラフを再帰的にトラバースする。

・このトラバースを実行する際に、リーチ構成パーツ（後述）である構成パーツにのみトラバースする。

・グラフのエッジの終端節点（出て行く弧がない節点）すべてを特定する。

これらの終端節点は（＜ｉｔｅｍ＞要素を介して）リーチペイロードのルートと呼ばれるパーツ群を参照する。

固定ペイロード（Ｆｉｘｅｄ Ｐａｙｌｏａｄ）
固定ペイロードは、ルートパーツがＦｉｘｅｄＰａｎｅｌパーツであるペイロードである。例えば、図１０の固定ペイロードはそれぞれ、ルートパーツとして、関連するＦｉｘｅｄＰａｎｅｌパーツを持つ。ペイロードは、ＦｉｘｅｄＰａｎｅｌの有効な処理に必要なパーツのすべての完全閉方（ｃｌｏｓｕｒｅ）を含む。これらに含まれるのは、以下のとおりである。

・ＦｉｘｅｄＰａｎｅｌ自体
・ＦｉｘｅｄＰａｎｅｌ内から参照されるすべてのＦｉｘｅｄＰａｇｅｓ
・ペイロード内のＦｉｘｅｄＰａｇｅｓのどれかにより（直接的に、またはセレクタを通じて間接的に）参照されるすべてのイメージパーツ
・ペイロード内の任意のＦｉｘｅｄＰａｇｅｓで使用されるイメージブラシから直接的または間接的に参照されるすべてのリーチセレクタ（後述）
・ペイロード内のＦｉｘｅｄＰａｇｅｓのどれかにより参照されるすべてのフォントパーツ
・固定ペイロード内の任意のパーツに添付されるすべての記述的メタデータパーツ
・固定ペイロード内の任意のパーツに添付される任意のプリントチケット
リーチパッケージの有効性（Ｖａｌｉｄｉｔｙ）規則
こうして定義が適切に行われたので、説明されている実施形態に従って「有効な」リーチパッケージを記述する適合性規則について説明することにする。

・リーチパッケージは、上述のようにパッケージ関係の標準の機構を使用して定義された開始パーツを持たなければならない。

・リーチパッケージの開始パーツは、セレクタまたはシーケンスのいずれかでなければならない。

・リーチパッケージは、ＦｉｘｅｄＰａｎｅｌである少なくとも１つのリーチペイロードルートを持たなければならない。

・ＰｒｉｎｔＴｉｃｋｅｔパーツは、複数の構成パーツのどれか、複数のＦｉｘｅｄＰａｎｅｌパーツ、または１つまたは複数のＦｉｘｅｄＰａｎｅｌで識別された複数のＦｉｘｅｄＰａｇｅパーツのどれかに添付することができる。この実施例では、これは、http://PLACEHOLDER/HasPrintTicketRel関係を介して行われる。

・ＰｒｉｎｔＴｉｃｋｅｔｓは、これらのパーツのどれかまたはすべてに添付することができる。

・与えられたパーツは、高々１つのＰｒｉｎｔＴｉｃｋｅｔが添付されなければならない。

・記述的メタデータパーツは、パッケージ内の任意のパーツに添付できる。

・ＦｉｘｅｄＰａｙｌｏａｄ内のすべてのＦｏｎｔオブジェクトは、セクション「フォントパーツ」で定義されているフォントフォーマット規則の条件を満たしていなければならない。

・固定ペイロードのＦｉｘｅｄＰａｇｅ内からのイメージの参照は、選択を行い（他のセレクタを通じて再帰的に行う可能性がある）、表示される実際のイメージパーツを見つけることができるセレクタを指すことができる。

・固定ペイロードで使用されるすべてのＩｍａｇｅオブジェクトは、セクション「イメージパーツ」で定義されているフォントフォーマット規則の条件を満たしていなければならない。

・ＦｉｘｅｄＰａｇｅから（直接的に、またはセレクタを通じて間接的に）参照される任意のフォント、イメージ、またはセレクタパーツについて、参照するＦｉｘｅｄＰａｇｅから参照されているパーツへの「必須パーツ」関係（関係名＝http://mmcf-fixed-RequiredResource-PLACEHOLDER）がなければならない。

リーチ構成パーツ
リーチパッケージに含まれる構成パーツは何種類あってもよいが、構成パーツのタイプの明確に定義された集合のみが、本明細書に基づく明確に定義された挙動を持つ。挙動が明確に定義されている構成パーツをリーチ構成パーツと呼ぶ。これら以外のパーツは、リーチパッケージの有効性を判断するときに関係しない。

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

リーチセレクタ
リーチ構成パーツとして定義されているセレクタ構成パーツは、リーチセレクタと呼ばれる。上述のように、言語セレクタは、英語またはフランス語などの自然言語に基づいて表現を選択する。この言語を発見するために、セレクタは各アイテムを検査する。ＸＭＬであるもののみ考察する。これらについては、それぞれのＸＭＬのルート要素を検査して、その言語を判別する。ｘｍｌ：ｌａｎｇ属性が存在していない場合、パーツは無視される。その後セレクタはそれぞれのパーツを次々に検討し、言語がシステムのデフォルト言語と一致する最初のものを選択する。

カラーセレクタは、モノクロかカラーかに基づいて表現を選択する。ページサイズセレクタは、ページサイズに基づいて表現を選択する。コンテンツタイプセレクタは、コンテンツタイプがシステムにより認識できるかどうかに基づいて表現を選択する。

リーチシーケンス
リーチ構成パーツとして定義されているシーケンス構成パーツは、リーチシーケンスと呼ばれる。固定シーケンスでは、固定コンテンツである子を１つのシーケンスにまとめる。

固定ペイロードパーツ（Ｆｉｘｅｄ Ｐａｙｌｏａｄ Ｐａｒｔｓ）
固定ペイロードは、ＦｉｘｅｄＰａｎｅｌパーツ、ＦｉｘｅｄＰａｇｅパーツ、イメージパーツ、フォントパーツ、プリントチケットパーツ、および記述的メタデータパーツを含むことができ、それぞれの小見出しのところで説明する。

ＦｉｘｅｄＰａｎｅｌパーツ
以下に示すように、固定ペイロードのドキュメント構造は、ＦｉｘｅｄＰａｇｅｓをスパインの一部として識別する。スパインパーツとページパーツとの関係は、そのスパインの関係ストリーム内で定義される。ＦｉｘｅｄＰａｎｅｌパーツは、コンテンツタイプａｐｐｌｉｃａｔｉｏｎ／ｘｍｌ＋ＰＬＡＣＥＨＯＬＤＥＲである。

Ｆｉｘｅｄ−Ｐａｙｌｏａｄコンテンツのスパインは、＜ＦｉｘｅｄＰａｎｅｌ＞要素を＜Ｄｏｃｕｍｅｎｔ＞要素内に入れることにより、マークアップで指定する。以下の例では、＜ＦｉｘｅｄＰａｎｅｌ＞要素により、スパイン内に保持されているページのソースを指定している。

＜Ｄｏｃｕｍｅｎｔ＞要素
＜Ｄｏｃｕｍｅｎｔ＞要素は、属性を持たず、子は１つだけ、つまり＜ＦｉｘｅｄＰａｎｅｌ＞を持たなければならない。

＜ＦｉｘｅｄＰａｎｅｌ＞要素
＜ＦｉｘｅｄＰａｎｅｌ＞要素は、ドキュメントスパインであり、ページの順序付きシーケンスを単一のマルチページドキュメントに論理的にバインドして、１つにまとめる。ページについては、常に、その幅と高さを指定するが、＜ＦｉｘｅｄＰａｎｅｌ＞要素は、さらにオプションにより、高さおよび幅を指定することもできる。この情報は、例えば、ページサイズに基づいて代替的な表現を選択することなど、様々な目的のために使用できる。＜ＦｉｘｅｄＰａｎｅｌ＞要素によって高さと幅を指定している場合、通常は、＜ＦｉｘｅｄＰａｎｅｌ＞内のページの幅および高さとを揃えられるが、それらの寸法は、個々のページの高さと幅とを指定しているわけではない。

以下の表は、説明されている実施形態によるＦｉｘｅｄＰａｎｅｌ属性のまとめである。

＜ＰａｇｅＣｏｎｔｅｎｔ＞要素は、＜ＦｉｘｅｄＰａｎｅｌ＞要素の唯一の許容可能な子要素である。＜ＰａｇｅＣｏｎｔｅｎｔ＞要素は、ドキュメントのページ順序と一致する順次マークアップの順序になっている。

＜ＰａｇｅＣｏｎｔｅｎｔ＞要素
各＜ＰａｇｅＣｏｎｔｅｎｔ＞要素は、単一ページのコンテンツのソースへの参照である。ドキュメント内のページ数を判別するには、＜ＦｉｘｅｄＰａｎｅｌ＞に含まれる＜ＰａｇｅＣｏｎｔｅｎｔ＞子の数を数える。

＜ＰａｇｅＣｏｎｔｅｎｔ＞要素は、許容可能な子を持たず、単一の必須属性Ｓｏｕｒｃｅを持ち、これはページのコンテンツに対するＦｉｘｅｄＰａｇｅを参照する。

＜ＦｉｘｅｄＰａｎｅｌ＞要素と同様に、＜ＰａｇｅＣｏｎｔｅｎｔ＞要素は、オプションにより、ＰａｇｅＨｅｉｇｈｔおよびＰａｇｅＷｉｄｔｈ属性を含むことができ、ここでは単一ページのサイズを反映している。必須ページサイズは、ＦｉｘｅｄＰａｇｅパーツで指定され、＜ＰａｇｅＣｏｎｔｅｎｔ＞のオプションサイズは報告のみである。＜ＰａｇｅＣｏｎｔｅｎｔ＞サイズ属性を使用すると、個々のＦｉｘｅｄＰａｇｅパーツをすべてロードして解析することなく、ドキュメントビューアなどのアプリケーションからドキュメントの視覚的レイアウト推定を素早く行うことができる。

以下に示す表は、＜ＰａｇｅＣｏｎｔｅｎｔ＞のまとめであり、属性の説明も載せてある。

ページコンテンツのＵＲＩ文字列は、パッケージに相対的なコンテンツのパーツ位置を参照しなければならない。

ＦｉｘｅｄＰａｇｅパーツ
＜ＦｉｘｅｄＰａｎｅｌ＞内の＜ＰａｇｅＣｏｎｔｅｎｔ＞要素はＦｉｘｅｄＰａｇｅパーツを名前（ＵＲＩ）で参照する。各ＦｉｘｅｄＰａｇｅパーツは、コンテンツの単一ページの表示を記述するＦｉｘｅｄＰａｇｅマークアップを含む。ＦｉｘｅｄＰａｇｅパーツは、コンテンツタイプａｐｐｌｉｃａｔｉｏｎ／ｘｍｌ＋ＰＬＡＣＥＨＯＬＤＥＲ−ＦｉｘｅｄＰａｇｅである。

マークアップでのＦｉｘｅｄＰａｇｅｓの記述
以下に、ソースコンテンツのマークアップで上述のスパインマークアップ例で参照されているページを探す実施例を示す（＜ＰａｇｅＣｏｎｔｅｎｔ Ｓｏｕｒｃｅ＝“ｐ１．ｘｍｌ”／＞）。

以下の表は、ＦｉｘｅｄＰａｇｅプロパティのまとめであり、プロパティの説明も載せてある。

ＦｉｘｅｄＰａｇｅマークアップの読み込み順序
一実施形態では、ＦｉｘｅｄＰａｇｅに含まれるＧｌｙｐｈｓ子要素のマークアップ順序は、ページのテキストコンテンツの所望の読み込み順序と同じでなければならない。この読み込み順序は、ビューア内のＦｉｘｅｄＰａｇｅからの順次テキストの対話形式による選択／コピーのためと、アクセシビリティ技術による順次テキストへのアクセスを可能にするために使用することができる。マークアップ順序と読み込み順序との間の対応関係を保証するのは、ＦｉｘｅｄＰａｇｅマークアップを生成するアプリケーション側の役目である。

イメージパーツ
サポートされているフォーマット
説明されている実施形態によれば、リーチパッケージ内でＦｉｘｅｄＰａｇｅｓにより使用されるイメージパーツは、固定された数のフォーマット、例えば、ＰＮＧまたはＪＰＥＧとすることができるが、他のフォーマットを使用することもできる。

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

当業者であれば理解するであろうが、ＯｐｅｎＴｙｐｅフォントフォーマットは、ＴｒｕｅＴｙｐｅフォントフォーマットの拡張であり、ＰｏｓｔＳｃｒｉｐｔフォントデータおよび複雑な印刷レイアウトのサポートを追加したものである。ＯｐｅｎＴｙｐｅフォントファイルは、ＴｒｕｅＴｙｐｅアウトラインフォントまたはＰｏｓｔＳｃｒｉｐｔアウトラインフォントのいずれかを含む表形式のデータが格納される。

説明されている実施形態によれば、リーチパッケージでサポートされていないフォントフォーマットは、Ａｄｏｂｅ ｔｙｐｅ １、Ｂｉｔｍａｐフォント、隠し属性付きのフォント（システムフラグを使用してそれを列挙するかどうかを決定する）、ベクトルフォント、およびＥＵＤＣフォント（フォントファミリ名がＥＵＤＣ）である。

フォントのサブセット化
固定ペイロードは、後で詳しく説明するＧｌｙｐｈｓ要素を使用してすべてのテキストを表す。この実施形態では、フォーマットは固定なので、ＦｉｘｅｄＰａｙｌｏａｄｓにより要求されるグリフのみを含むように、フォントをサブセット化することが可能である。したがって、リーチパッケージ内のフォントは、グリフの使用法に基づいてサブセット化することができる。サブセット化されたフォントは、オリジナルフォント内のすべてのグリフを含むわけではないが、サブセット化されたフォントは有効なＯｐｅｎＴｙｐｅフォントファイルでなければならない。

プリントチケットパーツ
プリントチケットパーツは、パッケージが印刷されるときに使用できる設定を提供する。これらのプリントチケットは様々な方法で添付することができ、かなり柔軟性が高い。例えば、プリントチケットをパッケージ全体に「添付」することができ、その設定はパッケージ全体に適用される。プリントチケットは、さらに、構造内の下位のレベル（例えば、個々のページ）に添付することもでき、それらのプリントチケットは、パーツを添付先に印刷するときに使用する優先（Ｏｖｅｒｒｉｄｅ）設定を備える。

記述的メタデータ
上述のように、記述的メタデータパーツは、パッケージのライターまたは作成者に、パッケージのリーダーが高い信頼度で発見できるようなプロパティの値を保存する手段を提供する。これらのプロパティは、通常、パッケージ全体だけでなくコンテナ内の個々のパーツに関する追加情報を記録するために使用される。

ＦｉｘｅｄＰａｇｅマークアップの基本事項
このセクションでは、ＦｉｘｅｄＰａｇｅマークアップに関連する一部の基本情報について説明するが、「固定ペイロードおよびその他のマークアップ標準」、「ＦｉｘｅｄＰａｇｅマークアップモデル」、「リソースおよびリソース参照」、および「ＦｉｘｅｄＰａｇｅ描画モデル」のセクションを含む。

固定ペイロードおよびその他のマークアップ標準
リーチパッケージ内の固定ペイロードのＦｉｘｅｄＰａｎｅｌおよびＦｉｘｅｄＰａｇｅマークアップは、Ｗｉｎｄｏｗｓ（登録商標）ＬｏｎｇｈｏｒｎのＡｖａｌｏｎ ＸＡＭＬのマークアップから抽出されたサブセットである。つまり、Ｆｉｘｅｄ Ｐａｙｌｏａｄマークアップは、独立のＸＭＬマークアップフォーマットとして孤立しているが（本明細書で説明しているように）、Ｌｏｎｇｈｏｒｎシステムと同じ方法でオリジナルのマルチページドキュメントのＷＹＳＩＷＹＧ複製をロードし、それを表示する。

ＸＡＭＬマークアップに関するバックグラウンドとして以下について考察する。ＸＡＭＬマークアップは、ユーザがオブジェクトの階層およびオブジェクトの背後にあるプログラミングロジックを、ＸＭＬベースのマークアップ言語として指定できるようにする機構である。これにより、オブジェクトモデルはＸＭＬによって記述できる。このため、マイクロソフト社による．ＮＥＴ ＦｒａｍｅｗｏｒｋのＣｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ（ＣＬＲ）におけるクラスなどの拡張可能クラスを、ＸＭＬにおいてアクセスすることができる。ＸＡＭＬ機構は、ＸＭＬタグをＣＬＲオブジェクトに直接マッピングし、マークアップの中で関連コードを表すことができるようにする機能を備える。様々な実装において、ＸＡＭＬのＣＲＬベースの実装を特に利用する必要はないことは評価され理解されるであろう。むしろ、ＣＬＲベースの実装は、本明細書で説明されている実施形態の背景においては、ＸＡＭＬを採用できる一手段をなすにすぎない。

より具体的に、ＣＬＲ概念（左側のコンポーネント）からＸＭＬ（右側のコンポーネント）へのマッピングの実施例を例示している図１１とともに、以下の点を考察する。名前空間は、リフレクションと呼ばれるＣＬＲ概念を使用するｘｍｌｎｓ宣言内に見つけられる。クラスは、ＸＭＬタグに直接マッピングされる。プロパティおよびイベントは、直接属性にマッピングされる。この階層を使用することにより、ユーザは、ＸＭＬマークアップファイル内のＣＬＲオブジェクトの階層木を指定できる。Ｘａｍｌファイルは、．ｘａｍｌ拡張子を持ち、媒体タイプがａｐｐｌｉｃａｔｉｏｎ／ｘａｍｌ＋ｘｍｌであるｘｍｌファイルである。Ｘａｍｌファイルは、通常ｘｍｌｎｓ属性を使用して名前空間を指定する１つのルートタグを持つ。名前空間は、他のタイプのタグによって指定することができる。

続きであるが、ｘａｍｌファイル内のタグは、一般に、ＣＬＲオブジェクトにマッピングされる。タグは、要素、複合プロパティ、定義、またはリソースである。要素は、一般的に実行時にインスタンス化され、オブジェクトの階層を形成するＣＬＲオブジェクトである。複合プロパティタグは、親タグでプロパティを設定する場合に使用される。定義タグは、コードをページに追加し、リソースを定義するために使用される。リソースタグは、木をリソースとして指定することよってのみオブジェクトの木を再利用できる機能を提供する。定義タグは、さらに、他のタグ内でｘｍｌｎｓ属性として定義することもできる。

ドキュメントがマークアップで適切に記述された後（通常は、ライターにより）、マークアップは解析して処理することができる（通常は、リーダーにより）。適宜構成されているパーサは、タグを見つけるためにどのＣＬＲアセンブリおよび名前空間を探索すべきかを、ルートタグから判別する。様々な場合において、パーサは、ｘｍｌｎｓ属性により指定されたＵＲＬで名前空間定義ファイルを探し、見つける。名前空間定義ファイルからは、アセンブリの名前およびそのインストールパスならびにＣＬＲ名前空間のリストが得られる。パーサは、タグを見つけると、タグのｘｍｌｎｓおよびそのｘｍｌｎｓのｘｍｌｎｓ定義ファイルを使用してタグが参照するＣＬＲクラスを判別する。パーサは、定義ファイル内でアセンブリおよび名前空間が指定されている順序で探索する。一致が見つかると、パーサはそのクラスのオブジェクトをインスタンス化する。

そこで、上で説明したばかりの、上記の参照により組み込まれるアプリケーションにおいてより詳しく説明されている機構を使用することにより、マークアップタグを使用するＸＭＬベースのファイルによって、オブジェクトモデルを表すことができる。オブジェクトモデルをマークアップタグとして表すことができるこの機能を使用すると、ベクトルグラフィックドローイング、固定フォーマットドキュメント、適応フロードキュメント、およびアプリケーションＵＩを非同期でまたは同期して作成することができる。

例示され説明されている実施形態では、Ｆｉｘｅｄ Ｐａｙｌｏａｄマークアップはごく最低限度のものであり、Ａｖａｌｏｎ ＸＡＭＬレンダリングプリミティブのほぼ完全に倹約的なサブセットである。これは、Ａｖａｌｏｎで表すことができるものであれば何でも視覚的に表し、忠実度も完全である。固定ペイロードマークアップは、Ａｖａｌｏｎ ＸＡＭＬ要素およびプロパティのサブセットであるが、Ａｖａｌｏｎ ＸＡＭＬと比べて、追加規約、標準形式、または使用上の制約がプラスされている。

定義されている完全最小の固定ペイロードマークアップセットにより、プリンタＲＩＰまたは対話形式のビューアアプリケーションなどのリーチパッケージリーダーの実装およびテストにかかわるコストが低減されるだけでなく、関連するパーサの複雑さと占有メモリ量の軽減化をはかることができる。この倹約的マークアップセットでは、さらに、サブセット化、エラー、またはリーチパッケージライターとリーダーとの間の不整合に対する機会を最小限に抑えるため、フォーマットおよびそのエコシステムは本質的により強固なものとなる。

リーチパッケージでは、固定ペイロードマークアップが最小であることに加えて、ハイパーリンク、セクション／アウトライン構造およびナビゲーション、テキスト選択、ならびにドキュメントアクセシビリティなどの機能を含むリーチパッケージドキュメントのビューアまたはプレゼンテーションをサポートするため追加の意味的情報用のマークアップを指定する。

最後に、上述のバージョン管理および拡張性機構を使用すると、特定のターゲット消費アプリケーション、ビューア、またはデバイスに対して、最小の固定ペイロードマークアップを、よりリッチな要素群によって補助することが可能である。

ＦｉｘｅｄＰａｇｅマークアップモデル
例示され説明されている実施形態では、ＦｉｘｅｄＰａｇｅパーツは、ＸＭＬ要素、ＸＭＬ属性、およびＸＭＬ名前空間に基づくＸＭＬベースのマークアップ言語で表される。本明細書では、３つのＸＭＬ名前空間はＦｉｘｅｄＰａｇｅマークアップに含まれるように定義されている。このような名前空間の１つは、本明細書の他の場所で定義されているバージョン管理要素および属性を参照する。ＦｉｘｅｄＰａｇｅマークアップで要素および属性に使用される主名前空間は、「http://schemas.microsoft.com/MMCF-PLACEHOLDER-FixedPage」である。そして最後に、ＦｉｘｅｄＰａｇｅマークアップでは、後述の第３の名前空間を必要とする「リソース」という概念を導入する。

ＦｉｘｅｄＰａｇｅマークアップは、ＸＭＬ要素およびＸＭＬ属性を使用して表されるが、その仕様は、「コンテンツ」および「プロパティ」の高水準抽象モデルに基づく。ＦｉｘｅｄＰａｇｅ要素は、すべてＸＭＬ要素として表される。ほんの一握りのＦｉｘｅｄＰａｇｅ要素で、子ＸＭＬ要素として表される、「コンテンツ」を保持することができる。しかし、プロパティ値は、ＸＭＬ属性を使用するか、または子ＸＭＬ要素を使用して表すことができる。

ＦｉｘｅｄＰａｇｅマークアップは、さらに、リソース辞書およびリソース参照の双子の概念に依存する。リソース辞書と複数のリソース参照を組み合わせることにより、単一のプロパティ値を複数のＦｉｘｅｄＰａｇｅマークアップ要素の複数のプロパティにより共有することができる。

ＦｉｘｅｄＰａｇｅマークアップのプロパティ
例示され説明されている実施形態では、ＦｉｘｅｄＰａｇｅマークアッププロパティの値を指定するために使用できる３つの形式のマークアップがある。

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

リソース参照として指定されていないプロパティ値は、値が設定されているプロパティを識別する入れ子になっている子ＸＭＬ要素を使用して、ＸＭＬで表すことができる。この「複合プロパティシンタックス」については後述する。

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

与えられた要素について、プロパティは、値を指定するのに使用されているシンタックスに関係なく、高々１回設定することができる。

単純属性シンタックス
単純文字列として表すことができるプロパティ値については、ＸＭＬ属性シンタックスを使用してプロパティ値を指定することができる。例えば、「Ｃｏｌｏｒ」というプロパティを持つ「ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ」と呼ばれるＦｉｘｅｄＰａｇｅマークアップ要素が与えられた場合、以下のシンタックスを使用してプロパティ値を指定できる。

複合プロパティシンタックス
ある種のプロパティ値は、単純文字列として表すことができず、例えば、ＸＭＬ要素を使用してプロパティ値を記述する。このようなプロパティ値は、単純な属性シンタックスを使用して表すことはできない。しかし、複合プロパティシンタックスを使用すると表すことができる。

複合プロパティシンタックスでは、子ＸＭＬ要素が使用されるが、ＸＭＬ要素名は親要素名とプロパティ名との組合せを、ピリオドで区切ったものから派生される。＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ＞に設定することができるプロパティ「Ｆｉｌｌ」を持つＦｉｘｅｄＰａｇｅマークアップ要素＜Ｐａｔｈ＞が与えられた場合、以下のマークアップを使用して、＜Ｐａｔｈ＞要素の「Ｆｉｌｌ」プロパティを設定することができる。

複合プロパティシンタックスは、プロパティ値を表すのに単純な属性シンタックスで十分であっても使用することができる。したがって、前のセクションの例は以下のようになる。

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

複合プロパティシンタックスを使用してプロパティ値を指定する場合、「Ｐｒｏｐｅｒｔｉｅｓ」を表す子ＸＭＬ要素は、「Ｃｏｎｔｅｎｔｓ」を表す子ＸＭＬ要素の前になければならない。個々の複合プロパティ子ＸＭＬ要素の順序は重要でなく、親要素の「Ｃｏｎｔｅｎｔｓ」の前にまとめて現れればよい。

例えば、＜Ｃａｎｖａｓ＞要素（後述）のＣｌｉｐおよびＲｅｎｄｅｒＴｒａｎｓｆｏｒｍプロパティの両方を使用する場合、両方とも＜Ｃａｎｖａｓ＞の＜Ｐａｔｈ＞および＜Ｇｌｙｐｈｓ＞コンテンツの前に現れなければならない。

リソースおよびリソース参照
リソース辞書は、それぞれリソースと呼ばれる共有可能プロパティ値を保持するために使用することができる。それ自体ＦｉｘｅｄＰａｇｅマークアップ要素であるプロパティ値は、リソース辞書内に保持することができる。リソース辞書内のリソースには、それぞれ名前が付く。リソースの名前を使用して、プロパティのＸＭＬ属性からリソースを参照することができる。

例示され説明されている実施形態では、＜Ｃａｎｖａｓ＞および＜ＦｉｘｅｄＰａｇｅ＞要素は、リソース辞書を伴うことができる。リソース辞書は、「Ｒｅｓｏｕｒｃｅｓ」と呼ばれるプロパティ内の＜Ｃａｎｖａｓ＞および＜ＦｉｘｅｄＰａｇｅ＞要素のプロパティとしてマークアップで表現される。しかし、個々のリソース値は、直に＜ＦｉｘｅｄＰａｇｅ．Ｒｅｓｏｕｒｃｅｓ＞または＜Ｃａｎｖａｓ．Ｒｅｓｏｕｒｃｅｓ＞ＸＭＬ要素内に埋め込まれる。構文上は、＜Ｃａｎｖａｓ．Ｒｅｓｏｕｒｃｅｓ＞および＜ＦｉｘｅｄＰａｇｅ．Ｒｅｓｏｕｒｃｅ＞のマークアップは、「Ｃｏｎｔｅｎｔｓ」を含むマークアップ要素のそれに類似している。

この実施形態によれば、＜Ｃａｎｖａｓ．Ｒｅｓｏｕｒｃｅｓ＞または＜ＦｉｘｅｄＰａｇｅ．Ｒｅｓｏｕｒｃｅｓ＞は、＜Ｃａｎｖａｓ＞または＜ＦｉｘｅｄＰａｇｅ＞の複合プロパティシンタックスプロパティ値の前になければならない。これらも、同様に、＜Ｃａｎｖａｓ＞または＜ＦｉｘｅｄＰａｇｅ＞の「Ｃｏｎｔｅｎｔｓ」の前になければならない。

固定ペイロードリソース辞書の定義
＜ＦｉｘｅｄＰａｇｅ＞または＜Ｃａｎｖａｓ＞は、＜Ｃａｎｖａｓ．Ｒｅｓｏｕｒｃｅｓ＞ＸＭＬ要素を使用して表される、リソース辞書を伴うことができる。単一のリソース辞書内のそれぞれの要素は、要素に関連付けられたＸＭＬ属性を使用して識別される固有の名前が付けられる。プロパティに対応する属性からこの「Ｎａｍｅ」属性を区別するために、Ｎａｍｅ属性をＦｉｘｅｄＦｏｒｍａｔ要素のとは別の名前空間からとる。そのＸＭＬ名前空間に対するＵＲＩは、「http://schemas.microsoft.com/PLACEHOLDER-for-resources」である。下の例では、２つのジオメトリが定義されており、１つは矩形で、もう１つは円である。

リソースの参照
プロパティ値を上で定義したリソースの１つに設定するには、リソース名を｛｝で囲むＸＭＬ属性値を使用する。例えば、「｛Ｒｅｃｔａｎｇｌｅ｝」は使用されるジオメトリを表す。以下のマークアップの例では、辞書内のジオメトリオブジェクトにより定義される矩形領域は、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈにより塗りつぶされる。

この実施形態によれば、リソース参照は、リソース辞書内のリソースの定義の範囲にあってはならない。

リソース参照を解決するためのスコープ規則
同じリソース辞書内で単一の名前を２回使用することはできないが、単一のＦｉｘｅｄＰａｇｅパーツ内の２つの異なるリソース辞書内であれば同じ名前を使用できる。さらに、内側の＜Ｃａｎｖａｓ＞のリソース辞書では、何らかの外側の＜Ｃａｎｖａｓ＞または＜ＦｉｘｅｄＰａｇｅ＞のリソース辞書内で定義された名前を再利用することができる。

要素のプロパティを設定するのにリソース参照が使用される場合、与えられた名前のリソースの検索は様々なリソース辞書内で行われる。プロパティを持つ要素が＜Ｃａｎｖａｓ＞であれば、その＜Ｃａｎｖａｓ＞のリソース辞書が存在する場合、目的の名前のリソースの検索に使用される。要素が＜Ｃａｎｖａｓ＞でない場合、検索は＜Ｃａｎｖａｓ＞または＜ＦｉｘｅｄＰａｇｅ＞を含む最も近いものから始まる。目的の名前が最初に検索されたリソース辞書内で定義されていない場合、＜Ｃａｎｖａｓ＞または＜ＦｉｘｅｄＰａｇｅ＞を含む次に最も近いものが検索される。検索が＜ＦｉｘｅｄＰａｇｅ＞ルート要素まで続けられ、目的の名前のリソースがその＜ＦｉｘｅｄＰａｇｅ＞と関連するリソース辞書内に見つからない場合には、エラーが発生する。

以下の実施例は、これらの規則を説明している。

ＦｉｘｅｄＰａｇｅ描画モデル
ＦｉｘｅｄＰａｇｅ（または入れ子になっているＣａｎｖａｓ子）要素は、他の要素が上に表示される要素である。コンテンツの配列は、ＦｉｘｅｄＰａｇｅ（またはＣａｎｖａｓ）について指定されたプロパティ、ＦｉｘｅｄＰａｇｅ（またはＣａｎｖａｓ）上の要素に対して指定されたプロパティ、および固定ペイロード名前空間に対し定義されている構成規則により制御される。

要素の位置決めにＣａｎｖａｓを使用する
固定マークアップでは、すべての要素は、座標系の現在の原点（０，０）に相対的に配置される。現在の原点を削除するには、ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ属性を、要素を含むＦｉｘｅｄＰａｇｅまたはＣａｎｖａｓのそれぞれの要素に適用する。

以下の例では、ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍを通じて要素の位置決めを行うことを例示している。

座標系および単位
例示され説明されている実施形態によれば、座標系は、最初、浮動小数点数として表される、１インチ（２．５４ｃｍ）の１／９６に等しくなるように設定され、座標系の原点（０，０）はＦｉｘｅｄＰａｇｅ要素の左上角である。

ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ属性を子要素上で指定することにより、アフィン変換を現在の座標系に適用することができる。

ページ寸法
ページ寸法は、ＦｉｘｅｄＰａｇｅ要素上の「ＰａｇｅＷｉｄｔｈ」および「ＰａｇｅＨｅｉｇｈｔ」パラメータにより指定される。

構成規則
ＦｉｘｅｄＰａｇｅｓでは、アルファチャネルとともにペインタのモデルを使用する。説明されている実施形態によれば、構成は構成規則に従い、以下の順序で実行されなければならない。

・ＦｉｘｅｄＰａｇｅ（または入れ子になっているＣａｎｖａｓ）は、子要素がマークアップ内に現れる順序で描画される非束縛サーフェス（ｕｎｂｏｕｎｄｅｄ ｓｕｒｆａｃｅ）として考えられる。このサーフェスのアルファチャネルは「０．０」（すべて透明）に初期化されている。実際、理想的な非束縛サーフェスは、すべての子要素を表示することにより作られるすべてのマークを保持できる十分な大きさのビットマップバッファと考えることができる。

・サーフェスのコンテンツは、ＦｉｘｅｄＰａｇｅ（またはＣａｎｖａｓ）のＲｅｎｄｅｒＴｒａｎｓｆｏｒｍプロパティにより指定されたアフィン変換を使用して変換される。

・すべての子要素は、サーフェス上に表示され、ＦｉｘｅｄＰａｇｅ（またはＣａｎｖａｓ）のＣｌｉｐプロパティ（これもまたＲｅｎｄｅｒＴｒａｎｓｆｏｒｍプロパティを使用して変換される）によりクリッピングされる。ＦｉｘｅｄＰａｇｅは、さらに、（０，０，ＰａｇｅＷｉｄｔｈ，ＰａｇｅＨｅｉｇｈｔ）で指定された矩形にクリッピングされる。子要素がＯｐａｃｉｔｙプロパティまたはＯｐａｃｉｔｙＭａｓｋプロパティを持つ場合、サーフェス上に表示される前にその子要素に適用される。

・最後に、ＦｉｘｅｄＰａｇｅ（またはＣａｎｖａｓ）のコンテンツが、含む側の要素上に表示される。ＦｉｘｅｄＰａｇｅの場合、含む側の要素は物理的結像面である。

レンダリングは、以下の規則に従って実行される。

・サーフェスにマークを作る要素は、「Ｇｌｙｐｈｓ」および「Ｐａｔｈ」だけである。

・他のすべてのレンダリング効果は、「Ｇｌｙｐｈｓ」および「Ｐａｔｈ」要素を「Ｃａｎｖａｓ」上に配置し、その様々な有効な属性を適用することにより得られる。

固定ペイロード要素およびプロパティ
例示され説明されている実施形態によれば、固定ペイロードは、ページおよびそのコンテンツを表現するためにマークアップ内で使用される、ＸＭＬ要素の小さな集まりを含む。ＦｉｘｅｄＰａｎｅｌパーツ内のマークアップは、＜Ｄｏｃｕｍｅｎｔ＞、＜ＦｉｘｅｄＰａｎｅｌ＞、および＜ＰａｇｅＣｏｎｔｅｎｔ＞要素を使用することで、ドキュメントの複数のページをふつうのインデックスの作成しやすいルートにまとめる。それぞれのＦｉｘｅｄＰａｇｅパーツは、＜Ｐａｔｈ＞および＜Ｇｌｙｐｈｓ＞要素（いっしょになって描画すべてを行う）、およびそれらをグループにまとめるための＜Ｃａｎｖａｓ＞要素のみを含む、＜ＦｉｘｅｄＰａｇｅ＞要素内のページのコンテンツを表す。

固定ペイロードマークアップの要素階層を、「最上位レベルの要素」、「パスのジオメトリ、クリップ」、「パス、グリフ、またはＯｐａｃｉｔｙＭａｓｋを塗りつぶすために使用されるブラシ」、「ＦｉｘｅｄＰａｇｅまたはキャンバスのリソース辞書」、「アルファ透明の不透明マスク」、「クリッピングパス」、および「変換」という表題の以下のセクションにまとめた。

最上位レベルの要素
・＜Ｄｏｃｕｍｅｎｔ＞［ＦｉｘｅｄＰａｎｅｌパーツ毎にちょうど１つ］
・属性：
・［なし］
・子要素：
・＜ＦｉｘｅｄＰａｎｅｌ＞［ちょうど１つ］
・＜ＦｉｘｅｄＰａｎｅｌ＞
・属性：
・ＰａｇｅＨｅｉｇｈｔ［オプション］
・ＰａｇｅＷｉｄｔｈ［オプション］
・子要素：
・＜ＰａｇｅＣｏｎｔｅｎｔ＞［これらの子要素のうちの１〜Ｎ］
・＜ＰａｇｅＣｏｎｔｅｎｔ＞
・属性：
・Ｓｏｕｒｃｅ［必須］
・ＰａｇｅＨｅｉｇｈｔ［オプション］
・ＰａｇｅＷｉｄｔｈ［オプション］
・子要素：
・［なし］
・＜ＦｉｘｅｄＰａｇｅ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・ＰａｇｅＨｅｉｇｈｔ［必須（ここでは、または子要素として）］
・ＰａｇｅＷｉｄｔｈ［必須（ここでは、または子要素として）］
・ＸＭＬ子要素としてそれ自体表されるリソース辞書：
・＜ＦｉｘｅｄＰａｇｅ．Ｒｅｓｏｕｒｃｅｓ＞
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＦｉｘｅｄＰａｇｅ．ＰａｇｅＨｅｉｇｈｔ＞［必須（ここでは、または属性として）］
・＜ＦｉｘｅｄＰａｇｅ．ＰａｇｅＷｉｄｔｈ＞［必須（ここでは、または属性として）］
・ＸＭＬ子要素を介したコンテンツ：
・＜Ｃａｎｖａｓ＞
・＜Ｐａｔｈ＞
・＜Ｇｌｙｐｈｓ＞
・＜Ｃａｎｖａｓ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・リソース辞書参照を介して表されるプロパティ：
・Ｃｌｉｐ
・ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ
・ＯｐａｃｉｔｙＭａｓｋ
・ＸＭＬ子要素としてそれ自体表されるリソース辞書：
・＜Ｃａｎｖａｓ．Ｒｅｓｏｕｒｃｅｓ＞
・ＸＭＬ子要素を介して表されるプロパティ
・＜Ｃａｎｖａｓ．Ｏｐａｃｉｔｙ＞
・＜Ｃａｎｖａｓ．Ｃｌｉｐ＞
・＜Ｃａｎｖａｓ．ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ＞
・＜Ｃａｎｖａｓ．ＯｐａｃｉｔｙＭａｓｋ＞
・ＸＭＬ子要素を介したコンテンツ：
・＜Ｃａｎｖａｓ＞
・＜Ｐａｔｈ＞
・＜Ｇｌｙｐｈｓ＞
・＜Ｐａｔｈ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・リソース辞書参照を介して表されるプロパティ：
・Ｃｌｉｐ
・ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ
・ＯｐａｃｉｔｙＭａｓｋ
・Ｆｉｌｌ
・ＸＭＬ子要素を介して表されるプロパティ
・＜Ｐａｔｈ．Ｏｐａｃｉｔｙ＞
・＜Ｐａｔｈ．Ｃｌｉｐ＞
・＜Ｐａｔｈ．ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ＞
・＜Ｐａｔｈ．ＯｐａｃｉｔｙＭａｓｋ＞
・＜Ｐａｔｈ．Ｆｉｌｌ＞
・＜Ｐａｔｈ．Ｄａｔａ＞
・＜Ｇｌｙｐｈｓ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・ＢｉｄｉＬｅｖｅｌ
・ＦｏｎｔＦａｃｅＩｎｄｅｘ
・ＦｏｎｔＨｉｎｔｉｎｇＥｍＳｉｚｅ
・ＦｏｎｔＲｅｎｄｅｒｉｎｇＥｍＳｉｚｅ
・ＦｏｎｔＵｒｉ
・Ｉｎｄｉｃｅｓ
・ＯｒｉｇｉｎＸ
・ＯｒｉｇｉｎＹ
・Ｓｉｄｅｗａｙｓ
・ＳｔｙｌｅＳｉｍｕｌａｔｉｏｎｓ
・ＵｎｉｃｏｄｅＳｔｒｉｎｇ
・リソース辞書参照を介して表されるプロパティ：
・Ｃｌｉｐ
・ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ
・ＯｐａｃｉｔｙＭａｓｋ
・Ｆｉｌｌ
・ＸＭＬ子要素を介して表されるプロパティ
・＜Ｇｌｙｐｈｓ．Ｃｌｉｐ＞
・＜Ｇｌｙｐｈｓ．ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ＞
・＜Ｇｌｙｐｈｓ．ＯｐａｃｉｔｙＭａｓｋ＞
・＜Ｇｌｙｐｈｓ．Ｆｉｌｌ＞
・＜Ｇｌｙｐｈｓ．Ｏｐａｃｉｔｙ＞
・＜Ｇｌｙｐｈｓ．ＢｉｄｉＬｅｖｅｌ＞
・＜Ｇｌｙｐｈｓ．ＦｏｎｔＦａｃｅＩｎｄｅｘ＞
・＜Ｇｌｙｐｈｓ．ＦｏｎｔＨｉｎｔｉｎｇＥｍＳｉｚｅ＞
・＜Ｇｌｙｐｈｓ．ＦｏｎｔＲｅｎｄｅｒｉｎｇＥｍＳｉｚｅ＞
・＜Ｇｌｙｐｈｓ．ＦｏｎｔＵｒｉ＞
・＜Ｇｌｙｐｈｓ．Ｉｎｄｉｃｅｓ＞
・＜Ｇｌｙｐｈｓ．ＯｒｉｇｉｎＸ＞
・＜Ｇｌｙｐｈｓ．ＯｒｉｇｉｎＹ＞
・＜Ｇｌｙｐｈｓ．Ｓｉｄｅｗａｙｓ＞
・＜Ｇｌｙｐｈｓ．ＳｔｙｌｅＳｉｍｕｌａｔｉｏｎｓ＞
・＜Ｇｌｙｐｈｓ．ＵｎｉｃｏｄｅＳｔｒｉｎｇ＞
パスのジオメトリ、クリップ
・＜Ｐａｔｈ．Ｄａｔａ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｐａｔｈ．Ｄａｔａは以下の子全体をちょうど１つとして持つ］
・＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞
・＜ＰａｔｈＧｅｏｍｅｔｒｙ＞
・＜ＧｅｏｍｅｔｘｙＣｏｌｌｅｃｔｉｏｎ＞
・属性：
・ＣｏｍｂｉｎｅＭｏｄｅ
・子要素：
［１〜Ｎ個の子］
・＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞
・＜ＰａｔｈＧｅｏｍｅｔｒｙ＞
・＜ＰａｔｈＧｅｏｍｅｔｒｙ＞
・属性：
・ＦｉｌｌＲｕｌｅ
・子要素：
［１〜Ｎ個の子］
・＜ＰａｔｈＦｉｇｕｒｅ＞
・＜ＰａｔｈＦｉｇｕｒｅ＞
・属性：
・［なし］
・子要素：
［ＳｔａｒｔＳｅｇｍｅｎｔが先頭で、ＣｌｏｓｅＳｅｇｍｅｎｔが最後、Ｐｏｌｙ＊の１〜Ｎはその間］
・＜ＳｔａｒｔＳｅｇｍｅｎｔ＞
・＜ＰｏｌｙＬｉｎｅＳｅｇｍｅｎｔ＞
・＜ＰｏｌｙＢｅｚｉｅｒＳｅｇｍｅｎｔ＞
・＜ＣｌｏｓｅＳｅｇｍｅｎｔ＞
・＜ＳｔａｒｔＳｅｇｍｅｎｔ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｐｏｉｎｔ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＳｔａｒｔＳｅｇｍｅｎｔ．Ｐｏｉｎｔ＞
・＜ＰｏｌｙＬｉｎｅＳｅｇｍｅｎｔ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｐｏｉｎｔｓ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＰｏｌｙＬｉｎｅＳｅｇｍｅｎｔ．Ｐｏｉｎｔｓ＞
・＜ＰｏｌｙＢｅｚｉｅｒＳｅｇｍｅｎｔ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｐｏｉｎｔｓ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＰｏｌｙＢｅｚｉｅｒＳｅｇｍｅｎｔ．Ｐｏｉｎｔｓ＞
パス、グリフ、またはＯｐａｃｉｔｙＭａｓｋを塗りつぶすために使用されるブラシ
・＜Ｐａｔｈ．Ｆｉｌｌ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｐａｔｈ．Ｆｉｌｌは以下の子のうちのちょうど１つを持つ］
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ＞
・＜ＩｍａｇｅＢｒｕｓｈ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜Ｇｌｙｐｈｓ．Ｆｉｌｌ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｇｌｙｐｈｓ．Ｆｉｌｌは以下の子のうちのちょうど１つを持つ］
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ＞
・＜ＩｍａｇｅＢｒｕｓｈ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・Ｃｏｌｏｒ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ．Ｏｐａｃｉｔｙ＞
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ．Ｃｏｌｏｒ＞
・＜ＩｍａｇｅＢｒｕｓｈ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔ
・ＶｅｒｔｉｃａｌＡｌｉｇｎｍｅｎｔ
・ＶｉｅｗＢｏｘ
・ＶｉｅｗＰｏｒｔ
・Ｓｔｒｅｔｃｈ
・ＴｉｌｅＭｏｄｅ
・ＣｏｎｔｅｎｔＵｎｉｔｓ
・ＶｉｅｗｐｏｒｔＵｎｉｔｓ
・ＩｍａｇｅＳｏｕｒｃｅ
・リソース辞書参照を介して表されるプロパティ：
・Ｔｒａｎｓｆｏｒｍ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＩｍａｇｅＢｒｕｓｈ．Ｏｐａｃｉｔｙ＞
・＜ＩｍａｇｅＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＶｅｒｔｉｃａｌＡｌｉｇｍｎｅｎｔ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＶｉｅｗＢｏｘ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＶｉｅｗＰｏｒｔ＞
・＜ＩｍａｇｅＢｒｕｓｈ．Ｓｔｒｅｔｃｈ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＴｉｌｅＭｏｄｅ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＣｏｎｔｅｎｔＵｎｉｔｓ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＶｉｅｗｐｏｒｔＵｎｉｔｓ＞
・＜ＩｍａｇｅＢｒｕｓｈ．ＩｍａｇｅＳｏｕｒｃｅ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔ
・ＶｅｒｔｉｃａｌＡｌｉｇｎｍｅｎｔ
・ＶｉｅｗＢｏｘ
・ＶｉｅｗＰｏｒｔ
・Ｓｔｒｅｔｃｈ
・ＴｉｌｅＭｏｄｅ
・ＣｏｎｔｅｎｔＵｎｉｔｓ
・ＶｉｅｗｐｏｒｔＵｎｉｔｓ
・リソース辞書参照を介して表されるプロパティ：
・Ｔｒａｎｓｆｏｒｍ
・Ｄｒａｗｉｎｇ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．Ｏｐａｃｉｔｙ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．ＶｅｒｔｉｃａｌＡｌｉｇｎｍｅｎｔ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．ＶｉｅｗＢｏｘ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．ＶｉｅｗＰｏｒｔ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．Ｓｔｒｅｔｃｈ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．ＴｉｌｅＭｏｄｅ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．ＣｏｎｔｅｎｔＵｎｉｔｓ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．ＶｉｅｗｐｏｒｔＵｎｉｔｓ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．Ｄｒａｗｉｎｇ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．Ｄｒａｗｉｎｇ＞
・ＸＭＬ子要素を介したコンテンツ：
・＜Ｃａｎｖａｓ＞
・＜Ｐａｔｈ＞
・＜Ｇｌｙｐｈｓ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・ＭａｐｐｉｎｇＭｏｄｅ
・ＳｐｒｅａｄＭｅｔｈｏｄ
・ＳｔａｒｔＰｏｉｎｔ
・ＥｎｄＰｏｉｎｔ
・リソース辞書参照を介して表されるプロパティ：
・Ｔｒａｎｓｆｏｒｍ
・ＧｒａｄｉｅｎｔＳｔｏｐｓ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｏｐａｃｉｔｙ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．ＭａｐｐｉｎｇＭｏｄｅ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．ＳｐｒｅａｄＭｅｔｈｏｄ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．ＳｔａｒｔＰｏｉｎｔ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．ＥｎｄＰｏｉｎｔ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．ＧｒａｄｉｅｎｔＳｔｏｐｓ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｏｐａｃｉｔｙ
・Ｃｅｎｔｅｒ
・Ｆｏｃｕｓ
・ＲａｄｉｕｓＸ
・ＲａｄｉｕｓＹ
・リソース辞書参照を介して表されるプロパティ：
・Ｔｒａｎｓｆｏｒｍ
・ＧｒａｄｉｅｎｔＳｔｏｐｓ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｏｐａｃｉｔｙ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｃｅｎｔｅｒ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｆｏｃｕｓ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．ＲａｄｉｕｓＸ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．ＲａｄｉｕｓＹ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．ＧｒａｄｉｅｎｔＳｔｏｐｓ＞
・＜ＧｒａｄｉｅｎｔＳｔｏｐｓ＞
・ＸＭＬ子要素を介したコンテンツ：
・＜ＧｒａｄｉｅｎｔＳｔｏｐ＞［これらの子のうちの１〜Ｎ］
・＜ＧｒａｄｉｅｎｔＳｔｏｐ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｃｏｌｏｒ
・Ｏｆｆｓｅｔ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＧｒａｄｉｅｎｔＳｔｏｐ．Ｃｏｌｏｒ＞
・＜ＧｒａｄｉｅｎｔＳｔｏｐ．Ｏｆｆｓｅｔ＞
ＦｉｘｅｄＰａｇｅまたはＣａｎｖａｓのリソース辞書
・＜ＦｉｘｅｄＰａｇｅ．Ｒｅｓｏｕｒｃｅｓ＞
・＜Ｃａｎｖａｓ．Ｒｅｓｏｕｒｃｅｓ＞
これらの要素は、リソース辞書を説明している上のセクションで説明されている。

アルファ透明の不透明マスク
・＜Ｃａｎｖａｓ．ＯｐａｃｉｔｙＭａｓｋ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｃａｎｖａｓ．ＯｐａｃｉｔｙＭａｓｋは以下の子のうちのちょうど１つを持つ］
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ＞
・＜ＩｍａｇｅＢｒｕｓｈ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜Ｐａｔｈ．ＯｐａｃｉｔｙＭａｓｋ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｐａｔｈ．ＯｐａｃｉｔｙＭａｓｋは以下の子のうちのちょうど１つを持つ］
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ＞
・＜ＩｍａｇｅＢｒｕｓｈ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜Ｇｌｙｐｈｓ．ＯｐａｃｉｔｙＭａｓｋ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｇｌｙｐｈｓ．ＯｐａｃｉｔｙＭａｓｋは以下の子のうちのちょうど１つを持つ］
・＜ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ＞
・＜ＩｍａｇｅＢｒｕｓｈ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ＞
クリッピングパス
・＜Ｃａｎｖａｓ．Ｃｌｉｐ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｃａｎｖａｓ．Ｃｌｉｐは以下の子のうちのちょうど１つを持つ］
・＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞
・＜ＰａｔｈＧｅｏｍｅｔｒｙ＞
・＜Ｐａｔｈ．Ｃｌｉｐ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｐａｔｈ．Ｃｌｉｐは以下の子のうちのちょうど１つを持つ］
・＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞
・＜ＰａｔｈＧｅｏｍｅｔｒｙ＞
・＜Ｇｌｙｐｈｓ．Ｃｌｉｐ＞
・属性：
・［なし］
・単一のＸＭＬ子要素として表されるプロパティ値：
［Ｇｌｙｐｈｓ．Ｃｌｉｐは以下の子のうちのちょうど１つを持つ］
・＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞
・＜ＰａｔｈＧｅｏｍｅｔｒｙ＞
変換
・＜Ｃａｎｖａｓ．ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ＞
・単一のＸＭＬ子要素として表されるプロパティ値：
・＜ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞［必須］
・＜Ｐａｔｈ．ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ＞
・単一のＸＭＬ子要素として表されるプロパティ値：
・＜ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞［必須］
・＜Ｇｌｙｐｈｓ．ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ＞
・単一のＸＭＬ子要素として表されるプロパティ値：
・＜ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞［必須］
・＜ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・Ｍａｔｒｉｘ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ．Ｍａｔｒｉｘ＞
・＜ＩｍａｇｅＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ_ｘ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＩｍａｇｅＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ．ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＤｒａｗｉｎｇＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ．ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ．ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ＞
・単純なＸＭＬ属性を介して直接表されるプロパティ：
・ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ
・ＸＭＬ子要素を介して表されるプロパティ
・＜ＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈ．Ｔｒａｎｓｆｏｒｍ．ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ＞
ＦｉｘｅｄＰａｇｅマークアップ
それぞれのＦｉｘｅｄＰａｇｅパーツは、＜ＦｉｘｅｄＰａｇｅ＞要素にルートを持つＸＭＬマークアップでページのコンテンツを表す。このＦｉｘｅｄＰａｇｅマークアップは、わずかの要素およびプロパティ、つまり、＜Ｐａｔｈ＞および＜Ｇｌｙｐｈｓ＞要素（いっしょになって描画すべてを行う）、およびそれらをグループにまとめるための＜Ｃａｎｖａｓ＞要素のみで、ライターおよびリーダーとの間のドキュメントのＷＹＳＩＷＷＧ忠実性をもたらす。

共通要素プロパティ
ＦｉｘｅｄＰａｇｅマークアップにおける各要素に固有の属性について説明する前に、描画およびグループ化要素に共通の属性、つまりＯｐａｃｉｔｙ、Ｃｌｉｐ、ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ、およびＯｐａｃｉｔｙＭａｓｋについて考察する。これらは最上位レベル要素に共通の唯一のプロパティであるだけでなく、上記の構成規則のセクションで説明したように、親要素から子要素へ結果を「累積する」唯一のプロパティでもある。累積は、構成規則の適用結果である。以下の表は、これらの共通属性に関するまとめの説明であり、その後に、各属性の詳細な説明を載せた。

Ｏｐａｃｉｔｙ属性
不透明は、表示（アルファブレンディング）の際に２つの要素を透過的にブレンドするために使用される。Ｏｐａｃｉｔｙ属性は、０（完全透明）から１（完全不透明）まで様々な範囲を指定する。包含する範囲外の値は、マークアップ解析時にこの範囲に固定される。したがって、実際に、［−∞．．．０］は透明であり、［１．．∞］は不透明である。

Ｏｐａｃｉｔｙ属性は、以下の計算を通じて適用される（事前乗算されていないソースおよびデスティネーション色を仮定し、両方ともｓｃＲＧＢとして指定される）。

Ｏ_Ｅ：ＯｐａｃｉｔｙＭａｓｋでの対応する位置にある要素またはアルファ値の不透明属性
Ａ_Ｓ：ソースサーフェスに存在するアルファ値
Ｒ_Ｓ：ソースサーフェスに存在する赤色値
Ｇ_Ｓ：ソースサーフェスに存在する緑色値
Ｂ_Ｓ：ソースサーフェスに存在する青色値
Ａ_Ｄ：デスティネーションサーフェスにすでに存在するアルファ値
Ｒ_Ｄ：デスティネーションサーフェスにすでに存在する赤色値
Ｇ_Ｄ：デスティネーションサーフェスにすでに存在する緑色値
Ｂ_Ｄ：デスティネーションサーフェスにすでに存在する青色値
Ａ＊：デスティネーションサーフェスに対する結果のアルファ値
Ｒ＊：デスティネーションサーフェスに対する結果の赤色値
Ｇ＊：デスティネーションサーフェスに対する結果の緑色値
Ｂ＊：デスティネーションサーフェスに対する結果の青色値
下付文字Ｔで指定されている値はすべて一時的な値である（例えば、Ｒ_Ｔ１）。

ステップ１：ソースアルファ値に不透明度値を乗算する
Ａ_Ｓ＝Ａ_Ｓ＊Ｏ_Ｅ
ステップ２：ソースアルファを事前乗算する
Ａ_Ｔ１＝Ａ_Ｓ
Ｒ_Ｔ１＝Ｒ_Ｓ＊Ａ_Ｓ
Ｇ_Ｔ１＝Ｇ_Ｓ＊Ａ_Ｓ
Ｂ_Ｔ１＝Ｂ_Ｓ＊Ａ_Ｓ
ステップ３：デスティネーションアルファを事前乗算する
Ａ_Ｔ２＝Ａ_Ｄ
Ｒ_Ｔ２＝Ｒ_Ｄ＊Ａ_Ｄ
Ｇ_Ｔ２＝Ｇ_Ｄ＊Ａ_Ｄ
Ｂ_Ｔ２＝Ｂ_Ｄ＊Ａ_Ｄ
ステップ３：ブレンド
Ａ_Ｔ２＝（１−Ａ_Ｔ１）＊Ａ_Ｔ２＋Ａ_Ｔ１
Ｒ_Ｔ２＝（１−Ａ_Ｔ１）＊Ｒ_Ｔ２＋Ｒ_Ｔ１
Ｇ_Ｔ２＝（１−Ａ_Ｔ１）＊Ｇ_Ｔ２＋Ｇ_Ｔ１
Ｂ_Ｔ２＝（１−_ＡＴ１）＊Ｂ_Ｔ２＋Ｂ_Ｔ１
ステップ４：事前乗算を逆にする
Ａ_Ｔ２＝０ならば、すべてのＡ＊Ｒ＊Ｇ＊Ｂ＊を６０に設定する。

そうでなければ、
Ａ＊＝Ａ_Ｔ２
Ｒ＊＝Ｒ_Ｔ２／Ａ_Ｔ２
Ｇ＊＝Ｇ_Ｔ２／Ａ_Ｔ２
Ｂ＊＝Ｂ_Ｔ２／Ａ_Ｔ２
Ｃｌｉｐプロパティ
Ｃｌｉｐプロパティは、幾何学的要素＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞または＜ＰａｔｈＧｅｏｍｅｔｒｙ＞の一方として指定される（詳細は、Ｐａｔｈ．Ｄａｔａを参照）。

Ｃｌｉｐプロパティは次のようにして適用される。

・Ｃｌｉｐ子要素により記述されている幾何学的要素の内側に入るすべての表示されたコンテンツは可視である。

・Ｃｌｉｐ子要素により記述されている幾何学的要素の外側にあるすべての表示されたコンテンツは可視ではない。

ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ子要素
ＭａｔｒｉｘＴｒａｎｓｆｏｒｍは、要素に利用できる唯一の変換属性である。これは、アフィン変換を表す。シンタックスは以下のとおりである。

Ｍａｔｒｉｘ属性で指定されている６個の数値は、ｍ００、ｍ０１、ｍ１０、ｍ１１、ｄｘ、ｄｙである。

完全な行列は以下のようになる。

ｍ００ ｍ０１ ０
ｍ１０ ｍ１１ ０
ｄｘ ｄｙ １
与えられた座標Ｘ、Ｙは、ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍにより、以下の計算を適用することで変換され、座標Ｘ’、Ｙ’に関する結果が得られる。

Ｘ’＝Ｘ＊ｍ００＋Ｙ＊ｍ１０＋ｄｘ
Ｙ’＝Ｘ＊ｍ０１＋Ｙ＊ｍ１１＋ｄｙ
ＯｐａｃｉｔｙＭａｓｋ子要素
ＯｐａｃｉｔｙＭａｓｋでは、Ｂｒｕｓｈを指定するが、Ｆｉｌｌ Ｂｒｕｓｈとは対照的に、ブラシのアルファチャネル（上のＯｐａｃｉｔｙ属性を参照）のみを、要素を表示するための追加パラメータとして使用する。さらに、要素の各ピクセルの各アルファ値に、ＯｐａｃｉｔｙＭａｓｋ Ｂｒｕｓｈ内の対応する位置のアルファ値を掛ける。

＜Ｃａｎｖａｓ＞要素
＜Ｃａｎｖａｓ＞要素は、複数の要素をひとまとめにする場合に使用される。通常、ＦｉｘｅｄＰａｇｅ要素が＜Ｃａｎｖａｓ＞でひとまとめにされるのは、構成された共通属性（つまり、Ｏｐａｃｉｔｙ、Ｃｌｉｐ、ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ、またはＯｐａｃｉｔｙＭａｓｋ）を共有する場合である。これらの要素をＣａｎｖａｓ上でグループ化することにより、共通属性を個々の要素ではなくキャンバスに適用できる場合が多い。

＜Ｃａｎｖａｓ＞の属性および子要素
＜Ｃａｎｖａｓ＞要素は、前記の共通属性、つまりＯｐａｃｉｔｙ、Ｃｌｉｐ、ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ、およびＯｐａｃｉｔｙＭａｓｋのみを持つ。これらは、以下の表で説明されているような＜Ｃａｎｖａｓ＞要素とともに使用される。

以下のマークアップの実施例は、＜Ｃａｎｖａｓ＞の使い方を説明している。

Ｃａｎｖａｓマークアップの読み込み順序に関して、以下の点について考察する。ＦｉｘｅｄＰａｇｅの場合と同様、Ｃａｎｖａｓ内に含まれるＧｌｙｐｈｓ子要素のマークアップ順序は、テキストコンテンツの所望の読み込み順序と同じでなければならない。この読み込み順序は、ビューア内のＦｉｘｅｄＰａｇｅからの順次テキストの対話形式による選択／コピーのためと、アクセシビリティ技術による順次テキストへのアクセスを可能にするために使用することができる。マークアップ順序と読み込み順序との間の対応関係を保証するのは、ＦｉｘｅｄＰａｇｅマークアップを生成するアプリケーション側の役目である。

入れ子になっているＣａｎｖａｓ要素内に含まれる子Ｇｌｙｐｈｓ要素は、Ｃａｎｖａｓの前後に出現する兄弟Ｇｌｙｐｈｓ要素の間で一列に順序付けられる。

実施例：

＜Ｐａｔｈ＞要素
Ｐａｔｈ要素は、幾何学的領域を記述するＸＭＬベースの要素である。幾何学的領域とは、塗りつぶすことができる、またはクリッピングパスとして使用できる形状のことである。矩形および楕円などのふつうのジオメトリタイプは、Ｐａｔｈジオメトリを使用して表すことができる。パスは、Ｇｅｏｍｅｔｒｙ．Ｄａｔａ子要素およびＦｉｌｌまたはＯｐａｃｉｔｙなどのレンダリング属性を指定することにより記述される。

＜Ｐａｔｈ＞のプロパティおよび子要素
後述のように、以下のプロパティは＜Ｐａｔｈ＞要素に適用可能である。

＜Ｐａｔｈ．Ｄａｔａ＞子要素のジオメトリにより記述される領域を塗りつぶす方法を記述するために、Ｆｉｌｌプロパティを使用する。＜Ｐａｔｈ．Ｄａｔａ＞形状を描画できる領域を制約する場合には、Ｃｌｉｐプロパティを使用する。

ジオメトリの記述のために＜Ｐａｔｈ＞を使用する
パスのジオメトリは、以下に示すように、＜Ｐａｔｈ．Ｄａｔａ＞の入れ子になっている子要素の系列として指定される。ジオメトリは、＜ＰａｔｈＧｅｏｍｅｔｒｙ＞子要素の集合を含む＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞、または＜ＰａｔｈＦｉｇｕｒｅｓ＞を含む単一の＜ＰａｔｈＧｅｏｍｅｔｒｙ＞子要素で表すことができる。

同じ＜ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ＞または＜ＰａｔｈＧｅｏｍｅｔｒｙ＞要素により、Ｃａｎｖａｓ、Ｐａｔｈ、またはＧｌｙｐｈｓのＣｌｉｐプロパティで使用されるクリッピングパスに対するジオメトリが定義される。

以下の表では、Ｐａｔｈジオメトリを定義する子要素の階層を導入している。

ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ
ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎは、Ｂｏｏｌｅａｎ ＣｏｍｂｉｎｅＭｏｄｅオプションに従って表示するためにひとまとめにされる幾何学的オブジェクトの集合である。ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ要素は、ＦｉｘｅｄＰａｇｅマークアップ内の、幾何学的形状の視覚的組合せを作るための機構である。

ＣｏｍｂｉｎｅＭｏｄｅ属性は、ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ内の幾何学的形状の集合を組み合わせるために使用されるブール演算を指定する。モードに応じて、様々な領域が含まれたり、除外されたりする。

ＣｏｍｂｉｎｅＭｏｄｅｓは、以下のように取り扱われる。

非可換： ＣｏｍｐｌｅｍｅｎｔおよびＥｘｃｌｕｄｅは、非可換であり、したがって、ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎ内の第１のジオメトリとそれぞれの個別の残りのジオメトリとの間で定義される。例えば、集合｛ｇ１，ｇ２，ｇ３｝に対して、ＥｘｃｌｕｄｅのＣｏｍｂｉｎｅＭｏｄｅは（（ｇ１ ｅｘｃｌｕｄｅ ｇ２） ａｎｄ （ｇ１ ｅｘｃｌｕｄｅ ｇ３））として適用される。

可換： ブール演算Ｕｎｉｏｎ、Ｘｏｒ、Ｉｎｔｅｒｓｅｃｔは、可換であり、したがって、順序独立性がジオメトリに適用される。

ＰａｔｈＧｅｏｍｅｔｒｙ
ＰａｔｈＧｅｏｍｅｔｒｙ要素は、ＰａｔｈＦｉｇｕｒｅ要素の集合を含む。ＰａｔｈＦｉｇｕｒｅｓの和集合は、ＰａｔｈＧｅｏｍｅｔｒｙの内部を定義する。

ＦｉｌｌＲｕｌｅ属性に関して、以下の事項を考察する。ＰａｔｈＧｅｏｍｅｔｒｙの塗りつぶされた領域は、Ｆｉｌｌｅｄ属性が真に設定されている包含されるＰａｔｈＦｉｇｕｒｅのすべてをとり、ＦｉｌｌＲｕｌｅを適用して囲まれている領域を決定することにより定義される。ＦｉｌｌＲｕｌｅオプションは、Ｇｅｏｍｅｔｒｙに含まれるＦｉｇｕｒｅ要素の共通部分領域を組み合わせることで、Ｇｅｏｍｅｔｒｙの結果領域を形成する方法を指定する。

説明されている実施形態では、ＥｖｅｎＯｄｄ ＦｉｌｌおよびＮｏｎＺｅｒｏ Ｆｉｌｌアルゴリズムが実現されている。

ＥｖｅｎＯｄｄ Ｆｉｌｌアルゴリズムでは、キャンバス上のある点の「内部性」、つまり内部にあるかどうかを判定するために、その点から任意の方向に無限大まで延びる光線を描画し、その後、形状のセグメントがその光線を横切る場所を調べる。カウント０から始め、セグメントが左から右へ光線を横切るたびに１を加え、パスセグメントが右から左へ光線を横切るたびに１を引く。交差点を数えた後、その結果が０であればその点はパスの外部にある。そうでなければ内部にある。

ＮｏｎＺｅｒｏ Ｆｉｌｌアルゴリズムでは、キャンバス上のある点の「内部性」、つまり内部にあるかどうかを判定するために、その点から任意の方向に無限大まで延びる光線を描画し、その光線が横切る与えられた形状からのパスセグメントの個数を数える。この数が奇数であればその点は内部にあり、偶数であればその点は外部にある。

ＰａｔｈＦｉｇｕｒｅ
ＰａｔｈＦｉｇｕｒｅ要素は、１つまたは複数の線分もしくは曲線セグメントの集合からなる。セグメント要素により、ＰａｔｈＦｉｇｕｒｅの形状が定義される。ＰａｔｈＦｉｇｕｒｅでは、常に、閉じた形状を定義しなければならない。

図はまず開始点が必要であり、その後、各線分または曲線セグメントは加えられた最後の点から続く。ＰａｔｈＦｉｇｕｒｅ集合内の第１のセグメントは、ＳｔａｒｔＳｅｇｍｅｎｔでなければならず、ＣｌｏｓｅＳｅｇｍｅｎｔは最後のセグメントでなければならない。ＳｔａｒｔＳｅｇｍｅｎｔはＰｏｉｎｔ属性を持つ。ＣｌｏｓｅＳｅｇｍｅｎｔは属性を持たない。

Ｐａｔｈ．Ｄａｔａジオメトリの固定ペイロードマークアップ
以下では、キャンバス上にパスを描画し塗りつぶすためのマークアップを取りあげる。以下の特定の実施例では、矩形パスがキャンバス上に描画され、濃い緑色のブラシで塗りつぶされる。

以下のマークアップでは、ベジエ三次曲線の描画が記述される。つまり、ＰｏｌｙＬｉｎｅＳｅｇｍｅｎｔのほかに、固定ペイロードマークアップは、ベジエ三次曲線を描画するＰｏｌｙＢｅｚｉｅｒＳｅｇｍｅｎｔを含む。

ブラシ
ブラシは、＜Ｐａｔｈ＞要素により定義された幾何学的形状の内部を塗りつぶす場合、および＜Ｇｌｙｐｈｓ＞要素で表示されたキャラクタビットマップを塗りつぶす場合に使用される。ブラシは、さらに、＜Ｃａｎｖａｓ．ＯｐａｃｉｔｙＭａｓｋ＞、＜Ｐａｔｈ．ＯｐａｃｉｔｙＭａｓｋ＞、および＜Ｇｌｙｐｈｓ．ＯｐａｃｉｔｙＭａｓｋ＞でアルファ透明マスクを定義する際にも使用される。ＦｉｘｅｄＰａｇｅマークアップは、以下のブラシを含む。

属性は、ブラシ毎に異なるが、すべてのブラシがＯｐａｃｉｔｙ属性を持つ。ＩｍａｇｅＢｒｕｓｈおよびＤｒａｗｉｎｇＢｒｕｓｈはタイリング機能を共有する。この２つのグラディエント塗りつぶしブラシは、属性も共通に持つ。

マークアップでブラシの子要素を使用する方法を以下に示す。

ブラシの共通プロパティ
説明されている実施形態によれば、以下のプロパティは、オプションの子要素が比較的少ない単純なブラシであるＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈを除く、すべてのブラシに適用可能である。

ＤｒａｗｉｎＢｒｕｓｈおよびＩｍａｇｅＢｒｕｓｈの共通属性

Ｈｏｒｉｚｏｎｔａｌ Ａｌｉｇｎｍｅｎｔ属性は、書き込まれる領域内でブラシを水平方向に揃える方法を指定する。Ｖｅｒｔｉｃａｌ Ａｌｉｇｎｍｅｎｔ属性は、書き込まれる領域内でブラシを垂直方向に揃える方法を指定する。ＶｉｅｗＢｏｘ属性は、デフォルト値として（０，０，０，０）を持ち、未設定と解釈される。未設定の場合、調整は行われず、Ｓｔｒｅｔｃｈ属性は無視される。ビューボックスは、コンテンツに対する新しい座標系を指定する、つまり、ビューポートの範囲と原点を再定義する。Ｓｔｒｅｔｃｈ属性を使用すると、コンテンツがどのようにビューポートにマッピングされるかを指定しやすい。ｖｉｅｗＢｏｘ属性の値は、ホワイトスペースおよび／またはカンマで区切られた４つの「無次元」数のリスト、＜ｍｉｎ−ｘ＞、＜ｍｉｎ−ｙ＞、＜ｗｉｄｔｈ＞、および＜ｈｅｉｇｈｔ＞であり、Ｒｅｃｔ型である。Ｖｉｅｗｂｏｘ ｒｅｃｔは、境界ボックスにマッピングされるユーザ空間内の矩形を指定する。この動作は、ｓｃａｌｅＸおよびｓｃａｌｅＹを挿入することと同じである。Ｓｔｒｅｔｃｈ属性（オプションがｎｏｎｅ以外の場合）により、グラフィックスのアスペクト比を維持する制御をさらに行える。追加変換を与えられた要素のすべての子孫に適用することで、指定された効果を生み出す。Ｂｒｕｓｈに対する変換がある場合、これは、ＶｉｅｗＢｏｘへのマッピングの「上で」適用される。

Ｓｔｒｅｔｃｈ属性は、Ｎｏｎｅ、Ｆｉｌｌ、Ｕｎｉｆｏｒｍ、ＵｎｉｆｏｒｍＴｏＦｉｌｌの４つのモードを持つ。

単純なブラシとその属性
Ｐａｔｈ．ＢｒｕｓｈおよびＣａｎｖａｓ．Ｂｒｕｓｈ子要素は、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、ＩｍａｇｅＢｒｕｓｈ、およびＤｒａｗｉｎｇＢｒｕｓｈを含む。

ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈは、定義済みの幾何学的領域をベタ一色に塗りつぶす。色のアルファ成分がある場合、それはＢｒｕｓｈ内の対応する不透明属性と乗法的に結合される。

以下の例は、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈに対する色属性の表し方を例示している。

ＩｍａｇｅＢｒｕｓｈは、空間をイメージで塗りつぶす場合に使用することができる。ＩｍａｇｅＢｒｕｓｈのマークアップでは、ＵＲＩを指定することができる。他のすべての属性がデフォルト値に設定されている場合、イメージは、その領域の境界ボックスいっぱいに引き延ばされる。

ＩｍａｇｅＳｏｕｒｃｅ属性は、サポートされているリーチイメージフォーマットまたはそれらのタイプのうちの１つのイメージが得られるセレクタのいずれか一方を参照しなければならない。

ＤｒａｗｉｎｇＢｒｕｓｈは、空間をベクトルドローイングで塗りつぶす場合に使用することができる。ＤｒａｗｉｎｇＢｒｕｓｈはＤｒａｗｉｎｇ Ｃｈｉｌｄ要素を持ち、マークアップでの使い方は以下に示されている。

グラディエントブラシとその属性
グラディエントは、グラディエントブラシのＸＭＬ子要素としてグラディエントストップ（ｇｒａｄｉｅｎｔ ｓｔｏｐｓ）の集合を指定することにより描画される。これらのグラディエントストップは、ある種の数列で色を指定する。このフレームワークでサポートされているグラディエントブラシは２種類ある、つまり線形と放射状である。

グラディエントは、指定された色空間内のグラディエントストップ間の補間を実行することにより描画される。ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈおよびＧｒａｄｉｅｎｔＢｒｕｓｈは、以下の共通属性を共有する。

ＳｐｒｅａｄＭｅｔｈｏｄ属性に関して、以下の事項を考察する。ＳｐｒｅａｄＭｅｔｈｏｄオプションにより、空間の塗りつぶし方を指定する。デフォルト値はＰａｄである。

ＭａｐｐｉｎｇＭｏｄｅ属性
ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈに関して、以下の事項を考察する。ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈは、ベクトルに沿って線形グラディエントブラシを指定する。

以下のマークアップの実施例は、ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈの使い方を説明している。矩形パスが含まれるページは、線形グラディエントで塗りつぶされる。

この実施例は、線形グラディエントで塗りつぶされる矩形パスが含まれるページを示している。パスは、さらに、パスをクリッピングする八角形のクリッププロパティも持つ。

ＲａｄｉａｌＧｒａｄｉｅｎｔは、プログラミングモデルにおいては線形グラディエントに似ている。しかし、線形グラディエントはグラディエントベクトルを定義する始点と終点を持つが、放射状グラディエントは、グラディエントの挙動を定義する焦点を伴う円を持つ。この円は、グラディエントの終点を定義する、つまり、１．０でのグラディエントストップは、円の周囲の色を定義する。焦点は、グラディエントの中心を定義する。０．０のグラディエントストップは、焦点での色を定義する。

アルファおよび透明
例示され説明されている実施形態によれば、それぞれの要素の各ピクセルは、０．０（完全透明）から１．０（完全不透明）までの範囲のアルファ値を伴う。アルファ値は、透明の視覚的効果を生み出すために要素をブレンドする場合に使用される。

それぞれの要素は、要素の各ピクセルのアルファ値に一様に乗じられるＯｐａｃｉｔｙ属性を持ちうる。

さらに、ＯｐａｃｉｔｙＭａｓｋを使用することで、表示されたコンテンツをブレンドしてデスティネーションに送るのを制御するピクセル毎の不透明度を指定することができる。ＯｐａｃｉｔｙＭａｓｋで指定された不透明度は、コンテンツのアルファチャネル内にすでにたまたま存在しうる不透明度と乗法的に結合される。ＯｐａｃｉｔｙＭａｓｋにより指定されたピクセル毎の不透明度は、マスク内の各ピクセルのアルファチャネルを見ることにより判別されるが、色データは無視される。

ＯｐａｃｉｔｙＭａｓｋのタイプはＢｒｕｓｈである。これにより、様々な方法でＢｒｕｓｈのコンテンツをコンテンツの及ぶ範囲へマッピングする仕方を指定することができる。ジオメトリの塗りつぶしに使用された場合と同様に、ブラシは、デフォルトでは、コンテンツ空間全体を塗りつぶし、そのコンテンツを適宜引き延ばすかまたは複製する。これは、ＩｍａｇｅＢｒｕｓｈがそのＩｍａｇｅＳｏｕｒｃｅを引き延ばして、コンテンツを完全に覆い、ＧｒａｄｉｅｎｔＢｒｕｓｈは辺から辺へ延びることを意味する。

アルファブレンディングに必要な計算は、「Ｏｐａｃｉｔｙ属性」という前のセクションで説明されている。

以下の実施例は、ＯｐａｃｉｔｙＭａｓｋを使用して、「フェード効果」をＧｌｙｐｈｓ要素に与える方法を例示している。実施例のＯｐａｃｉｔｙＭａｓｋは、不透明黒色から透明黒色へフェードする線形グラディエントである。

リーチドキュメント内のイメージ
ＦｉｘｅｄＰａｇｅｓでは、イメージは囲まれている領域を塗りつぶす。ＦｉｘｅｄＰａｇｅ上にイメージを配置するには、ページ上で領域をまず指定しなければならない。この領域は、Ｐａｔｈ要素のジオメトリにより定義される。

Ｐａｔｈ要素のＦｉｌｌプロパティは、描かれている領域に対する塗りつぶしコンテンツを指定する。イメージは、ＩｍａｇｅＢｒｕｓｈにより領域内に描画される、一種の塗りつぶしである。すべてのブラシは、適宜ブラシコンテンツの引き延ばしまたは反復（タイリング）のいずれかにより領域全体を塗りつぶすデフォルトの挙動を持つ。ＩｍａｇｅＢｒｕｓｈの場合、ＩｍａｇｅＳｏｕｒｃｅプロパティにより指定されたコンテンツは、その領域を完全に覆うように引き延ばされる。

以下のマークアップは、イメージをキャンバス上に置く方法を示している。

多くのイメージは矩形なので、リソース辞書に矩形パス要素を入れることは、マークアップの簡素化に役立つと考えられる。その後、ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ属性を使用してＰａｔｈの位置を決めることができる（上を参照）。

色
色は、ｓｃＲＧＢまたはｓＲＧＢ表記を使用して例示され説明されているマークアップで指定することができる。ｓｃＲＧＢ規格は、「ＩＥＣ ６１９６６−２−２ ｓｃＲＧＢ」と呼ばれ、ｗｗｗ．ｉｅｃ．ｃｈから入手することができる。

ＡＲＧＢパラメータを以下の表に示す。

カラーマッピング
現在、カラーコンテキストを指定するメタデータで、色分け要素のタグ付けをすることが検討中である。このようなメタデータは、ＩＣＣカラープロファイルまたは他の色定義データを含むことが可能である。

＜Ｇｌｙｐｈｓ＞要素
テキストは、Ｇｌｙｐｈｓ要素を使用して固定ペイロードにより表される。要素は、印刷およびリーチドキュメントの要件を満たすように設計されている。

Ｇｌｙｐｈｓ要素は、以下のプロパティの複数の組合せを持つことができる。

テキストマークアップの概要
グリフメトリクス
それぞれのグリフは、他のグリフとの位置の揃え方を指定するメトリクスを定義する。一実施形態によるメトリクスの実施例を図１２に示す。

送り幅（Ａｄｖａｎｃｅ ｗｉｄｔｈ）と組合せマーク
一般に、フォント内のグリフは、ベースグリフまたはベースグリフに付けられる組合せマークのいずれかである。ベースグリフは、通常、非ゼロの送り幅と０，０のオフセットベクトルを持つ。組合せマークは、通常、送り幅が０である。オフセットベクトルは、組合せマークの位置を調整するために使用することができ、したがって、組合せマークに対して非０，０値を設定することができる。

グリフラン内の各グリフは、その位置を制御する３つの値を持つ。これらの値は、原点、送り幅、およびグリフオフセットを示すが、以下ではこれらについて説明する。

・原点：各グリフは、名目上の原点が与えられていると想定され、ランの中の最初のグリフに対して、これはランの原点である。

・送り幅：各グリフの送り幅は、このグリフ原点に対する次のグリフの原点を与える。アドバンスベクトルは、常にランの進行方向に描画される。

・グリフオフセット（ベースまたはマーク）：グリフオフセットベクトルにより名目上の原点に関してこのグリフ位置を調整する。

文字、グリフ、およびクラスタマップ
クラスタマップは、Ｕｎｉｃｏｄｅコードポイントによる１つのエントリを含む。エントリ内の値は、このコードポイントを表すＧｌｙｐｈＩｎｄｉｃｅｓ配列内の第１のグリフのオフセットである。それとは別に、コードポイントが不可分の文字クラスタを表すコードポイントのグループの一部である場合、ＧｌｙｐｈＩｎｄｉｃｅｓ配列内の第１のグリフは、そのクラスタを表す第１のグリフのオフセットを表す。

クラスタマッピング
クラスタマップは、１対１、多対１、１対多、または多対多であるコードポイント−グリフ間マッピングを表すことができる。１対１マッピングは、それぞれのコードポイントがちょうど１つのグリフで表される場合のもので、図１３のクラスタマップエントリは、０、１、２、．．．である。

多対１マッピングは、２つ以上のコードポイントが単一のグリフにマッピングされる場合のものである。これらのコードポイントのエントリは、グリフインデックスバッファ内でそのグリフのオフセットを指定する。図１４の例では、「ｆ」および「ｉ」の文字は、多くのセリフフォントの通常の活字組方法と同様に、合字で置き換えられている。

１対多マッピングに関しては、図１５について以下の事項を考察する。「Ｓａｒａ Ａｍ」は、前のベース文字の上に置かれている部分（リング）とベース文字の右に置かれている部分（フック）を含む。タイ語のテキストが微調整される場合、フックはベース文字から間隔をあけて並べられるが、リングは、ベース文字の上に残り、したがって、多くのフォントでは、リングとフックを別々のグリフとして符号化する。１つのコードポイントが２つ以上のグリフにマッピングされる場合、そのコードポイントに対するＣｌｕｓｔｅｒＭａｐ内の値は、そのコードポイントを表すＧｌｙｐｈＩｎｄｅｃｅｓ配列内の第１のグリフを参照する。

多対多マッピングに関しては、図１６について以下の事項を考察する。ある種のフォントでは、文字クラスタのコードポイントの不可分グループは、複数のグリフにマッピングされる。例えば、これは、インド語書き文字をサポートするフォントでは普通のことである。コードポイントの不可分のグループが１つまたは複数のグリフにマッピングされる場合、それらのコードポイントのそれぞれに対するＣｌｕｓｔｅｒＭａｐ内の値は、そのコードポイントを表すＧｌｙｐｈＩｎｄｅｃｅｓ配列内の第１のグリフを参照する。

以下の実施例は、タミル語の単語□□□□のＵｎｉｃｏｄｅおよびグリフの表現を示している。最初の２つのコードポイントが組み合わさって、３つのグリフができる。

クラスタの指定
クラスタ指定は、非１：１クラスタの第１のグリフに対するグリフ指定の前に来る（マッピングは、１文字対１グリフよりも複雑になる）。

各クラスタ指定は、以下の形式を持つ。

(ClusterCodepointCount[:ClusterGlyphCount])

＜Ｇｌｙｐｈｓ＞マークアップ
Ｇｌｙｐｈｓ要素では、フォントをＵＲＩ、書体インデックス、および上述の一組の他の属性として指定する。例えば、

各グリフ指定は、以下の形式を持つ。

[GlyphIndex][,[Advance][,[uOffset][,[vOffset][,[Flags]]]]]
グリフ指定の各部はオプションである。

丸め誤差が累積しないアドバンス計算について、以下の事項を考察する。それぞれのアドバンス値は、後続のグリフの丸めを行っていない正確な原点から先行するグリフの計算で求めた（つまり、丸めた）送り幅の合計を、引いた値として計算しなければならない。このようにして、各グリフは、正確な位置のｅｍの０．５％以内で位置決めされる。

グリフマークアップの実施例

グリフマークアップのサイズの最適化
グリフインデックスおよび送り幅などのマークアップの詳細は、ターゲットのクライアントがそれらを確実に再生できれば省略できる。以下のオプションにより、通常使用される単純なスクリプトの劇的な最適化が可能になる。

グリフインデックスのマークアップの最適化
グリフインデックスは、Ｕｎｉｃｏｄｅ文字列内の文字の位置とグリフ文字列内のグリフの位置との間の１対１マッピングがある場合にマークアップから省略することができ、グリフインデックスは、フォントのＣＭＡＰ（キャラクタマッピング）テーブル内の値であり、Ｕｎｉｃｏｄｅ文字はあいまいさのない意味を持つ。

グリフインデックスは、文字からグリフへのマッピングが以下の場合にマークアップ内に用意すべきである。

・２つ以上のコードポイントが単一のグリフを形成する場合（合字）など、１対１でないか、または
・１つのコードポイントで複数のグリフを生成しているか、または
・ＯｐｅｎＴｙｐｅ機能の適用などによる、他の形態のグリフ置換が生じた場合。

グリフインデックスは、レンダリングエンジンがフォント内のＣＭＡＰ（キャラクタマッピング）テーブル内のグリフと異なるグリフを置き換えるおそれがある場合に、マークアップに用意すべきである。グリフインデックスは、所望のグリフ表現がフォントのＣＭＡＰテーブル内にある表現でない場合に用意すべきである。

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

グリフ垂直オフセットは、それが０の場合にマークアップから省略することができる。これは、ベース文字についてはほとんどいつでもそのとおりであり、より単純なスクリプト内の組合せマークについても一般的にそのとおりである。しかし、これは、アラビア語やインド語などのより複雑なスクリプト中の組合せマークについては当てはまらないことが多い。

グリフフラグのマークアップの最適化
グリフフラグは、通常のジャスティフィケーション優先度を持つベースグリフについては省略できる。

結論
上記のモジュール型のコンテンツフレームワークおよびドキュメントフォーマットの方法およびシステムでは、ドキュメント中心のコンテンツの構成、パッケージ化、配布、および表示のためのビルディングブロックを一式備える。これらのビルディングブロックは、ソフトウェアおよびハードウェアシステムによりドキュメントの生成、交換、および表示を、信頼性が高く一貫性のある形で行えるようにするドキュメントフォーマットのためのプラットフォーム依存性のないフレームワークを定義する。例示され説明されているリーチパッケージフォーマットは、ページ付けまたは事前ページ付けドキュメントを格納するためのフォーマットであり、これにより、様々な環境および様々なシナリオにわたるデバイスおよびアプリケーション間でのリーチパッケージのコンテンツの完全に忠実な表示または印刷が可能になる。本発明は構造的機能および／または方法論的ステップに固有の言語で説明されているが、付属の請求項で定められている発明は、説明した特定の機能またはステップに必ずしも限られないことは理解されるであろう。むしろ、特定の機能およびステップは請求されている発明を実施する好ましい形態として開示されている。

一実施形態におけるフレームワークおよびフォーマットの実施例のコンポーネントのブロック図である。 一実施形態における多数のパーツを含むドキュメントを保持するパッケージの実施例のブロック図である。 一実施形態における、パッケージを作成するライターおよびパッケージを読み込むリーダーの実施例を示すブロック図である。 ３つの別々のページをバインドして１つにするパーツの例を示す図である。 一実施形態における、レポートの英語とフランス語の両方の表現を収めた財務レポートを作成するように配列されたセレクタおよびシーケンスの例を示す図である。 一実施形態における、ライターおよびリーダーが連携してパッケージに関する通信を行ういくつかの例を示す図である。 ドキュメントの複数のパーツをインタリーブする一実施例を示す図である。 図７に示されているドキュメントの複数のパーツをパッケージ化する様々な実施例を示す図である。 図７に示されているドキュメントの複数のパーツをパッケージ化する様々な実施例を示す図である。 一実施形態における、リーチパッケージの実施例およびパッケージを構成する、またはパッケージ内に見つかる有効な種類のパーツのそれぞれを示す図である。 一実施形態における、Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ概念をＸＭＬにマッピングする実施例を示す図である。 一実施形態における、縦書きと横書きの両方のグリフメトリクスを例示する図である。 一実施形態による１対１のクラスタマップを例示する図である。 一実施形態による多対１のクラスタマップを例示する図である。 一実施形態による１対多のクラスタマップを例示する図である。 一実施形態による多対多のクラスタマップを例示する図である。

Claims (33)

1. ドキュメントを定義するパッケージを構築するステップであって、前記パッケージは前記ドキュメントを構成する複数のパーツを含むことと、
   前記パッケージ内に、１つあるいは複数の構成パーツを含めるステップであって、前記構成パーツはドキュメントパーツ選択またはドキュメントパーツ順序付けの少なくとも一方を実行できることと、
   を備えることを特徴とする方法。
2. 前記含めるステップは、前記１つまたは複数の構成パーツをＸＭＬ要素として表すことを含むことを特徴とする請求項１に記載の方法。
3. 前記複数のパーツのいずれもが、関連するタイプを有し、前記１つまたは複数の構成パーツは、パーツタイプに基づき実行するように構成されることを特徴とする請求項１に記載の方法。
4. 前記複数のパーツのいずれもが、関連するタイプを有し、前記１つまたは複数の構成パーツは、構成パーツマークアップに含まれる特定の命令のパーツタイプに基づき実行するように構成されることを特徴とする請求項１に記載の方法。
5. ドキュメントパーツ選択を実行するように構成されている構成パーツのうち少なくとも一部は、いずれかの間から選択をするパーツに関連付けられているコンテンツタイプに基づき選択を実行できることを特徴とする請求項３に記載の方法。
6. コンテンツタイプ選択は、少なくとも一部は、特定のコンテンツタイプを認識するソフトウェアが使用可能かどうかに基づくことを特徴とする請求項５に記載の方法。
7. コンピュータ可読命令を含み、前記命令が実行されると、請求項６に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
8. 請求項７に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
9. コンピュータ可読命令を含み、前記命令が実行されると、請求項１に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
10. 請求項９に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
11. ドキュメントを定義するパッケージを受信するステップであって、前記パッケージは前記ドキュメントを構成する複数のパーツを含み、前記パッケージは１つまたは複数の構成パーツを含み、前記構成パーツはドキュメントパーツ選択またはドキュメントパーツ順序付けの少なくとも一方を実行することができことと、
    前記パッケージを処理して前記１つまたは複数の構成パーツを識別するステップと、
    前記１つまたは複数の構成パーツに関連付けられているアクションを実行するステップと、
    を備えることを特徴とする方法。
12. 前記１つまたは複数の構成パーツは、ＸＭＬ要素として表されることを特徴とする請求項１１に記載の方法。
13. 前記複数のパーツいずれもが、関連するタイプを備え、前記１つまたは複数の構成パーツは、パーツタイプに基づき実行するように構成されることを特徴とする請求項１１に記載の方法。
14. ドキュメントパーツ選択を実行するように構成されている構成パーツのうち少なくとも一部は、いずれかの間から選択をするパーツに関連付けられているコンテンツタイプに基づき選択を実行できることを特徴とする請求項１３に記載の方法。
15. コンテンツタイプの選択は、少なくとも一部は、特定のコンテンツタイプを認識するソフトウェアが使用可能かどうかに基づくことを特徴とする請求項１４に記載の方法。
16. コンピュータ可読命令を含み、前記命令が実行されると、請求項１５に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
17. 請求項１６に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
18. コンピュータ可読命令を含み、前記命令が実行されると、請求項１１に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
19. 請求項１８に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
20. ドキュメントを定義するパッケージを構築するステップであって、前記パッケージは前記ドキュメントを構成する複数のパーツを含み、各々のパーツは関連付けられたタイプを有することと、
    前記パッケージ内に、１つまたは複数の構成パーツを含めるステップであって、前記構成パーツはドキュメントパーツ選択またはドキュメントパーツ順序付けの少なくとも一方を実行でき、ドキュメントパーツ選択を行う前記構成パーツは、言語タイプ、カラータイプ、ページサイズタイプ、またはコンテンツタイプのうちの少なく１つに基づき前記選択を行うことと、
    を備えることを特徴とする方法。
21. 前記含めるステップは、前記１つまたは複数の構成パーツをＸＭＬ要素として表すことを含むことを特徴とする請求項２０に記載の方法。
22. コンテンツタイプの選択は、少なくとも一部は、特定のコンテンツタイプを認識するソフトウェアが使用可能かどうかに基づくことを特徴とする請求項２０に記載の方法。
23. コンピュータ可読命令を含み、前記命令が実行されると、請求項２２に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
24. 請求項２３に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
25. コンピュータ可読命令を含み、前記命令が実行されると、請求項２０に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
26. 請求項２５に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
27. ドキュメントを定義するパッケージを受信するステップであって、前記パッケージは前記ドキュメントを構成する複数のパーツを含み、各々のパーツは関連付けられたタイプを有し、前記パッケージは１つまたは複数の構成パーツを含み、前記構成パーツはドキュメントパーツ選択またはドキュメントパーツ順序付けの少なくともいずれか一方を実行することができ、ドキュメントパーツ選択を行う前記構成パーツは、言語タイプ、カラータイプ、ページサイズタイプ、コンテンツタイプのうちの少なくとも１つに基づいて前記選択を実行できることと、
    前記１つまたは複数の構成パーツを識別するのに前記パッケージを処理するステップと、
    前記１つまたは複数の構成パーツに関連付けられたアクションを実行するステップと、
    を備えることを特徴とする方法。
28. 前記１つまたは複数の構成パーツは、ＸＭＬ要素として表されることを特徴とする請求項２７に記載の方法。
29. コンテンツタイプの選択は、少なくとも一部は、特定のコンテンツタイプを認識するソフトウェアが使用可能かどうかに基づくことを特徴とする請求項２７に記載の方法。
30. コンピュータ可読命令を含み、前記命令が実行されると、請求項２９に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
31. 請求項３０に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
32. コンピュータ可読命令を含み、前記命令が実行されると、請求項２７に記載の方法が実行されることを特徴とする１つまたは複数のコンピュータ読取り可能媒体。
33. 請求項３２に記載のコンピュータ読取り可能媒体を実現することを特徴とするコンピューティングシステム。
    

Images