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


圖1是依照一個(gè)實(shí)施例的示例性框架和格式的組件的框圖。
圖2是依照一個(gè)實(shí)施例容納包括若干部件的文檔的示例性包的框圖。
圖3所示是依照一個(gè)實(shí)施例產(chǎn)生包的示例性書寫者以及讀取包的示例性閱讀者的框圖。
圖4示出了將三個(gè)單獨(dú)的頁(yè)面綁定在一起的示例性部件。
圖5所示是依照一個(gè)實(shí)施例的示例性選擇器，以及被排列以產(chǎn)生包含報(bào)表的英語(yǔ)表示和法語(yǔ)表示的財(cái)務(wù)報(bào)表的序列的圖示。
圖6示出了依照一個(gè)實(shí)施例共同工作以交流包的書寫者和閱讀者的某些示例。
圖7示出了文檔的多個(gè)交錯(cuò)部件的示例。
圖8和9示出了包裝圖7所示的文檔的多個(gè)部件的不同示例。
圖10示出了依照一個(gè)實(shí)施例的示例性到達(dá)包以及可構(gòu)成該包或可在該包中找到的部件的每一個(gè)有效類型。
圖11示出了依照一個(gè)實(shí)施例從公用語(yǔ)言運(yùn)行庫(kù)概念到XML的示例性映射。
圖12示出了依照一個(gè)實(shí)施例的豎直和橫向字形度量。
圖13示出了依照一個(gè)實(shí)施例的一對(duì)一群集映射。
圖14示出了依照一個(gè)實(shí)施例的多對(duì)一群集映射。
圖15示出了依照一個(gè)實(shí)施例的一對(duì)多群集映射。
圖16示出了依照一個(gè)實(shí)施例的多對(duì)多群集映射。
較佳實(shí)施例的詳細(xì)描述
綜述
本文檔描述了一種模塊化內(nèi)容框架和文檔格式。該框架和格式定義了一組構(gòu)件塊，用于組成、包裝、分發(fā)和呈現(xiàn)以文檔為中心的內(nèi)容。這些構(gòu)件塊定義了一種用于文檔格式的平臺(tái)無(wú)關(guān)框架，使軟件和硬件系統(tǒng)能夠可靠并一致地生成、交換和顯示文檔。該框架和格式是以靈活和可擴(kuò)充的方式來(lái)設(shè)計(jì)的。在各種實(shí)施例中，對(duì)可包括的內(nèi)容類型、如何呈現(xiàn)內(nèi)容或構(gòu)建用于處理內(nèi)容的客戶機(jī)的平臺(tái)沒有任何限制。
除這一通用框架之外，使用該通用框架定義了一種特定格式。該格式在本文檔中被稱為到達(dá)包格式，并且是用于儲(chǔ)存已編頁(yè)碼或預(yù)編頁(yè)碼的文檔的格式。到達(dá)包的內(nèi)容可以用完全的保真度在各種各樣的環(huán)境中的設(shè)備和應(yīng)用程序之間，以及跨各種各樣的情形來(lái)顯示或打印。
下文描述的框架的目標(biāo)之一是確保獨(dú)立書寫的軟件和硬件系統(tǒng)在讀取或書寫依照下文描述的框架和格式產(chǎn)生的內(nèi)容時(shí)的互操作性。為實(shí)現(xiàn)這一互操作性，所描述的格式定義了讀取或書寫內(nèi)容的系統(tǒng)必須滿足的形式要求。
以下討論是沿以下線條來(lái)組織的，并在兩個(gè)主要章節(jié)中提出—一個(gè)名為“框架”，另一個(gè)名為“到達(dá)包格式”。
名為“框架”的一節(jié)提出了一種說(shuō)明性的包裝模型，并描述了構(gòu)成框架包的各個(gè)部件和關(guān)系。討論了關(guān)于使用框架包中的描述性元數(shù)據(jù)的信息，以及映射到物理容器、擴(kuò)展框架標(biāo)記的過(guò)程，以及對(duì)框架版本化機(jī)制的使用。
名為“到達(dá)包格式”的一節(jié)研究了被稱為到達(dá)包的一個(gè)特定類型的框架構(gòu)建包的結(jié)構(gòu)。該節(jié)也描述了對(duì)固定的有效負(fù)載專用包部件，并定義了一種到達(dá)包標(biāo)記模型和繪制模型。本節(jié)以示例性到達(dá)標(biāo)記元素及其屬性連同所示的樣例一起結(jié)束。
作為以下討論的高級(jí)綜述，考慮圖1，它一般在100示出了本發(fā)明的框架和格式的各方面?？蚣艿哪承┦纠越M件在102示出，而到達(dá)包格式的某些組件在104示出。
框架102包括示例性組件，包括但不限于，關(guān)系組件、可插入容器組件、交錯(cuò)/流組件以及版本化/可擴(kuò)充性組件，其每一個(gè)都在下文更詳細(xì)地研究。到達(dá)包格式104包括組件，組件包括選擇器/定序器組件以及包標(biāo)記定義組件。
在以下討論中，將周期性地回頭參考圖1，使得讀者可以維持關(guān)于所描述的組件適合框架和包格式的那里的觀點(diǎn)。
框架
在以下討論中，提供了對(duì)通用框架的描述。各個(gè)初級(jí)小標(biāo)題包括“包模型”、“排版部件選擇器和序列”、“描述性元數(shù)據(jù)”、“物理模型”、“物理映射”、以及“版本化和可擴(kuò)充性”。每一初級(jí)小標(biāo)題具有一個(gè)或多個(gè)相關(guān)小標(biāo)題。
包模型
本節(jié)描述了包模型，并包括描述包和部件、驅(qū)動(dòng)程序、關(guān)系、包關(guān)系和起始部件的小標(biāo)題。
包和部件
在所示和描述的模型中，內(nèi)容被容納在包內(nèi)。包是容納相關(guān)部件的集合的邏輯實(shí)體。包的目的是將文檔的所有片段(或其它類型的內(nèi)容)收集到程序員和終端用戶易于工作的一個(gè)對(duì)象。例如，考慮圖2，示出了容納文檔的示例性包200，文檔包括若干部件，部件包括表示文檔的XML標(biāo)記部件202、描述文檔中使用的字體的字體部件204、描述文檔的頁(yè)面的多個(gè)頁(yè)面部件206、以及表示文檔內(nèi)的圖片的圖片部件。表示文檔的XML標(biāo)記部件202是有利的，因?yàn)樗蓽?zhǔn)許容易的可搜索性和參考，而無(wú)需對(duì)包的整個(gè)內(nèi)容進(jìn)行語(yǔ)法分析。這將在下文變得顯而易見。
貫穿該文檔，引入并討論的閱讀者(也稱為消費(fèi)者)和書寫者(也稱為生產(chǎn)者)的概念。本文檔中使用的術(shù)語(yǔ)閱讀者指的是讀取基于模塊化內(nèi)容格式的文件或包的實(shí)體。本文檔中使用的術(shù)語(yǔ)書寫者指的是書寫基于模塊化內(nèi)容格式的文件或包。作為一個(gè)示例，考慮圖3，示出了產(chǎn)生包的書寫者和讀取包的閱讀者。通常，書寫者和閱讀者被具體化為軟件。在至少一個(gè)實(shí)施例中，與創(chuàng)建和格式化包相關(guān)聯(lián)的大多數(shù)處理開銷和復(fù)雜性被放置在書寫者上。這進(jìn)而從閱讀者中消除了大多數(shù)處理復(fù)雜性和開銷，如本領(lǐng)域的技術(shù)人員所理解的，這是違背許多現(xiàn)有模型的。這一方面將在下文變得顯而易見。
依照至少一個(gè)實(shí)施例，單個(gè)包包含容納在包內(nèi)的內(nèi)容的一個(gè)或多個(gè)表示。通常，包是單個(gè)文件，在本申請(qǐng)中被稱為容器。例如，這給予終端用戶一種方便的方法來(lái)以文檔的所有組成片段(圖像、字體、數(shù)據(jù)等)分發(fā)其文檔。盡管包通常直接對(duì)應(yīng)于單個(gè)文件，然而不必要總是如此。包是可以用各種方式來(lái)物理地表示的邏輯實(shí)體(例如，但不限于，在單個(gè)文件中、松散文件的集合、數(shù)據(jù)庫(kù)中、通過(guò)網(wǎng)絡(luò)連接的短暫傳輸?shù)鹊?。由此，容器容納包，但是并非所有的包都儲(chǔ)存在容器內(nèi)。
抽象模型與任一物理存儲(chǔ)機(jī)制無(wú)關(guān)地描述了包。例如，抽象模型并不涉及“文件”、“流”或與包所位于的物理領(lǐng)域有關(guān)的其它物理術(shù)語(yǔ)。如下文所討論的，抽象模型允許用戶為各種物理格式、通信協(xié)議等創(chuàng)建驅(qū)動(dòng)程序。用類推的方法，當(dāng)應(yīng)用程序希望打印圖像時(shí)，它使用打印機(jī)的抽象(由理解特定種類的打印機(jī)的驅(qū)動(dòng)程序呈現(xiàn))。由此，不需要應(yīng)用程序知道特定的打印設(shè)備或如何與打印設(shè)備通信。
容器提供了除松散、斷開的文件集合之外的許多好處。例如，類似的組成部分可以被聚積，并且內(nèi)容可以被索引和壓縮。另外，組成部分之間的關(guān)系可以被識(shí)別，并且權(quán)限管理、數(shù)字簽名加密和元數(shù)據(jù)可以被應(yīng)用到組成部分。當(dāng)然，容器可用于并實(shí)施上文未具體列出的其它特征。
公用部件屬性
在所示并描述的實(shí)施例中，部件包括公用屬性(如，名字)和字節(jié)流。這類似于文件系統(tǒng)中的文件或HTTP服務(wù)器上的資源。除其內(nèi)容之外，每一部件具有某些公用部件屬性。這包括名字-它是部件的名字，以及內(nèi)容類型-它是儲(chǔ)存在部件中的內(nèi)容的類型。部件也可以具有一個(gè)或多個(gè)相關(guān)聯(lián)的關(guān)系，如下文所討論的。
部件名是在必須在某些方面涉及到部件的任何時(shí)刻使用的。在所示和描述的實(shí)施例中，名字被組織成分層結(jié)構(gòu)，這類似于文件系統(tǒng)中的路徑或URI中的路徑。以下是部件名的示例
/document.xml
/tickets/ticket.xml
/images/march/summer.jpeg
/pages/page4.xml
如上文可以見到的，在這一實(shí)施例中，部件名具有以下特征
●部件名類似于傳統(tǒng)文件系統(tǒng)中的文件名。
●部件名以正斜杠(“/”)開始。
●與文件系統(tǒng)中的路徑或URI中的路徑一樣，部件名可以按照一組類似目錄的名字(在以上示例中，為tickets、images/march)被組織成分層結(jié)構(gòu)。
●該分層結(jié)構(gòu)包括由正斜杠定界的段。
●名字的最后一段類似于傳統(tǒng)文件系統(tǒng)中的文件名。
重要的是注意，用于命名部件的規(guī)則，尤其是可用于部件名的有效字符，對(duì)本文檔中描述的框架是專用的。這些部件名規(guī)則基于互聯(lián)網(wǎng)標(biāo)準(zhǔn)的URI命名規(guī)則。依照本實(shí)施例，本實(shí)施例中用于指定部件名的語(yǔ)法完全與RFC 2396，同一資源標(biāo)識(shí)符(URI類屬句法)規(guī)范的5(相關(guān)URI引用)和節(jié)3.3(路徑成分)中定義的abs_path句法相匹配。
以下附加約束被應(yīng)用到abs_path，作為有效的部件名
●如節(jié)3(URI句法分量)和3.4(查詢分量)中定義的查詢分量不適用于部件名。
●如節(jié)4.1(分段標(biāo)識(shí)符)中描述的分段標(biāo)識(shí)符不適應(yīng)于部件名。
●任一部件具有通過(guò)向現(xiàn)有部件的部件名追加*(“/”分段)來(lái)創(chuàng)建的名字是不合法的。
部件名的語(yǔ)法示出如下part_name ="/"segment*("/"segment)segment =*pcharpchar =unreserved|escaped|
":"|"@"|"&"|"="|"+"|"$"|"′"unreserved=alphanum|mark
escaped ="%"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é)點(diǎn)是文件夾，而葉節(jié)點(diǎn)是包含內(nèi)容的實(shí)際文件。名字樹中這些類似文件夾的節(jié)點(diǎn)(即，非葉節(jié)點(diǎn))服務(wù)組織包中的部件的類似功能。然而，重要的是記住，這些“文件夾”僅作為命名分層結(jié)構(gòu)中的概念而存在-它們沒有持久格式的其它表現(xiàn)。
部件名不能在“文件夾”級(jí)存活。具體地，部件命名分層結(jié)構(gòu)中的非葉節(jié)點(diǎn)(“文件夾”)不能包含具有相同名字的部件和子文件夾。
在所述并描述的實(shí)施例中，每一部件具有內(nèi)容類型，它定義了什么類型的內(nèi)容儲(chǔ)存在部件中。內(nèi)容類型的示例包括
image/jpeg
text/xml
text/plain;charset="us-ascii"
內(nèi)容類型在RFC 2045(多用途互聯(lián)網(wǎng)郵件擴(kuò)展；(MIME))中定義的所示的框架中使用。具體地，每一內(nèi)容類型包括媒體類型(例如，text(文本))、子類型(例如，plain(純文本))以及關(guān)鍵字＝值形式的可任選參數(shù)集(例如，charset＝"us-ascii")；多個(gè)參數(shù)由分號(hào)分隔。
部件定址
通常部件包含到其它部件的引用。作為一個(gè)簡(jiǎn)單的示例，想象具有兩個(gè)部件的容器標(biāo)記文件和圖像。標(biāo)記文件希望容納對(duì)圖像的引用，使得當(dāng)處理標(biāo)記文件時(shí)，可識(shí)別和定位關(guān)聯(lián)的圖像。內(nèi)容類型和XML模式的設(shè)計(jì)者可使用URI來(lái)表示這些引用。為使其成為可能，需要定義部件名的領(lǐng)域和URI領(lǐng)域之間的映射。
為允許在包內(nèi)使用URI，當(dāng)評(píng)估基于包的內(nèi)容中的URI時(shí)，必須使用特殊的URI解釋規(guī)則包本身應(yīng)當(dāng)作為URI引用的“作者”來(lái)處理，而URI的路徑分量用于導(dǎo)航包內(nèi)的部件名分層結(jié)構(gòu)。
例如，給定包URI http://www.example.com/foo/something.package，將對(duì)/abc/bar.xml的引用解釋為意味著名為/abc/bar.xml的部件，而非URIhttp://www.example.com/abc/bar.xml。
當(dāng)必須具有從容器中的一個(gè)部件到另一個(gè)部件的引用時(shí)，應(yīng)當(dāng)使用相對(duì)URI。使用相對(duì)引用允許將容器的內(nèi)容一起移動(dòng)到不同的容器(或移動(dòng)到來(lái)自例如文件系統(tǒng)的容器)，而不修改部件間的引用。
來(lái)自部件的相對(duì)引用相對(duì)于包含該引用的部件的“基礎(chǔ)URI”來(lái)解釋。默認(rèn)地，部件的基礎(chǔ)URI是部件的名字。
考慮包括具有以下名字的部件的容器
/markup/page.xml
/image/picture.jpeg
/images/other_picture.jpeg
如果“markup/page.xml”部件包含對(duì)“../images/picture.jpeg”的引用，則依照上述規(guī)則，該引用必須被解釋為涉及部件名“/images/picture.jpeg”。
某些內(nèi)容類型提供了通過(guò)指定內(nèi)容中的不同基礎(chǔ)來(lái)覆蓋默認(rèn)基礎(chǔ)URI的方法。當(dāng)存在這些覆蓋之一時(shí)，應(yīng)當(dāng)使用明確指定的基礎(chǔ)URI而非默認(rèn)的基礎(chǔ)URI。
有時(shí)候，“地址”部件中的一部分或特定的點(diǎn)是有用的。在URI領(lǐng)域中，使用了分段標(biāo)識(shí)符[見例如RFC2396]。在容器中，該機(jī)制以同樣的方式工作。具體地，分段是包含定址的部分的內(nèi)容類型的背景中理解的額外信息的串。例如，在視頻文件中，分段可標(biāo)識(shí)幀，在XML文件中，它可通過(guò)xpath標(biāo)識(shí)XML文件的一部分。
分段標(biāo)識(shí)符結(jié)合定址部件的URI一起使用，來(lái)標(biāo)識(shí)定址的部件的分段。分段標(biāo)識(shí)符是可任選的，并且用交叉線(“#”)字符與URI分離。由此，它不是URI的一部分，但是通常結(jié)合URI一起使用。
以下描述提供了部件命名的某些指導(dǎo)，因?yàn)榘筒考Ｐ褪窍喈?dāng)靈活的。該靈活性允許框架包的各種各樣應(yīng)用。然而，重要的是認(rèn)識(shí)到，框架被設(shè)計(jì)成啟用了其中多個(gè)不相關(guān)軟件系統(tǒng)可操作“其自己的”包部件而不會(huì)彼此抵觸的情形。為允許這一情形，提供了某些方針，如果遵循這些方針，這種情形將成為可能。
此處給出的方針描述了用于最小化或至少減少部件命名沖突的出現(xiàn)，并在它們的確出現(xiàn)時(shí)處理它們的機(jī)制。創(chuàng)建包內(nèi)的部件的書寫者必須采取措施來(lái)檢測(cè)并處理與包中現(xiàn)有部件的命名沖突。在發(fā)生命名沖突的情況下，書寫者可能無(wú)法盲目地替換現(xiàn)有部件。
在保證包由單個(gè)書寫者操縱的情況下，該書寫者可與這些方針偏離。然而，如果有多個(gè)獨(dú)立書寫者共享一個(gè)包的可能性，則所有的書寫者必須遵循這些方針。然而，推薦的是所有的書寫者在任何情況下都遵循這些方針。
●要求將部件添加到現(xiàn)有容器的書寫者在命名分層結(jié)構(gòu)的新“文件夾”中這樣做，而非直接替換根或預(yù)先存在的文件夾中的部件。以此方式，名字沖突的可能性被限于部件名的第一段。在該新文件夾內(nèi)創(chuàng)建的部件可以在沒有與現(xiàn)有部件沖突的風(fēng)險(xiǎn)的情況下來(lái)命名。
●在文件夾的“較佳”名字已經(jīng)被現(xiàn)有部件使用的情況下，書寫者必須采用某一策略來(lái)選擇替換文件夾名字。書寫者應(yīng)當(dāng)使用向較佳名字追加數(shù)字直到找到可用文件夾名的策略(可能在幾次不成功迭代之后采用GUID)。
●這一政策的一個(gè)結(jié)果是閱讀者不許試圖通過(guò)“魔法”或“公知”的部件名來(lái)定位部件。相反，書寫者必須創(chuàng)建與它們所創(chuàng)建的每一文件夾中的至少一個(gè)部件的包關(guān)系。閱讀者必須使用這些包關(guān)系來(lái)定位部件而非依賴于公知的名字。
●一旦閱讀者找到了文件夾中的至少一個(gè)部件(通過(guò)上述包關(guān)系之一)，則它可使用關(guān)于該文件夾內(nèi)的公知部件名的約定來(lái)找到其它部件。
驅(qū)動(dòng)程序
此處描述的文件格式可以由不同的應(yīng)用程序、不同的文檔類型等來(lái)使用-它們中的許多具有沖突的用途、沖突的格式等等。使用了一個(gè)或多個(gè)驅(qū)動(dòng)程序來(lái)分解各種沖突，例如文件格式中的差異、通信協(xié)議中的差異等等。例如，不同的文件格式包括松散文件和復(fù)合文件，而不同的通信協(xié)議包括http、網(wǎng)絡(luò)和無(wú)線協(xié)議。一組驅(qū)動(dòng)程序?qū)⒏鞣N文件格式和通信協(xié)議抽象成單個(gè)模型。可提供多個(gè)驅(qū)動(dòng)程序用于不同的情形、不同的消費(fèi)者要求、不同的物理配置等等。
關(guān)系
包中的部件可包含對(duì)該包中的其它部件的引用。然而，一般而言，這些引用以對(duì)該部件的內(nèi)容類型專用的方式在引用部件內(nèi)表示；即，以任意的標(biāo)記或應(yīng)用程序?qū)Ｓ镁幋a。這有效地隱藏了來(lái)自不理解包含這些引用的部件的內(nèi)容類型的閱讀者的部件之間的內(nèi)部聯(lián)接。
即使對(duì)于公用內(nèi)容類型(如到達(dá)包一節(jié)中描述的固定有效負(fù)載標(biāo)記)，閱讀者需要對(duì)部件中的所有內(nèi)容進(jìn)行語(yǔ)法分析，以發(fā)現(xiàn)并解析對(duì)其它部件的引用。例如，當(dāng)實(shí)現(xiàn)一次打印文檔的一頁(yè)的打印系統(tǒng)時(shí)，可能期望識(shí)別包含在特定頁(yè)面中的圖片和字體?，F(xiàn)有的系統(tǒng)必須對(duì)每一頁(yè)的所有信息進(jìn)行語(yǔ)法分析，這是耗時(shí)的，而且必須理解每一頁(yè)的語(yǔ)言，這不是某些設(shè)備或閱讀者的情況(例如，當(dāng)在去設(shè)備的途中通過(guò)處理器管線在文檔上執(zhí)行中間處理的設(shè)備或閱讀者)。相反，此處描述的系統(tǒng)和方法使用了關(guān)系來(lái)識(shí)別部件之間的關(guān)系，并描述那些關(guān)系的特性。關(guān)系語(yǔ)言是簡(jiǎn)單的，并被定義一次，使得閱讀者可以理解關(guān)系，而無(wú)需多個(gè)不同語(yǔ)言的知識(shí)。在一個(gè)實(shí)施例中，關(guān)系以XML表示為個(gè)別的部件。每一部件具有相關(guān)聯(lián)的關(guān)系部件，它包含部件是源的關(guān)系。
例如，電子表格應(yīng)用程序使用這一格式并將不同的電子表格儲(chǔ)存為部件。不知道關(guān)于電子表格語(yǔ)言的應(yīng)用程序仍能夠發(fā)現(xiàn)與電子表格相關(guān)聯(lián)的各種關(guān)系。例如，應(yīng)用程序可發(fā)現(xiàn)電子表格中的圖像以及與電子表格相關(guān)聯(lián)的元數(shù)據(jù)。提供一個(gè)示例關(guān)系模式如下< 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>
該模式定義了兩個(gè)XML元素，一個(gè)被稱為“relationships”，另一個(gè)被稱為“relationship”。“relationship”元素用于描述此處所描述的單個(gè)關(guān)系，并且具有以下屬性(1)“target”，它指示了源部件要關(guān)系到的部件，(2)“name”，它指示了關(guān)系的類型或特性。定義了“relationships”元素以允許它容納零個(gè)或多個(gè)“relationship”元素，并僅用于將這些“relationship”元素搜集在一起成一個(gè)單元。
此處所描述的系統(tǒng)和方法引入了更高級(jí)機(jī)制，以解決稱為“關(guān)系”的問題。關(guān)系提供了表示包中的源部件和目標(biāo)部件之間的連接種類的額外方法。關(guān)系令部件之間的連接可以被直接“發(fā)現(xiàn)”，而不需要查看部件中的內(nèi)容，因此，它們獨(dú)立于內(nèi)容專用模式，并且能夠更快地被解析。另外，這些關(guān)系是協(xié)議無(wú)關(guān)的。各種不同的關(guān)系可以與特定的部件相關(guān)聯(lián)。
關(guān)系提供了第二個(gè)重要的功能允許部件相關(guān)而不需要修改它們。有時(shí)候，這一信息擔(dān)當(dāng)“注釋”的形式，其中，“注釋的”部件的內(nèi)容類型不定義附加給定信息的方法。潛在的示例包括附加的描述性元數(shù)據(jù)、打印票據(jù)和真實(shí)注釋。最后，某些情況要求信息被特別地附加到現(xiàn)有的部件而不修改該部件-例如，當(dāng)部件被加密并且不能被解密，或者當(dāng)部件被數(shù)字地簽署并且改變它將使簽名無(wú)效時(shí)。在另一示例中，用戶可能希望將注釋附加到JPEG圖像文件。JPEG圖像格式當(dāng)前不提供對(duì)識(shí)別注釋的支持。改變JPEG格式以容納這一用戶需求是不實(shí)際的。然而，此處討論的系統(tǒng)和方法允許用戶向JPEG文件提供注釋而不修改JPEG圖像格式。
在一個(gè)實(shí)施例中，使用關(guān)系部件中的XML來(lái)表示關(guān)系。容器中作為一個(gè)或多個(gè)關(guān)系的源的每一部件具有相關(guān)聯(lián)的關(guān)系部件。該關(guān)系部件容納(使用內(nèi)容類型application/PLACEHOLDER(應(yīng)用程序/占位符)以XML表達(dá))用于該源部件的關(guān)系列表。
下文圖4示出了環(huán)境400，其中“骨架(spine)”部件402(類似于固定面板)將三個(gè)頁(yè)面406、408和410綁定在一起。由骨架綁定在一起的該組頁(yè)面具有相關(guān)聯(lián)的“打印票據(jù)”404。另外，頁(yè)面2具有其自己的打印票據(jù)412。從骨架部件402到其打印票據(jù)404的連接以及從頁(yè)面2到其打印票據(jù)412的連接使用關(guān)系來(lái)表示。在圖4的排列中，骨架部件402具有相關(guān)聯(lián)的關(guān)系部件，它包含將骨架連接到票據(jù)1的關(guān)系，在以下示例中示出。<Relationships xmlns=”http://mmcfrels-PLACEHOLDER”>
<Relationship
Target=”../tickets/ticket1.xml”
Name=”http://mmcf-printing-ticket/PLACEHOLDER”/></Relationships>
關(guān)系使用單個(gè)<Relationships>元素中嵌套的<Relationship>元素來(lái)表示。這些元素在http://mmcfrels(PLACEHOLDER)名字空間中定義。見上文的示例模式，以及下文對(duì)示例關(guān)系的相關(guān)討論。
關(guān)系元素具有以下附加屬性
名字屬性不必要是實(shí)際的地址。不同類型的關(guān)系按其名字來(lái)標(biāo)識(shí)。這些名字以對(duì)XML名字空間定義名字空間的同一方式來(lái)定義。具體地，通過(guò)使用模仿因特網(wǎng)域名空間的名字，非協(xié)調(diào)方可安全地創(chuàng)建不沖突的關(guān)系名字-正如它們可以對(duì)XML名字空間所做的一樣。
不允許關(guān)系部件參與其它關(guān)系。然而，在所有其它意義上它是第一類部件(例如，它是可URI定址的、它可以被打開、讀取、刪除等等)。關(guān)系通常不指向包外部的內(nèi)容。用于標(biāo)識(shí)關(guān)系目標(biāo)的URI一般不包括URI模式。
部件及其相關(guān)聯(lián)的關(guān)系部件通過(guò)命名約定來(lái)連接。在這一示例中，骨架的關(guān)系部件將儲(chǔ)存在/content/_rels/spine.xml.rels中，而頁(yè)面2的關(guān)系將儲(chǔ)存在/content/_rels/p2.xml.rels中。注意，此處使用了兩個(gè)特殊的命名約定。首先，某些名字分層結(jié)構(gòu)中給定“文件夾”中的(其它)部件的關(guān)系部件儲(chǔ)存在名為_rels的“子文件夾”中(以標(biāo)識(shí)關(guān)系)。其次，這一關(guān)系容納部件的名字通過(guò)向原始部件的名字追加.rels擴(kuò)展名來(lái)形成。在特定的實(shí)施例中，關(guān)系部件是內(nèi)容類型application/xml+relationshipsPLACEHOLDER(應(yīng)用程序/xml+關(guān)系占位符)。
關(guān)系表示了兩個(gè)部件之間的有向連接。由于表示關(guān)系的方式，從其源部件開始遍歷關(guān)系是有效的(因?yàn)檎页鋈魏谓o定部件的關(guān)系部件是平凡的)。然而，從關(guān)系的目標(biāo)開始反向遍歷關(guān)系不是有效的(因?yàn)檎页鰧?duì)部件的所有關(guān)系的方法是瀏覽容器中的所有關(guān)系)。
為使關(guān)系的反向遍歷成為可能，使用了新關(guān)系來(lái)表示其它(可遍歷)方向。這是關(guān)系類型的設(shè)計(jì)者可以使用的一種建模技術(shù)。繼續(xù)以上示例，如果重要的是能夠找出附加了票據(jù)1的骨架，則將使用從票據(jù)連接到骨架的第二關(guān)系，如
在content/_rels/p1.xml.rels中
<Relationships xmlns=”http://mmcfrels-PLACEHOLDER”>
<Relationship
Target=”/content/spine.xml”
Name=”http://mmcf-printing-spine/PLACEHOLDER”/>
</Relationships>
包關(guān)系
“包關(guān)系”用于找出包中公知的部件。該方法避免了依賴于用于找出包中的部件的命名約定，并確保了在不同有效負(fù)載中的相同部件名之間沒有抵觸。
包關(guān)系是一種特殊的關(guān)系，其目標(biāo)是部件，而源不是部件源是整個(gè)包。具有“公知”的部件實(shí)際上是具有有助于找出該部件的“公知”關(guān)系名字。這能夠起作用，因?yàn)橛卸x良好的機(jī)制以允許由非協(xié)調(diào)方來(lái)命名關(guān)系，而某些實(shí)施例不包含這樣的部件名機(jī)制-那些實(shí)施例被限于一組方針。包關(guān)系在包關(guān)系部件中找到，并且使用關(guān)系部件的標(biāo)準(zhǔn)命名約定來(lái)命名。由此，它被命名為“/rels/.rels”。
該包關(guān)系中的關(guān)系部件在找出公知部件時(shí)是有用的。
起始部件
包級(jí)的公知部件的一個(gè)示例是包“起始”部件。這是通常在打開包時(shí)被處理的部件。它表示了儲(chǔ)存在包內(nèi)的文檔內(nèi)容的邏輯根。包的起始部件通過(guò)以下公知包關(guān)系來(lái)定位。在一個(gè)示例中，該關(guān)系具有以下名字http://mccf-start-part-PLACEHOLDER。
排版部件選擇器和序列
所描述的框架定義了用于從部件構(gòu)建更高階結(jié)構(gòu)的兩種機(jī)制選擇器和序列。
選擇器是在多個(gè)其它部件之間“選擇”的部件。例如，選擇器部件可以在表示文檔的英語(yǔ)版本的部件和表示文檔的法語(yǔ)版本的部件之間“選擇”。序列是對(duì)多個(gè)其它部件“定序”的部件。例如，序列部件可以組合兩個(gè)部件(成一個(gè)線性序列)，其中一個(gè)表示五頁(yè)文檔，而另一個(gè)表示十頁(yè)文檔。
這兩種類型的排版部件(序列和選擇器)以及用于匯編它們的規(guī)則構(gòu)成了組成模型。排版部件可組成其它排版部件，因此例如，可具有在兩個(gè)組成部分之間進(jìn)行選擇的選擇器。作為一個(gè)示例，考慮圖5，它示出了包含英語(yǔ)表示和法語(yǔ)表示的財(cái)務(wù)報(bào)表的一個(gè)示例。這些表示的每一個(gè)進(jìn)一步包括介紹(封面)以及其后的財(cái)務(wù)(電子表格)。在這一示例中，選擇器500在報(bào)表的英語(yǔ)和法語(yǔ)表示之間進(jìn)行選擇。如果選擇了英語(yǔ)表示，則序列502將英語(yǔ)介紹部件506與英語(yǔ)財(cái)務(wù)部件508定序。或者，如果選擇了法語(yǔ)部分，則序列504將法語(yǔ)介紹部件510與法語(yǔ)財(cái)務(wù)部件512定序。
排版部件XML
在所述并描述的實(shí)施例中，排版部件是使用少數(shù)XML元素來(lái)描述的，它們都取自公用的組成部分名字空間。作為一個(gè)示例，考慮下列
元素<selection>
屬性無(wú)
允許的子元素<item>
元素<sequence>
屬性無(wú)
允許的子元素<item>
元素<item>
屬性Target-組成部分中的部件的部件名
作為一個(gè)示例，以下是上文圖5的示例的XML
MainDocument.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表示包中的整個(gè)部件，并且根據(jù)“selection”標(biāo)簽，指示了要在由“item”標(biāo)簽封裝的不同項(xiàng)，即“EnglishRollup.xml”和“FrenchRollup.xml”之間作出選擇。
根據(jù)“sequence”標(biāo)簽，EnglishRollup.xml和FrenchRollup.xml是將由其各自的“item”標(biāo)簽封裝的各自的項(xiàng)定序在一起的序列。
由此，提供了簡(jiǎn)單的XML語(yǔ)法來(lái)描述選擇器和序列。這一組成塊中的每一部件被構(gòu)建，并執(zhí)行一個(gè)操作-選擇或定序。通過(guò)使用部件的分層結(jié)構(gòu)，可構(gòu)建選擇和序列的不同健壯集合。
組成塊
包的組成塊包括可從包的起始部件到達(dá)的所有排版部件(選擇器或序列)的集合。如果包的起始部件既非選擇器又非序列，則認(rèn)為該組成塊為空。如果起始部件是排版部件，則遞歸地遍歷那些排版部件中的子<item>，以產(chǎn)生排版部件的有向非循環(huán)圖(當(dāng)遇到非排版部件時(shí)停止遍歷)。該圖是組成塊(依照本發(fā)明，它必須是非循環(huán)的，以使包有效)。
確定組成部分語(yǔ)義
建立了上述相對(duì)直接的XML語(yǔ)法之后，以下討論描述了表示信息使得可基于內(nèi)容類型作出選擇的方法。即，上述XML提供了足夠的信息，以允許閱讀者定位被匯編成一個(gè)組成部分的部件，但是未提供足夠的信息來(lái)幫助閱讀者知道關(guān)于組成部分的特性的更多信息。例如，給定組成兩個(gè)部件的選擇，閱讀者如何知道基于什么基準(zhǔn)(例如，語(yǔ)言、紙張大小等)來(lái)作出選擇？答復(fù)是這些規(guī)則與排版部件的內(nèi)容類型相關(guān)聯(lián)。由此，用于基于語(yǔ)言在表示之間進(jìn)行選取的選擇器部件具有與基于紙張大小在表示之間進(jìn)行選取的選擇器部件不同的關(guān)聯(lián)內(nèi)容類型。
通用框架為這些內(nèi)容類型定義了通用形式
Application/XML+Selector-SOMETHING(應(yīng)用程序/XML+選擇器-某一內(nèi)容)
Application/XML+Sequence-SOMETHING(應(yīng)用程序/XML+序列-某一內(nèi)容)
這些內(nèi)容類型中的SOMETHING由指示選擇或序列的特性的詞來(lái)替換，例如，頁(yè)面大小、顏色、語(yǔ)言、閱讀者設(shè)備上的常駐軟件等等。因此，在此框架中，可發(fā)明所有種類的選擇器和序列，并且每一個(gè)可具有非常不同的語(yǔ)義。
描述的框架也定義了以下所有閱讀者或閱讀設(shè)備必須理解的選擇器和序列的公知內(nèi)容類型。
作為一個(gè)示例，考慮如下。假定包包含具有頁(yè)面的文件，并且在頁(yè)面的中間有要出現(xiàn)視頻的區(qū)域。在此示例中，頁(yè)面的視頻部件可包括Quicktime視頻形式的視頻。這一情形的一個(gè)問題是Quicktime視頻不是被普遍理解的。然而，假定依照本框架，尤其是下文描述的到達(dá)包格式，存在被普遍理解的圖像格式-JPEG。當(dāng)產(chǎn)生包含上述文檔的包時(shí)，除將視頻定義為包的部件之外，生產(chǎn)者還為頁(yè)面定義了JPEG圖像，并提出了一種SupportedContentType(支持的內(nèi)容類型)選擇器，使得如果用戶的計(jì)算機(jī)具有理解Quicktime視頻的軟件，則選擇Quicktime視頻，否則選擇JPEG圖像。
由此，如上所述，框架級(jí)選擇器和序列組件允許構(gòu)建健壯的分層結(jié)構(gòu)，在此示例中，它是以XML定義的。另外，存在定義明確的方法，確定使用內(nèi)容類型時(shí)選擇器和序列的行為。另外，依照一個(gè)實(shí)施例，通用框架包括一個(gè)特定的內(nèi)容類型，它是預(yù)定義的，并允許基于消費(fèi)者(例如，閱讀者或閱讀設(shè)備)理解什么和不理解什么來(lái)處理和使用包。
可使用類似的規(guī)則定義其它排版部件內(nèi)容類型，其示例在下文描述。
描述性元數(shù)據(jù)
依照一個(gè)實(shí)施例，描述性元數(shù)據(jù)部件向包的書寫者或生產(chǎn)者提供了儲(chǔ)存屬性值的方法，它使包的閱讀者能夠可靠地發(fā)現(xiàn)該值。這些屬性通常用于記錄關(guān)于整個(gè)包以及容器內(nèi)的個(gè)別部件的附加信息。例如，包內(nèi)的描述性元數(shù)據(jù)部件可容納諸如包作者、關(guān)鍵字、概要等的信息。
在所示并描述的實(shí)施例中，描述性元數(shù)據(jù)以XML來(lái)表達(dá)、被儲(chǔ)存在公知內(nèi)容類型的部件中、并可使用公知關(guān)系類型來(lái)找到。
描述性元數(shù)據(jù)容納元數(shù)據(jù)屬性。元數(shù)據(jù)屬性由屬性名和一個(gè)或多個(gè)屬性值來(lái)表示。屬性值具有簡(jiǎn)單的數(shù)據(jù)類型，因此每一數(shù)據(jù)類型由單個(gè)XML qname來(lái)描述。描述性元數(shù)據(jù)屬性具有簡(jiǎn)單類型的事實(shí)并不意味著不能在包內(nèi)用復(fù)雜的XML類型來(lái)儲(chǔ)存數(shù)據(jù)。在這一情況下，必須將信息作為完整的XML部件來(lái)儲(chǔ)存。當(dāng)完成時(shí)，刪除關(guān)于僅使用簡(jiǎn)單類型的所有約束，但是“平面”描述性元數(shù)據(jù)屬性模型的簡(jiǎn)單性丟失。
除用于定義屬性集的通用機(jī)制以外，有一種特定的、定義良好的、使用該機(jī)制儲(chǔ)存的文檔核心屬性集。這些文檔核心屬性通常用于描述文檔，并包括如標(biāo)題、關(guān)鍵字、作者等的屬性。
最后，容納這些文檔核心屬性的元數(shù)據(jù)部件也可容納除文檔核心屬性之外的附加、用戶定義的屬性。
元數(shù)據(jù)格式
依照本發(fā)明，描述性元數(shù)據(jù)具有內(nèi)容類型，并且依照以下規(guī)則的關(guān)系達(dá)到目標(biāo)
以下XML模式用于依照一個(gè)實(shí)施例表現(xiàn)描述性元數(shù)據(jù)。關(guān)于標(biāo)記的每一分量的細(xì)節(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="daratype"
mcs:multivalued="true|false">
<mcs:value>...value...</mcs:value>
</mcs:property></mcs:properties>
文檔核心屬性
以下是包括屬性名、屬性類型和描述的文檔核心屬性的表格。
物理模型
物理模型定義了書寫者和閱讀者使用包的各種方法。該模型基于三個(gè)組件書寫者、閱讀器以及它們之間的管道。圖6示出了共同工作以交流包的書寫者和閱讀者的某一示例。
管道將數(shù)據(jù)從書寫者傳送到閱讀者。在許多情況下，管道可以僅包括閱讀者作出的從本地文件系統(tǒng)讀取包的API調(diào)用。這被稱為直接訪問。
然而，通常閱讀者和書寫者必須通過(guò)某一類型的協(xié)議彼此通信。例如，這一通信可跨進(jìn)程邊界或在服務(wù)器和臺(tái)式計(jì)算機(jī)之間發(fā)生。這被稱為聯(lián)網(wǎng)訪問，并且由于管道的通信特征(尤其是速度和請(qǐng)求等待時(shí)間)，它是重要的。
為允許最大的性能。物理包設(shè)計(jì)必須考慮三個(gè)重要領(lǐng)域內(nèi)的支持訪問樣式、布局樣式和通信樣式。
訪問樣式
流式消耗
由于書寫者和閱讀者之間使用聯(lián)網(wǎng)訪問的通信不是瞬時(shí)的，因此重要的是允許包的漸進(jìn)創(chuàng)建和消耗。具體地，依照本實(shí)施例，推薦任何物理包格式被設(shè)計(jì)成允許閱讀者在包的所有比特通過(guò)管道傳送之前，當(dāng)它接收到的數(shù)據(jù)(例如，部件)時(shí)開始解釋并處理該數(shù)據(jù)。這一能力被成為流消耗。
流式創(chuàng)建
當(dāng)書寫者開始創(chuàng)建包時(shí)，它并不總是知道它將會(huì)在包中放入什么。作為一個(gè)示例，當(dāng)應(yīng)用程序開始構(gòu)建打印池文件包時(shí)，它可能不知道有多少頁(yè)需要被放入包中。作為另一示例，服務(wù)器上動(dòng)態(tài)生成報(bào)表的程序可能無(wú)法認(rèn)識(shí)到該報(bào)表有多長(zhǎng)，或者報(bào)表具有多少圖片一直到它完全生成了該報(bào)表。為允許這類書寫者，物理包應(yīng)當(dāng)允許書寫者在已經(jīng)添加了其它部件之后動(dòng)態(tài)地添加部件(例如，書寫者必須不被要求在開始書寫時(shí)預(yù)先規(guī)定它將創(chuàng)建多少部件)。另外，物理包應(yīng)當(dāng)允許書寫者在不知道該部件的最終長(zhǎng)度的情況下開始書寫部件的內(nèi)容。這些要求共同啟用了流式創(chuàng)建。
同時(shí)創(chuàng)建和消耗
在高管線化的體系結(jié)構(gòu)中，流式創(chuàng)建和流式消耗可對(duì)特定的包同時(shí)發(fā)生。當(dāng)設(shè)計(jì)物理包時(shí)，支持流式創(chuàng)建和支持流式消耗可在相反的方向推動(dòng)設(shè)計(jì)。然而，找出支持兩者的設(shè)計(jì)通常是可能的。由于管線化體系結(jié)構(gòu)中的好處，推薦物理包支持同時(shí)創(chuàng)建和消耗。
布局樣式
物理包容納部件的集合。這些部件可以用兩種樣式之一來(lái)布局簡(jiǎn)單排序和交錯(cuò)。采用簡(jiǎn)單排序，包內(nèi)的部件用定義的排序來(lái)布局。當(dāng)以純線性方式傳送這樣的包時(shí)，從包內(nèi)的第一字節(jié)開始直到最后一個(gè)字節(jié)，第一部件的所有字節(jié)首先到達(dá)，然后第二部件的所有字節(jié)到達(dá)，依此類推。
采用交錯(cuò)布局，多個(gè)部件的字節(jié)是交錯(cuò)的，這在某些情況下允許改進(jìn)的性能。從交錯(cuò)中顯著獲益的兩個(gè)情況是多媒體回放(例如，同時(shí)傳送視頻和音頻)和內(nèi)嵌資源引用(例如，標(biāo)記文件的中間對(duì)圖像的引用)。
交錯(cuò)通過(guò)用于組織交錯(cuò)部件的內(nèi)容的特殊約定來(lái)處理。通過(guò)將部件分割成片段并交錯(cuò)這些片段，可能達(dá)到期望的交錯(cuò)結(jié)果，同時(shí)仍可能容易地重建原始的較大部件。為理解交錯(cuò)是如何工作的，圖7示出了涉及兩個(gè)部件的簡(jiǎn)單示例content.xml702和image.jpeg 704。第一部件content.xml描述了頁(yè)的內(nèi)容，并且在該頁(yè)的中間是對(duì)應(yīng)當(dāng)出現(xiàn)在該頁(yè)上的圖像(image.jpeg)的引用。
為理解交錯(cuò)為何是有價(jià)值的，考慮如何使用簡(jiǎn)單排序在包內(nèi)排列這些部件，如圖8所示。處理該包(并且順序地接收字節(jié))的閱讀者在接收到所有的content.xml部件以及image.jpeg之前將無(wú)法顯示圖片。在某些情況下(例如，小或簡(jiǎn)單的包，或快速通信鏈路)這可能不是問題。在其它情況下(例如，如果content.xml非常大或者通信鏈路非常慢)，則需要讀完所有的content.xml部件來(lái)獲得圖像將導(dǎo)致不可接受的性能或?qū)﹂喿x者系統(tǒng)施加不合理的存儲(chǔ)器需求。
為更接近理想的性能，能夠分割content.xml部件并將image.jpeg部件插入到中間，緊接著引用圖片之處將是較佳的。這允許閱讀者更早地開始處理圖像一旦它遇到引用，圖像數(shù)據(jù)就在后面。例如，這將產(chǎn)生圖9所示的包布局。由于性能利益，通常期望物理包支持交錯(cuò)。根據(jù)使用的物理包的類型，可以支持或不支持交錯(cuò)。不同的物理包可不同地處理交錯(cuò)的內(nèi)部表示。不管物理包如何處理交錯(cuò)，重要的是記住，交錯(cuò)是在物理層上出現(xiàn)的優(yōu)化，并且被分割成物理文件中的多個(gè)片段的部件仍是一個(gè)邏輯部件；片段本身不是部件。
通信樣式
書寫者和閱讀者之間的通信可以基于部件的順序傳送或按對(duì)部件的隨機(jī)訪問來(lái)進(jìn)行，從而允許它們不按順序來(lái)訪問。使用這些通信樣式的哪一個(gè)取決于管道和物理包格式的能力。一般而言，所有的管道支持順序傳送。物理包必須支持順序傳送。為支持隨機(jī)訪問情形，使用的管道和物理包都必須支持隨機(jī)訪問。某些管道基于允許隨機(jī)訪問的協(xié)議(例如，具有字節(jié)范圍支持的HTTP 1.1)。為在使用這些管道時(shí)允許最大性能，推薦物理包支持隨機(jī)訪問。在缺少這一支持的情況下，閱讀者將簡(jiǎn)單地等待，直到它們需要的部件被順序地傳送。
物理映射
邏輯包裝模型定義了包抽象；包的實(shí)際示例基于包的某一特定物理表示。包裝模型可以被映射到物理持久格式以及各種傳輸(例如，基于網(wǎng)絡(luò)的協(xié)議)。物理包格式可以被描述為從抽象包裝模型的分量到特定的物理格式特征的映射。包裝模型未指定應(yīng)當(dāng)使用哪些物理包格式來(lái)歸檔、分發(fā)或假脫機(jī)操作包。在一個(gè)實(shí)施例中，僅指定了邏輯結(jié)構(gòu)。包可以由松散文件的集合、.ZIP文件檔案、復(fù)合文件或某一其它格式“物理地”實(shí)施。所選擇的格式由目標(biāo)消耗設(shè)備支持，或由設(shè)備的驅(qū)動(dòng)程序支持。
被映射的分量
每一物理包格式為以下分量定義了映射。某些分量是可任選的，并且特定的物理包格式可能不支持這些可任選的分量。
公用映射模式
存在許多物理存儲(chǔ)格式，其特征部分地與包裝模型分量相匹配。在定義從包裝模型到這類存儲(chǔ)格式的映射時(shí)，可能期望利用包裝模型和物理存儲(chǔ)介質(zhì)之間的任何能力相似性，同時(shí)使用映射的層來(lái)提供物理存儲(chǔ)介質(zhì)中不固有存在的附加能力。例如，某些物理包格式可將個(gè)別的部件儲(chǔ)存為文件系統(tǒng)中的個(gè)別文件。以這一物理格式，將許多部件名直接映射到相同的物理文件名字是自然的。使用不是有效文件系統(tǒng)文件名的字符的部件名可能需要某種類型的轉(zhuǎn)義機(jī)制。
在許多情況下，不同物理包格式的設(shè)計(jì)者可能面對(duì)單個(gè)公共的映射問題。公共映射問題的兩個(gè)示例是在將任意的內(nèi)容類型與部件相關(guān)聯(lián)時(shí)，以及當(dāng)支持交錯(cuò)布局樣式時(shí)產(chǎn)生的。本說(shuō)明書建議了對(duì)這類公共映射問題的公用解決方案。特定物理包格式的設(shè)計(jì)者可以被鼓勵(lì)，但并不要求來(lái)使用此處定義的公用映射解決方案。
標(biāo)識(shí)部件的內(nèi)容類型
物理包格式映射定義了用于儲(chǔ)存每一部件的內(nèi)容類型的機(jī)制。某些物理包格式具有用于表現(xiàn)內(nèi)容類型的本機(jī)機(jī)制(例如，MIME中的“Content-Type”標(biāo)題)。對(duì)于這些物理包，推薦映射使用本機(jī)機(jī)制來(lái)表示部件的內(nèi)容類型。對(duì)于其它物理格式，使用某些其它機(jī)制來(lái)表示內(nèi)容類型。推薦的用于表示這些包中的內(nèi)容類型的機(jī)制是通過(guò)在包內(nèi)包括特別命名的XML流，稱為類型流。該流不是部件，并且因此其本身不是URI可定址的。然而，它可以在物理包內(nèi)使用用于交錯(cuò)部件的相同機(jī)制來(lái)交錯(cuò)。
類型流包含具有頂級(jí)“Types”元素以及一個(gè)或多個(gè)“Default”和“Overide”子元素的XML?！癉efault”元素定義了從部件名擴(kuò)展名到內(nèi)容類型的默認(rèn)映射。這利用了文件擴(kuò)展名通常對(duì)應(yīng)于內(nèi)容類型的事實(shí)?！癘verride”元素用于指定不被默認(rèn)映射覆蓋或不與默認(rèn)映射一致的部件上的內(nèi)容類型。包書寫者可使用“Default”元素來(lái)減少每一部件“Override”元素的數(shù)量，但是不必要如此。
“Default”元素具有以下屬性
“Override”元素具有以下屬性
以下是包含在類型流中的XML的一個(gè)示例<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>
以下表格示出了部件及其由以上類型流定義的對(duì)應(yīng)內(nèi)容類型的示例列表
對(duì)于包內(nèi)的每一部件，類型流包含以下的任一個(gè)(a)一個(gè)匹配的“Default”元素，(b)一個(gè)匹配的“Override”元素，或者(c)匹配的“Default”元素和匹配的“Override”元素兩者(在這一情況下，“Override”元素有優(yōu)先級(jí))。一般而言，對(duì)任一給定的擴(kuò)展名，最多有一個(gè)“Default”元素，并且對(duì)任一給定的部件名，最多有一個(gè)“Override”元素。
類型流中“Default”和“Override”元素的順序不是重要的。然而，在交錯(cuò)包中，“Default”和“Override”元素在物理包中出現(xiàn)在它們對(duì)應(yīng)的部件之前。
交錯(cuò)
并非所有的物理包都本機(jī)地支持部件的數(shù)據(jù)流的交錯(cuò)。在一個(gè)實(shí)施例中，到任一這樣的物理包的映射使用了本節(jié)中描述的通用機(jī)制以允許部件的交錯(cuò)。通用機(jī)制通過(guò)將部件的數(shù)據(jù)流分割成可與其它部件的片段或整個(gè)部件交錯(cuò)的多個(gè)片段來(lái)工作。部件的個(gè)別片段在物理映射中存在，并且在邏輯包裝模型中不是可定址的。分段可具有零長(zhǎng)度。
定義了以下從部件名到部件的個(gè)別片段的名字的唯一映射，使得閱讀者可以按其原始的順序?qū)⑵慰p合在一起以形成部件的數(shù)據(jù)流。
用于導(dǎo)出給定部件名的片段名的語(yǔ)法
piece_name=part_name"/""["1*digit"]"[".last"]".piece"
以下有效性約束對(duì)由該語(yǔ)法生成的piece_names存在
●片段號(hào)以0開始，并且是正的、連續(xù)的整數(shù)。片段號(hào)可以被左零填充(left-zero-padded)。
●部件的片段集的最后一個(gè)片段包含片段名中“.piece”之前的“.last”。
●片段名在映射到物理包中的名字之前從邏輯部件的名字生成。
盡管不必要以其自然順序儲(chǔ)存片段，但是這樣的存儲(chǔ)可提供優(yōu)化的效率。包含交錯(cuò)(分段)的部件的物理包也可包含非交錯(cuò)(單片段)部件，因此以下示例是有效的
spine.xaml/
.piece
pages/page0.xaml
spine.xaml/[1].piece
pages/pagel.xaml
spine.xaml/[2].last.piece
pages/page2.xaml
特定映射
下文定義了對(duì)以下物理格式的特定映射Windows文件系統(tǒng)中的松散文件。
到Windows文件系統(tǒng)中的松散文件的映射
為更好地理解如何將邏輯模型的元素映射到物理格式，考慮將Metro包表示為Windows文件系統(tǒng)中的松散文件的集合的基本情況。邏輯包中的每一部件將包含在單獨(dú)的文件(流)內(nèi)。邏輯模型中的每一部件名對(duì)應(yīng)于文件名。
部件名被轉(zhuǎn)換成有效的Windows文件名，如以下表格中示出的。
下文給出的是兩個(gè)字符集，它們對(duì)于邏輯部件名段(URI段)和Windows文件名是有效的。該表格展示了兩個(gè)重要的內(nèi)容
存在兩個(gè)有效的URI符號(hào)，冒號(hào)()和星號(hào)(*)，在將URI轉(zhuǎn)化成文件名時(shí)需要對(duì)這兩個(gè)符號(hào)轉(zhuǎn)義。
存在有效的文件名符號(hào)^{}[]#，它們不能以URI呈現(xiàn)(它們可用于特殊的映射目的，如交錯(cuò))。
“轉(zhuǎn)義”用作在部件名包含不能在文件名中使用的字符時(shí)產(chǎn)生有效文件名字符的技術(shù)。為對(duì)字符轉(zhuǎn)義，使用了脫字符號(hào)(^)，其后跟隨字符的十六進(jìn)制表示。
為從abs_path(部件名)映射到文件名
首先刪除/
將所有的/轉(zhuǎn)化成\
對(duì)冒號(hào)和星號(hào)字符轉(zhuǎn)義
例如，部件名/a:b/c/d*.xaml變?yōu)橐韵挛募鸻^25b\c\d^2a.xaml。
為執(zhí)行反向映射
將所有的\轉(zhuǎn)化成/
向串的起始添加/
通過(guò)用對(duì)應(yīng)的字符替換^[十六進(jìn)制代碼]對(duì)字符解轉(zhuǎn)義(unescape)
版本化和可擴(kuò)充性
與其它技術(shù)規(guī)范一樣，此處包含的規(guī)范可用未來(lái)的增強(qiáng)來(lái)進(jìn)展。這一規(guī)范的第一版的設(shè)計(jì)包括用于基于第一版書寫的軟件系統(tǒng)以及為未來(lái)版本書寫的軟件系統(tǒng)之間的文檔的未來(lái)互換的計(jì)劃。類似地，該規(guī)范允許第三方創(chuàng)建對(duì)該規(guī)范的擴(kuò)展。這一擴(kuò)展可以例如允許構(gòu)造充分利用某一特定打印機(jī)的特征的文檔，同時(shí)仍維持與不知道該打印機(jī)的存在的其它閱讀者的兼容性。
使用固定有效負(fù)載標(biāo)記的新版本或?qū)?biāo)記的第三方擴(kuò)展的文檔要求閱讀者進(jìn)行關(guān)于行為(例如，如何可視地呈現(xiàn)某些內(nèi)容)的適當(dāng)判斷。為指導(dǎo)閱讀者，文檔的作者(或生成該文檔的工具)應(yīng)當(dāng)為遇到其它未識(shí)別元素或?qū)傩缘拈喿x者標(biāo)識(shí)適當(dāng)?shù)男袨椤?duì)于到達(dá)文檔，這一類型的指導(dǎo)是重要的。
新的打印機(jī)、瀏覽器和其它客戶機(jī)可實(shí)現(xiàn)對(duì)未來(lái)特征的各種支持。利用新版本或擴(kuò)展的文檔作者必須仔細(xì)地考慮不知道那些擴(kuò)展版本的閱讀者的行為。
版本化名字空間
XML標(biāo)記識(shí)別基于名字空間URL。對(duì)于任一XML名字空間，期望閱讀者識(shí)別所有的XML元素以及該名字空間中定義的XML屬性，或不識(shí)別任何東西。如果閱讀者不識(shí)別新的名字空間，則閱讀者需要執(zhí)行文檔中指定的后退呈現(xiàn)操作。
XML名字空間URI“http://PLACEHOLDER/version-control”包括用于構(gòu)造固定有效負(fù)載標(biāo)記的XML元素和屬性，該標(biāo)記是版本自適應(yīng)和擴(kuò)展自適應(yīng)的。固定有效負(fù)載不需要在其中具有版本化元素。然而，為構(gòu)建自適應(yīng)的內(nèi)容，必須使用<ver:Compatibility.Rules>和<ver:AlternativeContent>XML元素的至少一個(gè)。
這一固定有效負(fù)載標(biāo)記規(guī)范具有與其相關(guān)聯(lián)的xmlns URI“http://PLACEHOLDER/pdl”。在固定有效負(fù)載中使用該名字空間將指示閱讀者應(yīng)用程序，僅使用該規(guī)范中定義的元素。該規(guī)范的未來(lái)版本將具有其自己的名字空間。熟悉新名字空間的閱讀者應(yīng)用程序?qū)⒅廊绾沃С窒惹暗陌姹局卸x的元素或?qū)傩缘某?。不熟悉新版本的閱讀者應(yīng)用程序?qū)⑿掳姹镜腢RI考慮成它是對(duì)PDL的某一未知擴(kuò)展的URL一樣。這些應(yīng)用程序可能不知道在名字空間之間存在關(guān)系，即一個(gè)是另一個(gè)的超集。
后向和“前向”兼容性
在支持此處所討論的系統(tǒng)和方法的應(yīng)用程序或設(shè)備的環(huán)境中，兼容性由客戶機(jī)對(duì)使用規(guī)范的先前版本或規(guī)范的未知擴(kuò)展或版本創(chuàng)作的文檔進(jìn)行語(yǔ)法分析和顯示的能力來(lái)指示。各種版本化機(jī)制解決了“后向兼容性”，允許客戶機(jī)的未來(lái)實(shí)現(xiàn)能夠支持基于規(guī)范的下級(jí)版本的文檔，如下文所示出的。
當(dāng)諸如打印機(jī)等已實(shí)現(xiàn)的客戶機(jī)接受到使用標(biāo)記語(yǔ)言的未來(lái)版本構(gòu)建的文檔時(shí)，客戶機(jī)能夠?qū)捎贸尸F(xiàn)選項(xiàng)進(jìn)行語(yǔ)法分析并理解它們。依照規(guī)范的較舊版本書寫的客戶機(jī)軟件使用較新版本特征處理某些文檔的能力通常被稱為“前向兼容性”。被書寫成允許前向兼容性的文檔被描述為“版本自適應(yīng)的”。
此外，由于已實(shí)現(xiàn)的客戶機(jī)也需要能夠支持具有表示新元素或?qū)傩缘奈粗獢U(kuò)展的文檔，因此各種語(yǔ)義支持“擴(kuò)展自適應(yīng)的”文檔的更一般情況。
如果打印機(jī)或察看器遇到未知的擴(kuò)展，它將查找連同擴(kuò)展的使用一起嵌入的信息，以找出關(guān)于自適應(yīng)地呈現(xiàn)環(huán)繞的內(nèi)容的指導(dǎo)。這一自適應(yīng)涉及用理解的內(nèi)容替換未知的元素或?qū)傩?。然而，自適應(yīng)可采用其它形式，包括純忽略未知內(nèi)容。在缺乏明確指導(dǎo)的情況下，閱讀者應(yīng)當(dāng)將標(biāo)記中未識(shí)別的擴(kuò)展的存在視為錯(cuò)誤條件。如果未提供指導(dǎo)，則假定擴(kuò)展對(duì)理解內(nèi)容是基本的。呈現(xiàn)失敗將被捕捉并報(bào)告給用戶。
為支持這一模型，標(biāo)記語(yǔ)言的新的和擴(kuò)展的版本應(yīng)當(dāng)邏輯上組合名字空間中的相關(guān)擴(kuò)展。以此方式，文檔作者能夠使用最少數(shù)量的名字空間來(lái)利用擴(kuò)展的特征。
版本化標(biāo)記
用于支持?jǐn)U展自適應(yīng)行為的XML詞匯包括以下元素
<Compatibility.Rules>元素
Compatibility.Rules可以被附加到可容納附加的屬性的任一元素上，如附加到Xaml根元素上。<Compatibility.Rules>元素控制語(yǔ)法分析器如何對(duì)未知元素或?qū)傩苑磻?yīng)。通常這些項(xiàng)被報(bào)告為錯(cuò)誤。向Compatibility.Rules屬性添加Ignorable元素通知了編譯器來(lái)自某些名字空間的項(xiàng)可被忽略。
Compatibility.Rules可包含元素Ignorable和MustUnderstand。默認(rèn)地，所有的元素和屬性被假定為MustUnderstand。元素和屬性可以通過(guò)將Ignorable元素添加到其容器的Compatibility.Rules屬性中來(lái)變成Ignorable。元素或?qū)傩钥梢酝ㄟ^(guò)將MustUnderstand元素添加到嵌套容器之一再一次變成MustUnderstand。一個(gè)Ignorable或MustUnderstand指同一Compatibility.Rules元素中的特定名字空間URI。
<Compatibility.Rules>元素影響容器的內(nèi)容，而非容器自己的標(biāo)簽或?qū)傩?。為影響容器的?biāo)簽或?qū)傩裕淙萜鞅仨毎嫒菪砸?guī)則。Xaml根元素可用于為將另外成為根元素的元素，如Canvas指定兼容性規(guī)則。Compatibility.Rules復(fù)合屬性是容器中的第一元素。
<Ignorable>元素
<Ignorable>元素聲明了所包含的名字空間URI是可忽略的。如果在當(dāng)前塊或容器塊中在項(xiàng)的前方聲明了<Ignorable>標(biāo)簽，并且名字空間URI對(duì)語(yǔ)法分析器是未知的，則該項(xiàng)可認(rèn)為是可忽略的。如果URI已知，則可不予處理Ignorable標(biāo)簽，并且所有的項(xiàng)都是理解的。在一個(gè)實(shí)施例中，未被明確聲明為Ignorable的所有項(xiàng)必須被理解。Ignorable元素可包含<ProcessContent>和<CarryAlong>元素，它們用于修改如何忽略元素以及向文檔編輯工具給予應(yīng)當(dāng)如何在編輯的文檔中保存這些內(nèi)容的指導(dǎo)。
<ProcessContent>元素
<ProcessContent>元素聲明了如果元素被忽略，則元素的內(nèi)容將如同它由被忽略的元素的容器包含那樣被處理。
<ProcessContent>屬性
<CarryAlong>元素
可任選的<CarryAlong>元素向文檔編輯工具指示當(dāng)修改文檔時(shí)是否應(yīng)當(dāng)保存可忽略的內(nèi)容。編輯工具保存或丟棄可忽略內(nèi)容的方法是在編輯工具的域中。如果多個(gè)<CarryAlong>元素指名字空間中的同一元素或?qū)傩?，則指定的最后一個(gè)<CarryAlong>具有優(yōu)先級(jí)。
<CarryAlong>屬性
<MustUnderstand>元素
<MustUnderstand>是倒轉(zhuǎn)Ingorable元素的效果的元素。例如，當(dāng)與替換內(nèi)容結(jié)合時(shí)，這一技術(shù)是有用的。在<MustUnderstand>元素定義的范圍外，元素保持Ignorable。
<MustUnderstand>屬性
<AlternateContent>元素
<AlternateContent>元素允許如果指定內(nèi)容的任一部分不被理解則提供替換內(nèi)容。AlternateContent塊使用了<Prefer>和<Fallback>塊。如果<Prefer>塊中的任何內(nèi)容不被理解，則使用<Fallback>塊中的內(nèi)容。名字空間被聲明為<MustUnderstand>，以指示要使用后退。如果名字空間被聲明為可忽略并且在<Prefer>塊中使用了該名字空間，則不使用<Fallback>塊中的內(nèi)容。
版本化標(biāo)記示例
使用<Ignorable>
本示例使用了假想的標(biāo)記名字空間http://PLACEHOLDER/Circle，它定義了其初始版本中的元素Circle，并使用了引入到標(biāo)記的未來(lái)版本(版本2)中的Circle的Opacity屬性，以及引入到標(biāo)記的更后版本(版本3)中的Luminance屬性。這一標(biāo)記在版本1和2中，以及3和隨后的版本中保持可加載。另外，<CarryAlong>元素指定了當(dāng)編輯時(shí)，甚至在編輯器不理解v3:Luminance時(shí)，也必須保存v3:Luminance。
對(duì)于版本1閱讀者，忽略O(shè)pacity和Luminance
對(duì)于版本2閱讀者，僅忽略Luminance
對(duì)于版本3及以后的版本的閱讀者，使用所有的屬性。<FixedPanel
xmlns="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:Compatibilitv.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>
以下示例闡明了對(duì)<MustUnderstand>元素的使用。
<FixedPanel
xmlns="http://PLACEHOLDER/fixed-content"
xmlns:v="http://PLACEHODER/vetsioned-content"
xmlns:v1="http://PLACEHODER/Circle/v1"
xmlns:v2="http://PLACEHODER/Circle/v2"
xmlns:v3="http://PLACEHODER/Circle/v3">
<v:Compatibilitv.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:Combatibilitv.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:Opacitv="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>
對(duì)<MustUnderstand>元素的使用導(dǎo)致對(duì)v3:Luminance的引用錯(cuò)誤，即使它在根元素中被聲明為Ignorable。如果與使用例如添加到版本2中的Canvas的Luminance屬性(見下文)的替換內(nèi)容結(jié)合，則這一技術(shù)是有用的。在Canvas元素的范圍外，Circle的Luminance屬性再次是可忽略的。<FixedPanel
xmlns="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ū)傩员宦暶鳛?lt;MustUnderstand>，但是在<AlternateContent>塊的<Prefer>塊中不被理解，則整體跳過(guò)<Prefer>塊，并如常地處理<Fallback>塊(即，遇到的任何MustUnderstand項(xiàng)被報(bào)告為錯(cuò)誤)。<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>
到達(dá)包格式
在以下的討論中，提供了對(duì)特定文件格式的描述。本節(jié)中的各個(gè)初級(jí)小標(biāo)題包括“對(duì)到達(dá)包格式的介紹”、“到達(dá)包結(jié)構(gòu)”、“固定有效負(fù)載部件”、“固定頁(yè)標(biāo)記基礎(chǔ)”、“固定有效負(fù)載元素和屬性”以及“固定頁(yè)標(biāo)記”。每一初級(jí)小標(biāo)題具有一個(gè)或多個(gè)相關(guān)的小標(biāo)題。
對(duì)到達(dá)包格式的介紹
在上文描述了示例性框架之后，以下的描述是使用上述工具提供的特定格式之一。要意識(shí)到和理解，以下描述僅構(gòu)成了一個(gè)示例性格式，并不想要限制要求保護(hù)的本發(fā)明的應(yīng)用。
依照本實(shí)施例，單個(gè)包可包含多個(gè)有效負(fù)載，其每一個(gè)擔(dān)當(dāng)文檔的不同表示。有效負(fù)載是部件的集合，包括可標(biāo)識(shí)的“根”部件和該根部件的有效處理所需的所有部件。例如，有效負(fù)載可以是文檔的固定表示、可重新流動(dòng)的表示或任何任意的表示。
以下描述定義了被稱為“固定有效負(fù)載”的特定表示。固定有效負(fù)載具有包含固定面板標(biāo)記的根部件，它進(jìn)而引用固定頁(yè)部件。這些共同描述了多頁(yè)文檔的精確呈現(xiàn)。
容納至少一個(gè)固定有效負(fù)載，并遵循以下描述的其它規(guī)則的包被稱為到達(dá)包。到達(dá)包的閱讀者和書寫者可基于到達(dá)包格式的規(guī)范實(shí)現(xiàn)其自己的語(yǔ)法分析器和呈現(xiàn)引擎。
到達(dá)包的特征
依照所描述的實(shí)施例，到達(dá)包解決了信息工作者對(duì)分發(fā)、歸檔和呈現(xiàn)文檔的需求。使用已知的呈現(xiàn)規(guī)則，到達(dá)包可以從保存它們的格式中明白且明確地再生或打印，而無(wú)需將客戶機(jī)設(shè)備或應(yīng)用程序綁定到特定的操作系統(tǒng)或服務(wù)庫(kù)。另外，由于到達(dá)有效負(fù)載是以中立的、應(yīng)用程序無(wú)關(guān)的方式來(lái)表達(dá)的，因此文檔通?？梢栽跊]有用于創(chuàng)建該包的應(yīng)用程序的情況下來(lái)察看和打印。為提供這一能力，在到達(dá)包中引入并包含了固定有效負(fù)載的概念。
依照所描述的實(shí)施例，固定有效負(fù)載具有固定數(shù)量的頁(yè)，并且分頁(yè)符總是相同的。固定有效負(fù)載中頁(yè)面上所有元素的布局是預(yù)定的。每一頁(yè)具有固定的大小和方向。由此，不必要在消費(fèi)端上執(zhí)行布局計(jì)算，并且可容易地呈現(xiàn)內(nèi)容。這不僅應(yīng)用到圖形，也應(yīng)用到文本，它在固定有效負(fù)載中用精確的排字布局來(lái)表示。頁(yè)面的內(nèi)容(文本、圖形、圖像)使用更強(qiáng)大但是更簡(jiǎn)單的可視原語(yǔ)集來(lái)描述。
到達(dá)包支持用于組織頁(yè)面的各種機(jī)制。一組頁(yè)面逐個(gè)被“粘合”在一起成“固定面板”。該組頁(yè)面粗略地等效于傳統(tǒng)的多頁(yè)文檔。固定面板然后可進(jìn)一步參與組成一構(gòu)建序列和選擇以匯編“復(fù)合”文檔的過(guò)程。
在所示并描述的實(shí)施例中，到達(dá)包支持一種特定種類的序列，稱為固定面板序列，它可用于例如將一組固定面板粘合在一起成單個(gè)、較大的“文檔”。例如，想像將來(lái)自不同來(lái)源的兩個(gè)文檔粘合在一起一個(gè)兩頁(yè)的封面?zhèn)渫?固定面板)以及二十頁(yè)的報(bào)表(固定面板)。
到達(dá)包支持多個(gè)特定選擇器，它們可在構(gòu)建包含“相同”內(nèi)容的替換表示的文檔包時(shí)使用。具體地，到達(dá)包允許基于語(yǔ)言、顏色能力和頁(yè)面大小的選擇。由此，例如，可具有雙語(yǔ)言文檔，它使用選擇器在文檔的英語(yǔ)表示和法語(yǔ)表示之間選取。
除選擇器和序列對(duì)于到達(dá)包的組成的這些簡(jiǎn)單使用之外，重要的是注意，選擇器和序列還可指進(jìn)一步的選擇器和序列，由此允許構(gòu)建強(qiáng)大的聚積分層結(jié)構(gòu)。依照本實(shí)施例，關(guān)于什么可以完成以及什么不能完成的確切規(guī)則在下文名為“到達(dá)包結(jié)構(gòu)”一節(jié)中指定。
另外，到達(dá)包可包含附加的有效負(fù)載，它們不是固定有效負(fù)載，而是文檔的更豐富并且可能可編輯的表示。這允許包包含在編輯器應(yīng)用程序中運(yùn)作良好的豐富的、可編輯的文檔，以及視覺上準(zhǔn)確并可以在不編輯應(yīng)用程序的情況下察看的表示。
最后，依照該實(shí)施例，到達(dá)包支持所謂的打印票據(jù)。打印票據(jù)提供了應(yīng)當(dāng)在打印包時(shí)使用的設(shè)置。這些打印票據(jù)可以用各種方式附加，以實(shí)現(xiàn)實(shí)質(zhì)的靈活性。例如，打印票據(jù)可以被附加到整個(gè)包，并且其設(shè)置將影響整個(gè)包。打印票據(jù)還可以在結(jié)構(gòu)中的較低級(jí)別上附加(例如，附加到個(gè)別的頁(yè))，并且這些打印票據(jù)將提供在打印它們所附加的部件時(shí)使用的覆蓋設(shè)置。
到達(dá)包結(jié)構(gòu)
如上所述，到達(dá)包支持一組特征，包括“固定”頁(yè)面、固定面板、組成部分、打印票據(jù)等等。這些特征在包內(nèi)使用包模型的核心組件來(lái)表示部件和關(guān)系。在本節(jié)及其相關(guān)的小節(jié)中，提供了對(duì)“到達(dá)包”的完整描述，包括所有這些部件和關(guān)系必須如何被匯編、相關(guān)等的描述。
到達(dá)包結(jié)構(gòu)綜述
圖10示出了一個(gè)示例性到達(dá)包，并且在本實(shí)施例中，示出了可構(gòu)成包或在包中找到的部件的每一有效類型。下文提供的表格列出了每一有效部件類型，并提供了每一個(gè)的描述
由于到達(dá)包被設(shè)計(jì)成“在任何地方察看和打印”的文檔，因此到達(dá)包的閱讀者和書寫者必須共享對(duì)什么構(gòu)成了“有效”到達(dá)包的公用、明白定義的期望。為提供“有效”到達(dá)包的定義，下文首先定義若干概念。
到達(dá)排版部件
到達(dá)包必須包含可通過(guò)從包的起始部件開始遍歷組成塊來(lái)“發(fā)現(xiàn)”的至少一個(gè)固定面板。依照所描述的實(shí)施例，發(fā)現(xiàn)過(guò)程遵循以下算法
●從包的起始部件開始遞歸地遍歷排版部件圖。
●當(dāng)執(zhí)行該遍歷時(shí)，僅遍歷到作為到達(dá)排版部件(以下描述)的排版部件中。
●在圖的邊上定位所有的終端節(jié)點(diǎn)(沒有向外的弧的節(jié)點(diǎn))。
這些終端節(jié)點(diǎn)指的是(通過(guò)其<item>元素)一組被稱為到達(dá)有效負(fù)載根的部件。
固定有效負(fù)載
固定有效負(fù)載是其根部件是固定面板部件的有效負(fù)載。例如，圖10中的每一固定有效負(fù)載具有相關(guān)聯(lián)的固定面板部件作為其根部件。有效負(fù)載包括固定面板的有效處理所需的所有部件的完整閉包。這包括
●固定面板本身；
●從固定面板內(nèi)引用的所有固定頁(yè)；
●由有效負(fù)載中的任一固定頁(yè)(直接或通過(guò)選擇器間接)引用的所有圖像部件；
●從有效負(fù)載內(nèi)的任一固定頁(yè)內(nèi)使用的圖像刷直接或間接引用的所有到達(dá)選擇器(下文描述)；
●由有效負(fù)載中的任一固定頁(yè)引用的所有字體部件；
●附加到固定有效負(fù)載的任一部件的所有描述性元數(shù)據(jù)部件；以及
●附加到固定有效負(fù)載中的任一部件的任一打印票據(jù)。
用于到達(dá)包的有效性規(guī)則
在適當(dāng)?shù)奈恢糜辛松鲜龆x，現(xiàn)在描述依照所描述的實(shí)施例描述“有效”到達(dá)包的一致性規(guī)則
●到達(dá)包必須具有使用上述包關(guān)系的標(biāo)準(zhǔn)機(jī)制定義的起始部件；
●到達(dá)包的起始部件必須是選擇器或序列；
●到達(dá)包必須具有作為固定面板的至少一個(gè)到達(dá)有效負(fù)載根；
●打印票據(jù)部件可以被附加到任一排版部件、固定面板部件或固定面板內(nèi)標(biāo)識(shí)的任一固定頁(yè)部件。在本實(shí)例中，這是通過(guò)http://PLACEHOLDER/HasPrintTicketRel關(guān)系來(lái)完成的；
○ 打印票據(jù)可以被附加到這些部件的任一個(gè)或所有；
○ 任一給定部件必須附加不多于一個(gè)的打印票據(jù)；
●描述性元數(shù)據(jù)部件可以被附加到包內(nèi)的任一部件；
●固定有效負(fù)載中的每一字體對(duì)象必須滿足“字體部件”一節(jié)中定義的字體格式規(guī)則；
●從固定有效負(fù)載的任一固定頁(yè)對(duì)圖像的引用必須指向(可能通過(guò)其它選擇器遞歸地)作出選擇來(lái)找出要呈現(xiàn)的實(shí)際圖像的選擇器；
●固定有效負(fù)載中使用的每一圖像對(duì)象必須滿足“圖像部件”一節(jié)中定義的字體格式規(guī)則；
●對(duì)于從固定頁(yè)(直接或通過(guò)選擇器間接)引用的任一字體、圖像或選擇器部件，必須有從引用固定頁(yè)到被引用的部件的“需要的部件”關(guān)系(關(guān)系名=http://mmcf-fixed-RequiredResource-PLACEHOLDER)。
到達(dá)排版部件
盡管到達(dá)包可包含許多類型的排版部件，然而僅明確定義的排版部件的類型集具有依照該文檔明確定義的行為。這些具有明確定義的行為的排版部件被稱為到達(dá)排版部件。不同于這些的部件在確定到達(dá)包的有效性時(shí)不是相關(guān)的。
以下排版部件類型被定義為到達(dá)排版部件
到達(dá)選擇器
被定義為到達(dá)排版部件的那些選擇器排版部件被稱為到達(dá)選擇器。如上所述，語(yǔ)言選擇器基于其自然語(yǔ)言，如英語(yǔ)或法語(yǔ)在表示之間選擇。為發(fā)現(xiàn)該語(yǔ)言，選擇器調(diào)查其每一項(xiàng)。僅作為XML的那些項(xiàng)被考慮在內(nèi)。對(duì)于那些項(xiàng)，調(diào)查每一項(xiàng)的根元素以確定其語(yǔ)言。如果xml:lang屬性不存在，則忽略該部件。選擇器然后依次考慮這些部件的每一個(gè)，選擇其語(yǔ)言與系統(tǒng)的默認(rèn)語(yǔ)言相匹配的第一個(gè)部件。
顏色選擇器基于它們是單色還是彩色在表示之間選擇。頁(yè)面大小選擇器基于其頁(yè)面大小在表示之間選擇。內(nèi)容類型選擇器基于其內(nèi)容類型是否能被系統(tǒng)理解在表示之間選擇。
到達(dá)序列
被定義為到達(dá)排版部件的那些序列排版部件被稱為到達(dá)序列。固定的序列將固定內(nèi)容的子部件組合成序列。
固定有效負(fù)載部件
固定有效負(fù)載能包括以下種類的部件固定面板部件、固定頁(yè)面部件、圖像部件、字體部件、打印票據(jù)部件以及描述性元數(shù)據(jù)部件，其每一個(gè)在下文其自己的小標(biāo)題下討論。
固定面板部件
固定有效負(fù)載的文檔結(jié)構(gòu)將固定頁(yè)面標(biāo)識(shí)為骨架的一部分，如下文所描述的。骨架部件和頁(yè)面部件之間的關(guān)系在骨架的關(guān)系流內(nèi)定義。固定面板部件是內(nèi)容類型application/xml+PLACEHOLDER。
固定有效負(fù)載內(nèi)容的骨架通過(guò)在<Document>元素內(nèi)包括<FixedPanel>元素在標(biāo)記中指定。在下文的示例中，<FixedPanel>元素指定了骨架中容納的頁(yè)的來(lái)源。
<！--SPINE-->
<Document $XMLNSFIXED$>
<FixedPanel>
<PageContent Source="p1.xml"/>
<PageContent Source="p2.xml"/>
</FixedPanel>
</Document>
<Document>元素
<Document>元素沒有屬性，并且必須只有一個(gè)子元素<FixedPanel>。
<FixedPanel>元素
<FixedPanel>元素是文檔的骨架，它邏輯上將已排序的頁(yè)面序列綁定在一起成單個(gè)多頁(yè)文檔。頁(yè)面總是指定了其自己的寬度和高度，但是<FixedPanel>元素也可任選地指定高度和寬度。該信息可用于各種各樣的目的，包括，例如基于頁(yè)面大小在替換表示之間選擇。如果<FixedPanel>元素指定了高度和寬度，則它通常可與<FixedPane>內(nèi)的頁(yè)面的寬度和高度對(duì)齊，但是這些尺寸不指定個(gè)別頁(yè)的高度和寬度。
以下表格依照所描述的實(shí)施例總結(jié)了FixedPanel屬性。
<PageContent>元素是<FixedPanel>元素唯一允許的子元素。<PageContent>元素是與文檔的頁(yè)順序相匹配的順序標(biāo)記次序。
<PageContent>元素
每一<PageContent>元素指的是單個(gè)頁(yè)面的內(nèi)容的來(lái)源。為確定文檔中頁(yè)的數(shù)量，可對(duì)包含在<FixedPanel>中的<PageContent>子元素進(jìn)行計(jì)數(shù)。
<PageContent>元素沒有允許的子元素，并且有單個(gè)需要的屬性-Source，它指的是頁(yè)的內(nèi)容的固定頁(yè)面部件。
如<FixedPanel>元素一樣，<PageContent>元素可任選地包括PageHeight和PageWidth屬性，此處反映了單個(gè)頁(yè)的大小。需要的頁(yè)面大小在固定頁(yè)面部件內(nèi)指定；<PageContent>上的可任選大小僅是建議性的。<PageContent>大小屬性允許諸如文檔察看器等應(yīng)用程序?qū)τ谖臋n快速地做出可視布局估算，而不加載和語(yǔ)法分析所有的個(gè)別固定頁(yè)面部件。
下文提供的表格總結(jié)了<PageContent>屬性并提供了屬性的描述。
頁(yè)內(nèi)容的URI串必須引用內(nèi)容相對(duì)于包的部件位置。
固定頁(yè)面部件
<FixedPanel>中的每一<PageContent>元素按名字(URI)引用了固定頁(yè)面部件。每一固定頁(yè)面部件包含描述內(nèi)容的單個(gè)頁(yè)面的呈現(xiàn)的固定頁(yè)面標(biāo)記。固定頁(yè)面部件是內(nèi)容類型application/xml+PLACEHOLDER-FixedPage。
在標(biāo)記中描述固定頁(yè)面
以下是源內(nèi)容的標(biāo)記如何查找上述實(shí)例骨架標(biāo)記(<PageContentSource="pl.xml"/>)中引用的頁(yè)面的示例。// /content/pl.xml<FixedPage PageHeight="1056"PageWidth="816">
<Glyphs
OriginX="96"
OriginY="96"
UnicodeString="This is Page 1！"
Fonturi="../Fonts/Times.TTF"
FontRenderingEmSize="16"
/></FixedPage>
以下表格總結(jié)了FixedPage的屬性并提供了屬性的描述。
固定頁(yè)面標(biāo)記中的讀取順序
在一個(gè)實(shí)施例中，包含在固定頁(yè)面內(nèi)的Glyphs子元素的標(biāo)記順序必須與頁(yè)面的文本內(nèi)容的期望讀取順序相同。該讀取順序可用于來(lái)自察看器中的固定頁(yè)面的順序文本的交互式選擇/賦值，以及允許可訪問性技術(shù)對(duì)順序文本的訪問。確保標(biāo)記順序和讀取順序的之間的這一對(duì)應(yīng)性是生成固定頁(yè)面標(biāo)記的應(yīng)用程序的責(zé)任。
圖像部件
支持的格式
依照所描述的實(shí)施例，到達(dá)包中的固定頁(yè)面使用的圖像部件可以是固定數(shù)量的格式，例如PNG或JPEG，盡管可使用其它格式。
字體部件
依照所描述的實(shí)施例，到達(dá)包支持有限數(shù)量的字體格式。在所示并描述的實(shí)施例中，支持的字體格式包括TrueType格式和OpenType格式。
如本領(lǐng)域的技術(shù)人員所理解的，OpenType字體格式是TrueType字體格式的擴(kuò)展，添加了對(duì)PostScript字體數(shù)據(jù)和復(fù)雜的排字布局的支持。OpenType字體文件包含表格格式的數(shù)據(jù)，它包括TrueType輪廓字體或PostScript輪廓字體。
依照所描述的實(shí)施例，到達(dá)包內(nèi)不支持以下字體格式Adobe類型1、位圖字體、具有隱藏屬性的字體(使用系統(tǒng)標(biāo)志來(lái)判斷是否枚舉它)、矢量字體以及EUDC字體(其字體家族名是EUDC)。
分設(shè)置字體
固定有效負(fù)載標(biāo)識(shí)使用下文詳細(xì)描述的Glyphs元素的所有文本。由于在本實(shí)施例中格式是固定的，因此可能對(duì)字體進(jìn)行分設(shè)置以僅包含固定有效負(fù)載所需的字形。因此，到達(dá)包內(nèi)的字體可以基于字形使用率來(lái)分設(shè)置。盡管分設(shè)置的字體將不包含原始字體中的所有字形，然而分設(shè)置的字體必須是有效的OpenType字體文件。
打印票據(jù)部件
打印票據(jù)部件提供了可在打印包時(shí)使用的設(shè)置。這些打印票據(jù)可以用各種方式附加，以實(shí)現(xiàn)實(shí)質(zhì)上的靈活性。例如，打印票據(jù)可被“附加”到整個(gè)包，并且其設(shè)置將影響整個(gè)包。打印票據(jù)可以在結(jié)構(gòu)中的較低級(jí)進(jìn)一步附加(例如，附加到個(gè)別的頁(yè))，并且這些打印票據(jù)將提供在打印它們所附加的部件時(shí)使用的覆蓋設(shè)置。
描述性元數(shù)據(jù)
如上所述，描述性元數(shù)據(jù)部件向包的書寫者或生產(chǎn)者提供了儲(chǔ)存屬性值的方法，使包的閱讀者能夠可靠地發(fā)現(xiàn)這些值。這些屬性通常用于記錄關(guān)于整個(gè)包以及容器內(nèi)個(gè)別部件的附加信息。
固定頁(yè)面標(biāo)記基礎(chǔ)
本節(jié)描述了與固定頁(yè)面標(biāo)記相關(guān)聯(lián)的某些基礎(chǔ)信息，并包括以下小節(jié)“固定有效負(fù)載和其它標(biāo)記標(biāo)準(zhǔn)”、“固定頁(yè)面標(biāo)記模型”、“資源和資源引用”、以及“固定頁(yè)面繪制模型”。
固定有效負(fù)載和其它標(biāo)記標(biāo)準(zhǔn)
到達(dá)包內(nèi)的固定有效負(fù)載的固定面板和固定頁(yè)面標(biāo)記是來(lái)自WindowsLonghorn的Avalon XAML標(biāo)記的子集。即，盡管固定有效負(fù)載標(biāo)記作為獨(dú)立的XML標(biāo)記格式(如在本文檔中編制的)是獨(dú)立的，但是它以與Longhorn系統(tǒng)相同的方式加載，并呈現(xiàn)了原始多頁(yè)文檔的WYSIWYG再現(xiàn)。
作為AML標(biāo)記的某些背景，考慮以下。XAML標(biāo)記是允許用戶將對(duì)象的層次以及對(duì)象后的編程邏輯指定為基于XML的標(biāo)記語(yǔ)言的機(jī)制。這為對(duì)象模型提供了以XML描述的能力。這允許諸如微軟公司的.NET框架的公用語(yǔ)言運(yùn)行庫(kù)(CLR)等類中的可擴(kuò)充類以XML來(lái)訪問。XAML機(jī)制提供了XML標(biāo)簽到CLR對(duì)象的直接映射，以及以標(biāo)記表示相關(guān)代碼的能力?？梢悦靼撞⒗斫?，各個(gè)實(shí)現(xiàn)不需要特別地使用XAML的基于CLR的實(shí)現(xiàn)。相反，基于CLR的實(shí)現(xiàn)僅構(gòu)成了可在本文檔中描述的實(shí)施例環(huán)境中采用XAML的一種方法。
更具體地，考慮結(jié)合圖11的以下內(nèi)容，它示出了CLR概念(左側(cè)分量)到XML(右側(cè)分量)的示例性映射。名字空間使用稱為反射的CLR概念在xmlns聲明中找到。類直接映射到XML標(biāo)簽。屬性和事件直接映射到屬性。使用這一分層結(jié)構(gòu)，用戶可指定XML標(biāo)記文件中的任一CLR對(duì)象的分層樹。xaml文件是具有xaml擴(kuò)展名以及application/xaml+xml的媒體類型的xml文件。xaml文件具有一個(gè)根標(biāo)簽，它通常使用xmlns屬性指定了名字空間。名字空間可以在標(biāo)簽的其它類型中指定。
繼續(xù)，xaml文件中的標(biāo)簽一般映射到CLR對(duì)象。標(biāo)簽可以是元素、復(fù)合屬性、定義或資源。元素是一般在運(yùn)行時(shí)例示的CLR對(duì)象，并形成了對(duì)象的分層結(jié)構(gòu)。復(fù)合屬性標(biāo)簽用于設(shè)置父標(biāo)簽中的屬性。定義標(biāo)簽用于將代碼添加到頁(yè)并定義資源。資源標(biāo)簽提供了僅通過(guò)將樹指定為資源來(lái)重新使用對(duì)象樹的能力。定義標(biāo)簽也可在另一標(biāo)簽中被指定為xmlns屬性。
一旦以標(biāo)記(通常由書寫者)合適地描述了文檔，可以(通常由閱讀者)對(duì)標(biāo)記進(jìn)行語(yǔ)法分析和處理。合適配置的語(yǔ)法分析器從根標(biāo)簽中確定應(yīng)當(dāng)搜索哪些CLR匯編和名字空間來(lái)找出標(biāo)簽。在許多情況下，語(yǔ)法分析器進(jìn)行查找，并找出由xmlns屬性指定的URL中的名字空間定義文件。名字空間定義文件提供了匯編的名字及其安裝路徑和CLR名字空間的列表。當(dāng)語(yǔ)法分析器遇到標(biāo)簽時(shí)，語(yǔ)法分析器使用標(biāo)簽的xmlns以及該xmlns的xmlns定義文件來(lái)確定標(biāo)簽引用哪些CLR類。語(yǔ)法分析器按定義文件中指定的匯編和名字空間的順序進(jìn)行搜索。當(dāng)它找到匹配時(shí)，語(yǔ)法分析器例示該類的對(duì)象。
由此，上文描述，并且在上文通過(guò)引用更完全結(jié)合在本申請(qǐng)中的機(jī)制允許使用標(biāo)記標(biāo)簽以基于XML文件來(lái)表示對(duì)象模型。這一將對(duì)象模型表示為標(biāo)記標(biāo)簽的能力可以用于異步或同步地創(chuàng)建矢量圖形繪圖、固定格式的文檔、自適應(yīng)流文檔和應(yīng)用程序UI。
在所示并描述的實(shí)施例中，固定有效負(fù)載標(biāo)記是最小的，幾乎完全是呈現(xiàn)原語(yǔ)的Avalon XAML的節(jié)儉的子集。它用完全的保真度可視地表示了可以用Avalon表示的任何內(nèi)容。固定有效負(fù)載標(biāo)記是Avalon XAML元素和屬性的子集-加上附加的約定、正則形式或與Avalon XAML相比在使用率上的限制。
定義的完全最小固定有效負(fù)載標(biāo)記集減少了與到達(dá)包閱讀者，如打印機(jī)RIP或交互式察看器應(yīng)用程序的實(shí)現(xiàn)和測(cè)試相關(guān)聯(lián)的成本-并減少了相關(guān)聯(lián)的語(yǔ)法分析器的復(fù)雜度和存儲(chǔ)器覆蓋區(qū)。節(jié)儉的標(biāo)記集也最小化了分設(shè)置、錯(cuò)誤或到達(dá)包書寫者和閱讀者之間的不一致性的機(jī)會(huì)，從而令格式及其生態(tài)系統(tǒng)內(nèi)在地更健壯。
除最小的固定有效負(fù)載標(biāo)記之外，到達(dá)包將為附加的語(yǔ)義信息指定標(biāo)記，以支持具有諸如超鏈接、版面/大綱結(jié)構(gòu)和導(dǎo)航、文本選擇和文檔可訪問性等特征的察看器到達(dá)包或呈現(xiàn)。
最后，使用上述版本化和可擴(kuò)充性機(jī)制，用用于特定的目標(biāo)消耗應(yīng)用程序、察看器或設(shè)備的更豐富的元素集來(lái)補(bǔ)充最小的固定有效負(fù)載標(biāo)記是可能的。
固定頁(yè)面標(biāo)記模型
在所示并描述的實(shí)施例中，固定頁(yè)面部件是基于XML元素、XML元屬性和XML名字空間以基于XML的標(biāo)記語(yǔ)言來(lái)表達(dá)的。本文檔中定義了三個(gè)XML名字空間以包括在固定頁(yè)面標(biāo)記中。一個(gè)這樣的名字空間參考了本說(shuō)明書中其它地方定義的版本控制元素和屬性。用于固定頁(yè)面標(biāo)記中的元素和屬性的原則名字空間是“http://schemas.microsoft.com/MMCF-PLACEHOLDER-FixedPage”。最后，固定頁(yè)面標(biāo)記引入了“資源”的概念，它需要下文描述的第三個(gè)名字空間。
盡管固定頁(yè)面標(biāo)記是使用XML元素和XML元屬性來(lái)表達(dá)的，然而其規(guī)范基于“內(nèi)容”和“屬性”的更高級(jí)抽象模型。固定頁(yè)面元素都被表達(dá)為XML元素。僅少數(shù)固定頁(yè)面元素可容納“內(nèi)容”，表達(dá)為XML子元素。但是屬性值可使用XML元屬性或使用XML子元素來(lái)表達(dá)。
固定頁(yè)面標(biāo)記也依賴于資源字典和資源引用的雙概念。資源字典和多個(gè)資源引用的組合允許單個(gè)屬性值由多個(gè)固定頁(yè)面標(biāo)記元素的多個(gè)屬性共享。
固定頁(yè)面標(biāo)記中的屬性
在所示并描述的實(shí)施例中，有三種形式的標(biāo)記，它們可用于指定固定頁(yè)面標(biāo)記屬性的值。
如果屬性是使用資源引用來(lái)指定的，則屬性名用作XML元屬性名，并且屬性值的特殊句法指示了資源引用的存在。用于表達(dá)資源引用的句法在名為“資源和資源引用”一節(jié)中描述。
未被指定為資源引用的任何屬性值可以使用標(biāo)識(shí)其值被設(shè)置的屬性的嵌套XML子元素以XML來(lái)表達(dá)。該“復(fù)合屬性句法”在下文描述。
最后，某些非資源引用屬性值可被表達(dá)為簡(jiǎn)單文本串。盡管所有這樣的屬性值可以使用復(fù)合屬性句法來(lái)表達(dá)，然而它們也可使用簡(jiǎn)單的XML元屬性句法來(lái)表達(dá)。
對(duì)于任一給定的元素，任一屬性可以被設(shè)置不多于一次，無(wú)論用于指定該值的句法是什么。
簡(jiǎn)單屬性句法
對(duì)于可被表達(dá)為簡(jiǎn)單串的屬性值，可使用XML元屬性句法來(lái)指定屬性值。例如，給定稱為“SolidColorBrush(純色刷)”的固定頁(yè)面標(biāo)記元素，它具有名為“Color(顏色)”的屬性，可使用以下句法來(lái)指定屬性值<！--Simple Attribute Syntax--><SolidColorBrush Color="#FF0000"/>
復(fù)合屬性句法
某些屬性值不能被表達(dá)為簡(jiǎn)單的串，例如XML元素用于描述屬性值。這一屬性值不能使用簡(jiǎn)單屬性句法來(lái)表達(dá)。但是它們可使用復(fù)合屬性句法來(lái)表達(dá)。
在復(fù)合屬性句法中，使用了XML子元素，但是從父元素名和屬性名的組合導(dǎo)出XML元素名，以點(diǎn)分隔。給定固定頁(yè)面標(biāo)記元素<Path>(路徑)，它具有屬性“Fill”，它可被設(shè)置到<SolidColorBrush>，可使用以下標(biāo)記來(lái)設(shè)置<Path>元素的“Fill”屬性<！--Compound-Property Syntax--><Path>
<Path.Fill>
<SolidColorBrush Color="#FF0000"/>
</Path.Fill>
...</Path>
復(fù)合屬性句法即使在簡(jiǎn)單屬性句法足以表達(dá)屬性值的情況下也可使用。因此，前一節(jié)的示例<！--Simple Attribute Syntax--><SolidColorBrush Color="#FF0000"/>
可替代地以復(fù)合屬性句法來(lái)表達(dá)<！--Compound-Property Syntax--><SolidColorBrush>
<SolidColorBrush.Color>#FF0000</SolidColorBrush.Color></SolidColorBrush>
當(dāng)使用復(fù)合屬性句法來(lái)指定屬性值時(shí)，表示“屬性”的XML子元素必須出現(xiàn)在表示“內(nèi)容”的XML子元素之前。個(gè)別復(fù)合屬性XML子元素的順序不是重要的，只需它們一起出現(xiàn)在父元素的任何“內(nèi)容”之前。
例如，當(dāng)使用<Canvas>(畫布)元素(下文描述)的Clip(裁剪)和RenderTransform(渲染變換)屬性時(shí)，這兩個(gè)屬性都必須出現(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>
資源和資源引用
資源字典可用于容納可共享的屬性值，其每一個(gè)被稱為資源。其本身是固定頁(yè)面標(biāo)記元素的任一屬性值可以容納在資源字典中。資源字典中的每一資源攜帶一名字。資源名可用于參考來(lái)自屬性的XML元屬性的資源。
在所示并描述的實(shí)施例中，<Canvas>和<FixedPage>元素可攜帶資源字典。資源字典是以標(biāo)記表達(dá)為名為“Resource(資源)”的屬性內(nèi)的<Canvas>和<FixedPage>元素的屬性。然而，個(gè)別的資源值直接嵌入在<FixedPage.Resources>或<Canvas.Resources>XML 元素內(nèi)。句法上，<Canvas.Resources>和<FixedPage.Resource>的標(biāo)記類似于具有“內(nèi)容”的標(biāo)記元素。
依照本實(shí)施例，<Canvas.Resources>或<FixedPage.Resources>必須在<Canvas>或<FixedPage>的任何復(fù)合屬性句法屬性值之前。類似地，它們必須在<Canvas>或<FixedPage>的任何“內(nèi)容”之前。
定義固定有效負(fù)載資源字典
任何<FixedPage>或<Canvas>可攜帶資源字典，用<Canvas.Resource>XML元素來(lái)表達(dá)。單個(gè)資源字典內(nèi)的每一元素被給予一唯一的名字，通過(guò)使用與該元素相關(guān)聯(lián)的XML元屬性來(lái)標(biāo)識(shí)。為將該“Name”元屬性與對(duì)應(yīng)于屬性的那些元屬性進(jìn)行區(qū)分，Name元屬性取自與固定格式元素的名字空間不同的名字空間。該XML名字空間的URI是“http://schemas.microsoft.com/PLACEHOLDER-for-resources”。在以下示例中，定義了兩種幾何結(jié)構(gòu)一個(gè)是矩形，另一個(gè)是圓形。
<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>
引用資源
為將屬性值設(shè)為上文定義的資源之一，使用在{}內(nèi)包含資源名的XML屬性值。例如，“{Rectangle}”將表示要使用該幾何結(jié)構(gòu)。在以下標(biāo)記樣例中，由字典中的幾何結(jié)構(gòu)對(duì)象定義的矩形區(qū)域?qū)⒂肧olidColorBrush來(lái)填充。<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>
依照本實(shí)施例，資源引用必須不出現(xiàn)在資源字典的資源定義內(nèi)。
用于解析資源引用的檢查規(guī)則
盡管在同一資源字典內(nèi)可能無(wú)法使用單個(gè)名字兩次，然而同一名字可以用在單個(gè)固定頁(yè)面部件的兩個(gè)不同的資源字典內(nèi)。此外，內(nèi)部<Canvas>的資源字典可重復(fù)使用某些外部<Canvas>或<FixedPage>的資源字典內(nèi)定義的名字。
當(dāng)使用資源引用來(lái)設(shè)置元素的屬性時(shí)，搜索各個(gè)資源字典來(lái)找出給定名字的資源。如果具有屬性的元素是<Canvas>，則搜索該<Canvas>的資源字典(如果有的話)以找出期望名字的資源。如果元素不是<Canvas>，則搜索以最接近的包含<Canvas>或<FixedPage>開始。如果在最初搜索的資源字典內(nèi)未定義期望的名字，則咨詢下一最接近的包含<Canvas>或<FixedPage>。如果搜索繼續(xù)到根<FixedPage>元素，并且在與該<FixedPage>相關(guān)聯(lián)的資源字典內(nèi)未找到期望名字的資源，則出現(xiàn)錯(cuò)誤。
以下示例表示了這些規(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>
固定頁(yè)面繪制模型
固定頁(yè)面元素(或嵌套的畫布子元素)是在其上呈現(xiàn)其它元素的元素。內(nèi)容的排列由對(duì)固定頁(yè)面(或畫布)指定的屬性、對(duì)固定頁(yè)面(或畫布)上的元素指定的屬性、以及對(duì)固定頁(yè)面名字空間定義的組成規(guī)則來(lái)控制。
使用畫布來(lái)定位元素
在固定標(biāo)記中，所有的元素都相對(duì)于坐標(biāo)系統(tǒng)的當(dāng)前原點(diǎn)(0，0)來(lái)定位。當(dāng)前原點(diǎn)可通過(guò)向包含元素的固定頁(yè)面或畫布的每一元素應(yīng)用RenderTransform元屬性來(lái)移動(dòng)。
以下示例示出了通過(guò)RenderTransform對(duì)元素的定位。<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>
坐標(biāo)系統(tǒng)和單位
依照所示并描述的實(shí)施例，最初設(shè)置坐標(biāo)系統(tǒng)，使得該坐標(biāo)系統(tǒng)中的一個(gè)單位等于英寸的1/96，被表達(dá)為浮點(diǎn)值，坐標(biāo)系統(tǒng)的原點(diǎn)(0，0)是固定頁(yè)面元素的左上角。
RenderTransform元屬性可以在任一子元素上指定，以向當(dāng)前坐標(biāo)系統(tǒng)應(yīng)用仿射變換。
頁(yè)面尺寸
頁(yè)面尺寸由固定頁(yè)面元素上的“PageWidth(頁(yè)寬度)”和“PageHeight(頁(yè)高度)”參數(shù)來(lái)指定。
組成規(guī)則
固定頁(yè)面使用了具有α通道的繪圖程序模型。依照所描述的實(shí)施例，組成必須依照這些規(guī)則，并且以以下順序發(fā)生
●固定頁(yè)面(或任何嵌套的畫布)被認(rèn)為是無(wú)界的表面，向該表面上按它們出現(xiàn)在標(biāo)記中的次序繪制子元素。該表面的α通道被初始化為“0.0”(全部透明)。實(shí)際上，理想的無(wú)界表面可以被認(rèn)為是一種位圖緩沖區(qū)，它足夠大以容納通過(guò)呈現(xiàn)所有的子元素產(chǎn)生的所有標(biāo)記。
●表面的內(nèi)容使用由固定頁(yè)面(或畫布)的渲染變換屬性指定的仿射變換來(lái)變換。
●所有的子元素被呈現(xiàn)到表面上、由固定頁(yè)面(或畫布)的裁剪屬性來(lái)裁剪(也使用渲染變換屬性來(lái)變換)。固定頁(yè)面另外裁剪到由(0，0，PageWitch，PageHeight)指定的矩形。如果子元素具有不透明(Opacity)屬性或不透明掩模(OpacityMask)屬性，則它在呈現(xiàn)到表面上之前被應(yīng)用到該子元素。
●最后，固定頁(yè)面(或畫布)的內(nèi)容被呈現(xiàn)到其包含元素上。在固定頁(yè)面的情況下，包含元素是物理映像表面。
呈現(xiàn)依照這些規(guī)則發(fā)生
●在表面上產(chǎn)生標(biāo)記的唯一元素是“字形(Glyphs)”和“路徑(Path)”。
●所有其它的呈現(xiàn)效果可通過(guò)將“字形”和“路徑”元素定位到“畫布”上，并應(yīng)用其各種有效元屬性來(lái)實(shí)現(xiàn)。
固定有效負(fù)載元素和屬性
依照所示并描述的實(shí)施例，固定有效負(fù)載包括在標(biāo)記中用于表示頁(yè)面及其內(nèi)容的一小組XML元素。固定面板部件中的標(biāo)記使用<Document>、<FixedPanel>和<PageContent>元素將文檔的頁(yè)面一起帶到一公用的、容易索引的根。每一固定頁(yè)面部件表示僅具有<Path>和<Glyphs>元素(它們共同完成所有的繪制)的<FixedPage>元素，以及組合它們的<Canvas>元素中的頁(yè)面內(nèi)容。
固定有效負(fù)載標(biāo)記的元素分層結(jié)構(gòu)在以下名為“頂級(jí)元素”、“用于路徑、裁剪的幾何結(jié)構(gòu)”、“用于填充路徑、字形或不透明掩模的刷子”、“用于固定頁(yè)面或畫布的資源字典”、“用于α透明性的不透明掩?！?、“裁剪路徑”和“變換”的章節(jié)中總結(jié)。
頂級(jí)元素●<Document>[對(duì)每一固定面板部件只有一個(gè)]
○ 元屬性
■ [無(wú)]
○ 子元素
■ <FixedPanel>[只有一個(gè)]● <FixedPanel>
○ 元屬性
■ PageHeight[可任選]
■ PageWidth[可任選]
○ 子元素
■ <PageContent>[這些子元素的1-N個(gè)]● <PageContent>
○ 元屬性
■ Source[需要]
■ PageHeight[可任選]
■ PageWidth[可任選]
○ 子元素
■ [無(wú)]● <Fixedpage>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ PageHeight[需要(此處或作為子元素)]
■ PageWidth[需要(此處或作為子元素)]
○ 表達(dá)為XML子元素的資源字典本身
■ <FixedPage.Resouces>
○ 通過(guò)XML子元素表達(dá)的屬性
■ <FixedPage.PageHeight>[需要(此處或作為元屬性)]
■ <FixedPage.PageWidth>[需要(此處或作為元屬性)]
○ 通過(guò)XML子元素表達(dá)的內(nèi)容
■ <Canvas>
■ <Path>
■ <Glyphs>● <Canvas>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
○ 通過(guò)資源字典引用表達(dá)的屬性
■ Clip
■ RenderTransform
■ OpacityMask
○ 表達(dá)為XML子元素的資源字典本身
■ <Canvas.Resources>
○ 通過(guò)XML子元素表達(dá)的屬性
■ <Canvas.Opacity>
■ <Canvas.Clip>
■ <Canvas.RenderTransform>
■ <Canvas.OpacityMask>
○ 通過(guò)XML子元素表達(dá)的內(nèi)容
■ <Canvas>
■ <Path>
■ <Glyphs>● <Path>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
○ 通過(guò)資源字典引用表達(dá)的屬性
■ Clip
■ RenderTransfrom
■ OpacityMask
■ Fill
○ 通過(guò)XML子元素表達(dá)的屬性
■ <Path.Opacity>
■ <Path.Clip>
■ <Path.RenderTransform>
■ <Path.OpacityMask>
■ <Path.Fill>
■ <Path.Data>● <Glyphs>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
■ BidiLevel
■ FontFaceIndex
■ FontHintingEmSize
■ FontRenderingEmSize
■ FontUri
■ Indices
■ OriginX
■ OriginY
■ Sideways
■ StyleSimulations
■ UnicodeString
○ 通過(guò)資源字典引用表達(dá)的屬性
■ Clip
■ RenderTransform
■ OpacityMask
■ Fill
○ 通過(guò)XML子元素表達(dá)的屬性
■ <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>
用于路徑、裁剪的幾何結(jié)構(gòu)● <Path.Data>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Path.Data總共只有這些子元素的一個(gè)]
■ <GeometryCollection>
■ <PathGeometry>● <GeometryCollection>
○ 元屬性
■ CombineMode
○ 子元素
■ <GeometryCollection>
■ <PathGeometry>● <PathGeometry>
○ 元屬性
■ FillRule
○ 子元素
[1-N個(gè)子元素]
■ <PathFigure>● <PathFigure>
○ 元屬性
■ [無(wú)]
○ 子元素
[首先出現(xiàn)StartSegment，最后出現(xiàn)CloseSegment，中間有1-N個(gè)Ploy*]
■ <StartSegment>
■ <PolyLineSegment>
■ <PolyBezierSegment>
■ <CloseSegment>● <StartSegment>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Point
○ 通過(guò)XML子元素表達(dá)的屬性
■ <StartSement.Point>● <PolyLineSegment>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Points
○ 通過(guò)XML子元素表達(dá)的屬性
■ <PolyLineSegment.Points>● <PolyBezierSegment>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Points
○ 通過(guò)XML子元素表達(dá)的屬性
■ <PolyBezierSegment.Points>
用于填充路徑、字形或不透明掩模的刷子● <Path.Fill>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為簡(jiǎn)單XML子元素的屬性值
[Path.Fill只有這些子元素的一個(gè)]
■ <SolidColorBrush>
■ <ImageBrush>
■ <DrawingBrush>
■ <LinearGradientBrush>
■ <RadialGradientBrush>● <Glyphs.Fill>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Glyphs.Fill只有這些子元素的一個(gè)]
■ <SolidColorBrush>
■ <ImageBrush>
■ <DrawingBrush>
■ <LinearGradientBrush>
■ <RadialGradientBrush>● <SolidColorBrush>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
■ Color
○ 通過(guò)XML子元素表達(dá)的屬性
■ <SolidColorBrush.Opacity>
■ <SolidColorBrush.Color>● <ImageBrush>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
■ HorizontalAlignment
■ VerticalAlignment
■ Viewbox
■ ViewPort
■ Stretch
■ TileMode
■ ContentUnits
■ ViewportUnits
■ ImageSource
○ 通過(guò)資源字典引用表達(dá)的屬性
■ Transform
○ 通過(guò)XML子元素表達(dá)的屬性
■ <ImageBrush.Opacity>
■ <ImageBrush.Transform>
■ <ImageBrush.HorizontalAlignment>
■ <ImageBrush.VericalAlignment>
■ <ImageBrush.ViewBox>
■ <ImageBrush.ViewPort>
■ <ImageBrush.Stretch>
■ <ImageBrush.TileMode>
■ <ImageBrush.ContentUnits>
■ <ImageBrush.ViewportUnits>
■ <ImageBrush.ImageSource>● <DrawingBrush>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
■ HorizontalAlignment
■ VerticalAlignment
■ ViewBox
■ ViewPort
■ Stretch
■ TileMode
■ ContentUnits
■ VeiwportUnits
○ 通過(guò)資源字典引用表達(dá)的屬性
■ Transform
■ Drawing
○ 通過(guò)XML子元素表達(dá)的屬性
■ <DrawingBrush.Opacity>
■ <DrawingBrush.Transform>
■ <DrawingBrush.HorizontalAlignment>
■ <DrawingBrush.Verticalalignment>
■ <DrawingBrush.ViewBox>
■ <DrawingBrush.ViewPort>
■ <DrawingBrush.Stretch>
■ <DrawingBrush.TileMode>
■ <DrawingBrush.ContentUnits>
■ <DrawingBrush.ViewportUnits>
■ <DrawingBrush.Drawing>● <DrawingBrush.Drawing>
○ 通過(guò)XML子元素表達(dá)的內(nèi)容
■ <Canvas>
■ <Path>
■ <Glyphs>● <LinearGradientBrush>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
■ MappingMode
■ SpreadMethod
■ StartPoint
■ EndPoint
○ 通過(guò)資源字典引用表達(dá)的屬性
■ Transform
■ GradientStops
○ 通過(guò)XML子元素表達(dá)的屬性
■ <LinearGradientBrush.Opacity>
■ <LinearGradientBrush.Transform>
■ <LinearGradientBrush.MappingMode>
■ <LinearGradient.Brush.SpreadMethod>
■ <LinearGradientBrush.StartPoint>
■ <LinearGradientBrush.EndPoint>
■ <LinearGradientBrush.GradientStops>● <RadialGradientBrush>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Opacity
■ Center
■ Focus
■ RadiusX
■ RadiusY
○ 通過(guò)資源字典引用表達(dá)的屬性
■ Transform
■ GradientStops
○ 通過(guò)XML子元素表達(dá)的屬性
■ <RadialGradientBrush.Opacity>
■ <RadialGradientBrush.Transform>
■ <RadialGradientBrush.Center>
■ <RadialGradientBrush.Focus>
■ <RadialGradientBrush.RadiusX>
■ <RadialGradientBrush.RadiusY>
■ <RadialGradientBrush.GradientStops>● <GradientStops>
○ 通過(guò)XML子元素表達(dá)的內(nèi)容
■ <GradientStop> [這些子元素的1-N個(gè)]● <GradientStop>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Color
■ Offset
○ 通過(guò)XML子元素表達(dá)的屬性
■ <GradientStop.Color>
■ <GradientStop.Offset>
用于固定頁(yè)面或畫布的資源字典● <FixedPage.Resources>● <Canvas.Resources>
這些元素在上文討論資源字典的一節(jié)中已作了討論。
用于α透明性的不透明性掩?！? <Canvas.OpacityMask>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Canvas.OpacityMask只有這些子元素的一個(gè)]
■ <SolidColorBrush>
■ <ImageBrush>
■ <DrawingBrush>
■ <LinearGradientBrush>
■ <RadialGradientBrush>● <Path.OpacityMask>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Path.OpacityMask只有這些子元素的一個(gè)]
■ <SolidColorBrush>
■ <ImageBrush>
■ <DrawingBrush>
■ <LinearGradientBrush>
■ <RadialGradientBrush>● <Glyphs.OpacityMask>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Glyphs.OpacityMask只有這些子元素的一個(gè)]
■ <SolidColorBrush>
■ <ImageBrush>
■ <DrawingBrush>
■ <LinearGradientBrush>
■ <RadialGradientBrush>
裁剪路徑● <Canvas.Clip>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Canvas.Clip只有這些子元素的一個(gè)]
■ <GeometryCollection>
■ <PathGeometry>● <Path.Clip>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Path.Clip只有這些子元素的一個(gè)]
■ <GeometryCollection>
■ <PathGeometry>● <Glyphs.Clip>
○ 元屬性
■ [無(wú)]
○ 表達(dá)為單個(gè)XML子元素的屬性值
[Glyphs.Clip只有這些子元素的一個(gè)]
■ <GeometryCollection>
■ <PathGeometry>
變換● <Canvas.RenderTransform>
○ 表達(dá)為單個(gè)XML子元素的屬性值
■ <MatrixTransform>[需要]● <Path.RenderTransfrom>
○ 表達(dá)為單個(gè)XML子元素的屬性值
■ <MatrixTransform[需要]● <Glyphs.RenderTransform>
○ 表達(dá)為單個(gè)XML子元素的屬性值
■ <MatrixTransform>[需要]● <MatrixTransform>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ Matrix
○ 通過(guò)XML子元素表達(dá)的屬性
■ <MatrixTransform.Matrix>● <ImageBrush.Transform>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ MatrixTransform
○ 通過(guò)XML子元素表達(dá)的屬性
■ <ImageBrush.Transform.MatrixTransform>● <DrawingBrush.Transform>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ MatrixTransform
○ 通過(guò)XML子元素表達(dá)的屬性
■ <DrawingBrush.Transform.MatrixTransform>● <LinearGradientBrush.Transform>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ MatrixTransform
○ 通過(guò)XML子元素表達(dá)的屬性
■ <LinearGradientBrush Transform.MatrixTransform>
● <RadialGradientBrush.Transform>
○ 通過(guò)簡(jiǎn)單XML元屬性直接表達(dá)的屬性
■ MatrixTransform
○ 通過(guò)XML子元素表達(dá)的屬性
■ <RadialGradientBrush.Transform.MatrixTransform>
固定頁(yè)面標(biāo)記
每一固定頁(yè)面部件表示<FixedPage>元素中作為根的XML標(biāo)記中的頁(yè)面內(nèi)容。該固定頁(yè)面標(biāo)記提供了書寫者和閱讀者之間的文檔的WYSIWYG保真度，只有一小組元素和屬性<Path>和<Glyphs>元素(共同完成了所有的繪制)，以及組合它們的<Canvas>元素。
公用元素屬性
在討論對(duì)固定頁(yè)面標(biāo)記中的每一元素專用的屬性之前，考慮對(duì)繪制和組合元素公用的屬性O(shè)pacity、Clip、RenderTransform和OpacityMask。這些不僅是對(duì)頂級(jí)元素公用的屬性，它們也是從父元素到子元素“聚積”其結(jié)果的唯一屬性，如上文“組成規(guī)則”一節(jié)中所描述的。聚積是應(yīng)用組成規(guī)則的結(jié)果。以下表格提供了這些通用屬性的概括描述，以及對(duì)每一屬性的更完整討論。
Opacity屬性
Opacity(不透明性)屬性用于在渲染時(shí)(α渲染)透明地混合兩個(gè)元素。Opacity屬性的范圍從0(完全透明)到1(完全不透明)。該閉區(qū)間外的值在標(biāo)記語(yǔ)法分析過(guò)程中被限制到該范圍內(nèi)。因此，有效地，[-∞...0]是透明的，而[1...∞]是不透明的。
Opacity屬性通過(guò)以下計(jì)算來(lái)應(yīng)用(假定非自左乘源和目標(biāo)顏色，兩者都被指定為scRGB)
OE元素的Opacity屬性或OpacityMask中對(duì)應(yīng)位置處的α值
AS源表面中存在的α值
RS源表面中存在的紅值
GS源表面中存在的綠值
BS源表面中存在的藍(lán)值
AD目標(biāo)表面中已經(jīng)存在的α值
RD目標(biāo)表面中已經(jīng)存在的紅值
GD目標(biāo)表面中已經(jīng)存在的綠值
BD目標(biāo)表面中已經(jīng)存在的藍(lán)值
A*對(duì)目標(biāo)表面所得的α值
R*對(duì)目標(biāo)表面所得的紅值
G*對(duì)目標(biāo)表面所得的綠值
B*對(duì)目標(biāo)表面所得的藍(lán)值
用T下標(biāo)指定的所有值是臨時(shí)值(例如，RT1)。
步驟1將源α值與不透明性值相乘
AS＝AS*OE
步驟2自左乘源α
AT1＝AS
RT1＝RS*AS
GT1＝GS*AS
BT1＝BS*AS
步驟3a自左乘目標(biāo)α
AT2＝AD
RT2＝RD*AD
GT2＝GD*AD
BT2＝BD*AD
步驟3b混合
AT2＝(1-AT1)*AT2+AT1
RT2＝(1-AT1)*RT2+RT1
GT2＝(1-AT1)*GT2+GT1
BT2＝(1-AT1)*BT2+BT1
步驟4反轉(zhuǎn)自左乘
如果AT2＝0，則將所有的A*、R*、G*、B*設(shè)為0
否則
A*＝AT2
R*＝RT2/AT2
G*＝GT2/AT2
B*＝BT2/AT2
Clip屬性
Clip屬性被指定為幾何結(jié)構(gòu)元素<GeometryCollection>或<PathGeomerty>之一(見Path.Data以知道細(xì)節(jié))
Clip屬性用以下方式來(lái)應(yīng)用
●所有落入由Clip子元素描述的幾何結(jié)構(gòu)元素內(nèi)的呈現(xiàn)內(nèi)容是可見的。
●所有落入由Clip子元素描述的幾何結(jié)構(gòu)元素外的呈現(xiàn)內(nèi)容是不可見的。
RenderTransform子元素
MatrixTransform是對(duì)元素可用的唯一變換屬性。它表達(dá)了仿射變換。句法如下
<X.RenderTransform>
<MatrixTransform Matrix="1,0,0,1,0,0"/>
</X.RenderTransform>
X表示向其應(yīng)用變換的元素。
Matrix屬性中指定的六個(gè)數(shù)字是m00、m01、m10、m11、dx、dy。
完整的矩陣看似為
m00 m01 0
m10 m11 0
dxdy1
給定坐標(biāo)X、Y通過(guò)應(yīng)用以下計(jì)算用RenderTransfrom變換來(lái)產(chǎn)生所得的坐標(biāo)X′、Y′
X′＝X*m00+Y*m10+dx
Y′＝X*m01+Y*m11+dy
OpacityMask子元素
OpacityMask指定了刷子(Brush)，但是與填充刷子(Fill Brush)相反，僅使用刷子的α通道(見上述Opacity屬性)作為用于呈現(xiàn)元素的附加參數(shù)。元素的每一像素的每一α值然后被額外地與OpacityMack刷子中的對(duì)應(yīng)位置處的α值相乘。
<Canvas>元素
<Canvas>元素用于將元素組合在一起。通常，當(dāng)固定頁(yè)面元素共享組合的公用屬性(即，Opacity、Clip、RenderTransfrom或OpacityMask)時(shí)，它們?cè)?lt;Canvas>中被組合在一起。通過(guò)在畫布上將這些元素組合在一起，通?？蓪⒐脤傩詰?yīng)用到畫布而非個(gè)別的元素。
<Canvas>的屬性和子元素
<Canvas>元素只有先前描述的公用屬性O(shè)pacity、Clip、RenderTransform和OpacityMask。它們?nèi)缦卤碇忻枋龅挠糜?lt;Canvas>元素
以下標(biāo)記示例示出了對(duì)<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.Data>
</Path></Canvas>
關(guān)于畫布標(biāo)記中的讀取順序，考慮以下內(nèi)容。如固定頁(yè)面一樣，包含在Canvas內(nèi)的Glyphs子元素的標(biāo)記順序必須與文本內(nèi)容的期望讀取順序相同。該讀取順序必須用于來(lái)自察看器中的固定頁(yè)面的順序文本的交互式選擇/復(fù)制，以及允許可訪問性技術(shù)對(duì)順序文本的訪問。確保標(biāo)記順序和讀取順序之間的這一對(duì)應(yīng)性是生成固定頁(yè)面標(biāo)記的應(yīng)用程序的責(zé)任。
包含在嵌套的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ū)域是可被填充，或者可用作裁剪路徑的形狀。諸如矩形和橢圓形等常見的幾何結(jié)構(gòu)類型可以使用路徑幾何結(jié)構(gòu)來(lái)表示。路徑通過(guò)指定需要的Geometry.Data子元素和諸如Fill或Opacity等渲染屬性來(lái)描述。
<Path>的屬性和子元素
以下屬性適用于下文描述的<Path>元素
為描述如何對(duì)由<Path.Data>子元素的幾何結(jié)構(gòu)描述的區(qū)域著色，使用了Fill屬性。為限制可在其上繪制<Path.Data>形狀的區(qū)域，使用了Clip屬性。
使用<Path>來(lái)描述幾何結(jié)構(gòu)
路徑的幾何結(jié)構(gòu)被指定為<Path.Data>的一系列嵌套子元素，如下文所示。幾何結(jié)構(gòu)可以用包含一組<PathGeometry>子元素的<GeometryCollection>或包含<PathFigures>的單個(gè)<PathGeometry>子元素來(lái)表示。<Path>
<Path.Data>
<GeometryCollection>
<PathGeometry>
<PathFigure>
...
</PathFigure>
</PathGeometry>
</GeometryCollection>
</Path.Data><Path>
相同的<GeometryCollection>或<PathGeometry>元素定義了用于裁剪Canvas、Path或Glyphs的Clip屬性中使用的路徑的幾何結(jié)構(gòu)。
以下表格介紹了定義路徑幾何結(jié)構(gòu)的子元素的分層結(jié)構(gòu)。
GeometryCollection
GeometryCollection是一組被組合在一起來(lái)依照布爾CombineMode選項(xiàng)呈現(xiàn)的幾何結(jié)構(gòu)對(duì)象。GeometryCollection元素是固定頁(yè)面標(biāo)記中用于構(gòu)建幾何形狀的可視組合的機(jī)制。
CombineMode屬性指定了用于組合GeometryCollection中的一組幾何形狀的布爾操作。根據(jù)模式，可包括或排除不同的區(qū)域。
CombineMode如下處理不可交換 Complement和Exclude不是可交換的，因此在GeometryCollection中
的第一個(gè)幾何結(jié)構(gòu)和每一個(gè)別的剩余幾何結(jié)構(gòu)之間定義。例如，對(duì)于
集合{g1，g2，g3}，Exclude的CombineMode將被應(yīng)用為((g1排除g2))
并且(g1排除g3))?？山粨Q 布爾操作Union、Xor、Intersect是可交換的，因此與順序無(wú)關(guān)地應(yīng)用
于幾何結(jié)構(gòu)。
PathGeometrv
PathGeometry元素包含一組PathFigure元素。PathFigure的并集定義了PathGeometry的內(nèi)部。
關(guān)于FillRule屬性，考慮以下內(nèi)容。PathGeomerty的填充區(qū)域是通過(guò)采用將其Filled屬性設(shè)為真的所有包含的PathFigure，并應(yīng)用FillRule來(lái)確定閉合區(qū)域來(lái)定義的。FillRule選項(xiàng)指定了如何將Geometry內(nèi)包含的Figure元素的相交區(qū)域組合在一起形成Geometry的所得區(qū)域。
依照所描述的實(shí)施例，提供了奇偶填充(EvenOdd Fill)和非零填充(NonZeroFill)算法。
奇偶填充算法通過(guò)繪制從畫布上的一點(diǎn)到任一方向上的無(wú)窮大的射線，然后檢查穿過(guò)該射線的形狀的片段之處，來(lái)確定該點(diǎn)的“內(nèi)部性”。從計(jì)數(shù)零開始，從左到右每次添加一個(gè)穿過(guò)該射線的片段，并且從右到左每次減去一個(gè)穿過(guò)該射線的路徑片段。如果這一數(shù)字是奇數(shù)，則該點(diǎn)在內(nèi)部；否則，該點(diǎn)在外部。
非零填充算法通過(guò)繪制從畫布上的一點(diǎn)到任一方向上的無(wú)窮大的射線，并對(duì)該射線穿過(guò)的給定形狀的路徑片段數(shù)進(jìn)行計(jì)數(shù)，來(lái)確定該點(diǎn)的“內(nèi)部性”。在對(duì)穿過(guò)進(jìn)行計(jì)數(shù)之后，如果結(jié)果是0，則該點(diǎn)在路徑外部。否則，該點(diǎn)在內(nèi)部。
PathFigure
PathFigure元素包括一個(gè)或多個(gè)線段或曲線段的集合。線段元素定義了PathFigure的形狀。PathFigure必須總是定義閉合的形狀。
圖形需要起始點(diǎn)，之后每一線段或曲線段從添加的最后一個(gè)點(diǎn)繼續(xù)。PathFigure集合中的第一段必須是StartSegment，而CloseSegment必須是最后一段。StartSegment具有Point屬性。CloseSegment沒有屬性。
用于Path.Data幾何結(jié)構(gòu)的固定有效負(fù)載標(biāo)記
以下提供了用于繪制并填充畫布上的路徑的標(biāo)記。在以下具體示例中，在畫布上繪制矩形路徑，并用純綠色刷子來(lái)填充。
<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>
以下標(biāo)記描述了繪制立方Bézier曲線。即，除PolyLineSegment(折線段)之外，固定有效負(fù)載標(biāo)記包括用于繪制立方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>
刷子
刷子用于對(duì)由<Path>元素定義的幾何形狀的內(nèi)部進(jìn)行著色，并填充用<Glyphs>元素呈現(xiàn)的字符位圖。刷子也用于定義<Canvas.OpacityMask>、<Path.OpacityMask>和<Glyphs.OpacityMask>中的α透明性掩模。固定頁(yè)面標(biāo)記包括以下刷子
屬性在各刷子之間變化，盡管所有的刷子都具有Opacity屬性。ImageBrush和DrawingBrush共享平鋪顯示能力。兩個(gè)用梯度填充的刷子也具有公用的屬性。
對(duì)標(biāo)記中刷子子元素的使用示出如下<Path>
<Path.Fill>
<SolidColorBrush Color="#00FFFF"/>
</Path.Fill>
...</Path>
刷子的公用屬性
依照所描述的實(shí)施例，以下屬性適用于所有的刷子，除簡(jiǎn)單刷子SolidColorBrush之外，它具有更少的可任選子元素。
用于DrawingBrush和ImageBrush的公用屬性
HorizontalAlignment(水平對(duì)齊)屬性指定了刷子如何在它所填充的區(qū)域內(nèi)水平對(duì)齊。VerticalAlignment(垂直對(duì)齊)屬性指定了刷子如何在它所填充的區(qū)域內(nèi)垂直對(duì)齊。ViewBox屬性具有默認(rèn)值(0，0，0，0)，被解釋為未設(shè)置。當(dāng)未設(shè)置時(shí)，不作出任何調(diào)整，并且忽略Stretch屬性。察看框(ViewBox)為內(nèi)容指定了新坐標(biāo)系統(tǒng)，即，重新定義了察看口(ViewPort)的范圍和原點(diǎn)。Stretch(拉伸)屬性幫助指定那些內(nèi)容如何映射到察看口。Viewbox屬性的值是四個(gè)“無(wú)單位”數(shù)字<min-x>、<min-y>、<width>和<height>的列表，由空格和/或逗號(hào)分隔，并且是Rect類型。ViewBox rect指定了映射到邊框的用戶空間中的矩形。它與插入scaleX和scaleY一樣起作用。Stretch屬性(在選項(xiàng)不同于無(wú)的情況下)提供了用于保持圖形的長(zhǎng)寬比的附加控制。附加變換被應(yīng)用到給定元素的所有子孫元素，以達(dá)到指定的效果。如果在Brush上有變換，則它在ViewBox映射“之上”應(yīng)用。
Stretch屬性具有以下模式None、Fill、Uniform、UniformToFil。
簡(jiǎn)單刷子及其屬性
Path.Brush和Canvas.Brush子元素包括以下SolidColorBrush、ImageBrush和DrawingBrush。
SolidColorBrush用純色填充定義的幾何區(qū)域。如果有顏色的α分量，則將它以相乘的方式與Brush中對(duì)應(yīng)的不透明性屬性組合。
以下示例示出了如何對(duì)SolidColorBrush表達(dá)顏色屬性。<Path>
<Path.Fill>
<SolidColorBrush Color="#00FFFF"/>
</Path.Fill>
...</Path>
ImageBrush可用于用圖像填充空間。ImageBrush的標(biāo)記允許指定URI。如果所有其它屬性被設(shè)為其默認(rèn)值，則將拉伸圖像以填充區(qū)域的邊框。
ImageSource屬性必須引用支持的到達(dá)圖像格式之一或通往這些類型之一的圖像的其中一個(gè)選擇器。
DrawingBrush可用于用矢量圖來(lái)填充空間。DrawingBrush具有Drawing子元素，其使用在以下示出的標(biāo)記中。<Path>
<Path.Fill>
<DrawingBrush>
<DrawingBrush.Drawing>
<Drawing>
<Path.../>
<Glyphs.../>
</Drawing>
</DrawingBrush.Drawing>
</DrawingBrush>
</Path.Fill></Path>
梯度刷子及其屬性
梯度通過(guò)將一組梯度停點(diǎn)(stop)指定為梯度刷子的XML子元素來(lái)繪制。這些梯度停點(diǎn)沿某一類行進(jìn)指定了顏色。本框架中支持兩種類型的梯度刷子線性和徑向。
梯度是通過(guò)在指定的顏色空間內(nèi)的梯度停點(diǎn)之間完成內(nèi)插來(lái)繪制的。LinearGradientBrush和RadialGradientBrush共享以下公用屬性
對(duì)于SpreadMethod屬性，考慮以下內(nèi)容。SpreadMethod選項(xiàng)指定了如何填充空間。默認(rèn)值是Pad。
MappingMode屬性
對(duì)于LinearGradientBrush，考慮以下內(nèi)容。LinearGradientBrush指定了沿一矢量的線性梯度刷子。
以下標(biāo)記示例示出了對(duì)LinearGradientBrush的使用。用線性梯度填充了具有矩形路徑的頁(yè)面
<FixedPaxnel>
<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,0100,1000,100"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Data>
</Path>
</FixedPage>
</FixedPanel>
該示例示出了用線性梯度填充的具有矩形路徑的頁(yè)面。路徑在裁剪它的八邊形的形狀內(nèi)也有裁剪屬性。<FixedPanel>
<FixedPage>
<Path>
<Path.Clip>
<PathGeometry>
<PathFigure>
<StartSegment Point="25,0"/>
<PolyLineSegmentPoints="75,0 100,25 100,75 75,100 25,100 0,75 0,25"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.CliD>
<Path.Fill>
<LinearGradientBrush StartPoint="0,0"EndPoint="1,0">
<LinearGradientBrush.GradientStops>
<GradientStopCollection>
<GradientStoo 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,0100,1000,100"/>
<CloseSegment/>
</PathFigure>
</PathGeometry>
</Path.Data>
</Path>
</FixedPage>
</FixedPanel>
RadialGradient(徑向梯度)在編程模型中與線性梯度相似。然而，線性梯度具有定義梯度矢量的起點(diǎn)和終點(diǎn)，而徑向梯度具有圓周以及焦點(diǎn)來(lái)定義梯度行為。圓周定義了梯度的終點(diǎn)-換言之，1.0的梯度停點(diǎn)定義了圓周周界的顏色。焦點(diǎn)定義了梯度的中心。0.0的梯度停點(diǎn)定義了焦點(diǎn)的顏色。
α和透明性
依照所示并描述的實(shí)施例，每一元素的每一像素?cái)y帶范圍從0.0(完全透明)到1.0(完全不透明)的α值。當(dāng)混合元素以達(dá)到透明性的視覺效果時(shí)，使用α值。
每一元素可具有Opacity(不透明性)屬性，元素的每一像素的α值將與該屬性均勻地相乘。
另外，OpacityMask允許指定每一像素的不透明性，它將控制如何將呈現(xiàn)的內(nèi)容混合成其目標(biāo)。由OpacityMask指定的不透明性與已經(jīng)發(fā)生在內(nèi)容的α通道中存在的任何不透明性用乘法組合。由OpacityMask指定的每一像素的Opacity通過(guò)查找掩模中每一像素的α通道來(lái)確定-忽略顏色數(shù)據(jù)。
OpacityMask的類型是Brush。這允許指定如何以各種不同的方式將Brush的內(nèi)容映射到內(nèi)容的范圍。如用于填充幾何結(jié)構(gòu)那樣，Brush默認(rèn)為填充整個(gè)內(nèi)容空間，在適當(dāng)時(shí)拉伸或復(fù)制其內(nèi)容。這意味著圖像刷將拉伸其圖像源以完全覆蓋內(nèi)容，而梯度刷將從邊延伸到邊。
α混合需要的計(jì)算在先前“Opcity屬性”一節(jié)中描述。
以下示例示出了如何使用OpacityMask在Glyphs元素上創(chuàng)建“漸弱效果”。本示例中的OpacityMask是從不透明的黑漸弱到透明的黑的線性梯度。///content/pl.xml<FixedPage PageHeight="1056"PageWidth="816">
<Glyphs
OriginX="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>
到達(dá)文檔中的圖像
在固定頁(yè)面上，圖像填充了閉合區(qū)域。為將圖像放置在固定頁(yè)面上，首先必須在頁(yè)面上指定區(qū)域。區(qū)域由Path元素的幾何結(jié)構(gòu)來(lái)定義。
Path元素的Fill屬性指定了所描述的區(qū)域的填充內(nèi)容。圖像是填充的一種類型，由圖像耍畫到區(qū)域中。所有的刷子具有默認(rèn)的行為，該行為將通過(guò)在適當(dāng)時(shí)拉伸或重復(fù)(平鋪)刷子內(nèi)容來(lái)填充整個(gè)區(qū)域。在圖像刷的情況下，由ImageSource屬性指定的內(nèi)容將被拉伸以完全覆蓋該區(qū)域。
以下標(biāo)記示出了如何將圖像放到畫布上。<Canvas>
<Path>
<Path.Data>
<GeometryCollection>
...
</GeometryCollection>
</Path.Data>
<Path.Fill>
<ImageBrush ImageSource="/images/dog.jpg"/>
</Path.Fill>
</Path></Canvas>
由于許多圖像是矩形的，包括在資源字典中的矩形路徑元素在簡(jiǎn)化標(biāo)記時(shí)是有用的。路徑然后可使用RenderTransform屬性來(lái)定位(見上文)。<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.RenderTransform><Path Data="{Rectangle}">
<Path.Fill>
<ImageBrush ImageSource="/images/dog.jpg"/>
</Path.Fill>
</Path>
</Canvas></Canvas>
顏色
顏色可以在所示并描述的標(biāo)記中使用scRGB或sRGB表示法來(lái)指定。scRGB規(guī)范被稱為“IEC 61966-2-2scRGB”，并且可從www.iec.ch獲得。
ARGB參數(shù)在下表中描述。
顏色映射
當(dāng)前，考慮了用指定顏色背景的元數(shù)據(jù)來(lái)對(duì)彩色元素加標(biāo)簽。該元數(shù)據(jù)可包含ICC顏色概覽或其它顏色定義數(shù)據(jù)。
<Glyphs>元素
文本在固定有效負(fù)載中使用Glyphs元素來(lái)表示。該元素被設(shè)計(jì)成滿足用于打印和到達(dá)文檔的需求。
Glyphs元素可具有以下屬性的組合。
文本標(biāo)記綜述
字形度量
每一字形定義了指定它如何與其它字形對(duì)齊的度量。依照一個(gè)實(shí)施例的示例性度量在圖12中示出。
前進(jìn)寬度和組合記號(hào)
一般而言，字體內(nèi)的字形是基礎(chǔ)字形或可附加到基礎(chǔ)字形的組合記號(hào)。基礎(chǔ)字形通常具有非零的前進(jìn)寬度，以及0，0的偏移矢量。而組合記號(hào)通常具有零前進(jìn)寬度。偏移矢量可用于調(diào)整組合記號(hào)的位置，并且因此對(duì)組合記號(hào)可具有非0，0值。
字形行程中的每一字形具有控制其位置的三個(gè)值。這些值指示了原點(diǎn)、前進(jìn)寬度和字形偏移，其每一個(gè)描述如下
●原點(diǎn)每一字形被假定給予一名義原點(diǎn)，對(duì)于行程中的第一個(gè)字形，這是行程的原點(diǎn)。
●前進(jìn)寬度每一字形的前進(jìn)寬度提供了下一字形相對(duì)于該字形原點(diǎn)的原點(diǎn)。前進(jìn)矢量總是在行程漸進(jìn)的方向上繪制。
●字形偏移(基礎(chǔ)或記號(hào))字形偏移矢量相對(duì)于其名義原點(diǎn)調(diào)整該字形位置。
字符、字形和群集映射
群集映射對(duì)每一Unicode碼點(diǎn)包含一個(gè)條目。條目中的值是GlyphIndices數(shù)組中表示該碼點(diǎn)的第一個(gè)字形的偏移?；蛘撸?dāng)碼點(diǎn)是一組表示不可見字符群集的碼點(diǎn)的一部分時(shí)，GlyphIndices數(shù)組中的第一個(gè)字形表示代表該群集的第一個(gè)字形的偏移。
群集映射
群集映射可表示碼點(diǎn)一字形映射，它可以是一對(duì)一、多對(duì)一、一對(duì)多或多對(duì)多。一對(duì)一映射是每一碼點(diǎn)僅由一個(gè)字形表示，圖13中的群集映射條目是0、1、2……。
多對(duì)一映射是兩個(gè)或多個(gè)碼點(diǎn)映射到單個(gè)字形。那些碼點(diǎn)的條目指定了字形索引緩沖區(qū)中該字形的偏移。在圖14的示例中，“f”和“i”字符用連字(ligature)來(lái)替換，這在許多襯線字體中是常見的排字慣例。
對(duì)于一對(duì)多映射，結(jié)合圖5考慮以下內(nèi)容?！癝ara Am”包含位于先前的基礎(chǔ)字符(環(huán))上方的部分，以及位于基礎(chǔ)字符(勾)右側(cè)的部分。當(dāng)對(duì)泰文文本進(jìn)行微調(diào)時(shí)，將勾與基礎(chǔ)字符分開，而環(huán)保留在基礎(chǔ)字符的上方，因此許多字體將環(huán)和勾編碼為單獨(dú)的字形。當(dāng)一個(gè)碼點(diǎn)映射到兩個(gè)或多個(gè)字形時(shí)，該碼點(diǎn)的ClusterMap(群集映射)中的值引用GlyphIndeces數(shù)組中表示該碼點(diǎn)的第一個(gè)字形。
對(duì)于多對(duì)多映射，結(jié)合圖16考慮以下內(nèi)容。在某些字體中，字符群集的一組不可見碼點(diǎn)映射到一個(gè)以上字形。例如，這在支持印度語(yǔ)腳本的字體中是常見的。當(dāng)該組不可見碼點(diǎn)映射到一個(gè)或多個(gè)字形時(shí)，每一碼點(diǎn)的ClusterMap中的值引用GlyphIndeces數(shù)組中表示該碼點(diǎn)的第一個(gè)字形。
以下示例示出了泰米爾單詞
的Unicode和字形表示。前兩個(gè)碼點(diǎn)組合在一起以生成三個(gè)字形。
指定群集
群集規(guī)范優(yōu)于非1∶1群集的第一個(gè)字形的字形規(guī)范(映射比一字符對(duì)一字形映射更復(fù)雜)。
每一群集規(guī)范具有以下形式
(ClusterCodepointCount[:ClusterGlyphCount])
<Glyphs>標(biāo)記
Glyphs元素將字體指定為URI、版面索引和一組上述的其它屬性。例如
每一字形規(guī)范具有以下形式[，[Advance][，[uOffset][，[vOffset][，[Flags]]]]]字形規(guī)范的每一部分是可任選的
對(duì)于計(jì)算前進(jìn)而沒有舍入誤差聚積，考慮以下內(nèi)容。每一前進(jìn)值必須被計(jì)算為后來(lái)的字形的未舍入原點(diǎn)減去先前字形的已計(jì)算(即，已舍入)前進(jìn)寬度的總和。以此方式，每一字形被定位到其確切位置的0.5％em之內(nèi)。
字形標(biāo)記示例
優(yōu)化字形標(biāo)記的大小
如果目標(biāo)客戶機(jī)能可靠地重新生成標(biāo)記細(xì)節(jié)，如字形索引和前進(jìn)寬度，則可從標(biāo)記中省略它們。以下選項(xiàng)允許常用簡(jiǎn)單腳本的顯著優(yōu)化。
優(yōu)化字形索引的標(biāo)記
當(dāng)在Unicode串中的字符位置和字形串中的字形位置之間有一對(duì)一映射，并且字形索引是字體的CMAP(字符映射)表中的值，并且Unicode字符有明確的語(yǔ)義時(shí)，字形索引可以從標(biāo)記中省略。
當(dāng)字符到字形的映射時(shí)，應(yīng)當(dāng)在標(biāo)記中提供字形索引
●不是一對(duì)一，如兩個(gè)或多個(gè)碼點(diǎn)形成單個(gè)字形(連字)，或者
●一個(gè)碼點(diǎn)生成多個(gè)字形，或者
●發(fā)生了任一其它形式的字形替換，如通過(guò)OpenType特征的應(yīng)用。
當(dāng)呈現(xiàn)引擎可能替換不同于字體的CMAP(字符映射)表中字形的字形時(shí)，應(yīng)當(dāng)在標(biāo)記中提供字形索引。當(dāng)期望的字形表示不是字體的CMAP表中的字形時(shí)，應(yīng)當(dāng)提供字形索引。
字形位置的優(yōu)化標(biāo)記
當(dāng)所需要的前進(jìn)寬度的確是字體的HMTX(水平度量)或VMTX(垂直度量)表中的字形的前進(jìn)寬度時(shí)，字形前進(jìn)寬度可以從標(biāo)記中省略。
當(dāng)為零時(shí)，字形垂直偏移可以從標(biāo)記中省略。這對(duì)于基礎(chǔ)字符幾乎總是真的，并且對(duì)于較簡(jiǎn)單的腳本中的組合記號(hào)，通常也是真。然而，對(duì)于諸如阿拉伯語(yǔ)和印度語(yǔ)等更復(fù)雜的腳本中的組合記號(hào)，這通常是假。
字形標(biāo)志的優(yōu)化標(biāo)記
對(duì)于具有正常調(diào)整優(yōu)先級(jí)的基礎(chǔ)字形，字形標(biāo)志可以被省略。
應(yīng)用程序接口
以下描述了平臺(tái)無(wú)關(guān)包裝應(yīng)用程序接口(API)的一個(gè)示例實(shí)施例。該API層由抽象類以及作為包裝層的一部分包括在內(nèi)的其它基類構(gòu)成。該API包括以下討論的類。
Container(容器)
容器是將部件集合容納在一起的邏輯實(shí)體。
構(gòu)造函數(shù)
protected Container(FileInfo fileInfo,FileAccess access)
基類的受保護(hù)構(gòu)造函數(shù)。明確地在該類中定義，因此能更容易地證明和維護(hù)該構(gòu)造
函數(shù)。如果不滿足，則編譯器將添加一構(gòu)造函數(shù)。同樣，這是抽象類和子類之間的
當(dāng)前合約。當(dāng)fileInfo對(duì)象為空時(shí)，它定義了容器在流上被打開或創(chuàng)建。
屬性
public virtual DateTime CreationTime{get;set}
獲取或設(shè)置該容器的創(chuàng)建時(shí)間。當(dāng)該值被設(shè)置時(shí)，也應(yīng)當(dāng)將LastAccessTime(最后一次訪問時(shí)間)和LastWriteTime(最后一次寫時(shí)間)更新為同一值。
System_IO_FileInfo對(duì)象用于操縱該值。
異常
-InvalidArgumentException(無(wú)效自變量異常)-如果CreationTime被設(shè)為大于LastAccessTime或LastWriteTime的值。
-InvalidOperationException(無(wú)效操作異常)-如果容器在流上打開，則無(wú)法獲取
這一屬性。
public virtual DateTime LastAccessTime{get;set;}
獲取或設(shè)置該容器被最后一次打開的時(shí)間。System_IO_FileInfo對(duì)象用于操縱該值。
異常
-InvalidArgumentException-如果LastAccessTime被設(shè)為小于CreationTime或LastWriteTime的值。
-InvalidOperationException-如果容器在流上打開，則無(wú)法獲取該屬性。
public virtual DateTime LastWriteTime{get；set}
獲取或設(shè)置最后一次修改該容器的時(shí)間。同樣，當(dāng)更新LastWriteTime時(shí)，應(yīng)當(dāng)將
LastAccessTime更新到同一值。System_IO_FileInfo對(duì)象用于操縱該值。
異常
-InvalidArgumentException-如果LastWriteTime被設(shè)為小于CreationTime的值。
-InvalidOperationException-如果容器在流上打開，則無(wú)法獲取該屬性。
public FileAccess FileOpenAccess{get;}
獲取用于打開容器的FileAccesss(文件訪問權(quán)限)。這是只讀屬性。該屬性在打開
容器時(shí)被設(shè)置。
public abstract Part StartingPart{get;set}
獲取或設(shè)置容器的StartingPart(起始部件)
方法
public static Container OpenOnFile(string path)
OpenOnFile方法的該重載版本將返回在給定路徑上指定的容器。該方法調(diào)用接受
具有以下默認(rèn)值的所有參數(shù)的重載。
FileMode(文件模式)-FileMode.OpenOrCreate
FileAccess(文件訪問權(quán)限)-FileAccess.ReadWrite
FileShare(文件共享)-FileShare.None
public static Container OpenOnFile(string path,FileMode mode)
OpenOnFile方法的這一重載版本將以指定的文件模式返回在給定路徑上指定的容器。該方法調(diào)用接受具有以下默認(rèn)值的所有參數(shù)的重載
FileAccess-FileAccess.ReadWrite
FileShare-FileShare.None
public static Container OpenOnFile(string path,FileMode mode,FileAccess access)
OpenOnFile的該重載版本將以指定的文件模式和文件訪問返回在給定路徑上指定
的容器。該方法調(diào)用接受具有以下默認(rèn)值的所有參數(shù)的重載
FileShare-FileShare.None
public static Container OpenOnFile(string path,FileMode mode,FileAccess access,
FileShare share)
OpenOnfile方法的該重載版本將用設(shè)為提供的值的模式、訪問和共享來(lái)打開給定路
徑上的容器。
異常
-InvalidArgumentException-如果FileMode、FileAccess和FileShare參數(shù)的組合無(wú)意義。
public static Container OpenOnUri(Uri uri)
OpenOnUri方法的該重載版本將返回在給定uri處指定的容器。該方法調(diào)用接受具有以下默認(rèn)值的所有參數(shù)的重載
FileMode-FileMode.Open
FileAccess-FileAccess.Read
public static Container OpenOnUri(Uri uri,FileMode mode)
OpenOnUri的該重載版本將以指定的文件模式返回給定uri處指定的容器。該方法
調(diào)用接受具有以下默認(rèn)值的所有參數(shù)的重載
FileAccess-FileAccess.Read
public static Container OpenOnUri(Uri uri,FileMode mode,FileAccess access)
OpenOnUri方法的該重載版本將用設(shè)為提供的值的模式和訪問打開給定uri處的容
器。WebRequest/WebResponse(web請(qǐng)求/web響應(yīng))機(jī)制將用于獲取容器。FileMode
和FileAccess參數(shù)將應(yīng)用于要打開的容器。該方法調(diào)用具有正確內(nèi)容類型的
OpenOnStream方法。
異常
-InvalidArgumentException-如果FileMode、FileAccess和FileShare參數(shù)的組合無(wú)意義。
public static Container OpenOnStrem(Stream stream,string contentType)
OpenOnStream的該重載版本將在提供的流上返回容器。該方法調(diào)用接受具有以下
默認(rèn)值的所有參數(shù)的重載
FileMode-FileMode.Open
FileAccess-FileAccess.Read
public static Container OpenOnStream(Stream stream,string contentType,FileModemode)
OpenOnStream的該重載版本將以指定的文件模式在提供的流上返回容器。該方法
調(diào)用接受具有以下默認(rèn)值的所有參數(shù)的重載
FileAccess-FileAccess,Read
public static Container OpenOnStream(Stream stream,string contentType,FileModemode,FileAccess access)
OpenOnStream的該重載版本將用設(shè)為提供的值的模式和訪問在提供的流上打開容
器。FileMode和FileAccess參數(shù)將被應(yīng)用于要打開的容器。contentType參數(shù)用于
例示適當(dāng)?shù)淖宇悓?duì)象。
異常
-InvalidArgumentException-如果FileMode、FileAccess和FileShare參數(shù)額度組合無(wú)意義。
public Part AddPart(MMCFUri uri,string contentType)
給定Uri的部件被添加到容器。如果未作出明確的調(diào)用來(lái)讀取或?qū)懭肓?，則該方法
將用空流來(lái)添加部件。該方法調(diào)用完成與物理實(shí)現(xiàn)相關(guān)的實(shí)際工作的AddPartCore。
異常
-InvalidArgumentException-如果對(duì)應(yīng)于該Uri的部件已在容器中存在。
public Part GetPart(MMCFUri uri)
返回給定Uri的部件。uri相對(duì)于容器的根。該方法調(diào)用實(shí)際獲取部件的GetPartCore。
異常
-InvalidArgumentException-如果對(duì)應(yīng)于該Uri的部件在容器中不存在。
public virtual bool Exists(MMCFUri uri)
由于可能令關(guān)系指向仍不存在的目標(biāo)，因此該方法提供了一種方便的方法來(lái)找出部件是否在底層容器中實(shí)際存在。該uri應(yīng)當(dāng)相對(duì)于容器的根。
public void DeletePart(MMCDUri uri)
該方法將從當(dāng)前容器中刪除容器部件。對(duì)于其該部件是源部件的所有關(guān)系也被刪
除。該方法將刪除底層的流，并且將處置對(duì)象。同樣，如果打開了該部件的多個(gè)實(shí)
例，則處置該部件的所有打開的實(shí)例。該方法將做必要的清理來(lái)實(shí)施這一行為，然
而流的實(shí)際刪除對(duì)于底層物理實(shí)現(xiàn)是專用的，并因此調(diào)用了刪除實(shí)際流的
DeletePartCore方法。未完成的部件枚舉器將被無(wú)效。
public PartCollection GetParts()
這返回容器內(nèi)所有部件的集合。不返回關(guān)系。
public void Flush()
該方法在打開的個(gè)別部件上調(diào)用清洗，由此強(qiáng)制了所有的部件和關(guān)系被清洗到底層容器。本質(zhì)上該類將維護(hù)它分發(fā)的所有部件的數(shù)組，然后將在所有的部件上調(diào)用Flush。它然后調(diào)用完成對(duì)整個(gè)容器專用的工作的FlushCore()。
public virtual void Dispose()
所有打開的部件和關(guān)系都被清洗到底層容器。由于該類維護(hù)分發(fā)的所有部件的數(shù)
組，因此該方法將在分發(fā)的所有部件上調(diào)用Dispose()。如果任一其它資源需要被
清洗，則子類應(yīng)當(dāng)覆蓋該方法以完成附加的清洗。
public void Close()
Close方法與處置相同，因此它內(nèi)部地調(diào)用了Dispose()方法。
public Relationship AddRelationship(Uri uri)
該方法添加了容器和由URI指定的部件之間的關(guān)系。它返回Relationship對(duì)象。該
改變進(jìn)在調(diào)用了Flush()方法之后被清洗到底層容器。在同一源和目標(biāo)之間可以有
多個(gè)關(guān)系。所有未完成的關(guān)系枚舉器將被無(wú)效。
public void DeleteRelationship(Relationship relationship)
該方法刪除由Relationship對(duì)象指定的目標(biāo)關(guān)系。該改變進(jìn)在調(diào)用了Flush()方法之后被清洗到底層容器。刪除操作基于對(duì)象的“名字”來(lái)完成，并且因此，每一對(duì)象被唯一地標(biāo)識(shí)。所有未完成的關(guān)系枚舉器被無(wú)效。
異常
-InvalidArgumentException-如果關(guān)系的源不與當(dāng)前部件相同。
public RelationshipCollection GetRelationships()
這從容器返回所有目標(biāo)關(guān)系的集合。當(dāng)在公知的uri上定位了容器的目標(biāo)關(guān)系，則可能提供一默認(rèn)實(shí)現(xiàn)，它將打開關(guān)系部件，然后從流中讀取xml并創(chuàng)建集合對(duì)象(異常-如果從底層容器讀取的XML是畸形的。)
protected abstract Part AddPartCore(MMFCUri uri,string contentType)
該方法用于底層文件格式的自定義實(shí)現(xiàn)。它將從AddPart方法中調(diào)用。這將實(shí)際在底層容器中創(chuàng)建部件?？詹考?yīng)當(dāng)作為該調(diào)用的結(jié)果而被創(chuàng)建。
protected abstract Part GetPartCore(MMCFUri uri)
該方法用于底層文件格式的自定義實(shí)現(xiàn)。它將從GetPart方法中調(diào)用。該方法從底層容器中取出實(shí)際的部件。如果部件不存在，則它返回“空”。
protected abstract void DeletePartCore(MMCFUri uri)
該方法用于底層文件格式的自定義實(shí)現(xiàn)。它應(yīng)當(dāng)實(shí)際刪除對(duì)應(yīng)于該部件的流。同樣，如果不存在對(duì)應(yīng)于給定URI的部件，則它應(yīng)當(dāng)不拋出。
protected abstract Part[]GetPartsCore()
該方法用于底層文件格式的自定義實(shí)現(xiàn)。它應(yīng)當(dāng)返回容器中所有部件的數(shù)組。由于獲取容器中所有部件的方法對(duì)實(shí)際物理格式是專用的，因此該方法是游泳的。提供了該方法，使得實(shí)際的GetParts調(diào)用僅將該數(shù)組傳遞到PartCollection，并且可提供其上的枚舉器。以此方式，PartCollection類可以是有形的類。同樣，如果容器中沒有部件，則GetPartsCore應(yīng)當(dāng)返回空數(shù)組。
protected abstract void FlushCore()
該方法用于底層文件格式的自定義實(shí)現(xiàn)。該方法將所有的內(nèi)容清洗到盤。
protected abstract void DisposeCore()
該方法用于底層文件格式的自定義實(shí)現(xiàn)。該方法應(yīng)當(dāng)釋放對(duì)應(yīng)于實(shí)際物理格式的資源。
Part(部件)
部件包括三個(gè)部分
●URI-相對(duì)于容器的根
●ContentType-它是由該部件表示的流的模仿類型
●Stream-對(duì)應(yīng)于該部件的實(shí)際流
另外部件可用關(guān)系被鏈接到其它部件。關(guān)系中的SourcePart(源部件)擁有該關(guān)系。
構(gòu)造函數(shù)
protected Part(Container container,MMCFUri uri,string contentType)
用于基類的受保護(hù)的構(gòu)造函數(shù)。在該類中明確地定義，使得能更容易地證明和維護(hù)該構(gòu)造函數(shù)。如果不滿足，則編譯器將添加一構(gòu)造函數(shù)。這也是抽象類和子類之間的當(dāng)前合約。
屬性
public MMCFUri Uri{get;}
該屬性返回部件的MMCFUri。這是只讀屬性。
public strig ContentType{get;}
該屬性返回由部件表示的流的內(nèi)容類型。這是只讀屬性。
public Container Container{get;}
該屬性返回部件的父容器。這是只讀屬性。
方法
public Stream GetStream()
該方法返回對(duì)應(yīng)于該部件的流。它調(diào)用接受具有以下默認(rèn)值的所有參數(shù)的重載
FileMode-Open
FileAccess-ReadWrite
public Stream GetStream(FileMode mode)
該方法以指定的模式返回對(duì)應(yīng)于該部件的流。它調(diào)用接受具有以下默認(rèn)值的所有參
數(shù)的重載
FileAccess-ReadWrite
public Stream GetStream(FileMode mode,FileAccess access)
該方法返回對(duì)應(yīng)于該部件的流。它調(diào)用返回實(shí)際流的GetStreamCore方法。該方法完成所需的內(nèi)務(wù)處理以跟蹤所有打開的流。
public abstract Stream GetStreamCore(FileMode mode,FileAccess access)
該方法返回對(duì)應(yīng)于該部件的流。該方法用于自定義實(shí)現(xiàn)。
public Relationship AddRelationship(Uri uri)
該方法添加指定的URI處的部件和當(dāng)前部件之間的關(guān)系。它返回Relationship對(duì)象。
該改變僅在調(diào)用了Flush()方法之后被清洗到底層容器。在同一源和目標(biāo)之間可以
有多個(gè)關(guān)系。所有未完成的關(guān)系枚舉器將被無(wú)效。
異常
-InvalidOperationException-如果當(dāng)前部件是關(guān)系。
public void DeleteRelationship(Relationship relationship)
該方法刪除由Relationship對(duì)象指定的目標(biāo)關(guān)系。該改變僅在調(diào)用了Flush()方法之后被清洗到底層容器。刪除操作基于對(duì)象的“引用”來(lái)完成，并且因此每一對(duì)象被唯一地標(biāo)識(shí)。所有未完成的關(guān)系枚舉器被無(wú)效。
異常
-InvalidArgumentException-如果關(guān)系的源不與當(dāng)前部件相同。
public RelationshipCollection GetRelationships()
這返回該部件的所有目標(biāo)關(guān)系的集合。當(dāng)在公知的uri處定位了該部件的目標(biāo)關(guān)系時(shí)，可能提供一默認(rèn)實(shí)現(xiàn)，它打開關(guān)系部件，然后從流中讀取xml并創(chuàng)建對(duì)象集合(異常一如果從底層容器讀取的XML是畸形的。)
Relationship(關(guān)系)
該類用于表達(dá)源和目標(biāo)部件之間的關(guān)系。創(chuàng)建關(guān)系的唯一方法是調(diào)用Part.AddRelationship(Uri uri)。關(guān)系由源部件擁有，因此如果源部件被刪除，則它所擁有的所有關(guān)系也被刪除。關(guān)系的目標(biāo)不必要存在。
構(gòu)造函數(shù)
internal Relationship(Uri source,Uri target,string name)
返回Relationship對(duì)象。
屬性
public Part Source{get;}
獲取關(guān)系的源部件。這是只讀屬性。當(dāng)創(chuàng)建關(guān)系時(shí)設(shè)置該屬性。
public Uri TargetUri{get;}
獲取關(guān)系的目標(biāo)Uri。該Uri應(yīng)當(dāng)被看作相對(duì)于源uri。
public string Name{get;}
獲取對(duì)應(yīng)于該關(guān)系的名字。
PartCollection(部件集合)
這是容器中部件的集合。
構(gòu)造函數(shù)
internal PartCollection(Dictionary<MMCFUri,Part>partDictionary)
基于Part對(duì)象的類屬字典創(chuàng)建PartCollection。
方法
public IEnumerator GetEnumerator()
IEnumerable接口的成員。它返回部件集合上的枚舉器。
RelationshipColection(關(guān)系集合)
這是與容器中部件相關(guān)聯(lián)的關(guān)系的集合。在給定的源和目標(biāo)部件之間可以有一個(gè)以上關(guān)系。
構(gòu)造函數(shù)
internal RelationshipCollection(Relationship[]relationships)
基于Relationship對(duì)象創(chuàng)建RelationshipCollection
方法
public IEnumerator GetEnumerator()
MMFCUri
該類從URI類繼承。該Uri類的主函數(shù)是確保指定的URI以“/”開始。該類的動(dòng)機(jī)是
1.確保用于每一個(gè)別部件的URI以“/”開始。這確保所有的部件名相對(duì)于容器的根。
2.由于System.Uri類不允許解析兩個(gè)相對(duì)URI，因此他們需要以不同的方式來(lái)解析，因此在一個(gè)地方有這一邏輯是較佳的。
3.強(qiáng)制容器是授權(quán)機(jī)構(gòu)這一事實(shí)。由此，任何相對(duì)引用應(yīng)當(dāng)不被解析成容器外部的位置。
4.
構(gòu)造函數(shù)
public MMCFUri(string uri)
從提供的uri串創(chuàng)建MMCFUri。確保該Uri是相對(duì)的且以“/”開始。
異常-InvalidArgumentException-如果URI包括主機(jī)名和協(xié)議，即，它是絕對(duì)URI。
public MMCFUri(MMCFUri baseUri,string relativeUri)從提供的Uri對(duì)象和relativeUri(相對(duì)URI)串創(chuàng)建MMCFUri對(duì)象。相對(duì)于baseUri(基礎(chǔ)URI)解析相對(duì)uri。確保Uri是相對(duì)的，且以“/”開始。異常-InvalidArgumentException-如果URI包括主機(jī)名和協(xié)議，即它是絕對(duì)URI。
代碼示例
其它API細(xì)節(jié)
OpenOnFile、OpenOnUri和OpenOnStream方法
這些方法具有硬編碼的邏輯，并且這些方法知道的唯一物理容器格式是復(fù)合文件實(shí)現(xiàn)。由于擁有這些類，因此有關(guān)于從這些靜態(tài)方法調(diào)用的子類構(gòu)造函數(shù)的假設(shè)。同樣，這些靜態(tài)方法基于文件擴(kuò)展名或當(dāng)前流的內(nèi)容類型例示正確的子類對(duì)象。
OpenOnStream方法和對(duì)容器指定的訪問的含義
當(dāng)在流上創(chuàng)建容器時(shí)，重要的是確保對(duì)容器指定的FileAccess與提供的流兼容。以下表格列出了各種可能性以及如何處理它們的示例。
在第一行中，流具有更多的訪問，而希望創(chuàng)建更受限制的容器，因此用稱為RestrictedStream的私有流包裝傳入的流，該私有流具有適當(dāng)?shù)哪茏x和能寫值。
Part和Relationship對(duì)象的存儲(chǔ)器中高速緩存
字典維持所有的部件可訪問，并且如果第二次要求部件，則返回從字典對(duì)該部件的引用。這是更有效的，并且因?yàn)镻art對(duì)象是不變的，這可以沒有任何問題地完成。它也應(yīng)用于Relationship對(duì)象。然而，如果底層容器以共享的寫模式打開，并且有第二用戶向底層容器添加或刪除了部件，則這些改變將不會(huì)在高速緩存中得到反映。
總結(jié)
上述模塊化內(nèi)容框架和文檔格式方法和系統(tǒng)提供了一組構(gòu)件塊，用于組成、包裝、分發(fā)和呈現(xiàn)以文檔為中心的內(nèi)容。這些構(gòu)件塊定義了用于文檔格式的平臺(tái)無(wú)關(guān)框架，使軟件和硬件系統(tǒng)能夠可靠和一致地生成、交換和顯示文檔。所示并描述的到達(dá)包格式提供了一種用于以可用各種各樣環(huán)境中的設(shè)備和應(yīng)用程序之間的完全保真度并且跨各種各樣情形來(lái)顯示或打印到達(dá)包的內(nèi)容的方式儲(chǔ)存已編頁(yè)碼或預(yù)編頁(yè)碼的文檔的格式。盡管以對(duì)結(jié)構(gòu)特征和/或方法步驟專用的語(yǔ)言描述了本發(fā)明，然而可以理解，所附權(quán)利要求書中定義的本發(fā)明不必要限于所描述的特征或步驟。相反，揭示了具體特征和步驟作為實(shí)現(xiàn)要求保護(hù)的本發(fā)明的較佳形式。
權(quán)利要求
1.一種方法，其特征在于，包括
創(chuàng)建定義文檔的包，其中，所述文檔包括構(gòu)成所述文檔的多個(gè)部件，其中，所述多個(gè)部件的每一個(gè)具有一相關(guān)聯(lián)的名字和一相關(guān)聯(lián)的內(nèi)容類型；以及
提供與所述包相關(guān)聯(lián)的多個(gè)驅(qū)動(dòng)程序，其中，所述多個(gè)驅(qū)動(dòng)程序與不同的文檔格式相關(guān)聯(lián)，并且其中，所述多個(gè)驅(qū)動(dòng)程序允許多個(gè)應(yīng)用程序訪問所述包，而與所述多個(gè)應(yīng)用程序的每一個(gè)相關(guān)聯(lián)的文檔格式無(wú)關(guān)。
2.如權(quán)利要求1所述的方法，其特征在于，與每一部件相關(guān)聯(lián)的名字是唯一的。
3.如權(quán)利要求1所述的方法，其特征在于，與每一部件相關(guān)聯(lián)的名字包括分層地址。
4.如權(quán)利要求1所述的方法，其特征在于，與每一部件相關(guān)聯(lián)的名字包括統(tǒng)一資源標(biāo)識(shí)符的本地部分。
5.如權(quán)利要求1所述的方法，其特征在于，與每一部件相關(guān)聯(lián)的內(nèi)容類型包括包含在所述部件內(nèi)的信息類型的描述。
6.如權(quán)利要求1所述的方法，其特征在于，所述多個(gè)部件的每一個(gè)映射到一特定文件。
7.如權(quán)利要求1所述的方法，其特征在于，所述多個(gè)部件儲(chǔ)存在單個(gè)文件中。
8.如權(quán)利要求1所述的方法，其特征在于，所述驅(qū)動(dòng)程序的至少一個(gè)還與不同的通信協(xié)議相關(guān)聯(lián)。
9.如權(quán)利要求8所述的方法，其特征在于，所述多個(gè)驅(qū)動(dòng)程序允許所述多個(gè)應(yīng)用程序訪問所述包，而無(wú)論與所述多個(gè)應(yīng)用程序的每一個(gè)相關(guān)聯(lián)的通信格式是什么。
10.如權(quán)利要求8所述的方法，其特征在于，所述多個(gè)驅(qū)動(dòng)程序允許所述多個(gè)應(yīng)用程序訪問所述包，而無(wú)論與所述多個(gè)應(yīng)用程序的每一個(gè)相關(guān)聯(lián)的文件格式是什么的。
11.如權(quán)利要求1所述的方法，其特征在于，所述多個(gè)部件的每一個(gè)還具有一組相關(guān)聯(lián)的關(guān)系。
12.如權(quán)利要求1所述的方法，其特征在于，構(gòu)成所述文檔的所述多個(gè)部件包括具有第一相關(guān)聯(lián)內(nèi)容類型的第一部件，以及具有第二相關(guān)聯(lián)內(nèi)容類型的第二部件。
13.如權(quán)利要求1所述的方法，其特征在于，內(nèi)容類型數(shù)據(jù)被儲(chǔ)存在與所述包相關(guān)聯(lián)的文件中。
14.如權(quán)利要求1所述的方法，其特征在于，還包括將所述包提供到一介質(zhì)上，消費(fèi)者可從所述介質(zhì)消費(fèi)所述包。
15.一個(gè)或多個(gè)其上具有計(jì)算機(jī)可讀指令的計(jì)算機(jī)可讀介質(zhì)，當(dāng)所述指令被執(zhí)行時(shí)，實(shí)現(xiàn)權(quán)利要求1所述的方法。
16.一種包含權(quán)利要求15所述的計(jì)算機(jī)可讀介質(zhì)的計(jì)算系統(tǒng)。
17.一種方法，其特征在于，包括
接收包括多個(gè)部件的包，其中，所述多個(gè)部件的每一個(gè)被唯一地標(biāo)識(shí)，并且通過(guò)一相關(guān)聯(lián)的名字可訪問；
標(biāo)識(shí)與所接收的包相關(guān)聯(lián)的驅(qū)動(dòng)程序；以及
由應(yīng)用程序使用與所接收的包相關(guān)聯(lián)的驅(qū)動(dòng)程序處理所接收的包。
18.如權(quán)利要求17所述的方法，其特征在于，所述多個(gè)部件的每一個(gè)由統(tǒng)一資源標(biāo)識(shí)符的本地部分來(lái)標(biāo)識(shí)。
19.如權(quán)利要求17所述的方法，其特征在于，所述多個(gè)部件的每一個(gè)具有一相關(guān)聯(lián)的內(nèi)容類型，它包括包含在所述部件內(nèi)的數(shù)據(jù)類型的描述。
20.如權(quán)利要求17所述的方法，其特征在于，與所接收的包相關(guān)聯(lián)的驅(qū)動(dòng)程序也與一特定通信協(xié)議相關(guān)聯(lián)。
21.如權(quán)利要求17所述的方法，其特征在于，與所接收的包相關(guān)聯(lián)的驅(qū)動(dòng)程序也與一特定文件格式相關(guān)聯(lián)。
22.如權(quán)利要求17所述的方法，其特征在于，還包括標(biāo)識(shí)與所接收的包相關(guān)聯(lián)的一組關(guān)系。
23.一個(gè)或多個(gè)其上具有計(jì)算機(jī)可讀指令的計(jì)算機(jī)可讀介質(zhì)，當(dāng)所述指令被執(zhí)行時(shí)，實(shí)現(xiàn)權(quán)利要求17所述的方法。
24.一種包含權(quán)利要求23所述的計(jì)算機(jī)可讀介質(zhì)的計(jì)算系統(tǒng)。
25.一種在一個(gè)或多個(gè)計(jì)算機(jī)可讀介質(zhì)上實(shí)施的應(yīng)用程序接口，其特征在于，包括
展示創(chuàng)建包的第一方法，其中，所述包將多個(gè)部件容納在一起；
展示向所述包添加第一部件的第二方法；
展示從所述包接收第二部件的第三方法；以及
展示標(biāo)識(shí)數(shù)據(jù)流的第四方法。
26.如權(quán)利要求25所述的應(yīng)用程序接口，其特征在于，所述包具有一相關(guān)聯(lián)的統(tǒng)一資源標(biāo)識(shí)符。
27.如權(quán)利要求25所述的應(yīng)用程序接口，其特征在于，所述第一方法具有相關(guān)聯(lián)的文件訪問參數(shù)。
28.如權(quán)利要求25所述的應(yīng)用程序接口，其特征在于，所述第一方法具有相關(guān)聯(lián)的文件共享參數(shù)。
29.如權(quán)利要求25所述的應(yīng)用程序接口，其特征在于，所述數(shù)據(jù)流具有一相關(guān)聯(lián)的內(nèi)容類型。
30.如權(quán)利要求25所述的應(yīng)用程序接口，其特征在于，還包括從所述包中刪除現(xiàn)有部件的第五方法。
31.一種在一個(gè)或多個(gè)計(jì)算機(jī)可讀介質(zhì)上實(shí)施的應(yīng)用程序接口，其特征在于，包括
調(diào)用標(biāo)識(shí)包含在包內(nèi)的多個(gè)部件的第一方法；
調(diào)用向所述包添加新部件的第二方法；
調(diào)用標(biāo)識(shí)與包含在所述包內(nèi)的部件之一相關(guān)聯(lián)的數(shù)據(jù)流的第三方法。
32.如權(quán)利要求31所述的應(yīng)用程序接口，其特征在于，還包括調(diào)用檢索包含在所述包內(nèi)的多個(gè)部件之一的第四方法。
33.如權(quán)利要求31所述的應(yīng)用程序接口，其特征在于，所述包具有相關(guān)聯(lián)的文件訪問參數(shù)和文件共享參數(shù)。
34.如權(quán)利要求31所述的應(yīng)用程序接口，其特征在于，還包括調(diào)用標(biāo)識(shí)與所述數(shù)據(jù)流相關(guān)聯(lián)的內(nèi)容類型的第四方法。
全文摘要
描述了模塊化內(nèi)容框架和文檔格式方法和系統(tǒng)。描述的框架和格式定義了一組構(gòu)件塊，用于組成、包裝、分發(fā)和呈現(xiàn)以文檔為中心的內(nèi)容。這些構(gòu)件塊定義了用于文檔格式的平臺(tái)無(wú)關(guān)框架，使軟件和硬件系統(tǒng)能夠可靠并一致地生成、交換和顯示文檔。該框架和格式用靈活和可擴(kuò)充的方式來(lái)設(shè)計(jì)。除該通用框架和格式之外，使用該通用框架定義了一種被稱為到達(dá)包的特定格式。到達(dá)包格式是用于儲(chǔ)存已編頁(yè)碼文檔的格式。到達(dá)包的內(nèi)容可以用各種各樣環(huán)境內(nèi)的設(shè)備和應(yīng)用程序之間的完全保真度并跨各種各樣情形來(lái)顯示或打印。
文檔編號(hào)G06F17/24GK1823330SQ200480001339
公開日2006年8月23日 申請(qǐng)日期2004年7月29日 優(yōu)先權(quán)日2004年4月30日
發(fā)明者A·舒爾, J·杜尼茲, O·弗爾, D·埃默森, M·希爾波格, Y·G·金, J·波洛克, S·謝斯, D·奧恩斯坦, J·潘利, B·瓊斯 申請(qǐng)人:微軟公司