KR20110057224A - 사전-페이지화된 문서들을 포함하는 패키지들을 구성하는 방법들 및 시스템들 - Google Patents

Abstract

모듈식 내용 프레임워크 및 문서 포맷 방법들 및 시스템들이 설명된다. 설명된 프레임워크 및 포맷은 문서-중심 내용을 구성, 패키지화, 분산, 및 렌더링하기 위한 한 세트의 구성 블록들을 정의한다. 이들 구성 블록들은, 소프트웨어 및 하드웨어 시스템들이 문서들을 확실하고 일관되게 생성, 교환, 및 디스플레이하는 것을 가능하게 하는 문서 포맷들을 위한 플랫폼-독립형 프레임워크를 정의한다. 프레임워크 및 포맷은 유연하고 확장 가능한 방식으로 설계되었다. 이러한 일반적 프레임워크 및 포맷 이외에, 리치 패키지 포맷으로 알려져 있는 특정 포맷이 일반적 프레임워크를 사용해 정의된다. 리치 패키지 포맷은 페이지화된 문서들을 저장하기 위한 포맷이다. 리치 패키지의 내용들은 광범위한 환경들 및 광범위한 상황들의 장치들 및 애플리케이션들 사이에서 완벽한 충실도로 디스플레이되거나 프린트될 수 있다.

Description

사전-페이지화된 문서들을 포함하는 패키지들을 구성하는 방법들 및 시스템들 {METHODS AND SYSTEMS FOR BUILDING PACKAGES THAT CONTAIN PRE-PAGINATED DOCUMENTS}

본 발명은 내용 프레임워크, 문서 포맷, 및 양자를 이용할 수 있는 관련 방법들 및 시스템들에 관한 것이다.

오늘날에는, 통상적으로, 내용을 표현하기 위한 많은 타 유형의 내용 프레임워크들 및 다양한 유형의 문서들을 포매팅하기 위한 많은 타 유형의 문서 포맷들이 존재한다. 많은 경우, 이들 프레임워크들 및 포맷들 각각은, 관련 문서를 구성, 생성, 프로세싱, 또는 소비하기 위해, 고유한 관련 소프트웨어를 필요로 한다. 특정한 관련 소프트웨어를 적합한 장치에 설치한 사람들에게는, 관련 문서들을 구성, 생성, 프로세싱, 또는 소비하는 것이 그다지 어렵지 않다. 적합한 소프트웨어를 설치하지 않은 사람들에게는, 관련 문서들을 구성, 생성, 프로세싱, 또는 소비하는 것은 통상적으로 불가능하다.

이러한 배경에도 불구하고, 문서들의 생성 및 소비에 관한 한 편재성(ubiquity)에 대한 필요성이 계속적으로 존재한다.

발명의 요약

모듈식 내용 프레임워크 및 문서 포맷 방법들 및 시스템들이 설명된다. 설명된 프레임워크 및 포맷은 문서-중심 내용을 구성, 패키지화, 분산, 및 렌더링하기 위한 한 세트의 구성 블록들을 정의한다. 이들 구성 블록들은, 소프트웨어 및 하드웨어 시스템들이 문서들을 확실하고 일관되게 생성, 교환, 및 디스플레이하는 것을 가능하게 하는 문서 포맷들을 위한 플랫폼-독립형 프레임워크를 정의한다. 프레임워크 및 포맷은 유연하고 확장 가능한 방식으로 설계되었다.

이러한 일반적 프레임워크 및 포맷 이외에, 리치 패키지 포맷(reach package format)으로 알려져 있는 특정 포맷이 일반적 프레임워크를 사용해 정의된다. 리치 패키지 포맷은 페이지화된 문서들을 저장하기 위한 포맷이다. 리치 패키지의 내용들은 광범위한 환경들 및 광범위한 상황들의 장치들 및 애플리케이션들 사이에서 완벽한 충실도로 디스플레이되거나 프린트될 수 있다.

도 1은 일 실시예에 따른 예시적 프레임워크 및 포맷의 컴포넌트들에 대한 블록도이다.
도 2는 일 실시예에 따른 다수 부분들을 구비한 문서들을 보유하는 예시적 패키지의 블록도이다.
도 3은, 일 실시예에 따른, 패키지를 생성하는 예시적 기입기 및 패키지를 판독하는 판독기를 도시하는 블록도이다.
도 4는 3개의 개별적인 페이지들을 함께 바인딩하는 예시적 부분을 도시한다.
도 5는, 일 실시예에 따른, 보고서의 영어 표현 및 불어 표현 모두를 포함하는 재정 보고서를 생성하도록 구성된 예시적 선택기 및 시퀀스들을 도시하는 블록도이다.
도 6은, 일 실시예에 따른, 패키지에 관해 통신하기 위해 함께 작업하는 기입기들 및 판독기들의 일부 예들을 도시한다.
도 7은 문서 다수 부분들을 인터리빙하는 일례를 도시한다.
도 8 및 도 9는 도 7에 나타낸 문서의 다수 부분들을 패키지화하는 상이한 예들을 도시한다.
도 10은, 일 실시예에 따른, 예시적 리치 패키지 및 패키지를 구성하거나 패키지에서 찾아볼 수 있는 부분들에 대한 유용한 유형들 각각을 도시한다.
도 11은, 일 실시예에 따른, CLR 개념들(Common Language Runtime concepts)의 XML로의 예시적 매핑을 도시한다.
도 12는 일 실시예에 따른 수직 및 측면의 글리프 메트릭들을 도시한다.
도 13은 일 실시예에 따른 일-대-일 클러스트 맵(cluster map)을 도시한다.
도 14는 일 실시예에 따른 다-대-일 클러스트 맵을 도시한다.
도 15는 일 실시예에 따른 일-대-다 클러스트 맵을 도시한다.
도 16은 일 실시예에 따른 다-대-다 클러스트 맵을 도시한다.

개요

본 명세서는 모듈식 내용 프레임워크 및 문서 포맷을 설명한다. 프레임워크 및 포맷은 문서-중심 내용(document-centered content)을 구성, 패키지화, 분배, 및 렌더링하기 위한 한 세트의 구성 블록들을 정의한다. 이들 구성 블록들은, 소프트웨어 및 하드웨어 시스템들이 신뢰할 수 있게 그리고 일관되게 문서들을 생성, 교환, 및 디스플레이하는 것을 가능하게 하는, 문서 포맷들을 위한 플랫폼-독립형 프레임워크를 정의한다. 프레임워크 및 포맷은 유연하며 확장 가능한 방식으로 설계되었다. 다양한 실시예들에서, 포함될 수 있는 내용 유형, 내용이 표현되는 방법, 또는 내용을 핸들링하기 위한 클라이언트들이 구축될 플랫폼에 대한 제한은 없다.

이러한 일반적 프레임워크 이외에, 일반적 프레임워크를 사용해 특정 포맷이 정의된다. 이 포맷을 본 명세서는 리치 패키지 포맷이라 하는데, 페이지화된 또는 사전-페이지화된 문서들을 저장하기 위한 포맷이다. 리치 패키지의 내용들은 광범위한 환경들 및 광범위한 상황들의 장치들 및 애플리케이션들 사이에서 완벽한 충실도로 디스플레이되거나 프린트될 수 있다.

다음에 설명된 프레임워크의 목적들 중 하나는 후술하는 프레임워크 및 포맷에 따라 생성된 내용을 판독하거나 기입하는 독립적으로-기입된 소프트웨어 및 하드웨어 시스템들의 상호 작용성(interoperability)을 보장하는 것이다. 이러한 상호 작용성을 실현하기 위해, 설명된 포맷들은, 내용을 판독하거나 기입하는 시스템들이 충족시켜야 할 형식적 요구 사항들을 정의한다.

이하의 논의는 다음의 방향들을 따라 조직되며, "프레임워크" 및 "리치 패키지 포맷"이라는 명칭의 2개의 주요 섹션들로 제시된다.

"프레임워크"라는 명칭의 섹션은 예시적인 패키지 모델을 제시하며 프레임워크 패키지들을 구성하는 다양한 부분들 및 관계들을 설명한다. 기술적 메타데이터(descriptive metadata)를 프레임워크 패키지들에 사용하는 것에 관한 정보가 논의될 뿐만 아니라, 물리적 컨테이너들로 매핑하고, 프레임워크 마크업을 확장하는 프로세스, 및 프레임워크 버전 관리 메커니즘들의 사용이 논의된다.

"리치 패키지 포맷"이라는 명칭의 섹션은 리치 패키지라고 하는 특정 유형의 프레임워크-구축형 패키지에 대한 구조를 조사한다. 또한, 이 섹션은 고정 페이로드가 특징인 패키지 부분들을 설명하며 리치 패키지 마크업 모델 및 드로잉 모델(drawing model)을 정의한다. 이 섹션은 도시된 샘플들과 함께 예시적인 리치 마크업 요소들 및 그들의 특성들로 종결된다.

다음의 논의에 대한 높은 수준의 개요로서, 100에서 본 발명의 프레임워크 및 포맷에 대한 관점들을 대략적으로 도시하는 도 1을 참고한다. 102에는 프레임워크에 대한 소정의 예시적 컴포넌트들이 도시되어 있으며, 104에는 리치 패키지 포맷의 소정 컴포넌트들이 도시되어 있다.

프레임워크(102)는, 각각이 보다 상세히 후술되어 있는, 관계 컴포넌트, 장착식(pluggable) 컨테이너 컴포넌트, 인터리빙/스트리밍 컴포넌트, 및 버전 관리/확장 가능 컴포넌트를, 제한 없이, 포함하는 예시적 컴포넌트들을 구비한다. 리치 패키지 포맷(104)은, 선택기/순서기 컴포넌트 및 패키지 마크업 정의 컴포넌트를 포함하는 컴포넌트들을 구비한다.

다음의 논의에서는, 독자들이, 설명된 컴포넌트들이 프레임워크 및 패키지 포맷의 어디에 적합한 것인지에 대한 통찰력을 보유할 수 있도록 하기 위해, 도 1을 주기적으로 재참조할 것이다.

프레임워크

다음의 논의에서는, 일반적 프레임워크가 설명된다. 개개의 일차적인 하부-제목들로는 "패키지 모델", "구성 부분들: 선택기 및 순서기", "기술적 메타데이터", "물리적 모델", "물리적 매핑들", 및 "버전 관리 및 확장성"이 포함되어 있다. 일차적인 하부-제목 각각은 하나 이상의 관련된 하부-제목들을 가진다.

패키지 모델

이 섹션은 패키지 모델을 설명하며, 패키지들 및 부분들, 드라이버들, 관계들, 패키지 관계들, 및 시작 부분을 설명하는 하부-제목들을 포함한다.

패키지들 및 부분들

도시되고 설명된 모델에서, 내용은 패키지내에 보유된다. 패키지는, 관련 부분들의 집합을 보유하는 논리적 엔티티이다. 패키지의 목적은, 문서의 모든 부분들(또는 내용의 다른 유형들)을 프로그래머들 또는 최종-사용자들이 작업하기에 용이한 하나의 오브젝트로 모으는 것이다. 예를 들어, 문서를 표현하는 XML 마크업 부분(202), 문서에 사용된 폰트를 설명하는 폰트 부분(204), 문서의 페이지들을 설명하는 다수의 페이지 부분들(206), 및 문서내의 영상을 표현하는 영상 부분을 포함하는 다수 부분들을 구비하는 문서를 보유하는 예시적 패키지(200)를 도시하는 도 2를 참조한다. 문서를 표현하는 XML 마크업 부분(202)은, 패키지의 전체 내용을 파싱할 필요없이, 용이한 검색 능력 및 참조를 허용할 수 있다는 것에 이점이 있다. 다음에서 이것을 좀더 명확히 알 수 있을 것이다.

이 명세서 전체에 걸쳐, (소비자들이라고도 하는) 판독기들 및 (생산자들이라고도 하는) 기입기들의 개념이 도입되고 논의된다. 판독기는, 그 용어가 본 명세서에서 사용되는 바와 같이, 모듈식 내용 포맷-기반 파일들 또는 패키지들을 판독하는 엔티티를 의미한다. 기입기는, 그 용어가 본 명세서에서 사용되는 바와 같이, 모듈식 내용 포맷-기반 파일들 또는 패키지들을 기입하는 엔티티를 의미한다. 일례로서, 패키지를 생성하는 기입기 및 패키지를 판독하는 판독기를 나타내는 도 3을 참조한다. 통상적으로, 기입기 및 판독기는 소프트웨어로서 구현될 것이다. 하나 이상의 실시예에서, 패키지들을 생성하고 포매팅하는 것과 관련된 프로세싱 오버헤드 및 복잡한 것들의 대부분은 기입기에 해당된다. 이것은, 반대로, 판독기들로부터 프로세싱 복잡성 및 오버헤드를 제거하는데, 당업자라면 알 수 있는 바와 같이, 이것이 많은 현재 모델들의 출발점이다. 다음에서 이러한 관점이 명백해 질 것이다.

하나 이상의 실시예에 따르면, 하나의 패키지는 패키지에 보유된 내용에 대한 하나 이상의 표현들을 포함한다. 대개 패키지는, 본 명세서에서 컨테이너(container)라고 하는 하나의 파일일 것이다. 이것은 최종-사용자들에게, 예를 들어, 그들의 문서들을 문서의 모든 컴포넌트 부분들(예를 들어, 이미지들, 폰트들, 데이터, 등)과 함께 분배하기에 편리한 방법을 제공한다. 패키지들이 종종 하나의 파일에 직접적으로 대응되기도 하지만, 항상 그래야 하는 것은 아니다. 패키지는, 물리적으로 다양한 방법(예를 들어, 제한없이, 하나의 파일, 낱개로 된 파일들의 집합(collection of loose files), 데이터베이스, 네트워크 접속을 통한 순간 전송 등)으로 표현될 수 있는 논리적 엔티티이다. 따라서, 컨테이너들이 패키지들을 보유하지만, 모든 패키지들이 컨테이너에 저장되는 것은 아니다.

추상적 모델이 임의의 물리적 저장 메커니즘과는 무관하게 패키지들을 설명한다. 예를 들어, 추상적 모델은, "파일들", "스트림들", 또는 패키지가 배치되는 물리적 세계에 관련된 다른 물리적 용어들을 의미하지 않는다. 후술하는 바와 같이, 추상적 모델로 인해, 사용자들은 다양한 물리적 포맷들, 통신 프로토콜들 등을 위한 드라이버들을 생성할 수 있다. 마찬가지로, 애플리케이션이 이미지를 프린트하고자 할 경우, 애플리케이션은 (특정 종류의 프린터를 인식하는 드라이버로써 표현되는) 추상적 개념의 프린터를 사용한다. 따라서, 애플리케이션이 구체적인 프린팅 장치 또는 프린팅 장치와의 통신 방법에 관해 알고 있어야 할 필요는 없다.

컨테이너는, 그렇지 않다면, 낱개로 된, 분리된 파일들의 집합일 수 있는 것에 비해 많은 이점들을 제공한다. 예를 들어, 유사한 컴포넌트들이 모일 수 있으며 내용은 인덱싱되고 압축될 수 있다. 또한, 컴포넌트들간의 관계가 식별될 수 있으며 권한 관리, 디지털 서명들, 암호화, 및 메타데이터가 컴포넌트들에 적용될 수 있다. 물론, 컨테이너들은, 위에서 구체적으로 열거하지 않은 다른 특징들을 위해 그리고 다른 특징들을 구현하는데 사용될 수도 있다.

공통 부분 특성들

도시되고 설명된 실시예에서, 부분은 공통 특성들(예를 들어, 이름) 및 바이트들의 스트림을 구비한다. 이것은 파일 시스템의 파일 또는 HTTP 서버의 리소스와 유사하다. 그것의 내용 이외에, 각각의 부분은 일부의 공통 부분 특성들을 가진다. 이들은, 부분의 이름인 이름 및 부분에 저장되어 있는 내용의 유형인 내용 유형을 포함한다. 또한, 부분들은, 후술하는 바와 같이, 하나 이상의 관련된 관계들을 가질 수 있다.

부분 이름들은, 필요할 때마다 어떤 방식으로 부분을 언급하는데 사용된다. 도시되고 설명된 실시예에서, 이름들은, 파일 시스템의 경로들 또는 URI들의 경로들과 유사한 계층 구조로 조직된다. 다음의 부분 이름들의 예들이다.

/document.xml

/ticket/ticket.xml

/images/march/summer.jpeg

/pages/page4.xml

이로부터 알 수 있는 바와 같이, 부분 이름들은 다음의 특징들을 가진다.

ㆍ 부분 이름들은 기존 파일 시스템의 파일 이름들과 유사하다.

ㆍ 부분 이름들은 '/'(forward slash)로 시작한다.

ㆍ 파일 시스템의 경로들 또는 URI의 경로들과 마찬가지로, 부분 이름들은 한 세트의 디렉토리형 이름들(상기 예들에서의 tickets, images/march, 및 pages)에 의해 계층 구조로 조직될 수 있다.

ㆍ 이 계층 구조는 사선들로써 구분된 세그먼트들로 이루어져 있다.

ㆍ 이름의 마지막 세그먼트는 기존 파일 시스템의 파일명과 유사하다.

부분들의 명명 규칙들, 특히 부분 이름들로 사용될 수 있는 유효 문자들이 본 명세서에서 설명된 프레임워크 특정적이라는 것을 알아 두는 것이 중요하다. 이러한 부분 이름 규칙들은 인터넷-표준 URI 명명 규칙들에 기초하고 있다. 이 실시예에 따르면, 이 실시예에서 부분 이름들을 특정하는데 사용된 문법은 RFC2396, (Uniform Resource Identifiers (URI: Generic Syntax) 명세서)의 섹션 3.3 (Path Component) 및 5 (Relative URI References)에서 정의된 abs _ path 구문과 정확하게 매칭된다.

다음의 추가적인 제한들은 유효한 부분 이름으로서 abs _ path에 적용된다.

ㆍ 섹션들 3 (URI Syntactic Components) 및 3.4 (Query Component)에 정의된 바와 같은, 질의 컴포넌트는 부분 이름으로 적용될 수 없다.

ㆍ 섹션 4.1 (Fragment Identifier)에서 설명된 바와 같은, 단락 식별자는 부분 이름으로 적용될 수 없다.

ㆍ 어떤 부분도 기존 부분의 부분 이름에 *("/" 세그먼트)를 첨부하는 것에 의해 생성된 이름을 갖는 것은 불법이다.

부분 이름들을 위한 문법은 다음과 같다.

패키지의 모든 부분들에 대한 이름들의 세그먼트들은 트리를 형성한다는 것을 알 수 있다. 이것은 파일 시스템들의 경우에서와 유사한데, 트리의 모든 비-리프 노드들(non-leaf nodes)이 폴더들이고 리프 노드들이 내용을 포함하는 실제 파일들이다. 이름 트리의 이들 폴더형 노드들(즉, 비-리프 노드들)은 패키지의 부분들을 조직하는 것과 유사한 기능을 한다. 그러나, 이들 "폴더들"은 명명 계층 구조에서의 개념으로서만 존재한다 - 이들이 영속적인 포맷의 다른 명시를 갖는 것은 아니라는 것을 기억해야 한다.

부분 이름들은 "폴더" 레벨에 존재할 수 없다. 구체적으로, 부분 명명 계층 구조에서의 비-리프 노드들("폴더")은 부분 및 동일한 이름을 가진 하부 폴더를 포함할 수 없다.

도시되고 설명된 실시예에서, 모든 부분은, 어떤 유형의 내용이 부분에 저장되어 있는지를 식별하는 내용 유형을 가진다. 내용 유형들의 예로는 다음과 같은 것들을 들 수 있다.

image/jpeg

text/xml

text/plain;charset="us-ascii"

RFC2045 (Multipurpose Internet Mail Extensions; (MIME))에 정의된 바와 같은 내용 유형들이 도시된 프레임워크에 사용된다. 구체적으로, 각각의 내용 유형은 매체 유형(예를 들어, 텍스트), 세부 유형(예를 들어, 평문), 및 키=값 형태인 파라미터들(예를 들어, charset="us-ascii";다수 파라미터들은 세미콜론으로 구별된다)의 선택 가능한 세트를 포함한다.

부분 주소화( Part Addressing )

종종 부분들은 다른 부분들에 대한 참조들을 포함할 것이다. 간단한 예로서, 마크업 파일 및 이미지의 2개 부분들을 가진 컨테이너를 가정한다. 마크업 파일은, 마크업 파일이 프로세싱될 때, 관련 이미지가 식별되어 배치될 수 있도록 하기 위해, 이미지에 대한 참조를 보유하려 할 것이다. 내용 유형들 및 XML 스키마들의 설계자들은 이러한 참조들을 표현하기 위해 URI들을 사용할 수 있다. 이것을 가능하게 하기 위해, 부분 이름 세계와 URI 세계간의 매핑이 정의될 필요가 있다.

URI들이 패키지에 사용될 수 있도록 하기 위해서는, 패키지-기반 내용의 URI들을 평가할 때, 패키지 자체는 URI 참조들을 위한 "출전"으로 취급되어야 하고 URI를 위한 경로 컴포넌트는 패키지의 부분 이름 계층 구조를 항행하는데 사용된다는 특수한 URI 해석 규칙이 사용되어야 한다.

예를 들어, http://www.example.com/foo/something.package의 패키지 URI가 주어진다면, /abc/bar.xml에 대한 참조는, URI http://www.example.com/abc/bar.xml가 아니라, /abc/bar.xml이라는 부분을 의미하는 것으로 해석된다.

컨테이너의 한 부분으로부터 다른 부분으로의 참조를 가질 필요가 있을 경우에는, 상대적 URI들을 사용해야 한다. 상대적 참조들을 사용함으로써, 컨테이너의 내용들은, 상호-부분 참조들의 변경없이, 다같이 상이한 컨테이너(즉, 예를 들어, 파일 시스템으로부터의 컨테이너)로 이동될 수 있다.

부분으로부터의 상대적 참조들은 참조를 포함하고 있는 부분의 "기본 URI"에 대해 상대적인 것으로 해석된다. 디폴트로, 부분의 기본 URI는 부분의 이름이다.

다음의 이름들을 가진 부분들을 포함하는 컨테이너를 고려한다.

/markup/page.xml

/images/picture.jpeg

/images/other_picture.jpeg

"/markup/page.xml" 부분이 "../images/picture.jpeg"으로의 URI 참조를 포함한다면, 이 참조는, 상기 규칙들에 따라, 부분 이름 "/images/picture.jpeg"을 참조하는 것으로 해석되어야 한다.

일부 내용 유형들은, 상이한 기본을 내용에 특정하는 것에 의해, 디폴트 기본 URI를 무효화하는 방법을 제공한다. 이러한 무효화들 중 하나가 존재할 경우에는, 디폴트 대신에 명시적으로 특정된 기본 URI가 사용되어야 한다.

어떤 경우에는 부분의 일부 또는 특정 포인트를 "주소화"하는 것이 유용하다. URI 세계에서는, 단락 식별자가 사용된다(예를 들어, RFC2396 참고). 컨테이너에서도, 메커니즘은 동일한 방식으로 작용한다. 구체적으로, 단락은, 주소화된 부분의 내용 유형 문맥에서 이해되는 추가적인 정보를 포함하는 스트링이다. 예를 들어, 비디오 파일에서, 단락은 프레임을 식별할 수 있고, XML 파일에서, 단락은 xpath를 통해 XML 파일의 일부를 식별할 수 있다.

부분을 주소화하는 URI와 함께, 주소화된 부분의 단락들을 식별하기 위한 단락 식별자가 사용된다. 단락 식별자는 선택적이며 "#"(crosshatcher) 문자에 의해 URI와 구별된다. 이와 같이, 단락 식별자는 URI의 부분은 아니지만, 종종 URI와 함께 사용된다.

패키지 및 부분 명명 모델은 상당히 유연하기 때문에, 다음의 논의는 부분 명명을 위한 어떤 지침을 제공한다. 이러한 유연성은 프레임워크 패키지의 광범위한 애플리케이션들을 고려한다. 그러나, 프레임워크는, 다수의 무관한 소프트웨어 시스템들이 "그들만의" 패키지 부분들을 서로 충돌없이 조작할 수 있는 상황들을 가능하게 하기 위해 설계된다는 것을 인지하고 있어야 한다. 이를 위해, 수반된다면, 이러한 것들을 가능하게 할 수 있는 소정의 지침들이 제공된다.

여기에서 주어진 지침들은, 부분 명명 충돌들의 발생을 최소화하거나 적어도 감소시키며, 부분 명명 충돌들이 발생할 경우, 부분 명명 충돌들을 처리하기 위한 메커니즘을 설명한다. 패키지의 부분들을 생성하는 기입기들은 패키지의 기존 부분들과의 충돌들을 검출하고 핸들링하는 조치들을 취해야 한다. 명명 충돌이 발생할 경우, 기입기들이 무작정 기존 부분들을 대체할 수는 없다.

패키지가 하나의 기입기에 의해 조작될 것이 보장되는 상황들에서의 기입기는 이러한 지침들을 벗어날 수 있다. 그러나, 다수의 독립적인 기입기들이 패키지를 공유할 가능성이 존재한다면, 모든 기입기들은 이러한 지침들에 따라야 한다. 그러나, 모든 기입기들이 어떤 경우에서든 이러한 지침들에 따를 것이 추천된다.

ㆍ 기존 컨테이너에 부분들을 부가하는 기입기들은, 부분들을 직접적으로 루트에 배치하거나 이전의 기존 폴더보다는, 명명 계층 구조의 새로운 "폴더"에서 그렇게 할 것이 요청된다. 이런 식으로, 명명 충돌들의 가능성이 부분 이름의 제 1 단락으로 한정된다. 이러한 새 폴더내에 생성된 부분들은 기존 부분들과의 충돌 위험없이 명명될 수 있다.

ㆍ 폴더를 위해 "바람직한" 이름이 기존 부분에 의해 이미 사용되고 있는 경우, 기입기는 다른 폴더 이름들을 선택하기 위한 어떤 전략을 가지고 있어야 한다. 기입기들은, (일정 횟수의 성공적이지 못한 반복들 후에 GUID를 참고하여) 유효한 폴더 이름이 발견될 때까지 바람직한 이름에 숫자들을 첨부하는 전략을 사용해야 한다.

ㆍ 이러한 전략의 한가지 결과는, 판독기들이 "미지의" 또는 "주지의" 부분 이름을 통해 부분을 배치하려는 시도를 하지 않아야 한다는 것이다. 대신, 기입기들은 그들이 생성하고 있는 각 폴더의 하나 이상 부분에 대해 패키지 관계를 생성해야 한다. 판독기들은, 주지의 이름들에 의존하기보다는, 이러한 패키기 관계들을 사용해 부분들을 배치해야 한다.

ㆍ (상기한 패키지 관계들 중 하나에 의해) 판독기가 폴더에서 하나 이상의 부분을 발견하고 나면, 그 폴더내에서 다른 부분들을 찾아내기 위해, 판독기는 주지의 부분 이름들에 관한 협약들을 사용할 수 있다.

드라이버들

여기에 설명된 파일 포맷은 상이한 애플리케이션들, 상이한 문서 유형들 등에 의해 사용될 수 있는데, 그들 중 많은 것들이 충돌하는 용도들, 충돌하는 포맷들 등을 가진다. 파일 포맷들의 차이들, 통신 프로토콜들의 차이들 등과 같은, 다양한 충돌들을 해결하기 위해 하나 이상의 드라이버들이 사용된다. 예를 들어, 상이한 파일 포맷들은 낱개로 된 파일들 및 구성 파일들을 포함하고, 상이한 통신 프로토코들은 http, 네트워크, 및 무선 프로토콜들을 포함한다. 드라이버들의 그룹은 다양한 파일 포맷들 및 통신 프로토콜들을 하나의 모델로 추상화한다. 상이한 상황들, 상이한 고객 요구 사항들, 상이한 물리적 구성들 등을 위해 다수의 드라이버들이 제공될 수 있다.

관계들

패키지의 부분들은 그 패키지의 다른 부분들에 대한 참조들을 포함할 수 있다. 그러나, 일반적으로, 이들 참조들은 부분의 내용 유형에 특징적인 방식들로, 즉, 임의의 마크업 또는 애플리케이션-특정 인코딩으로 참조 부분내에 표현된다. 이것은, 이러한 참조들을 포함하는 부분들의 내용 유형들을 이해하지 못하는 판독기들로부터 부분들간의 내부 연결들을 효과적으로 감춘다.

(리치 패키지 섹션에서 설명되는 고정 페이로드 마크업과 같은) 공통 내용 유형들에 대해서조차도, 다른 부분들에 대한 참조들을 찾아내고 해결하기 위해, 판독기는 부분의 내용 모두를 파싱해야 할 것이다. 예를 들어, 문서들을 한번에 한 페이지씩 인쇄하는 프린트 시스템을 구현할 경우, 특정 페이지에 포함된 영상들 및 폰트들을 식별하는 것이 바람직할 수 있다. 기존 시스템들은 각 페이지의 모든 정보를 파싱해야 하는데, 이것은 시간 소모적일 수 있고, 각 페이지의 언어를 이해해야 하는데, 이것은 소정 장치들 또는 판독기들(예를 들어, 문서가 장치로 전달되는 도중에 프로세서들의 파이프라인을 통과할 때, 문서에 대해 중간 프로세싱을 수행하는 장치들 또는 판독기들)의 경우에는 그렇지 않을 수도 있다. 대신에, 여기에서 설명된 시스템들 및 방법들은 관계들을 사용해 부분들간의 관계를 식별하고 그러한 관계들의 특징을 설명한다. 관계어는 단순하며 한번만 정의되기 때문에, 판독기들은 다수의 상이한 언어들에 대한 지식을 필요로 하지 않으면서 관계들을 이해할 수 있다. 일 실시예에서, 관계들은 XML에서의 개별적인 부분들로서 표현된다. 각 부분은, 부분이 소스인 관계들을 포함하는 관련된 관계 부분을 가진다.

예를 들어, 스프레드시트 애플리케이션은 이러한 포맷을 사용해 상이한 스프레드시트들을 부분들로서 저장한다. 스트레드시트 언어에 관해 아무 것도 모르는 애플리케이션도 여전히 스트레드시트들과 관련된 다양한 관계들을 찾아낼 수 있다. 예를 들어, 애플리케이션은 스트레드시트들에서 이미지들을 찾아낼 수 있고 스트레드시트들과 관련된 메타데이터를 찾아낼 수 있다. 예시적인 관계 스키마가 다음과 같이 제공된다.

이 스키마는 "Relationships" 및 "Relationship"이라는 2개의 XML 요소들을 정의한다. 이러한 "Relationship" 요소는 여기에서 설명되는 바와 같이 하나의 관계를 설명하는데 사용되며, (1) 소스 부분이 관련되어 있는 부분을 지시하는 "target" 및 (2) 관계의 유형 또는 종류를 지시하는 "name"이라는 특성들을 가진다. "Relationships" 요소는 0 또는 그 이상의 "Relationship" 요소들을 보유하도록 하기 위해 정의되며, 이들 "Relationship" 요소들을 다같이 하나의 단위로 모으는 기능을 한다.

여기에 설명된 시스템들 및 방법들은 이러한 문제점들을 해결하기 위해 "Relationships"라는 더 높은-수준의 메커니즘을 도입한다. 관계들은, 패키지의 소스 부분과 목표 부분간의 접속 종류를 표현하기 위한 추가적인 방법을 제공한다. 관계들로 인해, 부분들의 내용을 살펴 보지 않고도, 부분들간의 접속들을 직접적으로 "찾아 낼" 수 있다. 또한, 이러한 관계들은 프로토콜 독립적이다. 다양하고 상이한 관계들이 특정 부분과 관련될 수 있다.

관계들은, 부분들의 변경없이, 부분들이 관련될 수 있게 하는 두번째의 중요한 펑크션을 제공한다. 때때로, 이러한 정보는, "주석된(annotated)" 부분의 내용 유형이 소정 정보를 첨부하기 위한 방법을 정의하지 않는 "주석"의 형태로서 기능한다. 잠재적인 예들로는 첨부된 기술적 메타데이터, 인쇄 티켓들(print tickets), 및 순수 주석들을 들 수 있다. 마지막으로, 일부 상황들, 예를 들어, 부분이 암호화되어 복호화될 수 없을 때 또는 부분이 디지털 서명되어 그것을 변경하는 것이 서명을 무효로 만들 때는 특히 기존 부분을 변경하지 않으면서 기존 부분에 첨부될 정보를 요구한다. 다른 예로서, 사용자가 JPEG 이미지 파일에 주석을 첨부하고자 할 수도 있다. JPEG 이미지 포맷은 현재 주석들의 식별을 지원하지 않는다. 이러한 사용자의 소망을 수용하기 위해 JPEG 포맷을 변경하는 것을 현실적으로 불가능하다. 그러나, 여기에 설명된 시스템들 및 방법들은, 사용자로 하여금 JPEG 이미지 파일을 변경하지 않으면서 JPEG 파일에 주석을 제공할 수 있게 한다.

일 실시예에서, 관계들은 XML을 사용해 관계 부분들로 표현된다. 하나 이상의 관계들의 소스인 컨테이너의 각 부분은 관련된 관계 부분을 갖는다. 이러한 관계 부분은 (내용 유형 application/PLACEHOLDER를 사용해 XML로 표현된) 그 소스 부분에 대한 관계들의 리스트를 보유한다.

다음의 도 4는, (FixedPanel과 유사한) "spine" 부분(402)이 3개의 페이지들(406, 408, 및 410)을 바인딩하는 환경(400)을 나타낸다. spine에 의해 바인딩된 페이지들의 세트는 관련된 "인쇄 티켓"(404)을 갖는다. 또한, 페이지 2는 자신만의 인쇄 티켓(412)을 갖는다. spine 부분(402)으로부터 그것의 인쇄 티켓(404)으로의 그리고 페이지 2로부터 그것의 인쇄 티켓(412)으로의 접속들은 관계들을 사용해 표현된다. 도 4의 구성에서, spine 부분(402)은, 다음의 예에 나타낸 바와 같이, spine을 ticket1에 접속하는 관계가 포함된 관련 관계 부분을 가질 것이다.

관계들은 하나의 <Relationships> 요소에 중첩되어 있는 <Relationship> 요소들을 사용해 표현된다. 이들 요소들은 http://mmcfrels(PLACEHOLDER) 이름 공간에 정의되어 있다. 상기 예시적 스키마 및 관련 논의, 예를 들어, 관계들을 참고한다.

관계 요소들은 표 1과 같은 추가적인 특성들을 가진다.

특성	필요성	의미
Target	예	관계의 나머지 끝에 있는 부분을 포인팅하는 URI. 상대적 URI들은 소스 부분에 대해 상대적으로 해석되어야 한다.
Name	예	관계의 역할 또는 목적을 고유하게 정의하는 절대적 URI.

Name 특성이 반드시 실제 어드레스일 필요는 없다. 그들의 Name들에 의해 상이한 유형의 관계들이 식별된다. 이러한 이름들은, 이름 공간들이 XML 이름 공간들을 위해 정의되는 것과 동일한 방법으로 정의된다. 구체적으로, 인터넷 도메인 이름 공간 이후에 패턴화된 이름들을 사용하는 것에 의해, 비-좌표 파티들(non-coordinating parties)은, XML 이름 공간들에 대해 그럴 수 있는 것처럼, 안전하게 비-충돌 관계 이름들을 생성할 수 있다.

관계들 부분은 다른 관계들에 참여할 수 없다. 그러나, 그것은 다른 모든 의미에서 제 1 클래스 파트이다(예를 들어, 그것은 URI 주소화가 가능하고, 개방, 판독, 삭제 등이 될 수 있다). 관계들은 통상적으로 패키지 외부의 것들을 포인팅하지 않는다. 관계 목표들을 식별하는데 사용된 URI들은 일반적으로 URI 스킴을 포함하지 않는다.

부분 및 그와 관련된 관계 부분은 명명 협약에 의해 접속된다. 이 예에서, spine을 위한 관계 부분은 /content_rels/spine.xml.rels에 저장될 것이고 페이지 2를 위한 관계들은 /content/_rels/p2.xml.rels에 저장될 것이다. 여기에는 2개의 특수한 명명 협약들이 사용되고 있다. 첫번째, 이름 계층 구조의 소정 "폴더"의 어떤 (다른) 부분에 대한 관계 부분은 (관계들을 식별하기 위한) _rels라는 "상세-폴더"에 저장된다. 두번째, 이러한 관계-보유 부분의 이름은 원래 부분의 이름에 .rels 확장자를 첨부하는 것에 의해 형성된다. 구체적 실시예들에서, 관계 부분들은 내용 유형 애플리케이션/xml+relationshipsPLACEHOLDER 형태이다.

관계는 2개 부분들간의 직접적인 접속을 표현한다. 관계가 표현되는 방법으로 인해, (임의의 소정 부분에 대한 관계들 부분을 찾아내는 것은 간단하기 때문에) 관계들은 그들의 소스 부분들로부터 트래버스하는 것이 효율적이다. 그러나, (부분에 대한 모든 관계들을 찾아내는 방법은 컨테이너의 모든 관계들을 철저히 조사하는 것이기 때문에) 관계의 목표로부터 거꾸로 관계들을 트래버스하는 것은 비효율적이다.

관계의 후방 트래버스를 가능하게 하기 위해서는, 나머지 (트래버스 가능한) 방향을 표현하기 위한 새로운 관계가 사용된다. 이것은, 관계 유형의 설계자가 사용할 수 있는 모델링 기법이다. 상기 예에 따라, ticket1이 부착된 spine을 찾아낼 수 있다는 것이 중요하다면, 두번째 관계는, 다음과 같이, ticket으로부터 spine을 접속하는데 사용될 것이다.

패키지 관계들

"패키지 관계들"은 패키지에서 주지의 부분들을 찾아내는데 사용되는다. 이 방법은 패키지의 부분들을 찾아내기 위해 명명 협약들에 의존하지 않으며, 상이한 페이로드들의 동일한 부분 이름들간에 충돌이 없을 것이라는 것을 보장한다.

패키지 관계들은, 그 목표는 부분이지만 그 소스는 부분이 아닌(소스는 전체로서의 패키지이다) 특수한 관계들이다. "주지의" 부분을 갖는 것은 실제로, 그 부분을 찾아내는 것을 지원하는 "주지의" 관계 이름을 갖는 것이다. 비-좌표 파티들로 하여금 관계들을 명명할 수 있게 하는 잘-정의된 메커니즘이 존재하기 때문에, 이것이 가능하지만, 소정 실시예들은 부분 이름을 위한 이러한 메커니즘을 갖지 않는다(그러한 실시예들은 한 세트의 지침들로 한정된다). 패키지 관계들은 패키지 관계들 부분에서 발견되며 관계 부분들에 대한 표준 명명 협약들을 사용해 명명된다. 따라서, 그 이름은 "/_rels/.rels"이다.

패키지 관계들 부분의 관계들은 주지 부분들을 찾아내는데 유용하다.

시작 부분

패키지-레벨의 주지 부분의 일례로는 패키지 "시작(start)" 부분을 들 수 있다. 이것은, 패키지가 개방될 때 통상적으로 프로세싱되는 부분이다. 이것은, 패키지에 저장되어 있는 문서 내용의 논리적 루트를 표현한다. 패키지의 시작 부분은 주지의 패키지 관계가 수반되도록 배치된다. 일례에서, 이 관계는 http://mmcf-start-part-PLACEHOLDER의 이름을 가진다.

구성 부분들: 선택기 및 시퀀스( Composition Parts : Selector and Sequence )

설명된 프레임워크는 부분들로부터 더 높은-차수의 구조들을 구축하기 위한 2개의 메커니즘들(선택기들 및 시퀀스들)을 정의한다.

선택기는 다수의 다른 부분들 중에서 "선택하는" 부분이다. 예를 들어, 선택기 부분은, 문서의 영어 버전을 표현하는 부분과 문서의 불어 버전을 표현하는 부분 중에서 "선택"할 수 있다. 시퀀스는 다수의 다른 부분들을 "순서 매김(배열)"하는 부분이다. 예를 들어, 시퀀스 부분은 5-페이지 문서를 표현하는 부분과 10-페이지 문서를 표현하는 부분의 2개 부분들을 (선형 시퀀스로) 구성할 수 있다.

구성 부분들의 이러한 2가지 유형들(시퀀스 및 선택기) 및 이들을 구성하는 규칙들이 구성 모델을 구성한다. 구성 부분들이 다른 구성 부분들을 구성할 수 있으므로, 예를 들어, 2개 구성물들 중에서 선택하는 선택기를 가질 수 있다. 일례로서, 영어 표현 및 불어 표현 모두를 포함하는 재정 보고서의 일례를 나타내는 도 5를 참고한다. 이들 표현들 각각은 추가적으로 재정 정보들(스프레드시트)이 수반되는 도입(커버 페이지)으로 구성된다. 이 예에서, 선택기(500)는 보고서의 영어 표현과 불어 표현 중에서 선택한다. 영어 표현이 선택되면, 시퀀스(502)는 영어 재정 부분(508)을 과 함께 영어 도입 부분(506)을 배열한다. 다른 방법으로, 불어 표현이 선택되면, 시퀀스(504)는 불어 재정 부분(512)과 함께 불어 도입 부분(510)을 배열한다.

구성 부분 XML

도시되고 설명된 실시예에서, 구성 부분들은 소수의 XML 요소들을 사용해 설명되는데, 이들 모두는 공통적인 구성 이름 공간으로부터 유도된다. 일례로서, 다음을 참고한다.

일례로서, 상기 도 5의 예를 위한 XML이 제시된다.

이 XML에서, MainDocument.xml은 패키지의 전체 부분을 표현하고, "selection" 태그에 의해, MainDocument.xml은 "item" 태그에 의해 인캡슐레이트된 상이한 항목들, 즉, "EnglishRollup.xml" 및 "FrenchRollup.xml" 사이에서 선택이 이루어질 것이라는 것을 지시한다.

EnglishRollup.xml 및 FrenchRollup.xml은, "sequence" 태그들에 의해, 그들의 개별적인 "item" 태그들에 의해 인캡슐레이트된 개개의 항목들을 함께 배열하는 시퀀스들이다.

이와 같이, 간단한 XML 문법이 선택기들 및 시퀀스들을 설명하기 위해 제공된다. 이러한 구성 블록의 각 부분은 구축되어, 선택하는 것 또는 배열하는 것 중 하나의 연산을 수행한다. 부분들의 계층 구조를 사용함으로써, 선택들 및 시퀀스들의 상이하고 강건한 집합들이 구축될 수 있다.

구성 블록

패키지의 구성 블록은, 패키지의 시작 부분으로부터 도달될 수 있는 모든 구성 부분들(선택기 또는 시퀀스)의 세트를 구비한다. 패키지의 시작 부분이 선택기도 시퀀스도 아니라면, 구성 블록은 공백으로 간주된다. 시작 부분이 구성 부분이라면, 그들 구성 부분들의 자식 <항목>이 반복적으로 트래버스되어 구성 부분들의 직접적이고 비순환적인 그래프가 생성된다 (비-구성 부분에 직면할 때 트래버스는 중단됨). 이 그래프는 구성 블록이다(그리고 이 실시예에 따르면, 유효한 패키지에 대해 이 그래프는 비순환적이어야 한다).

구성 의미들의 판정

위에서 비교적 간단한 XML 문법을 확립했으므로, 다음 논의는, 내용 유형에 기초해 선택들이 이루어질 수 있는 것과 같이, 정보를 표현하는 방법을 설명한다. 즉, 위에서 설명된 XML은, 판독기들로 하여금 다같이 하나의 구성으로 조립될 수 있는 부분들을 배치하도록 하기에는 충분한 정보를 제공하지만, 판독기가 그 구성의 특징에 관해 더 많이 알 수 있도록 하기에 충분한 정보를 제공하지는 않는다. 예를 들어, 2개의 부분들을 구성하는 선택이 주어지면, 판독기는 무엇(예를 들어, 언어, 종이 크기 등)에 기초해 그 선택이 이루어졌는지를 어떻게 알 수 있을까? 대답은, 이러한 규칙들이 구성 부분의 내용 유형과 관련되어 있다는 것이다. 따라서, 언어에 기초해 표현들 중에서 골라내는데 사용되는 선택기 부분은 종이 크기들에 기초해 표현들 중에서 골라내는 선택기 부분과 상이한 관련 내용 유형을 가질 것이다.

일반적 프레임워크는 이러한 내용 유형들을 위해 일반적 형태를 정의한다.

Application/XML+Selector-SOMETHING

Application/XML+Sequence-SOMETHING

이러한 내용 유형들의 SOMETHING은, 선택 또는 시퀀스의 특징을 지시하는 단어, 예를 들어, 페이지 크기, 컬러, 언어, 판독기 장치상에 상주하는 소프트웨어 등으로 대체된다. 그 다음에는 이러한 프레임워크에서, 모든 종류의 선택기들 및 시퀀스들을 고안할 수 있고 각각은 아주 상이한 의미들을 가질 수 있다.

설명된 프레임워크 또한, 모든 판독기들 또는 판독 장치들이 이해해야 하는 선택기들 및 시퀀스들에 대해 표 2와 같은 주지의 내용 유형들을 정의한다.

내용 유형	규칙들
Application/XML+Selector+SupportedContentType	그들의 내용 유형들에 기초해 항목들 중에서 선택한다. 소정 내용 유형을 이해하는 소프트웨어가 유효한 제 1 항목을 선택한다.

일례로서, 다음을 고려한다. 패키지가, 중간에 비디오가 등장하는 영역이 존재하는 페이지를 가진 문서를 포함한다고 가정한다. 이 예에서, 페이지의 비디오 부분은 Quicktime 비디오의 형태로 비디오를 구비할 수 있다. 이러한 상황에서의 한가지 문제점은, Quicktime 비디오들이 보편적으로 이해되고 있지 않다는 것이다. 그러나, 이 프레임워크, 보다 구체적으로는, 후술하는 리치 패키지 포맷에 따라, 보편적으로 이해되는 이미지 포맷-JPEG이 존재한다고 가정한다. 상술한 문서를 포함하는 패키지를 생성할 때, 프로듀서는, 패키지의 부분으로서 비디오를 정의하는 이외에, 사용자의 컴퓨터가 Quicktime 비디오를 이해하는 소프트웨어를 가진다면, Quicktime 비디오가 선택되고, 그렇지 않으면, JPEG 이미지가 선택되도록 하기 위해, 페이지에 대한 JPEG 이미지를 정의하고, SupportedContentType 선택기를 개재한다.

따라서, 상술한 바와 같이, 프레임워크-레벨의 선택기 및 시퀀스 컴포넌트들로 인해, 이 예에서는, XML로 정의된 강건한 계층 구조가 구축될 수 있다. 또한, 내용 유형들을 사용해 선택기들 및 시퀀스들의 동작을 식별하기 위한 잘-정의된 방법이 존재한다. 또한, 일 실시예에 따르면, 일반적 프레임워크는, 사전 정의되며, 소비자(예를 들어, 판독기 또는 판독 장치)가 이해하고 이해하지 못하는 것에 기초해, 패키지들의 프로세싱 및 이용을 허용하는 하나의 특정한 내용 유형을 구비한다.

후술하는 예들과 같이, 유사한 규칙들을 사용해 다른 구성 부분 내용 유형들이 정의될 수 있다.

기술적 메타데이터

일 실시예에 따르면, 기술적 메타데이터 부분들은, 패키지들의 판독기들이 확실하게 값들을 찾아내는 것을 가능하게 하는, 특성 값들의 저장 방법을 가진 패키지들의 기입자들 또는 프로듀서들을 제공한다. 이러한 특성들은 통상적으로 전체로서의 패키지 뿐만 아니라 컨테이너내의 개별적인 부분들에 관한 추가적인 정보를 기록하는데도 사용된다. 예를 들어, 패키지의 기술적 메타데이터 부분은, 패키지의 작성자, 키워드들, 요약 등과 같은 정보를 보유할 수 있다.

도시되고 설명된 실시예에서, 기술적 메타데이터는 XML로 표현되고, 주지의 내용 유형들을 가진 부분들에 저장되며, 주지의 관계 유형들을 사용해 발견될 수 있다.

기술적 메타데이터는 메타데이터 특성들을 보유한다. 메타데이터 특성들은 특성 이름 및 하나 이상의 특성 값들로써 표현된다. 특성 값들은 간단한 데이터 유형들을 가지므로, 각각의 데이터 유형은 하나의 XML qname으로 설명된다. 기술적 메타데이터 특성들이 간단한 유형들을 가진다는 사실이, 복잡한 XML 유형들을 가진 데이터를 패키지에 저장할 수 없다는 것을 의미하는 것은 아니다. 이 경우에는, 정보를 완전 XML 부분(full XML part)으로서 저장해야 한다. 이것이 수행되면, 간단한 유형들만을 사용하는 것에 관한 모든 제한 사항들이 제거되지만, "일률적인" 기술적 메타데이터 특성 모델("flat" descriptive metadata property model)의 간략성이 상실된다.

특성들의 세트들을 정의하기 위한 범용 메커니즘 이외에, 이 메커니즘을 사용해 정의된, 문서 핵심 특성들의 특징적인, 잘-정의된 세트가 존재한다. 이러한 문서 핵심 특성들은 흔히 문서들을 설명하는데 사용되며 제목, 키워드들, 작성자 등과 같은 특성들을 포함한다.

마지막으로, 이러한 문서 핵심 특성들을 보유하는 메타데이터 부분들은 문서 핵심 특성들 이외에 추가적인, 고객-정의 특성들을 보유할 수도 있다.

메타데이터 포맷

일 실시예에 따르면, 기술적 메타데이터 부분들은 내용 유형을 가지며 표 3의 규칙들에 따른 관계들에 의한 목표가 된다.

기술적 메타데이터 발견 규칙들	고객-정의 특성들의 사용	문서 핵심 특성들의 사용
기술적 메타데이터 부분의 내용 유형은 반드시 다음과 같아야 한다.	application/xml-SimpleTypeProperties-PLACEHOLDER
기술적 메타데이터 부분을 목표로 하는 관계를 가질 수 있는 소스 부분의 내용 유형은 다음과 같을 수 있다.	임의	임의
기술적 메타데이터 부분을 목표로 하는 관계의 이름은 둘 중 하나일 수 있다.	*고객-정의형 URI-이름 공간*	http://mmcf-DocumentCore-PLACEHOLDER
소스 부분에 첨부될 수 있는 기술적 메타데이터 부분들의 수는 다음과 같을 수 있다.	무제한	0 또는 1
첨부된 것과 동일한 기술적 메타데이터 부분을 가질 수 있는 소스 부분들의 수는 반드시 다음과 같아야 한다.	무제한	무제한

다음의 XML 패턴은 일 실시예에 따른 기술적 메타데이터를 표현하는데 사용된다. 마크업의 컴포넌트 각각에 대한 세부 사항들은 샘플 이후의 표 4로 제시된다.

마크업 컴포넌트	설명
xmlns:mcs="http://mmcf-common-services/PLACEHOLDER	MMCF 공통 서비스들의 이름 공간을 정의한다.
xmlns:xsd="http://www.w3.org/2001/XMLSchema"	XML 스키마 이름 공간을 정의한다. 많은 고객-정의 특성들 및 대다수의 문서 핵심 특성들이 XSD를 사용해 정의된 내장 데이터 유형들을 가질 것이다. 각각의 특성이 자신만의 이름 공간을 가질 수 있지만, XSD 이름 공간은 기술적 메타데이터 XML의 루트상에 배치된다.
mcs:properties	기술적 메타데이터 XML의 루트 요소
mcs:property	특성 요소. 특성 요소는 특성 qname 및 값을 보유한다. 무한개의 특성 요소들이 존재할 수 있다. 특성 요소들은 루트 요소의 인접한 자식들로 간주된다.
xmlns:prns	특성 이름 공간:문서 핵심 특성들의 경우, 이것은 http://mmcf-DocumentCore-PLACEHOLDER이다. 고객-정의 특성들의 경우, 이것은 고객 이름 공간일 것이다.
prns:name	특성 이름:특성 이름을 보유하는 스트링 속성
mcs:type="datatype"	유형은 특성 데이터유형 정의, 예를 들어, xsd:string를 보유하는 스트링 속성이다.
mcs:value	이 컴포넌트는 특성 값을 특정한다. 값 요소들은 특성 요소들의 인접한 자식들이다. mcs:multivalued="true"이면, 무한개의 값 요소들이 존재할 수 있다.

문서 핵심 특성들

다음의 표 5는, 특성의 이름, 특성 유형, 및 설명을 포함하는 문서 핵심 특성들의 도표이다.

물리적 모델

물리적 모델은, 패키지가 기입기들 및 판독기들에 의해 사용되는 다양한 방법들을 정의한다. 이 모델은, 기입기, 판독기, 및 그들간의 파이프와 같은 3가지 컴포넌트들에 기초할 수 있다. 도 6은 패키지에 관해 통신하기 위해 기입기들 및 판독기들이 함께 작업하는 일부 예들을 나타낸다.

파이프는 기입기로부터 판독기로 데이터를 전달한다. 많은 경우, 파이프는 단순히, 판독기가 로컬 파일 시스템으로부터 패키지를 판독하기 위해 형성하는 API 호들을 구비할 수 있다. 이것을 다이렉트 액세스라고 한다.

그러나, 대개의 경우, 판독기 및 기입기는 어떤 유형의 프로토콜을 통해 서로 통신해야 한다. 이러한 통신은, 예를 들어, 프로세스 경계를 거치거나 서버와 데스크탑 컴퓨터 사이에서 발생한다. 이것을 네트워크 액세스라고 하는데, 파이프의 통신 특징들(구체적으로, 속도 및 요청 지연)때문에 중요하다.

최대 성능을 가능하게 하기 위해, 물리적 패키지 설계들은 액세스 스타일, 레이아웃 스타일, 및 통신 스타일의 중요한 3가지 영역들에서의 지원을 고려해야 한다.

액세스 스타일

스트리밍 소비

네트워크 액세스를 사용하는 기입기와 판독기간의 통신은 순간적으로 일어나지 않기 때문에, 패키지들의 점진적인 생성 및 소비를 고려하는 것이 중요하다. 특히, 이 실시예에 따르면, 어떤 물리적 패키지 포맷도, 패키지의 모든 비트들이 파이프를 통해 전달되기 전에, 판독기가 자신이 수신하는 데이터(예를 들어, 부분들)의 해석 및 프로세싱을 시작할 수 있도록 설계되는 것이 바람직하다. 이러한 능력을 스트리밍 소비라고 한다.

스트리밍 생성

기입기가 패키지를 생성하기 시작할 때, 무엇이 패키지에 놓이게 될 것인지를 기입기가 항상 알고 있는 것은 아니다. 일례로서, 애플리케이션이 프린트 스풀 파일 패키지를 구성하기 시작할 때, 얼마나 많은 페이지들이 패키지로 번역되어야 하는지 모를 수도 있다. 다른 예로서, 동적으로 보고서를 생성하고 있는 서버상의 프로그램은, 프로그램이 완전히 생성된 보고서를 갖기 전에는, 보고서가 얼마나 길어질지 또는 보고서가 얼마나 많은 영상들을 가질 것인지 인식할 수 없을 수도 있다. 기입기들에게 이러한 것을 허용하기 위해, 물리적 패키지들은, 다른 부분들이 이미 부가된 이후에 기입기들이 부분들을 동적으로 부가하는 것을 허용할 수 있어야 한다(예를 들어, 기입기는, 기입기가 기입하기 시작할 때 기입기가 얼마나 많은 부분들을 생성할 것인지를 사전에 명시할 필요가 없어야 한다). 또한, 물리적 패키지들은, 기입기가 그 부분의 궁극적인 길이를 모르는 상태에서 부분 내용들의 기입을 시작하도록 허용할 수 있어야 한다.

동시 생성 및 소비

고도의 파이프라인 아키텍처에서, 특정 패키지에 대한 스트리밍 생성 및 스트리밍 소비가 동시에 발생할 수 있다. 물리적 패키지를 설계할 때, 스트리밍 생성을 지원하는 것과 스트리밍 소비를 지원하는 것은 상반되는 방향으로 설계에 영향을 미칠 수 있다. 그러나, 양자를 지원하는 설계를 종종 발견할 수 있다. 파이프라인 아키텍처의 이점들로 인해, 물리적 패키지들은 동시 생성 및 소비를 지원할 것이 추천된다.

레이아웃 스타일들

물리적 패키지들은 부분들의 집합을 보유한다. 이들 부분들은 단순 순서화 및 인터리브의 2가지 스타일들 중 하나로 레이아웃될 수 있다. 단순 순서화의 경우, 패키지의 부분들은 정의된 순서로 레이아웃된다. 이러한 패키지가 순수한 선형 방식으로 전달될 경우, 패키지의 첫번째 바이트로 시작해 마지막까지, 제 1 부분의 바이트들 모두가 먼저 도착한 다음 제 2 부분의 바이트들 모두가 도착하는 식이다.

인터리브 레이아웃의 경우, 다수 부분들의 바이트들이, 소정 상황들에서 향상된 성능을 허용하기 위해, 인터리브된다. 인터리빙으로부터 상당한 이점을 취할 수 있는 2가지 상황들은 멀티미디어 재생(예를 들어, 비디오 및 오디오를 동시에 전달하는 것) 및 인라인 리소스 참조(inline resource reference;예를 들어, 마크업 파일 중간에서의 이미지 참조)이다.

인터리빙은, 인터리브된 부분들의 내용들을 조직하기 위한 특수 규약을 통해 핸들링된다. 부분들을 조각들로 분해하고 이들 조각들을 인터리빙함으로써, 여전히 원래의 더 큰 부분을 용이하게 재구성하는 것을 가능하게 하면서, 인터리빙의 소정 결과를 실현할 수 있다. 인터리빙의 작동 방법을 이해하기 위해, 도 7은 content.xml(702) 및 image.jpeg(704)의 2개 부분들이 관련된 간단한 일례를 도시한다. 제 1 부분, content.xml은 페이지의 내용들을 설명하며 그 페이지의 중간에 페이지상에 나타나야 할 이미지(image.jpeg)에 대한 참조가 있다.

인터리빙이 유용한 이유를 이해하기 위해, 도 8에 나타낸 바와 같은, 단순 순서화를 사용해 이들 부분들이 어떻게 패키지로 정렬되는지를 고려한다. 이 패키지를 프로세싱하고 있는 (그리고 순차적으로 바이트들을 수신하고 있는) 판독기는, 판독기가 content.xml 부분 뿐만 아니라 image.jpeg 모두를 수신하기 전에는 영상을 디스플레이할 수 없을 것이다. 일부 상황들(예를 들어, 작거나 단순한 패키지들, 또는 고속 통신 링크들)에서는, 이것이 문제가 아닐 수도 있다. 다른 상황들에서는(예를 들어, content.xml이 아주 크거나 통신 링크가 아주 느리다면), 이미지를 취하기 위해 content.xml 부분 모두를 통독해야 한다는 것은 수용할 수 없는 성능 또는 판독기 시스템에 불합리한 메모리 수요를 초래할 것이다.

이상적인 성능에 좀더 근접하기 위해, content.xml 부분을 분할해 영상이 참조되는 바로 직후인 중간에 image.jpeg 부분을 삽입할 수 있는 것이 바람직할 것이다. 이로 인해, 판독기는 이미지 데이터가 수반되는 참조를 맞닥뜨리자 마자 좀더 일찍 이미지 프로세싱을 시작할 수 있게 된다. 이것은, 예를 들어, 도 9에 나타낸 패키지 레이아웃을 발생시킬 것이다. 성능 이점들로 인해, 물리적 패키지들은 인터리빙을 지원하는 것이 대개는 바람직하다. 사용 중인 물리적 패키지의 종류에 따라, 인터리빙은 지원될 수도 그렇지 않을 수도 있다. 상이한 물리적 패키지들은 인터리빙의 내부적 표현을 상이하게 핸들링할 수 있다. 물리적 패키지가 인터리빙을 핸들링하는 방법에 관계없이, 인터리빙은 물리적 레벨에서 발생하는 최적화이고 다수의 조각들로 분해된 물리적 파일 부분은 여전히 하나의 논리적 부분이라는 것(조각들 자체는 부분들이 아니라는 것)을 기억하는 것이 중요하다.

통신 스타일들

기입기와 판독기간의 통신은 부분들의 순차적 전달에 기초하거나 순서없이 부분들에 액세스할 수 있게 하는 부분들로의 무작위-액세스(random-access)에 의한 것일 수 있다. 이러한 통신 스타일들 중 어떤 것이 이용될 것인지는 파이프와 물리적 패키지 포맷 양자의 능력들에 의존한다. 일반적으로, 모든 파이프들은 순차적 전달을 지원할 것이다. 물리적 패키지들은 순차적 전달을 지원해야 한다. 무작위-액세스 상황들을 지원하기 위해서는, 사용 중인 파이프 및 물리적 패키지 모두가 무작위-액세스를 지원해야 한다. 일부 파이프들은, 무작위 액세스를 가능하게 할 수 있는 프로토콜들(예를 들어, 바이트-범위의 지원을 가진 HTTP 1.1)에 기초한다. 이러한 파이프들이 사용 중일 때, 최대 성능을 허용하기 위해서는, 물리적 패키지들이 무작위-액세스를 지원할 것이 추천된다. 이러한 지원이 없다면, 판독기들은, 그들이 필요로 하는 부분들이 순차적으로 전달될 때까지 그저 대기할 것이다.

물리적 매핑들

논리적 패키지 모델은 추상적 패키지를 정의하고, 패키지의 실제 인스턴스는 패키지의 어떠한 특정 물리적 표현에 기초한다. 패키지 모델은 영속적인 물리적 포맷들 뿐만 아니라 다양한 전송 수단들(예를 들어, 네트워크-기반 프로토콜들)로 매핑될 수 있다. 물리적 패키지 포맷은 추상적 패키지 모델의 컴포넌트들로부터 물리적 특정 포맷 사양들로의 매핑으로 설명될 수 있다. 패키지 모델은, 패키지들을 아카이브, 분산, 또는 스풀링하는데 어떤 물리적 패키지 포맷들이 사용되어야 하는지 특정하지 않는다. 일 실시예에서는, 논리적 구조만이 특정될 뿐이다. 패키지는 낱개로 된 파일들, .ZIP 파일 아카이브, 구성 파일, 또는 어떤 다른 포맷의 집합으로써 "물리적으로" 구현될 수 있다. 선택된 포맷은 목표 소비 장치 또는 장치를 위한 드라이버에 의해 지원된다.

매핑되는 컴포넌트들

각각의 물리적 패키지 포맷은 다음 컴포넌트들에 대한 매핑을 정의한다. 일부 컴포넌트들은 선택적이며, 특정한 물리적 패키지 포맷은 이러한 선택적 컴포넌트들을 지원하지 않을 수도 있다.

ㆍ컴포넌트 ㆍ설명 ㆍ필요함

또는 선택적

ㆍName ㆍ부분을 명명함 ㆍ필요함

ㆍParts ㆍContenttype ㆍ부분에 저장된 내용의 ㆍ필요함

종류를 식별함

ㆍPartcontents ㆍ부분의 실제 내용을 ㆍ필요함

저장함

공통적인 매핑 패턴들

ㆍ액세스 스타일들

ㆍ스트리밍 소비 ㆍ전체 패키지가 도달하기 전에, ㆍ선택적

판독기들이 부분들의 프로세싱을

시작할 수 있게 함

ㆍ스트리밍 생성 ㆍ기입될 부분들 모두를 미리 ㆍ선택적

인식하지 않고도, 기입기들이

패키지로의 부분들 기입을 시작

할 수 있게 함

ㆍ동시 생성 및 소비 ㆍ동일한 패키지에서 스트리밍 ㆍ선택적

생성 및 스트리밍 소비가 동시에

발생할 수 있게 함

ㆍ레이아웃 스타일들

ㆍ단순 순서 매김 ㆍ부분 N에 대한 모든 바이트들이 ㆍ선택적

부분 N+1에 대한 바이트들 이전에

패키지에 나타남

ㆍ인터리브 ㆍ다수 부분들에 대한 바이트들이 ㆍ선택적

인터리브됨

ㆍ 통신 스타일들

ㆍ 순차적 전달 ㆍ부분 N의 전부가 부분 N+1 이전에 ㆍ선택적

판독기로 전달됨

ㆍ무작위-액세스 ㆍ판독기는 순차적 순서를 벗어나 ㆍ선택적

부분의 전달을 요청할 수 있음

그 사양들이 패키지-모델 컴포넌트들과 부분적으로 매칭되는 많은 물리적 저장 포맷들이 존재한다. 매핑 계층들을 사용하는 것이 물리적 저장 매체에 원래는 존재하지 않았던 능력들을 제공하기 위한 것이기는 하지만, 패키지 모델로부터 이러한 저장 포맷들로의 매핑들을 정의함에 있어서, 패키지 모델과 물리적 저장 매체간의 어떠한 능력적 유사점들을 이용하는 것이 바람직할 수 있다. 예를 들어, 일부 물리적 패키지 포맷들은 개별적인 부분들을 파일 시스템의 개별적인 파일들로서 저장할 수 있다. 이러한 물리적 포맷에서는, 많은 부분 이름들을 직접적으로 동일한 물리적 파일 이름들로 매핑하는 것이 자연스러울 것이다. 유효한 파일 시스템의 파일 이름들이 아닌 문자들을 사용하는 부분 이름들은 일종의 이스케이프 메커니즘(escape mechanism)을 필요로 할 수 있다.

많은 경우, 물리적 패키지 포맷들의 설계자들은 하나의 공통적인 매핑 문제에 직면할 수 있다. 임의적 내용 유형들을 부분들과 관련지을 때 그리고 인터리브 레이아웃 스타일을 지원할 때, 공통적 매핑 문제점들의 2가지 예들이 발생한다. 본 명세서는 이러한 공통적인 매핑 문제점들에 대한 공통적인 해결책들을 제시한다. 특정한 물리적 패키지의 설계자들이 여기에 정의된 공통적 매핑 해결책들을 사용하도록 고무될 수는 있지만, 반드시 그래야 하는 것은 아니다.

부분들의 내용 유형들 식별하기

물리적 패키지 포맷들의 매핑들은 각 부분에 대한 내용 유형을 저장하기 위한 메커니즘을 정의한다. 일부 물리적 패키지 포맷들은 내용 유형들을 표현하기 위한 고유 메커니즘(예를 들어, MIME의 "Content-Type" 헤더)을 가진다. 이러한 물리적 패키지들의 경우, 부분들에 대한 내용 유형들을 표현하기 위해 매핑이 고유 메커니즘을 사용할 것이 추천된다. 다른 물리적 패키지 포맷들의 경우, 내용 유형들을 표현하기 위해 어떠한 다른 메커니즘이 사용된다. 이러한 패키지들에서 내용 유형들을 표현하기 위해 추천된 메커니즘은, 유형들 스트림(types stream)이라고 하는, 특수하게-명명된 XML 스트림을 패키지에 포함하는 것에 의한 것이다. 이 스트림은 부분이 아니므로, 자체가 URI-주소화될 수는 없다. 그러나, 인터리빙 부분들에 사용된 것과 동일한 메커니즘들을 사용해 물리적 패키지에 인터리브될 수 있다.

유형들 스트림은 최상위의 "Types" 요소, 및 하나 이상의 "Default"와 "Override" 하부-요소들을 가진 XML을 포함한다. "Default" 요소들은 부분 이름 확장자들로부터 내용 유형들로의 디폴트 매핑을 정의한다. 이것은, 파일 확장자들이 종종 내용 유형에 대응된다는 사실을 이용한다. "Override" 요소들은, 디폴트 매핑들에 의해 커버되지 않거나 디폴트 매핑들과 일치되지 않는 부분들상의 내용 유형들을 특정한는데 사용된다. 패키지 기입기들은 부분당 "Override" 요소들의 수를 감소시키기 위해 "Default" 요소들을 사용할 수 있지만, 반드시 그래야 하는 것은 아니다.

"Default" 요소들은 다음의 특성들을 가진다.

ㆍ이름 ㆍ설명 ㆍ필요성

ㆍExtension ㆍ부분 이름 확장자. "Default"

요소는, 이 특성 값이 수반되는

마침표로 끝나는 이름을 가진

임의의 부분과 매칭된다.

ㆍContentType ㆍRFC2045에서 정의된 바와 같은

내용 유형. (후술하는 바와 같이,

"Override" 요소에 의해 무효화되지

않는다면) 임의의 매칭 부분들에 대한

내용 유형을 지시한다.

"Override" 요소는 다음의 특성들을 가진다.

ㆍ이름 ㆍ설명 ㆍ필요성

ㆍPartName ㆍ부분 이름 URI. "Override"

요소는 이 특성 값과 동일한

이름을 가진 부분과 매칭된다.

ㆍContentType ㆍRFC2045에서 정의된 바와 같은

내용 유형. 매칭 부분의 내용 유형을

지시한다.

다음은 유형들 스트림에 포함된 XML의 일례이다.

다음 도표는 부분들의 샘플 리스트를 나타내는데, 그들의 대응되는 내용 유형들은 상기 유형들 스트림에 의해 정의된 바와 같다.

ㆍ부분 이름 ㆍ내용 유형

패키지의 모든 부분에 대해, 유형들 스트림은 (a) 하나의 매칭되는 "Default" 요소, (b) 하나의 매칭되는 "Override" 요소, 또는 (c) 매칭되는 "Default" 요소 및 매칭되는 "Override" 요소 모두(이 경우, "Override" 요소가 우선 순위를 가진다) 중 하나를 포함한다. 일반적으로, 임의의 소정 확장자에 대해 적어도 하나의 "Default" 요소가 존재하며, 임의의 소정 부분 이름에 대해 하나의 "Override" 요소가 존재한다.

유형들 스트림에서 "Default" 및 "Override" 요소들의 순서는 중요하지 않다. 그러나, 인터리브 패키지들에서, "Default" 및 "Override" 요소들은, 그들이 대응되는 부분(들) 이전에 물리적 패키지에 나타난다.

인터리빙

모든 물리적 패키지들이 본래부터 부분들의 데이터 스트림들에 대한 인터리빙을 지원하는 것은 아니다. 일 실시예에서는, 임의의 이러한 물리적 패키지로의 매핑이, 부분들의 인터리빙을 허용하기 위해, 이 섹션에서 설명된 일반적 메커니즘을 사용한다. 일반적 메커니즘은, 부분의 데이터 스트림을 다른 부분들의 조각들 또는 전체 부분들과 인터리브될 수 있는 다수 조각들로 분해하는 것에 의해 작용한다. 부분의 개개 조각들은 물리적 매핑 상태로 존재하며 논리적 패키지 모델로 주소화될 수는 없다. 조각들은 0의 크기를 가질 수도 있다.

다음으로는, 부분 이름으로부터 부분의 개개 조각들에 대한 이름들로의 고유한 매핑이 정의되므로, 판독기는 조각들을 그들의 원래 순서로 합쳐 부분의 데이터 스트림을 형성할 수 있다.

소정 부분 이름에 대한 조각 이름들을 유도하기 위한 문법은 다음과 같다.

piece_name = part_name "/" "[" 1*digit "]" [".last"] ".piece"

다음은, 이 문법에 의해 생성된 piece_name들에 대해 존재하는 유효성 제한 사항들이다.

ㆍ 조각 번호들은 0 및 양의 연속적인 정수들로 시작한다. 조각 번호들은 왼쪽으로 0이 채워질 수 있다.

ㆍ 부분의 조각들 세트의 마지막 조각은 조각 이름의 ".piece" 전에 ".last"를 포함한다.

ㆍ 조각 이름은 물리적 패키지의 이름들로 매핑하기 이전에 논리적 부분의 이름으로부터 생성된다.

조각들을 그들의 원래 순서로 저장할 필요는 없지만, 이러한 저장은 최적화된 효율성을 제공할 수 있다. 인터리브(조각난) 부분들을 포함하는 물리적 패키지는 비-인터리브(일-조각) 부분들을 포함할 수도 있으므로, 다음 예는 유효할 것이다.

구체적인 매핑들

다음에서는, 윈도우즈 파일 시스템의 낱개로 된 파일들의 물리적 포맷들에 대한 구체적인 매핑들을 정의한다.

윈도우즈 파일 시스템의 낱개로 된 파일들로의 매핑

논리적 모델의 요소들을 물리적 포맷으로 매핑하는 방법을 좀더 잘 이해하기 위해, Metro 패키지를 윈도우즈 파일 시스템의 낱개로 된 파일들의 집합으로 표현하는 기본적인 경우를 고려한다. 논리적 패키지의 각 부분은 개개의 파일(스트림)에 포함될 것이다. 논리적 모델에서의 부분 이름 각각은 파일 이름에 대응된다.

논리적 컴포넌트	물리적 표현
부분	파일(들)
부분 이름	(URI처럼 보이는, /를 ＼로 변경하는 등의) 경로를 가진 파일 이름
부분 내용 유형	파일 이름들 및 그들의 관련 유형들의 간단한 리스트를 표현하는 XML을 포함하는 파일

부분 이름들은, 다음의 도표로 도시한 바와 같이, 유효한 윈도우즈 파일 이름들로 변환된다.

논리적 부분 이름 세그먼트들(URI 세그먼트들) 및 윈도우즈 파일명들로 유효한 2개의 문자 세트들이 다음과 같이 제시된다. 이 도표는 2가지 중요한 사실들을 나타낸다.

URI를 파일명으로 변환할 때 이스케이프해야 하는 2개의 유효한 URI 심볼들 (:(colon) 및 *(asterisk))이 존재한다.

URI로 표현될 수 없는 유효한 파일명 심볼들 ^ {} [] #이 존재한다(이들은 인터리빙과 같은 특수한 매핑 목적들에 사용될 수 있다).

"이스케이핑"은, 부분 이름이 파일 이름으로 사용될 수 없는 문자를 포함할 경우 유효한 파일명 문자들을 생성하기 위한 기술로서 사용된다. 문자를 이스케이프하기 위해, 문자의 16진수 표현이 수반되는 ^(caret) 심볼이 사용된다.

abs_path(부분 이름)로부터 파일 이름으로 매핑하기 위해서는,

처음의 /를 제거하고

모든 /를 ＼로 변환하며

: 및 * 문자들을 이스케이프한다 .

예를 들어, 부분 이름 /a:b/c/d*.xaml은 a^25b＼c＼d^2a.xaml의 파일 이름이 된다.

역매핑(reverse mapping)을 수행하기 위해서는,

모든 ＼를 /로 변환하고

스트링의 시작에 /를 부가하며

^[ hexCode ]를 대응되는 문자로 대체하는 것에 의해 문자들을 언이스케이프(unescape)한다.

버전 관리 및 확장 가능성( Versioning and Extensibility )

다른 기술 명세서들처럼, 여기에 포함된 명세서도 장래의 향상들로 발전할 수 있다. 이 명세서의 제1판 설계는 제1판에 기초해 기입된 소프트웨어 시스템들과 장래 판들에 대해 기입된 소프트웨어 시스템들 사이에서의 장차의 문서들의 상호 교환에 대한 계획들을 포함한다. 마찬가지로, 이 명세서는, 제3자들이 본 명세서에 대한 확장들을 생성할 수 있게 한다. 이러한 확장은, 예를 들어, 어떤 특정 프린터의 사양을 이용하지만, 그 프린터의 존재를 인식하지 못하는 다른 판독기들과의 호환성을 여전히 보유하는 문서 구성을 허용하기 위한 것일 수 있다.

고정 페이로드 마크업의 새로운 버전들을 사용하는 문서들 또는 마크업에 대한 제3자 확장들은, 판독기들이 동작(예를 들어, 무엇인가를 시각적으로 렌더링하는 방법)에 관해 적절한 판정을 내릴 것을 요한다. 판독기들을 안내하기 위해, 문서 작성자(또는 문서를 생성한 도구)는 다른-비인식 요소들 또는 특성들에 직면한 판독기들을 위한 적절한 동작을 식별해야 한다. 리치 문서들의 경우, 이러한 유형의 안내가 중요하다.

새로운 프린터들, 브라우저들, 및 다른 클라이언트들이 장래의 사양들을 위한 다양한 지원을 구현할 수 있다. 새로운 버전들 또는 확장들을 이용하는 문서 작성자들은 그러한 확장 버전들을 인지하지 못하는 판독기들의 동작을 주의깊게 고려해야 한다.

버전 관리 이름 공간

XML 마크업 인식은 이름 공간 URI들에 기초한다. 임의의 XML-이름 공간의 경우, 판독기는 그 이름 공간에서 정의된 XML-요소들 및 XML-속성들 전부를 인식하거나 인식하지 못할 것으로 기대된다. 판독기가 새로운 이름 공간을 인식하지 못한다면, 판독기는 문서내에서 특정된 바와 같이 대체용 렌더링 연산들(fallback rendering operations)을 수행해야 할 것이다.

XML 이름 공간 URI 'http://PLACEHOLDER/version-control'은, 버전-적응적이며 확장-적응적인 고정 페이로드 마크업을 구성하는데 사용된 XML 요소들 및 속성들을 포함한다. 고정 페이로드들은 내부에 버전 관리 요소들을 가질 필요가 없다. 그러나, 적응적 내용을 구축하기 위해, <ver:Compatibility.Rules> 및 <ver:AlternativeContent> XML-요소들 중 하나 이상을 사용해야 한다.

이러한 고정-페이로드 마크업 명세서는 관련된 xmlns URI 'http://PLACEHOLDER/pdl'을 가진다. 고정 페이로드에 이러한 이름 공간을 사용하는 것은, 이 명세서에서 정의된 요소들만이 사용될 것이라는 것을 판독기 애플리케이션에 지시한다. 이 명세서의 장래 버전들은 그들만의 이름 공간들을 가질 것이다. 새로운 이름 공간에 익숙한 판독기 애플리케이션들은 이전의 버전들에서 정의된 특성들 및 요소들의 전체 집합을 지원하는 방법을 알고 있을 것이다. 새로운 버전에 익숙하지 않은 판독기 애플리케이션들은 새로운 버전의 URI를 PDL로의 미지의 어떤 확장에 대한 URI인 것처럼 간주할 것이다. 이러한 애플리케이션들은, 이름 공간들간에, 하나가 다른 것의 전체 집합이라는 관계가 존재한다는 것을 알지 못할 수도 있다.

백워드 및 "포워드" 호환성

여기에서 논의된 시스템들 및 방법들을 지원하는 애플리케이션들 또는 장치들의 맥락에서, 호환성은 명세서의 이전 버전들 또는 명세서에 대한 미지의 확장들 또는 버전들을 사용해 작성된 문서들을 파싱 및 디스플레이할 수 있는 클라이언트들의 능력에 의해 지시된다. 다양한 버전 관리 메커니즘들은, 클라이언트들의 장래 구현들이, 후술하는 바와 같이, 명세서의 다운-레벨 버전들에 기초한 문서들을 지원할 수 있게 하는, "백워드 호환성"에 초점을 맞춘다.

프린터와 같은, 구현된 클라이언트가 마크업 언어의 장래 버전을 사용해 구성된 문서를 수신할 경우, 클라이언트는 이용 가능한 렌더링 옵션들을 파싱하고 이해할 수 있을 것이다. 새로운 버전의 사양들을 사용하는 일부 문서들을 핸들링하기 위해 명세서의 이전 버전에 따라 기입된 클라이언트 소프트웨어의 능력을 종종 "포워드 호환성"이라 한다. 포워드 호환성이 가능하도록 기입된 문서를 "버전-적응적(version-adaptive)"이라고 한다.

또한, 구현된 클라이언트들이, 새로운 요소들 또는 특성들을 표현하는 미지의 확장들을 가진 문서들도 지원할 수 있어야 하기 때문에, 다양한 의미들이 "확장 적응적"인 문서들의 좀더 일반적인 경우를 지원한다.

프린터 또는 뷰어가 미지의 확장들에 맞닥뜨리면, 프린터 또는 뷰어는 주변 내용을 적응적으로 렌더링하는 것에 관한 지침을 위해 확장의 사용과 함께 내장된 정보를 찾을 것이다. 이러한 적응은 미지의 요소들 또는 특성들을 이해되는 내용으로 대체하는 것과 관련이 있다. 그러나, 적응은, 미지의 내용을 완전히 무시하는 것을 포함하여, 다른 형태들로 발생할 수도 있다. 명시적인 지침이 없다면, 판독기는, 마크업에서의 미인식 확장의 존재를 오류-조건으로 취급해야 한다. 지침이 제공되지 않으면, 확장은 내용을 이해하는 기초가 되는 것으로 추정된다. 렌더링 실패는 포착되어 사용자에게 보고될 것이다.

이러한 모델을 지원하기 위해, 마크업 언어의 새로운 확장 버전들은 관련 확장들을 이름 공간들에 논리적으로 분류해야 한다. 이런 방식으로, 문서 작성자들은 최소 갯수의 이름 공간들을 사용해 확장된 사양들을 이용할 수 있을 것이다.

버전 관리 마크업

확장-적응적 동작을 지원하기 위한 XML 용어는 다음의 요소들을 포함한다.

ㆍ 버전 관리 요소 및 계층 구조 ㆍ 설명

ㆍ <Compatibility.Rules> ㆍ 파서가 미지의 요소 또는

특성에 반응하는 방법을 제어한다.

ㆍ <Ignorable> ㆍ 관련 이름 공간 URI가 무시될

수 있다는 것을 선언한다.

ㆍ <ProcessContent> ㆍ 요소가 무시되면, 요소의 내용들이 무시된 요소의 컨테이너에 포함되어

있는 것처럼 프로세싱될 것이라는

것을 선언한다.

ㆍ <CarryAlong> ㆍ 무시할 수 있는 내용이 문서가 변경 될 때 보존될 것인지의 여부를 문서

편집 도구들에 지시한다.

ㆍ <MustUnderstand> ㆍ 무시될 수 있는 것으로 선언된 요소 의 영향을 보존한다.

ㆍ <AlternateContent> ㆍ 버전 관리/확장 사양들을 이용하는 마크업에서, AlternateContent>요소는 대용물을 바람직한 것으로 특정된 마크업을 핸들링할 수 없는 판독기 애플리케이션들에 의해 사용될 "대체용" 마크업과 관련짓는다.

ㆍ <Prefer> ㆍ 바람직한 내용을 특정한다. 이 내용은, 클라이언트가 버전/확장 사양들을 인식하고 있는 것일 것이다.

ㆍ <Fallback> ㆍ 다운-레벨 클라이언트들에 대해, 바람직한 내용으로 대체될 '다운-레벨' 내용을 특정한다.

<Compatibility.Rules> 요소

Compatibility.Rules는, 첨부된 특성을 보유할 수 있는 임의의 요소 뿐만 아니라 Xaml 루트 요소에도 첨부될 수 있다. <Compatibility.Rules> 요소는, 파서가 미지의 요소들 또는 특성들에 반응하는 방법을 제어한다. 통상적으로 이러한 항목들은 오류로서 보고된다. Compatibility.Rules 특성에 무시할 수 있는 요소를 부가하는 것은, 소정 이름 공간들로부터의 항목들이 무시될 수 있다는 것을 컴파일러에 통지한다.

Compatibility.Rules는 Ignorable 및 MustUnderstand 요소들을 포함할 수 있다. 디폴트로, 모든 요소들 및 특성들은 MustUnderstand인 것으로 가정된다. 요소들 및 특성들은, 그것의 컨테이너 Compatibility.Rules 특성에 Ignorable 요소를 부가하는 것에 의해 Ignorable화될 수 있다. 요소 또는 특성은, 내포된 컨테이너들 중 하나에 MustUnderstand 요소를 부가하는 것에 의해, 다시 MustUnderstand화될 수 있다. 하나의 Ignorable 또는 MustUnderstand는 동일한 Compatibility.Rules 요소내의 특정 이름 공간 URI를 참조한다.

<Compatibility.Rules> 요소는, 컨테이너의 고유한 태그 또는 특성들이 아니라, 컨테이너의 내용들에 영향을 미친다. 컨테이너의 태그 또는 특성들에 영향을 미치기 위해서는, 컨테이너가 호환성 규칙들을 포함해야 한다. Xaml 루트 요소는, Canvas와 같은, 그렇지 않다면 루트 요소들일 요소들에 대해 호환성 규칙들을 특정하는데 사용될 수 있다. Compatibility.Rules 복합 특성이 컨테이너의 제 1 요소이다.

<Ignorable> 요소는, 밀폐형 이름 공간 URI가 무시될 수 있다는 것을 선언한다. <Ignorable> 태그가 현재의 블록 또는 컨테이너 블록에서의 항목 이전에 선언되고 이름 공간 URI가 파서에게 미공지라면, 그 항목은 무시될 수 있는 것으로 간주될 수 있다. URI가 공지라면, Ignorable 태그는 무시되며 모든 항목들이 이해된다. 일 실시예에서, 명시적으로 Ignorable인 것으로 선언되지 않은 모든 항목들은 이해되어야 한다. Ignorable 요소는, 요소가 무시되는 방법을 변경하는데 사용될 뿐만 아니라 이러한 내용이 편집된 문서들에 어떻게 보존되어야 하는지에 대한 지침을 문서 편집 도구들에 제공하는 <ProcessContent> 및 <CarryAlong> 요소들을 포함할 수 있다.

<ProcessContent> 요소

<ProcessContent> 요소는, 요소가 무시된다면, 요소의 내용들은 무시된 요소의 컨테이너에 포함되어 있는 것처럼 프로세싱될 것이라는 것을 선언한다.

<ProcessContent> 특성들

ㆍ 특성 ㆍ 설명

ㆍ 요소들 ㆍ 내용들을 프로세싱하기 위한 요소 이름들의 공간 범위가 정해진 리스트 또는 모든 요소들의 내용들을 지시하는 "*"가 프로세싱되어야 한다. 특정되지 않으면, 요소들은 디폴트로 "*"가 된다.

<CarryAlong> 요소

선택적인 <CarryAlong> 요소는, 문서가 변경될 때, 무시될 수 있는 내용이 보존되어야 하는지의 여부를 문서 편집 도구들에 지시한다. 편집 도구가 무시할 수 있는 내용을 보존하거나 파기하는 방법은 편집 도구의 영역에 해당한다. 다수의 <CarryAlong> 요소들이 이름 공간의 동일한 요소 또는 속성을 참조한다면, 특정된 마지막 <CarryAlong>이 우선 순위를 가진다.

<CarryAlong> 특성들

ㆍ 속성 ㆍ 설명

ㆍ 요소들 ㆍ 문서가 편집될 때 함께 전달될 것이 요청되는 요소 이름들의 공간 범위가 정해진 리스트 또는 이름 공간의 모든 요소들의 내용들을 지시하는 "*"이 함께 전달되어야 한다. 특정되지 않으면, 요소들은 디폴트로 "*"가 된다.

ㆍ 속성들 ㆍ 함께 전달될 요소들내의 특성 이름들의 공간 범위가 정해진 리스트 또는 요소들의 모든 특성들을 지시하는 "*"가 함께 전달되어야 한다. 요소가 무시되고 함께 전달될 때, 모든 특성들은 이 특성의 내용들과 상관없이 함께 전달된다. 이 특성은, 다음 예에서와 같이, 특정된 특성이 무시되지 않는 요소에 사용될 경우에만 효과를 가진다. 디폴트로, 특성들은 "*"이다.

<MustUnderstand> 요소

<MustUnderstand>는, Ignorable 요소의 효과들을 반전시키는 요소이다. 이 기법은, 예를 들어, 대체 내용과 구성될 경우에 유용하다. <MustUnderstand> 요소에 의해 정의된 범위를 벗어나면, 요소는 여전히 Ignorable인 상태로 남는다.

<MustUnderstand> 속성들

ㆍ 속성 ㆍ 설명

ㆍ NamespaceUri ㆍ 항목들이 이해되어야 하는 이름 공간의 URI

<AlternateContent> 요소

<AlternateContent> 요소는, 특정된 내용의 어떤 부분이 이해되지 않으면, 대체 내용이 제공될 수 있게 한다. AlternateContent 블록은 <Prefer> 및 <Fallback> 블록 모두를 사용한다. <Prefer> 블록의 어떤 것이 이해되지 않으면, <Fallback> 블록의 내용들이 사용된다. 대체용(fallback)이 사용된다는 것을 지시하기 위해, 이름 공간은 <MustUnderstand>로 선언된다. 이름 공간이 무시될 수 있는 것으로 선언되고 그 이름 공간이 <Prefer> 블록내에서 사용되면, <Fallback> 블록의 내용은 사용되지 않을 것이다.

버전 관리 마크업의 예들

< Ignorable > 사용하기

이 예는, 그것의 초기 버전에서 요소 Circle을 정의하고 마크업의 차후 버전(버전 2)에서 도입된 Circle의 불투명 속성 및 마크업의 그 이후 버전(버전 3)에서 도입된 Luminance 특성을 사용하는 가공의 마크업 이름 공간, http://PLACEHOLDER/Circle,을 사용한다. 이 마크업은 버전 1 및 2 뿐만 아니라 3 및 그 이상으로 로딩될 수 있는 상태를 유지한다. 또한, <CarryAlong> 요소는, 편집자가 v3:Luminance를 이해하지 못하는 때라 하더라도, v3:Luminance가 반드시 보존되어야 한다는 것을 특정한다.

버전 1 판독기의 경우, Opacity 및 Luminance가 무시된다.

버전 2 판독기의 경우, Luminance만이 무시된다.

버전 3 판독기 및 그 이상의 경우, 모든 특성들이 사용된다.

< MustUnderstand > 사용하기

다음의 예는 <MustUnderstand> 요소의 사용을 나타낸다.

<MustUnderstand> 요소의 사용은, 비록 그것이 루트 요소에서 Ignorable로 선언되었다 할지라도, v3:Luminance로의 참조들을 오류가 되게 한다. 이 기법은, 예를 들어, 버전 2에 부가된 Canvas의 Luminance 특성 대신에 사용하는 대체 내용과 구성될 경우에 유용하다. Canvas 요소의 범위를 벗어나면, Circle의 Luminance 특성은 다시 무시될 수 있다.

< AlternateContent > 사용하기

어떤 요소 또는 속성이 <MustUnderstand>로 선언되었지만 <AlternateContent> 블록의 <Prefer> 블록에서 이해되지 않으면, <Prefer> 블록은 전체가 생략되고 <Fallback> 블록이 정상(normal)으로 프로세싱된다(즉, 마주친 모든 MustUnderstand 항목들이 오류로서 보고된다).

리치 패키지 포맷

다음의 논의에서는, 특정 파일 포맷의 설명이 제공된다. 이 섹션에서의 개개의 1차 하부-제목들은 "리치 패키지 포맷에 대한 소개", "리치 패키지 구조", "고정 페이로드 부분들", "FixedPage 마크업 기본들", "고정-페이로드 요소들 및 특성들", 및 "FixedPage 마크업"을 포함한다. 각각의 1차 하부-제목은 하나 이상의 관련된 하부-제목들을 가진다.

리치 패키지 포맷으로의 도입

예시적 프레임워크를 상술하였으므로, 다음 설명은, 상술한 도구들을 이용해 제공되는 특정 포맷 중 하나이다. 다음 설명은 단 하나의 예시적 포맷만을 구성하지만 청구된 주제의 애플리케이션에 한정하려는 것이 아니라는 것을 알 수 있을 것이다.

이 실시예에 따르면, 하나의 패키지는, 각각이 문서의 상이한 표현으로 동작하는 다수 페이로드들을 포함할 수 있다. 페이로드는, 식별 가능한 "루트" 부분 및 그 루트 부분의 유효한 프로세싱을 위해 필요한 모든 부분들을 포함하는, 부분들의 집합이다. 예를 들어, 페이로드는 문서의 고정된 표현, 환원 가능한 표현, 또는 임의의 어떤 표현일 수 있다.

다음 설명은 고정 페이로드라고 하는 특정 표현을 정의한다. 고정 페이로드는, 반대로 FixedPage 부분들을 참조하는 FixedPanel 마크업을 포함하는 루트 부분을 가진다. 이들은 다같이 다수-페이지 문서의 정확한 렌더링을 설명한다.

하나 이상의 고정 페이로드를 보유하며 후술하는 다른 규칙들을 수반하는 패키지를 리치 패키지라고 한다고 알려져 있다. 리치 패키지들의 판독기들 및 기입기들은, 리치 패키지 포맷의 명세서에 기초해, 자신들만의 고유한 파서들 및 렌더링 엔진들을 구현할 수 있다.

리치 패키지들의 사양들

설명된 실시예에 따르면, 리치 패키지들은, 정보 작업자들이 문서들을 분배, 아카이브, 및 렌더링하기 위해 갖는 요구 사항들을 처리한다. 공지의 렌더링 규칙들을 사용해, 리치 패키지들은, 클라이언트 장치들 또는 애플리케이션들을 특정 오퍼레이팅 시스템들 또는 서비스 라이브러리들에 묶지 않으면서, 그들이 보존된 포맷으로부터 명료하고 정확하게 재생되거나 프린트될 수 있다. 또한, 리치 페이로드는 중립적이고 애플리케이션-독립적인 방식으로 표현되기 때문에, 패키지를 생성하는데 사용된 애플리케이션 없이도, 문서를 통상적으로 볼 수 있고 프린트할 수 있다. 이러한 능력을 제공하기 위해, 고정 페이로드 개념이 리치 패키지에 도입되고 포함된다.

설명된 실시예에 따르면, 고정 페이로드는 고정된 갯수의 페이지들을 가지며 페이지 브레이크들은 항상 동일하다. 고정 페이로드의 페이지에 대한 모든 요소들의 레이아웃이 판정된다. 각각의 페이지는 고정 크기 및 방향을 가진다. 이와 같이, 소비측에서는 전혀 레이아웃 계산들을 수행할 필요가 없으며 내용은 간단하게 렌더링될 수 있다. 이것은 단순히 그래픽 뿐만 아니라, 정확한 인쇄 배치를 사용해 고정 페이로드로 표현된 텍스트에도 적용된다. 시각적 프리미티브들의 강력하지만 단순한 세트를 사용해 페이지의 내용(텍스트, 그래픽, 영상들)을 설명한다.

리치 페이지들은 페이지들을 조직하기 위한 다양한 메커니즘들을 지원한다. 페이지들의 그룹은 하나씩 다같이 "FixedPanel"로 "접합"된다. 이러한 페이지들의 그룹은 대략적으로 종래의 다수-페이지 문서와 등가이다. 그 다음, FixedPanel은, "구성" 문서를 조립하기 위한 시퀀스들 및 선택들을 구축하는 프로세스인 구성에 추가적으로 참여할 수 있다.

도시되고 설명된 실시예에서, 리치 패키지들은, 예를 들어, 한 세트의 FixedPanel들을 하나의 더 큰 "문서"로 접합하는데, 사용될 수 있는 FixedPanel 시퀀스라는 특정한 종류의 시퀀스를 지원한다. 예를 들어, 상이한 소스들로부터 유래한 2개의 문서들:2-페이지의 표지 메모(FixedPanel) 및 20-페이지의 보고서(FixedPanel)을 접합하는 경우를 가정한다.

리치 패키지들은, "동일한" 내용의 대체 표현들을 포함하는 문서 패키지들을 구축할 때 사용될 수 있는 다수의 특정 선택기들을 지원한다. 구체적으로, 리치 패키지들은, 언어, 컬러 능력, 및 페이지 크기에 기초해 선택을 허용한다. 이와 같이, 선택기를 사용해, 예를 들어, 문서의 영어 표현과 불어 표현 사이에서 선택하는 2중-언어 문서를 가질 수 있다.

리치 패키지에서의 구성을 위해 간단하게 선택기 및 시퀀스를 사용하는 것 이외에, 선택기들 및 시퀀스들 또한 추가적인 선택기들 및 시퀀스들을 참조할 수 있어 강력한 집단 계층 구조들을 허용할 수 있다는 것에 주목하는 것이 중요하다. 이 실시예에 따라, 무엇을 할 수 있고 무엇을 할 수 없는지에 대한 정확한 규칙들이 "리치 패키지 구조"라는 명칭의 섹션에서 구체적으로 후술된다.

또한, 리치 패키지는, 고정 페이로드들은 아니지만 그 대신 문서의 더 풍부한 그리고 편집 가능할 수도 있는 표현들인 추가적인 페이로드들을 포함할 수 있다. 이로 인해, 패키지는, 편집기 애플리케이션에서 뿐만 아니라 시각적으로 정확하며 편집 애플리케이션 없이도 볼 수 있는 표현으로서 양호하게 동작하는 풍부하고 편집 가능한 문서를 포함할 수 있게 된다.

마지막으로, 이 실시예에 따르면, 리치 패키지들은 인쇄 티켓으로 공지되어 있는 것을 지원한다. 인쇄 티켓은, 패키지가 인쇄될 때 사용되어야 하는 설정들을 제공한다. 이러한 인쇄 티켓들은 실질적 호환성을 실현하기 위해 다양한 방법으로 첨부될 수 있다. 예를 들어, 인쇄 티켓은 전체 패키지에 "첨부"될 수 있으며 그 설정들은 전체 패키지에 영향을 줄 것이다. 인쇄 티켓들은 더 낮은 레벨의 구조(예를 들어, 개개의 페이지들)에 추가적으로 첨부될 수 있으며, 이들 인쇄 티켓들은 그들이 첨부된 부분을 인쇄할 때 사용될 우선 설정들을 제공할 것이다.

리치 패키지 구조

상술한 바와 같이, 리치 패키지는, "고정" 페이지들, FixedPanel들, 구성, 인쇄 티켓들 등을 포함하는 한 세트의 사양들을 지원한다. 이러한 사양들은 패키지 모델의 핵심 컴포넌트들:부분들 및 관계들을 사용해 패키지로 표현된다. 이 섹션 및 관련 하부-섹션들에서는, 이러한 모든 부분들 및 관계들이 어떻게 조립되고 관련되어야 하는지 등에 관한 설명을 포함하여, "리치-패키지"의 완전한 정의가 제공된다.

리치 패키지 구조 개요

도 10은 예시적인 리치 패키지 및, 이 실시예에서, 패키지를 구성하거나 패키지에서 찾아볼 수 있는 부분들의 유효한 유형들 각각을 도시한다. 다음의 표 8은 각각의 유효한 부분 유형을 열거하며 각각에 대한 설명을 제공한다.

FixedPage application/xml+FixedPage-PLACEHOLDER	각각의 FixedPage 부분은 페이지의 내용을 표현한다
FixedPanel application/xml+FixedPanel-PLACEHOLDER	각각의 FixedPanel은 한 세트의 FixedPage들을 순서대로 접합한다.
Font	폰트들은, 문서의 글리프들에 대한 신뢰할 수 있는 재생을 보장하기 위해, 패키지에 내장될 수 있다.
Image Image/jpeg image/png	이미지 부분들이 포함될 수 있다
구성 부분들 application/xml-Selector+[xxx] application/xml-Sequence+[xxx]	선택기들 및 시퀀스들은 패키지에 대한 더 높은-수준의 구성을 소개하는 "구성" 블록을 구축하는데 사용될 수 있다.
기술적 메타데이터 application/xml+SimpleTypeProperties-PLACEHOLDER	기술적 메타데이터(예를 들어, 제목, 키워드들)가 문서를 위해 포함될 수 있다.
인쇄 티켓 application/xml+PRINTTICKET-PLACEHOLDER	인쇄 티켓은 패키지를 인쇄할 때 사용될 설정들을 제공하기 위해 포함될 수 있다.

리치 패키지는 "어디에서든 보고 인쇄하는" 문서이도록 설계되기 때문에, 리키 패키지들의 판독기들 및 기입기들은 "유효한" 리치 패키지를 구성하는 것에 대한 공통적이며 명료하게-정의된 예상치들을 공유해야 한다. "유효한" 리치 패키지의 정의를 제공하기 위해, 다음에서는 먼저 몇가지 개념들을 정의한다.

리치 구성 부분들

리치 패키지는, 패키지의 시작 부분으로부터 구성 블록을 트래버스하는 것에 의해 "발견할 수 있는" 하나 이상의 FixedPanel을 포함해야 한다. 설명된 실시예에 따르면, 발견 프로세서는 다음의 알고리즘을 따른다.

ㆍ 패키지 시작 부분에서 시작해 구성 부분들의 그래프를 반복적으로

트래버스한다.

ㆍ 이러한 트래버스를 수행할 때, (후술하는) 리치 구성 부분들인 구

성 부분들로만 트래버스한다.

ㆍ (출력 아크들이 없는) 터미널 노드들 모두를 그래프의 가장자리에

배치한다.

이러한 터미널 노드들은 (그들의 <item> 요소들을 통해) 리치 페이로드 루트들이라고 하는 한 세트의 부분들을 참조한다.

고정 페이로드

고정 페이로드는, 루트 부분이 FixedPanel 부분인 페이로드이다. 예를 들어, 도 10의 고정 페이로드들 각각은 루트 부분으로서 관련된 FixedPanel 부분을 가진다. 페이로드는 FixedPanel의 유효한 프로세싱에 필요한 모든 부분들의 완전한 종결을 포함한다. 이들은 다음을 포함한다.

ㆍ FixedPanel 자체;

ㆍ FixedPanel내에서부터 참조되는 모든 FixedPage들;

ㆍ 페이로드의 FixedPage들 중 하나에 의해 (직접적으로 또는 선택기를 통해 간접적으로) 참조되는 모든 이미지 부분들;

ㆍ 페이로드내의 FixedPage들 중 하나에서 사용되는 이미지 브러시들로부터 직접적으로 또는 간접적으로 참조되는 (후술하는 바와 같은) 모든 리치 선택기들;

ㆍ 페이로드의 FixedPage들 중 하나에 의해 참조되는 모든 폰트 부분들;

ㆍ 고정 페이로드에 임의 부분에 첨부된 모든 기술적 메타데이터 부분들; 및

ㆍ 고정 페이로드의 임의 부분에 첨부된 임의의 인쇄 티켓들.

리치 패키지에 대한 유효성 규칙들

상기 정의들을 적절히 사용해, 이제는 설명된 실시예에 따른 "유효한" 리치 패키지를 설명하는 적절한 규칙들을 설명한다.

ㆍ 리치 패키지는, 상술한 바와 같은 패키지 관계의 표준 메커니즘을

사용해 정의된 시작 부분을 가져야 한다.

ㆍ 리치 패키지의 시작 부분은 선택기 또는 시퀀스 중 하나여야 한다.

ㆍ 리치 패키지는, FixedPanel인 하나 이상의 리치 페이로드 루트를

가져야 한다.

ㆍ PrintTicket 부분들은 구성 부분들 및 FixedPanel 부분들 중 하나,

또는 FixedPanel(들)에서 식별된 FixedPage 부분들 중 하나에 첨부

될 수있다. 본 예에서, 이것은 http://PLACEHOLDER/HasPrintTicketRel

관계를 통해 수행된다.

ｏ PrintTicket들은 이들 부분들 중 하나 또는 전부에 첨부될

수 있다.

ｏ 임의의 소정 부분은 단 하나의 첨부된 PrintTicket을 가져야

한다.

ㆍ 기술적 메타데이터 부분은 패키지의 임의 부분에 첨부될 수 있다.

ㆍ FixedPayload의 모든 Font 오브젝트는 섹션 "Font 부분들"에서 정

의된 폰트 포맷 규칙들을 충족시켜야 한다.

ㆍ 고정 페이로드의 임의의 FixedPage로부터의 이미지들에 대한 참조

들은 렌더링될 실제 이미지 부분을 찾아내기 위해 (어쩌면 다른 선

택기들을 통해 회귀적으로) 선택할 수 있는 선택기를 포인팅할 수

있다.

ㆍ 고정 페이로드에 사용된 모든 이미지 오브젝트는 섹션 "이미지 부

분들"에서 정의된 폰트 포맷 규칙들을 충족시켜야 한다.

ㆍ FixedPage로부터 (직접적으로 또는 선택기를 통해 간접적으로) 참

조되는 임의의 폰트, 이미지, 또는 선택기 부분에 대해, 참조하는

FixedPage로부터 참조되는 부분으로의 "필요 부분" 관계(관계 이름 = http://mmcf-fixed-RequiredResource-PLACEHOLDER)가 존재해야 한다

리치 구성 부분들

리치 패키지는 많은 유형들의 구성 부분을 포함할 수 있지만, 잘-정의된 구성 부분 유형들의 세트만이 이 문서에 따른 잘-정의된 동작을 갖는다. 잘-정의된 동작을 가진 이러한 구성 부분들을 리치 구성 부분들이라 한다. 이것들 이외의 부분들은 리치 패키지의 유효성을 판정할 때 상관이 없다.

다음의 구성 부분들 유형들이 리치 구성 부분들로 정의된다.

언어 선택기 application/xml+Selector+language	표현들의 자연어에 기초해 표현들 중에서 선택한다.
컬러 선택기 application/xml+Selector+color	표현들이 흑백인지 아니면 컬러인지의 여부에 기초해 표현들 중에서 선택한다
페이지 크기 선택기 application/xml+Selector+pagesize	표현들의 페이지 크기에 기초해 표현들 중에서 선택한다
내용 유형 선택기 application/xml+Selector+contenttype	표현들의 내용 유형들이 시스템에 의해 이해될 수 있는지의 여부에 기초해 표현들 중에서 선택한다
고정 시퀀스 application/xml+Selector+fixed	고정 내용인 자식들을 시퀀스로 구성한다.

리치 선택기들

리치 구성 부분들로서 정의된 선택기 구성 부분들을 리치 선택기들이라 한다. 상기한 바와 같이, 언어 선택기는, 영어 또는 불어와 같은, 표현들의 자연어에 기초해 표현들 중에서 선택한다. 이러한 언어를 찾아내기 위해, 선택기는 항목들 각각을 조사한다. XML인 것들만이 고려된다. 그것들에 대해, 각각의 루트 요소들이 그것의 언어를 판정하기 위해 조사된다. xml:lang 특성이 존재하지 않으면, 그 부분은 무시된다. 그 다음, 선택기는 그 부분들 각각을 차례로 고려하여, 첫번째로 그 언어가 시스템의 디폴트 언어와 매칭되는 것을 선택한다.

컬러 선택기는, 표현들이 흑백인지 또는 컬러인지의 여부에 기초해 표현들 중에서 선택한다. 페이지 크기 선택기는 표현들의 페이지 크기에 기초해 표현들 중에서 선택한다. 내용 유형 선택기는, 표현들의 내용 유형들이 시스템에 의해 이해될 수 있는지의 여부에 기초해 표현들 중에서 선택한다.

리치 시퀀스들

리치 구성 부분들로 정의된 시퀀스 구성 부분들을 리치 시퀀스들이라고 한다. 고정 시퀀스는 고정 내용인 자식들을 시퀀스로 구성한다.

고정 페이로드 부분들

고정 페이로드는, 각각이 자신의 하부-제목하에서 후술되는 FixedPanel 부분, FixedPage 부분, 이미지 부분들, 인쇄 티켓 부분들, 및 기술적 메타데이터 부분들을 포함할 수 있다.

FixedPanel 부분

고정-페이로드의 문서 구조는, 다음에 나타낸 바와 같이, FixedPage들을 spine의 부분으로 식별한다. spine 부분과 페이지 부분들간의 관계들은 spine에 대한 관계 스트림내에서 정의된다. FixedPanel 부분은 application/xml+PLACEHOLDER의 내용 유형이다.

고정-페이로드 내용의 spine는 <Document> 요소내에 <FixedPanel> 요소를 포함시키는 것에 의해 마크업에 특정된다. 다음의 예에서, <FixedPanel> 요소는 spine내에 보유된 페이지들의 소스들을 특정한다.

< Document > 요소

<Document> 요소는 특성들을 갖지 않으며, 하나의 자식:<FixedPanel>만을 가져야 한다.

< FixedPanel > 요소

<FixedPanel> 요소는, 순서가 매겨진 페이지들의 시퀀스를 하나의 다수-페이지 문서로 논리적으로 바인딩하는 문서 spine이다. 페이지들은 항상 그들만의 너비 및 높이를 특정하지만, <FixedPanel> 요소 또한 높이 및 너비를 선택적으로 특정할 수 있다. 이 정보는, 예를 들어, 페이지 크기에 기초해 대체 표현들 중에서 선택하는 것을 포함하여, 다양한 목적들을 위해 사용될 수 있다. <FixedPanel> 요소가 높이 및 너비를 특정한다면, 일반적으로 <FixedPanel>내의 페이지에 대한 너비 및 높이는 정렬되겠지만, 이러한 치수들이 개개 페이지들의 높이 및 너비를 특정하지는 않는다.

다음의 도표는 설명된 실시예에 따른 FixedPanel 특성들을 요약한다.

<FixedPanel> 특성	설명
PageHeight	<FixedPanel>에 포함된 페이지들의 통상적인 높이. 선택적
PageWidth	<FixedPanel>에 포함된 페이지들의 통상적인 너비. 선택적

<PageContent> 요소는 <FixedPanel> 요소의 유일하게 허용 가능한 자식 요소이다. <PageContent> 요소들은 문서의 페이지 순서와 매칭되는 순차적인 마크업 순서에 있다.

< PageContent > 요소

각각의 <PageContent> 요소는 단일 페이지에 대한 내용의 소스를 의미한다. 문서의 페이지 수를 판정하기 위해, <FixedPanel>내에 포함된 <PageContent> 자식들의 수를 카운트할 것이다.

<PageContent> 요소는 허용 가능한 자식들을 갖지 않으며, 페이지의 내용들을 위해 FixedPage 부분을 참조하는 하나의 요청 특성(Source)을 갖는다.

<FixedPanel> 요소들과 같이, <PageContent> 요소는 선택적으로, 단일 페이지의 크기를 반영하는 PageHeight 및 PageWidth 특성을 포함할 수 있다. 요청 페이지 크기는 FixedPage 부분에 특정되고;<PageContent>에 대한 선택적 크기는 다만 권고일 뿐이다. <PageContent> 크기 특성들로 인해, 문서 뷰어들과 같은 애플리케이션들은, 개개의 FixedPage 부분들 모두를 로딩 및 파싱하지 않으면서, 재빨리 문서에 대한 시각적 레이아웃을 추정할 수 있다.

바로 아래에 제공된 도표는 <PageContent> 특성들을 요약하며 그 특성들의 설명을 제공한다.

<PageContent> 특성	설명
Source	패키지내의 별개 부분에 보유되어 있는 페이지 내용을 참조하는 URI 스트링. 이 내용은 패키지내의 부분으로서 식별된다. 요청됨.
PageHeight	선택적
PageWidth	선택적

페이지 내용의 URI 스트링은, 패키지와 관련하여 내용 부분의 위치를 참조해야 한다.

FixedPage 부분

<FixedPanel>의 <PageContent> 요소 각각은 이름(URI)으로 FixedPage 부분을 참조한다. 각각의 FixedPage 부분은 한 페이지의 내용 렌더링을 설명하는 FixedPage 마크업을 포함한다. FixedPage 부분은 application/xml+PLACEHOLDER-FixedPage의 내용 유형이다.

마크업으로 FixedPage 들 설명하기

다음은 소스 내용의 마크업이 상기 예시적 spine 마크업(<PageContent Source="p1.xml"/>)에서 참조된 페이지를 찾을 수 있는 방법의 일례이다.

다음 도표는 FixedPage 특성들을 요약하며 그 특성들의 설명을 제공한다.

FixedPage 특성	설명
PageHeight	요청됨
PageWidth	요청됨

FixedPage 마크업에서의 판독 순서

일 실시예에서, FixedPage내에 포함된 Glyphs 자식 요소들의 마크업 순서는 페이지의 텍스트 내용에 대한 소정 판독 순서와 동일해야 한다. 이러한 판독 순서는 뷰어에서의 FixedPage로부터의 대화식 선택/순차적 텍스트 복사 및 액세스 가능성 기술(accessibility technology)에 의한 순차적 텍스트로의 액세스 가능화 모두에 사용될 수 있다. 마크업 순서와 판독 순서간의 이러한 대응을 보장하는 것은 FixedPage 마크업을 생성하는 애플리케이션의 책임이다.

이미지 부분들

지원되는 포맷들

설명된 실시예에 따르면, 리치 패키지의 FixedPage들에 의해 사용되는 이미지 부분들은, 다른 포맷들이 사용될 수도 있지만, 고정된 갯수의 포맷들, 예를 들어, PNG 또는 JPEG일 수 있다.

폰트 부분들

설명된 실시예에 따르면, 리치 패키지들은 한정된 갯수의 폰트 포맷들을 지원한다. 도시되고 설명된 실시예에서, 지원 폰트 포맷은 TrueType 폰트 및 OpenType 폰트를 포함한다.

당업자들이라면 알 수 있는 바와 같이, OpenType 폰트 포맷은, PostScript 폰트 데이터 및 복잡한 인쇄용 레이아웃을 부가하는, TrueType 폰트 포맷의 확장이다. OpenType 폰트 파일은 TrueType 아웃라인 폰트 또는 PostScript 아웃라인 폰트 중 하나를 구비하는, 도표 포맷의 데이터를 포함한다.

설명된 실시예에 따르면, 다음의 폰트 포맷들:Adobe 유형 1, 비트맵 폰트, 숨겨진 특성을 가진 폰트, (그것을 나열할 것인지의 여부를 판정하기 위해 시스템 플래그를 사용하는) 벡터 폰트들, 및 (폰트 계열 이름이 EUDC인) EUDC 폰트는 리치 패키지들에서 지원되지 않는다.

폰트들의 세분화

고정 페이로드들은 상세히 후술되는 Glyphs 요소를 사용해 모든 텍스트를 표현한다. 이 실시예에서, 포맷은 고정되어 있으므로, FixedPayload들에 의해 요청되는 글리프들만을 포함하도록 폰트들을 세분할 수 있다. 따라서, 리치 패키지들의 폰트들은 글리프 용도에 기초해 세분될 수 있다. 세분된 폰트가 원래 폰트의 모든 글리프들을 포함하지는 않겠지만, 세분된 폰트는 유효한 OpenType 폰트 파일이어야 한다.

인쇄 티켓 부분들

인쇄 티켓 부분들은, 패키지가 인쇄될 때 사용될 수 있는 설정들을 제공한다. 이러한 인쇄 티켓들은 실질적 호환성을 실현하기 위해 다양한 방식으로 첨부될 수 있다. 예를 들어, 인쇄 티켓은 전체 패키지에 "첨부"될 수 있으며 그 설정들은 전체 패키지에 영향을 미칠 것이다. 인쇄 티켓들은 추가적으로 더 낮은 레벨의 구조(예를 들어, 개개의 페이지들)에 첨부될 수 있고 이들 인쇄 티켓들은 그들이 첨부된 부분을 인쇄할 때 사용될 우선 설정들을 제공할 것이다.

기술적 메타데이터

상기한 바와 같이, 기술적 메타데이터 부분들은 패키지들의 기입기들 또는 프로듀서들에게, 패키지들의 판독기들이 값들을 확실하게 찾아낼 수 있도록 특성 값들을 저장하는 방법을 제공한다. 이러한 특성들은 통상적으로 전체로서의 패키지 뿐만 아니라 컨테이너내의 개별적인 부분들에 관한 추가적인 정보를 기록하는데도 사용된다.

FixedPage Markup 기본들

이 섹션은 FixedPage 마크업과 관련된 일부 기본 정보를 설명하며 다음의 섹션들:"고정 페이로드 및 다른 마크업 표준들", "FixedPage 마크업 모델", "리소스들 및 리소스 참조들", 및 "FixedPage 드로잉 모델"을 포함한다.

고정 페이로드 및 다른 마크업 표준들

리치 패키지의 고정 페이로드에 대한 FixedPanel 및 FixedPage 마크업은 Windows® Longhorn의 Avalon XAML 마크업으로부터의 서브세트이다. 즉, 고정 페이로드 마크업은, (이 문서에 기록된 바와 같은) 독립적인 XML 마크업 포맷으로 독립적인 상태에 있지만, 원래의 다수-페이지 문서의 위지위그(WYSIWYG) 재생을 Longhorn 시스템들에서와 동일한 방법으로 로딩하여 재생한다.

XAML 마크업에 대한 어떤 배경으로서, 다음을 고려한다. XAML 마크업은, 사용자가 오브젝트들 및 오브젝트들 이면의 프로그래밍 로직에 대한 계층 구조를 XML-기반 마크업 언어로서 특정할 수 있게 한다. 이것은 오브젝트 모델이 XML로 설명될 수 있는 능력을 제공한다. 이로 인해, Microsoft Corporation에 의한 .NET 프레임워크의 CLR(Common Language Runtime)에서의 클래스들과 같은, 확장 가능한 클래스들이 XML로 액세스될 수 있게 된다. XAML 메커니즘은 XML 태그들의 CLR 오브젝트들로의 직접적인 매핑 및 마크업에서의 관련 코드를 표현할 수 있는 능력을 제공한다. 다양한 구현들이 특정적으로 XAML의 CLR-기반 구현을 이용할 필요는 없다는 것을 알 수 있다. 오히려, CLR-기반 구현은, 이 문서에서 설명된 실시예들의 문맥에서 XAML이 이용될 수 있는 한가지 방법을 구성할 뿐이다.

보다 구체적으로, CLR 개념들(왼쪽 컴포넌트들)의 XML(오른쪽 컴포넌트들)로의 예시적 매핑을 도시하는 도 11과 관련하여 다음을 고려한다. 반사라고 하는 CLR 개념을 사용하는 xmlns 선언에서 이름 공간들이 발견된다. 클래스들은 XML 태그들로 직접적으로 매핑된다. 특성들 및 이벤트들은 특성들로 직접 매핑된다. 이러한 계층 구조를 사용해, 사용자는 XML 마크업 파일들의 임의의 CLR 오브젝트들에 대한 계층 구조 트리를 특정할 수 있다. xaml 파일들은 .xaml 확장자 및 application/xaml+xml의 매체 유형을 가진 xml 파일들이다. xaml 파일들은, 통상적으로 xmlns 특성을 사용해 이름 공간을 특정하는 하나의 루트 태그를 가진다. 이름 공간은 다른 유형들의 태그들로도 특정될 수 있다.

계속해서, xaml 파일의 태그들은 일반적으로 CLR 오브젝트들로 매핑된다. 태그들은 요소들, 복합 특성들, 정의들, 또는 리소스들일 수 있다. 요소들은, 일반적으로 실행 시간 동안에 초기화되며 오브젝트들의 계층 구조를 형성하는 CLR 오브젝트들이다. 복합 특성 태그들이 부모 태그의 특성을 설정하는데 사용된다. 정의 태그들이 페이지에 코드를 부가하고 리소스들을 정의하는데 사용된다. 리소스 태그는, 단지 트리를 리소스로 특정하는 것에 의해, 오브젝트들의 트리를 재사용하는 능력을 제공한다. 또한, 정의 태그들은 다른 태그내에서 xmlns 특성으로 정의될 수도 있다.

(통상적으로 기입기에 의해) 문서가 마크업으로 적절히 설명되고 나면, (통상적으로 판독기에 의해) 마크업은 파싱되고 프로세싱될 수 있다. 적당하게 구성된 파서는 루트 태그로부터 어떤 CLR 어셈블리들 및 이름 공간들이 태그를 찾아내기 위해 검색되어야 하는지를 판정한다. 많은 경우, 파서는 xmlns 특성에 의해 특정된 URL에서 이름 공간 정의 파일을 찾을 것이고 찾아낼 것이다. 이름 공간 정의 파일은 어셈블리들의 이름 및 그들의 설치 경로와 CLR 이름 공간들의 리스트를 제공한다. 파서가 태그를 직면할 경우, 파서는, 어떤 CLR 클래스가 태그의 xmlns 및 그 xmlns에 대한 정의 파일을 사용해 태그를 참조하는지를 판정한다. 파서는, 어셈블리들 및 이름 공간들이 정의 파일에 특정된 순서로 검색한다. 매칭을 발견하면, 파서는 클래스의 오브젝트를 초기화한다.

이와 같이, 바로 위에서 그리고 상기 참조에 의해 통합된 애플리케이션에서 보다 상세히 설명된 메커니즘으로 인해, 오브젝트 모델들은 마크업 태그들을 사용하는 XML-기반 파일로 표현될 수 있다. 오브젝트 모델들을 마크업 태그들로 표현하는 이러한 능력은 벡터 그래픽 드로잉들, 고정-포맷 문서들, 적응적-흐름 문서들, 및 애플리케이션 UI들을 비동기적으로 또는 동기적으로 생성하는데 사용될 수 있다.

도시되고 설명된 실시예에서, 고정 페이로드 마크업은 프리미티브들을 렌더링하는 Avalon XAML의 아주 최소화된, 극히 빈약한 서브세트이다. 이것은, 완전한 충실도를 가진, Avalon으로 표현될 수 있는 모든 것을 시각적으로 표현한다. 고정 페이로드 마크업은 Avalon XAML 요소들 및 특성들-덧붙여 추가적인 규약들, 정규 형태들, 또는 Avalon XAML과 비교되는 용도 제한들의 서브세트이다.

근본적으로-최소로 정의된 고정 페이로드 마크업 세트는, 프린터 RIP들 또는 대화식 뷰어 애플리케이션들과 같은, 리치 패키지 판독기들의 구현 및 테스트와 관련된 비용을 감소시킬 뿐만 아니라 관련 파서의 복잡도 및 메모리 공간을 감소시킨다. 빈약한 마크업 세트 또한 리치 패키지 기입기들 및 판독기들 사이에서의 세분화, 오류들, 또는 불일치 가능성들을 최소화하여, 포맷 및 그 생태계를 근본적으로 좀더 강건하게 한다.

최소화된 고정 페이로드 마크업 이외에, 리치 패키지는 뷰어들 또는, 하이퍼링크들, 섹션/아웃라인 구조와 네비게이션, 텍스트 선택, 및 문서 액세스 가능성과 같은, 사양들을 가진 리치 패키지 문서들의 표현들을 지원하기 위한 추가적 의미 정보에 대한 마크업을 특정할 것이다.

마지막으로, 상술한 버전 관리 및 확장 가능성 메커니즘들을 사용하면, 최소의고정 페이로드 마크업에 특정한 목표 소비 애플리케이션들, 뷰어들, 또는 장치들을 위한 요소들의 좀더 풍성한 세트를 보완할 수 있다.

FixedPage 마크업 모델

도시되고 설명된 실시예에서, FixedPage 부분은, XML-요소들, XML-속성들, 및 XML-이름 공간들에 기초해, XML-기반 마크업 언어로 표현된다. 이 문서에서는 FixedPage 마크업에 포함시키기 위한 3개의 XML-이름 공간들이 정의된다. 이러한 이름 공간 하나는 이 명세서의 다른 곳에서 정의된 버전-제어 요소들 및 특성들을 참조한다. FixedPage 마크업의 요소들 및 속성들에 사용되는 주된 이름 공간은 "http://schemas.microsoft.com/MMCF-PLACEHOLDER-FixedPage"이다. 그리고 마지막으로, FixedPage 마크업은, 후술하는 제 3 이름 공간을 필요로 하는 "리소스들"의 개념을 도입한다.

FixedPage 마크업이 XML-요소들 및 XML-속성들을 사용해 표현되긴 하지만, 그 세부 사항은 "내용들" 및 "특성들"에 대한 더 높은-수준의 추상 모델에 기초한다. FixedPage 요소들은 모두 XML-요소들로서 표현된다. 단지 소수의 FixedPage 요소들만이, 자식 XML-요소들로서 표현된 "내용들"을 보유할 수 있다. 그러나, 특성 값은 XML-속성을 사용하거나 자식 XML-요소를 사용해 표현될 수 있다.

또한, FixedPage 마크업은 리소스-사전 및 리소스-참조라는 한 쌍의 개념들에 의존한다. 리소스-사전 및 다수 리소스-참조들의 구성으로 인해, 하나의 특성-값이 다수의 FixedPage-마크업 요소들의 다수 특성들에 의해 공유될 수 있게 된다.

FixedPage 마크업의 특성들

도시되고 설명된 실시예들에는, FixedPage-마크업 특성의 값을 특정하는데 사용될 수 있는 마크업의 3가지 형태들이 존재한다.

특성이 리소스-참조를 사용해 특정되면, 특성 이름은 XML-속성 이름으로 사용되고 속성-값에 대한 특수한 통사(special syntax)는 리소스 참조의 존재를 지시한다. "리소스들 및 리소스-참조들"이라는 명칭의 섹션에서, 리소스 참조들을 표현하기 위한 통사가 설명된다.

리소스-참조로서 특정되지 않는 임의의 특성-값은, 그 값이 설정되고 있는 특성을 식별하는 중첩된 자식 XML-요소를 사용해 XML로 표현된다. 이러한 "복합-특성 통사"가 후술된다.

마지막으로, 일부의 비-리소스-참조 특성-값들은 간단한-텍스트 스트링들로 표현될 수 있다. 이러한 모든 특성-값들은 복합-특성 통사를 사용해 표현될 수 있지만, 이들은 간단한 XML-속성 통사를 사용해 표현될 수도 있다.

임의의 소정 요소에 대해, 값을 특정하는데 사용된 통사에 관계없이, 어떠한 특성도 단 한번만 설정될 수 있다.

간단한 속성 통사

간단한 스트링으로 표현될 수 있는 특성 값의 경우, XML-속성-통사가 특성-값을 특정하는데 사용될 수 있다. 예를 들어, "SolidColorBrush"라는 FixedPage-마크업 요소가 주어지면, "컬러"라는 특성의 경우, 다음의 통사가 특성 값을 특정하는데 사용될 수 있다.

복합-특성 통사

일부 특성 값들은 간단한 스트링으로 표현될 수 없는데, 예를 들어, XML-요소가 특성 값을 설명하는데 사용된다. 이러한 특성 값은 간단한 속성 통사를 사용해 표현될 수 없다. 그러나, 이들은 복합-특성 통사(compound-property syntax)를 사용해 표현될 수 있다.

복합-특성 통사에서는, 자식 XML-요소가 사용되지만, XML-요소 이름은 부모-요소 이름과 .로 구분된 특성 이름의 구성으로부터 유도된다. <SolidColorBrush>로 설정될 수 있는 특성 "Fill"을 가진 FixedPage-마크업 요소 <Path>가 주어지면, 다음의 마크업이 <Path> 요소의 "Fill" 특성을 설정하는데 사용될 수 있다.

간단한-속성 통사가 특성-값을 표현하기에 충분한 경우들에서도, 복합-특성 통사가 사용될 수 있다. 그래서, 이전 섹션의 다음 예:

는, 대신에 다음의 복합-특성 통사로 표현될 수 있다.

복합-특성 통사를 사용해 특성-값을 특정할 경우, "특성들"을 표현하는 자식 XML-요소들이 "내용들"을 표현하는 자식 XML-요소들 전에 나타나야 한다. 개개 복합-특성 자식 XML-요소들이 부모-요소의 어떤 "내용들" 전에 다같이 나타나기만 하면, 그들의 순서는 중요하지 않다.

예를 들어, (후술하는) <Canvas> 요소의 Clip 및 RenderTransform 속성들 모두를 사용할 경우, 양자는 <Canvas>의 임의의 <Path> 및 <Glyphs> 내용들 전에 나타나야 한다.

리소스들 및 리소스 참조들

리소스 사전들은, 각각을 리소스라고 하는, 공유 가능한 특성 값들을 보유하는데 사용될 수 있다. 자체가 FixedPage-마크업 요소인 임의의 특성 값이 리소스 사전에 보유될 수 있다. 리소스 사전의 리소스 각각은 이름을 전달한다. 리소스의 이름은 특성의 XML-속성으로부터 리소스를 참조하는데 사용될 수 있다.

도시되고 설명된 실시예에서는, <Canvas> 및 <FixedPage> 요소들이 리소스 사전을 전달할 수 있다. 리소스 사전은 "리소스들"이라고 하는 특성에서의 <Canvas> 및 <FixedPage> 요소들에 대한 특성으로서 마크업으로 표현된다. 그러나, 개개의 리소스-값들은 <FixedPage.Resources> 또는 <Canvas.Resources> XML-요소내에 직접적으로 삽입된다. 통사적으로, <Canvas.Resources> 및 <FixedPage.Resources>에 대한 마크업은 "내용들"을 가진 마크업 요소들에 대한 것과 유사하다.

이 실시예에 따르면, <Canvas.Resources> 또는 <FixedPage.Resources>는 <Canvas> 또는 <FixedPage>에 대한 임의의 복합-특성-통사 특성 값들을 선행해야 한다. 마찬가지로, 이들은 <Canvas> 또는 <FixedPage>에 대한 임의의 "내용들"을 선행해야 한다.

고정- 페이로드 리소스 사전들을 정의하기

임의의 <Canvas> 또는 <FixedPage>는, <Canvas.Resources> XML-요소를 사용해 표현된 리소스 사전을 전달할 수 있다. 하나의 리소스 사전내의 각 요소에게는 그 요소와 관련된 XML-속성을 사용하는 것에 의해 식별된 고유한 이름이 부여된다. 특성들에 대응되는 그러한 속성들로부터 이러한 "Name" 속성을 구별하기 위해, FixedFormat 요소들의 이름 공간이 아닌 이름 공간으로부터 Name 속성을 취한다. XML-이름 공간에 대한 URI는 "http://schemas.microfsoft.com/PLACEHOLDER-for-resources"이다. 다음의 예에서는, 하나는 직사각형을 위한 것이고 다른 하나는 원을 위한 2개의 기하 구조들이 정의된다.

리소스들을 참조하기

특성 값을 위에서 정의된 리소스들 중 하나로 설정하기 위해, 리소스 이름을 {}에 집어 넣는 XML-속성 값을 사용한다. 예를 들어, "{Rectangle}"은 사용될 기하 구조를 지시할 것이다. 다음의 마크업 샘플에서, 사전의 기하 구조 오브젝트들에 의해 정의된 직사각형 영역은 SolidColorBrush로 채워질 것이다.

이 실시예에 따르면, 리소스 참조가 리소스 사전의 리소스 정의내에서 발생해서는 안된다.

리소스 참조들을 해결하기 위한 규칙들의 범위 정하기

동일한 리소스 사전에 하나의 이름이 2번 사용될 수는 없지만, 동일한 이름이 하나의 FixedPage 부분내의 2개의 상이한 리소스 사전들에 사용될 수는 있다. 또한, 내부 <Canvas>의 리소스 사전은 어떠한 외부 <Canvas> 또는 <FixedPage>의 리소스 사전에 정의된 이름을 재사용할 수 있다.

리소스-참조가 요소의 특성을 설정하는데 사용될 경우, 소정 이름의 리소스를 위해 다양한 리소스 사전들이 검색된다. 특성을 담고 있는 요소가 <Canvas>라면, (존재한다면) <Canvas>의 리소스 사전이 소정 이름의 리소스를 위해 검색된다. 요소가 <Canvas>가 아니라면, <Canvas> 또는 <FixedPage>를 포함하는 가장 근접한 것으로부터 검색이 시작된다. 소정 이름이 처음에 검색된 리소스 사전에 정의되어 있지 않으면, <Canvas> 또는 <FixedPage>를 포함하는 다음으로 가장 근접한 것이 조사된다. 검색이 루트 <FixedPage> 요소까지 계속되고 소정 이름의 리소스가 <FixedPage>와 관련된 리소스 사전에서 발견되지 않으면, 오류가 발생한다.

다음 예가 이러한 규칙들을 보여 준다.

FixedPage 드로잉 모델

FixedPage (또는 중첩된 Canvas 자식) 요소는, 다른 요소들이 렌더링되는 요소이다. 내용의 정렬은 FixedPage (또는 Canvas)에 대해 특정된 특성들, FixedPage (또는 Canvas)상의 요소들에 대해 특정된 특성들에 의해 그리고 고정-페이로드 이름 공간에 대해 정의된 구성 규칙들에 의해 제어된다.

위치 요소들에 Canvas 사용하기

고정 마크업에서, 모든 요소들은 좌표계의 현재 원점(0,0)과 관련하여 배치된다. 요소를 포함하는 FixedPage 또는 Canvas의 각 요소에 RenderTransform 속성을 적용하는 것에 의해, 현재 원점은 이동될 수 있다.

다음 예는 RenderTranform을 통한 요소들의 배치를 도시한다.

좌표계들 및 단위들

도시되고 설명된 실시예에 따르면, 좌표계는 처음에, 좌표계의 한 단위는 부동 소수점 값으로 표현되는 1/96 인치와 동일하고, 좌표계의 원점은 FixedPage 요소의 상단 좌측 코너가 되도록 설정된다.

RenderTransform 속성은 임의의 자식 요소에 대해 특정되어 현재의 좌표계에 어파인 변환(affine transform)을 적용할 수 있다.

페이지 치수들

페이지 치수들은 FixedPage 요소에 대한 "PageWidth" 및 "PageHeight" 파라미터들에 의해 특정된다.

구성 규칙들

FixedPage들은 알파 채널을 가진 페인터 모델을 사용한다. 설명된 실시예에 따르면, 구성은 이러한 규칙들에 따라 그리고 다음의 순서로 발생해야 한다.

ㆍ FixedPage(또는 임의의 중첩된 Canvas)는, 자식 요소들이 마크업에 나타난 순서대로 자식 요소들이 그려지는 무한 표면(unbounded surface)으로 간주된다. 이 표면의 알파 채널은 "0.0"(모두 투과)으로 초기화된다. 실제 이상적인 무한 표면은, 모든 자식 요소들을 렌더링하는 것에 의해 생성되는 모든 마크들을 보유하기에 충분할 정도로 큰 비트맵 버퍼로 생각될 수 있다.

ㆍ 표면의 내용들은 FixedPage(또는 Canvas)의 RenderTransform 속성에 의해 특정된 어파인 변환을 사용해 변환된다.

ㆍ 모든 자식 요소들은 FixedPage(또는 Canvas)의 (이 또한 RenderTransform 속성을 사용해 변환되는) Clip 특성에 의해 클리핑된 표면상으로 렌더링된다. FixedPage는 추가적으로 (0,0,PageWidth,PageHeight)에 의해 특정된 직사각형으로 클리핑된다. 자식 요소가 불투명 속성 또는 OpacityMask 특성을 가진다면, 그것이 표면상으로 렌더링되기 전에 자식 요소에 그것이 적용된다.

ㆍ 마지막으로, FixedPage(또는 Canvas)의 내용들이 그것의 포함 요소들상으로 렌더링된다. FixedPage의 경우, 포함 요소는 물리적 이미지 표면이다.

렌더링은 다음과 같은 규칙들에 따라 발생한다.

ㆍ 표면상에 마크들을 생성하는 요소들은 "Glyphs" 및 "Path" 뿐이다.

ㆍ 다른 모든 렌더링 효과들은, "Glyphs" 및 "Path" 요소들을 "Canvas"상에 배치하고, 그들의 다양한 유효 특성들을 적용하는 것에 의해, 실현될 수 있다.

고정- 페이로드 요소들 및 특성들

도시되고 설명된 실시예에 따르면, 고정 페이로드 요소는 페이지들 및 페이지들의 내용들을 표현하기 위해 마크업에 사용된 XML 요소들의 작은 세트를 포함한다. FixedPanel 부분의 마크업은 문서의 페이지들을 <Document>, <FixedPanel>, 및 <PageContent> 요소들을 사용해 공통의, 용이하게-색인된 루트로 합친다. 각각의 FixedPage 부분은 <FixedPage> 요소의 패이지 내용들을 (드로잉의 모든 것을 함께 하는) <Path> 및 <Glyphs> 요소들과 그들을 그룹화하기 위한 <Canvas> 요소만으로 표현한다.

고정-페이로드 마크업 요소의 계층 구조가 "최상위 요소들", "Path, Clip을 위한 기하 구조", "Path, Glyphs, 또는 OpacityMask를 채우는데 사용되는 브러시들", "FixedPage 또는 Canvas를 위한 리소스 사전들", "알파 투과를 위한 불투명 마스크들", "클리핑 경로들", 및 "변환들"의 명칭을 가진 다음 섹션들에서 요약된다.

최상위 요소들

ㆍ <Document>[FixedPanel 부분당 정확하게 하나]

ｏ 속성들:

▶ [없음]

ｏ 자식 요소들:

▶ <FixedPanel>[정확하게 하나]

ㆍ <FixedPanel>

ｏ 속성들:

▶ PageHeight[선택적]

▶ PageWidth[선택적]

ｏ 자식 요소들:

▶ <PageContent>[1-N의 이러한 자식 요소들]

ㆍ <PageContent>

ｏ 속성들:

▶ Source[요구됨]

▶ PageHeight[선택적]

▶ PageWidth[선택적]

ｏ 자식 요소들:

▶ [없음]

ㆍ <FixedPage>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ PageHeight[(여기에서 또는 자식 요소로서)요청됨]

▶ PageWidth[(여기에서 또는 자식 요소로서)요청됨]

ｏ 자체가 XML 자식 요소로서 표현되는 리소스 사전:

▶ <FixedPage.Resources>

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <FixedPage.PageHeight>[(여기에서 또는 자식 요소로서)요청됨]

▶ <FixedPage.PageWidth>[(여기에서 또는 자식 요소로서)요청됨]

ｏ XML 자식 요소들을 통한 내용:

▶ <Canvas>

▶ <Path>

▶ <Glyphs>

ㆍ <Canvas>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

ｏ 리소스 사전 참조를 통해 표현되는 특성들:

▶ Clip

▶ RenderTransform

▶ OpacityMask

ｏ 자체가 XML 자식 요소로서 표현되는 리소스 사전:

▶ <Canvas.Resources>

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <Canvas.Opacity>

▶ <Canvas.Clip>

▶ <Canvas.RenderTransform>

▶ <Canvas.OpacityMask>

ｏ XML 자식 요소들을 통한 내용:

▶ <Canvas>

▶ <Path>

▶ <Glyphs>

ㆍ <Path>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

ｏ 리소스 사전 참조를 통해 표현되는 특성들:

▶ Clip

▶ RenderTransform

▶ OpacityMask

▶ Fill

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <Path.Opacity>

▶ <Path.Clip>

▶ <Path.RenderTransform>

▶ <Path.OpacityMask>

▶ <Path.Fill>

▶ <Path.Data>

ㆍ <Glyphs>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

▶ BidiLevel

▶ FontFaceIndex

▶ FontHintingEmSize

▶ FontRenderingEmSize

▶ FontUri

▶ Indices

▶ OriginX

▶ OriginY

▶ Sideways

▶ StyleSimulations

▶ UniCodeString

ｏ 리소스 사전 참조를 통해 표현되는 특성들:

▶ Clip

▶ RenderTransform

▶ OpacityMask

▶ Fill

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <Glyphs.Clip>

▶ <Glyphs.RenderTransform>

▶ <Glyphs.OpacityMask>

▶ <Glyphs.Fill>

▶ <Glyphs.Opacity>

▶ <Glyphs.BidiLevel>

▶ <Glyphs.FontFaceIndex>

▶ <Glyphs.FontHintingEmSize>

▶ <Glyphs.FontRenderingEmSize>

▶ <Glyphs.FontUri>

▶ <Glyphs.Indices>

▶ <Glyphs.OriginX>

▶ <Glyphs.OriginY>

▶ <Glyphs.Sideways>

▶ <Glyphs.StyleSimulations>

▶ <Glyphs.UniCodeString>

Path , Clip 을 위한 기하 구조

ㆍ <Path.Data>

ｏ 속성들:

▶ [없음]

ｏ 하나의 XML 자식 요소로 표현되는 특성 값:

[Path.Data는 정확하게 이러한 자식들 중 총 하나를 가진다]

▶ <GeometryCollection>

▶ <PathGeometry>

ㆍ <GeometryCollection>

ｏ 속성들:

▶ CombineMode

ｏ 자식 요소들:

[1-N 자식들]

▶ <GeometryCollection>

▶ <PathGeometry>

ㆍ <PathGeometry>

ｏ 속성들:

▶ FillRule

ｏ 자식 요소들:

[1-N 자식들]

▶ <PathFigure>

ㆍ <PathFigure>

ｏ 속성들:

▶ [없음]

ｏ 자식 요소들:

[StartSegment가 가장 먼저 오고, CloseSegment가 마지막이며, 그 사이에는 1-N의 Poly*가 온다.]

▶ <StartSegment>

▶ <PolyLineSegment>

▶ <PolyBezierSegment>

▶ <CloseSegment>

ㆍ <StartSegment>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Point

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <StartSegment.Point>

ㆍ <PolyLineSegment>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Points

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <PolyLineSegment.Points>

ㆍ <PolyBezierSegment>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Points

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <PolyBezierSegment.Points>

Path , Glyphs , 또는 OpacityMask 를 채우는데 사용되는 브러시들

ㆍ <Path.Fill>

ｏ 속성들:

▶ [없음]

ｏ 간단한 XML 자식 요소로서 표현되는 특성 값:

[Path.Fill은 이러한 자식들 중 정확하게 하나를 가진다]

▶ <SolidColorBrush>

▶ <ImageBrush>

▶ <DrawingBrush>

▶ <LinearGradientBrush>

▶ <RadialGradientBrush>

ㆍ <Glyphs.Fill>

ｏ 속성들:

▶ [없음]

ｏ 간단한 XML 자식 요소로서 표현되는 특성 값:

[Glyphs.Fill은 이러한 자식들 중 정확하게 하나를 가진다]

▶ <SolidColorBrush>

▶ <ImageBrush>

▶ <DrawingBrush>

▶ <LinearGradientBrush>

▶ <RadialGradientBrush>

ㆍ <SolidColorBrush>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

▶ Color

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <SolidColorBrush.Opacity>

▶ <SolidColorBrush.Color>

ㆍ <ImageBrush>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

▶ HorizontalAlignment

▶ VerticalAlignment

▶ ViewBox

▶ ViewPort

▶ Stretch

▶ TileMode

▶ ContentUnits

▶ ViewportUnits

▶ ImageSource

ｏ 리소스 사전 참조를 통해 표현되는 특성들:

▶ Transform

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <ImageBrush.Opacity>

▶ <ImageBrush.Transform>

▶ <ImageBrush.HorizontalAlignment>

▶ <ImageBrush.VerticalAlignment>

▶ <ImageBrush.ViewBox>

▶ <ImageBrush.ViewPort>

▶ <ImageBrush.Stretch>

▶ <ImageBrush.TileMode>

▶ <ImageBrush.ContentUnits>

▶ <ImageBrush.ViewportUnits>

▶ <ImageBrush.ImageSource>

ㆍ <DrawingBrush>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

▶ HorizontalAlignment

▶ VerticalAlignment

▶ ViewBox

▶ ViewPort

▶ Stretch

▶ TileMode

▶ ContentUnits

▶ ViewportUnits

ｏ 리소스 사전 참조를 통해 표현되는 특성들:

▶ Transform

▶ Drawing

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <DrawingBrush.Opacity>

▶ <DrawingBrush.Transform>

▶ <DrawingBrush.HorizontalAlignment>

▶ <DrawingBrush.VerticalAlignment>

▶ <DrawingBrush.ViewBox>

▶ <DrawingBrush.ViewPort>

▶ <DrawingBrush.Stretch>

▶ <DrawingBrush.TileMode>

▶ <DrawingBrush.ContentUnits>

▶ <DrawingBrush.ViewportUnits>

▶ <DrawingBrush.Drawing>

ㆍ <DrawingBrush.Drawing>

ｏ XML 자식 요소들을 통한 내용:

▶ <Canvas>

▶ <Path>

▶ <Glyphs>

ㆍ <LinearGradientBrush>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

▶ MappingMode

▶ SpreadMethod

▶ StartPoint

▶ EndPoint

ｏ 리소스 사전 참조를 통해 표현되는 특성들:

▶ Transform

▶ GradientStops

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <LinearGradientBrush.Opacity>

▶ <LinearGradientBrush.Transform>

▶ <LinearGradientBrush.MappingMode>

▶ <LinearGradientBrush.SpreadMethod>

▶ <LinearGradientBrush.StartPoint>

▶ <LinearGradientBrush.EndPoint>

▶ <LinearGradientBrush.GradientStops>

ㆍ <RadialGradientBrush>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Opacity

▶ Center

▶ Focus

▶ RadiusX

▶ RadiusY

ｏ 리소스 사전 참조를 통해 표현되는 특성들:

▶ Transform

▶ GradientStops

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <RadialGradientBrush.Opacity>

▶ <RadialGradientBrush.Transform>

▶ <RadialGradientBrush.Center>

▶ <RadialGradientBrush.Focus>

▶ <RadialGradientBrush.RadiusX>

▶ <RadialGradientBrush.RadiusY>

▶ <RadialGradientBrush.GradientStops>

ㆍ <GradientStops>

ｏ XML 자식 요소들을 통한 내용:

▶ <GradientStop> [이러한 자식들 중 1-N]

ㆍ <GradientStop>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Color

▶ Offset

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <GradientStop.Color>

▶ <GradientStop.Offset>

FixedPage 또는 Canvas 를 위한 리소스 사전들

ㆍ <FixedPage.Resources>

ㆍ <Canvas.Resources>

이러한 요소들은 리소스 사전들을 논의한 섹션에서 상술되었다.

알파 투과를 위한 Opacity 마스크들

ㆍ <Canvas.OpacityMask>

ｏ 속성들:

▶ [없음]

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

[Canvas.OpacityMask는 이러한 자식들 중 정확하게 하나를 가진다]

▶ <SolidColorBrush>

▶ <ImageBrush>

▶ <DrawingBrush>

▶ <LinearGradientBrush>

▶ <RadialGradientBrush>

ㆍ <Path.OpacityMask>

ｏ 속성들:

▶ [없음]

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

[Path.OpacityMask는 이러한 자식들 중 정확하게 하나를 가진다]

▶ <SolidColorBrush>

▶ <ImageBrush>

▶ <DrawingBrush>

▶ <LinearGradientBrush>

▶ <RadialGradientBrush>

ㆍ <Glyphs.OpacityMask>

ｏ 속성들:

▶ [없음]

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

[Glyphs.OpacityMask는 이러한 자식들 중 정확하게 하나를 가진다]

▶ <SolidColorBrush>

▶ <ImageBrush>

▶ <DrawingBrush>

▶ <LinearGradientBrush>

▶ <RadialGradientBrush>

클리핑 경로들

ㆍ <Canvas.Clip>

ｏ 속성들:

▶ [없음]

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

[Canvas.Clip은 이러한 자식들 중 정확하게 하나를 가진다]

▶ <GeometryCollection>

▶ <PathGeometry>

ㆍ <Path.Clip>

ｏ 속성들:

▶ [없음]

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

[Path.Clip은 이러한 자식들 중 정확하게 하나를 가진다]

▶ <GeometryCollection>

▶ <PathGeometry>

ㆍ <Glyphs.Clip>

ｏ 속성들:

▶ [없음]

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

[Glyphs.Clip은 이러한 자식들 중 정확하게 하나를 가진다]

▶ <GeometryCollection>

▶ <PathGeometry>

변환들

ㆍ <Canvas.RenderTransform>

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

▶ <MatrixTransform>[요청됨]

ㆍ <Path.RenderTransform>

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

▶ <MatrixTransform>[요청됨]

ㆍ <Glyphs.RenderTransform>

ｏ 하나의 XML 자식 요소로서 표현되는 특성 값:

▶ <MatrixTransform>[요청됨]

ㆍ <MatrixTransform>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ Matrix

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <MatrixTransform.Matrix>

ㆍ <ImageBrush.Transform>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ MatrixTransform

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <ImageBrush.Transform.MatrixTransform>

ㆍ <DrawingBrush.Transform>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ MatrixTransform

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <DrawingBrush.Transform.MatrixTransform>

ㆍ <LinearGradientBrush.Transform>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ MatrixTransform

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <LinearGradientBrush.Transform.MatrixTransform>

ㆍ <RadialGradientBrush.Transform>

ｏ 간단한 XML 속성들을 통해 직접적으로 표현되는 특성들:

▶ MatrixTransform

ｏ XML 자식 요소들을 통해 표현되는 특성들:

▶ <RadialGradientBrush.Transform.MatrixTransform>

FixedPage 마크업

각각의 FixedPage 부분은 <FixedPage> 요소에 근거를 둔 XML 마크업의 페이지 내용들을 표현한다. 이러한 FixedPage 마크업은, 요소들 및 특성들:(드로잉의 모든 것을 함께 하는)<Path> 및 <Glyphs> 요소들과 이들을 그룹화하기 위한 <Canvas> 요소의 작은 세트만을 가진, 기입기들과 판독기들간의 문서에 대한 위지위그 충실도를 제공한다.

공통 요소 특성들

FixedPage 마크업의 각 요소에 특징적인 속성들을 논의하기 전에, 요소들의 드로잉 및 그룹화에 공통적인 속성들:Opacity, Clip, RenderTransform, 및 OpacityMask을 고려한다. 이들은 최상위 요소들에 공통적인 특성들일 뿐만 아니라, 구성 규칙들 섹션에서 상술한 바와 같이, 부모로부터의 결과들을 그들의 자식 요소에 "누적하는" 유일한 특성들이다. 누적은 구성 규칙들을 적용한 결과이다. 다음 도표는, 속성들 각각에 대한 좀더 상세한 논의가 수반되는, 공통 속성들에 대한 요약 설명을 제공한다.

속성	요소들		설명
Opacity			요소의 균일한 투명성을 정의한다
자식 요소	요소들	설명
		Clip은 캔버스상에 브러시가 적용될 수 있는 영역을 제한한다.
		RenderTransform은 요소의 자식들에 대해 새로운 좌표 프레임을 확립한다. MatrixTransform만이 지원된다.
		불투명 속성과 동일한 방식으로 적용되지만, 픽셀-대-픽셀 방식으로 상이한 알파 값을 허용하는 알파 값들의 직사각형 마스크를 특정한다.

불투명 속성

Opacity는 렌더링시에 2개의 요소들을 투과적으로 블렌딩하는데 사용된다(알파 블렌딩). 불투명 속성은 0(완전 투명)에서 1(완전 불투명)의 범위이다. 이러한 포괄적 범위를 벗어난 값들은 마크업 파싱 동안 이 범위로 클램핑된다. 따라서, 실질적으로는, [-∞...0]은 투명이고 [1...∞]는 불투명이다.

불투명 속성은 (양자가 scRGB로서 특정된, 사전-배율되지 않은 소스 및 목적 컬러들을 가정하는)다음 계산들을 통해 적용된다.

O_E: OpacityMask 대응 위치에서의 요소에 대한 불투명 속성 또는 알파 값

A_S: 소스 표면에 존재하는 알파 값

R_S: 소스 표면에 존재하는 레드 값

G_S: 소스 표면에 존재하는 그린 값

B_S: 소스 표면에 존재하는 블루 값

A_D: 목적 표면에 이미 존재하고 있던 알파 값

R_D: 목적 표면에 이미 존재하고 있던 레드 값

G_D: 소스 표면에 이미 존재하고 있던 그린 값

B_D: 소스 표면에 이미 존재하고 있던 블루 값

A^*: 목적 표면에 대해 얻어진 알파 값

R^*: 목적 표면에 대해 얻어진 레드 값

G^*: 목적 표면에 대해 얻어진 그린 값

B^*: 목적 표면에 대해 얻어진 블루 값

T 아래 첨자를 갖도록 설계된 모든 값들(예를 들어, R_TI)은 임시적인 값들이다.

단계 1: 소스 알파 값을 불투명 값으로 배율하기

단계 2: 소스 알파 사전 배율하기

단계 3: 목적 알파 사전 배율하기

단계 4: 블렌딩

단계 5: 사전-배율 반전하기

A_T2 = 0이면, 모든 A*R*G*B를 0으로 설정한다.

그렇지 않으면:

클립 특성

클립 특성은 <GeometryCollection> 또는 <PathGeometry>의 기하 요소들 중 하나로서 특정된다(세부 사항들은 Path.Data 참고).

클립 특성은 다음의 방식으로 적용된다.

ㆍ 클립 자식 요소에 의해 설명된 기하 요소 내부에 해당되는 렌더링된 모든 내용들은 가시적이다.

ㆍ 클립 자식 요소에 의해 설명된 기하 요소 외부에 해당되는 렌더링된 모든 내용들은 비가시적이다.

RenderTransform 자식 요소

MatrixTransform이 요소들에 이용될 수 있는 유일한 변환 특성이다. 이것은 어파인 변환을 표현한다. 통사는 다음과 같다.

행렬 속성에서 특정되는 6개의 번호들은 m00, m01, m10, m11, dx, dy이다.

전체 행렬은 다음처럼 보인다.

m00 m01 0

m10 m11 0

dx dy 1

소정 좌표 X,Y는 다음의 계산들을 적용하는 것에 의해 얻어지는 좌표 X',Y'를 산출하기 위해 RenderTransform으로 변환된다.

OpacityMask 자식 요소

OpacityMask는 브러시를 특정하지만, Fill 브러시와 달리, 브러시의 알파 채널(상기 불투명 속성 참고)만이 요소를 렌더링하기 위한 추가적인 파라미터로서 사용된다. 그 다음, 요소의 각 픽셀에 대한 각각의 알파 값은 OpacityMask 브러시 대응 위치에서의 알파 값으로 추가 배율된다.

< Canvas > 요소

<Canvas> 요소는 요소들을 다같이 그룹화하는데 사용된다. 통상적으로, FixedPage 요소들은, 이들이 구성된 공통 특성(즉, Opacity, Clip, RenderTransform, 또는 OpacityMask)을 공유할 경우, 다같이 <Canvas>로 그룹화된다. 이러한 요소들을 다같이 Canvas로 그룹화하는 것에 의해, 공통 특성들은 대개 개개의 요소들 대신에 캔버스에 적용될 수 있다.

< Canvas >의 특성들 및 자식 요소들

<Canvas> 요소는 상술된 공통 속성들:Opacity, Clip, RenderTransform, 및 OpacityMask만을 가진다. 다음의 표 14에서 설명되는 바와 같이, 이들은 <Canvas> 요소로써 사용된다.

속성	Canvas에 대한 효과
Opacity	캔버스의 균일한 투명성을 정의한다
자식 요소	Canvas에 대한 효과
Clip	Clip은 Canvas의 자식 요소들에 의해 브러시가 적용될 수 있는 영역을 설명한다.
RenderTransform	RenderTransform은 캔버스의 자식 요소들에 대해, 다른 캔버스와 같은, 새로운 좌표계를 확립한다. MatrixTransform만이 지원된다.
OpacityMask	불투명 속성과 동일한 방식으로 적용되지만, 픽셀-대-픽셀 방식으로 다른 알파 값을 허용하는 알파 값들의 직사각형 마스크를 특정한다.

다음의 마크업 예는 <Canvas>의 사용을 도시한다.

Canvas 마크업의 판독 순서와 관련하여, 다음을 고려한다. FixedPage와 같이, Canvas내에 포함된 Glyphs 자식 요소들의 마크업 순서는 텍스트 내용의 소정 판독 순서와 동일해야 한다. 이러한 판독 순서는 뷰어의 FixedPage로부터의 순차적 텍스트에 대한 대화식 선택/복사 및 액세스 가능성 기술에 의해 순차적 텍스트로의 액세스를 가능하게 하는 것 모두에 사용될 수 있다. 마크업 순서와 판독 순서의 이러한 대응을 보장하는 것은 FixedPage 마크업을 생성하는 애플리케이션의 책임이다.

중첩된 Canvas 요소들내에 포함된 자식 Glyphs 요소들은 Canvas 이전 및 이후에서 발생하는 형제 Glyphs 요소들간에 직렬로 정렬된다.

예:

< Path > 요소

Path 요소는, 기하 영역을 설명하는 XML-기반 요소이다. 기하 영역은 채워질 수 있거나 클리핑 경로로서 사용될 수 있는 형태이다. 직사각형 및 타원과 같은, 보통의 기하 유형들을 Path 기하 구조들을 사용해 표현할 수 있다. 경로는, 필요한 Geometry.Data 자식 요소 및, Fill 또는 Opacity와 같은, 렌더링 특성들을 특정하는 것에 의해 설명된다.

< Path >의 특성들 및 자식 요소들

다음 특성들은 후술하는 바와 같이 <Path> 요소들에 적용될 수 있다.

특성들	경로에 대한 효과
Opacity	채워진 경로의 균일한 투명성을 정의한다.
자식 요소	경로에 대한 효과
Clip	클립은 Canvas의 기하 구조에 의해 브러시가 적용될 수 있는 영역을 설명한다.
RenderTransform	RenderTransform은 경로의 자식 요소들에 대해, Path.Data에 의해 정의된 기하 구조와 같은, 새로운 좌표계를 확립한다. MatrixTransform만이 지원된다.
OpacityMask	불투명 속성과 동일한 방식으로 적용되지만, 표면의 상이한 영역들에 대해 상이한 알파 값을 허용하는 알파 값들의 직사각형 마스크를 특정한다.
Data	경로의 기하 구조를 설명한다.
Fill	경로의 기하 구조를 칠하는데 사용되는 브러시를 설명한다.

<Path.Data> 자식 요소의 기하 구조에 의해 설명된 영역을 칠하는 방법을 설명하기 위해, Fill 특성을 사용한다. <Path.Data> 형태들이 그려질 수 있는 영역을 한정하기 위해, Clip 특성을 사용한다.

< Path >를 사용해 기하 구조들 설명하기

경로의 기하 구조는, 다음에 나타낸 바와 같이, <Path.Data>에 대한 일련의 중첩된 자식 요소들로서 특정된다. 기하 구조는 한 세트의 <PathGeometry> 자식 요소들을 포함하는 <GeometryCollection>이나 <PathFigures>를 포함하는 하나의 <PathGeometry> 자식 요소로 표현될 수 있다.

동일한 <GeometryCollection> 또는 <PathGeometry> 요소들이 Canvas, Path, 또는 Glyphs의 Clip 특성에 사용된 클리핑 경로에 대한 기하 구조를 정의한다.

다음 도표는 Path 기하 구조들을 정의하는 자식 요소들의 계층 구조를 소개한다.

기하 구조 요소들	설명
GeometryCollection	불 CombineMode 연산들을 사용해 렌더링된 한 세트의 PathGeometry 요소들.
PathGeometry	각각이 동일한 FillRule 옵션을 사용해 채워지는 한 세트의 PathFigure 요소들.
PathFigure	하나 이상의 세그먼트 요소들의 세트
StartSegment PolyLineSegment PolyBezierSegment CloseSegment

GeometryCollection

GeometryCollection은, 다같이 불 CombineMode 옵션들에 따른 렌더링을 위해 구성된 기하 오브젝트들의 세트이다. GeometryCollection 요소는 기하 형태들의 시각적 조합들을 구축하기 위한 FixedPage 마크업에서의 메커니즘이다.

속성들	GeometryCollection에 대한 효과
CombinationMode	기하 구조들을 구성하기 위한 상이한 모드들을 특정한다

CombineMode 속성은 CeometryCollection의 한 세트의 기하 형태들을 조합하는데 사용된 불 연산을 특정한다. 모드에 따라, 상이한 영역들이 포함되거나 제외될 것이다.

CombineMode 옵션들	설명
Complement	기존 영역이 새로운 영역으로부터 삭제되는 결과에 인해, 기존 영역이 대체된다는 것을 특정한다. 다시 말해, 새로운 영역으로부터 기존 영역이 제외된다.
Exclude	새로운 영역이 기존 영역으로부터 삭제되는 결과에 의해, 기존 영역이 대체된다는 것을 특정한다. 다시 말해, 기존 영역으로부터 새로운 영역이 제외된다.
Intersect	그들의 논리곱을 취하는 것에 의해, 2개 영역들이 조합된다.
Union	양자의 합을 취하는 것에 의해, 2개 영역들이 조합된다.
Xor	양자 모두에 의해서는 아니지만, 둘 중 하나에 의해 둘러싸인 영역들만을 취하는 것에 의해, 2개 영역들이 조합된다.

CombineMode들은 다음과 같이 핸들링된다.

Not Commutative Complement 및 Exclude는 교환 가능하지 않으므로, GeometryCollection의 제 1 기하 구조와 개별적인 각각의 나머지 기하 구조들 사이에서 정의된다. 예를 들어, {g1, g2, g3} 집합의 경우, Exclude의 CombineMode는 ((g1 exclude g2) 및 (g1 exclude g3))로서 적용될 것이다.

Commutative 불 연산들(합, XOR, 논리곱)은 교환 가능하므로 순서-독립적으로 기하 구조들에 적용된다.

PathGeometry

PathGeometry 요소는 한 세트의 PathFigure 요소들을 포함한다. PathFigure들의 합은 PathGeometry의 내부를 정의한다.

속성들	GeometryCollection에 대한 효과
FillRule	폐쇄된 영역을 설명하는 경로들을 채우기 위한 다른 알고리즘들을 특정한다.

FillRule 속성과 관련하여, 다음을 고려한다. Filled 속성이 참으로 설정되어 있는 포함된 PathFigure 모두를 취하고 FillRule을 적용하여 폐쇄된 영역을 판정하는 것에 의해, PathGeometry의 채워진 영역이 정의된다. FillRule 옵션들은, Geometry에 포함된 Figure 요소들의 교차 영역들이 Geometry의 결과 영역을 형성하기 위해 조합되는 방법을 특정한다.

설명된 실시예에 따르면, EvenOdd Fill 및 NonZero Fill 알고리즘들이 제공된다.

EvenOdd Fill 알고리즘은 캔버스상의 포인트로부터 임의 방향의 무한대로 사선을 그린 다음 형태의 세그먼트가 사선을 가로지르는 위치들을 조사하는 것에 의해 그 포인트에 대한 "내부성(insideness)"을 판정한다. 0의 카운트로 시작해, 세그먼트가 사선을 왼쪽에서 오른쪽으로 통과할 때마다 1을 더하고 경로 세그먼트가 사선을 오른쪽에서 왼쪽으로 통과할 때마다 1을 뺀다. 교차들을 카운트한 후, 결과가 0이면 포인트는 경로 외부에 있는 것이다. 그렇지 않으면, 내부에 있는 것이다.

NonZero Fill 알고리즘은 캔버스상의 포인트로부터 임의 방향의 무한대로 사선을 그리고 사선이 교차하는 소정 영역으로부터의 경로 세그먼트들의 수를 카운트하는 것에 의해 그 포인트에 대한 "내부성"을 판정한다. 이 숫자가 홀수이면, 포인트는 내부에 있는 것이고, 짝수이면, 포인트는 외부에 있는 것이다.

PathFigure

PathFigure 요소는 하나 이상의 직선 또는 곡선 세그먼트들의 세트로 구성된다. 세그먼트 요소들은 PathFigure의 형태를 정의한다. PathFigure는 항상 폐쇄된 형태를 정의해야 한다.

속성들	PathFigure에 대한 효과
FillRule	폐쇄된 영역을 설명하는 경로들을 채우기 위한 다른 알고리즘들을 특정한다.

형상은 시작점을 요하며, 그 후에는 각각의 직선 또는 곡선 세그먼트가 부가된 마지막 포인트로부터 계속된다. PathFigure 세트의 제 1 세그먼트는 StartSegment여야 하고, CloseSegment가 마지막 세그먼트여야 한다. StartSegment는 Point 속성을 가진다. CloseSegment는 속성들을 갖지 않는다.

StartSegment 속성	설명
Point	직선 세그먼트의 위치(시작점).

Path . Data 기하 구조들을 위한 고정- 페이로드 마크업

다음은 Canvas상에 Path를 그리고 채우기 위한 마크업을 제공한다. 다음의 특정 예에서는, Canvas상에 직사각형 Path가 그려지고 솔리드 그린 브러시로 채워진다.

다음 마크업은 3차원의 Bezier 곡선 그리기를 설명한다. 즉, PolyLineSegment 이외에, 고정-페이로드 마크업은 3차원의 Bezier 곡선들을 그리기 위한 PolyBezierSegment를 포함한다.

브러시들

브러시는 <Path> 요소에 의해 정의된 기하 형태들의 내부를 칠하고 <Glyphs> 요소로 렌더링된 문자 비트맵들을 채우는데 사용된다. 브러시는 또한 <Canvas.OpacityMask>, <Path.OpacityMask>, 및 <Glyphs.OpacityMask>의 알파-투명성 마스크를 정의하는데도 사용된다. FixedPage 마크업은 다음의 브러시들을 포함한다.

브러시 유형	설명
SolidColorBrush	정의된 기하 영역들을 솔리드 컬러로 채운다.
ImageBrush	영역을 이미지로 채운다.
DrawingBrush	영역을 벡터 드로잉으로 채운다.
LinearGradientBrush	영역을 선형 그라디언트로 채운다.
RadialGradientBrush	영역을 원형 그라디언트로 채운다.

모든 브러시들이 불투명 속성을 갖긴 하지만, 속성들은 브러시들에 따라 달라진다. ImageBrush와 DrawingBrush는 타일링 능력들(tiling capabilities)을 공유한다. 2개의 그라디언트-채우기 브러시들 역시 공통 속성들을 가진다.

마크업에서의 브러시 자식 요소에 대한 사용을 다음에 나타낸다.

브러시들에 대한 공통 특성들

소정 실시예에 따르면, 다음 특성들은, 더 적은 선택적 자식 요소들을 가진 간단한 브러시인 SolidColorBrush를 제외한, 모든 브러시들에 적용될 수 있다.

속성	브러시 유형	설명
Opacity	모든 브러시들
자식 요소	브러시 유형	설명
Transform	SolidColorBrush를 제외한 모든 브러시들	브러시의 좌표 공간에 적용되는 MatrixTransform을 설명한다.

DrawingBrush 및 ImageBrush 에 대한 공통 속성들

HorizontalAlignment 속성은, 브러시가 채울 영역내에서 브러시가 수평으로 정렬되는 방법을 특정한다. VerticalAlignment 속성은, 브러시가 채울 영역내에서 브러시가 수직으로 정렬되는 방법을 특정한다. ViewBox 특성은 미설정으로 해석되는 (0,0,0,0)의 디폴트 값을 가진다. 미설정일 경우, 조정은 이루어지지 않으며 Stretch 속성은 무시된다. ViewBox는, 내용들에 대해 새로운 좌표계를 특정하는데, 다시 말해, 보임창(viewport)의 범위 및 원점을 재정의한다. Stretch 속성은, 내용들을 보임창으로 매핑하는 방법을 특정하는 것을 돕는다. ViewBox 속성 값은 여백 및/또는 콤마로 구별된 4개의 "무단위" 숫자들 <min-x>, <min-y>, <width>, 및 <height>의 리스트이고, 유형은 Rect이다. ViewBox Rect는 방형 경계선으로 매핑되는 사용자 공간의 직사각형을 특정한다. scaleX 및 scaleY를 삽입하는 것과 동일하게 동작한다. (옵션이 None이 아닐 경우) Stretch 속성은 그래픽의 가로세로비(aspect ratio)를 보존하기 위한 추가적인 제어를 제공한다. 특정된 효과를 실현하기 위해 소정 요소의 모든 자손들에게 추가적인 변환이 적용된다. Brush에 대한 변환이 존재한다면, "상기" ViewBox로의 매핑에 적용된다.

Stretch 속성은 None, Fill, Uniform, UniformToFill의 모드들을 가진다.

Stretch 속성 옵션	설명
None	디폴트. 원래 크기를 보존한다.
Fill	가로세로비가 보존되지 않으며 내용은 확립된 경계들을 채우기 위해 스케일링된다.
Uniform	이미지가 확립된 경계들에 맞을 때까지 크기를 균일하게 스케일링한다.
UniformToFill	확립된 경계들을 채우기 위해 크기를 불균일하게 스케일링하며 필요하다면 클리핑한다.

간단한 브러시들과 그들의 속성들

Path.Brush 및 Canvas.Brush 자식 요소들은 SolidColorBrush, ImageBrush, 및 DrawingBrush를 포함한다.

SolidColorBrush는 정의된 기하 영역들을 솔리드 컬러로 채운다. 컬러의 알파 컴포넌트가 존재한다면, Brush의 대응되는 불투명 속성과 곱셈 방식으로 조합된다.

속성들	효과
Color	채워진 요소들에 대한 컬러를 특정한다.

다음 예는, SolidColorBrush에 대해 컬러 특성들이 표현되는 방법을 예시한다.

ImageBrush는 이미지로 공간을 채우는데 사용될 수 있다. ImageBrush에 대한 마크업으로 인해, URI가 특정될 수 있다. 모든 타 특성들이 그들의 디폴트 값들로 설정되면, 이미지는 신장되어 그 영역에 대한 방형 경계선을 채울 것이다.

속성들	효과
ImageSource	이미지 리소스의 URI를 특정한다.

ImageSource 속성은 지원되는 리치 이미지 포맷들 중 하나 또는 이러한 유형들 중 하나의 이미지로 유도하는 선택기를 참조해야 한다.

DrawingBrush는 벡터 드로잉으로 공간을 채우는데 사용될 수 있다. DrawingBrush는, 마크업에서의 그 용도가 다음에 도시되어 있는 Drawing 자식 요소를 가진다.

그라디언트 브러시들 및 그들의 속성들

그라디언트들은, 그라디언트 브러시들의 XML 자식 요소들로서 한 세트의 그라디언트 스톱들(a set of gradient stops)을 특정하는 것에 의해 그려진다. 이러한 그라디언트 스톱들은 일종의 진행을 따라 컬러들을 특정한다. 이 프레임워크에서 지원되는 2가지 유형의 그라디언트 브러시들:선형 및 원형이 존재한다.

그라디언트는. 특정 컬러 공간의 그라디언트 스톱들간에 보간들을 수행하는 것에 의해 그려진다. LinearGradientBrush 및 RadialGradientBrush는 다음의 공통 속성들을 공유한다.

속성	설명
SpreadMethod	이 특성은, 브러시가 1차의, 초기 그라디언트 영역 외부의 내용 영역을 채울 방법을 설명한다. 디폴트 값은 Pad이다.
MappingMode	이 특성은, 그라디언트를 설명하는 파라미터들이 오브젝트의 방형 경계선과 관련하여 해석되는지의 여부를 판정한다. 디폴트 값은 relative-to-bounding-box이다.
자식 요소	설명
GradientStops	GradientStop 요소들의 정렬된 시퀀스를 보유한다.

SpreadMethod 특성과 관련하여, 다음을 고려한다. SpreadMethod 옵션들은, 공간이 채워지는 방법을 특정한다. 디폴트 값은 Pad이다.

SpreadMethod 속성 옵션들	그라디언트에 대한 효과
Pad	제 1 컬러 및 마지막 컬러는 각각 시작 및 끝에서 나머지 공간을 채우는데 사용된다.
Reflect	공간을 채우기 위해, 반전된 순서로 반복하여 그라디언트 스톱들이 재생된다.
Repeat	공간이 채워질 때까지, 그라디언트 스톱들이 순서대로 반복된다.

MappingMode 속성

LinearGradientBrush와 관련하여, 다음을 고려한다. LinearGradientBrush는 벡터에 따른 선형 그라디언트 브러시를 특정한다.

속성	설명
EndPoint	선형 그라디언트의 끝점. LinearGradientBrush는, 오프셋 0을 표현하는 StartPoint로부터 오프셋 1을 표현하는 EndPoint까지의 컬러들을 보간한다. 디폴트는 1,1이다.
StartPoint	선형 그라디언트의 시작점.

다음의 마크업 예는, LinearGradientBrush의 사용을 나타낸다. 직사각형 경로를 가진 페이지가 선형 그라디언트로 채워진다.

이 예는, 선형 그라디언트로 채워진 직사각형 경로를 가진 페이지를 나타낸다. 또한, Path는 Path를 클리핑하는 팔각형 형태의 Clip 특성도 가진다.

RadialGradient는 선형 그라디언트와 프로그래밍 모델이 유사하다. 그러나, 선형 그라디언트는 그라디언트 벡터를 정의하기 위한 시작점 및 끝점을 갖는 반면, 원형 그라디언트는 그라디언트 벡터를 정의하기 위해 초점 주위의 원을 갖는다. 원은 그라디언트의 끝점을 정의하는데, 다시 말해, 1.0에서의 그라디언트 스톱이 원주에서의 컬러를 정의한다. 초점은 그라디언트의 중심을 정의한다. 0.0에서의 그라디언트 스톱은 초점에서의 컬러를 정의한다.

속성	설명
Center	이러한 원형 그라디언트의 중심점. RadialGradientBrush는 초점으로부터 타원 둘레까지의 컬러들을 보간한다. 둘레는 Center 및 반지름들에 의해 판정된다. 디폴트는 0.5,0.5이다.
Focus	원형 그라디언트의 초점
RadiusX	원형 그라디언트를 정의하는 타원에 대한 X 차원의 반지름들. 디폴트는 0.5이다.
RadiusY	원형 그라디언트를 정의하는 타원에 대한 Y 차원의 반지름들. 디폴트는 0.5이다.
FillGradient	Pad, Reflect, Repeat

알파 및 투명성

도시되고 설명된 실시예에 따르면, 각 요소의 픽셀 각각은 (완전 투명의) 0.0으로부터 (완전 불투명의) 1.0에 이르는 알파 값을 전달한다. 알파 값은, 투명한 시각적 효과를 실현하기 위해 요소들을 블렌딩할 때 사용된다.

각각의 요소는, 요소의 픽셀 각각에 대한 알파 값과 균일하게 배율될 불투명 속성을 가질 수 있다.

또한, OpacityMask는, 렌더링된 내용이 그것의 목적지로 불렌딩되는 방법을 제어할 픽셀당 불투명도의 세목(specification)을 허용한다. OpacityMask에 의해 특정된 불투명도는, 내용들의 알파 채널에 이미 존재할 수 있는 임의의 불투명도와 곱셈 방식으로 조합된다. OpacityMask에 의해 특정된 픽셀당 불투명도는, 컬러 데이터가 무시되는, 마스크의 픽셀 각각에 대한 알파 채널을 살펴보는 것에 의해 판정된다.

OpacityMask의 유형은 Brush이다. 이것은 브러시의 내용이 다양하고 상이한 방식으로 내용 범위로 매핑되는 방법에 대한 세목을 허용한다. Fill 기하 구조에 사용될 때와 마찬가지로, Brush들의 디폴트는 전체 내용 공간을 채우고, 그 내용을 적절히 신장하거나 반복하는 것이다. 이것은, 내용들을 완전히 커버하기 위해 ImageBrush는 ImageSource를 신장할 것이고, GradientBrush는 가장자리에서 가장자리로 연장할 것이라는 것을 의미한다.

알파 블렌딩을 위해 필요한 계산들은 이전 섹션 "불투명 속성"에 설명되어 있다.

다음 예는, OpacityMask가 Glyphs 요소에 대해 "페이드 효과(fade effect)"를 형성하는데 사용되는 방법을 예시한다. 본 예의 OpacityMask는 불투명한 블랙에서 투명한 블랙으로 페이드하는 선형 그라디언트이다.

리치 문서들의 이미지들

FixedPage들의 경우, 이미지들이 폐쇄된 영역들을 채운다. FixedPage상에 이미지를 배치하기 위해, 페이지에 대한 영역이 먼저 특정되어야 한다. Path 요소의 기하 구조에 의해 영역이 정의된다.

Path 요소의 Fill 특성은 설명된 영역에 대한 채우기 내용들을 특정한다. 이미지들은 ImageBrush에 의해 영역에 그려지는, 채우기의 일 유형이다. 모든 브러시들은, 적절한 브러시 내용을 신장하거나 반복(타일링)하는 것에 의해 전체 영역을 채우는 디폴트 동작을 가진다. ImageBrush의 경우, ImageSource 특성에 의해 특정된 내용이 신장되어 영역을 완전히 커버할 것이다.

다음의 마크업은, 이미지를 Canvas상에 배치하는 방법을 예시한다.

많은 이미지들이 직사각형이므로, 리소스 사전에 직사각형 Path 요소를 포함하는 것이 마크업을 단순화하는데 유용할 것이다. 그 다음, Path는 RenderTransform 속성(상기 참고)을 사용해 배치될 수 있다.

컬러

컬러들은, 도시되고 설명된 마크업에서, scRGB 또는 sRGB 표기법을 사용해 특정될 수 있다. sRGB 세목은 "IEC 61966-2-2 scRGB"로 공지되어 있으며 www.iec.ch로부터 얻을 수 있다.

ARGB 파라미터들이 다음 도표에 설명되어 있다.

이름	설명
R	현재 컬러의 레드 scRGB 컴포넌트
G	현재 컬러의 그린 scRGB 컴포넌트
B	현재 컬러의 블루 scRGB 컴포넌트
A	현재 컬러의 알파 scRGB 컴포넌트

컬러 매핑

이제는, 컬러 문맥을 특정하는 메타데이터로 채색된 요소들에 대한 태깅(tagging)을 고려한다. 이러한 메타데이터는 ICC 컬러 프로파일 또는 다른 컬러 정의 데이터를 포함할 수 있다.

< Glyphs > 요소

텍스트는 Glyphs 요소를 사용해 고정 페이로드들로 표현된다. 요소는 리치 문서들을 인쇄하기 위한 요구 사항들을 충족시키도록 설계된다.

Glyphs 요소들은 다음 특성들의 조합들을 가질 수 있다.

특성	목적	마크업 표현(Glyphs 요소)
Origin	실행 중인 제 1 글리프의 원점. 글리프는, 선행 벡터의 앞쪽 끝과 기준선이 이 점에서 교차하도록 배치된다.	OriginX 및 OriginY 특성들에 의해 특정됨
FontRenderingEmSize	화면 단위들의 폰트 크기(디폴트는 1/96 인치)	Length 단위로 측정됨
FontHintingEmSize	힌트가 되는 점들의 크기. 폰트들은 단순한 스케일링이 할 수 있는 것보다 좀더 동일해 보이는 양식의 결과들을 생성하기 위해, 작은 크기들의 좀더 두꺼운 대들 및 좀더 벌어진 주발들과 같이, 상이한 크기들에서의 미묘한 차이들을 생성하기 위한 힌트를 포함할 수 있다. 이것과, 자동적으로 핸들링되는 장치의 픽셀 해상도에 대한 힌트와는 상이하다. 지금(2003년 3월)까지의 주지 폰트들은 크기 힌트를 포함하지 않는다. 디폴트 값은 -12pts이다.	폰트의 점들의 크기를 표현하는 더블들로 측정됨
GlyphIndices	이러한 실행을 표현하는 16 비트 글리프 숫자들의 어레이	Part of Indices 특성. 표현을 위해 다음 참고.
AdvanceWidths	GlyphIndices의 글리프 각각에 대한 진행 폭들의 어레이. 실행 중인 n번째(n>0) 글리프의 명목 원점은 n-1번째 글리프의 명목 원점+선행 벡터 실행들을 따라 부가된 n-1번째 진행 폭이다. 기본 글리프들은 일반적으로 0이 아닌 진행 폭을 갖고, 구성 글리프들은 일반적으로 0의 진행 폭을 갖는다.	Part of Indices 특성. 표현을 위해 다음 참고.
GlyphOffsets	글리프 오프셋들의 어레이. 위에서 계산된 명목 글리프 원점에 부가되어 글리프에 대한 최종 원점을 생성한다. 기본 글리프들은 일반적으로 (0,0)의 글리프 오프셋을 갖고, 구성 글리프들은 일반적으로, 구성 글리프들을 가장 근접한 선행 기본 글리프위에 정확하게 배치하는 오프셋을 갖는다.	Part of Indices 특성. 표현을 위해 다음 참고.
GlyphTypeface	이러한 실행의 모든 글리프들이 그려지는 물리적 폰트.	FontUri, FontFaceIndex, 및 StyleSimulations 특성들
UnicodeString	선택적* 이러한 글리프 실행에 의해 표현되는 문자들의 어레이. *Win32 프린터 드라이버들로부터 생성된 GlyphRun의 경우, Win32 ExtTextOut(ETO_GLYPHINDEX) 호들에 의해 원래 인쇄되었던 텍스트가 글리프 인덱스들을 가지며 Unicode 코드포인트들이 없는 드라이버로 전달된다. 이 경우, 생성된 Glyphs 마크업 및 이와 같이 구성된 GlyphRun 오브젝트는 코드포인트들을 누락할 것이다. 코드포인트들이 없으면, 고정 포맷 뷰어에서의 잘라내기와 붙여넣기 또는 검색과 같은 기능은 이용될 수 없겠지만, 여전히 텍스트 디스플레이는 가능하다.	예
ClusterMap	UnicodeString의 문자당 하나의 엔트리. 각각의 값은 UnicodeString의 대응 문자를 표현하는 GlyphIndices의 제 1 글리프에 대한 오브셋을 제공한다. 다수 문자들이 하나의 글리프로 매핑되는 경우, 하나의 문자가 다수 글리프들로 매핑될 경우, 또는 다수 문자들이 다수 글리프들로 분할할 수 없이 매핑될 경우, 문자 또는 문자(들) 및 글리프 또는 글리프(들)을 클러스터라고 한다. 다수-문자 클러스터에 대한 ClusterMap의 모든 엔트리들은 클러스터의 제 1 글리프에 대한 GlyphIndices 어레이의 오프셋으로 매핑된다.	Part of Indices 특성. 표현을 위해 다음 참고.
Sideways	글리프들은 그들의 측면상에 레이아웃된다. 디폴트로, 글리프들은 서구의 기준 원점에 대응되는 원점을 가진 수평 텍스트가 되도록 렌더링된다. Sideways 플래그가 설정되면, 글리프는 자신의 측면으로 회전되고, 원점은, 회전되지 않은 글리프의 상부 중앙이 된다.	예
BidiLevel	양방향 중첩 레벨의 Unicode 알고리즘. 수치적으로 짝수의 값들은 왼쪽-대-오른쪽 레이아웃을 의미하고, 수치적으로 홀수 값들은 오른쪽-대-왼쪽 레이아웃을 의미한다. 오른쪽-대-왼쪽 레이아웃은 실행 원점을 제 1 글리프의 오른쪽에 배치하므로, 선행 벡터의 양의 값들은 후속 글리프들을 이전 글리프의 왼쪽에 배치한다.	예
Brush	글리프들을 그리는데 사용되는 최우선 브러시	Shape Fill 특성으로부터 선택됨
Language	실행 언어는 일반적으로 마크업의 xml:lang 특성에 기인한다.	xml:lang 특성에 의해 특정됨

텍스트 마크업의 개요

Glyph 메트릭들

각각의 글리프는, 그것이 다른 글리프들과 정렬되는 방법을 특정하는 메트릭들을 정의한다. 일 실시예에 따른 예시적 메트릭들을 도 12에 나타낸다.

진행 폭들 및 조합 마크들

일반적으로, 폰트내의 글리프들은 기본 글리프들 또는 기본 글리프들에 부착될 수 있는 조합 마크들이다. 기본 글리프들은 일반적으로 0이 아닌 진행 폭 및 0,0의 오프셋 벡터를 갖는다. 조합 마크들은 일반적으로 0의 진행 폭을 갖는다. 오프셋 벡터는 조합 마크의 위치를 조정하는데 사용될 수 있으므로 조합 마크들에 대해 0,0이 아닌 값을 가질 수도 있다.

글리프 실행의 글리프 각각은 그 위치를 제어하는 3개의 값들을 가진다. 값들은 각각 후술되는 원점, 진행 폭, 및 글리프 오프셋을 지시한다.

ㆍ 원점: 각각의 글리프에 명목 원점이 부여되는 것으로 가정할 때, 실행의 제 1 글리프에 대한 것이 실행 원점이다.

ㆍ 진행 폭: 각각의 글리프에 대한 진행 폭은 이러한 글리프들의 원점과 관련되어 있는 후속 글리프의 원점을 제공한다. 선행 벡터는 항상 실행의 진행 방향으로 그려진다.

ㆍ 글리프 오프셋(기본 또는 마크): 글리프 오프셋 벡터는 명목 원점과 관련되어 있는 이러한 글리프들의 위치를 조정한다.

문자들, 글리프들 , 및 클러스터 맵

클러스터 맵들은 Unicode 코드포인트당 하나의 엔트리를 포함한다. 엔트리의 값은, 이러한 코드포인트를 표현하는 GlyphIndices 어레이의 제 1 글리프에 대한 오프셋이다. 다른 방법으로, 코드포인트가 분할될 수 없는 문자 클러스터를 표현하는 코드포인트들의 그룹의 일부일 경우, GlyphIndices 어레이의 제 1 글리프는 클러스터를 표현하는 제 1 글리프의 오프셋을 표현한다.

클러스터 매핑들

클러스터 맵은, 일-대-일, 다-대-일, 일-대-다, 또는 다-대-다인 코드포인트-대-글리프 매핑들을 표현할 수 있다. 각각의 코드포인트가 정확하게 하나의 글리프로 표현될 경우가 일-대-일 매핑들인데, 도 13의 클러스터 맵 엔트리들은 0, 1, 2, ...이다.

다-대-일 매핑들은 2 이상의 코드포인트들이 하나의 글리프에 매핑될 경우이다. 이러한 코드포인트들에 대한 엔트리들은 글리프 인덱스 버퍼에 그 글리프에 대한 오프셋을 특정한다. 도 14의 예에서, "f" 및 "i" 문자들은, 많은 세리프 폰트들의 공통적인 조판 관행에서처럼, 모은자(ligature)로 대체되었다.

일-대-다 매핑들과 관련하여, 도 15에 관한 다음을 고려한다. 'Sara Am'은, 이전의 기본 문자 위에 놓이는 부분(링) 및 기본 문자의 오른쪽에 놓이는 부분(후크)을 포함한다. 타이 텍스트가 마이크로-정렬(micro-justification)될 때, 후크는 기본 문자로부터 간격이 벌어지는 한편, 링은 기본 문자 위에 남게 되므로, 많은 폰트들은 링 및 후크를 별개의 글리프들로 인코딩한다. 하나의 코드포인트가 2 이상의 글리프들로 매핑될 경우, 그 코드포인트에 대한 ClusterMap의 값은, 코드포인트를 표현하는 GlyphIndices의 제 1 글리프를 참조한다.

다-대-다 매핑들과 관련하여서는, 도 16에 관한 다음을 고려한다. 문자 클러스터에 대한 코드포인트들의 분할될 수 없는 그룹의 일부 폰트들은 하나 이상의 글리프로 매핑된다. 예를 들어, 인도의 필기체 활자를 지원하는 폰트들에서 이것을 흔히 볼 수 있다. 코드포인트들의 분할될 수 없는 그룹이 하나 이상의 글리프들로 매핑될 경우, 코드포인트들 각각에 대한 ClusterMap의 값은, 그 코드포인트를 표현하는 GlyphIndices의 제 1 글리프를 참조한다.

다음 예는 타밀어 단어 □□□□의 Unicode 및 글리프 표현들을 나타낸다. 처음 2개의 코드포인트들은 구성되어 3개의 글리프들을 생성한다.

클러스터들 특정하기

클러스터 세목들은 (매핑들이 하나의 문자-대-하나의 글리프보다 복잡한) 비 1:1 클러스터의 제 1 글리프에 대한 글리프 세목을 선행한다.

각각의 클러스터 세목은 다음의 형태를 갖는다.

(ClusterCodepointCount[:ClusterGlyphCount])

클러스터 세목 부분	유형	목적	디폴트 값
ClusterCodepointCount	양의 정수	이 클러스터를 형성하기 위해 구성하는 16비트 Unicode 코드포인트들의 수	1
ClusterGlyphCount	양의 정수	이 클러스터를 형성하기 위해 구성하는 16비트 글리프 인덱스들의 수	1

< Glyphs > 마크업

Glyphs 요소는 폰트를 URI, 정면 인덱스, 및 상술한 한 세트의 다른 특성들로서 특정한다. 예를 들면,

각각의 글리프 세목은 다음의 형태:

[GlyphIndex][,[Advance][,[uOffset][,[vOffset][,[Flags]]]]]를 가진다.

글리프 세목의 각 부분은 선택적이다.

글리프 세목 부분	목적	디폴트 값
GlyphIndex	물리적 폰트를 렌더링할 때의 글리프 인덱스	내부 텍스트의 대응되는 Unicode 코드포인트들에 대한 폰트들의 문자 맵 도표에 의해 정의된 바와 같음.
Advance	이 글리프의 원점과 관련되어 있는 후속 글리프의 배치. Sideways 및 BidiLevel 특성들에 의해 정의된 바와 같은 선행 방향에서 측정됨. FontEmSize의 100번째에서 측정됨. 선행은, 라운딩 오류들이 누적되지 않도록 계산되어야 한다. 이러한 요구 사항을 실현하는 방법에 관해서는 다음을 참고한다.	폰트들의 HMTX 또는 VMTX 폰트 메트릭 도표들에 의해 정의된 바와 같음.
uOffset, vOffset	이 글리프를 이동시키기 위한 글리프 원점과 관련되어 있는 오프셋. 일반적으로 마크들을 기본 문자들에 부착시키는데 사용됨. FontEmSize의 100번째에서 측정됨.	0,0
Flags	기본 글리프들과 조합 마크들을 구별한다	0(기본 글리프)

라운딩 오류를 누적하지 않으면서 선행을 계산하는 것과 관련하여, 다음을 고려한다. 각각의 선행 값은 (후속 글리프의 라운딩되지 않은 정확한 원점 - 선행 글리프들에 대해 계산된(즉, 라운딩된) 진행 폭들의 합)으로서 계산되어야 한다. 이런 방식으로, 각각의 글리프는 그것의 정확한 위치에 대한 엠(em)의 0.5% 이내에 배치된다.

Glyphs 마크업 예들

Glyphs 마크업 크기의 최적화

글리프 인덱스들 및 진행 폭들과 같은, 마크업 세부 사항들은, 목표 클라이언트가 그것들을 확실하게 재생할 수 있다면, 마크업으로부터 생략될 수 있다. 다음 옵션들은 흔히 사용되는 간단한 필기체 활자들의 극적인 최적화를 허용한다.

글리프 인덱스들의 마크업 최적화

Unicode 스트링의 문자들에 대한 위치들과 글리프 스트링의 글리프들에 대한 위치들간에 일-대-일 매핑이 존재하면, 마크업으로부터 글리프 인덱스들은 생략될 수 있고, 글리프 인덱스는 폰트의 CMAP(character mapping) 도표의 값이며, Unicode 문자는 명료한 의미들을 가진다.

글리프 인덱스들은, 문자들의 글리프들로의 매핑이,

ㆍ 2 이상의 코드포인트들이 하나의 글리프(모은자)를 형성하는 경우와 같이, 일-대-일이 아니거나,

ㆍ 하나의 코드포인트가 다수 글리프들을 생성하거나,

ㆍ OpenType 사양의 애플리케이션에 의한 것과 같이, 어떠한 다른 형태의 글리 프 대체가 발생하는 경우인 마크업에 제공되어야 한다.

글리프 인덱스들은, 렌더링 엔진이 폰트의 CMAP(charater mapping) 도표가 아닌 상이한 글리프를 대체할 수 있는 경우의 마크업에 제공되어야 한다. 글리프 인덱스들은, 소정 글리프 표현이 폰트의 CMAP 도표에서의 표현이 아닌 경우에 제공되어야 한다.

글리프 위치들의 마크업 최적화

필요한 진행 폭이 정확하게 폰트의 HMTX(horizontal metrics) 또는 VMTX(vertical metrics) 도표들에서의 글리프에 대한 것이라면, 마크업으로부터 글리프 진행 폭은 생략될 수 있다.

글리프 수직 오프셋은, 그것이 0인 경우, 마크업으로부터 생략될 수 있다. 이것이, 기본 문자들에 대해서는 거의 항상 참이고, 좀더 단순한 필기체 활자들의 조합 마크들에 대해서도 흔히 참이다. 그러나, 아라비아어 및 인도어와 같은, 좀더 복잡한 필기체 활자들의 조합 마크들에 대해서는 이것이 종종 거짓이다.

글리프 플래그들의 마크업 최적화

보통의 자리 맞춤 우선 순위(normal justification priority)를 가진 기본 글리프들에 대해서는 글리프 플래그들이 생략될 수 있다.

결론

상술한 모듈식 내용 프레임워크 및 문서 포맷 방법들 및 시스템들은 문서-중심 내용을 구성, 패키지화, 분산, 및 렌더링하기 위한 구성 블록들의 세트를 제공한다. 이들 구성 블록들은, 소프트웨어 및 하드웨어 시스템들이 확실하게 일관적으로 문서들을 생성, 교환, 및 디스플레이하는 것을 가능하게 하는 문서 포맷들을 위한 플랫폼-독립형 프레임워크를 정의한다. 도시되고 설명된 리치 패키지 포맷은, 페이지화된 또는 사전-페이지화된 문서들을, 광범위한 환경들 및 광범위한 상황들의 장치들 및 애플리케이션들 사이에서 패키지의 내용들이 완전한 충실도로 디스플레이되거나 인쇄될 수 있는 방식으로 저장하기 위한 포맷을 제공한다. 본 발명을 구성적 사양들 및/또는 방법적 단계들에 특징적인 언어로 설명하긴 했지만, 첨부된 청구항들에 정의된 본 발명이 반드시 설명된 특정 사양들 또는 단계들로 한정될 필요는 없다는 것을 알 수 있을 것이다. 오히려, 특정 사양들 및 단계들은 청구된 발명을 구현하는 바람직한 형태들로서 개시되어 있다.

Claims (10)

1. 방법으로서,
   문서를 정의하는 패키지를 구성하는 단계, 및
   상기 패키지에 다수의 페이로드를 포함시키는 단계
   를 포함하고,
   상기 다수의 페이로드 중 적어도 일부는 상기 문서의 서로 다른 발견 가능한(discoverable) 버전들을 집합적으로(collectively) 나타내고,
   적어도 하나의 페이로드는 고정 페이로드를 포함하여, 상기 패키지를 구성하는데 사용되는 애플리캐이션 없이도 상기 문서가 처리될 수 있도록 하고,
   상기 고정 페이로드는 고정된 페이지 수를 갖는 문서를 포함하고, 각 페이지는 고정된 크기 및 방향(orientation)을 갖고,
   소비 측면에서는 상기 고정 페이로드의 문서를 렌더링하기 위해 레이아웃 연산(layout calculation)이 실행될 필요가 없는, 방법.
2. 방법으로서,
   문서를 정의하는 패키지를 수신하는 단계 - 상기 패키지는 하나 이상의 페이로드를 포함하고, 상기 하나 이상의 페이로드의 적어도 일부는 상기 문서의 서로 다른 발견 가능한 버전들을 집합적으로 나타내고, 적어도 하나의 페이로드는 고정 페이로드를 포함하여, 상기 패키지를 구성하는데 사용되는 애플리캐이션 없이도 상기 문서가 처리될 수 있도록 하고, 상기 고정 페이로드는 고정된 페이지 수를 갖는 문서를 포함하고, 각 페이지는 고정된 크기 및 방향을 갖고, 소비 측면에서는 상기 고정 페이로드 문서를 렌더링하기 위해 레이아웃 연산이 실행될 필요가 없음 -; 및
   적어도 상기 문서의 일부 부분을 발견하기 위해 상기 패키지를 처리하는 단계
   를 포함하는, 방법.
3. 제1항 또는 제2항에 있어서,
   상기 고정 페이로드는 상기 고정 페이로드에 대응하는 문서의 버전을 직접적으로 렌더링하기에 충분한 미리 정해진 레이아웃 연산들을 포함하는, 방법.
4. 제1항 또는 제2항에 있어서,
   상기 고정 페이로드는 관련 문서의 다른 부분들을 식별하는 검색가능한 마크업 설명(markup description)을 포함하는, 방법.
5. 제1항 또는 제2항에 있어서,
   상기 패키지는 하나 이상의 구성 부분을 포함하고,
   각각의 상기 구성 부분은, 상기 패키지 내에서 선택을 행하기 위한 적어도 하나의 선택기 부분 및/또는 패키지 컨텐츠로부터 시퀀스를 만들기 위한 하나 이상의 시퀀스 부분을 포함할 수 있는, 방법.
6. 컴퓨터-판독 가능 명령어들을 기록한 하나 이상의 컴퓨터 판독가능 기록매체로서, 상기 컴퓨터-판독 가능 명령어들은 실행될 경우, 제1항 또는 제2항의 방법을 실행시키는, 하나 이상의 컴퓨터 판독가능 기록매체.
7. 시스템으로서,
   프로세서;
   상기 프로세서에 의해 실행가능하며, 문서를 정의하는 패키지를 구성하기 위한 수단; 및
   상기 프로세서에 의해 실행가능하며, 상기 패키지에, 다수의 페이로드를 포함시키기 위한 수단
   을 포함하고,
   상기 다수의 페이로드 중 적어도 일부는 상기 문서의 서로 다른 발견 가능한 버전들을 집합적으로 나타내고,
   적어도 하나의 페이로드는 고정 페이로드를 포함하고, 상기 고정 페이로드는, 상기 고정 페이로드에 대응하는 문서의 버전을 직접적으로 렌더링할 수 있는 미리 정해진 레이아웃 연산들 및 하나 이상의 고정된 페이지 부분을 개별적으로 참조하는 루트 부분을 포함하고,
   상기 문서의 상기 서로 다른 발견 가능한 버전들 중 적어도 하나는 선택 가능하고 상기 패키지의 수신기에 의해 렌더링 가능한, 시스템.
8. 시스템으로서,
   프로세서;
   상기 프로세서에 의해 실행 가능하고, 문서를 정의하는 패키지를 수신하기 위한 수단 - 상기 패키지는 하나 이상의 페이로드를 포함하고, 상기 하나 이상의 페이로드 중 적어도 일부는 상기 문서의 서로 다른 발견 가능한 버전들을 집합적으로 나타내고, 상기 페이로드 중 적어도 하나는 고정 페이로드를 포함하고, 상기 고정 페이로드는, 상기 고정 페이로드에 대응하는 문서의 버전을 직접적으로 렌더링할 수 있는 미리 정해진 레이아웃 연산들 및 하나 이상의 고정된 페이지 부분을 개별적으로 참조하는 루트 부분을 포함함 -;
   상기 프로세서에 의해 실행 가능하고, 적어도 상기 문서의 일부 부분들을 발견하기 위해 상기 패키지를 프로세싱하기 위한 수단; 및
   상기 문서의 상기 서로 다른 발견 가능한 버전들 중 적어도 하나를 선택하고 상기 선택된 버전을 렌더링하기 위한 수단
   을 포함하는, 시스템.
9. 제7항 또는 제8항에 있어서,
   상기 고정 페이로드의 부분들의 집합은,
   관련 문서의 개별적인 페이지들을 각각 참조하는 루트 부분;
   하나 이상의 고정된 페이지 파트; 및
   적어도, 하나 이상의 폰트 파트, 하나 이상의 이미지 파트, 하나 이상의 구성 파트(composition part), 하나 이상의 기술적 메타 데이터 파트, 또는 하나 이상의 프린트 티켓 파트 중 하나 이상의 파트를 포함하는, 시스템.
10. 제7항 또는 제8항에 있어서,
    상기 고정 페이로드는 상기 문서의 다른 부분들을 식별하는 검색가능한 마크업 설명을 포함하는, 시스템.

Images