專利名稱：維護包內(nèi)部件之間的關系的方法和裝置的制作方法
技術領域：
本發(fā)明涉及內(nèi)容框架、文檔格式以及可使用兩者的相關方法和系統(tǒng)。
背景技術：
當今通常有不同類型的內(nèi)容框架來表示內(nèi)容，并且不同類型的文檔格式來格式化各種類型的文檔。這些框架和格式的每一個常常需要其自己的相關聯(lián)的軟件，以構建、產(chǎn)生、處理或消耗相關聯(lián)的文檔。對于在適當?shù)脑O備上安裝了特定的關聯(lián)軟件的那些人，構建、產(chǎn)生、處理或消耗關聯(lián)文檔并不是一個問題。對于不具有適當軟件的那些人，構建、產(chǎn)生、處理或消耗關聯(lián)的文檔通常是不可能的。
針對這一背景，在考慮到文檔的產(chǎn)生和消耗的范圍內(nèi)，對這一普遍性有不斷的需求。
發(fā)明概述描述了模塊化的內(nèi)容框架和文檔格式方法和系統(tǒng)。描述的框架和格式定義了一組構件塊，用于組成、包裝、分發(fā)和呈現(xiàn)以文檔為中心的內(nèi)容。這些構件塊定義了一種用于文檔格式的平臺無關框架，使軟件和硬件系統(tǒng)能夠可靠并一致地生成、交換和顯示文檔。該框架和格式是以靈活和可擴充的方式設計的。
除這一通用框架和格式之外，使用該通用框架定義了一種特定的格式，稱為到達包(reach package)格式。到達包格式是用于儲存已編頁碼文檔的格式。到達包的內(nèi)容可以用完全的保真度在各種各樣的環(huán)境中的設備和應用程序之間，并且跨各種各樣的情形來顯示或打印。
附圖的簡要描述

圖1是依照一個實施例的示例性框架和格式的組件的框圖。
圖2是依照一個實施例容納包括若干部件的文檔的示例性包的框圖。
圖3所示是依照一個實施例產(chǎn)生包的示例性書寫者以及讀取包的示例性閱讀者的框圖。
圖4示出了將三個單獨的頁面綁定在一起的示例性部件。
圖5所示是依照一個實施例的示例性選擇器，以及被排列以產(chǎn)生包含報表的英語表示和法語表示的財務報表的序列的圖示。
圖6示出了依照一個實施例共同工作以交流包的書寫者和閱讀者的某些示例。
圖7示出了文檔的多個交錯部件的示例。
圖8和9示出了包裝圖7所示的文檔的多個部件的不同示例。
圖10示出了依照一個實施例的示例性到達包以及可構成該包或可在該包中找到的部件的每一個有效類型。
圖11示出了依照一個實施例從公用語言運行庫概念到XML的示例性映射。
圖12示出了依照一個實施例的豎直和橫向字形度量。
圖13示出了依照一個實施例的一對一群集映射。
圖14示出了依照一個實施例的多對一群集映射。
圖15示出了依照一個實施例的一對多群集映射。
圖16示出了依照一個實施例的多對多群集映射。
較佳實施例的詳細描述綜述本文檔描述了一種模塊化內(nèi)容框架和文檔格式。該框架和格式定義了一組構件塊，用于組成、包裝、分發(fā)和呈現(xiàn)以文檔為中心的內(nèi)容。這些構件塊定義了一種用于文檔格式的平臺無關框架，使軟件和硬件系統(tǒng)能夠可靠并一致地生成、交換和顯示文檔。該框架和格式是以靈活和可擴充的方式來設計的。在各種實施例中，對可包括的內(nèi)容類型、如何呈現(xiàn)內(nèi)容或構建用于處理內(nèi)容的客戶機的平臺沒有任何限制。
除這一通用框架之外，使用該通用框架定義了一種特定格式。該格式在本文檔中被稱為到達包格式，并且是用于儲存已編頁碼或預編頁碼的文檔的格式。到達包的內(nèi)容可以用完全的保真度在各種各樣的環(huán)境中的設備和應用程序之間，以及跨各種各樣的情形來顯示或打印。
下文描述的框架的目標之一是確保獨立書寫的軟件和硬件系統(tǒng)在讀取或書寫依照下文描述的框架和格式產(chǎn)生的內(nèi)容時的互操作性。為實現(xiàn)這一互操作性，所描述的格式定義了讀取或書寫內(nèi)容的系統(tǒng)必須滿足的形式要求。
以下討論是沿以下線條來組織的，并在兩個主要章節(jié)中提出—一個名為“框架”，另一個名為“到達包格式”。
名為“框架”的一節(jié)提出了一種說明性的包裝模型，并描述了構成框架包的各個部件和關系。討論了關于使用框架包中的描述性元數(shù)據(jù)的信息，以及映射到物理容器、擴展框架標記的過程，以及對框架版本化機制的使用。
名為“到達包格式”的一節(jié)研究了被稱為到達包的一個特定類型的框架構建包的結構。該節(jié)也描述了對固定的有效負載專用包部件，并定義了一種到達包標記模型和繪制模型。本節(jié)以示例性到達標記元素及其屬性連同所示的樣例一起結束。
作為以下討論的高級綜述，考慮圖1，它一般在100示出了本發(fā)明的框架和格式的各方面?？蚣艿哪承┦纠越M件在102示出，而到達包格式的某些組件在104示出。
框架102包括示例性組件，包括但不限于，關系組件、可插入容器組件、交錯/流組件以及版本化/可擴充性組件，其每一個都在下文更詳細地研究。到達包格式104包括組件，組件包括選擇器/定序器組件以及包標記定義組件。
在以下討論中，將周期性地回頭參考圖1，使得讀者可以維持關于所描述的組件適合框架和包格式的那里的觀點。
框架在以下討論中，提供了對通用框架的描述。各個初級小標題包括“包模型”、“排版部件選擇器和序列”、“描述性元數(shù)據(jù)”、“物理模型”、“物理映射”、以及“版本化和可擴充性”。每一初級小標題具有一個或多個相關小標題。
包模型本節(jié)描述了包模型，并包括描述包和部件、驅(qū)動程序、關系、包關系和起始部件的小標題。
包和部件在所示和描述的模型中，內(nèi)容被容納在包內(nèi)。包是容納相關部件的集合的邏輯實體。包的目的是將文檔的所有片段(或其它類型的內(nèi)容)收集到程序員和終端用戶易于工作的一個對象。例如，考慮圖2，示出了容納文檔的示例性包200，文檔包括若干部件，部件包括表示文檔的XML標記部件202、描述文檔中使用的字體的字體部件204、描述文檔的頁面的多個頁面部件206、以及表示文檔內(nèi)的圖片的圖片部件。表示文檔的XML標記部件202是有利的，因為它可準許容易的可搜索性和參考，而無需對包的整個內(nèi)容進行語法分析。這將在下文變得顯而易見。
貫穿該文檔，引入并討論的閱讀者(也稱為消費者)和書寫者(也稱為生產(chǎn)者)的概念。本文檔中使用的術語閱讀者指的是讀取基于模塊化內(nèi)容格式的文件或包的實體。本文檔中使用的術語書寫者指的是書寫基于模塊化內(nèi)容格式的文件或包。作為一個示例，考慮圖3，示出了產(chǎn)生包的書寫者和讀取包的閱讀者。通常，書寫者和閱讀者被具體化為軟件。在至少一個實施例中，與創(chuàng)建和格式化包相關聯(lián)的大多數(shù)處理開銷和復雜性被放置在書寫者上。這進而從閱讀者中消除了大多數(shù)處理復雜性和開銷，如本領域的技術人員所理解的，這是違背許多現(xiàn)有模型的。這一方面將在下文變得顯而易見。
依照至少一個實施例，單個包包含容納在包內(nèi)的內(nèi)容的一個或多個表示。通常，包是單個文件，在本申請中被稱為容器。例如，這給予終端用戶一種方便的方法來以文檔的所有組成片段(圖像、字體、數(shù)據(jù)等)分發(fā)其文檔。盡管包通常直接對應于單個文件，然而不必要總是如此。包是可以用各種方式來物理地表示的邏輯實體(例如，但不限于，在單個文件中、松散文件的集合、數(shù)據(jù)庫中、通過網(wǎng)絡連接的短暫傳輸?shù)鹊?。由此，容器容納包，但是并非所有的包都儲存在容器內(nèi)。
抽象模型與任一物理存儲機制無關地描述了包。例如，抽象模型并不涉及“文件”、“流”或與包所位于的物理領域有關的其它物理術語。如下文所討論的，抽象模型允許用戶為各種物理格式、通信協(xié)議等創(chuàng)建驅(qū)動程序。用類推的方法，當應用程序希望打印圖像時，它使用打印機的抽象(由理解特定種類的打印機的驅(qū)動程序呈現(xiàn))。由此，不需要應用程序知道特定的打印設備或如何與打印設備通信。
容器提供了除松散、斷開的文件集合之外的許多好處。例如，類似的組成部分可以被聚積，并且內(nèi)容可以被索引和壓縮。另外，組成部分之間的關系可以被識別，并且權限管理、數(shù)字簽名加密和元數(shù)據(jù)可以被應用到組成部分。當然，容器可用于并實施上文未具體列出的其它特征。
公用部件屬性在所示并描述的實施例中，部件包括公用屬性(如，名字)和字節(jié)流。這類似于文件系統(tǒng)中的文件或HTTP服務器上的資源。除其內(nèi)容之外，每一部件具有某些公用部件屬性。這包括名字—它是部件的名字，以及內(nèi)容類型—它是儲存在部件中的內(nèi)容的類型。部件也可以具有一個或多個相關聯(lián)的關系，如下文所討論的。
部件名是在必須在某些方面涉及到部件的任何時刻使用的。在所示和描述的實施例中，名字被組織成分層結構，這類似于文件系統(tǒng)中的路徑或URI中的路徑。以下是部件名的示例/document.xml/tickets/ticket.xml/images/march/summer.jpeg/pages/page4.xml如上文可以見到的，在這一實施例中，部件名具有以下特征●部件名類似于傳統(tǒng)文件系統(tǒng)中的文件名。
●部件名以正斜杠(“/”)開始。
●與文件系統(tǒng)中的路徑或URI中的路徑一樣，部件名可以按照一組類似目錄的名字(在以上示例中，為tickets、images/march)被組織成分層結構。
●該分層結構包括由正斜杠定界的段。
●名字的最后一段類似于傳統(tǒng)文件系統(tǒng)中的文件名。
重要的是注意，用于命名部件的規(guī)則，尤其是可用于部件名的有效字符，對本文檔中描述的框架是專用的。這些部件名規(guī)則基于互聯(lián)網(wǎng)標準的URI命名規(guī)則。依照本實施例，本實施例中用于指定部件名的語法完全與RFC 2396，同一資源標識符(URI類屬句法)規(guī)范的5(相關URI引用)和節(jié)3.3(路徑成分)中定義的abs path句法相匹配。
以下附加約束被應用到abs_path，作為有效的部件名●如節(jié)3(URI句法分量)和3.4(查詢分量)中定義的查詢分量不適用于部件名。
●如節(jié)4.1(分段標識符)中描述的分段標識符不適應于部件名。
●任一部件具有通過向現(xiàn)有部件的部件名追加*(“/”分段)來創(chuàng)建的名字是不合法的。
部件名的語法示出如下part_name ="/"segment*("/"segment)segment =*pcharpchar =unreserved|escaped|":"|"@"|"&"|"="|"+"|"$"|","unreserved =alphanum|markescaped="%"hex hexhex=digit|"A"|"B"|"C"|"D"|"E"|"F"|"a"|"b"|"c"|"d"|"e"|"f"mark ="-"|"_"|"."|"!"|"~"|"*"|"'"|"("|")"alpha =lowalpha|upalphalowalpha ="a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|"l"|"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|"w"|"x"|"y"|"z"upalpha="A"|"B"|"C"|"D"|"E"|"F"|"G"|"H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|"Q"|"R"|"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"digit ="0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"alphanum =alpha|digit可以看到包中所有部件的名字的分段形成了樹。這類似于文件系統(tǒng)中所發(fā)生的，其中，所有樹中的所有非葉節(jié)點是文件夾，而葉節(jié)點是包含內(nèi)容的實際文件。名字樹中這些類似文件夾的節(jié)點(即，非葉節(jié)點)服務組織包中的部件的類似功能。然而，重要的是記住，這些“文件夾”僅作為命名分層結構中的概念而存在—它們沒有持久格式的其它表現(xiàn)。
部件名不能在“文件夾”級存活。具體地，部件命名分層結構中的非葉節(jié)點(“文件夾”)不能包含具有相同名字的部件和子文件夾。
在所述并描述的實施例中，每一部件具有內(nèi)容類型，它定義了什么類型的內(nèi)容儲存在部件中。內(nèi)容類型的示例包括image/jpegtext/xmltext/plain;charset="us-ascii″內(nèi)容類型在RFC 2045(多用途互聯(lián)網(wǎng)郵件擴展；(MIME))中定義的所示的框架中使用。具體地，每一內(nèi)容類型包括媒體類型(例如，text(文本))、子類型(例如，plain(純文本))以及關鍵字＝值形式的可任選參數(shù)集(例如，charset="us-ascii")；多個參數(shù)由分號分隔。
部件定址通常部件包含到其它部件的引用。作為一個簡單的示例，想象具有兩個部件的容器標記文件和圖像。標記文件希望容納對圖像的引用，使得當處理標記文件時，可識別和定位關聯(lián)的圖像。內(nèi)容類型和XML模式的設計者可使用URI來表示這些引用。為使其成為可能，需要定義部件名的領域和URI領域之間的映射。
為允許在包內(nèi)使用URI，當評估基于包的內(nèi)容中的URI時，必須使用特殊的URI解釋規(guī)則包本身應當作為URI引用的“作者”來處理，而URI的路徑分量用于導航包內(nèi)的部件名分層結構。
例如，給定包URI http://www.example.com/foo/something.package，將對/abc/bar.xml的引用解釋為意味著名為/abc/bar.xml的部件，而非URIhttp://www.example.com/abc/bar.xml。
當必須具有從容器中的一個部件到另一個部件的引用時，應當使用相對URI。使用相對引用允許將容器的內(nèi)容一起移動到不同的容器(或移動到來自例如文件系統(tǒng)的容器)，而不修改部件間的引用。
來自部件的相對引用相對于包含該引用的部件的“基礎URI”來解釋。默認地，部件的基礎URI是部件的名字。
考慮包括具有以下名字的部件的容器/markup/page.xml/image/picture.jpeg/images/other_picture.jpeg如果“markup/page.xml”部件包含對“../images/picture.jpeg”的引用，則依照上述規(guī)則，該引用必須被解釋為涉及部件名“/images/picture.jpeg”。
某些內(nèi)容類型提供了通過指定內(nèi)容中的不同基礎來覆蓋默認基礎URI的方法。當存在這些覆蓋之一時，應當使用明確指定的基礎URI而非默認的基礎URI。
有時候，“地址”部件中的一部分或特定的點是有用的。在URI領域中，使用了分段標識符[見例如RFC2396]。在容器中，該機制以同樣的方式工作。具體地，分段是包含定址的部分的內(nèi)容類型的背景中理解的額外信息的串。例如，在視頻文件中，分段可標識幀，在XML文件中，它可通過xpath標識XML文件的一部分。
分段標識符結合定址部件的URI一起使用，來標識定址的部件的分段。分段標識符是可任選的，并且用交叉線(“#”)字符與URI分離。由此，它不是URI的一部分，但是通常結合URI一起使用。
以下描述提供了部件命名的某些指導，因為包和部件命名模型是相當靈活的。該靈活性允許框架包的各種各樣應用。然而，重要的是認識到，框架被設計成啟用了其中多個不相關軟件系統(tǒng)可操作“其自己的”包部件而不會彼此抵觸的情形。為允許這一情形，提供了某些方針，如果遵循這些方針，這種情形將成為可能。
此處給出的方針描述了用于最小化或至少減少部件命名沖突的出現(xiàn)，并在它們的確出現(xiàn)時處理它們的機制。創(chuàng)建包內(nèi)的部件的書寫者必須采取措施來檢測并處理與包中現(xiàn)有部件的命名沖突。在發(fā)生命名沖突的情況下，書寫者可能無法盲目地替換現(xiàn)有部件。
在保證包由單個書寫者操縱的情況下，該書寫者可與這些方針偏離。然而，如果有多個獨立書寫者共享一個包的可能性，則所有的書寫者必須遵循這些方針。然而，推薦的是所有的書寫者在任何情況下都遵循這些方針。
●要求將部件添加到現(xiàn)有容器的書寫者在命名分層結構的新“文件夾”中這樣做，而非直接替換根或預先存在的文件夾中的部件。以此方式，名字沖突的可能性被限于部件名的第一段。在該新文件夾內(nèi)創(chuàng)建的部件可以在沒有與現(xiàn)有部件沖突的風險的情況下來命名。
●在文件夾的“較佳”名字已經(jīng)被現(xiàn)有部件使用的情況下，書寫者必須采用某一策略來選擇替換文件夾名字。書寫者應當使用向較佳名字追加數(shù)字直到找到可用文件夾名的策略(可能在幾次不成功迭代之后采用GUID)。
●這一政策的一個結果是閱讀者不許試圖通過“魔法”或“公知”的部件名來定位部件。相反，書寫者必須創(chuàng)建與它們所創(chuàng)建的每一文件夾中的至少一個部件的包關系。閱讀者必須使用這些包關系來定位部件而非依賴于公知的名字。
●一旦閱讀者找到了文件夾中的至少一個部件(通過上述包關系之一)，則它可使用關于該文件夾內(nèi)的公知部件名的約定來找到其它部件。驅(qū)動程序此處描述的文件格式可以由不同的應用程序、不同的文檔類型等來使用—它們中的許多具有沖突的用途、沖突的格式等等。使用了一個或多個驅(qū)動程序來分解各種沖突，例如文件格式中的差異、通信協(xié)議中的差異等等。例如，不同的文件格式包括松散文件和復合文件，而不同的通信協(xié)議包括http、網(wǎng)絡和無線協(xié)議。一組驅(qū)動程序?qū)⒏鞣N文件格式和通信協(xié)議抽象成單個模型?？商峁┒鄠€驅(qū)動程序用于不同的情形、不同的消費者要求、不同的物理配置等等。
關系包中的部件可包含對該包中的其它部件的引用。然而，一般而言，這些引用以對該部件的內(nèi)容類型專用的方式在引用部件內(nèi)表示；即，以任意的標記或應用程序?qū)Ｓ镁幋a。這有效地隱藏了來自不理解包含這些引用的部件的內(nèi)容類型的閱讀者的部件之間的內(nèi)部聯(lián)接。
即使對于公用內(nèi)容類型(如到達包一節(jié)中描述的固定有效負載標記)，閱讀者需要對部件中的所有內(nèi)容進行語法分析，以發(fā)現(xiàn)并解析對其它部件的引用。例如，當實現(xiàn)一次打印文檔的一頁的打印系統(tǒng)時，可能期望識別包含在特定頁面中的圖片和字體?，F(xiàn)有的系統(tǒng)必須對每一頁的所有信息進行語法分析，這是耗時的，而且必須理解每一頁的語言，這不是某些設備或閱讀者的情況(例如，當在去設備的途中通過處理器管線在文檔上執(zhí)行中間處理的設備或閱讀者)。相反，此處描述的系統(tǒng)和方法使用了關系來識別部件之間的關系，并描述那些關系的特性。關系語言是簡單的，并被定義一次，使得閱讀者可以理解關系，而無需多個不同語言的知識。在一個實施例中，關系以XML表示為個別的部件。每一部件具有相關聯(lián)的關系部件，它包含部件是源的關系。
例如，電子表格應用程序使用這一格式并將不同的電子表格儲存為部件。不知道關于電子表格語言的應用程序仍能夠發(fā)現(xiàn)與電子表格相關聯(lián)的各種關系。例如，應用程序可發(fā)現(xiàn)電子表格中的圖像以及與電子表格相關聯(lián)的元數(shù)據(jù)。提供一個示例關系模式如下< xml version="1.0" ><xsd:schema xmlns:mmcfrels="http://mmcfrels-PLACEHOLDER"xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:attribute name="Target"type="xsd:string"/>
<xsd:attribute name="Name"type="xsd:string"/>
<xsd:element name="Relationships">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Relationship"minOccurs="0"maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Relationship">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute ref="Target"/>
<xsd:attribute ref="Name"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType></xsd:element></xsd:schema>
該模式定義了兩個XML元素，一個被稱為“relationships”，另一個被稱為“relationship”。“relationship”元素用于描述此處所描述的單個關系，并且具有以下屬性(1)“target”，它指示了源部件要關系到的部件，(2)“name”，它指示了關系的類型或特性。定義了“relationships”元素以允許它容納零個或多個“relationship”元素，并僅用于將這些“relationship”元素搜集在一起成一個單元。
此處所描述的系統(tǒng)和方法引入了更高級機制，以解決稱為“關系”的問題。關系提供了表示包中的源部件和目標部件之間的連接種類的額外方法。關系令部件之間的連接可以被直接“發(fā)現(xiàn)”，而不需要查看部件中的內(nèi)容，因此，它們獨立于內(nèi)容專用模式，并且能夠更快地被解析。另外，這些關系是協(xié)議無關的。各種不同的關系可以與特定的部件相關聯(lián)。
關系提供了第二個重要的功能允許部件相關而不需要修改它們。有時候，這一信息擔當“注釋”的形式，其中，“注釋的”部件的內(nèi)容類型不定義附加給定信息的方法。潛在的示例包括附加的描述性元數(shù)據(jù)、打印票據(jù)和真實注釋。最后，某些情況要求信息被特別地附加到現(xiàn)有的部件而不修改該部件—例如，當部件被加密并且不能被解密，或者當部件被數(shù)字地簽署并且改變它將使簽名無效時。在另一示例中，用戶可能希望將注釋附加到JPEG圖像文件。JPEG圖像格式當前不提供對識別注釋的支持。改變JPEG格式以容納這一用戶需求是不實際的。然而，此處討論的系統(tǒng)和方法允許用戶向JPEG文件提供注釋而不修改JPEG圖像格式。
在一個實施例中，使用關系部件中的XML來表示關系。容器中作為一個或多個關系的源的每一部件具有相關聯(lián)的關系部件。該關系部件容納(使用內(nèi)容類型application/PLACEHOLDER(應用程序/占位符)以XML表達)用于該源部件的關系列表。
下文圖4示出了環(huán)境400，其中“骨架(spine)”部件402(類似于固定面板)將三個頁面406、408和410綁定在一起。由骨架綁定在一起的該組頁面具有相關聯(lián)的“打印票據(jù)”404。另外，頁面2具有其自己的打印票據(jù)412。從骨架部件402到其打印票據(jù)404的連接以及從頁面2到其打印票據(jù)412的連接使用關系來表示。在圖4的排列中，骨架部件402具有相關聯(lián)的關系部件，它包含將骨架連接到票據(jù)1的關系，在以下示例中示出。<Relationships xmlns=”http://mmcfrels-PLACEHOLDER”>
<RelationshipTarget=”../tickets/ticketl.xml”Name=”http://mmcf-printing-ticket-PLACEHOLDER”/>
</Relationships>
關系使用單個<Relationships>元素中嵌套的<Relationship>元素來表示。這些元素在http://mmcfrels(PLACEHOLDER)名字空間中定義。見上文的示例模式，以及下文對示例關系的相關討論。
關系元素具有以下附加屬性

名字屬性不必要是實際的地址。不同類型的關系按其名字來標識。這些名字以對XML名字空間定義名字空間的同一方式來定義。具體地，通過使用模仿因特網(wǎng)域名空間的名字，非協(xié)調(diào)方可安全地創(chuàng)建不沖突的關系名字—正如它們可以對XML名字空間所做的一樣。
不允許關系部件參與其它關系。然而，在所有其它意義上它是第一類部件(例如，它是可URI定址的、它可以被打開、讀取、刪除等等)。關系通常不指向包外部的內(nèi)容。用于標識關系目標的URI一般不包括URI模式。
部件及其相關聯(lián)的關系部件通過命名約定來連接。在這一示例中，骨架的關系部件將儲存在/content/_rels/spine.xml.rels中，而頁面2的關系將儲存在/content/_rels/p2.xml.rels中。注意，此處使用了兩個特殊的命名約定。首先，某些名字分層結構中給定“文件夾”中的(其它)部件的關系部件儲存在名為_rels的“子文件夾”中(以標識關系)。其次，這一關系容納部件的名字通過向原始部件的名字追加.rels擴展名來形成。在特定的實施例中，關系部件是內(nèi)容類型application/xml+relationshipsPLACEHOLDER(應用程序/xml+關系占位符)。
關系表示了兩個部件之間的有向連接。由于表示關系的方式，從其源部件開始遍歷關系是有效的(因為找出任何給定部件的關系部件是平凡的)。然而，從關系的目標開始反向遍歷關系不是有效的(因為找出對部件的所有關系的方法是瀏覽容器中的所有關系)。
為使關系的反向遍歷成為可能，使用了新關系來表示其它(可遍歷)方向。這是關系類型的設計者可以使用的一種建模技術。繼續(xù)以上示例，如果重要的是能夠找出附加了票據(jù)1的骨架，則將使用從票據(jù)連接到骨架的第二關系，如
在content/_rels/pl.xml.rels中<Relationships xmlns=”http://mmcfrels-PLACEHOLDER”>
<RelationshipTarget=”/content/spine.xml”Name=”http://mmcf-printing-spine/PLACEHOLDER”/>
</Relationships>
包關系“包關系”用于找出包中公知的部件。該方法避免了依賴于用于找出包中的部件的命名約定，并確保了在不同有效負載中的相同部件名之間沒有抵觸。
包關系是一種特殊的關系，其目標是部件，而源不是部件源是整個包。具有“公知”的部件實際上是具有有助于找出該部件的“公知”關系名字。這能夠起作用，因為有定義良好的機制以允許由非協(xié)調(diào)方來命名關系，而某些實施例不包含這樣的部件名機制—那些實施例被限于一組方針。包關系在包關系部件中找到，并且使用關系部件的標準命名約定來命名。由此，它被命名為“/_rels/.rels”。
該包關系中的關系部件在找出公知部件時是有用的。
起始部件包級的公知部件的一個示例是包“起始”部件。這是通常在打開包時被處理的部件。它表示了儲存在包內(nèi)的文檔內(nèi)容的邏輯根。包的起始部件通過以下公知包關系來定位。在一個示例中，該關系具有以下名字http://mccf-start-part-PLACEHOLDER。
排版部件選擇器和序列所描述的框架定義了用于從部件構建更高階結構的兩種機制選擇器和序列。
選擇器是在多個其它部件之間“選擇”的部件。例如，選擇器部件可以在表示文檔的英語版本的部件和表示文檔的法語版本的部件之間“選擇”。序列是對多個其它部件“定序”的部件。例如，序列部件可以組合兩個部件(成一個線性序列)，其中一個表示五頁文檔，而另一個表示十頁文檔。
這兩種類型的排版部件(序列和選擇器)以及用于匯編它們的規(guī)則構成了組成模型。排版部件可組成其它排版部件，因此例如，可具有在兩個組成部分之間進行選擇的選擇器。作為一個示例，考慮圖5，它示出了包含英語表示和法語表示的財務報表的一個示例。這些表示的每一個進一步包括介紹(封面)以及其后的財務(電子表格)。在這一示例中，選擇器500在報表的英語和法語表示之間進行選擇。如果選擇了英語表示，則序列502將英語介紹部件506與英語財務部件508定序?；蛘?，如果選擇了法語部分，則序列504將法語介紹部件510與法語財務部件512定序。
排版部件XML在所述并描述的實施例中，排版部件是使用少數(shù)XML元素來描述的，它們都取自公用的組成部分名字空間。作為一個示例，考慮下列元素<selection>
屬性無允許的子元素<item>
元素<sequence>
屬性無允許的子元素<item>
元素<item>
屬性Target一組成部分中的部件的部件名作為一個示例，以下是上文圖5的示例的XMLMainDocument.XML<selection>
<item target=”EnglishRollup xml”/>
<item target=”FrenchRollup xml”/>
</selection>
EnglishRollup.XML<sequence>
<item target=”EnglishIntroduction xml”/>
<item target=”EnglishFinancials xml”/>
</sequence>
FrenchRollup.XML<sequence>
<item target=”FrenchIntroduction xml”>
<item target=”FrenchFinancials xml”>
</sequence>
在這一XML中，MainDocument.xml表示包中的整個部件，并且根據(jù)“selection”標簽，指示了要在由“item”標簽封裝的不同項，即“EnglishRollup.xml”和“FrenchRollup.xml”之間作出選擇。
根據(jù)“sequence”標簽，EnglishRollup.xml和FrenchRollup.xml是將由其各自的“item”標簽封裝的各自的項定序在一起的序列。
由此，提供了簡單的XML語法來描述選擇器和序列。這一組成塊中的每一部件被構建，并執(zhí)行一個操作—選擇或定序。通過使用部件的分層結構，可構建選擇和序列的不同健壯集合。
組成塊包的組成塊包括可從包的起始部件到達的所有排版部件(選擇器或序列)的集合。如果包的起始部件既非選擇器又非序列，則認為該組成塊為空。如果起始部件是排版部件，則遞歸地遍歷那些排版部件中的子<item>，以產(chǎn)生排版部件的有向非循環(huán)圖(當遇到非排版部件時停止遍歷)。該圖是組成塊(依照本發(fā)明，它必須是非循環(huán)的，以使包有效)。
確定組成部分語義建立了上述相對直接的XML語法之后，以下討論描述了表示信息使得可基于內(nèi)容類型作出選擇的方法。即，上述XML提供了足夠的信息，以允許閱讀者定位被匯編成一個組成部分的部件，但是未提供足夠的信息來幫助閱讀者知道關于組成部分的特性的更多信息。例如，給定組成兩個部件的選擇，閱讀者如何知道基于什么基準(例如，語言、紙張大小等)來作出選擇？答復是這些規(guī)則與排版部件的內(nèi)容類型相關聯(lián)。由此，用于基于語言在表示之間進行選取的選擇器部件具有與基于紙張大小在表示之間進行選取的選擇器部件不同的關聯(lián)內(nèi)容類型。
通用框架為這些內(nèi)容類型定義了通用形式Application/XML+Selector-SOMETHING(應用程序/XML+選擇器-某一內(nèi)容)
Application/XML+Sequence-SOMETHING(應用程序/XML+序列-某一內(nèi)容)這些內(nèi)容類型中的SOMETHING由指示選擇或序列的特性的詞來替換，例如，頁面大小、顏色、語言、閱讀者設備上的常駐軟件等等。因此，在此框架中，可發(fā)明所有種類的選擇器和序列，并且每一個可具有非常不同的語義。
描述的框架也定義了以下所有閱讀者或閱讀設備必須理解的選擇器和序列的公知內(nèi)容類型。

作為一個示例，考慮如下。假定包包含具有頁面的文件，并且在頁面的中間有要出現(xiàn)視頻的區(qū)域。在此示例中，頁面的視頻部件可包括Quicktime視頻形式的視頻。這一情形的一個問題是Quicktime視頻不是被普遍理解的。然而，假定依照本框架，尤其是下文描述的到達包格式，存在被普遍理解的圖像格式-JPEG。當產(chǎn)生包含上述文檔的包時，除將視頻定義為包的部件之外，生產(chǎn)者還為頁面定義了JPEG圖像，并提出了一種SupportedContentType(支持的內(nèi)容類型)選擇器，使得如果用戶的計算機具有理解Quicktime視頻的軟件，則選擇Quicktime視頻，否則選擇JPEG圖像。
由此，如上所述，框架級選擇器和序列組件允許構建健壯的分層結構，在此示例中，它是以XML定義的。另外，存在定義明確的方法，確定使用內(nèi)容類型時選擇器和序列的行為。另外，依照一個實施例，通用框架包括一個特定的內(nèi)容類型，它是預定義的，并允許基于消費者(例如，閱讀者或閱讀設備)理解什么和不理解什么來處理和使用包。
可使用類似的規(guī)則定義其它排版部件內(nèi)容類型，其示例在下文描述。
描述性元數(shù)據(jù)依照一個實施例，描述性元數(shù)據(jù)部件向包的書寫者或生產(chǎn)者提供了儲存屬性值的方法，它使包的閱讀者能夠可靠地發(fā)現(xiàn)該值。這些屬性通常用于記錄關于整個包以及容器內(nèi)的個別部件的附加信息。例如，包內(nèi)的描述性元數(shù)據(jù)部件可容納諸如包作者、關鍵字、概要等的信息。
在所示并描述的實施例中，描述性元數(shù)據(jù)以XML來表達、被儲存在公知內(nèi)容類型的部件中、并可使用公知關系類型來找到。
描述性元數(shù)據(jù)容納元數(shù)據(jù)屬性。元數(shù)據(jù)屬性由屬性名和一個或多個屬性值來表示。屬性值具有簡單的數(shù)據(jù)類型，因此每一數(shù)據(jù)類型由單個XML qname來描述。描述性元數(shù)據(jù)屬性具有簡單類型的事實并不意味著不能在包內(nèi)用復雜的XML類型來儲存數(shù)據(jù)。在這一情況下，必須將信息作為完整的XML部件來儲存。當完成時，刪除關于僅使用簡單類型的所有約束，但是“平面”描述性元數(shù)據(jù)屬性模型的簡單性丟失。
除用于定義屬性集的通用機制以外，有一種特定的、定義良好的、使用該機制儲存的文檔核心屬性集。這些文檔核心屬性通常用于描述文檔，并包括如標題、關鍵字、作者等的屬性。
最后，容納這些文檔核心屬性的元數(shù)據(jù)部件也可容納除文檔核心屬性之外的附加、用戶定義的屬性。
元數(shù)據(jù)格式依照本發(fā)明，描述性元數(shù)據(jù)具有內(nèi)容類型，并且依照以下規(guī)則的關系達到目標


以下XML模式用于依照一個實施例表現(xiàn)描述性元數(shù)據(jù)。關于標記的每一分量的細節(jié)在樣例后的表格中給出。<mcs:properties xmlns:mcs="http://mmcf-core-services/PLACEHOLDER"xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<mcs:property prns:name="property name"xmlns:prns="property namespace"mcs:type="datatype"mcs:multivalued="true|false">
<mcs:value>…value…</mcs:value>
</mcs:property></mcs:properties>


文檔核心屬性以下是包括屬性名、屬性類型和描述的文檔核心屬性的表格。


物理模型物理模型定義了書寫者和閱讀者使用包的各種方法。該模型基于三個組件書寫者、閱讀器以及它們之間的管道。圖6示出了共同工作以交流包的書寫者和閱讀者的某一示例。
管道將數(shù)據(jù)從書寫者傳送到閱讀者。在許多情況下，管道可以僅包括閱讀者作出的從本地文件系統(tǒng)讀取包的API調(diào)用。這被稱為直接訪問。
然而，通常閱讀者和書寫者必須通過某一類型的協(xié)議彼此通信。例如，這一通信可跨進程邊界或在服務器和臺式計算機之間發(fā)生。這被稱為聯(lián)網(wǎng)訪問，并且由于管道的通信特征(尤其是速度和請求等待時間)，它是重要的。
為允許最大的性能。物理包設計必須考慮三個重要領域內(nèi)的支持訪問樣式、布局樣式和通信樣式。
訪問樣式流式消耗由于書寫者和閱讀者之間使用聯(lián)網(wǎng)訪問的通信不是瞬時的，因此重要的是允許包的漸進創(chuàng)建和消耗。具體地，依照本實施例，推薦任何物理包格式被設計成允許閱讀者在包的所有比特通過管道傳送之前，當它接收到的數(shù)據(jù)(例如，部件)時開始解釋并處理該數(shù)據(jù)。這一能力被成為流消耗。
流式創(chuàng)建當書寫者開始創(chuàng)建包時，它并不總是知道它將會在包中放入什么。作為一個示例，當應用程序開始構建打印池文件包時，它可能不知道有多少頁需要被放入包中。作為另一示例，服務器上動態(tài)生成報表的程序可能無法認識到該報表有多長，或者報表具有多少圖片—直到它完全生成了該報表。為允許這類書寫者，物理包應當允許書寫者在已經(jīng)添加了其它部件之后動態(tài)地添加部件(例如，書寫者必須不被要求在開始書寫時預先規(guī)定它將創(chuàng)建多少部件)。另外，物理包應當允許書寫者在不知道該部件的最終長度的情況下開始書寫部件的內(nèi)容。這些要求共同啟用了流式創(chuàng)建。
同時創(chuàng)建和消耗在高管線化的體系結構中，流式創(chuàng)建和流式消耗可對特定的包同時發(fā)生。當設計物理包時，支持流式創(chuàng)建和支持流式消耗可在相反的方向推動設計。然而，找出支持兩者的設計通常是可能的。由于管線化體系結構中的好處，推薦物理包支持同時創(chuàng)建和消耗。
布局樣式物理包容納部件的集合。這些部件可以用兩種樣式之一來布局簡單排序和交錯。采用簡單排序，包內(nèi)的部件用定義的排序來布局。當以純線性方式傳送這樣的包時，從包內(nèi)的第一字節(jié)開始直到最后一個字節(jié)，第一部件的所有字節(jié)首先到達，然后第二部件的所有字節(jié)到達，依此類推。
采用交錯布局，多個部件的字節(jié)是交錯的，這在某些情況下允許改進的性能。從交錯中顯著獲益的兩個情況是多媒體回放(例如，同時傳送視頻和音頻)和內(nèi)嵌資源引用(例如，標記文件的中間對圖像的引用)。
交錯通過用于組織交錯部件的內(nèi)容的特殊約定來處理。通過將部件分割成片段并交錯這些片段，可能達到期望的交錯結果，同時仍可能容易地重建原始的較大部件。為理解交錯是如何工作的，圖7示出了涉及兩個部件的簡單示例content.xml702和image.jpeg 704。第一部件content.xml描述了頁的內(nèi)容，并且在該頁的中間是對應當出現(xiàn)在該頁上的圖像(image.jpeg)的引用。
為理解交錯為何是有價值的，考慮如何使用簡單排序在包內(nèi)排列這些部件，如圖8所示。處理該包(并且順序地接收字節(jié))的閱讀者在接收到所有的content.xml部件以及image.jpeg之前將無法顯示圖片。在某些情況下(例如，小或簡單的包，或快速通信鏈路)這可能不是問題。在其它情況下(例如，如果content.xml非常大或者通信鏈路非常慢)，則需要讀完所有的content.xml部件來獲得圖像將導致不可接受的性能或?qū)﹂喿x者系統(tǒng)施加不合理的存儲器需求。
為更接近理想的性能，能夠分割content.xml部件并將image.jpeg部件插入到中間，緊接著引用圖片之處將是較佳的。這允許閱讀者更早地開始處理圖像一旦它遇到引用，圖像數(shù)據(jù)就在后面。例如，這將產(chǎn)生圖9所示的包布局。由于性能利益，通常期望物理包支持交錯。根據(jù)使用的物理包的類型，可以支持或不支持交錯。不同的物理包可不同地處理交錯的內(nèi)部表示。不管物理包如何處理交錯，重要的是記住，交錯是在物理層上出現(xiàn)的優(yōu)化，并且被分割成物理文件中的多個片段的部件仍是一個邏輯部件；片段本身不是部件。
通信樣式書寫者和閱讀者之間的通信可以基于部件的順序傳送或按對部件的隨機訪問來進行，從而允許它們不按順序來訪問。使用這些通信樣式的哪一個取決于管道和物理包格式的能力。一般而言，所有的管道支持順序傳送。物理包必須支持順序傳送。為支持隨機訪問情形，使用的管道和物理包都必須支持隨機訪問。某些管道基于允許隨機訪問的協(xié)議(例如，具有字節(jié)范圍支持的HTTP 1.1)。為在使用這些管道時允許最大性能，推薦物理包支持隨機訪問。在缺少這一支持的情況下，閱讀者將簡單地等待，直到它們需要的部件被順序地傳送。
物理映射邏輯包裝模型定義了包抽象；包的實際示例基于包的某一特定物理表示。包裝模型可以被映射到物理持久格式以及各種傳輸(例如，基于網(wǎng)絡的協(xié)議)。物理包格式可以被描述為從抽象包裝模型的分量到特定的物理格式特征的映射。包裝模型未指定應當使用哪些物理包格式來歸檔、分發(fā)或假脫機操作包。在一個實施例中，僅指定了邏輯結構。包可以由松散文件的集合、.ZIP文件檔案、復合文件或某一其它格式“物理地”實施。所選擇的格式由目標消耗設備支持，或由設備的驅(qū)動程序支持。
被映射的分量每一物理包格式為以下分量定義了映射。某些分量是可任選的，并且特定的物理包格式可能不支持這些可任選的分量。


公用映射模式

存在許多物理存儲格式，其特征部分地與包裝模型分量相匹配。在定義從包裝模型到這類存儲格式的映射時，可能期望利用包裝模型和物理存儲介質(zhì)之間的任何能力相似性，同時使用映射的層來提供物理存儲介質(zhì)中不固有存在的附加能力。例如，某些物理包格式可將個別的部件儲存為文件系統(tǒng)中的個別文件。以這一物理格式，將許多部件名直接映射到相同的物理文件名字是自然的。使用不是有效文件系統(tǒng)文件名的字符的部件名可能需要某種類型的轉(zhuǎn)義機制。
在許多情況下，不同物理包格式的設計者可能面對單個公共的映射問題。公共映射問題的兩個示例是在將任意的內(nèi)容類型與部件相關聯(lián)時，以及當支持交錯布局樣式時產(chǎn)生的。本說明書建議了對這類公共映射問題的公用解決方案。特定物理包格式的設計者可以被鼓勵，但并不要求來使用此處定義的公用映射解決方案。
標識部件的內(nèi)容類型物理包格式映射定義了用于儲存每一部件的內(nèi)容類型的機制。某些物理包格式具有用于表現(xiàn)內(nèi)容類型的本機機制(例如，MIME中的“Content-Type”標題)。對于這些物理包，推薦映射使用本機機制來表示部件的內(nèi)容類型。對于其它物理格式，使用某些其它機制來表示內(nèi)容類型。推薦的用于表示這些包中的內(nèi)容類型的機制是通過在包內(nèi)包括特別命名的XML流，稱為類型流。該流不是部件，并且因此其本身不是URI可定址的。然而，它可以在物理包內(nèi)使用用于交錯部件的相同機制來交錯。
類型流包含具有頂級“Types”元素以及一個或多個“Default”和“Overide”子元素的XML。“Default”元素定義了從部件名擴展名到內(nèi)容類型的默認映射。這利用了文件擴展名通常對應于內(nèi)容類型的事實。“Override”元素用于指定不被默認映射覆蓋或不與默認映射一致的部件上的內(nèi)容類型。包書寫者可使用“Default”元素來減少每一部件“Override”元素的數(shù)量，但是不必要如此。
“Default”元素具有以下屬性

“Override”元素具有以下屬性

以下是包含在類型流中的XML的一個示例
<Types xmlns="http://mmcfcontent-PLACEHOLDER"><Default Extension="txt"ContentType="plain/text"/><Default Extension="jpeg"ContentType="image/jpeg"/><Default Extension="picture"ContentType="image/gif"/><Override PartName="/a/b/sample4.picture"ContentType="image/jpeg"/></Types>
以下表格示出了部件及其由以上類型流定義的對應內(nèi)容類型的示例列表

對于包內(nèi)的每一部件，類型流包含以下的任一個(a)一個匹配的“Default”元素，(b)一個匹配的“Override”元素，或者(c)匹配的“Default”元素和匹配的“Override”元素兩者(在這一情況下，“Override”元素有優(yōu)先級)。一般而言，對任一給定的擴展名，最多有一個“Default”元素，并且對任一給定的部件名，最多有一個“Override”元素。
類型流中“Default”和“Override”元素的順序不是重要的。然而，在交錯包中，“Default”和“Override”元素在物理包中出現(xiàn)在它們對應的部件之前。
交錯并非所有的物理包都本機地支持部件的數(shù)據(jù)流的交錯。在一個實施例中，到任一這樣的物理包的映射使用了本節(jié)中描述的通用機制以允許部件的交錯。通用機制通過將部件的數(shù)據(jù)流分割成可與其它部件的片段或整個部件交錯的多個片段來工作。部件的個別片段在物理映射中存在，并且在邏輯包裝模型中不是可定址的。分段可具有零長度。
定義了以下從部件名到部件的個別片段的名字的唯一映射，使得閱讀者可以按其原始的順序?qū)⑵慰p合在一起以形成部件的數(shù)據(jù)流。
用于導出給定部件名的片段名的語法
piece_name=part_name"/""["l*digit"]"[".last"]".piece"以下有效性約束對由該語法生成的piece_names存在●片段號以0開始，并且是正的、連續(xù)的整數(shù)。片段號可以被左零填充(left-zero-padded)。
●部件的片段集的最后一個片段包含片段名中“.piece”之前的“.last”。
●片段名在映射到物理包中的名字之前從邏輯部件的名字生成。
盡管不必要以其自然順序儲存片段，但是這樣的存儲可提供優(yōu)化的效率。包含交錯(分段)的部件的物理包也可包含非交錯(單片段)部件，因此以下示例是有效的spine.xaml/
.piecepages/page0.xamlspine.xaml/[1].piecepages/pagel.xamlspine.xaml/[2].last.piecepages/page2.xaml特定映射下文定義了對以下物理格式的特定映射Windows文件系統(tǒng)中的松散文件。
到Windows文件系統(tǒng)中的松散文件的映射為更好地理解如何將邏輯模型的元素映射到物理格式，考慮將Metro包表示為Windows文件系統(tǒng)中的松散文件的集合的基本情況。邏輯包中的每一部件將包含在單獨的文件(流)內(nèi)。邏輯模型中的每一部件名對應于文件名。

部件名被轉(zhuǎn)換成有效的Windows文件名，如以下表格中示出的。
下文給出的是兩個字符集，它們對于邏輯部件名段(URI段)和Windows文件名是有效的。該表格展示了兩個重要的內(nèi)容存在兩個有效的URI符號，冒號()和星號(*)，在將URI轉(zhuǎn)化成文件名時需要對這兩個符號轉(zhuǎn)義。
存在有效的文件名符號＾{}[]#，它們不能以URI呈現(xiàn)(它們可用于特殊的映射目的，如交錯)。
“轉(zhuǎn)義”用作在部件名包含不能在文件名中使用的字符時產(chǎn)生有效文件名字符的技術。為對字符轉(zhuǎn)義，使用了脫字符號(＾)，其后跟隨字符的十六進制表示。
為從abs_path(部件名)映射到文件名首先刪除/將所有的/轉(zhuǎn)化成\對冒號和星號字符轉(zhuǎn)義例如，部件名/a:b/c/d*.xaml變?yōu)橐韵挛募鸻＾25b\c\d＾2a.xaml。
為執(zhí)行反向映射將所有的\轉(zhuǎn)化成/向串的起始添加/通過用對應的字符替換＾[十六進制代碼]對字符解轉(zhuǎn)義(unescape)


版本化和可擴充性與其它技術規(guī)范一樣，此處包含的規(guī)范可用未來的增強來進展。這一規(guī)范的第一版的設計包括用于基于第一版書寫的軟件系統(tǒng)以及為未來版本書寫的軟件系統(tǒng)之間的文檔的未來互換的計劃。類似地，該規(guī)范允許第三方創(chuàng)建對該規(guī)范的擴展。這一擴展可以例如允許構造充分利用某一特定打印機的特征的文檔，同時仍維持與不知道該打印機的存在的其它閱讀者的兼容性。
使用固定有效負載標記的新版本或?qū)擞浀牡谌綌U展的文檔要求閱讀者進行關于行為(例如，如何可視地呈現(xiàn)某些內(nèi)容)的適當判斷。為指導閱讀者，文檔的作者(或生成該文檔的工具)應當為遇到其它未識別元素或?qū)傩缘拈喿x者標識適當?shù)男袨椤τ诘竭_文檔，這一類型的指導是重要的。
新的打印機、瀏覽器和其它客戶機可實現(xiàn)對未來特征的各種支持。利用新版本或擴展的文檔作者必須仔細地考慮不知道那些擴展版本的閱讀者的行為。
版本化名字空間XML標記識別基于名字空間URL。對于任一XML名字空間，期望閱讀者識別所有的XML元素以及該名字空間中定義的XML屬性，或不識別任何東西。如果閱讀者不識別新的名字空間，則閱讀者需要執(zhí)行文檔中指定的后退呈現(xiàn)操作。
XML名字空間URI“http://PLACEHOLDER/version-control”包括用于構造固定有效負載標記的XML元素和屬性，該標記是版本自適應和擴展自適應的。固定有效負載不需要在其中具有版本化元素。然而，為構建自適應的內(nèi)容，必須使用<ver:Compatibility.Rules>和<ver:AlternativeContent>XML元素的至少一個。
這一固定有效負載標記規(guī)范具有與其相關聯(lián)的xmlns URI:“http://PLACEHOLDER/pdl”。在固定有效負載中使用該名字空間將指示閱讀者應用程序，僅使用該規(guī)范中定義的元素。該規(guī)范的未來版本將具有其自己的名字空間。熟悉新名字空間的閱讀者應用程序?qū)⒅廊绾沃С窒惹暗陌姹局卸x的元素或?qū)傩缘某?。不熟悉新版本的閱讀者應用程序?qū)⑿掳姹镜腢RI考慮成它是對PDL的某一未知擴展的URL一樣。這些應用程序可能不知道在名字空間之間存在關系，即一個是另一個的超集。
后向和“前向”兼容性在支持此處所討論的系統(tǒng)和方法的應用程序或設備的環(huán)境中，兼容性由客戶機對使用規(guī)范的先前版本或規(guī)范的未知擴展或版本創(chuàng)作的文檔進行語法分析和顯示的能力來指示。各種版本化機制解決了“后向兼容性”，允許客戶機的未來實現(xiàn)能夠支持基于規(guī)范的下級版本的文檔，如下文所示出的。
當諸如打印機等已實現(xiàn)的客戶機接受到使用標記語言的未來版本構建的文檔時，客戶機能夠?qū)捎贸尸F(xiàn)選項進行語法分析并理解它們。依照規(guī)范的較舊版本書寫的客戶機軟件使用較新版本特征處理某些文檔的能力通常被稱為“前向兼容性”。被書寫成允許前向兼容性的文檔被描述為“版本自適應的”。
此外，由于已實現(xiàn)的客戶機也需要能夠支持具有表示新元素或?qū)傩缘奈粗獢U展的文檔，因此各種語義支持“擴展自適應的”文檔的更一般情況。
如果打印機或察看器遇到未知的擴展，它將查找連同擴展的使用一起嵌入的信息，以找出關于自適應地呈現(xiàn)環(huán)繞的內(nèi)容的指導。這一自適應涉及用理解的內(nèi)容替換未知的元素或?qū)傩浴Ｈ欢?，自適應可采用其它形式，包括純忽略未知內(nèi)容。在缺乏明確指導的情況下，閱讀者應當將標記中未識別的擴展的存在視為錯誤條件。如果未提供指導，則假定擴展對理解內(nèi)容是基本的。呈現(xiàn)失敗將被捕捉并報告給用戶。
為支持這一模型，標記語言的新的和擴展的版本應當邏輯上組合名字空間中的相關擴展。以此方式，文檔作者能夠使用最少數(shù)量的名字空間來利用擴展的特征。
版本化標記用于支持擴展自適應行為的XML詞匯包括以下元素


<Compatibility.Rules>元素Compatibility.Rules可以被附加到可容納附加的屬性的任一元素上，如附加到Xaml根元素上。<Compatibility.Rules>元素控制語法分析器如何對未知元素或?qū)傩苑磻?。通常這些項被報告為錯誤。向Compatibility.Rules屬性添加Ignorable元素通知了編譯器來自某些名字空間的項可被忽略。
Compatibility.Rules可包含元素Ignorable和MustUnderstand。默認地，所有的元素和屬性被假定為MustUnderstand。元素和屬性可以通過將Ignorable元素添加到其容器的Compatibility.Rules屬性中來變成Ignorable。元素或?qū)傩钥梢酝ㄟ^將MustUnderstand元素添加到嵌套容器之一再一次變成MustUnderstand。一個Ignorable或MustUnderstand指同一Compatibility.Rules元素中的特定名字空間URI。
<Compatibility.Rules>元素影響容器的內(nèi)容，而非容器自己的標簽或?qū)傩?。為影響容器的標簽或?qū)傩裕淙萜鞅仨毎嫒菪砸?guī)則。Xaml根元素可用于為將另外成為根元素的元素，如Canvas指定兼容性規(guī)則。Compatibility.Rules復合屬性是容器中的第一元素。
<Ignorable>元素
<Ignorable>元素聲明了所包含的名字空間URI是可忽略的。如果在當前塊或容器塊中在項的前方聲明了<Ignorable>標簽，并且名字空間URI對語法分析器是未知的，則該項可認為是可忽略的。如果URI已知，則可不予處理Ignorable標簽，并且所有的項都是理解的。在一個實施例中，未被明確聲明為Ignorable的所有項必須被理解。Ignorable元素可包含<ProcessContent>和<CarryAlong>元素，它們用于修改如何忽略元素以及向文檔編輯工具給予應當如何在編輯的文檔中保存這些內(nèi)容的指導。
<ProcessContent>元素<ProcessContent>元素聲明了如果元素被忽略，則元素的內(nèi)容將如同它由被忽略的元素的容器包含那樣被處理。
<ProcessContent>屬性

<CarryAlong>元素可任選的<CarryAlong>元素向文檔編輯工具指示當修改文檔時是否應當保存可忽略的內(nèi)容。編輯工具保存或丟棄可忽略內(nèi)容的方法是在編輯工具的域中。如果多個<CarryAlong>元素指名字空間中的同一元素或?qū)傩裕瑒t指定的最后一個<CarryAlong>具有優(yōu)先級。
<CarryAlong>屬性


<MustUnderstand>元素<MustUnderstand>是倒轉(zhuǎn)Ingorable元素的效果的元素。例如，當與替換內(nèi)容結合時，這一技術是有用的。在<MustUnderstand>元素定義的范圍外，元素保持Ignorable。
<MustUnderstand>屬性

<AlternateContent>元素<AlternateContent>元素允許如果指定內(nèi)容的任一部分不被理解則提供替換內(nèi)容。AlternateContent塊使用了<Prefer>和<Fallback>塊。如果<Prefer>塊中的任何內(nèi)容不被理解，則使用<Fallback>塊中的內(nèi)容。名字空間被聲明為<MustUnderstand>，以指示要使用后退。如果名字空間被聲明為可忽略并且在<Prefer>塊中使用了該名字空間，則不使用<Fallback>塊中的內(nèi)容。
版本化標記示例使用<Ignorable>
本示例使用了假想的標記名字空間http://PLACEHOLDER/Circle，它定義了其初始版本中的元素Circle，并使用了引入到標記的未來版本(版本2)中的Circle的Opacity屬性，以及引入到標記的更后版本(版本3)中的Luminance屬性。這一標記在版本1和2中，以及3和隨后的版本中保持可加載。另外，<CarryAlong>元素指定了當編輯時，甚至在編輯器不理解v3:Luminance時，也必須保存v3:Luminance。
對于版本1閱讀者，忽略Opacity和Luminance對于版本2閱讀者，僅忽略Luminance對于版本3及以后的版本的閱讀者，使用所有的屬性。<FixedPanelxmlns="http://PLACEHOLDER/fixed-content"xmlns:v="http://PLACEHODER/versioned-content"xmlns:v1="http://PLACEHODER/Circle/v1"xmlns:v2="http://PLACEHODER/Circle/v2"xmlns:v3="http://PLACEHODER/Circle/v3"><v:Compatibility.Rules>
<v:Ignorable NamespaceUri="http://PLACEHODER/Circle/v2"/>
<v:Ignorable NamespaceUri="http://PLACEHODER/Circle/v3">
<v:CarryAlong Attributes="Luminance"/>
</v:Ignorable></v:Compatibility.Rules><Canvas>
<Circle Center="0,0"Radius="20"Color="Blue"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="25,0"Radius="20"Color="Black"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="50,0"Radius="20"Color="Red"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="13,20"Radius="20"Color="Yellow"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="38,20"Radius="20"Color="Green"v2:Opacity="0.5"v3:Luminance="13"/></Canvas></FixedPanel>
使用<MustUnderstand>
以下示例闡明了對<MustUnderstand>元素的使用。<FixedPanelxmlns="http://PLACEHOLDER/fixed-content"xmlns:v="http://PLACEHODER/versioned-content"xmlns:v1="http://PLACEHODER/Circle/v1"xmlns:v2="http://PLACEHODER/Circle/v2"xmlns:v3="http://PLACEHODER/Circle/v3"><v:Compatibility.Rules><v:Ignorable NamespaceUri="http://PLACEHODER/Circle/v2"/><v:Ignorable NamespaceUri="http://PLACEHODER/Circle/v3">
<v:CarryAlong Attributes="Luminance"/></v:Ignorable></v:Compatibility.Rules><Canvas><v:Compatibility.Rules>
<v:MustUnderstand NamespaceUri="http://PLACEHODER/Circle/v3"/></v:Compatbility.Rules><Circle Center="0,0"Radius="20"Color="Blue "v2:Opacity="0.5"v3:Luminance="13"/><Circle Center="25,0"Radius="20"Color="Black"v2:Opacity="0.5"v3:Luminance="13"/><Circle Center="50,0"Radius="20"Color="Red"v2:Opacity="0.5"v3:Luminance="13"/><Circle Center="13,20"Radius="20"Color="Yellow"v2:Opacity="0.5"v3:Luminance="13"/><Circle Center="38,20"Radius="20"Color="Green"v2:Opacity="0.5"v3:Luminance="13"/></Canvas></FixedPanel>
對<MustUnderstand>元素的使用導致對v3:Luminance的引用錯誤，即使它在根元素中被聲明為Ignorable。如果與使用例如添加到版本2中的Canvas的Luminance屬性(見下文)的替換內(nèi)容結合，則這一技術是有用的。在Canvas元素的范圍外，Circle的Luminance屬性再次是可忽略的。<FixedPanelxmlns="http://PLACEHOLDER/fixed-content"xmlns:v="http://PLACEHODER/versioned-content"xmlns:v1="http://PLACEHODER/Circle/v1"xmlns:v2="http://PLACEHODER/Circle/v2"xmlns:v3="http://PLACEHODER/Circle/v3"><v:Compatibility.Rules><v:Ignorable NamespaceUri="http://PLACEHODER/Circle/v2"/><v:Ignorable NamespaceUri="http://PLACEHODER/Circle/v3">
<v:CarryAlong Attributes="Luminance"/></v:Ignorable></v:Compatibility.Rules><Canvas><v:Compatibility.Rules>
<v:MustUnderstand NamespaceUri="http://PLACEHODER/Circle/v3"/></v:Compatbility.Rules><v:AlternateContent>
<v:Prefer>
<Circle Center="0,0"Radius="20"Color="Blue"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="25,0"Radius="20"Color="Black"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="50,0"Radius="20"Color="Red"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="13,20"Radius="20"Color="Yellow"v2:Opacity="0.5"v3:Luminance="13"/>
<Circle Center="38,20"Radius="20"Color="Green"v2:Opacity="0.5"v3:Luminance="13"/>
</v:Prefer>
<v:Fallback>
<Canvas Luminance="13">
<Circle Center="0,0"Radius="20"Color="Blue"v2:Opacity="0.5"/>
<Circle Center="25,0"Radius="20"Color="Black"v2:Opacity="0.5"/>
<Circle Center="50,0"Radius="20"Color="Red"v2:Opacity="0.5"/>
<Circle Center="13,20"Radius="20"Color="Yellow"v2:Opacity="0.5"/>
<Circle Center="38,20"Radius="20"Color="Green"v2:Opacity="0.5"/>
</Canvas>
</v:Fallback>
</v:AlternateContent></Canvas></FixedPanel>
使用<AlternateContent>
如果任一元素或?qū)傩员宦暶鳛?amp;lt;MustUnderstand>，但是在<AlternateContent>塊的<Prefer>塊中不被理解，則整體跳過<Prefer>塊，并如常地處理<Fallback>塊(即，遇到的任何MustUnderstand項被報告為錯誤)。<v:AlternateContent><v:Prefer><Path xmlns:m="http://schemas.example.com/2008/metallic-finishes"m:Finish="GoldLeaf"...../></v:Prefer><v:Fallback><Path Fill="Gold"...../></v:Fallback></v:AlternateContent>
到達包格式在以下的討論中，提供了對特定文件格式的描述。本節(jié)中的各個初級小標題包括“對到達包格式的介紹”、“到達包結構”、“固定有效負載部件”、“固定頁標記基礎”、“固定有效負載元素和屬性”以及“固定頁標記”。每一初級小標題具有一個或多個相關的小標題。
對到達包格式的介紹在上文描述了示例性框架之后，以下的描述是使用上述工具提供的特定格式之一。要意識到和理解，以下描述僅構成了一個示例性格式，并不想要限制要求保護的本發(fā)明的應用。
依照本實施例，單個包可包含多個有效負載，其每一個擔當文檔的不同表示。有效負載是部件的集合，包括可標識的“根”部件和該根部件的有效處理所需的所有部件。例如，有效負載可以是文檔的固定表示、可重新流動的表示或任何任意的表示。
以下描述定義了被稱為“固定有效負載”的特定表示。固定有效負載具有包含固定面板標記的根部件，它進而引用固定頁部件。這些共同描述了多頁文檔的精確呈現(xiàn)。
容納至少一個固定有效負載，并遵循以下描述的其它規(guī)則的包被稱為到達包。到達包的閱讀者和書寫者可基于到達包格式的規(guī)范實現(xiàn)其自己的語法分析器和呈現(xiàn)引擎。
到達包的特征依照所描述的實施例，到達包解決了信息工作者對分發(fā)、歸檔和呈現(xiàn)文檔的需求。使用已知的呈現(xiàn)規(guī)則，到達包可以從保存它們的格式中明白且明確地再生或打印，而無需將客戶機設備或應用程序綁定到特定的操作系統(tǒng)或服務庫。另外，由于到達有效負載是以中立的、應用程序無關的方式來表達的，因此文檔通?？梢栽跊]有用于創(chuàng)建該包的應用程序的情況下來察看和打印。為提供這一能力，在到達包中引入并包含了固定有效負載的概念。
依照所描述的實施例，固定有效負載具有固定數(shù)量的頁，并且分頁符總是相同的。固定有效負載中頁面上所有元素的布局是預定的。每一頁具有固定的大小和方向。由此，不必要在消費端上執(zhí)行布局計算，并且可容易地呈現(xiàn)內(nèi)容。這不僅應用到圖形，也應用到文本，它在固定有效負載中用精確的排字布局來表示。頁面的內(nèi)容(文本、圖形、圖像)使用更強大但是更簡單的可視原語集來描述。
到達包支持用于組織頁面的各種機制。一組頁面逐個被“粘合”在一起成“固定面板”。該組頁面粗略地等效于傳統(tǒng)的多頁文檔。固定面板然后可進一步參與組成—構建序列和選擇以匯編“復合”文檔的過程。
在所示并描述的實施例中，到達包支持一種特定種類的序列，稱為固定面板序列，它可用于例如將一組固定面板粘合在一起成單個、較大的“文檔”。例如，想像將來自不同來源的兩個文檔粘合在一起一個兩頁的封面?zhèn)渫?固定面板)以及二十頁的報表(固定面板)。
到達包支持多個特定選擇器，它們可在構建包含“相同”內(nèi)容的替換表示的文檔包時使用。具體地，到達包允許基于語言、顏色能力和頁面大小的選擇。由此，例如，可具有雙語言文檔，它使用選擇器在文檔的英語表示和法語表示之間選取。
除選擇器和序列對于到達包的組成的這些簡單使用之外，重要的是注意，選擇器和序列還可指進一步的選擇器和序列，由此允許構建強大的聚積分層結構。依照本實施例，關于什么可以完成以及什么不能完成的確切規(guī)則在下文名為“到達包結構”一節(jié)中指定。
另外，到達包可包含附加的有效負載，它們不是固定有效負載，而是文檔的更豐富并且可能可編輯的表示。這允許包包含在編輯器應用程序中運作良好的豐富的、可編輯的文檔，以及視覺上準確并可以在不編輯應用程序的情況下察看的表示。
最后，依照該實施例，到達包支持所謂的打印票據(jù)。打印票據(jù)提供了應當在打印包時使用的設置。這些打印票據(jù)可以用各種方式附加，以實現(xiàn)實質(zhì)的靈活性。例如，打印票據(jù)可以被附加到整個包，并且其設置將影響整個包。打印票據(jù)還可以在結構中的較低級別上附加(例如，附加到個別的頁)，并且這些打印票據(jù)將提供在打印它們所附加的部件時使用的覆蓋設置。
到達包結構如上所述，到達包支持一組特征，包括“固定”頁面、固定面板、組成部分、打印票據(jù)等等。這些特征在包內(nèi)使用包模型的核心組件來表示部件和關系。在本節(jié)及其相關的小節(jié)中，提供了對“到達包”的完整描述，包括所有這些部件和關系必須如何被匯編、相關等的描述。
到達包結構綜述圖10示出了一個示例性到達包，并且在本實施例中，示出了可構成包或在包中找到的部件的每一有效類型。下文提供的表格列出了每一有效部件類型，并提供了每一個的描述

由于到達包被設計成“在任何地方察看和打印”的文檔，因此到達包的閱讀者和書寫者必須共享對什么構成了“有效”到達包的公用、明白定義的期望。為提供“有效”到達包的定義，下文首先定義若干概念。
到達排版部件到達包必須包含可通過從包的起始部件開始遍歷組成塊來“發(fā)現(xiàn)”的至少一個固定面板。依照所描述的實施例，發(fā)現(xiàn)過程遵循以下算法●從包的起始部件開始遞歸地遍歷排版部件圖。
●當執(zhí)行該遍歷時，僅遍歷到作為到達排版部件(以下描述)的排版部件中。
●在圖的邊上定位所有的終端節(jié)點(沒有向外的弧的節(jié)點)。
這些終端節(jié)點指的是(通過其<item>元素)一組被稱為到達有效負載根的部件。
固定有效負載固定有效負載是其根部件是固定面板部件的有效負載。例如，圖10中的每一固定有效負載具有相關聯(lián)的固定面板部件作為其根部件。有效負載包括固定面板的有效處理所需的所有部件的完整閉包。這包括●固定面板本身；●從固定面板內(nèi)引用的所有固定頁；●由有效負載中的任一固定頁(直接或通過選擇器間接)引用的所有圖像部件；●從有效負載內(nèi)的任一固定頁內(nèi)使用的圖像刷直接或間接引用的所有到達選擇器(下文描述)；●由有效負載中的任一固定頁引用的所有字體部件；●附加到固定有效負載的任一部件的所有描述性元數(shù)據(jù)部件；以及●附加到固定有效負載中的任一部件的任一打印票據(jù)。
用于到達包的有效性規(guī)則在適當?shù)奈恢糜辛松鲜龆x，現(xiàn)在描述依照所描述的實施例描述“有效”到達包的一致性規(guī)則●到達包必須具有使用上述包關系的標準機制定義的起始部件；●到達包的起始部件必須是選擇器或序列；●到達包必須具有作為固定面板的至少一個到達有效負載根；
●打印票據(jù)部件可以被附加到任一排版部件、固定面板部件或固定面板內(nèi)標識的任一固定頁部件。在本實例中，這是通過http://PLACEHOLDER/HasPrintTicketRel關系來完成的；○打印票據(jù)可以被附加到這些部件的任一個或所有；○任一給定部件必須附加不多于一個的打印票據(jù)；●描述性元數(shù)據(jù)部件可以被附加到包內(nèi)的任一部件；●固定有效負載中的每一字體對象必須滿足“字體部件”一節(jié)中定義的字體格式規(guī)則；●從固定有效負載的任一固定頁對圖像的引用必須指向(可能通過其它選擇器遞歸地)作出選擇來找出要呈現(xiàn)的實際圖像的選擇器；●固定有效負載中使用的每一圖像對象必須滿足“圖像部件”一節(jié)中定義的字體格式規(guī)則；●對于從固定頁(直接或通過選擇器間接)引用的任一字體、圖像或選擇器部件，必須有從引用固定頁到被引用的部件的“需要的部件”關系(關系名=http://mmcf-fixed-RequiredResource-PLACEHOLDER)。
到達排版部件盡管到達包可包含許多類型的排版部件，然而僅明確定義的排版部件的類型集具有依照該文檔明確定義的行為。這些具有明確定義的行為的排版部件被稱為到達排版部件。不同于這些的部件在確定到達包的有效性時不是相關的。
以下排版部件類型被定義為到達排版部件


到達選擇器被定義為到達排版部件的那些選擇器排版部件被稱為到達選擇器。如上所述，語言選擇器基于其自然語言，如英語或法語在表示之間選擇。為發(fā)現(xiàn)該語言，選擇器調(diào)查其每一項。僅作為XML的那些項被考慮在內(nèi)。對于那些項，調(diào)查每一項的根元素以確定其語言。如果xml:lang屬性不存在，則忽略該部件。選擇器然后依次考慮這些部件的每一個，選擇其語言與系統(tǒng)的默認語言相匹配的第一個部件。
顏色選擇器基于它們是單色還是彩色在表示之間選擇。頁面大小選擇器基于其頁面大小在表示之間選擇。內(nèi)容類型選擇器基于其內(nèi)容類型是否能被系統(tǒng)理解在表示之間選擇。
到達序列被定義為到達排版部件的那些序列排版部件被稱為到達序列。固定的序列將固定內(nèi)容的子部件組合成序列。
固定有效負載部件固定有效負載能包括以下種類的部件固定面板部件、固定頁面部件、圖像部件、字體部件、打印票據(jù)部件以及描述性元數(shù)據(jù)部件，其每一個在下文其自己的小標題下討論。
固定面板部件固定有效負載的文檔結構將固定頁面標識為骨架的一部分，如下文所描述的。骨架部件和頁面部件之間的關系在骨架的關系流內(nèi)定義。固定面板部件是內(nèi)容類型application/xml+PLACEHOLDER。
固定有效負載內(nèi)容的骨架通過在<Document>元素內(nèi)包括<FixedPanel>元素在標記中指定。在下文的示例中，<FixedPanel>元素指定了骨架中容納的頁的來源。
<!--SPINE-->
<Document $XMLNSFIXED$>
<FixedPanel>
<PageContent Source="p1.xml"/>
<PageContent Source="p2.xml"/>
</FixedPanel>
</Document>
<Document>元素<Document>元素沒有屬性，并且必須只有一個子元素<FixedPanel>。
<FixedPanel>元素<FixedPanel>元素是文檔的骨架，它邏輯上將已排序的頁面序列綁定在一起成單個多頁文檔。頁面總是指定了其自己的寬度和高度，但是<FixedPanel>元素也可任選地指定高度和寬度。該信息可用于各種各樣的目的，包括，例如基于頁面大小在替換表示之間選擇。如果<FixedPanel>元素指定了高度和寬度，則它通?？膳c<FixedPane>內(nèi)的頁面的寬度和高度對齊，但是這些尺寸不指定個別頁的高度和寬度。
以下表格依照所描述的實施例總結了FixedPanel屬性。

<PageContent>元素是<FixedPanel>元素唯一允許的子元素。<PageContent>元素是與文檔的頁順序相匹配的順序標記次序。
<PageContent>元素每一<PageContent>元素指的是單個頁面的內(nèi)容的來源。為確定文檔中頁的數(shù)量，可對包含在<FixedPanel>中的<PageContent>子元素進行計數(shù)。
<PageContent>元素沒有允許的子元素，并且有單個需要的屬性-Source，它指的是頁的內(nèi)容的固定頁面部件。
如<FixedPanel>元素一樣，<PageContent>元素可任選地包括PageHeight和PageWidth屬性，此處反映了單個頁的大小。需要的頁面大小在固定頁面部件內(nèi)指定；<PageContent>上的可任選大小僅是建議性的。<PageContent>大小屬性允許諸如文檔察看器等應用程序?qū)τ谖臋n快速地做出可視布局估算，而不加載和語法分析所有的個別固定頁面部件。
下文提供的表格總結了<PageContent>屬性并提供了屬性的描述。

頁內(nèi)容的URI串必須引用內(nèi)容相對于包的部件位置。
固定頁面部件<FixedPanel>中的每一<PageContent>元素按名字(URI)引用了固定頁面部件。每一固定頁面部件包含描述內(nèi)容的單個頁面的呈現(xiàn)的固定頁面標記。固定頁面部件是內(nèi)容類型application/xml+PLACEHOLDER-FixedPage。
在標記中描述固定頁面以下是源內(nèi)容的標記如何查找上述實例骨架標記(<PageContentSource="p1.xml″/>)中引用的頁面的示例。// /content/p1.xml<FixedPage PageHeight="1056"PageWidth="816">
<GlyphsOriginX="96"OriginY="96"UnicodeString="This is Page 1!"FontUri="../Fonts/Times.TTF"FontRenderingEmSize="16"/></FixedPage>
以下表格總結了FixedPage的屬性并提供了屬性的描述。

固定頁面標記中的讀取順序在一個實施例中，包含在固定頁面內(nèi)的Glyphs子元素的標記順序必須與頁面的文本內(nèi)容的期望讀取順序相同。該讀取順序可用于來自察看器中的固定頁面的順序文本的交互式選擇/賦值，以及允許可訪問性技術對順序文本的訪問。確保標記順序和讀取順序的之間的這一對應性是生成固定頁面標記的應用程序的責任。
圖像部件支持的格式依照所描述的實施例，到達包中的固定頁面使用的圖像部件可以是固定數(shù)量的格式，例如PNG或JPEG，盡管可使用其它格式。
字體部件依照所描述的實施例，到達包支持有限數(shù)量的字體格式。在所示并描述的實施例中，支持的字體格式包括TrueType格式和OpenType格式。
如本領域的技術人員所理解的，OpenType字體格式是TrueType字體格式的擴展，添加了對PostScript字體數(shù)據(jù)和復雜的排字布局的支持。OpenType字體文件包含表格格式的數(shù)據(jù)，它包括TrueType輪廓字體或PostScript輪廓字體。
依照所描述的實施例，到達包內(nèi)不支持以下字體格式Adobe類型1、位圖字體、具有隱藏屬性的字體(使用系統(tǒng)標志來判斷是否枚舉它)、矢量字體以及EUDC字體(其字體家族名是EUDC)。
分設置字體固定有效負載標識使用下文詳細描述的Glyphs元素的所有文本。由于在本實施例中格式是固定的，因此可能對字體進行分設置以僅包含固定有效負載所需的字形。因此，到達包內(nèi)的字體可以基于字形使用率來分設置。盡管分設置的字體將不包含原始字體中的所有字形，然而分設置的字體必須是有效的OpenType字體文件。
打印票據(jù)部件打印票據(jù)部件提供了可在打印包時使用的設置。這些打印票據(jù)可以用各種方式附加，以實現(xiàn)實質(zhì)上的靈活性。例如，打印票據(jù)可被“附加”到整個包，并且其設置將影響整個包。打印票據(jù)可以在結構中的較低級進一步附加(例如，附加到個別的頁)，并且這些打印票據(jù)將提供在打印它們所附加的部件時使用的覆蓋設置。
描述性元數(shù)據(jù)如上所述，描述性元數(shù)據(jù)部件向包的書寫者或生產(chǎn)者提供了儲存屬性值的方法，使包的閱讀者能夠可靠地發(fā)現(xiàn)這些值。這些屬性通常用于記錄關于整個包以及容器內(nèi)個別部件的附加信息。
固定頁面標記基礎本節(jié)描述了與固定頁面標記相關聯(lián)的某些基礎信息，并包括以下小節(jié)“固定有效負載和其它標記標準”、“固定頁面標記模型”、“資源和資源引用”、以及“固定頁面繪制模型”。
固定有效負載和其它標記標準到達包內(nèi)的固定有效負載的固定面板和固定頁面標記是來自WindowsLonghorn的Avalon XAML標記的子集。即，盡管固定有效負載標記作為獨立的XML標記格式(如在本文檔中編制的)是獨立的，但是它以與Longhorn系統(tǒng)相同的方式加載，并呈現(xiàn)了原始多頁文檔的WYSIWYG再現(xiàn)。
作為XAML標記的某些背景，考慮以下。XAML標記是允許用戶將對象的層次以及對象后的編程邏輯指定為基于XML的標記語言的機制。這為對象模型提供了以XML描述的能力。這允許諸如微軟公司的.NET框架的公用語言運行庫(CLR)等類中的可擴充類以XML來訪問。XAML機制提供了XML標簽到CLR對象的直接映射，以及以標記表示相關代碼的能力?？梢悦靼撞⒗斫?，各個實現(xiàn)不需要特別地使用XAML的基于CLR的實現(xiàn)。相反，基于CLR的實現(xiàn)僅構成了可在本文檔中描述的實施例環(huán)境中采用XAML的一種方法。
更具體地，考慮結合圖11的以下內(nèi)容，它示出了CLR概念(左側(cè)分量)到XML(右側(cè)分量)的示例性映射。名字空間使用稱為反射的CLR概念在xmlns聲明中找到。類直接映射到XML標簽。屬性和事件直接映射到屬性。使用這一分層結構，用戶可指定XML標記文件中的任一CLR對象的分層樹。xaml文件是具有xaml擴展名以及application/xaml+xml的媒體類型的xml文件。xaml文件具有一個根標簽，它通常使用xmlns屬性指定了名字空間。名字空間可以在標簽的其它類型中指定。
繼續(xù)，xaml文件中的標簽一般映射到CLR對象。標簽可以是元素、復合屬性、定義或資源。元素是一般在運行時例示的CLR對象，并形成了對象的分層結構。復合屬性標簽用于設置父標簽中的屬性。定義標簽用于將代碼添加到頁并定義資源。資源標簽提供了僅通過將樹指定為資源來重新使用對象樹的能力。定義標簽也可在另一標簽中被指定為xmlns屬性。
一旦以標記(通常由書寫者)合適地描述了文檔，可以(通常由閱讀者)對標記進行語法分析和處理。合適配置的語法分析器從根標簽中確定應當搜索哪些CLR匯編和名字空間來找出標簽。在許多情況下，語法分析器進行查找，并找出由xmlns屬性指定的URL中的名字空間定義文件。名字空間定義文件提供了匯編的名字及其安裝路徑和CLR名字空間的列表。當語法分析器遇到標簽時，語法分析器使用標簽的xmlns以及該xmlns的xmlns定義文件來確定標簽引用哪些CLR類。語法分析器按定義文件中指定的匯編和名字空間的順序進行搜索。當它找到匹配時，語法分析器例示該類的對象。
由此，上文描述，并且在上文通過引用更完全結合在本申請中的機制允許使用標記標簽以基于XML文件來表示對象模型。這一將對象模型表示為標記標簽的能力可以用于異步或同步地創(chuàng)建矢量圖形繪圖、固定格式的文檔、自適應流文檔和應用程序UI。
在所示并描述的實施例中，固定有效負載標記是最小的，幾乎完全是呈現(xiàn)原語的Avalon XAML的節(jié)儉的子集。它用完全的保真度可視地表示了可以用Avalon表示的任何內(nèi)容。固定有效負載標記是Avalon XAML元素和屬性的子集—加上附加的約定、正則形式或與Avalon XAML相比在使用率上的限制。
定義的完全最小固定有效負載標記集減少了與到達包閱讀者，如打印機RIP或交互式察看器應用程序的實現(xiàn)和測試相關聯(lián)的成本—并減少了相關聯(lián)的語法分析器的復雜度和存儲器覆蓋區(qū)。節(jié)儉的標記集也最小化了分設置、錯誤或到達包書寫者和閱讀者之間的不一致性的機會，從而令格式及其生態(tài)系統(tǒng)內(nèi)在地更健壯。
除最小的固定有效負載標記之外，到達包將為附加的語義信息指定標記，以支持具有諸如超鏈接、版面/大綱結構和導航、文本選擇和文檔可訪問性等特征的察看器到達包或呈現(xiàn)。
最后，使用上述版本化和可擴充性機制，用用于特定的目標消耗應用程序、察看器或設備的更豐富的元素集來補充最小的固定有效負載標記是可能的。
固定頁面標記模型在所示并描述的實施例中，固定頁面部件是基于XML元素、XML元屬性和XML名字空間以基于XML的標記語言來表達的。本文檔中定義了三個XML名字空間以包括在固定頁面標記中。一個這樣的名字空間參考了本說明書中其它地方定義的版本控制元素和屬性。用于固定頁面標記中的元素和屬性的原則名字空間是“http://schemas.microsoft.com/MMCF-PLACEHOLDER-FixedPage”。最后，固定頁面標記引入了“資源”的概念，它需要下文描述的第三個名字空間。
盡管固定頁面標記是使用XML元素和XML元屬性來表達的，然而其規(guī)范基于“內(nèi)容”和“屬性”的更高級抽象模型。固定頁面元素都被表達為XML元素。僅少數(shù)固定頁面元素可容納“內(nèi)容”，表達為XML子元素。但是屬性值可使用XML元屬性或使用XML子元素來表達。
固定頁面標記也依賴于資源字典和資源引用的雙概念。資源字典和多個資源引用的組合允許單個屬性值由多個固定頁面標記元素的多個屬性共享。
固定頁面標記中的屬性在所示并描述的實施例中，有三種形式的標記，它們可用于指定固定頁面標記屬性的值。
如果屬性是使用資源引用來指定的，則屬性名用作XML元屬性名，并且屬性值的特殊句法指示了資源引用的存在。用于表達資源引用的句法在名為“資源和資源引用”一節(jié)中描述。
未被指定為資源引用的任何屬性值可以使用標識其值被設置的屬性的嵌套XML子元素以XML來表達。該“復合屬性句法”在下文描述。
最后，某些非資源引用屬性值可被表達為簡單文本串。盡管所有這樣的屬性值可以使用復合屬性句法來表達，然而它們也可使用簡單的XML元屬性句法來表達。
對于任一給定的元素，任一屬性可以被設置不多于一次，無論用于指定該值的句法是什么。
簡單屬性句法對于可被表達為簡單串的屬性值，可使用XML元屬性句法來指定屬性值。例如，給定稱為“SolidColorBrush(純色刷)”的固定頁面標記元素，它具有名為“Color(顏色)”的屬性，可使用以下句法來指定屬性值
<!--Simple Attribute Syntax--><SolidColorBrush Color="#FF0000"/>
復合屬性句法某些屬性值不能被表達為簡單的串，例如XML元素用于描述屬性值。這一屬性值不能使用簡單屬性句法來表達。但是它們可使用復合屬性句法來表達。
在復合屬性句法中，使用了XML子元素，但是從父元素名和屬性名的組合導出XML元素名，以點分隔。給定固定頁面標記元素<Path>(路徑)，它具有屬性“Fill”，它可被設置到<SolidColorBrush>，可使用以下標記來設置<Path>元素的“Fill”屬性<!--Compound-Property Syntax--><path>
<Path.Fill>
<SolidColorBrush Color="#FF0000"/>
</Path.Fill>
...</Path>
復合屬性句法即使在簡單屬性句法足以表達屬性值的情況下也可使用。因此，前一節(jié)的示例<!--Simple Attribute Syntax--><SolidColorBrush Color="#FF0000"/>
可替代地以復合屬性句法來表達<!--Compound-Property Syntax--><SolidColorBrush>
<SolidColorBrush.Color>#FF0000</SolidColorBrush.Color></SolidColorBrush>
當使用復合屬性句法來指定屬性值時，表示“屬性”的XML子元素必須出現(xiàn)在表示“內(nèi)容”的XML子元素之前。個別復合屬性XML子元素的順序不是重要的，只需它們一起出現(xiàn)在父元素的任何“內(nèi)容”之前。
例如，當使用<Canvas>(畫布)元素(下文描述)的Clip(裁剪)和RenderTransform(渲染變換)屬性時，這兩個屬性都必須出現(xiàn)在<Canvas>的任何<Path>和<Glyphs>內(nèi)容之前
<Canvas>
<!--First,the property-related child elements-->
<Canvas.RenderTransform>
<MatrixTransform Matrix="1,0,0,1,0,0">
</Canvas.RenderTransform>
<Canvas.Clip>
<PathGeometry>
...
</PathGeometry>
</Canvas.Clip>
<!--Then,the"Contents"-->
<Path...>
...
</Path>
<Glyphs...>
...
</Glyphs></Canvas>
資源和資源引用資源字典可用于容納可共享的屬性值，其每一個被稱為資源。其本身是固定頁面標記元素的任一屬性值可以容納在資源字典中。資源字典中的每一資源攜帶一名字。資源名可用于參考來自屬性的XML元屬性的資源。
在所示并描述的實施例中，<Canvas>和<FixedPage>元素可攜帶資源字典。資源字典是以標記表達為名為“Resource(資源)”的屬性內(nèi)的<Canvas>和<FixedPage>元素的屬性。然而，個別的資源值直接嵌入在<FixedPage.Resources>或<Canvas.Resources>XML元素內(nèi)。句法上，<Canvas.Resources>和<FixedPage.Resource>的標記類似于具有“內(nèi)容”的標記元素。
依照本實施例，<Canvas.Resources>或<FixedPage.Resources>必須在<Canvas>或<FixedPage>的任何復合屬性句法屬性值之前。類似地，它們必須在<Canvas>或<FixedPage>的任何“內(nèi)容”之前。
定義固定有效負載資源字典任何<FixedPage>或<Canvas>可攜帶資源字典，用<Canvas.Resource>XML元素來表達。單個資源字典內(nèi)的每一元素被給予一唯一的名字，通過使用與該元素相關聯(lián)的XML元屬性來標識。為將該“Name”元屬性與對應于屬性的那些元屬性進行區(qū)分，Name元屬性取自與固定格式元素的名字空間不同的名字空間。該XML名字空間的URI是“http://schemas.microsoft.com/PLACEHOLDER-for-resources”。在以下示例中，定義了兩種幾何結構一個是矩形，另一個是圓形。
<Canvas xmlns:def="http://schemas.microsoft.com/PLACEHOLDER-for-resources">
<Canvas.Resources>
<PathGeometry def:Name="Rectangle">
<PathFigure>
...
</PathFigure>
</PathGeometry>
<PathGeometry def:Name="Circle">
<PathFigure>
...
</PathFigure>
</pathGeometry>
</Canvas.Resources></Canvas>
引用資源為將屬性值設為上文定義的資源之一，使用在{}內(nèi)包含資源名的XML屬性值。例如，“{Rectangle}”將表示要使用該幾何結構。在以下標記樣例中，由字典中的幾何結構對象定義的矩形區(qū)域?qū)⒂肧olidColorBrush來填充。<Canvas>
<Canvas.Resources>
<PathGeometry def:Name="Rectangle">
...
</PathGeometry>
</Canvas.Resources>
<Path>
<Path.Data>
<PathGeometry PathGeometry="{Rectangle}"/>
</Path.Data>
<Path.Fill>
<SolidColorBrush Color="#FF0000"/>
</Path.Fill>
</Path></Canvas>
依照本實施例，資源引用必須不出現(xiàn)在資源字典的資源定義內(nèi)。
用于解析資源引用的檢查規(guī)則盡管在同一資源字典內(nèi)可能無法使用單個名字兩次，然而同一名字可以用在單個固定頁面部件的兩個不同的資源字典內(nèi)。此外，內(nèi)部<Canvas>的資源字典可重復使用某些外部<Canvas>或<FixedPage>的資源字典內(nèi)定義的名字。
當使用資源引用來設置元素的屬性時，搜索各個資源字典來找出給定名字的資源。如果具有屬性的元素是<Canvas>，則搜索該<Canvas>的資源字典(如果有的話)以找出期望名字的資源。如果元素不是<Canvas>，則搜索以最接近的包含<Canvas>或<FixedPage>開始。如果在最初搜索的資源字典內(nèi)未定義期望的名字，則咨詢下一最接近的包含<Canvas>或<FixedPage>。如果搜索繼續(xù)到根<FixedPage>元素，并且在與該<FixedPage>相關聯(lián)的資源字典內(nèi)未找到期望名字的資源，則出現(xiàn)錯誤。
以下示例表示了這些規(guī)則。<FixedPage xmlns:def="http://schemas.microsoft.com/PLACEHOLDER-for-resources"PageHeight="1056"PageWidth="816">
<FixedPage.Resources>
<Fill def:Name="FavoriteColorFill">
<SolidColorBrush Color="#808080"/>
</Fill>
</FixedPage.Resources>
<Canvas>
<Canvas.Resources>
<Fill def:Name="FavoriteColorFill">
<SolidColorBrush Color="#000000"/>
</Fill>
</Canvas.Resources>
<!--The following Path will be filed with color #000000-->
<Path Fill="{FavoriteColorFill}">
<Path.Data>
...
</Path.Data>
</Path>
<Canvas>
<!--The following Path will be filed with color #000000-->
<Path Fill="{FavoriteColorFill}">
<Path.Data>
...
</Path.Data>
</Path>
</Canvas>
</Canvas>
<--The following path will be filled with color #808080-->
<Path Fill="{FavoriteColorFill}">
<Path.Data>
...
</Path.Data>
</Path></FixedPage>
固定頁面繪制模型固定頁面元素(或嵌套的畫布子元素)是在其上呈現(xiàn)其它元素的元素。內(nèi)容的排列由對固定頁面(或畫布)指定的屬性、對固定頁面(或畫布)上的元素指定的屬性、以及對固定頁面名字空間定義的組成規(guī)則來控制。
使用畫布來定位元素在固定標記中，所有的元素都相對于坐標系統(tǒng)的當前原點(0，0)來定位。當前原點可通過向包含元素的固定頁面或畫布的每一元素應用RenderTransform元屬性來移動。
以下示例示出了通過RenderTransform對元素的定位。<Canvas>
<Canvas.Resources>
<PathGeometry def:Name="StarFish">
<!--Various PathFigures in here-->
...
</PathGeometry>
<PathGeometry def:Name="LogoShape">
<!--Various PathFigures in here-->
...
</PathGeometry>
</Canvas.Resources>
<!--Draw a green StarFish and a red LogoShape shifted by 100 to the right and 50 down-->
<Canvas>
<Canvas.RenderTransform>
<MatrixTransform Matrix="1,0,0,1,100,50"/>
</Canvas.RenderTransform>
<Path Fill="#00FF00"Data="{StarFish}"/>
<Path Fill="#FF0000"Data="{LogoShape}"/>
</Canvas>
<!--Draw a green StarFish and a red LogoShape shifted by 200 to the right and 250 down-->
<Canvas>
<Canvas.RenderTransform>
<MatrixTransform Matrix="1,0,0,1,200,250"/>
</Canvas.RenderTransform>
<Path Fill="#00FF00"Data="{StarFish}"/>
<Path Fill="#FF0000"Data="{LogoShape}"/>
</Canvas></Canvas>
坐標系統(tǒng)和單位依照所示并描述的實施例，最初設置坐標系統(tǒng)，使得該坐標系統(tǒng)中的一個單位等于英寸的1/96，被表達為浮點值，坐標系統(tǒng)的原點(0，0)是固定頁面元素的左上角。
RenderTransform元屬性可以在任一子元素上指定，以向當前坐標系統(tǒng)應用仿射變換。
頁面尺寸頁面尺寸由固定頁面元素上的“PageWidth(頁寬度)”和“PageHeight(頁高度)”參數(shù)來指定。
組成規(guī)則固定頁面使用了具有α通道的繪圖程序模型。依照所描述的實施例，組成必須依照這些規(guī)則，并且以以下順序發(fā)生●固定頁面(或任何嵌套的畫布)被認為是無界的表面，向該表面上按它們出現(xiàn)在標記中的次序繪制子元素。該表面的α通道被初始化為“0.0”(全部透明)。實際上，理想的無界表面可以被認為是一種位圖緩沖區(qū)，它足夠大以容納通過呈現(xiàn)所有的子元素產(chǎn)生的所有標記。
●表面的內(nèi)容使用由固定頁面(或畫布)的渲染變換屬性指定的仿射變換來變換。
●所有的子元素被呈現(xiàn)到表面上、由固定頁面(或畫布)的裁剪屬性來裁剪(也使用渲染變換屬性來變換)。固定頁面另外裁剪到由(0，0，PageWitch，PageHeight)指定的矩形。如果子元素具有不透明(Opacity)屬性或不透明掩模(OpacityMask)屬性，則它在呈現(xiàn)到表面上之前被應用到該子元素。
●最后，固定頁面(或畫布)的內(nèi)容被呈現(xiàn)到其包含元素上。在固定頁面的情況下，包含元素是物理映像表面。
呈現(xiàn)依照這些規(guī)則發(fā)生●在表面上產(chǎn)生標記的唯一元素是“字形(Glyphs)”和“路徑(Path)”。
●所有其它的呈現(xiàn)效果可通過將“字形”和“路徑”元素定位到“畫布”上，并應用其各種有效元屬性來實現(xiàn)。
固定有效負載元素和屬性依照所示并描述的實施例，固定有效負載包括在標記中用于表示頁面及其內(nèi)容的一小組XML元素。固定面板部件中的標記使用<Document>、<FixedPanel>和<PageContent>元素將文檔的頁面一起帶到一公用的、容易索引的根。每一固定頁面部件表示僅具有<Path>和<Glyphs>元素(它們共同完成所有的繪制)的<FixedPage>元素，以及組合它們的<Canvas>元素中的頁面內(nèi)容。
固定有效負載標記的元素分層結構在以下名為“頂級元素”、“用于路徑、裁剪的幾何結構”、“用于填充路徑、字形或不透明掩模的刷子”、“用于固定頁面或畫布的資源字典”、“用于α透明性的不透明掩?！薄ⅰ安眉袈窂健焙汀白儞Q”的章節(jié)中總結。
頂級元素●<Document>[對每一固定面板部件只有一個]○元屬性■[無]○子元素■<FixedPanel>[只有一個]●<FixedPanel>
○元屬性■PageHeight[可任選]■PageWidth[可任選]○子元素■<PageContent>[這些子元素的1-N個]●<PageContent>
○元屬性■Source[需要]■PageHeight[可任選]■PageWidth[可任選]○子元素■[無]●<Fixedpage>
○通過簡單XML元屬性直接表達的屬性■PageHeight[需要(此處或作為子元素)]■PageWidth[需要(此處或作為子元素)]○表達為XML子元素的資源字典本身■<FixedPage.Resouces>
○通過XML子元素表達的屬性■<FixedPage.PageHeight>[需要(此處或作為元屬性)]■<FixedPage.PageWidth>[需要(此處或作為元屬性)]○通過XML子元素表達的內(nèi)容
■<Canvas>
■<Path>
■<Glyphs>
●<Canvas>
○通過簡單XML元屬性直接表達的屬性■Opacity○通過資源字典引用表達的屬性■Clip■RenderTransform■OpacityMask○表達為XML子元素的資源字典本身■<Canvas.Resources>
○通過XML子元素表達的屬性■<Canvas.Opacity>
■<Canvas.Clip>
■<Canvas.RenderTransform>
■<Canvas.OpacityMask>
○通過XML子元素表達的內(nèi)容■<Canvas>
■<Path>
■<Glyphs>
●<Path>
○通過簡單XML元屬性直接表達的屬性■Opacity○通過資源字典引用表達的屬性■Clip■RenderTransfrom■OpacityMask■Fill○通過XML子元素表達的屬性■<Path.Opacity>
■<Path.Clip>
■<Path.RenderTransform>
■<Path.OpacityMask>
■<Path.Fill>
■<Path.Data>
●<GlyPhs>
○通過簡單XML元屬性直接表達的屬性■Opacity■BidiLevel■FontFaceIndex■FontHintingEmSize■FontRenderingEmSize■FontUri■Indices■OriginX■OriginY■Sideways■StyleSimulations■UnicodeString○通過資源字典引用表達的屬性■Clip■RenderTransform■OpacityMask■Fill○通過XML子元素表達的屬性■<Glyphs.Clip>
■<Glyphs.RenderTransfrom>
■<Glyphs.OpacityMask>
■<Glyphs.Fill>
■<Glyphs.Opacity>
■<Glyphs.BidiLevel>
■<Glyphs.FontFaceIndex>
■<Glyphs.FontHintingEmSize>
■<Glyphs.FontRenderingEmSize>
■<Glyphs.FontUri>
■<Glyphs.Indices>
■<Glyphs.OriginX>
■<Glyphs.OriginY>
■<Glyphs.Sideways>
■<Glyphs.StyleSimulations>
■<Glyphs.UnicodeString>
用于路徑、裁剪的幾何結構●<Path.Data>
○元屬性■[無]○表達為單個XML子元素的屬性值[Path.Data總共只有這些子元素的一個]■<GeometryCollection>
■<PathGeometry>
●<GeometryCollection>
○元屬性■CombineMode○子元素[1-N個子元素]■<GeometryCollection>
■<PathGeometry>
●<PathGeometry>
○元屬性■FillRule○子元素[1-N個子元素]
■<PathFigure>
●<PathFigure>
○元屬性■[無]○子元素[首先出現(xiàn)StartSegment，最后出現(xiàn)CloseSegment，中間有1-N個Ploy*]■<StartSegment>
■<PolyLineSegment>
■<PolyBezierSegment>
■<CloseSegment>
●<StartSegment>
○通過簡單XML元屬性直接表達的屬性■Point○通過XML子元素表達的屬性■<StartSement.Point>
●<PolyLineSegment>
○通過簡單XML元屬性直接表達的屬性■Points○通過XML子元素表達的屬性■<PolyLineSegment.Points>
●<PolyBezierSegment>
○通過簡單XML元屬性直接表達的屬性■Points○通過XML子元素表達的屬性■<PolyBezierSegment.Points>
用于填充路徑、字形或不透明掩模的刷子●<Path.Fill>
○元屬性■[無]○表達為簡單XML子元素的屬性值 ■<SolidColorBrush>
■<ImageBrush>
■<DrawingBrush>
■<LinearGradientBrush>
■<RadialGradientBrush>
●<Glyphs.Fill>
○元屬性■[無]○表達為單個XML子元素的屬性值[Glyphs.Fill只有這些子元素的一個]■<SolidColorBrush>
■<ImageBrush>
■<DrawingBrush>
■<LinearGradientBrush>
■<RadialGradientBrush>
●<SolidColorBrush>
○通過簡單XML元屬性直接表達的屬性■Opacity■Color○通過XML子元素表達的屬性■<SolidColorBrush.Opacity>
■<SolidColorBrush.Color>
●<ImageBrush>
○通過簡單XML元屬性直接表達的屬性■Opacity■HorizontalAlignment■VerticalAlignment■Viewbox■ViewPort■Stretch
■TileMode■ContentUnits■ViewportUnits■ImageSource○通過資源字典引用表達的屬性■Transform○通過XML子元素表達的屬性■<ImageBrush.Opacity>
■<ImageBrush.Transform>
■<ImageBrush.HorizontalAlignment>
■<ImageBrush.VerticalAlignment>
■<ImageBrush.ViewBox>
■<ImageBrush.ViewPort>
■<ImageBrush.Stretch>
■<ImageBrrush.TileMode>
■<ImageBrush.ContentUnits>
■<ImageBrush.ViewportUnits>
■<ImageBrush.ImageSource>
●<DrawingBrush>
○通過簡單XML元屬性直接表達的屬性■Opacity■HorizontalAlignment■VerticalAlignment■ViewBox■ViewPort■Stretch■TileMode■ContentUnits■VeiwportUnits○通過資源字典引用表達的屬性■Transform
■Drawing○通過XML子元素表達的屬性■<DrawingBrush.Opacity>
■<DrawingBrush.Transform>
■<DrawingBrush.HorizontalAlignment>
■<DrawingBrush.Verticalalignment>
■<DrawingBrush.ViewBox>
■<DrawingBrush.ViewPort>
■<DrawingBrush.Stretch>
■<DrawingBrush.TileMode>
■<DrawingBrush.ContentUnits>
■<DrawingBrush.ViewportUnits>
■<DrawingBrush.Drawing>
●<DrawingBrush.Drawing>
○通過XML子元素表達的內(nèi)容■<Canvas>
■<Path>
■<Glyphs>
●<LinearGradientBrush>
○通過簡單XML元屬性直接表達的屬性■Opacity■MappingMode■SpreadMethod■StartPoint■EndPoint○通過資源字典引用表達的屬性■Transform■GradientStops○通過XML子元素表達的屬性■<LinearGradientBrush.Opacity>
■<LinearGradientBrush.Transform>
■<LinearGradientBrush.MappingMode>
■<LinearGradient.Brush.SpreadMethod>
■<LinearGradientBrush.StartPoint>
■<LinearGradientBrush.EndPoint>
■<LinearGradientBrush.GradientStops>
●<RadialGradientBrush>
○通過簡單XML元屬性直接表達的屬性■Opacity■Center■Focus■RadiusX■RadiusY○通過資源字典引用表達的屬性■Transform■GradientStops○通過XML子元素表達的屬性■<RadialGradientBrush.Opacity>
■<RadialGradientBrush.Transform>
■<RadialGradientBrush.Center>
■<RadialGradientBrush.Focus>
■<RadialGradientBrush.RadiusX>
■<RadialGradientBrush.RadiusY>
■<RadialGradientBrush.GradientStops>
●<GradientStops>
○通過XML子元素表達的內(nèi)容■<GradientStop>[這些子元素的1-N個]●<GradientStop>
○通過簡單XML元屬性直接表達的屬性■Color■Offset○通過XML子元素表達的屬性
■<GradientStop.Color>
■<GradientStop.Offset>
用于固定頁面或畫布的資源字典●<FixedPage.Resources>
●<Canvas.Resources>
這些元素在上文討論資源字典的一節(jié)中已作了討論。
用于α透明性的不透明性掩?！?amp;lt;Canvas.OpacityMask>
○元屬性■[無]○表達為單個XML子元素的屬性值[Canvas.OpacityMask只有這些子元素的一個]■<SolidColorBrush>
■<ImageBrush>
■<DrawingBrush>
■<LinearGradientBrush>
■<RadialGradientBrush>
●<Path.OpacityMask>
○元屬性■[無]○表達為單個XML子元素的屬性值[Path.OpacityMask只有這些子元素的一個]■<SolidColorBrush>
■<ImageBrush>
■<DrawingBrush>
■<LinearGradientBrush>
■<RadialGradientBrush>
●<Glyphs.OpacityMask>
○元屬性
■[無]○表達為單個XML子元素的屬性值[Glyphs.OpacityMask只有這些子元素的一個]■<SolidColorBrush>
■<ImageBrush>
■<DrawingBrush>
■<LinearGradientBrush>
■<RadialGradientBrush>
裁剪路徑●<Canvas.Clip>
○元屬性■[無]○表達為單個XML子元素的屬性值[Canvas.Clip只有這些子元素的一個]■<GeometryCollection>
■<PathGeometry>
●<Path.Clip>
○元屬性■[無]○表達為單個XML子元素的屬性值[Path.Clip只有這些子元素的一個]■<GeometryCollection>
■<PathGeometry>
●<Glyphs.Clip>
○元屬性■[無]○表達為單個XML子元素的屬性值[Glyphs.Clip只有這些子元素的一個]■<GeometryCollection>
■<PathGeometry>
變換●<Canvas.RenderTransform>
○表達為單個XML子元素的屬性值■<MatrixTransform>[需要]●<Path.RenderTransfrom>
○表達為單個XML子元素的屬性值■<MatrixTransform[需要]●<Glyphs.RenderTransform>
○表達為單個XML子元素的屬性值■<MatrixTransform>[需要]●<MatrixTransform>
○通過簡單XML元屬性直接表達的屬性■Matrix○通過XML子元素表達的屬性■<MatrixTransform.Matrix>
●<ImageBrush.Transform>
○通過簡單XML元屬性直接表達的屬性■MatrixTransform○通過XML子元素表達的屬性■<ImageBrush.Transform.MatrixTransform>
●<DrawingBrush.Transform>
○通過簡單XML元屬性直接表達的屬性■MatrixTransform○通過XML子元素表達的屬性■<DrawingBrush.Transform.MatrixTransform>
●<LinearGradientBrush.Transform>
○通過簡單XML元屬性直接表達的屬性■MatrixTransform○通過XML子元素表達的屬性■<LinearGradientBrush.Transform.MatrixTransform>
●<RadialGradientBrush.Transform>
○通過簡單XML元屬性直接表達的屬性■MatrixTransform○通過XML子元素表達的屬性■<RadialGradientBrush.Transform.MatrixTransform>
固定頁面標記每一固定頁面部件表示<FixedPage>元素中作為根的XML標記中的頁面內(nèi)容。該固定頁面標記提供了書寫者和閱讀者之間的文檔的WYSIWYG保真度，只有一小組元素和屬性<Path>和<Glyphs>元素(共同完成了所有的繪制)，以及組合它們的<Canvas>元素。
公用元素屬性在討論對固定頁面標記中的每一元素專用的屬性之前，考慮對繪制和組合元素公用的屬性Opacity、Clip、RenderTransform和OpacityMask。這些不僅是對頂級元素公用的屬性，它們也是從父元素到子元素“聚積”其結果的唯一屬性，如上文“組成規(guī)則”一節(jié)中所描述的。聚積是應用組成規(guī)則的結果。以下表格提供了這些通用屬性的概括描述，以及對每一屬性的更完整討論。



Opacity屬性Opacity(不透明性)屬性用于在渲染時(α渲染)透明地混合兩個元素。Opacity屬性的范圍從0(完全透明)到1(完全不透明)。該閉區(qū)間外的值在標記語法分析過程中被限制到該范圍內(nèi)。因此，有效地，[-∞...0]是透明的，而[1...∞]是不透明的。
Opacity屬性通過以下計算來應用(假定非自左乘源和目標顏色，兩者都被指定為scRGB)OE元素的Opacity屬性或OpacityMask中對應位置處的α值AS源表面中存在的α值RS源表面中存在的紅值GS源表面中存在的綠值BS源表面中存在的藍值AD目標表面中已經(jīng)存在的α值RD目標表面中已經(jīng)存在的紅值GD目標表面中已經(jīng)存在的綠值BD目標表面中已經(jīng)存在的藍值A*對目標表面所得的α值R*對目標表面所得的紅值G*對目標表面所得的綠值B*對目標表面所得的藍值用T下標指定的所有值是臨時值(例如，RT1)。
步驟1將源α值與不透明性值相乘AS＝AS*OE步驟2自左乘源αAT1＝ASRT1＝RS*AS
GT1＝GS*ASBT1＝BS*AS步驟3a自左乘目標αAT2＝ADRT2＝RD*ADGT2＝GD*ADBT2＝BD*AD步驟3b混合AT2＝(1-AT1)*AT2+AT1RT2＝(1-AT1)*RT2+RT1GT2＝(1-AT1)*GT2+GT1BT2＝(1-AT1)*BT2+BT1步驟4反轉(zhuǎn)自左乘如果AT2＝0，則將所有的A*、R*、G*、B*設為0否則A*＝AT2R*＝RT2/AT2G*＝GT2/AT2B＝BT2/AT2Clip屬性Clip屬性被指定為幾何結構元素<GeometryCollection>或<PathGeomerty>之一(見Path.Data以知道細節(jié))Clip屬性用以下方式來應用●所有落入由Clip子元素描述的幾何結構元素內(nèi)的呈現(xiàn)內(nèi)容是可見的。
●所有落入由Clip子元素描述的幾何結構元素外的呈現(xiàn)內(nèi)容是不可見的。
RenderTransform子元素MatrixTransform是對元素可用的唯一變換屬性。它表達了仿射變換。句法如下
<X.RenderTransform>
<MatrixTransform Matrix="1,0,0,1,0,0"/>
</X.RenderTransform>
X表示向其應用變換的元素。
Matrix屬性中指定的六個數(shù)字是m00、m01、m10、m11、dx、dy。
完整的矩陣看似為m00m010m10m110dx dy 1給定坐標X、Y通過應用以下計算用RenderTransfrom變換來產(chǎn)生所得的坐標X′、Y′X′＝X*m00+Y*m10+dxY′＝X*m01+Y*m11+dyOpacityMask子元素OpacityMask指定了刷子(Brush)，但是與填充刷子(Fill Brush)相反，僅使用刷子的α通道(見上述Opacity屬性)作為用于呈現(xiàn)元素的附加參數(shù)。元素的每一像素的每一α值然后被額外地與OpacityMack刷子中的對應位置處的α值相乘。
<Canvas>元素<Canvas>元素用于將元素組合在一起。通常，當固定頁面元素共享組合的公用屬性(即，Opacity、Clip、RenderTransfrom或OpacityMask)時，它們在<Canvas>中被組合在一起。通過在畫布上將這些元素組合在一起，通?？蓪⒐脤傩詰玫疆嫴级莻€別的元素。
<Canvas>的屬性和子元素<Canvas>元素只有先前描述的公用屬性Opacity、Clip、RenderTransform和OpacityMask。它們?nèi)缦卤碇忻枋龅挠糜?amp;lt;Canvas>元素



以下標記示例示出了對<Canvas>的使用。<Canvas>
<Path Fill="#0000FF">
<Path.Data>
<PathGeometry>
<PathFigure>
<StartSegment Point="0,0"/>
<PolylineSegment Points="100,0 100,100 0,100 0,0"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Dara>
</Path></Canvas>
關于畫布標記中的讀取順序，考慮以下內(nèi)容。如固定頁面一樣，包含在Canvas內(nèi)的Glyphs子元素的標記順序必須與文本內(nèi)容的期望讀取順序相同。該讀取順序必須用于來自察看器中的固定頁面的順序文本的交互式選擇/復制，以及允許可訪問性技術對順序文本的訪問。確保標記順序和讀取順序之間的這一對應性是生成固定頁面標記的應用程序的責任。
包含在嵌套的Canvas元素內(nèi)的Glyphs子元素在出現(xiàn)在Canvas之前和之后的兄弟Glyphs元素之間內(nèi)嵌。
示例<FixedPage>
<Glyphs...UnicodeString="Now is the time for"/>
<Canvas>
<Glyphs...UnicodeString="all good men and women "/>
<Glyphs...UnicodeString="to come to the aid "/>
</Canvas>
<Glyphs...UnicodeString="of the party."/></FixedPage>
<Path>元素Path元素是描述幾何區(qū)域的基于XML的元素。幾何區(qū)域是可被填充，或者可用作裁剪路徑的形狀。諸如矩形和橢圓形等常見的幾何結構類型可以使用路徑幾何結構來表示。路徑通過指定需要的Geometry.Data子元素和諸如Fill或Opacity等渲染屬性來描述。
<Path>的屬性和子元素以下屬性適用于下文描述的<Path>元素



為描述如何對由<Path.Data>子元素的幾何結構描述的區(qū)域著色，使用了Fill屬性。為限制可在其上繪制<Path.Data>形狀的區(qū)域，使用了Clip屬性。
使用<Path>來描述幾何結構路徑的幾何結構被指定為<Path.Data>的一系列嵌套子元素，如下文所示。幾何結構可以用包含一組<PathGeometry>子元素的<GeometryCollection>或包含<PathFigures>的單個<PathGeometry>子元素來表示。<Path>
<Path.Data>
<GeometryCollection>
<PathGeometry>
<PathFigure>
</PathFigure>
</PathGeometry>
</GeometryCollection>
</Path.Data><Path>
相同的<GeometryCollection>或<PathGeometry>元素定義了用于裁剪Canvas、Path或Glyphs的Clip屬性中使用的路徑的幾何結構。
以下表格介紹了定義路徑幾何結構的子元素的分層結構。


GeometryCollectionGeometryCollection是一組被組合在一起來依照布爾CombineMode選項呈現(xiàn)的幾何結構對象。GeometryCollection元素是固定頁面標記中用于構建幾何形狀的可視組合的機制。

CombineMode屬性指定了用于組合GeometryCollection中的一組幾何形狀的布爾操作。根據(jù)模式，可包括或排除不同的區(qū)域。

CombineMode如下處理不可交換 Complement和Exclude不是可交換的，因此在GeometryCollection中的第一個幾何結構和每一個別的剩余幾何結構之間定義。例如，對于集合{g1，g2，g3}，Exclude的CombineMode將被應用為((g1排除g2))并且(g1排除g3))。
可交換 布爾操作Union、Xor、Intersect是可交換的，因此與順序無關地應用于幾何結構。
PathGeometryPathGeometry元素包含一組PathFigure元素。PathFigure的并集定義了PathGeometry的內(nèi)部。

關于FillRule屬性，考慮以下內(nèi)容。PathGeomerty的填充區(qū)域是通過采用將其Filled屬性設為真的所有包含的PathFigure，并應用FillRule來確定閉合區(qū)域來定義的。FillRule選項指定了如何將Geometry內(nèi)包含的Figure元素的相交區(qū)域組合在一起形成Geometry的所得區(qū)域。
依照所描述的實施例，提供了奇偶填充(EvenOdd Fill)和非零填充(NonZeroFill)算法。
奇偶填充算法通過繪制從畫布上的一點到任一方向上的無窮大的射線，然后檢查穿過該射線的形狀的片段之處，來確定該點的“內(nèi)部性”。從計數(shù)零開始，從左到右每次添加一個穿過該射線的片段，并且從右到左每次減去一個穿過該射線的路徑片段。如果這一數(shù)字是奇數(shù)，則該點在內(nèi)部；否則，該點在外部。
非零填充算法通過繪制從畫布上的一點到任一方向上的無窮大的射線，并對該射線穿過的給定形狀的路徑片段數(shù)進行計數(shù)，來確定該點的“內(nèi)部性”。在對穿過進行計數(shù)之后，如果結果是0，則該點在路徑外部。否則，該點在內(nèi)部。
PathFigurePathFigure元素包括一個或多個線段或曲線段的集合。線段元素定義了PathFieure的形狀。PathFigure必須總是定義閉合的形狀。

圖形需要起始點，之后每一線段或曲線段從添加的最后一個點繼續(xù)。PathFigure集合中的第一段必須是StartSegment，而CloseSegment必須是最后一段。StartSegment具有Point屬性。CloseSegment沒有屬性。

用于Path.Data幾何結構的固定有效負載標記以下提供了用于繪制并填充畫布上的路徑的標記。在以下具體示例中，在畫布上繪制矩形路徑，并用純綠色刷子來填充。
<Canvas>
<Path Fill="#0000FF">
<Path.Data>
<PathGeometry>
<PathFigure>
<StartSegment Point="0,0"/>
<PolylineSegment Points="100,0 100,100 0,100 0,0"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Data>
</Path></Canvas>
以下標記描述了繪制立方Bézier曲線。即，除PolyLineSegment(折線段)之外，固定有效負載標記包括用于繪制立方Bézier曲線的PolyuBezierSegment。<Canvas>
<Path Fill="#0000FF">
<Path.Data>
<PathGeometry>
<PathFigure>
<StartSegment Point="0,0"/>
<PolybezierSegment Points="100,0 100,100 0,100 0,0"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Data>
</Path></Canvas>
刷子刷子用于對由<Path>元素定義的幾何形狀的內(nèi)部進行著色，并填充用<Glyphs>元素呈現(xiàn)的字符位圖。刷子也用于定義<Canvas.OpacityMask>、<Path.OpacityMask>和<Glyphs.OpacityMask>中的α透明性掩模。固定頁面標記包括以下刷子

屬性在各刷子之間變化，盡管所有的刷子都具有Opacity屬性。ImageBrush和DrawingBrush共享平鋪顯示能力。兩個用梯度填充的刷子也具有公用的屬性。
對標記中刷子子元素的使用示出如下<Path>
<Path.Fill>
<SolidColorBrush Color="#00FFFF"/>
</Path.Fill>
...</Path>
刷子的公用屬性依照所描述的實施例，以下屬性適用于所有的刷子，除簡單刷子SolidColorBrush之外，它具有更少的可任選子元素。


用于DrawingBrush和ImageBrush的公用屬性

HorizontalAlignment(水平對齊)屬性指定了刷子如何在它所填充的區(qū)域內(nèi)水平對齊。VerticalAlignment(垂直對齊)屬性指定了刷子如何在它所填充的區(qū)域內(nèi)垂直對齊。ViewBox屬性具有默認值(0，0，0，0)，被解釋為未設置。當未設置時，不作出任何調(diào)整，并且忽略Stretch屬性。察看框(ViewBox)為內(nèi)容指定了新坐標系統(tǒng)，即，重新定義了察看口(ViewPort)的范圍和原點。Stretch(拉伸)屬性幫助指定那些內(nèi)容如何映射到察看口。Viewbox屬性的值是四個“無單位”數(shù)字<min-x>、<min-y>、<width>和<height>的列表，由空格和/或逗號分隔，并且是Rect類型。ViewBox rect指定了映射到邊框的用戶空間中的矩形。它與插入scaleX和scaleY一樣起作用。Stretch屬性(在選項不同于無的情況下)提供了用于保持圖形的長寬比的附加控制。附加變換被應用到給定元素的所有子孫元素，以達到指定的效果。如果在Brush上有變換，則它在ViewBox映射“之上”應用。
Stretch屬性具有以下模式None、Fill、Uniform、UniformToFil。

簡單刷子及其屬性Path.Brush和Canvas.Brush子元素包括以下SolidColorBrush、ImageBrush和DrawingBrush。
SolidColorBrush用純色填充定義的幾何區(qū)域。如果有顏色的α分量，則將它以相乘的方式與Brush中對應的不透明性屬性組合。

以下示例示出了如何對SolidColorBrush表達顏色屬性。<Path>
<Path.Fill>
<SolidColorBrush Color="#00FFFF"/>
</Path.Fill>
...</Path>
ImageBrush可用于用圖像填充空間。ImageBrush的標記允許指定URI。如果所有其它屬性被設為其默認值，則將拉伸圖像以填充區(qū)域的邊框。

ImageSource屬性必須引用支持的到達圖像格式之一或通往這些類型之一的圖像的其中一個選擇器。
DrawingBrush可用于用矢量圖來填充空間。DrawingBrush具有Drawing子元素，其使用在以下示出的標記中。<Path><Path.Fill>
<DrawingBrush>
<DrawingBrush.Drawing>
<Drawing>
<Path.../>
<Glyphs.../>
</Drawing>
</DrawingBrush.Drawing>
</DrawingBrush>
</Path.Fill></Path>
梯度刷子及其屬性梯度通過將一組梯度停點(stop)指定為梯度刷子的XML子元素來繪制。這些梯度停點沿某一類行進指定了顏色。本框架中支持兩種類型的梯度刷子線性和徑向。
梯度是通過在指定的顏色空間內(nèi)的梯度停點之間完成內(nèi)插來繪制的。LinearGradientBrush和RadialGradientBrush共享以下公用屬性


對于SpreadMethod屬性，考慮以下內(nèi)容。SpreadMethod選項指定了如何填充空間。默認值是Pad。

MappingMode屬性對于LinearGradientBrush，考慮以下內(nèi)容。LinearGradientBrush指定了沿一矢量的線性梯度刷子。

以下標記示例示出了對LinearGradientBrush的使用。用線性梯度填充了具有矩形路徑的頁面<FixedPanel>
<FixedPage>
<Path>
<Path.Fill>
<LinearGradientBrush StartPoint="0,0"EndPoint="1,0">
<LinearGradientBrush.GradientStops>
<GradientStopCollection>
<GradientStop Color="#FF0000"Offset="0"/>
<GradientStop Color="#0000FF"offset="1"/>
</GradientStopCollection>
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Path.Fill>
<Path.Data>
<PathGeometry>
<PathFigure>
<StartSegment Point="0,0"/>
<PolyLineSegment Points="100,0 100,100 0,100"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Data>
</Path>
</FixedPage>
</FixedPanel>
該示例示出了用線性梯度填充的具有矩形路徑的頁面。路徑在裁剪它的八邊形的形狀內(nèi)也有裁剪屬性。<FixedPanel>
<FixedPage>
<Path>
<Path.Clip>
<PathGeometry>
<PathFigure>
<StartSegment Point="25,0"/>
<PolyLineSegment Points="75,0 100,25 100,75 75,100 25,100 0,75 0,25"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Clip>
<Path.Fill>
<LinearGradientBrush StartPoint="0,0"EndPoint="1,0">
<LinearGradientBrush.GradientStops>
<GradientStopCollection>
<GradientStop Color="#FF0000"Offset="0"/>
<GradientStop Color="#0000FF"Offset="1"/>
</GradientStopCollection>
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Path.Fill>
<Path.Data>
<PathGeometry>
<PathFigure>
<StartSegment Point="0,0"/>
<PolyLineSegment Points="100,0 100,100 0,100"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Data>
</Path></FixedPage></FixedPanel>
RadialGradient(徑向梯度)在編程模型中與線性梯度相似。然而，線性梯度具有定義梯度矢量的起點和終點，而徑向梯度具有圓周以及焦點來定義梯度行為。圓周定義了梯度的終點—換言之，1.0的梯度停點定義了圓周周界的顏色。焦點定義了梯度的中心。0.0的梯度停點定義了焦點的顏色。


α和透明性依照所示并描述的實施例，每一元素的每一像素攜帶范圍從0.0(完全透明)到1.0(完全不透明)的α值。當混合元素以達到透明性的視覺效果時，使用α值。
每一元素可具有Opacity(不透明性)屬性，元素的每一像素的α值將與該屬性均勻地相乘。
另外，OpacityMask允許指定每一像素的不透明性，它將控制如何將呈現(xiàn)的內(nèi)容混合成其目標。由OpacityMask指定的不透明性與已經(jīng)發(fā)生在內(nèi)容的α通道中存在的任何不透明性用乘法組合。由OpacityMask指定的每一像素的Opacity通過查找掩模中每一像素的α通道來確定—忽略顏色數(shù)據(jù)。
OpacityMask的類型是Brush。這允許指定如何以各種不同的方式將Brush的內(nèi)容映射到內(nèi)容的范圍。如用于填充幾何結構那樣，Brush默認為填充整個內(nèi)容空間，在適當時拉伸或復制其內(nèi)容。這意味著圖像刷將拉伸其圖像源以完全覆蓋內(nèi)容，而梯度刷將從邊延伸到邊。
α混合需要的計算在先前“Opcity屬性”一節(jié)中描述。
以下示例示出了如何使用OpacityMask在Glyphs元素上創(chuàng)建“漸弱效果”。本示例中的OpacityMask是從不透明的黑漸弱到透明的黑的線性梯度。// /content/p1.xml<FixedPage PageHeight="1056"PageWidth="816">
<GlyphsOriginX="96"OriginY="96"UnicodeString="This is Page 1!"FontUri="../Fonts/Times.TTF"FontRenderingEmSize="16">
<Glyphs.OpacityMask>
<LinearGradientBrush StartPoint="0,0"EndPoint="1,0">
<LinearGradientBrush.GradientStops>
<GradientStopCollection>
<GradientStop Color="#FF000000"Offset="0"/>
<GradientStop Color="#00000000"Offset="1"/>
</GradientStopCollection>
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Glyphs.OpacityMask>
</Glyphs>
</FixedPage>
到達文檔中的圖像在固定頁面上，圖像填充了閉合區(qū)域。為將圖像放置在固定頁面上，首先必須在頁面上指定區(qū)域。區(qū)域由Path元素的幾何結構來定義。
Path元素的Fill屬性指定了所描述的區(qū)域的填充內(nèi)容。圖像是填充的一種類型，由圖像耍畫到區(qū)域中。所有的刷子具有默認的行為，該行為將通過在適當時拉伸或重復(平鋪)刷子內(nèi)容來填充整個區(qū)域。在圖像刷的情況下，由ImageSource屬性指定的內(nèi)容將被拉伸以完全覆蓋該區(qū)域。
以下標記示出了如何將圖像放到畫布上。<Canvas>
<Path>
<Path.Data>
<GeometryCollection>
...
</GeometryCollection>
</Path.Data>
<Path.Fill>
<ImageBrush ImageSource="/images/dog.jpg"/>
</Path.Fill>
</Path></Canvas>
由于許多圖像是矩形的，包括在資源字典中的矩形路徑元素在簡化標記時是有用的。路徑然后可使用RenderTransform屬性來定位(見上文)。<Canvas>
<Canvas.Resources>
<PathGeometry def:Name="Rectangle">
<PathFigure>
<StartSegment Point="0,0"/>
<PolylineSegment Points="100,0 100,100 0,100"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Canvas.Resources>
<Canvas>
<Canvas.RenderTransform>
<MatrixTransform Matrix="1,0,0,1,100,100"/>
</Canvas.RenderTransfom>
<Path Data="{Rectangle}">
<Path.Fill>
<ImageBrush ImageSource="/images/dog.jpg"/>
</Path.Fill>
</Path>
</Canvas></Canvas>
顏色顏色可以在所示并描述的標記中使用scRGB或sRGB表示法來指定。scRGB規(guī)范被稱為“IEC 61966-2-2scRGB”，并且可從www.iec.ch獲得。
ARGB參數(shù)在下表中描述。

顏色映射當前，考慮了用指定顏色背景的元數(shù)據(jù)來對彩色元素加標簽。該元數(shù)據(jù)可包含ICC顏色概覽或其它顏色定義數(shù)據(jù)。
<Glyphs>元素文本在固定有效負載中使用Glyphs元素來表示。該元素被設計成滿足用于打印和到達文檔的需求。
Glyphs元素可具有以下屬性的組合。




文本標記綜述字形度量每一字形定義了指定它如何與其它字形對齊的度量。依照一個實施例的示例性度量在圖12中示出。
前進寬度和組合記號一般而言，字體內(nèi)的字形是基礎字形或可附加到基礎字形的組合記號?；A字形通常具有非零的前進寬度，以及0，0的偏移矢量。而組合記號通常具有零前進寬度。偏移矢量可用于調(diào)整組合記號的位置，并且因此對組合記號可具有非0，0值。
字形行程中的每一字形具有控制其位置的三個值。這些值指示了原點、前進寬度和字形偏移，其每一個描述如下●原點每一字形被假定給予一名義原點，對于行程中的第一個字形，這是行程的原點。
●前進寬度每一字形的前進寬度提供了下一字形相對于該字形原點的原點。前進矢量總是在行程漸進的方向上繪制。
●字形偏移(基礎或記號)字形偏移矢量相對于其名義原點調(diào)整該字形位置。
字符、字形和群集映射群集映射對每一Unicode碼點包含一個條目。條目中的值是GlyphIndices數(shù)組中表示該碼點的第一個字形的偏移?；蛘撸敶a點是一組表示不可見字符群集的碼點的一部分時，GlyphIndices數(shù)組中的第一個字形表示代表該群集的第一個字形的偏移。
群集映射群集映射可表示碼點—字形映射，它可以是一對一、多對一、一對多或多對多。一對一映射是每一碼點僅由一個字形表示，圖13中的群集映射條目是0、1、2......。
多對一映射是兩個或多個碼點映射到單個字形。那些碼點的條目指定了字形索引緩沖區(qū)中該字形的偏移。在圖14的示例中，“f”和“i”字符用連字(ligature)來替換，這在許多襯線字體中是常見的排字慣例。
對于一對多映射，結合圖5考慮以下內(nèi)容?！癝ara Am”包含位于先前的基礎字符(環(huán))上方的部分，以及位于基礎字符(勾)右側(cè)的部分。當對泰文文本進行微調(diào)時，將勾與基礎字符分開，而環(huán)保留在基礎字符的上方，因此許多字體將環(huán)和勾編碼為單獨的字形。當一個碼點映射到兩個或多個字形時，該碼點的ClusterMap(群集映射)中的值引用GlyphIndeces數(shù)組中表示該碼點的第一個字形。
對于多對多映射，結合圖16考慮以下內(nèi)容。在某些字體中，字符群集的一組不可見碼點映射到一個以上字形。例如，這在支持印度語腳本的字體中是常見的。當該組不可見碼點映射到一個或多個字形時，每一碼點的ClusterMap中的值引用GlyphIndeces數(shù)組中表示該碼點的第一個字形。
以下示例示出了泰米爾單詞

的Unicode和字形表示。前兩個碼點組合在一起以生成三個字形。
指定群集群集規(guī)范優(yōu)于非1∶1群集的第一個字形的字形規(guī)范(映射比一字符對一字形映射更復雜)。
每一群集規(guī)范具有以下形式(ClusterCodepointCount[:ClusterGlyphCount])

<Glyphs>標記
Glyphs元素將字體指定為URI、版面索引和一組上述的其它屬性。例如<GlyphsFontUri="file://c:/windows/fonts/times.ttf"FontFaceIndex ="0" <!--Default 0==>
FontRenderingEmSize="20" <!--No default-->
FontHintingEmSize ="12" <!--Default 12-->
StyleSimulations ="BoldSimulation" <!--Default None-->
Sideways ="false" <!--Default false-->
BidiLevel ="0" <!--Default 0-->
Unicode="..." <!--Unicode rep-->
Indices="..." <!--See below-->
remaining attributes.../>
每一字形規(guī)范具有以下形式[GlyphIndex][,[Advance][,[uOffset][,[vOffset][,[Flags]]]]]字形規(guī)范的每一部分是可任選的

對于計算前進而沒有舍入誤差聚積，考慮以下內(nèi)容。每一前進值必須被計算為后來的字形的未舍入原點減去先前字形的已計算(即，已舍入)前進寬度的總和。以此方式，每一字形被定位到其確切位置的0.5％em之內(nèi)。
字形標記示例
<Canvas xmlns="http://schemas.microsoft.com/2005/xaml/"><GlyphsFontUri="file://c:/windows/fonts/times.ttf"FontFaceIndex ="0"FontRenderingEmSize="20"FontHintingEmSize ="12"StyleSimulations ="ItalicSimulation"Sideways ="false"BidiLevel ="0"OriginX="75"OriginY="75"Fill ="#00FF00"UnicodeString ="inner text..."/><!--'Hello Windows'without kerning--><GlyphsOriginX="200"OriginY="50"UnicodeString ="Hello,Windows!"FontUri="file://C:/Windows/Fonts/Times.TTF"Fill ="#00FF00"FontRenderingEmSize="20"/><!--'Hello Windows'with kerning--><GlyphsOriginX="200"OriginY="150"UnicodeString ="Hello,Windows!"Indices=";;;;;;;,89"FontUri="file://C:/Windows/Fonts/Times.TTF"Fill ="#00FF00"FontRenderingEmSize="20"/><!--'Open file'without'fi'ligature--><GlyphsOriginX="200"OriginY="250"UnicodeString ="Open file"FontUri="file://C:/Windows/Fonts/Times.TTF"Fill ="#00FF00"FontRenderingEmSize="20"/><!--'Open file'with'fi'ligature--><GlyphsOriginX="200"OriginY="350"UnicodeString ="Open file"Indices=";;;;;(2:1)191"FontUri="file://C:/Windows/Fonts/Times.TTF"Fill ="#00FF00"FontRenderingEmSize="20"/><!--'ежикв тумане'using pre-composed'e'--><GlyphsOriginX="200"OriginY="450"xml:lang ="ru-RU"UnicodeString ="ежикв тумане"FontUri="file://C:/Windows/Fonts/Times.TTF"Fill ="#00FF00"FontRenderingEmSize="20"/><!--'ежикв тумане'using composition of'e'and diaeresis--><GlyphsOriginX="200"OriginY="500"xml:lang ="ru-RU"UnicodeString ="ежикв тумане"Indices="(1:2)72;142,0,-45"FontUri="C:/Windows/Fonts/Times.TTF"Fill ="#00FF00"FontRenderingEmSize="20"/><!--'ежикв тумане'Forced rendering right-to-left showingcombining mark in logical order--><GlyphsOriginX="200"OriginY="550"BidiLevel ="1"xml:lang ="ru-RU"UnicodeString ="ежикв тумане"Indices="(1:2)72;142,0,-45"FontUri="file://C:/Windows/Fonts/Times.TTF"Fill ="#00FF00"FontRenderingEmSize="20"/></Canvas>
優(yōu)化字形標記的大小如果目標客戶機能可靠地重新生成標記細節(jié)，如字形索引和前進寬度，則可從標記中省略它們。以下選項允許常用簡單腳本的顯著優(yōu)化。
優(yōu)化字形索引的標記當在Unicode串中的字符位置和字形串中的字形位置之間有一對一映射，并且字形索引是字體的CMAP(字符映射)表中的值，并且Unicode字符有明確的語義時，字形索引可以從標記中省略。
當字符到字形的映射時，應當在標記中提供字形索引●不是一對一，如兩個或多個碼點形成單個字形(連字)，或者
●一個碼點生成多個字形，或者●發(fā)生了任一其它形式的字形替換，如通過OpenType特征的應用。
當呈現(xiàn)引擎可能替換不同于字體的CMAP(字符映射)表中字形的字形時，應當在標記中提供字形索引。當期望的字形表示不是字體的CMAP表中的字形時，應當提供字形索引。
字形位置的優(yōu)化標記當所需要的前進寬度的確是字體的HMTX(水平度量)或VMTX(垂直度量)表中的字形的前進寬度時，字形前進寬度可以從標記中省略。
當為零時，字形垂直偏移可以從標記中省略。這對于基礎字符幾乎總是真的，并且對于較簡單的腳本中的組合記號，通常也是真。然而，對于諸如阿拉伯語和印度語等更復雜的腳本中的組合記號，這通常是假。
字形標志的優(yōu)化標記對于具有正常調(diào)整優(yōu)先級的基礎字形，字形標志可以被省略。
應用程序接口以下描述了平臺無關包裝應用程序接口(API)的一個示例實施例。該API層由抽象類以及作為包裝層的一部分包括在內(nèi)的其它基類構成。該API包括以下討論的類。
Container(容器)容器是將部件集合容納在一起的邏輯實體。


構造函數(shù)protected Container(FileInfo fileInfo,FileAccess access)基類的受保護構造函數(shù)。明確地在該類中定義，因此能更容易地證明和維護該構造函數(shù)。如果不滿足，則編譯器將添加一構造函數(shù)。同樣，這是抽象類和子類之間的當前合約。當fileInfo對象為空時，它定義了容器在流上被打開或創(chuàng)建。
屬性public virtual DateTime CreationTime{get;set}獲取或設置該容器的創(chuàng)建時間。當該值被設置時，也應當將LastAccessTime(最后一次訪問時間)和LastWriteTime(最后一次寫時間)更新為同一值。System_IO_FileInfo對象用于操縱該值。
異常-InvalidArgumentException(無效自變量異常)—如果CreationTime被設為大于LastAccessTime或LastWriteTime的值。
-InvalidOperationException(無效操作異常)—如果容器在流上打開，則無法獲取這一屬性。
public virtual DateTime LastAccessTime{get;set;}獲取或設置該容器被最后一次打開的時間。System_IO_FileInfo對象用于操縱該值。異常-InvalidArgumentException-如果LastAccessTime被設為小于CreationTime或LastWriteTime的值。
-InvalidOperationException-如果容器在流上打開，則無法獲取該屬性。
public virtual DateTime LastWriteTime{get;set}獲取或設置最后一次修改該容器的時間。同樣，當更新LastWriteTime時，應當將LastAccessTime更新到同一值。System_IO_FileInfo對象用于操縱該值。
異常-InvalidArgumentException-如果LastWriteTime被設為小于CreationTime的值。
-InvalidOperationException-如果容器在流上打開，則無法獲取該屬性。
public FileAccess FileOpenAccess{get;}獲取用于打開容器的FileAccesss(文件訪問權限)。這是只讀屬性。該屬性在打開容器時被設置。
public abstract Part StartingPart{get;set}獲取或設置容器的StartinGpART(起始部件)方法public static Container OpenOnFile(string path)OpenOnFile方法的該重載版本將返回在給定路徑上指定的容器。該方法調(diào)用接受具有以下默認值的所有參數(shù)的重載。
FileMode(文件模式)-FileMode.OpenOrCreateFileAccess(文件訪問權限)-FileAccess.ReadWriteFileShare(文件共享)-FileShare.None
public static Container OpenOnFile(string path,FileMode mode)OpenOnFile方法的這一重載版本將以指定的文件模式返回在給定路徑上指定的容器。該方法調(diào)用接受具有以下默認值的所有參數(shù)的重載FileAccess-FileAccess.ReadWriteFileShare-FileShare.Nonepublic static Container OpenOnFile(string path,FileMode mode,FileAccess access)OpenOnFile的該重載版本將以指定的文件模式和文件訪問返回在給定路徑上指定的容器。該方法調(diào)用接受具有以下默認值的所有參數(shù)的重載FileShare-FileShare.Nonepublic static Container OpenOnFile(string path,FileMode mode,FileAccess access,FileShare share)OpenOnfile方法的該重載版本將用設為提供的值的模式、訪問和共享來打開給定路徑上的容器。
異常-InvalidArgumentException-如果FileMode、FileAccess和FileShare參數(shù)的組合無意義。
public static Container OpenOnUri(Uri uri)OpenOnUri方法的該重載版本將返回在給定uri處指定的容器。該方法調(diào)用接受具有以下默認值的所有參數(shù)的重載FileMode-FileMode.OpenFileAccess-FileAccess.Readpublic static Container OpenOnUri(Uri uri,FileMode mode)OpenOnUri的該重載版本將以指定的文件模式返回給定uri處指定的容器。該方法調(diào)用接受具有以下默認值的所有參數(shù)的重載FileAccess-FileAccess.Read
public static Container OpenOnUri(Uri uri,FileMode mode,FileAccess access)OpenOnUri方法的該重載版本將用設為提供的值的模式和訪問打開給定uri處的容器。WebRequest/WebResponse(web請求/web響應)機制將用于獲取容器。FileMode和FileAccess參數(shù)將應用于要打開的容器。該方法調(diào)用具有正確內(nèi)容類型的OpenOnStream方法。
異常-InvalidArgumentException-如果FileMode、FileAccess和FileShare參數(shù)的組合無意義。
public static Container OpenOnStrem(Stream stream,string contentType)OpenOnStream的該重載版本將在提供的流上返回容器。該方法調(diào)用接受具有以下默認值的所有參數(shù)的重載FileMode-FileMode.OpenFileAccess-FileAccess.Readpublic static Container OpenOnStream(Stream stream,string contentType,FileModemode)OpenOnStream的該重載版本將以指定的文件模式在提供的流上返回容器。該方法調(diào)用接受具有以下默認值的所有參數(shù)的重載FileAccess-FileAccess,Readpublic static Container OpenOnStream(Stream stream,string contentType,FileModemode,FileAccess access)OpenOnStream的該重載版本將用設為提供的值的模式和訪問在提供的流上打開容器。FileMode和FileAccess參數(shù)將被應用于要打開的容器。contentType參數(shù)用于例示適當?shù)淖宇悓ο蟆?br> 異常-InvalidArgumentException-如果FileMode、FileAccess和FileShare參數(shù)額度組合無意義。
public Part AddPart(MMCFUri uri,string contentType)給定Uri的部件被添加到容器。如果未作出明確的調(diào)用來讀取或?qū)懭肓?，則該方法將用空流來添加部件。該方法調(diào)用完成與物理實現(xiàn)相關的實際工作的AddPartCore。
異常-InvalidArgumentException-如果對應于該Uri的部件已在容器中存在。
public Part GetPart(MMCFUri uri)返回給定Uri的部件。uri相對于容器的根。該方法調(diào)用實際獲取部件的GetPartCore。
異常-InvalidArgumentException-如果對應于該Uri的部件在容器中不存在。
public virtual bool Exists(MMCFUri uri)由于可能令關系指向仍不存在的目標，因此該方法提供了一種方便的方法來找出部件是否在底層容器中實際存在。該uri應當相對于容器的根。
public void DeletePart(MMCDUri uri)該方法將從當前容器中刪除容器部件。對于其該部件是源部件的所有關系也被刪除。該方法將刪除底層的流，并且將處置對象。同樣，如果打開了該部件的多個實例，則處置該部件的所有打開的實例。該方法將做必要的清理來實施這一行為，然而流的實際刪除對于底層物理實現(xiàn)是專用的，并因此調(diào)用了刪除實際流的DeletePartCore方法。未完成的部件枚舉器將被無效。
public PartCollection GetParts()這返回容器內(nèi)所有部件的集合。不返回關系。
public void Flush()該方法在打開的個別部件上調(diào)用清洗，由此強制了所有的部件和關系被清洗到底層容器。本質(zhì)上該類將維護它分發(fā)的所有部件的數(shù)組，然后將在所有的部件上調(diào)用Flush。它然后調(diào)用完成對整個容器專用的工作的FlushCore()。
public virtual void Dispose()所有打開的部件和關系都被清洗到底層容器。由于該類維護分發(fā)的所有部件的數(shù)組，因此該方法將在分發(fā)的所有部件上調(diào)用Dispose()。如果任一其它資源需要被清洗，則子類應當覆蓋該方法以完成附加的清洗。
public void Close()Close方法與處置相同，因此它內(nèi)部地調(diào)用了Dispose()方法。
public Relationship AddRelationship(Uri uri)該方法添加了容器和由URI指定的部件之間的關系。它返回Relationship對象。該改變進在調(diào)用了Flush()方法之后被清洗到底層容器。在同一源和目標之間可以有多個關系。所有未完成的關系枚舉器將被無效。
public void DeleteRelationship(Relationship relationship)該方法刪除由Relationship對象指定的目標關系。該改變進在調(diào)用了Flush()方法之后被清洗到底層容器。刪除操作基于對象的“名字”來完成，并且因此，每一對象被唯一地標識。所有未完成的關系枚舉器被無效。
異常-InvalidArgumentException-如果關系的源不與當前部件相同。
public RelationshipCollection GetRelationships()這從容器返回所有目標關系的集合。當在公知的uri上定位了容器的目標關系，則可能提供一默認實現(xiàn)，它將打開關系部件，然后從流中讀取xml并創(chuàng)建集合對象(異常—如果從底層容器讀取的XML是畸形的。)protected abstract Part AddPartCore(MMFCUri uri,string contentType)該方法用于底層文件格式的自定義實現(xiàn)。它將從AddPart方法中調(diào)用。這將實際在底層容器中創(chuàng)建部件?？詹考斪鳛樵撜{(diào)用的結果而被創(chuàng)建。
protected abstract Part GetPartCore(MMCFUri uri)該方法用于底層文件格式的自定義實現(xiàn)。它將從GetPart方法中調(diào)用。該方法從底層容器中取出實際的部件。如果部件不存在，則它返回“空”。
protected abstract void DeletePartCore(MMCFUri uri)該方法用于底層文件格式的自定義實現(xiàn)。它應當實際刪除對應于該部件的流。同樣，如果不存在對應于給定URI的部件，則它應當不拋出。
protected abstract Part[]GetPartsCore()該方法用于底層文件格式的自定義實現(xiàn)。它應當返回容器中所有部件的數(shù)組。由于獲取容器中所有部件的方法對實際物理格式是專用的，因此該方法是游泳的。提供了該方法，使得實際的GetParts調(diào)用僅將該數(shù)組傳遞到PartCollection，并且可提供其上的枚舉器。以此方式，PartCollection類可以是有形的類。同樣，如果容器中沒有部件，則GetPartsCore應當返回空數(shù)組。
protected abstract void FlushCore()該方法用于底層文件格式的自定義實現(xiàn)。該方法將所有的內(nèi)容清洗到盤。
protected abstract void DisposeCore()該方法用于底層文件格式的自定義實現(xiàn)。該方法應當釋放對應于實際物理格式的資源。
Part(部件)部件包括三個部分●URI-相對于容器的根●ContentType-它是由該部件表示的流的模仿類型●Stream-對應于該部件的實際流另外部件可用關系被鏈接到其它部件。關系中的SourcePart(源部件)擁有該關系。

構造函數(shù)protected Part(Container container,MMCFUri uri,string contentType)用于基類的受保護的構造函數(shù)。在該類中明確地定義，使得能更容易地證明和維護該構造函數(shù)。如果不滿足，則編譯器將添加一構造函數(shù)。這也是抽象類和子類之間的當前合約。
屬性public MMCFUri Uri{get;}該屬性返回部件的MMCFUri。這是只讀屬性。
public string ContentType{get;}該屬性返回由部件表示的流的內(nèi)容類型。這是只讀屬性。
public Container Container{get；}該屬性返回部件的父容器。這是只讀屬性。
方法
public Stream GetStream()該方法返回對應于該部件的流。它調(diào)用接受具有以下默認值的所有參數(shù)的重載FileMode-OpenFileAccess-ReadWritepublic Stream GetStream(FileMode mode)該方法以指定的模式返回對應于該部件的流。它調(diào)用接受具有以下默認值的所有參數(shù)的重載FileAccess-ReadWritepublic Stream GetStream(FileMode mode，F(xiàn)ileAccess access)該方法返回對應于該部件的流。它調(diào)用返回實際流的GetStreamCore方法。該方法完成所需的內(nèi)務處理以跟蹤所有打開的流。
public abstract Stream GetStreamCore(FileMode mode,FileAccess access)該方法返回對應于該部件的流。該方法用于自定義實現(xiàn)。
public Relationship AddRelationship(Uri uri)該方法添加指定的URI處的部件和當前部件之間的關系。它返回Relationship對象。
該改變僅在調(diào)用了Flush()方法之后被清洗到底層容器。在同一源和目標之間可以有多個關系。所有未完成的關系枚舉器將被無效。
異常-InvalidOperationException-如果當前部件是關系。
public void DeleteRelationship(Relationship relationship)該方法刪除由Relationship對象指定的目標關系。該改變僅在調(diào)用了Flush()方法之后被清洗到底層容器。刪除操作基于對象的“引用”來完成，并且因此每一對象被唯一地標識。所有未完成的關系枚舉器被無效。
異常-InvalidArgumentException-如果關系的源不與當前部件相同。
public RelationshipCollection GetRelationships()這返回該部件的所有目標關系的集合。當在公知的uri處定位了該部件的目標關系時，可能提供一默認實現(xiàn)，它打開關系部件，然后從流中讀取xml并創(chuàng)建對象集合(異常—如果從底層容器讀取的XML是畸形的。)Relationship(關系)該類用于表達源和目標部件之間的關系。創(chuàng)建關系的唯一方法是調(diào)用Part.AddRelationship(Uri uri)。關系由源部件擁有，因此如果源部件被刪除，則它所擁有的所有關系也被刪除。關系的目標不必要存在。

構造函數(shù)internal Relationship(Uri source,Uri target,string name)返回Relationship對象。
屬性public Part Source{get;}獲取關系的源部件。這是只讀屬性。當創(chuàng)建關系時設置該屬性。
public Uri TargetUri{get;}獲取關系的目標Uri。該Uri應當被看作相對于源uri。
public string Name{get;}獲取對應于該關系的名字。
PartCollection(部件集合)這是容器中部件的集合。

構造函數(shù)internal PartCollection(Dictionary<MMCFUri,Part>partDictionary)基于Part對象的類屬字典創(chuàng)建PartCollection。
方法public IEnumerator GetEnumerator()IEnumerable接口的成員。它返回部件集合上的枚舉器。
RelationshipColection(關系集合)這是與容器中部件相關聯(lián)的關系的集合。在給定的源和目標部件之間可以有一個以上關系。

構造函數(shù)internal RelationshipCollection(Relationship[] relationships)基于Relationship對象創(chuàng)建RelationshipCollection方法public IEnumerator GetEnumerator()MMFCUri該類從URI類繼承。該Uri類的主函數(shù)是確保指定的URI以“/”開始。該類的動機是1.確保用于每一個別部件的URI以“/”開始。這確保所有的部件名相對于容器的根。
2.由于System.Uri類不允許解析兩個相對URI，因此他們需要以不同的方式來解析，因此在一個地方有這一邏輯是較佳的。
3.強制容器是授權機構這一事實。由此，任何相對引用應當不被解析成容器外部的位置。
4.

構造函數(shù)public MMCFUri(string uri)從提供的uri串創(chuàng)建MMCFUri。確保該Uri是相對的且以“/”開始。
異常-InvalidArgumentException-如果URI包括主機名和協(xié)議，即，它是絕對URI。
public MMCFUri(MMCFUri baseUri,string relativeUri)
從提供的Uri對象和relativeUri(相對URI)串創(chuàng)建MMCFUri對象。相對于baseUri(基礎URI)解析相對uri。確保Uri是相對的，且以“/”開始。
異常-InvalidArgumentException-如果URI包括主機名和協(xié)議，即它是絕對URI。
代碼示例

其它API細節(jié)OpenOnFile、OpenOnUri和OpenOnStream方法這些方法具有硬編碼的邏輯，并且這些方法知道的唯一物理容器格式是復合文件實現(xiàn)。由于擁有這些類，因此有關于從這些靜態(tài)方法調(diào)用的子類構造函數(shù)的假設。同樣，這些靜態(tài)方法基于文件擴展名或當前流的內(nèi)容類型例示正確的子類對象。
OpenOnStream方法和對容器指定的訪問的含義當在流上創(chuàng)建容器時，重要的是確保對容器指定的FileAccess與提供的流兼容。以下表格列出了各種可能性以及如何處理它們的示例。


在第一行中，流具有更多的訪問，而希望創(chuàng)建更受限制的容器，因此用稱為RestrictedStream的私有流包裝傳入的流，該私有流具有適當?shù)哪茏x和能寫值。
Part和Relationship對象的存儲器中高速緩存字典維持所有的部件可訪問，并且如果第二次要求部件，則返回從字典對該部件的引用。這是更有效的，并且因為Part對象是不變的，這可以沒有任何問題地完成。它也應用于Relationship對象。然而，如果底層容器以共享的寫模式打開，并且有第二用戶向底層容器添加或刪除了部件，則這些改變將不會在高速緩存中得到反映。
總結上述模塊化內(nèi)容框架和文檔格式方法和系統(tǒng)提供了一組構件塊，用于組成、包裝、分發(fā)和呈現(xiàn)以文檔為中心的內(nèi)容。這些構件塊定義了用于文檔格式的平臺無關框架，使軟件和硬件系統(tǒng)能夠可靠和一致地生成、交換和顯示文檔。所示并描述的到達包格式提供了一種用于以可用各種各樣環(huán)境中的設備和應用程序之間的完全保真度并且跨各種各樣情形來顯示或打印到達包的內(nèi)容的方式儲存已編頁碼或預編頁碼的文檔的格式。盡管以對結構特征和/或方法步驟專用的語言描述了本發(fā)明，然而可以理解，所附權利要求書中定義的本發(fā)明不必要限于所描述的特征或步驟。相反，揭示了具體特征和步驟作為實現(xiàn)要求保護的本發(fā)明的較佳形式。
權利要求
1.一種方法，其特征在于，包括創(chuàng)建定義文檔的包，其中，所述文檔包括構成所述文檔的多個部件，并且其中，所述多個部件的每一個具有一相關聯(lián)的名字；以及將一關系與所述多個部件的至少一個相關聯(lián)，其中，所述關系標識了所述相關聯(lián)的部件和所述包內(nèi)的至少一個其它部件之間的連接，并且其中，所述相關聯(lián)的關系儲存在一關系部件中，所述關系部件具有從所述相關聯(lián)部件的名字導出的名字。
2.如權利要求1所述的方法，其特征在于，還包括儲存關于所述包內(nèi)至少一個關系的信息。
3.如權利要求1所述的方法，其特征在于，還包括標識關于與所述包內(nèi)的部件相關聯(lián)的關系的信息；以及儲存所標識的信息。
4.如權利要求1所述的方法，其特征在于，所述關系標識了有關部件，以及所述相關聯(lián)的部件和所述有關部件之間的關系的特性。
5.如權利要求1所述的方法，其特征在于，所述關系的名字是統(tǒng)一資源標識符。
6.如權利要求1所述的方法，其特征在于，還包括通過分析與所述包內(nèi)的部件相關聯(lián)的關系發(fā)現(xiàn)所述包內(nèi)部件之間的連接。
7.如權利要求1所述的方法，其特征在于，還包括高速緩存關于所述關系的信息。
8.如權利要求1所述的方法，其特征在于，所述關系是使用與用于所述關系所連接的部件的模式無關的模式來描述的。
9.如權利要求1所述的方法，其特征在于，所述關系被儲存，使得它不改變所述相關聯(lián)部件的任一個的內(nèi)容。
10.如權利要求1所述的方法，其特征在于，所述關系被發(fā)送，使得它不改變所述相關聯(lián)部件的任一個的內(nèi)容。
11.一個或多個其上具有計算機可讀指令的計算機可讀介質(zhì)，當所述指令被執(zhí)行時，實現(xiàn)權利要求1所述的方法。
12.一種包含權利要求11所述的計算機可讀介質(zhì)的計算系統(tǒng)。
13.一種方法，其特征在于，包括標識包含多個部件的包，其中，所述包定義了文檔；標識與所述多個部件相關聯(lián)的關系，其中，每一關系定義了第一有關部件、第二有關部件以及所述第一有關部件和所述第二有關部件之間的關系的特性；以及基于包含在所標識的關系中的信息從所述包檢索至少一個部件。
14.如權利要求13所述的方法，其特征在于，還包括儲存關于與所述多個部件相關聯(lián)的關系的信息。
15.如權利要求13所述的方法，其特征在于，還包括檢索與所述包相關聯(lián)的關系信息。
16.如權利要求13所述的方法，其特征在于，還包括通過分析所標識的關系發(fā)現(xiàn)所述包內(nèi)部件之間的連接。
17.一種方法，其特征在于，包括創(chuàng)建定義文檔的包，其中，所述文檔包括構成所述文檔的多個部件，并且其中，所述多個部件的每一個具有一相關聯(lián)的名字；以及將有關部件的列表與所述多個部件的每一個相關聯(lián)，其中，所述有關部件的列表標識了所述包內(nèi)所述相關聯(lián)的部件和其它部件之間的任何連接，并且其中，所述有關部件的列表具有從所述相關聯(lián)的部件的名字導出的名字。
18.如權利要求17所述的方法，其特征在于，還包括在所述包內(nèi)儲存所述有關部件的列表。
19.如權利要求17所述的方法，其特征在于，還包括與所述包分離地儲存所述有關部件的列表。
20.如權利要求17所述的方法，其特征在于，所述有關部件的列表標識了與所述列表相對應的部件相關聯(lián)的多個部件。
21.如權利要求17所述的方法，其特征在于，還包括通過分析所述有關部件的列表發(fā)現(xiàn)所述包內(nèi)部件之間的連接。
22.如權利要求17所述的方法，其特征在于，還包括高速緩存儲存在標識所述有關部件列表中的有關部件的部件中的信息。
23.如權利要求17所述的方法，其特征在于，所述有關部件列表不改變應用所述有關部件列表應用的源部件，或所述有關部件列表中標識的任何有關部件。
24.一個或多個其上具有計算機可讀指令的計算機可讀介質(zhì)，當所述指令被執(zhí)行時，實現(xiàn)權利要求17所述的方法。
25.一種包含權利要求24所述的計算機可讀介質(zhì)的計算系統(tǒng)。
26.一種模式，其特征在于，包括標識包內(nèi)部件之間的關系的至少一個關系元素；標識每一關系中的目標部件的至少一個屬性；以及標識名字的至少一個屬性，其中，所述名字標識了每一關系的目的。
27.如權利要求26所述的模式，其特征在于，一附加關系元素將任意數(shù)量的關系元素組合在一起。
28.如權利要求26所述的模式，其特征在于，所述關系元素不改變所述包內(nèi)的任何部件。
29.如權利要求26所述的模式，其特征在于，多個關系與所述包相關聯(lián)。
30.如權利要求26所述的模式，其特征在于，標識目標部件的所述屬性包括統(tǒng)一資源標識符。
31.如權利要求26所述的模式，其特征在于，標識名字的所述屬性使用統(tǒng)一資源標識符來唯一地定義所述關系的目的。
32.一種在一個或多個計算機可讀介質(zhì)上實施的應用程序接口，其特征在于，包括展示創(chuàng)建包的第一方法，其中，所述包將多個部件容納在一起；展示創(chuàng)建所述包和多個部件之間的關系的第二方法；以及展示標識所述多個部件之間的關系的第三方法。
33.如權利要求32所述的應用程序接口，其特征在于，還包括刪除現(xiàn)有關系的第四方法。
34.如權利要求32所述的應用程序接口，其特征在于，還包括檢索關于現(xiàn)有關系的信息的第四方法。
35.如權利要求32所述的應用程序接口，其特征在于，還包括標識與特定關系相關聯(lián)的源部件的屬性。
36.如權利要求32所述的應用程序接口，其特征在于，還包括標識與特定關系相關聯(lián)的目標統(tǒng)一資源標識符的屬性。
37.如權利要求32所述的應用程序接口，其特征在于，還包括標識與特定關系相關聯(lián)的名字的屬性。
38.一種在一個或多個計算機可讀介質(zhì)上實施的應用程序接口，其特征在于，包括調(diào)用創(chuàng)建包的第一方法，其中，所述包包含多個部件；調(diào)用創(chuàng)建所述包內(nèi)兩個部件之間的關系的第二方法；以及調(diào)用標識所述包內(nèi)令另一對部件之間的關系的第三方法。
39.如權利要求38所述的應用程序接口，其特征在于，還包括對每一關系定義一源部件。
40.如權利要求38所述的應用程序接口，其特征在于，還包括對每一關系定義一目標統(tǒng)一資源標識符。
41.如權利要求38所述的應用程序接口，其特征在于，還包括定義與每一關系相關聯(lián)的名字。
全文摘要
描述了模塊化內(nèi)容框架和文檔格式方法和系統(tǒng)。描述的框架和格式定義了一組構件塊，用于組成、包裝、分發(fā)和呈現(xiàn)以文檔為中心的內(nèi)容。這些構件塊定義了用于文檔格式的平臺無關框架，使軟件和硬件系統(tǒng)能夠可靠并一致地生成、交換和顯示文檔。該框架和格式用靈活和可擴充的方式來設計。除該通用框架和格式之外，使用該通用框架定義了一種被稱為到達包的特定格式。到達包格式是用于儲存已編頁碼文檔的格式。到達包的內(nèi)容可以用各種各樣環(huán)境內(nèi)的設備和應用程序之間的完全保真度并跨各種各樣情形來顯示或打印。
文檔編號G06F17/30GK1833240SQ200480001329
公開日2006年9月13日 申請日期2004年7月23日 優(yōu)先權日2004年4月30日
發(fā)明者D·奧恩斯坦, A·舒爾, M·J·希爾波格, B·M·瓊斯, D·F·埃默森, J·杜尼茲, O·H·弗爾, B·A·麥克肯齊, J·D·潘利, J·波洛克, S·謝斯 申請人:微軟公司