Copyright © 2017 . This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.
EPUB Packages 3.1 defines package semantics and conformance requirements.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at https://www.w3.org/TR/.
By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.
This section is non-normative.
This specification, EPUB Packages 3.1, defines semantics and conformance requirements for an EPUB® Package. Each Package represents one Rendition of an EPUB Publication, and is defined by a Package Document that describes the content of the Rendition and sets the requirements for how Publication Resources are associated.
This specification also defines the EPUB Navigation Document, a machine- and human-readable specialization of an EPUB Content Document that provides navigation aids such as the table of contents.
This specification is one of a family of specifications that compose [EPUB 3.1], an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3.1.
Refer to [EPUB3 Changes] for more information on the differences between this specification and its predecessor.
Terms with meanings specific to EPUB 3.1 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [EPUB 3.1].
Only the first instance of a term in a section is linked to its definition.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].
All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.
All examples in this specification are informative.
For convenience, the following reserved prefix mappings are used in this specification.
| prefix | URI |
|---|---|
dcterms
|
http://purl.org/dc/terms/
|
opf
|
http://www.idpf.org/2007/opf
|
rendition
|
http://www.idpf.org/vocab/rendition/#
|
A conformant EPUB Package MUST meet all of the following criteria:
It MUST contain exactly one Package Document, which MUST conform to the content requirements defined in Package Document — Content Conformance.
All Publication Resources associated with the Package MUST be listed in the Package Document (as defined in manifest).
It MUST contain one or more EPUB Content Documents, each of which MUST conform to the content requirements defined in [Content Docs 3.1].
It MAY contain zero or more CSS Style Sheets, each of which MUST conform to the content requirements defined in CSS Style Sheets — Content Conformance [Content Docs 3.1].
It MAY contain zero or more PLS Documents, each of which MUST conform to the content requirements defined in PLS Documents — Content Conformance [Content Docs 3.1].
It MAY contain zero or more Media Overlay Documents, each of which MUST conform to the content requirements defined in [Media Overlays 3.1].
It MAY contain zero or more Publication Resources in addition to those listed above, each of which MUST adhere to the requirements in Publication Resources [EPUB 3.1].
An EPUB Reading System MUST meet all of the following criteria:
It MUST process the Package Document as defined in Package Document — Reading System Conformance, and honor all presentation logic expressed through the Package Document (e.g., the reading order, fallback chains, page progression direction and fixed layouts).
It MUST NOT use any resources not listed in the Package Document in the processing of the Package (e.g., META-INF files [OCF 3.1] and resources specific to other Renditions of the EPUB Publication).
This section is non-normative.
The Package Document is an XML document that consists of a set of elements that each encapsulate information about a particular aspect of the EPUB Package. These elements serve to centralize metadata, detail the individual resources that compose the Package and provide the reading order and other information necessary to render the Rendition.
The following list summarizes the information found in the Package Document:
Metadata — mechanisms to include and/or reference metadata applicable to the given Rendition of the EPUB Publication.
A manifest — identifies (via IRI) and describes (via MIME media type) the set of resources that collectively compose the given Rendition.
A spine — an ordered sequence of ID references to top-level resources in the manifest from which all other resources in the set can be reached or utilized. The spine defines the default reading order of the given Rendition.
Collections — a method of encapsulating and identifying subcomponents within the Package.
Manifest fallback chains — a mechanism that defines an ordered list of top-level resources as content equivalents. A Reading System can then choose between the resources based on which it is capable of rendering.
A Package Document MUST meet all of the following criteria:
It MUST meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].
It MUST be valid to the Package Document schema, as defined in Appendix B, Package Document Schema, and conform to all content conformance constraints expressed in Package Document Definition.
The Package Document filename SHOULD use the file extension .opf.
Package Documents have the MIME media type application/oebps-package+xml
[RFC4839].
An EPUB Reading System MUST meet all of the following criteria:
It MUST process the Package Document in conformance with all Reading System conformance constraints expressed in Package Document Definition.
It SHOULD process rendering metadata, as expressed in Package Rendering Metadata
It MUST process fixed layout metadata, as expressed in Fixed-Layout Properties
It MUST ignore proprietary metadata properties that pertain to layout expressions if they conflict behaviorally with the property semantics defined in Fixed-Layout Properties.
All [XML] elements defined in this section are in the http://www.idpf.org/2007/opf namespace [XMLNS] unless otherwise specified.
When an element defined in this section has mandatory text content, that content is referred to as the value of the element in the explanatory descriptions.
The package element is the root element of the Package
Document and defines various aspects of the EPUB Package (see the introduction for a general overview).
package
The package element is the root element of the Package Document.
In this order:
metadata
[exactly 1]
manifest
[exactly 1]
spine
[exactly 1]
collection
[0 or more]
The version attribute specifies the EPUB specification version to which the given EPUB Package conforms. The attribute MUST have the value "3.1" to indicate compliance with this version of the specification.
The unique-identifier attribute takes an IDREF [XML] that identifies the dc:identifier element that provides the preferred, or primary, identifier. Refer to Publication Identifiers for more information.
The prefix attribute provides a declaration mechanism for prefixes not reserved by this specification. Refer to The prefix
Attribute for more information.
The metadata element encapsulates meta information for the given Rendition.
metadata
REQUIRED first child of package.
None
In any order:
dc:identifier
[1 or more]
dc:title
[1 or more]
dc:language
[1 or more]
DCMES Optional Elements
[0 or more]
meta
[1 or more]
link
[0 or more]
The Package Document metadata element has two primary functions:
to provide a minimal set of meta information for Reading Systems to use to internally catalogue an EPUB Publication and make it available to a user (e.g., to present in a bookshelf).
to provide access to all rendering metadata needed to control the layout and display of the Rendition's content (e.g., fixed-layout properties).
The Package Document is not designed to provide complex metadata encoding capabilities. If more detailed information about an EPUB Publication is needed, metadata records can be associated using the link element (e.g., that conform to an international standard such as [ONIX] or are created for custom purposes). This approach allows the metadata to be processed in its native form, avoiding the potential problems and information loss caused by translating to use the minimal Package Document structure.
In keeping with this philosophy, the Package Document only has the following minimal metadata requirements: it MUST include the [DCMES]
title, identifier and language elements together with the [DCTERMS]
modified property. All other metadata is OPTIONAL.
The following example shows the minimal set of metadata that Authors have to include in the Package Document.
<package … unique-identifier="pub-id">
…
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
<dc:title>Norwegian Wood</dc:title>
<dc:language>en</dc:language>
<meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
</metadata>
…
</package>
The meta element provides a generic mechanism for including metadata properties from any vocabulary. It is typically used to include rendering metadata defined in IDPF specifications, but MAY be used for any metadata purposes.
See [EPUB Accessibility] for accessibility metadata recommendations.
The [DCMES]
identifier element contains an identifier associated with the given Rendition, such as a UUID, DOI or ISBN.
dc:identifier
http://purl.org/dc/elements/1.1/
REQUIRED child of metadata.
id
[optional]
opf:scheme
[optional]
Text
The metadata section MUST include an identifier element that contains an unambiguous identifier for the Rendition. This identifier MUST be marked as the Unique Identifier via the package element unique-identifier attribute.
The following example shows the unique identifier element for an EPUB Publication.
<package … unique-identifier="pub-id">
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:identifier id="pub-id">
urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809
</dc:identifier>
…
</metadata>
</package>
The Unique Identifier for each Rendition MAY differ, and a Rendition MAY include additional identifier elements.
To differentiate different versions of the same EPUB Publication, this specification makes a distinction between the Unique Identifier for an EPUB Publication and the Release Identifier that uniquely identifies a specific version of it.
To identify a specific version of a packaged EPUB Publication, a Release Identifier can be constructed by combining the Unique Identifier with the last modified date of the Rendition. For more information on the semantics and requirements of the Release Identifier, refer to Release Identifier.
The following example shows the two components of the Release Identifier.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:identifier id="pub-id">
urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809
</dc:identifier>
<meta property="dcterms:modified">2016-01-01T00:00:01Z</meta>
…
</metadata>
Whenever a Rendition is modified, it MUST include a new last modified date.
To determine whether an identifier conforms to an established system or has been granted by an issuing authority, Reading Systems SHOULD attempt to parse the value of the element.
For additional precision (e.g., if the scheme cannot be determined from the value or could lead to an ambiguous result), Authors MAY attach an opf:scheme attribute to assist in Reading System identification. This attribute identifies the system or authority that generated or assigned the value of the element. Its value MUST be either:
a reserved identifier value [ID Registry] (case-insensitive); or
an absolute IRI [RFC3987] that identifies the scheme. The IRI SHOULD refer to a resource that provides more information about the scheme.
The following example shows the opf:scheme attribute used to indicate a dc:identifier element contains an ISBN.
<dc:identifier opf:scheme="isbn">9780123456789</dc:identifier>
When included, the opf:scheme value SHOULD take precedence over value parsing the identifier. This specification does not require or endorse the use of any particular scheme for identifiers.
Reading Systems MUST trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.
This specification imposes no additional restrictions or the requirements of the identifier except that it MUST be at least one character in length after white space has been trimmed. It is strongly RECOMMENDED that the identifier be a fully qualified URI, however.
The [DCMES]
title element represents an instance of a name given to the EPUB Publication.
dc:title
http://purl.org/dc/elements/1.1/
REQUIRED child of metadata.
opf:alt-rep
[optional]
opf:alt-rep-lang
[conditionally required]
dir
[optional]
opf:file-as
[optional]
id
[optional]
xml:lang
[optional]
Text
The metadata section MUST include at least one title element containing the title for the EPUB Publication.
The following example shows a multi-part title.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:opf="http://www.idpf.org/2007/opf">
<dc:title opf:file-as="Fellowship of the Ring">
THE LORD OF THE RINGS, Part One: The Fellowship of the Ring
</dc:title>
…
</metadata>
Reading Systems MUST recognize the first title element in document order as the main title of the EPUB Publication (i.e., the primary one to present to users). This specification does not define how to process additional title elements.
The title for each Rendition MAY differ.
Reading Systems MUST trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.
This specification imposes no additional restrictions or requirements on the title except that it MUST be at least one character in length after white space has been trimmed.
The [DCMES]
language element specifies the language of the content of the given Rendition.
The metadata section MUST include at least one language element with a value conforming to [BCP
47].
The following example shows an EPUB Publication is in U.S. English.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
…
<dc:language>en-US</dc:language>
…
</metadata>
Additional language elements MAY be included for multilingual Publications, but each element's value MUST conform to [BCP
47].
Languages for each Rendition MAY differ.
Reading Systems MUST trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.
With the exception of identifier, language and title, all other [DCMES] elements are designated as OPTIONAL. These elements conform to the following generalized definition:
contributor | coverage | creator | date | description | format | publisher | relation | rights | source | subject |
type
http://purl.org/dc/elements/1.1/
OPTIONAL child of metadata. Repeatable.
opf:alt-rep
[optional] – only allowed on contributor, creator, and publisher.
opf:alt-rep-lang
[conditionally required] – only allowed on contributor, creator, and publisher.
dir
[optional] – only allowed on contributor, coverage, creator, description, publisher, relation, rights and subject.
opf:file-as
[optional] – only allowed on contributor, creator, and publisher.
id
[optional] – allowed on any element.
opf:role
[optional] – only allowed on contributor and creator.
opf:scheme
[optional] – only allowed on identifier and source.
xml:lang
[optional] – only allowed on contributor, coverage, creator, description, publisher, relation, rights and subject.
Text
The OPTIONAL [DCMES] metadata for each Rendition MAY differ.
Reading Systems MUST trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.
The value of all OPTIONAL [DCMES] elements MUST be at least one character in length after white space has been trimmed.
This specification does not modify the [DCMES] element definitions except as noted in the following sections.
The [DCMES]
contributor element is used to represent the name of a person, organization, etc. that played a secondary role in the creation of the content of an EPUB Publication.
The requirements for the contributor element are identical to those for the creator element in all other respects.
The [DCMES]
creator element represents the name of a person, organization, etc. responsible for the creation of the content of the Rendition.
The creator element SHOULD contain the name of the creator as a Reading System will present it to a user. The opf:file-as attribute MAY be attached to include a normalized form of the name, and the opf:alt-rep attribute MAY be used to represent a creator's name in another language or script (as indicated in the opf:alt-rep-lang attribute).
The role attribute MAY be attached to distinguish the role the creator played in the creation of the content (e.g., an author or illustrator).
The following example shows how a creator name can be included to facilitate sorting and rendering.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:opf="http://www.idpf.org/2007/opf">
…
<dc:creator id="creator" opf:file-as="Murakami, Haruki">
Haruki Murakami
</dc:creator>
…
</metadata>
If an EPUB Publication has more than one creator, each SHOULD be included in a separate creator element.
When determining display priority, Reading Systems MUST use the document order of creator elements in the metadata section, where the first creator element encountered is the primary creator. If a Reading System exposes creator metadata to the user, it SHOULD include all the creators listed in the
metadata section whenever possible (e.g., when not constrained by display considerations).
In the following example, Lewis Carroll is the primary creator as he is listed first.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
…
<dc:creator id="creator01">Lewis Carroll</dc:creator>
<dc:creator id="creator02">John Tenniel</dc:creator>
…
</metadata>
Secondary contributors SHOULD be represented using the contributor element.
The [DCMES]
date element MUST be used only to define the publication date of the
EPUB Publication. The publication date is not the same as the last modified date (the last time the Rendition was changed).
It is RECOMMENDED that the date string conform to [ISO8601], particularly the subset expressed in W3C Date and Time Formats [DateTime], as such strings are both human and machine readable.
The following example shows a publication date.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
…
<dc:date>2000-01-01T00:00:00Z</dc:date>
…
</metadata>
Additional dates SHOULD be expressed using the specialized date properties available in the [DCTERMS] vocabulary, or similar.
The publication date MAY be common to all instances of an EPUB Publication or MAY change from instance to instance (e.g., if the EPUB Publication gets generated on demand).
Only one date element is allowed.
The [DCMES]
subject element identifies the subject of the EPUB Publication.
a reserved authority value [Authority Registry] (case-insensitive); or
an absolute IRI [RFC3987] that identifies the scheme. The IRI SHOULD refer to a resource that provides more information about the scheme.
When a scheme is identified in the opf:authority attribute, the subject code MUST be included in an opf:term attribute. The value of the element SHOULD be the human-readable heading or label, but MAY be the code value if the subject taxonomy does not provide a separate descriptive label.
The following example shows a BISAC code and heading.
<dc:subject opf:authority="BISAC" opf:term="FIC024000">
FICTION / Occult & Supernatural
</dc:subject>
The following example shows the use of an IRI for the scheme.
<dc:subject opf:authority="http://www.ams.org/msc/msc2010.html"
opf:term="11">
Number Theory
</dc:subject>
The opf:term attribute MUST NOT occur on a subject element that does not specify a scheme.
The values of the subject element and opf:term attribute are case sensitive only when the designated scheme requires.
The [DCMES]
type element is used to indicate that the given EPUB Publication is of a specialized type (e.g., annotations or a dictionary packaged in EPUB format).
The IDPF maintains an informative registry of specialized EPUB Publication types for use with this element in [Types Registry].
The meta element provides a generic means of including package metadata.
meta
As child of the metadata element. Repeatable.
opf:alt-rep
[optional]
opf:alt-rep-lang
[conditionally required]
dir
[optional]
opf:file-as
[optional]
id
[optional]
property
[required]
refines
[optional]
[SUPERSEDED]
scheme
[optional]
xml:lang
[optional]
Text
Each meta element defines a metadata expression that establishes some aspect of the EPUB Publication. The property attribute takes a property data type value that defines the statement being made in the expression; the text content of the element represents the assertion. (Refer to Vocabulary
Association Mechanisms for more information.)
This specification reserves the [Meta Vocab] for use with the property attribute. Terms from any other vocabulary MAY be used provided they have a prefix (refer to Reserved
Prefixes for a list of prefixes that do not have to be declared).
The following example shows various property declarations using reserved prefixes.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
…
<meta property="dcterms:modified">2016-02-29T12:34:56Z</meta>
<meta property="rendition:layout">pre-paginated</meta>
<meta property="media:active-class">-epub-media-overlay-active</meta>
…
</metadata>
The scheme attribute identifies the system or scheme that the element's value is drawn from. The value of the attribute MUST be a property data type that resolves to the resource that defines the scheme. If a Reading System does not recognize the scheme attribute value, it SHOULD treat the value of the element as a string.
Reading Systems SHOULD ignore all meta elements whose property attributes define expressions they do not recognize. A Reading System MUST NOT fail when encountering unknown expressions.
Unless an individual property explicitly defines a different white space normalization algorithm, Reading Systems MUST trim all leading and trailing white space from the meta element values, as defined by the XML specification [XML], before further processing them.
Every meta element MUST express a value that is at least one character in length after white space normalization.
The link element is used to associate resources with the given Rendition, such as metadata records.
link
As a child of metadata. Repeatable.
href
[required]
id
[optional]
media-type
[conditionally required]
properties
[optional]
rel
[required]
Empty
The metadata element MAY contain zero or more link elements, each of which identifies the location of a linked resource in its REQUIRED href attribute
Linked resources are not Publication Resources and MUST NOT be listed in the manifest. A linked resource MAY be embedded in a Publication Resource that is listed in the manifest, however, in which case it MUST adhere to Core Media Type requirements [EPUB 3.1] (e.g., an EPUB Content Document could contain a metadata record serialized as [RDFa 1.1] or [JSON-LD]).
The following example shows a reference to a metadata record embedded in a script element inside an XHTML Content
Document. Note that the media type of the embedded record is obtained from type attribute on the script element; it is not specified in the link element.
<metadata>
…
<link rel="record"
href="front.xhtml#meta-json"
media-type="application/xhtml+xml"/>
…
</metadata>
Linked resources MAY be located locally or remotely, but Authors need to be aware that retrieval of Remote Resources by Reading Systems is OPTIONAL (i.e., the resource might not be available).
The media-type attribute is OPTIONAL when a linked resource is located outside the EPUB Container, as more than one media type could be served from the same IRI. The attribute is REQUIRED for all Local Resources.
The REQUIRED rel attribute takes a space-separated list of property values that establish the relationship the resource has with the Rendition.
The following example shows the link element used to associate a local MARC XML record.
<link rel="record"
href="meta/9780000000001.xml"
media-type="application/marc"/>
Reading System do not have to use or present linked resources, even if they recognize the relationship defined in the rel attribute.
The value of the media-type attribute is not always sufficient to identify the type of linked resource (e.g., many XML-based record formats use the media type "application/xml"). To aid Reading Systems in the identification of such generic resources, the properties attribute can be attached with a semantic identifier.
The following example shows the properties attribute used to identify a remote XMP record.
<link rel="record"
href="http://example.org/meta/12389347?format=xmp"
media-type="application/xml"
properties="xmp"/>
The list of reserved relationships and properties recognized by this specification is defined in [Link Vocab].
Authors MAY add relationships and properties from other vocabularies via the metadata extensibility mechanism defined in this specification. Authors also MAY create new values by defining their own prefixes. Refer to Vocabulary Association Mechanisms for more information.
The following example shows the link element used to associate an informational web page. Note that as foaf is not a predefined prefix, it has to be declared in the prefix attribute.
<package … prefix="foaf: http://xmlns.com/foaf/spec/">
<metadata>
…
<link rel="foaf:homepage"
href="http://example.org/book-info/12389347" />
…
</metadata>
…
</package>
In the case of a linked metadata record, Reading Systems MUST NOT skip processing the metadata expressed in the Package Document and only use the information expressed in the record. Linked records are intended to enhance the information available to Reading Systems, and the package metadata typically contains important rendering information. Reading Systems MAY compile metadata from multiple linked records; they do not have to select only one record.
When it comes to resolving discrepancies and conflicts between metadata expressed in the Package Document and in linked metadata records, Reading Systems MUST use the document order of link elements in the Package Document to establish precedence (i.e., metadata in the first linked record encountered has the highest precedence and metadata in the Package Document the lowest, regardless of whether the link elements occur before within or after the package metadata elements).
The following example shows that a remote record that has higher precedence than a local record, which in turn has higher precedence than the metadata found in the metadata element.
<metadata>
…
<link rel="record"
href="http://example.org/onix/12389347"
media-type="application/xml"
properties="onix" />
<link rel="record"
href="meta/meta.jsonld"
media-type="application/ld+json" />
…
</metadata>
Reading Systems MUST ignore any instructions contained in linked resources related to the layout and rendering of the EPUB Publication.
Due to the variety of metadata record formats and serializations that can be linked to an EPUB Publication, and the complexity of comparing metadata properties between them, this specification does not require Reading Systems to process linked records.
The manifest element provides an exhaustive list of the Publication Resources that constitute the given Rendition, each represented by an item element.
This specification supports internationalized resource naming, so elements and attributes that reference Publication Resources accept IRIs as their value. For compatibility with older Reading Systems that only accept URIs, resource names need to be restricted to the ASCII character set.
The item element represents a Publication
Resource.
item
As a child of manifest. Repeatable.
duration
[conditionally required]
fallback
[conditionally required]
href
[required]
id
[required]
media-overlay
[optional]
media-type
[required]
properties
[optional]
Empty
Each item element in the manifest identifies a
Publication
Resource by the IRI [RFC3987] provided in its href attribute. The IRI MAY be absolute or relative. In the case of relative IRIs, Reading Systems MUST use the IRI of the Package Document as the base when resolving these to absolute IRIs. The resulting absolute IRI MUST be unique within the manifest scope.
All Publication Resources MUST be referenced from the manifest, regardless of whether they are Local or Remote
Resources. Refer to Publication Resource Locations
[EPUB
3.1] for media type-specific requirements regarding resource locations.
Note that the manifest is not self-referencing: it MUST NOT include an item element that refers to the Package Document itself.
The Publication Resource identified by an item element MUST conform to the applicable specification(s) as inferred from the MIME media type provided in the media-type attribute.
Core Media Type Resources MUST use the media type designated in [Core Media
Types].
The fallback attribute takes an IDREF [XML] that identifies a fallback for the Publication Resource referenced from the item element. Fallbacks MAY be provided for Core Media Type Resources (e.g., to provide a static alternative to a Scripted Content
Document). Fallback requirements for Foreign Resources are defined in Manifest Fallbacks.
This specification reserves the [Manifest Vocab] for use with the properties attribute. Terms from other vocabularies MAY be used provided they have a prefix (refer to Reserved Prefixes for a list of prefixes that do not have to be declared).
Authors MUST declare all applicable descriptive metadata properties for each Publication Resource in this attribute, as Reading Systems MAY optimize the rendering depending on the properties that have been set (e.g., disable a rendering process or use a fallback). Reading Systems MUST ignore all descriptive metadata properties that they do not recognize.
Exactly one item MUST be declared as the EPUB
Navigation Document using the nav property.
The media-overlay attribute takes an IDREF
[XML] that identifies the Media Overlay
Document for the resource described by this item. Refer to
Packaging
[Media
Overlays 3.1] for more information.
The duration attribute takes a [SMIL]
clock value that provides the total duration of the audio media referenced from a Media Overlay Document or, in the case of timed media, the total duration of the referenced media file. Refer to Package Metadata
[Media
Overlays 3.1] for more information.
The order of item elements in the manifest is not significant. The presentation sequence of content documents is provided in the spine.
The following example shows a manifest that contains only Core Media Type Resources.
<manifest>
<item id="nav"
href="nav.xhtml"
properties="nav"
media-type="application/xhtml+xml"/>
<item id="intro"
href="intro.xhtml"
media-type="application/xhtml+xml"/>
<item id="c1"
href="chap1.xhtml"
media-type="application/xhtml+xml"/>
<item id="c1-answerkey"
href="chap1-answerkey.xhtml"
media-type="application/xhtml+xml"/>
<item id="c2"
href="chap2.xhtml"
media-type="application/xhtml+xml"/>
<item id="c2-answerkey"
href="chap2-answerkey.xhtml"
media-type="application/xhtml+xml"/>
<item id="c3"
href="chap3.xhtml"
media-type="application/xhtml+xml"/>
<item id="c3-answerkey"
href="chap3-answerkey.xhtml"
media-type="application/xhtml+xml"/>
<item id="notes"
href="notes.xhtml"
media-type="application/xhtml+xml"/>
<item id="cover"
href="./images/cover.svg"
properties="cover-image"
media-type="image/svg+xml"/>
<item id="f1"
href="./images/fig1.jpg"
media-type="image/jpeg"/>
<item id="f2"
href="./images/fig2.jpg"
media-type="image/jpeg"/>
<item id="css"
href="./style/book.css"
media-type="text/css"/>
<item id="pls"
href="./speech/dict.pls"
media-type="application/pls+xml"/>
</manifest>
The following example shows a manifest that references two Foreign Resources, and therefore uses the fallback chain
mechanism to supply content alternatives. The fallback chain terminates with a Core Media Type.
<manifest>
<item id="item1"
href="chap1_docbook.xml"
media-type="application/docbook+xml"
fallback="fall1"/>
<item id="fall1"
href="chap1.xml"
media-type="application/z3998-auth+xml"
fallback="fall2" />
<item id="fall2"
href="chap1.xhtml"
media-type="application/xhtml+xml"/>
…
</manifest>
The following example shows a reference to a remote audio file that has to be referenced from the manifest (the audio is rendered inline in the XHTML Content Document so it is a Publication Resource).
XHTML:
<audio src="http://www.example.com/book/audio/ch01.mp4" controls="controls"/>
Manifest:
<item id="audio01"
href="http://www.example.com/book/audio/ch01.mp4"
media-type="audio/mp4"/>
The following example shows a link to the same audio file, but in this case it is not be listed in the manifest (hyperlinked Remote Resources are not Publication Resources). The audio file would only be listed in the manifest if the Author has also referenced it from an [HTML] embedded content element, as above (i.e., in a context where it is used as a Publication Resource).
XHTML:
<a href="http://www.example.com/book/audio/ch01.mp4">Go to audio file</a>
Manifest:
No Entry
The following example shows a link to a local version of the audio file. Because audio files are not EPUB Content Documents, it requires a fallback to an EPUB Content Document (it also has to be listed in the spine).
XHTML:
<a href="audio/ch01.mp4">Open Audio File</a>
Manifest:
<item id="audio01"
href="audio/ch01.mp4"
media-type="audio/mp4"
fallback="#audio01-xhtml"/>
Foreign Resources MAY be referenced in contexts in which an intrinsic fallback cannot be provided (e.g., directly from spine
itemref elements; from [HTML]
img, iframe and link elements in XHTML Content
Documents; and from @import rules in CSS Style Sheets). Manifest fallbacks MUST be provided in such cases.
Manifest fallbacks are provided using the fallback attribute on the manifest
item element that represents the Publication Resource. The fallback attribute's IDREF [XML] value MUST resolve to another item in the manifest. This fallback item MAY itself specify another fallback item, and so on.
The ordered list of all the ID references that can be reached starting from a given item's fallback attribute represents the fallback
chain for that item. The order of the resources in the fallback chain represents the Author's preferred fallback order.
A Reading System that does not support the Media Type of a given Publication Resource MUST traverse the fallback chain until it has identified at least one supported Publication Resource to be used in place of the unsupported resource. If the Reading System supports multiple Publication Resources in the fallback chain, it MAY select the resource to use based on specific properties of that resource, otherwise it SHOULD honor the Author's preferred fallback order.
Fallback chains MUST conform to one of the following requirements, as appropriate:
For Foreign Resources referenced directly from spine itemref elements, the chain MUST contain at least one EPUB Content Document.
For Foreign Resources for which an intrinsic fallback cannot be provided, the chain MUST contain at least one Core Media Type Resource.
Fallback chains MUST NOT contain any circular- or self-references to item elements in the chain.
Fallbacks MAY also be provided for Top-Level Content Documents that are EPUB Content Documents; a Reading System MAY choose to utilize such fallbacks in order to find the optimal version of a Content Document to render in a given context. An example of when this feature can be utilized is when providing fallbacks for scripted content [Content Docs 3.1].
The spine element defines an ordered list of manifest item references that represent the default reading order of the given Rendition.
Reading Systems MUST provide a means of rendering the Rendition in the order defined in the spine, which includes: 1) recognizing the first primary itemref as the beginning of the default reading order; and, 2) rendering successive primary items in the order given in the spine.
All Publication
Resources that are hyperlinked to from Publication Resources in the spine MUST themselves be listed in the spine, where hyperlinking is defined to be any linking mechanism that requires the user to navigate away from the current resource. Common hyperlinking mechanisms include the href attribute of the [HTML]
a and area elements and scripted links (e.g., using DOM Events and/or form elements). The requirement to list hyperlinked resources applies recursively (i.e., all Publication Resources hyperlinked from hyperlinked Publication Resources also have to be listed, and so on.).
All Publication Resources hyperlinked to from the EPUB Navigation
Document also MUST be listed in the spine, regardless of whether the Navigation Document is itself listed the spine.
As Remote Resources referenced from hyperlinks are not Publication Resources, they are not subject to the requirement to include in the spine (e.g., Web pages and resources).
Embedded Publication Resources (e.g., via the [HTML]
iframe element) do not have to be listed in the spine.
The page-progression-direction attribute sets the global direction in which the content flows. Allowed values are ltr (left-to-right), rtl (right-to-left) and default. When the default value is specified, the Author is expressing no preference and the Reading System can choose the rendering direction. The default value MUST be assumed when the attribute is not specified.
Although the page-progression-direction attribute sets the global flow direction, individual Content Documents and parts of Content Documents MAY override this setting (e.g., via the writing-mode CSS property). Reading Systems MAY also provide mechanisms to override the default direction (e.g., buttons or settings that allow the application of alternate style sheets).
Reading Systems MUST ignore the page progression direction defined in pre-paginated XHTML Content Documents. The page-progression-direction attribute defines the flow direction from one fixed-layout page to the next.
The child itemref elements of the spine represent a sequential list of Publication
Resources (typically
EPUB Content Documents). The order of the itemref elements defines the default reading order of the given Rendition.
itemref
As a child of spine. Repeatable.
id
[optional]
idref
[required]
linear
[optional]
properties
[optional]
Empty
Each itemref element MUST reference the ID [XML] of a unique item in the manifest via the IDREF [XML] in its idref attribute (i.e., two or more itemref elements cannot reference the same item).
Each referenced manifest item MUST be either a) an EPUB Content Document or b) another type of Publication Resource which, regardless of whether it is a
Core Media Type Resource or a Foreign Resource
, MUST include an EPUB Content Document in its fallback
chain.
Although EPUB Publications have to include an EPUB Navigation Document, it is not mandatory to include it in the
spine.
The linear attribute indicates whether the referenced item contains content that contributes to the primary reading order and has to be read sequentially ("yes") or auxiliary content that enhances or augments the primary content and can be accessed out of sequence ("no"). Examples of auxiliary content include: notes, descriptions and answer keys.
The linear attribute allows Reading Systems to distinguish content that a user needs to access as part of the default reading order from supplementary content which might, for example, be presented in a popup window or omitted from an aural rendering.
When rendering an EPUB Publication, a Reading System MAY either suppress non-linear content so that it does not appear in the default reading order, or ignore the linear attribute in order to provide users access to the entire content of the EPUB Publication. This specification does not mandate which model Reading Systems have to use. A Reading System MAY also provide the option for users to toggle between the two models.
Each Rendition MUST include at least one itemref whose linear attribute value is either explicitly or implicitly set to "yes". An itemref that omits the linear attribute is assumed to have the value "yes".
Authors MUST provide a means of accessing all non-linear content (e.g., hyperlinks in the content or from the EPUB Navigation Document).
This specification reserves the [Spine Vocab] for use with the properties attribute. Terms from any other vocabulary MAY be used provided they have a prefix (refer to Reserved Prefixes for a list of prefixes that do not have to be declared).
All applicable descriptive metadata properties defined in [Spine Vocab] SHOULD be declared.
Reading Systems MUST ignore all metadata properties expressed in the properties attribute that they do not recognize.
The following example shows a spine element corresponding to the manifest example above.
<spine page-progression-direction="ltr">
<itemref idref="intro"/>
<itemref idref="c1"/>
<itemref idref="c1-answerkey" linear="no"/>
<itemref idref="c2"/>
<itemref idref="c2-answerkey" linear="no"/>
<itemref idref="c3"/>
<itemref idref="c3-answerkey" linear="no"/>
<itemref idref="notes" linear="no"/>
</spine>
The collection element defines a related group of resources.
collection
OPTIONAL sixth element of package. Repeatable.
In this order: metadata
[0 or 1], ( collection
[1 or more] or ( collection
[0 or more], link
[1 or more] ))
The collection element allows resources to be assembled into logical groups for a variety of potential uses: enabling content that has been split across multiple EPUB Content Documents to be reassembled back into a meaningful unit (e.g., an index split across multiple documents), identifying resources for specialized purposes (e.g., preview content), or collecting together resources that present additional information about the given Rendition.
The collection element, as defined in this section, represents a generic framework from which specializations are intended to be derived (e.g., through IDPF sub-specifications). Such specializations MUST define the purpose of the collection element within a Rendition, as well as all requirements for its valid production and use (specifically any requirements that differ from the general framework presented below).
Each specialization MUST define a role value that uniquely identifies all conformant collection elements. The role of each collection element in the Package Document MUST be identified in its role attribute, whose value MUST be one or more NMTOKENs [XSD-DATATYPES] and/or absolute IRIs [RFC3987]. The use of NMTOKEN values is reserved for IDPF-defined roles, which are maintained in the [Role Registry]. NMTOKEN values not defined in the registry are not valid. No roles are defined in this section.
Third parties MAY define custom roles for the collection element, but such roles MUST be identified using absolute IRIs. Custom roles MUST NOT incorporate the string "idpf.org" in the host component of their identifying IRI.
To facilitate interoperability of custom roles across Reading Systems, implementers are strongly encouraged to document their use of the collection element in [Role Extensions].
The OPTIONAL metadata element child of
collection is an adaptation of the package metadata element, with the following differences in syntax and semantics:
No metadata is mandatory by default.
Package-level restrictions on the use of metadata elements MAY be overridden.
A collection MAY define sub-collections through the inclusion of one or more child collection elements.
The link element child of collection is an adaptation of the metadata link element, with the following differences in syntax and semantics:
The rel attribute is OPTIONAL.
The properties attribute also accepts manifest item properties
[Manifest Vocab] without a prefix (e.g., so that a collection can declare its own Navigation Document or cover image).
Each link element MUST reference a resource that is a member of the group. The order of link elements is not significant.
Specializations of the collection element MAY tailor the requirements defined above to better reflect their needs (e.g., requiring metadata, imposing further restrictions on the use of elements and attributes, or making the order of link elements significant). However, the resulting content model MUST represent a valid subset of the one defined in this section (e.g., specializations cannot introduce new elements or attributes, or re-introduce those expressly forbidden above). Specializations MUST NOT define collections in a way that overrides the requirements of the manifest and spine.
In the context of this specification, support for collections in Reading Systems is OPTIONAL. Reading Systems MUST ignore collection elements that define unrecognized roles.
The rendering of a Rendition MUST NOT be dependent on the recognition of collection elements. The content MUST remain consumable by a user without any information loss or other significant deterioration.
The following example shows the assembly of two XHTML Content Documents that represent a single unit.
<package …>
…
<collection role="http://example.org/roles/unit">
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:title>Foo Bar</dc:title>
</metadata>
<link href="EPUB/xhtml/foo-1.xhtml"/>
<link href="EPUB/xhtml/foo-2.xhtml"/>
</collection>
…
</package>
The Author is responsible for including a primary identifier in the Package
Document metadata that is unique to one and only one EPUB
Publication. This Unique Identifier, whether chosen or assigned, MUST be stored in the dc:identifier element and be referenced as the Unique Identifier in the package element unique-identifier attribute.
Although not static, changes to the Unique Identifier for an EPUB Publication SHOULD be made as infrequently as possible. New identifiers SHOULD NOT be issued when updating metadata, fixing errata or making other minor changes to the EPUB Publication.
Reading Systems MUST NOT depend on the Unique Identifier being unique to one and only one EPUB Publication. Determining whether two EPUB Publications with the same Unique Identifier represent different versions of the same publication (see Release Identifier), or different publications, might require inspecting other metadata, such as the titles or authors.
The Unique Identifier of an EPUB Publication typically SHOULD NOT change with each minor revision to the package or its contents, as Unique Identifiers are intended to have maximal persistence both for referencing and distribution purposes. Each release of an EPUB Publication normally requires that the new version be uniquely identifiable, however, which results in the contradictory need for reliable Unique Identifiers that are changeable.
To redress this problem of identifying minor modifications and releases without changing the Unique Identifier, this specification defines the semantics for a Release Identifier, or means of distinguishing and sequentially ordering EPUB Publications with the same Unique Identifier.
The Release Identifier is not an actual property in the package metadata section, but is a value that can be obtained from two other mandatory pieces of metadata: the Unique Identifier and the last modification date of the Rendition. When the taken together, the combined value represents a unique identity that can be used to distinguish any particular version of an EPUB Publication from another.
To ensure that a Release Identifier can be constructed, each Rendition MUST include exactly one [DCTERMS] modified property containing its last modification date. The value of this property MUST be an [XSD-DATATYPES] dateTime conformant date of the form:
CCYY-MM-DDThh:mm:ssZ
The last modification date MUST be expressed in Coordinated Universal Time (UTC) and MUST be terminated by the "Z" (Zulu) time zone indicator.
Although not a part of the package metadata, for referencing and other purposes all string representations of the identifier MUST be constructed using the at sign (@) as the separator (i.e., of the form "id@date"). Whitespace MUST NOT be included when concatenating the strings.
The following example shows how a Unique Identifier and modification date are combined to form the Release Identifier.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
<meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
…
</metadata>
results in the Package ID:
urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809@2011-01-01T12:00:00Z
Note that it is possible that the separator character MAY occur in the Unique Identifier, as these identifiers MAY be any string value. The Release Identifier consequently MUST be split on the last instance of the at sign when decomposing it into its component parts.
The Release Identifier does not supersede the Unique Identifier, but represents the means by which different versions of the same EPUB Publication can be distinguished and identified in distribution channels and by Reading Systems. The sequential, chronological order inherent in the format of the timestamp also places EPUB Publications in order without requiring knowledge of the exact identifier that came before.
The Release Identifier consequently allows a set of EPUB Publications to be inspected to determine if they represent the same version of the same Publication, different versions of a single EPUB Publication, or any combination of differing and similar EPUB Publications.
When an EPUB Container includes more than one Rendition of an EPUB Publication, updating the last modified date of the default rendition for each release — even if it has not been updated — will help ensure that the EPUB Publication does not appear to be the same version as an earlier release, as Reading Systems only have to process the default rendition.
This section is non-normative.
The property, properties, rel and scheme attributes use the property data type to represent terms from metadata vocabularies. Similar to a CURIE [RDFa 1.1], the property data type represents an IRI [RFC3987] in compact form and simplifies the authoring of metadata from standardized vocabularies.
A property value is an expression that consists of a prefix and a reference, where the prefix — whether literal or implied — is a shorthand mapping of an IRI that typically resolves to a term vocabulary. When the prefix is converted to its IRI representation and combined with the reference, the resulting IRI normally resolves to a fragment within that vocabulary that contains human- and/or machine-readable information about the term.
To assist Reading Systems in processing property values, this specification defines three mechanisms to establish the IRI a prefix maps to:
default vocabularies — define the mapping when a property value does not include a prefix;
reserved prefixes — these mappings are predefined (i.e., all Reading Systems recognize them) and can be used without having to be declared; and
the prefix attribute — a declarative means of creating new prefix mappings on the root
package element.
A default vocabulary is a vocabulary that does not require a prefix to be declared in order to use its terms, and whose terms MUST always be unprefixed.
As the Package Document has multiple unrelated uses for metadata terms, a single default vocabulary is not defined for all attributes. Instead, different default vocabularies are defined for use in attributes that accept a property data type as follows:
The EPUB Meta
Properties Vocabulary
[Meta Vocab] is defined to be the default vocabulary for the meta
properties attribute.
If the attribute's value does not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI: http://idpf.org/epub/vocab/package/meta/#
The EPUB Metadata
Link Vocabulary
[Link Vocab] is defined to be the default vocabulary for the link
rel and properties attributes.
If any of these attributes' values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them:
http://idpf.org/epub/vocab/package/link/#
The EPUB Manifest
Properties Vocabulary
[Manifest Vocab] is defined to be the default vocabulary for the item
properties attribute.
If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them:
http://idpf.org/epub/vocab/package/item/#
The EPUB Spine
Properties Vocabulary
[Spine Vocab] is defined to be the default vocabulary for the itemref
properties attribute.
If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem MUST be used to generate the resulting IRI for them:
http://idpf.org/epub/vocab/package/itemref/#
The IRIs associated with these vocabularies MUST NOT be assigned a prefix using the prefix attribute.
This specification reserves a set of prefixes that Authors MAY use in package metadata without having to declare. These prefixes are defined in [Reserved Prefixes].
The prefixes defined in this document are maintained and updated separately of this specification and are subject to change at any time.
Reading Systems MUST resolve all reserved prefixes used in Package Documents using their predefined URIs unless a local prefix is declared. Reserved prefixes SHOULD NOT be overridden in the prefix attribute, but Reading Systems
MUST use such local overrides when encountered.
As changes to the reserved prefixes and updates to Reading Systems are not always going happen in synchrony, Reading Systems MUST NOT fail when encountering unrecognized prefixes (i.e., not reserved and not declared using the prefix attribute).
The prefix attribute defines additional prefix mappings not reserved by this specification.
The value of the prefix attribute is a white space-separated list of one or more prefix-to-IRI mappings of the form:
| prefixes | = |
mapping , { whitespace, { whitespace } , mapping } ; | |
| mapping | = |
prefix , ":" , space , { space } , ? xsd:anyURI ? ; | |
| prefix | = |
? xsd:NCName ? ; | |
| space | = |
#x20 ; | |
| whitespace | = |
(#x20 | #x9 | #xD | #xA) ; |
The following example shows prefixes for the Friend of a Friend (foaf) and DBPedia (dbp) vocabularies being declared using the prefix attribute.
<package …
prefix="foaf: http://xmlns.com/foaf/spec/
dbp: http://dbpedia.org/ontology/">
…
</package>
To avoid conflicts, the prefix attribute MUST NOT be used to declare a prefix that maps to the default vocabulary. If the prefix attribute includes a declaration for a predefined
prefix, Reading Systems MUST use the URI mapping defined in the prefix attribute, regardless of whether of it maps to the same URI as the predefined prefix.
The prefix '_' MUST NOT be declared as it is reserved for future compatibility with RDFa [RDFa 1.1] processing.
For future compatibility with alternative serializations of the Package Document, a prefix for the Dublin Core /elements/1.1/ namespace [DCTERMS] MUST NOT be declared in the prefix attribute. Authors MUST use only the [DCMES] elements allowed in the Package Document metadata.
The property data type is a compact means of expressing an IRI [RFC3987] and consists of an OPTIONAL prefix separated from a reference by a colon.
| property | = |
[ prefix , ":" ] , reference; | |
| prefix | = |
? xsd:NCName ? ; | |
| reference | = |
? irelative-ref ? ; | /* as defined in [RFC3987] */ |
The property data type is derived from the CURIE data type defined in [RDFa 1.1], and represents a subset of CURIEs.
The following example shows a property value composed of the prefix dcterms and the reference modified.
<meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
After processing, this property would expand to the following IRI:
http://purl.org/dc/terms/modified
as the dcterms: prefix is a reserved prefix that maps to the IRI "http://purl.org/dc/terms/".
When a prefix is omitted from a property value, the expressed reference represents a term from the default vocabulary for that attribute.
The following example shows the [Manifest Vocab]
mathml property on a manifest item element:
<item … properties="mathml"/>
This property expands to:
http://idpf.org/epub/vocab/package/item/#mathml
when the IRI for the vocabulary is concatenated with the reference.
An empty string does not represent a valid property value, even though it is valid to the definition above.
A Reading System MUST use the following rules to create an IRI [RFC3987] from a property:
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.
The resulting IRI MUST be valid to [RFC3987]. Reading Systems do not have to resolve this IRI, however.
This section is non-normative.
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.e., functionality that can only be implemented by the EPUB Reading System). If a Reading System supports the desired rendering, these properties enable the user to be presented the content as the Author optimally designed it.
When the rendition:flow property
[Rendition Vocab] is specified on a meta element, it indicates the Author's global preference for overflow content handling (i.e., for all spine items). 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.e., with a dynamic page break between each).
If a Reading System supports the specified rendering, it SHOULD use that method to handle overflow content, but MAY provide the option for users to override the requested rendering.
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.
Note that when two reflowable EPUB Content Documents occur sequentially in the spine, the default rendering for their [HTML]
body elements is consistent with the page-break-before property
[CSS
Snapshot] having been set to always. 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 rendition:flow property MUST NOT be declared more than once.
The following values are defined for use with the rendition:flow property:
The Reading System SHOULD dynamically paginate all overflow content.
The Reading System SHOULD render all Content Documents such that overflow content is scrollable, and the EPUB Publication represented by the given Rendition SHOULD be presented as one continuous scroll from spine item to spine item (except where locally overridden).
It is expected that a future version of this specification will provide more information about Reading System behaviors for scrolled-continuous.
The Reading System SHOULD render all Content Documents such that overflow content is scrollable, and each spine item SHOULD be presented as a separate scrollable document.
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.
The rendition:flow-auto, rendition:flow-paginated, rendition:flow-scrolled-continuous and rendition:flow-scrolled-doc properties [Rendition Vocab] MAY be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.
Only one of these overrides is allowed on any 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 following example demonstrates an Author's intent to have a paginated Rendition with a scrollable table of contents.
<metadata>
<meta property="rendition:flow">paginated</meta>
</metadata>
<spine>
<itemref idref="toc" properties="rendition:flow-scrolled-doc"/>
<itemref idref="c01"/>
</spine>
When the rendition:align-x-center property [Rendition Vocab] 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.
For reflowable content, Reading Systems that support this property MUST center each virtual page.
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.
This property was developed primarily to handle "Naka-Tobira (中扉)" (sectional title pages), in the absence of reliable centering control within the content rendering. 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.
This section is non-normative.
EPUB documents, unlike print books or PDF files, are designed to change. The content flows, or reflows, to fit the screen and to fit the needs of the user. As noted in Rendering and CSS [EPUB3 Overview] “content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content”
But this principle doesn’t work for all types of documents. Sometimes content and design are so intertwined they cannot be separated. Any change in appearance risks changing the meaning, or losing all meaning. Fixed-Layout Documents give Authors greater control over presentation when a reflowable EPUB is not suitable for the content.
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.1.
EPUB 3.1 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.
When the rendition:layout property
[Rendition Vocab] is specified on a meta element, it indicates that the paginated or reflowable layout style applies globally for the Rendition (i.e., for all spine items).
The default value reflowable MUST be assumed by EPUB Reading
Systems as the global value if no meta element carrying this property occurs in the metadata section.
When the rendition:layout property is set to pre-paginated, Reading Systems MUST NOT include space between the adjacent content slots when rendering Synthetic Spreads.
When the property is set to pre-paginated for a spine item, its content dimensions MUST be set as defined in Fixed Layouts
[Content Docs 3.1].
The rendition:layout property MUST NOT be declared more than once.
Refer to rendition:viewport property for how to additionally declare the dimensions within the package metadata to facilitate Reading System optimization of the rendering.
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 MUST produce exactly one page per spine
itemref when rendering.
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.4 - Provide text configuration [UAAG 2.0] for related information.
The rendition:layout-pre-paginated and rendition:layout-reflowable properties [Rendition Vocab] MAY be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.
Only one of these overrides is allowed on any given spine item.
The following example demonstrates fully fixed-layout content, using [Media Queries] to apply different style sheets for three different device categories. Note that the Media Queries only affect the style sheet applied to the document; the size of the content area set in the viewport
meta tag is static.
<meta property="rendition:layout">pre-paginated</meta>
<head>
<meta name="viewport" content="width=1200, height=900"/>
<link rel="stylesheet" href="eink-style.css" media="(max-monochrome: 3)"/>
<link rel="stylesheet" href="skinnytablet-style.css" media="((color) and
(max-height:600px) and (orientation:landscape), (color) and (max-width:600px)
and (orientation:portrait))"/>
<link rel="stylesheet" href="fattablet-style.css" media="((color) and
(min-height:601px) and (orientation:landscape), (color) and (min-width:601px)
and (orientation:portrait)"/>
</head>
When the rendition:orientation property
[Rendition Vocab] is specified on a meta element, it indicates that the intended orientation applies globally for the given Rendition (i.e., for all spine items).
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.
The rendition:orientation property MUST NOT be declared more than once.
The following values are defined for use with the rendition:orientation property:
The given Rendition is intended for landscape rendering.
The given Rendition is intended for portrait rendering.
The given Rendition is not orientation constrained.
Reading Systems that support multiple orientations SHOULD convey the intended orientation to the user, unless the given value is auto. The means by which the intent is conveyed is implementation-specific.
The rendition:orientation-landscape, rendition:orientation-portrait and rendition:orientation-auto properties [Rendition Vocab] MAY be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.
Only one of these overrides is allowed on any given spine item.
The following example demonstrates fully fixed-layout content intended to be rendered without synthetic spreads, and locked to landscape orientation.
<metadata>
<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:spread">none</meta>
<meta property="rendition:orientation">landscape</meta>
</metadata>
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.e., for all spine items).
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.
The rendition:spread property MUST NOT be declared more than once.
The following values are defined for use with the rendition:spread property:
Reading Systems MUST NOT incorporate spine items in a Synthetic Spread.
Reading Systems SHOULD render a Synthetic Spread for spine items only when the device is in landscape orientation.
Reading Systems SHOULD render a Synthetic Spread regardless of device orientation.
No explicit Synthetic Spread behavior is defined. Reading Systems MAY use Synthetic Spreads in specific or all device orientations as part of a Content Display Area utilization optimization process.
When Synthetic Spreads are used in the context of HTML and SVG Content Documents, the dimensions given via the viewport
meta element
[Content Docs 3.1] and viewBox attribute
[Content Docs 3.1] represents the size of one page in the spread, respectively.
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.
The rendition:spread-landscape, rendition:spread-both, rendition:spread-auto and rendition:spread-none properties [Rendition Vocab] MAY be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.
Only one of these overrides is allowed on any given spine item.
The following example demonstrates fully fixed-layout content intended to be rendered using synthetic spreads in landscape orientation, and with no spreads in portrait orientation.
<metadata>
<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:spread">landscape</meta>
</metadata>
The following example demonstrates reflowable content with a single fixed-layout title page, where the fixed-layout page is intended for right-hand spread slot if the device renders Synthetic Spreads.
<metadata>
<meta property="rendition:layout">reflowable</meta>
<meta property="rendition:spread">auto</meta>
</metadata>
<spine>
<itemref idref="titlepage" properties="page-spread-right rendition:layout-pre-paginated"/>
</spine>
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. By providing one of the rendition:page-spread-left, rendition:page-spread-right or rendition:page-spread-center properties [Rendition Vocab] on a spine itemref element, an Author
MAY override this automatic population behavior by forcing that document to be placed in a particular viewport.
The rendition:page-spread-left property indicates that the given spine item SHOULD be rendered in the left-hand slot in the spread, and rendition:page-spread-right that it SHOULD be rendered in the right-hand slot. 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 rendition:page-spread-* properties take precedence over whatever value of the page-break-before property [CSS Snapshot] has been set for an XHTML Content Document.
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.
When a reflowable spine item follows a pre-paginated one, the reflowable one SHOULD start on the next page (as defined by the page-progression-direction) when it lacks a rendition:page-spread-* property value. If the reflowable spine item has a rendition:page-spread-* specification, it MUST be honored (e.g., by inserting a blank page).
Similarly, when a pre-paginated spine item follows a reflowable one, the pre-paginated one SHOULD start on the next page (as defined by the page-progression-direction) when it lacks a rendition:page-spread-* property value. If the pre-paginated spine item has a rendition:page-spread-* specification, it MUST be honored (e.g., by inserting a blank page).
Although Authors often indicate to use a spread in certain device orientations, the content itself does not represent true spreads (i.e., two consecutive pages that have to be rendered side-by-side for readability, such as a two-page map). 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. When a Reading System encounters two spine items that represent a true spread, it SHOULD create the spread with no space between the adjacent pages.
Only one page-spread-* property can be declared on any given spine item.
The rendition:page-spread-left and rendition:page-spread-right properties are aliases for the page-spread-left and spread-right properties [Spine Vocab]. 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 [Spine Vocab] is no longer being extended for package rendering metadata, so an unprefixed page-spread-center is not available.
The following example demonstrates reflowable content with a two-page fixed-layout center plate that is intended to be rendered using synthetic spreads in any device orientation. Note that the author has left spread behavior for the other (reflowable) parts of the Rendition undefined, since the global value of rendition:spread is initialized to auto by default.
<spine page-progression-direction="ltr">
…
<itemref idref="center-plate-left"
properties="rendition:spread-both rendition:page-spread-left"/>
<itemref idref="center-plate-right"
properties="rendition:spread-both rendition:page-spread-right"/>
…
</spine>
The following example demonstrates fixed-layout content, where synthetic spreads, when used, have to be disabled for a center plate. Note that the rendition:spread declaration none expression is not needed on the center plate item, as the rendition:page-spread-center property already specifies semantics that dictates that synthetic spreads be disabled.
<metadata>
<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:spread">auto</meta>
</metadata>
<spine>
<itemref idref="center-plate" properties="rendition:page-spread-center"/>
</spine>
This appendix lists deprecated and superseded [EPUB 3.1] features of this specification.
Use of the meta
refines attribute is deprecated. It is replaced by the duration, opf:alt-rep, opf:authority, opf:file-as, opf:role, opf:scheme and opf:term attributes.
For more information about this attribute, refer to its definition in [Publications 3.0.1].
Use of the portrait value with the rendition:spread property is deprecated.
The rendition:spread-portrait spine override is similarly deprecated.
For more information about this value, refer to its definition in [Publications 3.0.1].
Use of the rendition:viewport property is deprecated.
For more information about this property, refer to its definition in [Publications 3.0.1].
The [OPF2] NCX file is superseded and marked for removal.
The NCX provides a measure of backwards compatibility for EPUB 2 Reading Systems, but has no function in EPUB 3. It is replaced by the EPUB Navigation Document. EPUB 3 Reading Systems MUST ignore the NCX.
The spine
toc attribute is superseded and marked for removal.
This attribute allows the [OPF2] NCX to be identified.
The schema for Package Documents is available at http://www.idpf.org/epub/31/schema/package-31.nvdl.
Validation using this schema requires a processor that supports [NVDL], [RelaxNG], [ISO Schematron] and [XSD-DATATYPES].
The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.
This appendix registers the media type application/oebps-package+xml for the EPUB Package Document. This registration supersedes [RFC4839].
The Package Document is an XML file that describes a Rendition of an EPUB Publication. It identifies the resources in the Rendition and provides metadata information. The Package Document and its related standards are maintained and defined by the International Digital Publishing Forum (IDPF).
application
oebps-package+xml
None.
None.
Package Documents are UTF-8 or UTF-16 encoded XML.
Package Documents contain well-formed XML conforming to the XML 1.0 specification.
Clearly, it is possible to author malicious files which, for example, contain malformed data. Most XML parsers protect themselves from such attacks by rigorously enforcing conformance.
All processors that read Package Documents should rigorously check the size and validity of data retrieved.
There is no current provision in the EPUB Publications 3.0 standard for encryption, signing, or authentication within the Package Document format.
None.
This media type registration is for the EPUB Package Document, as described by the EPUB Publications 3.0 specification located at http://www.idpf.org/epub/30/spec/epub30-publications.html.
The EPUB Publications 3.0 specification supersedes the Open Packaging Format 2.0.1 specification, which is located at http://www.idpf.org/epub/20/spec/OPF_2.0.1_draft.htm and which also uses the application/oepbs-package+xml media type.
This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive.
Adobe Digital Editions
Aldiko
Azardi
Apple iBooks
Barnes & Noble Nook
Calibre
Google Books
Ibis Reader
MobiPocket reader
Sony Reader
Stanza
none
.opf
TEXT
The IDPF maintains a registry of linking schemes at http://www.idpf.org/epub/linking/. Some of these schemes define custom fragment identifiers that resolve to application/oebps-package+xml documents.
William McCoy, bmccoy@idpf.org
COMMON
International Digital Publishing Forum (http://www.idpf.org)
This section is non-normative.
EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.
The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:
Active members of the working group included:
For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].
[Authority Registry] EPUB Subject Authorities Registry.
[BCP 47] Tags for Identifying Languages; Matching of Language Tags. September 2009.
[CSS Snapshot] CSS Snapshot .
[Content Docs 3.1] EPUB Content Documents 3.1 .
[Core Media Types] EPUB 3 Core Media Types.
[DCTERMS] DCMI Metadata Terms .
[DateTime] Date and Time Formats . 15 September 1997.
[EPUB 3.1] EPUB 3.1 .
[EPUB Accessibility] EPUB Accessibility .
[HTML] HTML .
[ID Registry] EPUB Identifiers Registry.
[ISO Schematron] ISO/IEC 19757-3: Rule-based validation — Schematron . 2006-06-01.
[ISO8601] ISO 8601:2004 Data elements and interchange formats -- Information interchange -- Representation of dates and times . 2004-12-01.
[Link Vocab] EPUB Metadata Link Vocabulary .
[MARC Relators] MARC Code List for Relators.
[Manifest Vocab] EPUB Manifest Properties Vocabulary .
[Media Overlays 3.1] EPUB Media Overlays 3.1 .
[Media Queries] Media Queries .
[Meta Vocab] EPUB Meta Properties Vocabulary .
[NVDL] ISO/IEC 19757-4: NVDL (Namespace-based Validation Dispatching Language) . 2006-06-01.
[OCF 3.1] Open Container Format 3.1 .
[ONIX] ONIX for Books .
[OPF2] Open Packaging Format 2.0.1 .
[Publications 3.0.1] EPUB Publications 3.0.1 .
[RDFa 1.1] RDFa Core 1.1 - Second Edition . Syntax and processing rules for embedding RDF through attributes. 22 August 2013.
[RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (RFC 2046) . November 1996.
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.
[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . January 2005.
[RFC4839] Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) (RFC 4839) . April 2007.
[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG. Second Edition . 2008-12-15.
[Rendition Vocab] EPUB Package Rendering Vocabulary .
[Reserved Prefixes] EPUB Package Document Reserved Prefixes.
[Role Registry] EPUB Collection Roles Registry.
[SMIL] SMIL Version 3.0 . 01 December 2008.
[Spine Vocab] EPUB Spine Properties Vocabulary .
[Structure Vocab] EPUB 3 Structural Semantics Vocabulary .
[UAAG 2.0] User Agent Accessibility Guidelines 2.0 . 17 December 2002.
[Unicode] The Unicode Consortium. The Unicode Standard..
[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . 26 November 2008.
[XMLNS] Namespaces in XML (Third Edition) . 8 December 2009.
[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition . 28 October 2004.
[EPUB3 Changes] EPUB 3.1 Differences from EPUB 3.0.1 .
[EPUB3 Overview] EPUB 3.1 Overview .
[JSON-LD] JSON-LD 1.0: A JSON-based Serialization for Linked Data. 16 January 2014..
[Role Extensions] EPUB Collection Element Role Extensions.
[Types Registry] EPUB Publication Types Registry.