A package file opf

Windows often associates a default program to each file extension, so that when you double-click the file, the program launches automatically. When that program is no longer on your PC, you can sometimes get an error when you try to open the associated file.

Are You Sure? Repair file extension issues on your PC. Start Download. All rights reserved. Terms Of Use Privacy Cookies. Summer Sale! Get My Deal Now. Driver Reviver Windows Driver Updater. InstallSafe Protect your browser and PC. Privacy Reviver Complete Privacy Protection. MacReviver Complete Mac Optimization. Registry Reviver Windows Registry Optimizer. Battery Optimizer Laptop Battery Optimization. Visit our Store. Blog Latest tips, tricks and news. Video Blogs Protect your browser and PC.

File Extensions Library of file extensions. Newsletter News from ReviverSoft. Answers Your questions answered. Driver Reviver Driver Reviver support. InstallSafe InstallSafe support. Disk Reviver Disk Reviver support. Security Reviver Security Reviver support. There are two things to notice with this part. The enumeration builds the dynamic section of the file. We first create two variables to hold the content and spine of the manifest.

When we complete this section, we have a list of all the files under OEBPS and are now ready to, finally, build the package file. After all the work, actually creating the file is almost anti climatic. We print each section in the following order:. This is not a complete solution. It is a starting point and it will require manual edits before it passes validation.

After processing , this property would expand to the following IRI:. When a prefix is omitted from a property value, the expressed reference represents a term from the default vocabulary for that attribute.

An empty string does not represent a valid property value, even though it is valid to the definition above. If the property consists only of a reference, the IRI is obtained by concatenating the IRI stem associated with the default vocabulary to the reference.

If the property consists of a prefix and reference, the IRI is obtained by concatenating the IRI stem associated with the prefix to the reference. If no matching prefix has been defined, the property is invalid and MUST be ignored. Reading Systems do not have to resolve this IRI, however. Not all rendering information can be expressed through the underlying technologies that EPUB is built upon.

For example, although HTML with CSS provides powerful layout capabilities, those capabilities are limited to the scope of the document being rendered. This section defines general-purpose properties that allow Authors to express package-level rendering intentions i. If a Reading System supports the desired rendering, these properties enable the user to be presented the content as the Author optimally designed it.

The " rendition: " prefix is reserved for use with the package rendering properties and does not have to be declared in the Package Document. The rendition:flow property specifies the Author preference for how Reading Systems should handle content overflow. When the rendition:flow property is specified on a meta element, it indicates the Author's global preference for overflow content handling i.

Authors MAY indicate a preference for dynamic pagination or scrolling. For scrolled content, it is also possible to specify whether consecutive EPUB Content Documents are to be rendered as a continuous scrolling view or whether each is to be rendered separately i. The default value auto MUST be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the metadata section.

Reading Systems MAY support only this default value. If a Reading Systems supports the rendition:layout property, it MUST ignore the rendition:flow property when it has been set on a spine item that also specifies the rendition:layout value pre-paginated.

In addition to using the rendition:flow property, Authors MAY override this behavior through an appropriate style sheet declaration, if the Reading System supports such overrides. The Author does not have a preference for overflow handling. The Reading System MAY render overflow content using its default method or a user preference, whichever is applicable.

Authors MAY specify the following properties locally on spine itemref elements to override the global value for the given spine item:. For the rendition:flow-scrolled-continuous property, the scroll direction is defined relative to the block flow direction of the root element of the XHTML Content Document referenced by the itemref element.

The scroll direction is vertical if the block flow direction is downward top-to-bottom. It is horizontal if the block flow direction of the root element is rightward left-to-right or leftward right-to-left.

The rendition:align-x-center property specifies that the given spine item should be centered horizontally in the viewport or spread. When the rendition:align-x-center property is set on a spine item, it indicates that the rendered content SHOULD be centered horizontally within the Viewport or spread, as applicable. This property does not affect the rendering of the spine item, only the placement of the resulting content box.

This version of this specification does not define a default rendering behavior when this property is not supported or specified. Reading Systems MAY render spine items by their own design. As support for paged media evolves in CSS, however, this property is expected to be deprecated. Authors are encouraged to use CSS solutions when effective. The content flows, or reflows, to fit the screen and to fit the needs of the user.

As noted in Rendering and CSS "content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content. Sometimes content and design are so intertwined they cannot be separated. Any change in appearance risks changing the meaning, or losing all meaning.

This section defines a set of metadata properties to allow declarative expression of intended rendering behaviors of Fixed-Layout Documents in the context of EPUB 3. EPUB 3 affords multiple mechanisms for representing fixed-layout content. When fixed-layout content is necessary, the Author's choice of mechanism will depend on many factors including desired degree of precision, file size, accessibility, etc. This section does not attempt to dictate the Author's choice of mechanism.

The rendition:layout property specifies whether the given Rendition is reflowable or pre-paginated. When the rendition:layout property is specified on a meta element, it indicates that the paginated or reflowable layout style applies globally for the Rendition i. The following values are defined for use with the rendition:layout property:.

The given Rendition is not pre-paginated. Reading Systems MAY apply dynamic pagination when rendering. The given Rendition is pre-paginated. Reading Systems typically restrict or deny the application of user or user agent style sheets to pre-paginated documents, since, as a result of intrinsic properties of such documents, dynamic style changes are highly likely to have unintended consequences.

Authors need to take into account the negative impact on usability and accessibility that these restrictions have when choosing to use pre-paginated instead of reflowable content.

Refer to Guideline 1. The rendition:orientation property specifies which orientation the Author intends the given Rendition to be rendered in. When the rendition:orientation property is specified on a meta element, it indicates that the intended orientation applies globally for the given Rendition i.

The following values are defined for use with the rendition:orientation property:. The means by which the intent is conveyed is implementation-specific. The rendition:spread property specifies the intended Reading System synthetic spread behavior for the given Rendition. When the rendition:spread property is specified on a meta element, it indicates that the intended Synthetic Spread behavior applies globally for the given Rendition i.

The following values are defined for use with the rendition:spread property:. The use of spreads only in portrait orientation is deprecated. Authors are advised to use the value " both " instead, as spreads that are readable in portrait orientation are also readable in landscape.

No explicit Synthetic Spread behavior is defined. Refer to spine for information about declaration of global flow directionality using the page-progression-direction attribute and that of local page-progression-direction within content documents.

When a Reading System renders a Synthetic Spread , the default behavior is to populate the spread by rendering the next EPUB Content Document in the next available unpopulated viewport, where the next available viewport is determined by the given page progression direction or by local declarations within Content Documents.

An Author MAY override this automatic population behavior and forcing a document to be placed in a particular viewport by specifying one of the following properties on its spine itemref element:.

The rendition:page-spread-center property indicates that the synthetic spread mode SHOULD be overridden and a single viewport rendered and positioned at the center of the screen. The rendition:page-spread-left , rendition:page-spread-right and rendition:page-spread-center properties apply to both pre-paginated and reflowable content, and they only apply when the Reading System is creating Synthetic Spreads.

The presence of rendition:page-spread-center does not change the viewport dimensions. In particular, it does not indicate that a viewport with the size of the whole spread has to be created. This is important so that the scale factor stays consistent between regular and center-spread pages. Although Authors often indicate to use a spread in certain device orientations, the content itself does not represent true spreads i.

To indicate that two consecutive pages represent a true spread, Authors SHOULD use the rendition:page-spread-left and rendition:page-spread-right properties on the spine items for the two adjacent EPUB Content Documents, and omit the properties on spine items where one-up or two-up presentation is equally acceptable.

The rendition:page-spread-left and rendition:page-spread-right properties are aliases for the page-spread-left and spread-right properties. They allow the use of a single vocabulary for all fixed-layout properties.

Authors can use either property set, but older Reading Systems might only recognize the unprefixed versions. The EPUB Spine Properties Vocabulary is no longer being extended for package rendering metadata, so an unprefixed page-spread-center is not available.

Use of the property is deprecated. Refer to its definition in [ Publications ] for more information. It allows Authors to include a human- and machine-readable global navigation layer, thereby ensuring increased usability and accessibility for the user. Because it is an XHTML Content Document, it can be part of the linear reading order, avoiding the need for duplicate tables of contents. Content which is only destined for machine processing, such as page lists , can be hidden from visual rendering with the hidden attribute.

If such formatting and functionality is needed, then the EPUB Navigation Document also needs to be included in the spine. The use of progressive enhancement [ ContentDocs32 ] techniques for scripting and styling of the navigation document will help ensure the content will retain its integrity when rendered in a non-browser context.

When requested by a user, it MUST provide access to the links and link labels in the nav elements of the EPUB Navigation Document in a fashion that allows the user to activate the links. When a link is activated, it MUST relocate the application's current reading position to the destination identified by that link.

When a nav element carries the epub:type attribute [ ContentDocs32 ] in an EPUB Navigation Document , this specification restricts the content model of the element and its descendants as follows:. HTML Heading content [0 or 1].

HTML Phrasing content [1 or more]. The ol child of the nav element represents the primary level of content navigation. Each list item of the ordered list represents a heading, structure or other item of interest. A child a element describes the target that the link points to, while a span element serves as a heading for breaking down lists into distinct groups for example, a large list of illustrations can be segmented into several lists, one for each chapter.

The child a or span element MUST provide a non zero-length text label after concatenation of all child content and application of white space normalization rules.

Although non-textual descendant elements MAY be rendered directly to users, text content included in title or alt attributes MUST be used when determining compliance with this requirement. If an a or span element contains instances of HTML embedded content that do not provide intrinsic text alternatives, the element MUST also include a title attribute with an alternate text rendering of the link label.

An a element MAY be followed by an ol ordered list representing a subsidiary content level below that heading e.

A span element MUST be followed by an ol ordered list; it cannot be used in "leaf" li elements. Regardless of whether an a or span element precedes it, every sublist MUST adhere to the content requirements defined in this section for constructing the primary navigation list. In the context of this specification, the default display style of list items within nav elements MUST be equivalent to the list-style: none property [ CSSSnapshot ]. Identifies the nav element that contains the table of contents.

For an example of the types of content that may be considered auxiliary, refer to the example below and the subsequent discussion. Reading Systems are not required to differentiate between primary and auxiliary content, and for the requirements and recommendations given in this section may consider all OPS Content Documents in spine to be primary, regardless of the value of the linear attribute. Reading Systems are to use the ordered itemref information in spine to present the publication during reading.

Reading Systems must recognize the first primary OPS Content Document in spine to be the beginning of the main reading order of the publication. Successive primary OPS Content Documents form the remainder of the main reading order in the same order given in spine.

Reading Systems may use "next-page" style functionality when moving from one primary OPS Content Document to the next primary one in spine.

The spine element must include the toc attribute, whose value is the the id attribute value of the required NCX document declared in manifest see Section 2. Example illustrating spine and the optional linear attribute:. Three of the four are "answer keys," and the fourth is a note of some sort; all four are auxiliary to the main flow of the book and may be viewed separately from the main flow.

Reading Systems which recognize and render auxiliary content separate from primary content will set the main reading order to be the four primary OPS Content Documents: intro , c1 , c2 and c3. The auxiliary content documents will be rendered by such Reading Systems, upon activation such as through a hypertext link or entry in NCX , in some manner distinct from the main reading order.

It is important that the publication author provide the necessary references to the auxiliary content documents, otherwise this content might not be reachable in some auxiliary-aware Reading Systems. This is especially useful for Reading Systems which provide print output, where it is important that all the information in the OPS Content Documents be printed in an author-determined linear order.

A Reading System may , at its discretion, provide both rendering options to the user. The NCX is a portion Section 8 of this comprehensive multimedia standard. Some optional elements and metadata items are not needed to implement the NCX for this specification. All "exceptions" are described in Section 2. The NCX is similar to a table of contents in that it enables the reader to jump directly to any of the major structural elements of the document, i.

It can be visualized as a collapsible tree familiar to PC users. Its development was motivated by the need to provide quick access to the main structural elements of a document without the need to parse the entire documents.

Other elements such as pages, footnotes, figures, tables, etc. It is important to emphasize that these navigation features are intended as a convenience for users who want them, and not a burden to those who do not. The alternative guide to the book may be provided for those users not requiring the navigation features of the NCX. A Reading System should have the ability to, at user selection, provide access to the NCX navMap in a fashion that allows the user to activate the links provided in the navMap , thus relocating the application's current reading position to the destination described by the selected NCX navPoint.

Reading System implementors should be aware that in a forthcoming major revision of the EPUB specification, it likely will become a compliance criteria for Reading Systems to support the NCX navMap , pageList and navList as described above. The NCX-referencing item must not contain any fallback information required-namespace , fallback or fallback-style attributes. The version and xmlns attributes on the ncx element must be explicitly specified in the document instance, using values drawn from the above-named DTD.

One or several navList 's may be included to allow navigation to other arbitrary constructs in the content see the below informative example. This difference causes the following exceptions to be noted from Section 8 in that standard:.

XML Islands may be referenced from the spine. In the event that a Reading System cannot display the XML Island correctly, then the standard fallback methodology defined in the Open Publication Structure must be used. In short, the Reading System must display the chosen fallback for an XML Island in the event that the island itself cannot be displayed. Much as a tour-guide might assemble points of interest into a set of sightseers' tours, a content provider could assemble selected parts of a publication into a set of tours to enable convenient navigation.

An OPS Package Document may , but need not, contain one tours element, which in turn contains one or more tour elements. Each tour must have a title attribute, intended for presentation to the user. Reading Systems may use tours to provide various access sequences to parts of the publication, such as selective views for various reading purposes, reader expertise levels, etc. Because Reading Systems are not required to implement tour support, content providers should also provide other means of accessing content referenced from tours.

Each tour element contains one or more site elements, each of which must have an href attribute and a title attribute. The href attribute must refer to an OPS Content Document included in the manifest , and may include a fragment identifier as defined in section 4. Each site element specifies a starting point from which the reader can explore freely. Reading Systems may use the bounds of the referenced element to determine the scope of the site.

If a fragment identifier is not used, the scope is considered to be the entire document. This specification does not require Reading Systems to mark or otherwise identify the entire scope of a referenced element. The order of site elements is presumed to be significant, and should be used by Reading Systems to aid navigation. Within the package there may be one guide element, containing one or more reference elements. The guide element identifies fundamental structural components of the publication, to enable Reading Systems to provide convenient access to them.

The structural components of the books are listed in reference elements contained within the guide element. These components could refer to the table of contents, list of illustrations, foreword, bibliography, and many other standard parts of the book.

Reading Systems are not required to use the guide element in any way. Each reference must have an href attribute referring to an OPS Content Document included in the manifest , and which may include a fragment identifier as defined in section 4. Reading Systems may use the bounds of the referenced element to determine the scope of the reference. The required type attribute describes the publication component referenced by the href attribute.

The values for the type attributes must be selected from the list defined below when applicable. Other types may be used when none of the predefined type s are applicable; their names must begin with the string other. The value for the type attribute is case-sensitive. The following list of type values is derived from the 13th edition of the Chicago Manual of Style:.

This specification has been developed through a cooperative effort, bringing together publishers, Reading System vendors, software developers, and experts in the relevant standards. Active members of the working group at the time of publication of revision 2. Members of the working group at the time of publication of revision 2. The working group wishes to specifically acknowledge the contributions of the following individuals.

Ben Trafford for the concept and drafting of XML Islands, as well as overall technical participation, and the XML templates used to produce the specifications. Garth Conboy for working group leadership and motivation, specification drafting and technical contributions.

If errors in the specifications are identified following publication, please post these errors to the forums. The responsible Working Group will review the errors and post pending corrections to the specifications if required or necessary.

Corrections will be incorporated into subsequent versions of the specifications. Table of Contents 1. Specifically, the specification is intended to: Give publication tool providers and content providers e. Specifically, OPF: Describes and references all components of the electronic publication e. Provides publication-level metadata. Specifies the linear reading-order of the publication. Provides fallback information to use when unsupported extensions to OPS are employed. Provides a mechanism to specify a declarative table of contents global navigation structure the NCX.

Together, these three standards constitute EPUB. Deprecated A feature that is permitted, but not recommended , by this specification. OPF The Open Packaging Format — this standard — defines the mechanism by which all components of a published work conforming to the OPS standard including metadata, reading order and navigational information are packaged into an OPS Publication.

Reader A person who reads a publication. Together, these facilitate the construction, organization, presentation, and unambiguous interchange of electronic documents: Extensible Markup Language XML 1.

Reading, Mass. A Reading System is conformant if and only if it processes documents as follows: When presented with an OPF Package Document the Reading System must process all elements and attributes as described in Section 2 of this specification; and ignore all elements and attributes not described in Section 2 of this specification; and verify the existence of the appropriate namespace specifications, as defined in the Relationship to XML Namespaces section above.

Specifically, the following are the most substantive additions: XML 1. XML namespace processing is now required. The tours element has been deprecated. Metadata Publication metadata title, author, publisher, etc. Manifest A list of files documents, images, style sheets, etc. Spine An arrangement of documents providing a linear reading order. Tours Deprecated A set of alternate reading sequences through the publication, such as selective views for various reading purposes, reader expertise levels, etc.

Guide A set of references to fundamental structural features of the publication, such as table of contents, foreword, bibliography, etc.