Copyright © 1999-2020 W3C ® ( MIT , ERCIM , Keio , Beihang ). W3C liability , trademark and permissive document license rules apply.
EPUB® 3 defines a distribution and interchange format for digital publications and documents. The EPUB format provides a means of representing, packaging and encoding structured and semantically enhanced Web content — including HTML, CSS, SVG and other resources — for distribution in a single-file container.
This specification defines the authoring requirements for EPUB Publications and represents the third major revision of the standard.
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 and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document was published by the EPUB 3 Working Group as an Editor's Draft.
GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-epub-wg@w3.org ( archives ).
Publication as an Editor's Draft does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 1 August 2017 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 15 September 2020 W3C Process Document .
EPUB 3 has been widely adopted as the format for digital books (ebooks), and this revision continues to increase the format's capabilities in order to better support a wider range of publication requirements, including complex layouts, rich media and interactivity, and global typography features. The expectation is that the EPUB 3 format will be utilized for a broad range of content, including books, magazines and educational, professional and scientific publications.
This specification represents the core of EPUB 3 and includes the conformance requirements for EPUB Publications — the product of the standard. The other specifications that comprise EPUB 3 are as follows:
EPUB 3 Reading Systems [ EPUB-RS-33 ] — defines the processing requirements for EPUB Reading Systems — the applications that consume EPUB Publications and present their content to users.
EPUB Accessibility [ EPUBAccessibility-10 ] — defines accessibility conformance and discovery requirements for EPUB Publications.
These specifications represent the formal list recognized as belonging to EPUB 3 and that contain functionality normatively referenced as part of the standard. New functionality is also added periodically through the development of extension specifications. Features and functionality defined outside of core revisions to the standard, while not formally recognized in this specification, are nonetheless available for use by Authors and Reading System developers.
The informative EPUB 3 Overview [ EPUB-OVERVIEW-33 ] provides a general introduction to EPUB 3. A list of technical changes from the previous version is also available in the change log .
An index to key concepts and definitions is also provided at the end of this specification.
This section is non-normative.
This section reviews the organization of the EPUB specifications through the central product they define: the EPUB Publication .
An EPUB Publication consists of one or more Renditions of its content, each of which is represented by what is called an EPUB Package . An EPUB Package consists of all the resources needed to render the content. The key file among these is the Package Document , which includes all the metadata used by Reading Systems to present the EPUB Publication to the user (e.g., the title and author for display in a bookshelf, as well rendering metadata such as whether content has a fixed layout or can be reflowed). It also provides a complete manifest of resources, and includes a spine that lists the sequence to render documents in as a user progresses through the content.
An EPUB Package also include another key file called the EPUB Navigation Document . This document provides critical navigation capabilities, such as the table of contents, that allow users to quickly and easily navigate the content.
The requirements for EPUB Packages are defined in § 3. EPUB Packages .
The
EPUB
Publication's
resources
are
bundled
for
distribution
in
a
ZIP-based
archive
with
the
file
extension
.epub
.
As
conformant
ZIP
archives,
EPUB
Publications
can
be
unzipped
by
many
software
programs,
simplifying
both
their
production
and
consumption.
The
container
format
not
only
provides
a
means
of
determining
that
the
zipped
content
represents
an
EPUB
Publication
(the
mimetype
file),
but
also
provides
a
universally-named
directory
of
informative
resources
(
/META-INF
).
Key
among
these
resources
is
the
container.xml
file,
which
directs
Reading
Systems
to
the
available
Package
Documents.
The
container
format
is
defined
in
§
5.
6.
Open
Container
Format
.
The structure and containment of an EPUB Publication is only one half of the format, the other half being the content that gets presented to users. This content is built on the Open Web Platform and comes in two flavours: XHTML and SVG . Called EPUB Content Documents , these documents typically reference many additional resources required for their proper rendering, such as images, audio and video clips, scripts and style sheets.
Detailed information about the rules and requirements for the production of EPUB Content Documents is provided in § 4. EPUB Content Documents , and accessibility requirements are defined in [ EPUBAccessibility-10 ].
Media
Overlay
Documents
complement
EPUB
Content
Documents.
They
provide
declarative
markup
for
synchronizing
the
text
in
EPUB
Content
Documents
with
prerecorded
audio.
The
result
is
the
ability
to
create
a
read-aloud
experience
where
text
is
highlighted
as
it
is
narrated.
Media
Overlay
Documents
are
defined
in
§
6.
7.
Media
Overlays
.
While conceptually simple, an EPUB Publication is more than just a collection of HTML pages and dependent assets in a ZIP package as presented here. Additional information about the primary features and functionality that EPUB Publications provide to enhance the reading experience is available from the referenced specifications, and a more general introduction to the features of EPUB 3 is provided in the informative [ EPUB-OVERVIEW-33 ].
The processing requirements for Reading Systems are defined in [ EPUB-RS-33 ]. Although it is not necessary that Authors read this document in order to create EPUB Publications, an understanding of how Reading Systems have to present the content can help craft publications for optimal presentation to users.
This section is non-normative.
The [ HTML ] standard is continuously evolving — there are no longer versioned releases of it. That standard, in turn, references various technologies that continue to evolve, such as MathML, SVG, CSS, and JavaScript.
The benefit of this approach for EPUB is that EPUB Publications always keep pace with changes to the Web without the need for new revisions. Authors, however, will need to keep track of the various changes to HTML and the technologies it references, and ensure that their processes are kept up to date.
As HTML evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. In general, however, features are typically only removed if serious issues with them arise (e.g., lack of support in browsers, security issues).
The XHTML profile defined by this specification inherits all definitions of semantics, structure and processing behaviors from HTML unless otherwise specified.
In addition, this specification defines a set of extensions to the [ HTML ] document model that Authors can include in XHTML Content Documents .
This specification does not reference a specific version of [ SVG ], but instead uses an undated reference. Whenever there is any ambiguity in this reference, the latest recommended specification is the authoritative reference.
This approach ensures that EPUB will always keep pace with changes to the SVG standard. Authors and Reading System developers will need to keep track of changes to the SVG standard, and ensure that their processes are kept up to date.
As SVG evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. It is anticipated that the W3C will make any such changes carefully to ensure minimal disruption for Authors, but in the case of a backwards-incompatible revision the use of an undated reference could be revisited.
EPUB 3 supports CSS as defined by the CSS Working Group Snapshot [ CSSSnapshot ]. EPUB 3 also maintains some prefixed CSS properties, to ensure consistent support for global languages.
This
specification
relies
on
a
subset
of
[
SMIL3
],
from
which
the
EPUB
Media
Overlays
elements
and
attributes
defined
in
§
6.2.2
7.2.2
Media
Overlay
Document
Definition
are
derived.
The following terms are specific to EPUB 3. They are capitalized wherever used.
Only the first instance of a term in a section is linked to its definition.
The person(s) or organization responsible for the creation of an EPUB Publication . The Author is not necessarily the creator of the content.
Codec refers to content that has intrinsic binary format qualities, such as video and audio media types which are already designed for optimum compression, or which provide optimized streaming capabilities.
The area within the Viewport dedicated to the display of EPUB Content Documents . The Content Display Area excludes any borders, margins, headers, footers or other decoration a EPUB Reading System might inject into the Viewport.
In the case of synthetic spreads , the Viewport contains two Content Display Areas.
A Publication Resource that does not require the provision of a fallback (cf. Foreign Resource ).
The
Rendition
listed
in
the
first
rootfile
element
in
the
container.xml
file.
The
ZIP-based
packaging
and
distribution
format
for
EPUB
Publications
defined
in
§
5.2
6.2
OCF
ZIP
Container
.
A Publication Resource with an XHTML or SVG media type that contains all or part of the content of an EPUB Publication (i.e., the textual, visual and/or audio content). These resources have to conform to their respective XHTML or SVG definitions to be used in the spine or be referenced from another EPUB Content Document.
An EPUB Content Document is a Core Media Type Resource , so can be included in the EPUB Publication without the provision of fallbacks .
A specialization of the XHTML Content Document that contains human- and machine-readable global navigation information. The EPUB Navigation Document conforms to the constraints expressed in § 3.4 EPUB Navigation Document .
A logical document entity consisting of a set of interrelated resources representing one Rendition of an EPUB Publication , as defined by a Package Document .
A collection of one or more Renditions that conform to this specification, packaged in an EPUB Container .
An EPUB Publication typically represents a single intellectual or artistic work, but this specification does not circumscribe the nature of the content.
A system that processes EPUB Publications for presentation to a user in a manner conformant with this specification.
The name of any type of file within an OCF Abstract Container , whether a directory or a file within a directory.
An
EPUB
Content
Document
directly
referenced
from
the
spine
that
has
been
designated
pre-paginated
in
the
Package
Document
,
as
defined
in
§
3.3.3.4.2
5.2.1
The
rendition:layout
Property
Layout
.
The
dimensions
to
use
for
rendering
Fixed-Layout
Documents
are
defined
in
§
4.5
5.
Fixed
Layouts
.
A Publication Resource that is not a Core Media Type Resource . Foreign Resources are subject to the fallback requirements defined in § 2.2.1.3 Foreign Resources .
A resource that is located inside the EPUB Container .
Refer to § 2.2.2 Resource Locations for media type specific rules for resource locations.
A list of all Publication Resources that constitute the given Rendition of a EPUB Publication .
Refer
to
§
3.2.2.4.1
The
manifest
Element
for
more
information.
An
XML
document
that
associates
the
XHTML
Content
Document
with
pre-recorded
audio
narration
in
order
to
provide
a
synchronized
playback
experience,
as
defined
in
§
6.
7.
Media
Overlays
.
A Publication Resource that describes one Rendition of an EPUB Publication , as defined in § 3.2 Package Document . The Package Document carries meta information about the Rendition, provides a manifest of resources and defines the default reading order.
Non-Codec refers to content types that benefit from compression due to the nature of their internal data structure, such as file formats based on character strings (for example, HTML, CSS, etc.).
The
OCF
Abstract
Container
defines
a
file
system
model
for
the
contents
of
the
OCF
ZIP
Container
,
as
defined
in
§
5.1
6.1
OCF
Abstract
Container
.
The
ZIP-based
packaging
and
distribution
format
for
EPUB
Publications,
as
defined
in
§
5.2
6.2
OCF
ZIP
Container
.
OCF ZIP Container and EPUB Container are synonymous.
For
a
given
directory
within
the
OCF
Abstract
Container
,
the
string
holding
all
directory
File
Name
in
the
full
path
concatenated
together
with
a
/
(
U+002F
)
character
separating
the
directory
File
Names.
For
a
given
file
within
the
OCF
Abstract
Container,
the
Path
Name
is
the
string
holding
all
directory
File
Names
concatenated
together
with
a
/
character
separating
the
directory
File
Names,
followed
by
a
/
character
and
then
the
File
Name
of
the
file.
A resource that contains content or instructions that contribute to the logic and rendering of at least one Rendition of an EPUB Publication . In the absence of this resource, the EPUB Publication might not render as intended by the Author . Examples of Publication Resources include a Rendition's Package Document , EPUB Content Document , CSS Style Sheets, audio, video, images, embedded fonts and scripts.
With the exception of the Package Document itself, the Publication Resources necessary to render a Rendition are listed in that Rendition's manifest and bundled in the EPUB Container file (unless specified otherwise in § 2.2.2 Resource Locations ).
Examples
of
resources
that
are
not
Publication
Resources
include
those
identified
by
the
Package
Document
link
element
and
those
identified
in
outbound
hyperlinks
that
resolve
to
Remote
Resources
(e.g.,
referenced
from
the
href
attribute
of
an
[
HTML
]
a
element).
The Release Identifier allows any instance of an EPUB Publication to be compared against another to determine if they are identical, different versions, or unrelated.
Refer
to
§
3.3.1.2
3.3.2
Release
Identifier
for
more
information.
A resource that is located outside of the EPUB Container , typically, but not necessarily, online.
Refer to § 2.2.2 Resource Locations for media type specific rules for resource locations.
One rendering of the content of an EPUB Publication , as expressed by an EPUB Package .
The root directory represents the base of the OCF Abstract Container file system. This directory is virtual in nature: a EPUB Reading System might or might not generate a physical root directory for the contents of the OCF Abstract Container if the contents are unzipped.
An EPUB Content Document that includes scripting or an XHTML Content Document that contains [ HTML ] forms .
Refer to § 4.4 Scripting for more information.
An ordered list of Publication Resources , typically EPUB Content Documents , representing the default reading order of the given Rendition of an EPUB Publication.
Refer
to
§
3.2.2.5.1
The
spine
Element
for
more
information.
An EPUB Content Document that conforms to the constraints expressed in § 4.2 SVG Content Documents .
The rendering of two adjacent pages simultaneously on a device screen.
The rendering of the textual content of an EPUB Publication as artificial human speech using a synthesized voice.
An EPUB Content Document referenced from the spine , whether directly or via a fallback chain .
The
Unique
Identifier
is
the
primary
identifier
for
an
EPUB
Publication
,
as
identified
by
the
unique-identifier
attribute
.
The
Unique
Identifier
can
be
shared
by
one
or
more
Renditions
of
the
same
EPUB
Publication.
Significant revision, abridgement, etc. of the content requires a new Unique Identifier.
The region of an EPUB Reading System in which an EPUB Publication is rendered visually to a user.
An EPUB Content Document that conforms to the profile of [ HTML ] defined in § 4.1 XHTML Content Documents .
XHTML Content Documents use the XHTML syntax defined in [ HTML ].
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY , MUST , MUST NOT , OPTIONAL , RECOMMENDED , REQUIRED , SHOULD , and SHOULD NOT in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.
In Package Document metadata examples, reserved prefixes are used without declaration.
For convenience, the following namespace prefixes [ XML-NAMES ] are used in this specification without explicitly being declared. To use any of these prefixes in an EPUB Content Document , a declaration is REQUIRED .
| prefix | URI |
|---|---|
epub
|
http://www.idpf.org/2007/ops
|
ssml
|
https://www.w3.org/2001/10/synthesis
|
The basic requirements for an EPUB Publication are that:
It MUST include one or more EPUB Packages .
It SHOULD conform to the accessibility requirements defined in [ EPUBAccessibility-10 ].
It MUST be packaged in an OCF Container .
Specific conformance details are covered in the rest of this specification.
Each Rendition of an EPUB Publication typically consists of many Publication Resources . These resources are divided into two categories: those that can be included without fallbacks ( Core Media Type Resources ) and those that cannot ( Foreign Resources ).
Formats are typically only included as Core Media Type Resources when it can be shown that they have broad support in web browser cores — the rendering engines on which EPUB 3 Reading Systems are built. They are an agreement between Reading System developers and Authors to ensure the predictability of rendering of EPUB Publications.
Inclusion as a Core Media Type Resource does not mean that all Reading Systems will support the rendering of a resource, however. Only Reading Systems that are capable of rendering the type of resource have to (e.g., a Reading System with a Viewport has to support image Core Media Type Resources, but a Reading System without a Viewport does not). Refer to Conformance Requirements [ EPUB-RS-33 ] for more information about which Reading Systems rendering capabilities require support for which Core Media Type Resources.
Foreign Resources come with no guarantee of rendering support, which is why they require a fallback to a Core Media Type Resource. EPUB Publications are designed to be fully consumable on any compliant Reading System, so providing a fallback is necessary to ensure that the use of Foreign Resources does not impact on the ability of the user to consume the content.
This section lists the set of Core Media Type Resources and identifies fallback mechanisms that can be used to satisfy the consumability requirement.
EPUB also exempts some [ HTML ] elements from support requirements (see § 4.1.4.5 Foreign Resource Restrictions ). Resources referenced from these elements are neither Core Media Type Resources nor Foreign Resources — they do not require fallbacks, but they also have no support requirements.
Publication Resources that conform to the following MIME media type [ RFC2046 ] specifications can be included in an EPUB Publication without fallbacks.
The columns in the following table represent the following information:
Media Type —The MIME media type [ RFC2046 ] used to represent the given Publication Resource in the manifest .
If more than one media type is listed, the first one is the preferred media type. The preferred media type is strongly encouraged for all new EPUB Publications.
| Media Type | Content Type Definition | Applies to |
|---|---|---|
| Images | ||
image/gif
|
[ GIF ] | GIF Images |
image/jpeg
|
[ JPEG ] | JPEG Images |
image/png
|
[ PNG ] | PNG Images |
image/svg+xml
|
SVG Content Documents | SVG documents |
| Audio | ||
audio/mpeg
|
[ MP3 ] | MP3 audio |
audio/mp4
|
[ MPEG4-Audio ], [ MP4 ] | AAC LC audio using MP4 container |
audio/opus
|
[ RFC7845 ] | OPUS audio using OGG container |
| Video | ||
| EPUB 3 allows any video codecs to be included without fallbacks, although none are technically considered Core Media Type Resources. Refer to the note in Conformance — General Requirements [ EPUB-RS-33 ] for informative recommendations on support for video codecs in EPUB Publications. | ||
| Style | ||
text/css
|
CSS Style Sheets | CSS Style Sheets. |
| Fonts | ||
| EPUB 3 allows any font resource to be included without a fallback, as CSS already defines fallback rules for fonts. Refer to the Reading System support requirements for fonts [ EPUB-RS-33 ] for more information. | ||
font/ttf
application/font-sfnt
|
[ TrueType ] | TrueType fonts |
font/otf
application/font-sfnt
application/vnd.ms-opentype
|
[ OpenType ] | OpenType fonts |
font/woff
application/font-woff
|
[ WOFF ] | WOFF fonts |
font/woff2
|
[ WOFF2 ] | WOFF2 fonts |
| Other | ||
application/xhtml+xml
|
XHTML Content Documents | XHTML Content Documents that use the XHTML syntax [ HTML ]. |
application/javascript
text/javascript
|
[ RFC4329 ] | Scripts. |
application/x-dtbncx+xml
|
[ OPF-201 ] | The legacy NCX. |
application/smil+xml
|
Media Overlays | EPUB Media Overlay documents |
application/pls+xml
|
[ PRONUNCIATION-LEXICON ] | Text-to-Speech (TTS) Pronunciation lexicons |
Although, OPUS/OGG has good support in Android, MacOS, Windows, and Linux, Apple, starting with iOS 11, only supports the OPUS codec in a CAF container. The working group will monitor support for OPUS in iOS, and may remove OPUS as a core media type if the level of support is inadequate.
Foreign
Resources
MAY
be
included
in
an
EPUB
Publication
without
a
fallback
provided
they
are
not
referenced
from
spine
itemref
elements
or
directly
rendered
in
their
native
format
in
EPUB
Content
Documents
(e.g.,
via
[
HTML
]
embedded
content
and
[
SVG
]
image
and
foreignObject
elements).
This exception allows Authors to include resources in the EPUB Container that are not for use by EPUB Reading Systems. The primary case for this exception is to allow data files to travel with an EPUB Publication, whether for use by scripts in its constituent EPUB Content Documents or for use by external applications (e.g., a scientific journal might include a data set with instructions on how to extract it from the EPUB Container).
When a Foreign Resource is included in the spine or directly rendered in its native format in an EPUB Content Document, a fallback Core Media Type Resource MUST be included. Fallbacks take one of the two following forms:
intrinsic fallback mechanisms provided by the host format (e.g., [ HTML ] elements often provide the ability to reference more than one media type or to display an alternate embedded message when a media type cannot be rendered);
Manifest
fallbacks
are
a
feature
of
the
Package
Document
that
create
fallback
chains
to
Core
Media
Type
Resources.
They
are
used
to
create
fallbacks
for
Foreign
Resources
in
the
spine
and
when
intrinsic
fallback
capabilities
are
not
available
(e.g.,
for
the
[
HTML
]
img
element).
Refer to the [ HTML ] and [ SVG ] specifications for the intrinsic fallback capabilities their elements provide.
All Publication Resources MUST be located in the EPUB Container , with the following exceptions:
Audio resources MAY be located outside the EPUB Container.
Video resources MAY be located outside the EPUB Container.
Resources retrieved by scripts MAY be located outside the EPUB Container.
Font resources MAY be located outside the EPUB Container.
Authors are encouraged to locate audio, video and script resources inside the EPUB Container whenever feasible to allow users access to the entire presentation regardless of connectivity status.
The rules in this section for Publication Resource locations apply regardless of whether the given resource is a Core Media Type Resource or a Foreign Resource .
The
inclusion
of
Remote
Resources
in
an
EPUB
Publication
is
indicated
via
the
remote-resources
property
on
the
manifest
item
element
.
Any Publication Resource that is an XML-Based Media Type has to meet the following constraints:
It MUST be a conformant XML 1.0 Document as defined in Conformance of Documents [ XML-NAMES ].
External identifiers MUST NOT appear in the document type declaration [ XML ].
It MUST NOT make use of XInclude [ XInclude ].
It MUST be encoded in UTF-8 or UTF-16 [ Unicode ].
The above constraints apply regardless of whether the given Publication Resource is a Core Media Type Resource or a Foreign Resource .
An EPUB Package has the following requirements:
It MUST contain exactly one Package Document , including all content requirements defined in § 3.2 Package Document .
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 [ RFC3987 ]) and describes (via MIME media type [ RFC4839 ]) 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.
All
[
XML
]
elements
defined
in
this
section
are
in
the
http://www.idpf.org/2007/opf
namespace
[
XML-NAMES
]
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.
package
Element
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]
bindings
[0
or
1]
(deprecated)
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.0
"
to
indicate
conformance
with
EPUB
3.
Updates
to
this
specification
do
not
represent
new
versions
of
EPUB
3
(i.e.,
each
new
3.X
specification
is
a
continuation
of
the
EPUB
3
format).
The
working
group
is
committed
to
minimizing
any
changes
that
would
invalidate
existing
content,
allowing
the
version
attribute
value
to
remain
unchanged.
The
unique-identifier
attribute
takes
an
IDREF
[
XML
]
that
identifies
the
dc:identifier
element
that
provides
the
preferred,
or
primary,
identifier.
Refer
to
§
3.3.1
3.3
Publication
Identifiers
for
more
information.
The
prefix
attribute
provides
a
declaration
mechanism
for
prefixes
not
reserved
by
this
specification
.
Refer
to
§
3.3.2.4
C.1.4
The
prefix
Attribute
for
more
information.
metadata
Element
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
(e.g.,
that
conform
to
an
international
standard
such
as
[
ONIX
]
or
are
created
for
custom
purposes)
can
be
associated
using
the
link
element.
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
[
DC11
]
title
,
identifier
and
language
elements
together
with
the
[
DCTERMS
]
modified
property
.
All
other
metadata
is
OPTIONAL
.
The
meta
element
provides
a
generic
mechanism
for
including
metadata
properties
from
any
vocabulary.
It
is
typically
used
to
include
rendering
metadata
defined
in
EPUB
specifications,
but
MAY
be
used
for
any
metadata
purposes.
See [ EPUBAccessibility-10 ] for accessibility metadata recommendations.
identifier
Element
The
[
DC11
]
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]
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 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
§
3.3.1.2
3.3.2
Release
Identifier
.
Whenever a Rendition is modified, it MUST include a new last modified date.
The
identifier-type
property
is
used
to
indicate
that
an
identifier
conforms
to
an
established
system
or
has
been
granted
by
an
issuing
authority.
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 encouraged that the identifier be a fully qualified URI, however.
title
Element
The
[
DC11
]
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
.
Text
The
metadata
section
MUST
include
at
least
one
title
element
containing
the
title
for
the
EPUB
Publication.
The
first
title
element
in
document
order
is
the
main
title
of
the
EPUB
Publication
(i.e.,
the
primary
one
to
present
to
users).
The title for each Rendition MAY differ.
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.
language
Element
The
[
DC11
]
language
element
specifies
the
language
of
the
content
of
the
given
Rendition
.
This
value
is
not
inherited
by
the
individual
resources
of
the
Rendition.
dc:language
http://purl.org/dc/elements/1.1/
REQUIRED
child
of
metadata
.
Repeatable.
id
[optional]
Text
The
metadata
section
MUST
include
at
least
one
language
element
with
a
value
conforming
to
[
BCP47
].
Additional
language
elements
MAY
be
included
for
multilingual
Publications,
but
each
element's
value
MUST
conform
to
[
BCP47
].
The
first
language
element
in
document
order
is
considered
the
primary
language
of
the
rendition.
Languages for each Rendition MAY differ.
With
the
exception
of
identifier
,
language
and
title
,
all
other
[
DC11
]
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.
Text
The OPTIONAL [ DC11 ] metadata for each Rendition MAY differ.
The value of all OPTIONAL [ DC11 ] elements MUST be at least one character in length after white space has been trimmed.
This specification does not modify the [ DC11 ] element definitions except as noted in the following sections.
contributor
Element
The
[
DC11
]
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.
creator
Element
The
[
DC11
]
creator
element
represents
the
name
of
a
person,
organization,
etc.
responsible
for
the
creation
of
the
content
of
the
Rendition
.
The
role
property
can
be
attached
to
the
element
to
indicate
the
function
the
creator
played
in
the
creation
of
the
content.
The
creator
element
SHOULD
contain
the
name
of
the
creator
as
the
Author
intends
it
to
be
displayed
to
a
user.
The
file-as
property
MAY
be
attached
to
include
a
normalized
form
of
the
name,
and
the
alternate-script
property
to
represent
a
creator's
name
in
another
language
or
script.
If
an
EPUB
Publication
has
more
than
one
creator,
each
SHOULD
be
included
in
a
separate
creator
element.
The
document
order
of
creator
elements
in
the
metadata
section
determines
the
display
priority,
where
the
first
creator
element
encountered
is
the
primary
creator.
Secondary
contributors
SHOULD
be
represented
using
the
contributor
element
.
date
Element
The
[
DC11
]
date
element
MUST
only
be
used
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.
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.
subject
Element
The
[
DC11
]
subject
element
identifies
the
subject
of
the
EPUB
Publication.
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.
Authors
MAY
identify
the
system
or
scheme
the
element's
value
is
drawn
from
using
the
authority
property
.
When
a
scheme
is
identified,
a
subject
code
MUST
be
attached
using
the
term
property
.
The
term
property
MUST
NOT
be
attached
to
a
subject
element
that
does
not
specify
a
scheme.
The
values
of
the
subject
element
and
term
property
are
case
sensitive
only
when
the
designated
scheme
requires.
type
Element
The
[
DC11
]
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).
An informative registry of specialized EPUB Publication types for use with this element is maintained in the [ TypesRegistry ], but Authors MAY use any text string as a value.
meta
Element
The
meta
element
provides
a
generic
means
of
including
package
metadata.
meta
As
child
of
the
metadata
element.
Repeatable.
Text
Each
meta
element
defines
a
metadata
expression.
The
property
attribute
takes
a
property
data
type
value
that
defines
the
statement
being
made
in
the
expression,
and
the
text
content
of
the
element
represents
the
assertion.
(Refer
to
§
3.3.2
C.1
Vocabulary
Association
Mechanisms
for
more
information.)
This
specification
defines
two
types
of
metadata
expressions
that
can
be
defined
using
the
meta
element:
meta
element
establishes
some
aspect
of
the
EPUB
Publication
.
A
meta
element
that
omits
a
refines
attribute
defines
a
primary
expression.
meta
element
enhances
the
meaning
of
the
expression
or
resource
referenced
in
its
refines
attribute.
A
subexpression
might
refine
a
media
clip,
for
example,
by
expressing
its
duration,
or
refine
a
creator
or
contributor
expression
by
defining
the
role
of
the
person.
Subexpressions are not limited to refining only primary expressions and resources; they may be used to refine the meaning of other subexpressions, thereby creating chains of information.
All of the DCMES [ DC11 ] elements represent primary expressions, and permit refinement by meta element subexpressions.
This
specification
reserves
the
The
Meta
Properties
Vocabulary
is
the
default
vocabulary
for
use
with
the
property
attribute.
Terms
from
other
vocabularies
If
the
attribute's
value
does
not
include
a
prefix,
the
following
IRI
[
RFC3987
]
stem
MAY
MUST
be
used
provided
they
have
a
prefix
(refer
to
generate
the
resulting
IRI:
http://idpf.org/epub/vocab/package/meta/#
Authors
MAY
add
terms
from
other
vocabularies
as
defined
in
§
3.3.2.3
C.1
Reserved
Prefixes
for
a
list
of
prefixes
that
do
not
have
to
be
declared).
Vocabulary
Association
Mechanisms
.
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
value
that
resolves
to
the
resource
that
defines
the
scheme.
Every
meta
element
MUST
express
a
value
that
is
at
least
one
character
in
length
after
white
space
normalization.
link
Element
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]
refines
[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 be a Core Media Type Resource (e.g., an EPUB Content Document could contain a metadata record serialized as [ RDFA-CORE ] or [ JSON-LD ]).
Linked resources MAY be located locally or remotely , but Authors need to be aware that Reading Systems are not required to retrieve to Remote Resources (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
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
list
of
reserved
relationships
and
properties
recognized
by
this
specification
is
defined
in
the
EPUB
Metadata
Link
Vocabulary
.
is
the
default
vocabulary
for
the
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/#
Authors
MAY
add
relationships
and
properties
from
other
vocabularies
via
the
metadata
extensibility
mechanism
as
defined
in
this
specification.
Authors
also
MAY
create
new
values
by
defining
their
own
prefixes
.
Refer
to
§
3.3.2
C.1
Vocabulary
Association
Mechanisms
for
more
information.
.
Linked records are only intended to enhance the information available to Reading Systems, and the package metadata typically contains important rendering information.
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.
manifest
Element
The
manifest
element
provides
an
exhaustive
list
of
the
Publication
Resources
that
constitute
the
given
Rendition
,
each
represented
by
an
item
element.
All
Publication
Resources
associated
with
the
Package
MUST
be
listed
in
the
manifest
.
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.
item
Element
The
item
element
represents
a
Publication
Resource
.
item
As
a
child
of
manifest
.
Repeatable.
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,
the
IRI
of
the
Package
Document
is
used
as
the
base
when
resolving
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
§
2.2.2
Resource
Locations
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
§
2.2.1.2
Supported
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
§
3.2.2.4.3
Manifest
Fallbacks
.
This
specification
reserves
the
The
EPUB
Manifest
Properties
Vocabulary
is
the
default
vocabulary
for
use
with
the
properties
attribute.
Terms
from
other
vocabularies
If
any
of
the
attribute's
values
do
not
include
a
prefix,
the
following
IRI
[
RFC3987
]
stem
MAY
MUST
be
used
provided
they
have
a
prefix
(refer
to
generate
the
resulting
IRI
for
them:
http://idpf.org/epub/vocab/package/item/#
Authors
MAY
add
terms
from
other
vocabularies
as
defined
in
§
3.3.2.3
C.1
Reserved
Prefixes
for
a
list
of
prefixes
that
do
not
have
to
be
declared).
Vocabulary
Association
Mechanisms
.
Authors MUST declare all applicable descriptive metadata properties for each Publication Resource in this attribute.
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
§
6.3.5
7.3.5
Packaging
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
>
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.
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.
User
agents
MUST
terminate
the
fallback
chain
at
the
first
reference
to
a
manifest
item
that
has
already
been
encountered.
Fallbacks MAY also be provided for Top-Level Content Documents that are EPUB Content Documents. An example of when this feature can be utilized is when providing fallbacks for scripted content .
bindings
Element
(Deprecated)
The
bindings
element
defines
a
set
of
custom
handlers
for
media
types
not
supported
by
this
specification.
Its
use
is
deprecated
.
Refer to [ EPUBPublications-301 ] for more information about this element.
spine
Element
The
spine
element
defines
an
ordered
list
of
manifest
item
references
that
represent
the
default
reading
order
of
the
given
Rendition
.
spine
id
[optional]
page-progression-direction
[optional]
itemref
[1
or
more]
The
spine
MUST
include
at
least
one
Publication
Resource
.
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
in
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.
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
can
also
provide
mechanisms
to
override
the
default
direction
(e.g.,
buttons
or
settings
that
allow
the
application
of
alternate
style
sheets).
The
legacy
toc
attribute
takes
an
IDREF
[
XML
]
that
identifies
the
manifest
item
that
represents
the
NCX
.
itemref
Element
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.
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
The
EPUB
Spine
Properties
Vocabulary
is
the
default
vocabulary
for
use
with
the
properties
attribute.
Terms
from
If
any
other
vocabulary
of
the
attribute's
values
do
not
include
a
prefix,
the
following
IRI
[
RFC3987
]
stem
MAY
MUST
be
used
provided
they
have
a
prefix
(refer
to
Reserved
Prefixes
generate
the
resulting
IRI
for
a
list
of
prefixes
that
do
not
have
to
be
declared).
them:
http://idpf.org/epub/vocab/package/itemref/#
Authors MAY add terms from other vocabularies as defined in § C.1 Vocabulary Association Mechanisms .
All applicable descriptive metadata properties defined in the Spine Properties Vocabulary SHOULD be declared.
collection
Element
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
EPUB
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
[
XMLSCHEMA-2
]
and/or
absolute
IRIs
[
RFC3987
].
The
use
of
NMTOKEN
values
is
reserved
for
roles
not
defined
in
EPUB,
which
are
maintained
in
the
[
RoleRegistry
].
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
[
RoleExtensions
].
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.
All
primary
metadata
expressions
apply
to
the
collection
.
The
refines
attribute
MUST
NOT
reference
elements
outside
the
containing
collection
.
The
OPF2
meta
element
MUST
NOT
be
included.
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
without
a
prefix
(e.g.,
so
that
a
collection
can
declare
its
own
Navigation
Document
or
cover
image).
The
refines
attribute
MUST
NOT
be
attached.
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
.
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.
meta
Element
The
meta
element
[
OPF-201
]
is
a
legacy
feature
that
previously
provided
a
means
of
including
generic
metadata.
It
is
replaced
in
EPUB
3
by
the
updated
meta
element
,
which
uses
different
attributes
and
requires
text
content.
For
more
information
about
the
meta
element,
refer
to
its
definition
in
[
OPF-201
].
guide
Element
The
guide
element
[
OPF-201
]
is
a
legacy
feature
that
previously
provided
machine-processable
navigation
to
key
structures
in
an
EPUB
Publication
.
It
is
replaced
in
EPUB
3
by
landmarks
in
the
EPUB
Navigation
Document
.
For
more
information
about
the
guide
element,
refer
to
its
definition
in
[
OPF-201
].
The NCX [ OPF-201 ] is a legacy feature that previously provided the table of contents for EPUB Publications . It is replaced in EPUB 3 by the EPUB Navigation Document .
For more information about the NCX, refer to its definition in [ OPF-201 ].
The
Package
Document
filename
SHOULD
use
the
file
extension
.opf
.
Package
Documents
have
the
MIME
media
type
application/oebps-package+xml
[
RFC4839
].
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.
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
[
XMLSCHEMA-2
]
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.
Additional
modified
properties
MAY
be
included
in
the
package
metadata,
but
they
MUST
have
a
different
subject
(i.e.,
they
require
a
refines
attribute
that
references
an
element
or
resource).
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.
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 defines a profile of [ HTML ] for creating XHTML Content Documents. An instance of an XML document that conforms to this profile is a Core Media Type Resource and is referred to in this specification as an XHTML Content Document .
Unless otherwise specified, this specification inherits all definitions of semantics, structure and processing behaviors from the [ HTML ] specification.
An XHTML Content Document has to meet the following basic requirements:
It MUST be an [ HTML ] document that conforms to the XHTML syntax.
It MUST conform to the conformance criteria for all document constructs defined by [ HTML ] unless explicitly overridden in § 4.1.4 HTML Deviations and Constraints .
It MAY include extensions to the [ HTML ] grammar as defined in § 4.1.3 HTML Extensions , and MUST conform to all content conformance constraints defined therein.
The recommendation that EPUB Publications follow the accessibility requirements in [ EPUBAccessibility-10 ] applies to XHTML Content Documents. See Accessibility .
This section defines EPUB 3 XHTML Content Document extensions to the underlying [ HTML ] document model.
Although [ HTML ] allows user agents to support vendor-neutral extensions , unless such extensions are listed in this section they are not supported features of EPUB 3.
Semantic
inflection
is
the
process
of
attaching
additional
meaning
about
the
specific
purpose
and/or
nature
an
element
plays
in
an
XHTML
Content
Document
.
The
epub:type
attribute
is
used
to
express
domain-specific
semantics
in
XHTML
Content
Documents,
with
the
inflection(s)
it
carries
complementing
the
underlying
[
HTML
]
vocabulary.
The
applied
semantics
are
intended
to
refine
the
meaning
of
their
containing
elements;
they
are
not
provided
to
override
their
nature
(e.g.,
the
attribute
can
be
used
to
indicate
a
section
is
a
chapter
in
a
work,
but
is
not
designed
to
turn
p
elements
into
list
items
to
avoid
proper
list
structures).
Semantic
metadata
is
intended
to
enrich
content
for
use
in
publishing
workflows
and
for
author-defined
purposes.
While
it
also
allows
Reading
Systems
to
learn
more
about
the
structure
and
content
of
a
document,
no
specific
behaviors
are
defined
for
the
semantics
by
this
specification.
Any
such
behaviors
are
Reading
System-dependent.
This
specification
defines
a
method
for
semantic
inflection
using
the
attribute
axis
:
instead
of
adding
new
elements,
the
epub:type
attribute
can
be
appended
to
existing
elements
to
inflect
the
desired
semantics.
A
mechanism
to
identify
external
vocabularies
that
provide
controlled
values
for
the
attributes
is
also
defined.
4.1.3.1.2
The
epub:type
Attribute
Attribute
Name
type
Namespace
http://www.idpf.org/2007/ops
Usage
Global
attribute
.
MAY
be
specified
on
all
elements.
Value
A
white
space-separated
list
of
property
values,
with
restrictions
as
defined
in
§
4.1.3.1.3
Vocabulary
Association
.
White
space
is
the
set
of
characters
as
defined
used
in
[
XML
XHTML
Content
Documents
].
The
epub:type
attribute
inflects
semantics
on
the
element
on
which
it
appears.
Its
value
is
one
or
more
white
space-separated
terms
stemming
from
external
vocabularies
associated
with
the
document
instance,
as
defined
in
§
4.1.3.1.3
Vocabulary
Association
.
The
inflected
semantic
MUST
to
express
a
subclass
of
the
semantic
of
the
carrying
element.
In
the
case
of
semantically
neutral
elements,
such
as
the
[
HTML
]
div
and
span
elements,
the
inflected
semantic
MUST
NOT
attach
a
meaning
that
is
already
conveyed
by
an
existing
element
(e.g.,
that
a
div
represents
a
paragraph
or
section).
structural
semantics.
As
the
[
HTML
]
head
element
contains
metadata
for
the
document,
structural
semantics
expressed
on
this
element
or
any
descendant
of
it
have
no
meaning.
The
[
Microdata
]
and
[
RDFA-CORE
]
specifications
both
define
sets
specification
defines
a
set
of
attributes
that
can
be
used
in
XHTML
Content
Documents
to
semantically
enrich
the
content.
The
use
of
[
RDFA-CORE
]
attributes
is
allowed
in
XHTML
Content
Documents
,
but
any
usage
MUST
conform
to
the
requirements
defined
in
[
HTML-RDFA
].
The [ RDFA-CORE ] specification defines changes to the [ HTML ] content model when RDFa attributes are used. This modified content model is valid in XHTML Content Documents.
The
use
of
[
Microdata
]
specification
defines
a
set
of
attributes
is
allowed
that
can
be
used
in
XHTML
Content
Documents
,
but
any
usage
to
semantically
enrich
the
content.
The use of [ Microdata ] attributes MUST conform to the requirements defined in that specification.
The [ Microdata ] specification defines changes to the [ HTML ] content model when Microdata attributes are used. This modified content model is valid in XHTML Content Documents.
The W3C Speech Synthesis Markup Language [ SSML ] is a language used for assisting Text-to-Speech (TTS) engines in generating synthetic speech. Although SSML is designed as a standalone document type, it also defines semantics suitable for use within other markup languages.
This
specification
recasts
the
[
SSML
]
phoneme
element
as
two
attributes
—
ssml:ph
and
ssml:alphabet
—
and
makes
them
available
within
XHTML
Content
Documents.
Reading Systems with Text-to-Speech (TTS) capabilities SHOULD support the SSML Attributes as defined below.
For more information on EPUB 3 features related to synthetic speech, refer to Text-to-speech [ EPUB-OVERVIEW-33 ].
ssml:ph
attribute
The
ssml:ph
attribute
specifies
a
phonemic/phonetic
pronunciation
of
the
text
represented
by
the
element
to
which
the
attribute
is
attached.
ph
https://www.w3.org/2001/10/synthesis
Global attribute . MAY be specified on all elements with which a phonetic equivalent can logically be associated (e.g., elements that contain textual information).
MUST NOT be specified on a descendant of an element that already carries this attribute.
A phonemic/phonetic expression, syntactically valid with respect to the phonemic/phonetic alphabet being used .
This
attribute
inherits
all
the
semantics
of
the
[
SSML
]
phoneme
element
ph
attribute,
with
the
following
addition:
When
the
ssml:ph
attribute
appears
on
an
element
that
has
text
node
descendants,
the
corresponding
document
text
to
which
the
pronunciation
applies
is
the
string
that
results
from
concatenating
the
descendant
text
nodes,
in
document
order.
The
specified
phonetic
pronunciation
MUST
therefore
logically
match
the
element's
textual
data
in
its
entirety
(i.e.,
not
just
an
isolated
part
of
its
content).
ssml:alphabet
attribute
The
ssml:alphabet
attribute
specifies
which
phonemic/phonetic
pronunciation
alphabet
is
used
in
the
value
of
the
ssml:ph
attribute.
alphabet
https://www.w3.org/2001/10/synthesis
Global attribute . MAY be specified on any element.
The
name
of
the
pronunciation
alphabet
used
in
the
value
of
ssml:ph
(inherited).
This
attribute
inherits
all
the
semantics
of
the
[
SSML
]
phoneme
element
alphabet
attribute,
with
the
following
addition:
The
value
of
the
ssml:alphabet
attribute
is
inherited
in
the
document
tree.
The
pronunciation
alphabet
used
in
a
given
ssml:ph
attribute
value
is
determined
by
locating
the
first
occurrence
of
the
ssml:alphabet
attribute
starting
with
the
element
on
which
the
ssml:ph
attribute
appears,
followed
by
the
nearest
ancestor
element.
Although the [ SSML ] specification makes reference to a registry of alphabets, one has not been published. As the charter of the W3C Voice Browser Working Group has expired, the publication of such a registry is not anticipated. Authors therefore need to reference Reading System support documentation to determine what alphabet values are supported. Some common alphabets include: x-JEITA (also x-JEITA-IT-4002 and x-JEITA-IT-4006) and x-sampa.
The
switch
element
provides
a
simple
mechanism
through
which
Authors
can
tailor
the
content
displayed
to
users,
one
that
is
not
dependent
on
the
scripting
capabilities
of
the
EPUB
Reading
System
.
Use
of
the
switch
element
is
deprecated
.
Refer
to
its
definition
in
[
EPUBContentDocs-301
]
for
usage
information.
epub:trigger
Element
(Deprecated)
The
trigger
element
enables
the
creation
of
markup-defined
user
interfaces
for
controlling
multimedia
objects,
such
as
audio
and
video
playback,
in
both
scripted
and
non-scripted
contexts.
Use
of
the
trigger
element
is
deprecated
.
Refer
to
its
definition
in
[
EPUBContentDocs-301
]
for
usage
information.
Reading Systems can introduce functionality not defined in this specification to enhance the rendering of EPUB Publications . The allowance of custom attributes in XHTML Content Documents is designed to facilitate this experimentation.
Custom attributes MAY be included on any element in an XHTML Content Document provided such attributes are from a foreign namespace, which is defined as a namespace [ XML-NAMES ] that does not map to either of the following URIs:
http://www.w3.org/1999/xhtml
http://www.idpf.org/2007/ops
Custom attributes, and the behaviors associated with them, MUST NOT alter the integrity of an EPUB Publication. The content MUST remain consumable by a user without any information loss or other significant deterioration, regardless of the Reading System it is rendered on.
This section defines deviations from, and constraints on, the underlying [ HTML ] document model applicable to EPUB 3 XHTML Content Documents .
XHTML Content Documents support embedded [ MATHML3 ]. Occurrences of MathML markup MUST conform to the constraints expressed in the MathML specification [ MATHML3 ], with the following additional restrictions:
The
math
element
MUST
contain
only
Presentation
MathML
,
with
the
exception
of
the
annotation-xml
element.
Content
MathML
MAY
be
included
within
MathML
markup
in
XHTML
Content
Documents,
and,
when
present,
MUST
occur
within
an
annotation-xml
child
element
of
a
semantics
element.
When
Content
MathML
is
included
as
per
the
previous
condition,
the
given
annotation-xml
element's
encoding
attribute
MUST
be
set
to
either
of
the
functionally-equivalent
values
MathML-Content
or
application/mathml-content+xml
,
and
its
name
attribute
MUST
be
set
to
contentequiv
.
Elements and attributes marked as deprecated in [ MATHML3 ] MUST NOT be included within MathML markup in XHTML Content Documents.
This subset is designed to ease the implementation burden on Reading Systems and to promote accessibility, while retaining compatibility with [ HTML ] user agents.
The
mathml
property
of
the
manifest
item
element
indicates
that
an
XHTML
Content
Document
contains
embedded
MathML.
XHTML
Content
Documents
support
the
embedding
of
SVG
document
fragments
[
SVG
]
by
reference
(embedding
via
reference,
for
example,
from
an
img
or
object
element)
and
by
inclusion
(embedding
via
direct
inclusion
of
the
svg
element
in
the
XHTML
Content
Document).
The content conformance constraints for SVG embedded in XHTML Content Documents are the same as defined for SVG Content Documents in § 4.2.3 Restrictions on SVG .
The
svg
property
of
the
manifest
item
element
indicates
that
an
XHTML
Content
Document
contains
embedded
SVG.
This section lists restrictions on the Unicode character repertoire.
Any included characters that map to a code point within one of the Private Use Area (PUA) ranges as defined in [ Unicode ] MUST occur within a string that is styled or attributed in a manner that includes a reference to an embedded font [ CSS-Fonts-3 ] that contains an appropriate glyph for that code point.
This section is non-normative.
rp
Element
The
[
HTML
]
rp
element
is
intended
to
provide
a
fallback
for
older
Reading
Systems
that
do
not
recognize
ruby
markup
(i.e.,
a
parenthesis
display
around
ruby
markup).
As
EPUB
3
Reading
Systems
are
ruby-aware,
and
can
provide
fallbacks,
the
use
of
rp
elements
is
discouraged.
embed
Element
Since
the
[
HTML
]
embed
element
does
not
include
intrinsic
facilities
to
provide
fallback
content
for
Reading
Systems
that
do
not
support
scripting,
Authors
are
discouraged
from
using
the
element
when
the
referenced
resource
includes
scripting.
The
[
HTML
]
object
element
can
be
used
instead,
as
it
includes
intrinsic
fallback
capabilities.
Foreign Resources MAY be referenced from elements that have intrinsic fallback mechanisms, where an intrinsic fallback method is the capability to offer an alternative presentation if the foreign resource is not supported. For example, most [ HTML ] embedded content elements provide options for alternative rendering, such as allowing multiple sources to be specified or allowing embedded HTML content for when a resource cannot be rendered. A Core Media Type Resource or embedded HTML content MUST be provided via the given element's intrinsic fallback mechanism when a Foreign Resource is referenced.
[
HTML
]
flow
content
MAY
be
embedded
within
the
audio
and
video
elements
for
rendering
in
older
Reading
Systems
that
do
not
recognize
these
elements
(e.g.,
EPUB
2
Reading
Systems),
but
it
does
not
represent
a
fallback
Core
Media
Type
Resource.
Due
to
the
variety
of
sources
that
can
be
associated
with
to
the
[
HTML
]
img
element
,
the
following
fallback
conditions
apply
to
its
use:
If
it
is
the
child
of
a
picture
element
:
src
and
srcset
attributes,
when
those
attributes
are
specified;
and
source
element
MUST
reference
a
Core
Media
Type
Resource
from
its
src
and
srcset
attributes
unless
it
specifies
a
media
type
in
its
type
attribute
that
is
not
a
Core
Media
Type.
src
and
srcset
attributes
provided
manifest
fallbacks
are
defined.
The following [ HTML ] elements can refer to Foreign Resources without having to provide a fallback Core Media Type Resource:
link
—
when
its
rel
attribute
has
the
value
"
pronunciation
"
Foreign Resources MAY be referenced from the preceding three elements without the provision of a fallback Core Media Type Resource.
Refer
to
manifest
fallbacks
for
the
provision
of
fallbacks
for
elements
without
intrinsic
mechanisms,
such
as
the
[
HTML
]
iframe
.
Some features of [ SVG ] are not fully supported in Reading Systems , or supported across all platforms on which Reading Systems run. When utilizing such features, Authors need to consider the inherent risks in terms of the potential impact on interoperability and document longevity.
This section is non-normative.
The Scalable Vector Graphics (SVG) specification [ SVG ] defines a format for representing final-form vector graphics and text.
Although an EPUB Publication typically uses XHTML Content Documents as the top-level document type, the use of SVG Content Documents is also permitted. SVGs are typically only used in certain special circumstances, such as when final-form page images are the only suitable representation of the content (e.g., for cover art or in the context of manga or comic books).
This section defines a profile for [ SVG ] documents. An instance of an XML document that conforms to this profile is a Core Media Type Resource and is referred to in this specification as an SVG Content Document .
This section defines conformance requirements for SVG Content Documents . Refer to § 4.1.4.2 Embedded SVG for the conformance requirements for SVG embedded in XHTML Content Documents.
An SVG Content Document has to meet the following requirements:
It MUST be an SVG document fragment [ SVG ], and conform to all content conformance constraints expressed in § 4.2.3 Restrictions on SVG .
It
MAY
include
the
epub:type
attribute
for
semantic
inflection
,
and
use
all
applicable
vocabulary
association
mechanisms
for
that
attribute.
It
SHOULD
use
the
file
extension
.svg
.
The recommendation that EPUB Publications follow the accessibility requirements in [ EPUBAccessibility-10 ] applies to SVG Content Documents. See Accessibility .
This specification restricts the content model of SVG Content Documents and SVG embedded in XHTML Content Documents as follows:
The
[
SVG
]
foreignObject
element
MUST
adhere
to
the
following
criteria:
It
MUST
contain
either
[
HTML
]
flow
content
or
exactly
one
[
HTML
]
body
element
.
In
the
case
of
embedded
SVGs
,
a
body
element
is
not
permitted
per
the
restrictions
on
SVG
defined
in
[
HTML
].
Its content MUST be a valid document fragment that conforms to the XHTML Content Document model defined in § 4.1.2 XHTML Requirements .
Its
requiredExtensions
attribute,
if
given,
MUST
be
set
to
"
http://www.idpf.org/2007/ops
".
The
[
SVG
]
title
element
MUST
contain
only
valid
XHTML
Content
Document
Phrasing
content
.
This section is non-normative.
CSS is an integral part of the Open Web Platform. Readers, publishers, and document authors expect CSS to "just work," as they expect HTML to just work.
In the past, EPUB defined a profile of CSS that mandated support for certain properties and provided prefixed versions of numerous other properties. Although the CSS Working Group no longer recommends the use of prefixed properties, this specification has to maintain some prefixed properties to avoid breaking existing content. But with the minor exceptions defined in this section, EPUB defers to the W3C to define CSS.
Keep in mind that some Reading Systems will not support all desired features of CSS. In particular, the following are known to be problematic:
Reading System-induced pagination can interact poorly with style sheets. Pagination is sometimes done using columns, which can result in incorrect values for viewport sizes. Fixed and absolute positioning are particularly problematic.
Some types of screens will render animations and transitions poorly (e.g., those with high latency).
A CSS style sheets has to meet the following requirements:
It MAY include any CSS properties, with the following exceptions:
It
MUST
NOT
use
the
direction
property
[
CSS-Writing-Modes-3
].
Use
the
[
HTML
]
dir
attribute
to
set
the
inline
base
direction.
It
MUST
NOT
use
the
unicode-bidi
property
[
CSS-Writing-Modes-3
].
Use
[
HTML
]
bdo
elements
and
dir
attributes
to
control
bidirectionality.
It MAY include the prefixed properties defined in § 4.3.3 Prefixed Properties .
It MUST be encoded in UTF-8 or UTF-16 [ Unicode ].
Authors are strongly encouraged to use unprefixed properties, and Reading Systems to support current CSS specifications. The widely-used prefixed properties from [ EPUBContentDocs-301 ] have been retained, but support for the other properties has been removed. Authors are advised to use CSS-native solutions for the removed properties where and when they are available.
Authors currently using these prefixed properties are advised to move to unprefixed versions as soon as support allows, as these properties are not anticipated to be supported in the next major version of EPUB.
The
following
table
lists
the
-epub-
prefixed
properties
for
[
CSS-Writing-Modes-3
].
The
Value
column
indicates
the
value
the
property
accepts.
The
Prior
EPUB
Mapping
column
indicates
values/properties
that
were
used
in
previous
versions
of
EPUB
3.
An
asterisk
(*)
denotes
that
the
older
property
or
value
is
now
deprecated.
The
final
column
describes
how
to
implement
the
prefixed
property
based
on
[
CSS-Writing-Modes-3-20151215
].
| Property | Value | Prior EPUB Mapping | Mapping to [ CSS-Writing-Modes-3-20151215 ] |
|---|---|---|---|
-epub-text-orientation
|
upright
|
upright
|
upright
|
-epub-text-orientation
|
mixed
|
vertical-right
*
|
mixed
|
-epub-text-orientation
|
sideways-right
|
sideways-right
|
sideways
|
-epub-text-orientation
|
sideways-right
|
rotate-right
*
|
sideways
|
-epub-text-orientation
|
sideways
|
rotate-normal
*
|
sideways
|
-epub-text-orientation
|
sideways
|
sideways
|
sideways
|
-epub-text-orientation
|
mixed
|
mixed
|
mixed
|
-epub-writing-mode
|
horizontal-tb
|
horizontal-tb
|
horizontal-tb
|
-epub-writing-mode
|
vertical-rl
|
vertical-rl
|
vertical-rl
|
-epub-writing-mode
|
vertical-lr
|
vertical-lr
|
vertical-lr
|
-epub-text-combine
*
|
-epub-text-combine-horizontal:
none
|
none
|
text-combine-upright:
none
|
-epub-text-combine
*
|
-epub-text-combine-horizontal:
all
|
horizontal
|
text-combine-upright:
all
|
-epub-text-combine
*
|
Error |
horizontal
<number>
|
text-combine-upright:
digits
<number>
|
| Property | Value | Mapping to [ CSS-Text-3-20160119 ] |
|---|---|---|
-epub-hyphens
|
none
|
manual
|
auto
|
No Change |
-epub-hyphens
|
all
|
Not Supported |
-epub-line-break
|
auto
|
loose
|
normal
|
strict
|
No Change |
-epub-text-align-last
|
auto
|
start
|
end
|
left
|
right
|
center
|
justify
|
No Change |
-epub-word-break
|
normal
|
keep-all
|
break-all
|
No Change |
text-transform
|
-epub-fullwidth
|
text-transform:
full-width
|
| Property | Value | Mapping to [ CSS-Text-Decor-3 ] |
|---|---|---|
-epub-text-emphasis-color
|
<color>
|
No Change |
-epub-text-emphasis-position
|
[
over
|
under
]
&&
[
right
|
left
]
|
No Change |
-epub-text-emphasis-style
|
none
|
[
[
filled
|
open
]
||
[
dot
|
circle
|
double-circle
|
triangle
|
sesame
]
]
|
<string>
|
No Change |
-epub-text-underline-position
|
auto
|
[
under
||
[
left
|
right
]
]
|
No Change |
-epub-text-underline-position
|
alphabetic
|
text-underline-position:
auto
|
Property value syntax defined in Component value combinators [ CSS-Values-3 ].
EPUB Content Documents MAY contain scripting using the facilities defined for this in the respective underlying specifications ([ HTML ] and [ SVG ]). When an EPUB Content Document contains scripting, it is referred to in this specification as a Scripted Content Document . This label also applies to XHTML Content Documents when they contain instances of [ HTML ] forms .
The
scripted
property
of
the
manifest
item
element
indicates
that
an
EPUB
Content
Document
is
a
Scripted
Content
Document
.
This specification defines two contexts in which scripts MAY appear:
An
instance
of
the
[
HTML
]
script
or
[
SVG
]
script
element
included
in
a
Top-level
Content
Document
.
Either of the following:
An
instance
of
the
[
HTML
]
script
element
included
in
an
XHTML
Content
Document
that
is
embedded
in
a
parent
XHTML
Content
Document
using
the
[
HTML
]
iframe
element.
An
instance
of
the
[
SVG
]
script
element
included
in
an
SVG
Content
Document
that
is
embedded
in
a
parent
XHTML
Content
Document
using
the
[
HTML
]
iframe
element.
In
both
of
the
above-defined
contexts,
whether
the
JavaScript
code
is
embedded
directly
in
the
script
element
or
referenced
via
its
src
attribute
makes
no
difference
to
the
executing
context.
Which context a script is used in determines the rights and restrictions that a Reading System places on it. Refer to the following sections and Scripting Conformance [ EPUB-RS-33 ] for some specific requirements that have to be adhered to (not all Reading Systems will provide the same scripting functionality).
A container-constrained script MUST NOT contain instructions for modifying the DOM of the parent Content Document or other contents in the EPUB Publication, and MUST NOT contain instructions for manipulating the size of its containing rectangle.
EPUB Content Documents that include spine-level scripting MUST utilize the progressive enhancement technique , which for the purposes of this specification has the following definition: when the document is rendered by a Reading System without scripting support or with scripting support disabled, the Top-level Content Document MUST retain its integrity, remaining consumable by the user without any information loss or other significant deterioration.
EPUB Content Documents that include scripting SHOULD employ relevant [ WAI-ARIA ] accessibility techniques to ensure that the content remains consumable by all users.
EPUB
Content
Documents
that
include
scripting
MAY
provide
fallbacks
for
such
content,
either
by
using
intrinsic
fallback
mechanisms
(such
as
those
available
for
the
[
HTML
]
object
and
canvas
elements)
or,
when
an
intrinsic
fallback
is
not
applicable,
by
using
a
manifest-level
fallback
.
Authors MUST ensure that scripts only generate Core Media Type Resources or fragments thereof.
The W3C Pronunciation Lexicon Specification ( PLS ) [ PRONUNCIATION-LEXICON ] defines syntax and semantics for XML-based pronunciation lexicons to be used by Automatic Speech Recognition and Text-to-Speech (TTS) engines.
PLS
Documents
MUST
be
valid
to
the
RELAX
NG
schema
available
at
the
URI
https://www.w3.org/TR/2008/REC-pronunciation-lexicon-20081014/
[
PRONUNCIATION-LEXICON
].
A PLS Document MAY be associated with XHTML Content Documents . Each XHTML Content Document MAY contain zero or more PLS document associations.
A
PLS
Document
MUST
be
associated
with
the
XHTML
Content
Document
to
which
it
applies
using
the
[
HTML
]
link
element
with
its
rel
attribute
set
to
"
pronunciation
"
and
its
type
attribute
set
to
the
media
type
"
application/pls+xml
".
The
link
element
hreflang
attribute
SHOULD
be
specified
on
each
link
,
and
its
value
MUST
match
the
language
for
which
the
pronunciation
lexicon
is
relevant
[
PRONUNCIATION-LEXICON
]
when
specified.
PLS
Documents
SHOULD
use
the
file
extension
.pls
.
For more information on EPUB 3 features related to synthetic speech, refer to Text-to-speech [ EPUB-OVERVIEW-33 ].
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 "content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content." [ EPUB-OVERVIEW-33 ]
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.
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.e.,
for
all
spine
items).
The
following
values
are
defined
for
use
with
the
rendition:layout
property:
The given Rendition is not pre-paginated (i.e., Reading Systems apply dynamic pagination when rendering). Default value.
The
given
Rendition
is
pre-paginated
(i.e.,
Reading
Systems
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 [ UAAG20 ] for related information.
When
the
property
is
set
to
pre-paginated
for
a
spine
item,
its
content
dimensions
MUST
be
set
as
defined
in
§
5.
Fixed
Layouts
.
The
rendition:layout
property
MUST
NOT
be
declared
more
than
once.
Authors
MAY
specify
the
following
properties
locally
on
spine
itemref
elements
to
override
the
global
value
for
the
given
spine
item:
Only one of these overrides is allowed on any given spine item.
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.e.,
for
all
spine
items).
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. Default value.
The
rendition:orientation
property
MUST
NOT
be
declared
more
than
once.
Authors
MAY
specify
the
following
properties
locally
on
spine
itemref
elements
to
override
the
global
value
for
the
given
spine
item:
Only one of these overrides is allowed on any given spine item.
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.e.,
for
all
spine
items).
The
following
values
are
defined
for
use
with
the
rendition:spread
property:
Do not incorporate spine items in a Synthetic Spread.
Render a Synthetic Spread for spine items only when the device is in landscape orientation.
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.
Render a Synthetic Spread regardless of device orientation.
No explicit Synthetic Spread behavior is defined. Default value.
The
rendition:spread
property
MUST
NOT
be
declared
more
than
once.
When
Synthetic
Spreads
are
used
in
the
context
of
HTML
and
SVG
Content
Documents,
the
dimensions
given
via
the
viewport
meta
element
and
viewBox
attribute
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.
Authors
MAY
specify
the
following
properties
locally
on
spine
itemref
elements
to
override
the
global
value
for
the
given
spine
item:
spread-portrait
property
is
deprecated
.
Refer
to
its
definition
in
[
EPUBPublications-301
]
for
more
information.
Only one of these overrides is allowed on any given spine item.
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
force
a
document
to
be
placed
in
a
particular
viewport
by
specifying
one
of
the
following
properties
on
its
spine
itemref
element:
rendition:page-spread-center
rendition:page-spread-center
property
specifies
the
forced
placement
of
a
Content
Document
in
a
Synthetic
Spread
.
rendition:page-spread-left
rendition:page-spread-left
property
is
an
alias
for
the
page-spread-left
property.
rendition:page-spread-right
rendition:page-spread-right
property
is
an
alias
for
the
page-spread-right
property.
The
rendition:page-spread-left
property
indicates
that
the
given
spine
item
is
to
be
rendered
in
the
left-hand
slot
in
the
spread,
and
rendition:page-spread-right
that
it
be
rendered
in
the
right-hand
slot.
The
rendition:page-spread-center
property
indicates
to
override
the
synthetic
spread
mode
and
render
a
single
viewport
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.
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.
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.
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.
The
rendition:viewport
property
allows
Authors
to
express
the
CSS
initial
containing
block
(ICB)
[
CSS21
]
for
XHTML
and
SVG
Content
Documents
whose
rendition:layout
property
has
been
set
to
pre-paginated
.
Use of the property is deprecated . Refer to its definition in [ EPUBPublications-301 ] for more information.
This section defines rules for the expression and interpretation of dimensional properties of Fixed-Layout Documents .
Fixed-Layout Documents specify their initial containing block [ CSS2 ] in the manner applicable to their format:
For
XHTML
Fixed-Layout
Documents
,
the
initial
containing
block
[
CSS2
]
dimensions
MUST
be
expressed
in
a
viewport
meta
tag
using
the
syntax
defined
in
[
CSS-Device-Adapt-1
].
For
SVG
Fixed-Layout
Documents
,
the
ICB
dimensions
MUST
be
expressed
using
the
viewBox
attribute
[
SVG
].
This section is non-normative.
The OCF Abstract Container file system model uses a single common Root Directory for all of the contents. All Local Resources for the EPUB Publication are located within the directory tree headed by the Root Directory, but no specific file system structure for them is mandated by this specification.
The
file
system
model
also
includes
a
mandatory
directory
named
META-INF
that
is
a
direct
child
of
the
Root
Directory
and
is
used
to
store
the
following
special
files:
container.xml
[required]
Identifies the Package Documents that define each Rendition of the EPUB Publication.
signatures.xml
[optional]
Contains digital signatures for various assets.
encryption.xml
[optional]
Contains information about the encryption of Publication Resources . This file is mandatory when obfuscation is used.
metadata.xml
[optional]
Used to store metadata about the OCF ZIP Container .
rights.xml
[optional]
Used to store information about digital rights.
manifest.xml
[optional]
A manifest of container contents as allowed by Open Document Format [ ODF ].
Conformance
requirements
for
the
various
files
in
the
META-INF
directory
are
defined
in
§
5.1.5
6.1.5
META-INF
Directory
.
The virtual file system for the OCF Abstract Container MUST have a single common Root Directory for all of the contents of the container.
The
OCF
Abstract
Container
MUST
include
a
directory
named
META-INF
that
is
a
direct
child
of
the
container's
Root
Directory.
Requirements
for
the
contents
of
this
directory
are
described
in
§
5.1.5
6.1.5
META-INF
Directory
.
The
file
name
mimetype
in
the
Root
Directory
is
reserved
for
use
by
OCF
ZIP
Containers
,
as
explained
in
§
5.2
6.2
OCF
ZIP
Container
.
All
other
files
within
the
OCF
Abstract
Container
MAY
be
in
any
location
descendant
from
the
Root
Directory,
provided
they
are
not
within
the
META-INF
directory.
Files within the OCF Abstract Container MUST reference each other via relative IRI references ([ RFC3987 ] and [ RFC3986 ]).
For relative IRI references, the Base IRI [ RFC3986 ] is determined by the relevant language specifications for the given file formats. For example, CSS defines how relative IRI references work in the context of CSS style sheets and property declarations [ CSSSnapshot ].
Unlike
most
language
specifications,
the
Base
IRIs
for
all
files
within
the
META-INF
directory
use
the
Root
Directory
of
the
OCF
Abstract
Container
as
the
default
Base
IRI.
For
example,
if
META-INF/container.xml
has
the
following
content:
<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="EPUB/Great_Expectations.opf"
media-type="application/oebps-package+xml" />
</rootfiles>
</
container
>
then
the
path
EPUB/Great_Expectations.opf
is
relative
to
the
root
directory
for
the
OCF
Abstract
Container
and
not
relative
to
the
META-INF
directory.
All relative IRI references MUST resolve to resources within the OCF Abstract Container (i.e., at or below the Root Directory).
The File Name restrictions described in this section are designed to allow Path Names and File Names to be used without modification on most commonly used operating systems.
In the context of an OCF Abstract Container , File and Path Names are case sensitive and have to meet the following criteria:
File Names MUST be UTF-8 [ Unicode ] encoded.
The Path Name for any directory or file within the OCF Abstract Container MUST NOT exceed 65535 bytes.
File Names MUST NOT use the following [ Unicode ] characters, as these characters might not be supported consistently across commonly-used operating systems:
SOLIDUS:
/
(
U+002F
)
QUOTATION
MARK:
"
(
U+0022
)
ASTERISK:
*
(
U+002A
)
FULL
STOP
as
the
last
character:
.
(
U+002E
)
COLON:
:
(
U+003A
)
LESS-THAN
SIGN:
<
(
U+003C
)
GREATER-THAN
SIGN:
>
(
U+003E
)
QUESTION
MARK:
?
(
U+003F
)
REVERSE
SOLIDUS:
\
(
U+005C
)
VERTICAL
LINE:
|
(
U+007C
)
DEL
(
U+007F
)
C0
range
(
U+0000
…
U+001F
)
C1
range
(
U+0080
…
U+009F
)
Private
Use
Area
(
U+E000
…
U+F8FF
)
Non
characters
in
Arabic
Presentation
Forms-A
(
U+FDDO
…
U+FDEF
)
Specials
(
U+FFF0
…
U+FFFF
)
Tags
and
Variation
Selectors
Supplement
(
U+E0000
…
U+E0FFF
)
Supplementary
Private
Use
Area-A
(
U+F0000
…
U+FFFFF
)
Supplementary
Private
Use
Area-B
(
U+100000
…
U+10FFFF
)
All File Names within the same directory MUST be unique following case normalization as described in section 3.13 of [ Unicode ].
All File Names within the same directory SHOULD be unique following NFC or NFD normalization [ TR15 ].
Some commercial ZIP tools do not support the full Unicode range and might support only the [ US-ASCII ] range for File Names. Authors who want to use ZIP tools that have these restrictions might find it is best to restrict their File Names to the [ US-ASCII ] range. If the names of files cannot be preserved during the unzipping process, it will be necessary to compensate for any name translation which took place when the files are referenced by URI from within the content.
META-INF
Directory
All
OCF
Abstract
Containers
MUST
include
a
directory
called
META-INF
in
their
Root
Directory
.
This
directory
contains
the
files
specified
in
§
5.1.5.2
6.1.5.2
Reserved
Files
.
Files
other
than
the
ones
listed
in
that
section
MAY
be
included
in
the
META-INF
directory.
container.xml
)
The
REQUIRED
container.xml
file
in
the
META-INF
directory
identifies
the
EPUB
Packages
in
the
OCF
Abstract
Container
.
The
contents
of
this
file
MUST
be
valid
to
the
schema
in
§
C.2.1
D.2.1
Schema
for
container.xml
after
removing
all
elements
and
attributes
from
other
namespaces
(including
all
attributes
and
contents
of
such
elements).
Each
rootfile
element
MUST
identify
the
location
of
a
Package
Document
representing
one
Rendition
of
the
EPUB
Publication
.
Each
rendition
MUST
conform
to
the
same
version
of
EPUB
as
its
container.
Although the EPUB Container provides the ability to include more than one rendition of the content, Reading System support for multiple renditions remains largely unrealized, outside specialized environments where the purpose and meaning of the renditions is established by the involved parties.
The
OPTIONAL
links
element
identifies
resources
necessary
for
the
processing
of
the
OCF
ZIP
Container
.
Each
of
its
child
link
elements
MUST
include
an
href
attribute
whose
value
identifies
the
location
of
a
resource.
Each
link
element
also
MUST
include
a
rel
attribute
whose
value
identifies
the
relationship
of
the
resource,
and
MAY
include
a
media-type
attribute
whose
value
MUST
be
a
media
type
[
RFC2046
]
that
specifies
the
type
and
format
of
the
resource
referenced
by
the
link
.
The
links
element
is
used
to
point
to
rendition
mapping
documents
for
multiple-rendition
EPUBs
[
EPUBMultipleRenditions-10
].
The
value
of
the
rootfile
element
full-path
attribute
and
the
link
element
href
attribute
MUST
contain
a
path
component
[
RFC3986
]
which
MUST
take
the
form
of
a
path-rootless
[
RFC3986
]
only.
The
path
components
are
relative
to
the
Root
Directory
.
encryption.xml
)
The
OPTIONAL
encryption.xml
file
in
the
META-INF
directory
holds
all
encryption
information
on
the
contents
of
the
container.
If
any
resource
within
the
container
is
encrypted,
encryption.xml
MUST
be
present
to
indicate
that
the
resource
is
encrypted
and
provide
information
on
how
it
is
encrypted.
This
file
is
an
XML
document
whose
root
element
is
encryption
.
The
encryption
element
contains
child
elements
of
type
EncryptedKey
and
EncryptedData
as
defined
by
[
XMLENC-CORE1
].
An
EncryptedKey
element
describes
each
encryption
key
used
in
the
container,
while
an
EncryptedData
element
describes
each
encrypted
file.
Each
EncryptedData
element
refers
to
an
EncryptedKey
element,
as
described
in
XML
Encryption.
The
contents
of
the
encryption.xml
file
MUST
be
valid
to
the
schema
in
§
C.2.2
D.2.2
Schema
for
encryption.xml
.
OCF encrypts individual files independently, trading off some security for improved performance, allowing the container contents to be incrementally decrypted. Encryption in this way exposes the directory structure and file naming of the whole package.
OCF
uses
XML
Encryption
[
XMLENC-CORE1
]
to
provide
a
framework
for
encryption,
allowing
a
variety
of
algorithms
to
be
used.
XML
Encryption
specifies
a
process
for
encrypting
arbitrary
data
and
representing
the
result
in
XML.
Even
though
an
OCF
Abstract
Container
might
contain
non-XML
data,
XML
Encryption
can
be
used
to
encrypt
all
data
in
an
OCF
Abstract
Container.
OCF
encryption
supports
only
the
encryption
of
entire
files
within
the
container,
not
parts
of
files.
The
encryption.xml
file,
if
present,
MUST
NOT
be
encrypted.
Encrypted
data
replaces
unencrypted
data
in
an
OCF
Abstract
Container.
For
example,
if
an
image
named
photo.jpeg
is
encrypted,
the
contents
of
the
photo.jpeg
resource
SHOULD
be
replaced
by
its
encrypted
contents.
Within
the
ZIP
directory,
encrypted
files
SHOULD
be
stored
rather
than
Deflate-compressed.
Note
that
some
situations
require
obfuscating
the
storage
of
embedded
resources
referenced
by
a
Rendition
to
tie
them
to
the
"parent"
EPUB
Publication
and
make
them
more
difficult
to
extract
for
unrestricted
use
(e.g.,
fonts).
Although
obfuscation
is
not
encryption,
the
encryption.xml
file
is
used
in
conjunction
with
the
resource
obfuscation
algorithm
to
identify
resources
that
need
to
be
de-obfuscated
before
they
can
be
used.
The following files MUST NOT be encrypted, regardless of whether default or specific encryption is requested:
mimetype
META-INF/container.xml
META-INF/encryption.xml
META-INF/manifest.xml
META-INF/metadata.xml
META-INF/rights.xml
META-INF/signatures.xml
Package
Document
Signed resources MAY subsequently be encrypted using the Decryption Transform for XML Signature [ XMLENC-DECRYPT ]. This feature enables an application such as an OCF agent to distinguish data that was encrypted before signing from data that was encrypted after signing. Only data that was encrypted after signing MUST be decrypted before computing the digest used to validate the signature.
When stored in a ZIP container, streams of data with Non-Codec content types SHOULD be compressed before they are encrypted, and Deflate compression MUST be used. This practice ensures that file entries stored in the ZIP container have a smaller size.
Streams of data with Codec content types SHOULD NOT be compressed before they are encrypted. In such cases, additional compression would introduce unnecessary processing overhead at production time (especially with large resource files), and would impact audio/video playback performance at consumption time. In some cases, the combination of compression with some encryption schemes might even compromise the ability of Reading Systems to handle partial content requests (e.g. HTTP byte ranges), due to the technical impossibility to determine the length of the full resource ahead of media playback (e.g. HTTP Content-Length header).
Streams
of
data
that
are
compressed
before
they
are
encrypted
SHOULD
provide
additional
EncryptionProperties
metadata
to
specify
the
size
of
the
initial
resource
(i.e.,
before
compression
and
encryption),
as
per
the
Compression
XML
element
defined
below.
Streams
of
data
that
are
not
compressed
before
they
are
encrypted
MAY
provide
the
additional
EncryptionProperties
metadata
to
specify
the
size
of
the
initial
resource
(i.e.,
before
encryption).
Compression
http://www.idpf.org/2016/encryption#compression
OPTIONAL
child
of
EncryptionProperty
.
[required]
Identifies the compression method used.
Value
is
either
"
0
"
(no
compression)
or
"
8
"
(Deflate
algorithm).
[required]
Represents the size of the initial resource (number of bytes).
Value is a positive integer.
Empty
manifest.xml
)
The
OPTIONAL
manifest.xml
file
in
the
META-INF
directory
provides
a
manifest
of
files
in
the
Container.
The OCF specification does not mandate a format for the manifest.
Note
that
the
manifest
element
contained
within
a
Package
Document
specifies
the
one
and
only
manifest
used
for
processing
a
given
Rendition.
Ancillary
manifest
information
contained
in
the
ZIP
archive
or
in
the
OPTIONAL
manifest.xml
file
MUST
NOT
be
used
for
processing
the
Rendition.
metadata.xml
)
The
OPTIONAL
META-INF/metadata.xml
file
in
the
META-INF
directory,
if
present,
MUST
be
used
for
container-level
metadata.
If
the
metadata.xml
file
is
present,
its
contents
SHOULD
be
only
namespace-qualified
elements
[
XML-NAMES
].
The
file
SHOULD
contain
the
root
element
metadata
in
the
namespace
http://www.idpf.org/2013/metadata
,
but
other
root
elements
are
allowed
for
backwards
compatibility.
Reading
Systems
SHOULD
ignore
metadata.xml
files
with
unrecognized
root
elements.
This
version
of
the
OCF
specification
does
not
define
metadata
for
use
in
the
metadata.xml
file.
Container-level
metadata
MAY
be
defined
in
future
versions
of
this
specification
and
in
EPUB
extension
specifications.
rights.xml
)
The
OPTIONAL
rights.xml
file
in
the
META-INF
directory
is
reserved
for
digital
rights
management
(DRM)
information
for
trusted
exchange
of
EPUB
Publications
among
rights
holders,
intermediaries,
and
users.
This
version
of
the
OCF
specification
does
not
require
a
specific
format
for
DRM
information,
but
a
future
version
might.
The
contents
of
the
rights.xml
SHOULD
be
only
namespace-qualified
elements
[
XML-NAMES
]
to
avoid
collision
with
a
future
format.
When
the
rights.xml
file
is
not
present,
no
part
of
the
container
is
rights
governed
at
the
container
level.
Rights
expressions
might
exist
within
the
contained
Renditions.
If
the
rights.xml
file
is
not
present,
no
part
of
the
OCF
Abstract
Container
is
rights
governed.
signatures.xml
)
Adding a digital signature is not a guarantee that an EPUB cannot be tampered with, since Reading Systems are not required to check signatures.
The
OPTIONAL
signatures.xml
file
in
the
META-INF
directory
holds
digital
signatures
for
the
container
and
its
contents.
The
contents
of
this
file
MUST
be
valid
to
the
schema
in
§
C.2.3
D.2.3
Schema
for
signatures.xml
.
The
root
element
of
the
signatures.xml
file
is
the
signatures
element.
This
element
contains
child
elements
of
type
Signature
,
as
defined
by
[
XMLDSIG-CORE1
].
Signatures
can
be
applied
to
an
EPUB
Publication
as
a
whole
or
to
its
parts,
and
can
specify
the
signing
of
any
kind
of
data
(i.e.,
not
just
XML).
When
the
signatures.xml
file
is
not
present,
no
part
of
the
container
is
digitally
signed
at
the
container
level.
Digital
signing
might
exist
within
the
EPUB
Publication
.
When
a
data
signature
is
created
for
the
container,
the
signature
SHOULD
be
added
as
the
last
child
Signature
element
of
the
signatures
element.
Each
Signature
in
the
signatures.xml
file
identifies
by
IRI
the
data
to
which
the
signature
applies,
using
the
[
XMLDSIG-CORE1
]
Manifest
element
and
its
Reference
sub-elements.
Individual
contained
files
might
be
signed
separately
or
together.
Separately
signing
each
file
creates
a
digest
value
for
the
resource
that
can
be
validated
independently.
This
approach
might
make
a
Signature
element
larger.
If
files
are
signed
together,
the
set
of
signed
files
can
be
listed
in
a
single
XML
Signature
Manifest
element
and
referenced
by
one
or
more
Signature
elements.
Any
or
all
files
in
the
container
can
be
signed
in
their
entirety
with
the
exception
of
the
signatures.xml
file
since
that
file
will
contain
the
computed
signature
information.
Whether
and
how
the
signatures.xml
file
is
signed
depends
on
the
objective
of
the
signer.
If
the
signer
wants
to
allow
signatures
to
be
added
or
removed
from
the
container
without
invalidating
the
signer's
signature,
the
signatures.xml
file
SHOULD
NOT
be
signed.
If
the
signer
wants
any
addition
or
removal
of
a
signature
to
invalidate
the
signer’s
signature,
the
Enveloped
Signature
transform
defined
in
Section
6.6.4
of
[
XMLDSIG-CORE1
]
can
be
used
to
sign
the
entire
preexisting
signature
file
excluding
the
Signature
being
created.
This
transform
would
sign
all
previous
signatures,
and
it
would
become
invalid
if
a
subsequent
signature
was
added
to
the
package.
If the signer wants the removal of an existing signature to invalidate the signer’s signature, but also wants to allow the addition of signatures, an XPath transform could be used to sign just the existing signatures. The details of such a transform are outside the scope of this specification, however.
The
[
XMLDSIG-CORE1
]
specification
does
not
associate
any
semantics
with
a
signature;
an
agent
might
include
semantic
information,
for
example,
by
adding
information
to
the
Signature
element
that
describes
the
signature.
The
[
XMLDSIG-CORE1
]
specification
describes
how
additional
information
can
be
added
to
a
signature,
such
as
by
use
the
SignatureProperties
element.
This section is non-normative.
An OCF ZIP Container is a physical single-file manifestation of an OCF Abstract Container . The Container is used:
to exchange in-progress EPUB Publication between different individuals and/or different organizations;
to provide EPUB Publications from a publisher or conversion house to the distribution or sales channel; and
to deliver EPUB Publications to EPUB Reading Systems or users.
An OCF ZIP Container uses the ZIP format as specified by [ ZIP ], but with the following constraints and clarifications:
The contents of the OCF ZIP Container MUST be a conforming OCF Abstract Container .
OCF ZIP Containers MUST NOT use the features in the ZIP application note [ ZIP ] that allow ZIP files to be spanned across multiple storage media, or split into multiple files.
OCF ZIP Containers MUST include only stored (uncompressed) and Deflate-compressed ZIP entries within the ZIP archive.
OCF ZIP Containers MAY use the ZIP64 extensions defined as "Version 1" in section V, subsection G of the application note [ ZIP ] and SHOULD use only those extensions when the content requires them.
OCF
ZIP
Containers
MUST
NOT
use
the
encryption
features
defined
by
the
ZIP
format;
instead,
encryption
MUST
be
done
using
the
features
described
in
§
5.1.5.2.2
6.1.5.2.2
Encryption
File
(
encryption.xml
)
.
OCF ZIP Containers MUST encode File System Names using UTF-8 [ Unicode ].
The following constraints apply to particular fields in the OCF ZIP Container archive:
In
the
local
file
header
table,
OCF
ZIP
Containers
MUST
set
the
version
needed
to
extract
fields
to
the
values
10
,
20
or
45
in
order
to
match
the
maximum
version
level
needed
by
the
given
file
(e.g.,
20
if
Deflate
is
needed,
45
if
ZIP64
is
needed).
In
the
local
file
header
table,
OCF
ZIP
Containers
MUST
set
the
compression
method
field
to
the
values
0
or
8
.
The
first
file
in
the
OCF
ZIP
Container
MUST
be
the
mimetype
file,
which
meets
the
following
requirements:
mimetype
file
MUST
be
the
MIME
media
type
[
RFC2046
]
string
application/epub+zip
encoded
in
US-ASCII
[
US-ASCII
].
mimetype
file
MUST
NOT
contain
any
leading
or
trailing
padding
or
white
space.
mimetype
file
MUST
NOT
begin
with
the
Unicode
byte
order
mark
U+FEFF.
mimetype
file
MUST
NOT
be
compressed
or
encrypted,
and
there
MUST
NOT
be
an
extra
field
in
its
ZIP
header.
Refer
to
§
G.2
The
application/epub+zip
Media
Type
for
further
information
about
the
application/epub+zip
media
type.
This section is non-normative.
Since an OCF ZIP Container is fundamentally a ZIP file, commonly available ZIP tools can be used to extract any unencrypted content stream from the package. Moreover, the nature of ZIP files means that their contents might appear like any other native container on some systems (e.g., a folder).
While this simplicity of ZIP files is quite useful, it also poses a problem when ease of extraction of resources is not a desired side-effect of not encrypting them. An Author who wishes to include a third-party font, for example, typically does not want that font extracted and re-used by others. More critically, many commercial fonts allow embedding, but embedding a font implies making it an integral part of the EPUB Publication, not just providing the original font file along with the content.
Since integrated ZIP support is so ubiquitous in modern operating systems, simply placing a font in the ZIP archive is insufficient to signify that it is not intended to be reused in other contexts. This uncertainty can undermine the otherwise very useful font embedding capability of EPUB Publications.
In order to discourage reuse of the font, some font vendors might only allow use of their fonts in EPUB Publications if those fonts are bound in some way to the EPUB Publication. That is, if the font file cannot be installed directly for use on an operating system with the built-in tools of that computing device, and it cannot be directly used by other EPUB Publications.
It is beyond the scope of this specification to provide a digital rights management or enforcement system for such resources. This section instead defines a method of obfuscation that will require additional work on the part of the final OCF recipient to gain general access to any obfuscated resources.
Note that no claim is made in this specification that this constitutes encryption, nor does it guarantee that the resource will be secure from copyright infringement. It is hoped, however, that this algorithm will meet the requirements of most vendors who require some assurance that their resources cannot simply be extracted by unzipping the Container.
In the case of fonts, the primary use case for obfuscation, the defined mechanism will simply provide a stumbling block for those who are unaware of the license details. It will not prevent a determined user from gaining full access to the font. Given an OCF Container, it is possible to apply the algorithms defined to extract the raw font file. Whether this method of obfuscation satisfies the requirements of individual font licenses remains a question for the licensor and licensee.
The key used in the obfuscation algorithm is derived from the Unique Identifier of the Default Rendition .
All
white
space
characters,
as
defined
in
section
2.3
of
the
XML
1.0
specification
[
XML
],
MUST
be
removed
from
this
identifier
—
specifically,
the
Unicode
code
points
U+0020
,
U+0009
,
U+000D
and
U+000A
.
A SHA-1 digest of the UTF-8 representation of the resulting string SHOULD be generated as specified by the Secure Hash Standard [ FIPS-180-4 ]. This digest is then directly used as the key for the algorithm.
The algorithm employed to obfuscate resource consists of modifying the first 1040 bytes (~1KB) of the file. In the unlikely event that the file is less than 1040 bytes, then the entire file will be modified.
To obfuscate the original data, the result of performing a logical exclusive or (XOR) on the first byte of the raw file and the first byte of the obfuscation key is stored as the first byte of the embedded resource.
This process is repeated with the next byte of source and key, and continues until all bytes in the key have been used. At this point, the process continues starting with the first byte of the key and 21st byte of the source. Once 1040 bytes have been encoded in this way (or the end of the source is reached), any remaining data in the source is directly copied to the destination.
Obfuscation
of
resources
MUST
occur
before
they
are
compressed
and
added
to
the
OCF
Container.
Note
that
as
obfuscation
is
not
encryption,
this
requirement
is
not
a
violation
of
the
one
in
§
5.1.5.2.2
6.1.5.2.2
Encryption
File
(
encryption.xml
)
to
compress
resources
before
encrypting
them.
To get the original font data back, the process is simply reversed: the source file becomes the obfuscated data and the destination file will contain the raw data.
The obfuscation of fonts was allowed prior to EPUB 3.0.1, but the order of obfuscation and compression was not specified. As a result, invalid fonts might be encountered after decompression and de-obfuscation. In such instances, de-obfuscating the data before inflating it might return a valid font. This specification does not require support for this method of retrieval, as it is not compliant with this version of this specification, but it needs to be considered when supporting EPUB 3 content generally.
Although
not
technically
encrypted
data,
all
obfuscated
resources
MUST
have
an
entry
in
the
encryption.xml
file
accompanying
the
EPUB
Publication
(see
§
5.1.5.2.2
6.1.5.2.2
Encryption
File
(
encryption.xml
)
).
An
EncryptedData
element
MUST
be
included
for
each
obfuscated
resource.
Each
EncryptedData
element
MUST
include
a
child
EncryptionMethod
element
whose
Algorithm
attribute
is
set
to
the
value
http://www.idpf.org/2008/embedding
.
The
presence
of
this
attribute
signals
the
use
of
the
algorithm
described
in
this
specification.
The
path
to
the
obfuscated
resource
MUST
be
listed
in
the
CipherReference
child
of
the
CipherData
element.
To
prevent
trivial
copying
of
the
embedded
resource
to
other
EPUB
Publications,
the
obfuscation
key
MUST
NOT
be
provided
in
the
encryption.xml
file.
This section is non-normative.
Synchronized audio narration is found in mainstream ebooks, educational tools and ebooks formatted for persons with print disabilities. In EPUB 3, these types of books are created using Media Overlay Documents to describe the timing for the pre-recorded audio narration and how it relates to the EPUB Content Document markup. The file format for Media Overlays is defined as a subset of [ SMIL3 ], a W3C recommendation for representing synchronized multimedia information in XML.
The text and audio synchronization enabled by Media Overlays provides enhanced accessibility for any user who has difficulty following the text of a traditional book. Media Overlays also provide a continuous listening experience for readers who are unable to read the text for any reason, something that traditional audio embedding techniques cannot offer. They are even useful for purposes not traditionally considered accessibility concerns (e.g., for language learning or reading of commercial audio books).
The Media Overlays feature is designed to be transparent to EPUB Reading Systems that do not support the feature. The inclusion of Media Overlays in an EPUB Publication has no impact on the ability of Media Overlay-unaware Reading Systems to render the EPUB Publication as though the Media Overlays are not present.
Although future versions of this specification might incorporate support for video media (e.g., synchronized text/sign-language books), this version supports only synchronizing audio media with the EPUB Content Document.
A Media Overlay Document has to meet the following requirements:
It
MUST
be
valid
to
the
Media
Overlays
schema
as
defined
in
§
C.3
D.3
Media
Overlays
Schema
and
conform
to
all
content
conformance
constraints
expressed
in
§
6.2.2
7.2.2
Media
Overlay
Document
Definition
.
It MAY refer to more than one EPUB Content Document, but an EPUB Content Document MUST NOT be referenced by more than one Media Overlay Document.
It SHOULD use semantic markup where appropriate.
All
elements
[
XML
]
defined
in
this
section
are
in
the
https://www.w3.org/ns/SMIL
namespace
[
XML-NAMES
]
unless
otherwise
specified.
smil
Element
The
smil
element
is
the
root
element
of
all
Media
Overlay
Documents.
smil
The
smil
element
is
the
root
element
of
the
Media
Overlay
Document.
version
[required]
Specifies the version number of the [ SMIL3 ] specification to which the Media Overlay adheres.
This
attribute
MUST
have
the
value
"
3.0
".
id
[optional]
The ID [ XML ] of the element, which MUST be unique within the document scope.
epub:prefix
[optional]
Declares additional metadata vocabulary prefixes.
Refer
to
§
6.3.3
7.3.3
Semantic
Inflection
for
more
information.
In this order:
head
Element
The
head
element
is
the
container
for
metadata
in
the
Media
Overlay
Document.
head
The
head
element
is
the
OPTIONAL
first
child
of
the
smil
element.
None
metadata
[0
or
1]
As
this
specification
does
not
define
any
metadata
properties
that
have
to
occur
in
the
Media
Overlay
Document,
the
head
element
is
OPTIONAL
.
metadata
Element
The
metadata
element
represents
metadata
for
the
Media
Overlay
Document.
The
metadata
element
is
an
extension
point
that
allows
the
inclusion
of
metadata
from
any
metainformation
structuring
language.
metadata
As
a
child
of
the
head
element.
None
[0
or
more]
elements
from
any
namespace
This
specification
defines
no
metadata
properties
that
MUST
occur
in
the
Media
Overlay
Document;
the
metadata
element
is
provided
for
custom
metadata
requirements.
body
Element
The
body
element
is
the
starting
point
for
the
presentation
contained
in
the
Media
Overlay
Document.
It
contains
the
main
sequence
of
par
and
seq
elements.
body
The
body
element
is
the
REQUIRED
second
child
of
the
smil
element.
epub:type
[optional]
An expression of the structural semantics of the corresponding element in the EPUB Content Document .
The
value
is
a
white
space
separated
list
of
property
types.
Refer
to
§
6.3.3
7.3.3
Semantic
Inflection
for
more
information.
id
[optional]
The ID [ XML ] of the element, which MUST be unique within the document scope.
epub:textref
[optional]
The relative IRI reference [ RFC3987 ] of the corresponding EPUB Content Document, including a fragment identifier that references the specific element as per the [ XPTRSH ].
In any order:
At
least
one
par
or
seq
is
REQUIRED
.
seq
Element
The
seq
element
contains
media
objects
which
are
to
be
rendered
sequentially.
seq
One
or
more
seq
elements
MAY
occur
as
children
of
the
body
element
and
of
the
seq
element
.
epub:type
[optional]
An expression of the structural semantics of the corresponding element in the EPUB Content Document .
The
value
is
a
white
space
separated
list
of
property
types.
Refer
to
§
6.3.3
7.3.3
Semantic
Inflection
for
more
information.
id
[optional]
The ID [ XML ] of the element, which MUST be unique within the document scope.
epub:textref
[required]
The relative IRI reference [ RFC3987 ] of the corresponding EPUB Content Document, including a fragment identifier that references the specific element as per the [ XPTRSH ].
Refer
to
§
6.3.2.1
7.3.2.1
Structure
for
more
information.
In any order:
At
least
one
par
or
seq
is
REQUIRED
.
par
Element
The
par
element
contains
media
objects
which
are
to
be
rendered
in
parallel.
par
One
or
more
par
elements
MAY
occur
as
children
of
the
body
and
seq
elements.
epub:type
[optional]
An expression of the structural semantics of the corresponding element in the EPUB Content Document .
The
value
is
a
white
space
separated
list
of
property
types.
Refer
to
§
6.3.3
7.3.3
Semantic
Inflection
for
more
information.
id
[optional]
The ID [ XML ] of the element, which MUST be unique within the document scope.
In any order:
The
audio
element
is
OPTIONAL
only
if
its
sibling
text
element
refers
to
audio
or
video
media
(see
§
6.3.2.3
7.3.2.3
Embedded
Media
),
or
to
textual
content
intended
for
rendering
via
Text-to-Speech
(TTS).
text
Element
The
text
element
references
an
element
in
the
EPUB
Content
Document
.
A
text
element
typically
refers
to
a
textual
element,
but
can
also
refer
to
other
EPUB
Content
Document
media
elements
(see
§
6.3.2.3
7.3.2.3
Embedded
Media
).
text
As
a
REQUIRED
child
of
the
par
element.
Empty
audio
Element
The
audio
element
represents
a
clip
of
audio
media.
audio
A
REQUIRED
child
of
the
par
element
unless
its
sibling
text
element
refers
to
audio
or
video
media,
or
to
textual
content
intended
for
rendering
via
Text-to-Speech
(TTS),
in
which
case
it
is
OPTIONAL
(see
§
6.3.2.3
7.3.2.3
Embedded
Media
).
id
[optional]
The ID [ XML ] of the element, which MUST be unique within the document scope.
src
[required]
The relative or absolute IRI reference [ RFC3987 ] of an audio file. The audio file MUST be one of the audio formats listed in the Core Media Type Resources table.
clipBegin
[optional]
A clock value that specifies the offset into the physical media corresponding to the start point of an audio clip.
MUST be a [ SMIL3 ] clock value .
clipEnd
[optional]
A clock value that specifies the offset into the physical media corresponding to the end point of an audio clip.
MUST be a [ SMIL3 ] clock value .
See
§
E.
F.
Examples
of
Clock
Values
.
The
chronological
offset
of
the
terminating
position
MUST
be
after
the
starting
offset
specified
in
the
clipBegin
attribute.
Empty
This section is non-normative.
A pre-recorded narration of a publication can be represented as a series of audio clips, each corresponding to part of the EPUB Content Document . A single audio clip, for example, typically represents a single phrase or paragraph, but infers no order relative to the other clips or to the text of a document. Media Overlays solve this problem of synchronization by tying the structured audio narration to its corresponding text (or other media) in the EPUB Content Document using [ SMIL3 ] markup. Media Overlays are, in fact, a simplified subset of SMIL 3.0 that allow the playback sequence of these clips to be defined.
The
SMIL
elements
primarily
used
for
structuring
Media
Overlays
are
body
(used
for
the
main
sequence),
seq
(sequence)
and
par
(parallel).
(Refer
to
§
6.2.2
7.2.2
Media
Overlay
Document
Definition
for
more
information
on
these
and
other
SMIL
elements.)
The
par
element
is
the
basic
building
block
of
an
Overlay
and
corresponds
to
a
phrase
in
the
EPUB
Content
Document.
The
element
provides
two
key
pieces
of
information
for
synchronizing
content:
1)
the
audio
clip
containing
the
narration
for
the
phrase;
and
2)
a
pointer
to
the
associated
EPUB
Content
Document
fragment.
The
par
element
uses
two
media
element
children
to
represent
this
information:
an
audio
element
and
a
text
element.
Since
par
elements
render
their
children
in
parallel,
the
audio
clip
and
EPUB
Content
Document
fragment
are
played
at
the
same
time,
resulting
in
a
synchronized
presentation.
The
text
element
src
attribute
references
the
associated
phrase,
sentence,
or
other
segment
of
the
EPUB
Content
Document
by
its
IRI
reference.
The
audio
element
src
attribute
similarly
references
the
location
of
the
corresponding
audio
clip,
and
adds
the
OPTIONAL
clipBegin
and
clipEnd
attributes
to
indicate
a
specific
offset
within
the
clip.
par
elements
are
placed
together
sequentially
to
form
a
series
of
phrases
or
sentences.
Not
every
element
of
the
EPUB
Content
Document
will
have
a
corresponding
par
element
in
the
Media
Overlay,
only
those
relevant
to
the
audio
narration.
par
elements
can
also
be
added
to
seq
elements
to
define
more
complex
structures
such
as
parts
and
chapters
(see
§
6.3.2.1
7.3.2.1
Structure
).
In this section, the EPUB Content Document is assumed to be an XHTML Content Document . While Media Overlays can be used with SVG Content Documents , playback behavior might not be consistent and therefore interoperability is not guaranteed.
The
body
of
a
Media
Overlay
Document
consists
of
two
elements:
the
par
element
and
the
seq
element
.
The
ordering
of
these
elements
MUST
match
the
default
reading
order
of
the
EPUB
Content
Document.
The
par
element
represents
phrases.
Each
element
identifies
a
text
and
audio
component
to
sychronize
during
playback.
The
seq
element
represents
sequences.
It
is
used
to
represent
nested
containers
such
as
sections,
asides,
headers,
and
footnotes.
It
allows
the
structure
inherent
in
these
containers
to
be
retained
in
the
Media
Overlay
Document.
The
seq
element
MUST
contain
an
epub:textref
attribute
.
The
IRI
[
RFC3987
]
value
of
this
attribute
MUST
reference
the
corresponding
structural
element
in
an
EPUB
Content
Document.
As
seq
elements
do
not
provide
synchronization
instructions,
this
attribute
allows
a
Reading
System
to
still
match
the
element
to
a
location
in
the
text.
The
following
example
shows
a
Media
Overlay
Document
with
nested
seq
elements,
representing
a
chapter
with
both
a
section
header
and
a
figure.
<smil xmlns="http://www.w3.org/ns/SMIL" xmlns:epub="http://www.idpf.org/2007/ops" version="3.0">
<body>
<!-- a chapter -->
<seq id="id1" epub:textref="chapter1.xhtml#sectionstart" epub:type="chapter">
<!-- the section title -->
<par id="id2">
<text src="chapter1.xhtml#section1_title"/>
<audio src="chapter1_audio.mp3"
clipBegin="0:23:23.84"
clipEnd="0:23:34.221"/>
</par>
<!-- some sentences in the chapter -->
<par id="id3">
<text src="chapter1.xhtml#text1"/>
<audio src="chapter1_audio.mp3"
clipBegin="0:23:34.221"
clipEnd="0:23:59.003"/>
</par>
<par id="id4">
<text src="chapter1.xhtml#text2"/>
<audio src="chapter1_audio.mp3"
clipBegin="0:23:59.003"
clipEnd="0:24:15.000"/>
</par>
<!-- a figure -->
<seq id="id7" epub:textref="chapter1.xhtml#figure">
<par id="id8">
<text src="chapter1.xhtml#photo"/>
<audio src="chapter1_audio.mp3"
clipBegin="0:24:18.123"
clipEnd="0:24:28.764"/>
</par>
<par id="id9">
<text src="chapter1.xhtml#caption"/>
<audio src="chapter1_audio.mp3"
clipBegin="0:24:28.764"
clipEnd="0:24:50.010"/>
</par>
</seq>
<!-- more sentences in the chapter (outside the figure) -->
<par id="id12">
<text src="chapter1.xhtml#text3"/>
<audio src="chapter1_audio.mp3"
clipBegin="0:25:45.515"
clipEnd="0:26:30.203"/>
</par>
<par id="id13">
<text src="chapter1.xhtml#text4"/>
<audio src="chapter1_audio.mp3"
clipBegin="0:26:30.203"
clipEnd="0:27:15.000"/>
</par>
</seq>
</body>
</
smil
>
The
reason
for
grouping
structures
like
sections,
figures,
tables,
and
footnotes
in
a
seq
element
is
so
that
their
start
and
end
positions
can
be
identified
during
playback.
Reading
Systems
can
then
offer
playback
options
tailored
to
the
layout
of
the
given
Rendition
,
such
as
jumping
past
a
long
figure,
turning
off
rendering
of
page
break
announcements
(see
§
6.4
7.4
Skippability
and
Escapability
),
or
customizing
the
reading
mode
to
suit
structures
such
as
tables.
This section is non-normative.
Media
Overlay
text
elements'
src
attributes
refer
to
EPUB
Content
Document
elements
by
their
IDs
[
XML
].
The
granularity
level
of
the
Media
Overlay
therefore
depends
on
how
the
EPUB
Content
Document
is
marked
up.
If
the
finest
level
of
markup
is
at
the
paragraph
level,
then
that
is
the
finest
possible
level
at
which
Media
Overlay
synchronization
can
be
authored.
Likewise,
if
sub-paragraph
markup
is
available,
such
as
[
HTML
]
span
elements
representing
phrases
or
sentences,
then
finer
granularity
is
possible
in
the
Media
Overlay.
Finer
granularity
gives
users
more
precise
results
for
synchronized
playback
when
navigating
by
word
or
phrase
and
when
searching
the
text,
but
increases
the
file
size
of
the
Media
Overlay
Documents.
Any
EPUB
Content
Document
associated
with
a
Media
Overlay
MAY
contain
embedded
media
such
as
video,
audio,
and
images.
The
Media
Overlay
text
element
MAY
be
used
in
such
instances
to
reference
the
embedded
media
by
its
ID
[
XML
]
value.
When
a
text
element
references
embedded
media
that
contains
audio,
the
audio
sibling
element
is
OPTIONAL
.
Authors SHOULD avoid using scripts to control playback of referenced embedded EPUB Content Document media, as this might conflict with Media Overlays playback behavior.
This
specification
allows
the
use
of
Text-to-Speech
(TTS)
in
addition
to
pre-recorded
audio
clips.
When
a
Media
Overlay
text
element
with
no
sibling
audio
element
references
an
element
within
the
target
EPUB
Content
Document
,
the
contents
of
that
referenced
element
MUST
be
appropriate
for
rendering
via
TTS.
For
example,
it
could
be
a
textual
EPUB
Content
Document
element
or
contain
a
text
fallback.
In
order
to
express
semantic
inflections,
inflections
,
the
epub:type
attribute
MAY
be
attached
to
Media
Overlay
par
,
seq
,
and
body
elements.
Values
for
the
Media
Overlay
epub:type
attribute
are
constrained
identically
to
the
epub:type
attribute
in
EPUB
Content
Documents
.
Refer
to
§
4.1.3.1
Semantic
Inflection
for
details.
The
epub:type
attribute
facilitates
Reading
System
behavior
appropriate
for
the
semantic
type(s)
indicated.
Examples
of
these
behaviors
are
skippability
and
escapability
and
table
reading
mode
[
EPUB-RS-33
].
This
specification
adopts
the
vocabulary
association
mechanisms
defined
in
§
4.1.3.1.3
Vocabulary
Association
unmodified.
Terms
from
the
default
vocabulary
MUST
be
used
unprefixed
in
Overlay
Documents.
Media
Overlays
MAY
use
additional
vocabularies
by
defining
them
in
the
epub:prefix
attribute
applicable
vocabulary
association
mechanisms
on
for
the
root
smil
epub:type
element.
attribute
to
define
additinal
semantics.
Visual
rendering
information
for
the
currently-playing
EPUB
Content
Document
element
MAY
be
expressed
in
the
CSS
Style
Sheet
using
author-defined
classes.
These
author-defined
class
names
SHOULD
be
declared
in
the
Package
Document
metadata
using
the
metadata
properties
active-class
and
playback-active-class
.
The
class
names
are
then
discoverable
by
Reading
Systems.
The
active-class
and
playback-active-class
properties
MUST
NOT
be
used
in
conjunction
with
a
refines
attribute
,
as
they
are
always
considered
to
apply
to
the
entire
Rendition
.
This example demonstrates how Authors can associate style information with the currently-playing EPUB Content Document.
Although
this
example
uses
the
class
names
-epub-media-overlay-active
and
-epub-media-overlay-playing
,
any
class
names
are
permitted.
The
class
names
chosen
can
be
used
along
with
any
supported
CSS
features.
In
this
example,
the
Reading
System
would
apply
the
author-defined
-epub-media-overlay-active
class
to
each
text
element
in
the
EPUB
Content
Document
as
it
became
active
during
playback.
Conversely,
the
class
name
is
removed
when
the
element
is
no
longer
active.
The
user
would
see
each
EPUB
Content
Document
element
styled
with
a
yellow
background
for
the
duration
of
that
element's
playback.
The
Reading
System
would
also
apply
the
author-defined
-epub-media-overlay-playing
class
to
the
document
element
of
the
EPUB
Content
Document
when
Media
Overlays
playback
begins.
The
class
name
is
removed
when
playback
stops.
In
the
case
of
an
XHTML
Content
Document,
the
class
name
would
be
applied
to
the
html
element.
In
the
case
of
an
SVG
Content
Document,
it
would
be
applied
to
the
svg
element.
The
user
would
see
all
the
inactive
text
elements
turn
gray
during
Media
Overlays
playback.
When
playback
stopped,
the
elements’
colors
would
return
to
their
defaults.
If
an
EPUB
Content
Document
is
wholly
or
partially
referenced
by
a
Media
Overlay,
then
its
manifest
item
element
MUST
include
a
media-overlay
attribute.
The
attribute
MUST
reference
the
ID
[
XML
]
of
the
manifest
item
for
the
corresponding
Media
Overlay
Document.
The
media-overlay
attribute
MUST
only
be
attached
to
manifest
item
elements
that
reference
EPUB
Content
Documents
.
Manifest
items
for
Media
Overlay
Documents
MUST
have
the
media
type
application/smil+xml
.
The
Package
Document
MUST
include
the
duration
of
the
entire
Rendition
in
a
meta
element
with
the
duration
property
.
In
addition,
the
duration
of
each
EPUB
Content
Document
with
an
associated
Media
Overlay
MUST
be
provided.
The
refines
attribute
is
used
to
associate
each
duration
declaration
to
the
corresponding
manifest
item
.
Authors
also
MAY
include
narrator
information
in
the
Package
Document,
as
well
as
author-defined
CSS
class
names
to
be
applied
to
the
currently-playing
EPUB
Content
Document
element.
The
prefix
media:
is
reserved
by
for
the
inclusion
of
these
properties
in
package
metadata.
While
reading,
users
might
want
to
turn
on
or
off
certain
features
of
the
content,
such
as
footnotes,
page
numbers,
or
other
types
of
secondary
content.
This
feature
is
called
skippability.
Reading
Systems
use
the
semantic
information
provided
by
Media
Overlay
elements'
epub:type
attribute
to
determine
when
to
offer
users
the
option
of
skippable
features.
The
following
non-exhaustive
list
represents
terms
from
the
[
EPUB-SSV
Strucural
Semantics
Vocbulary
]
for
which
Reading
Systems
might
offer
the
option
of
skippability:
footnote
endnote
pagebreak
Reading
System
are
not
required
to
support
for
skippability
based
on
epub:type
values.
Escapable items are nested structures, such as tables and lists, that users might wish to skip over, continuing to read from the point immediately after the nested structure. The escapability feature differs from the skippability feature in that it does not enable or disable entire types of items, but provides an exit from them (e.g., a user can listen to some of the content before choosing to escape).
The
following
non-exhaustive
list
represents
terms
from
the
[
EPUB-SSV
Structural
Semantics
Vocabulary
]
for
which
Reading
Systems
might
offer
the
option
of
escapability:
table
table-row
table-cell
list
list-item
figure
This specification and its siblings contain certain features that are no longer recommended for use or that are only retained for legacy support reasons. This section defines the meanings of the designations attached to these features and the support expectations for such features.
A deprecated feature is one that is no longer recommended for use in this version of the specification. Deprecated features typically have had limited or no support in Reading Systems and/or usage in EPUB Publications. If a feature is marked as deprecated, the following hold true:
Authors are strongly RECOMMENDED not to use the feature in their EPUB Publications .
Reading Systems MAY support the feature.
Developers are advised to consider the unlikelihood of encountering content with deprecated features before adding new support for them.
Validation tools SHOULD alert Authors that inclusion of the feature is deprecated when encountered in an EPUB Publication.
A legacy feature is one that is retained only for authoring content that is compatible with versions of EPUB prior to 3.0. If a feature is marked as legacy, the following hold true:
Authors MAY include the legacy feature for compatibility purposes.
Reading Systems MUST NOT support the legacy feature in content that conforms to this version of EPUB.
Validation tools SHOULD NOT alert Authors about the presence of legacy features in an EPUB Publication , as their inclusion is valid for backwards compatibility. Validation tools MUST alert Authors if a legacy feature does not conform to its definition or otherwise breaks a usage requirement.
Semantic
inflection
is
the
process
of
attaching
additional
meaning
about
the
specific
purpose
and/or
nature
an
element
plays.
The
epub:type
attribute
is
used
to
express
domain-specific
semantics
in
EPUB
Content
Documents
and
Media
Ovelay
Documents
,
with
the
inflection(s)
it
carries
complementing
the
underlying
vocabulary.
The
applied
semantics
are
intended
to
refine
the
meaning
of
their
containing
elements;
they
are
not
provided
to
override
their
nature
(e.g.,
the
attribute
can
be
used
to
indicate
a
[
HTML
]
section
is
a
chapter
in
a
work,
but
is
not
designed
to
turn
p
elements
into
list
items
to
avoid
proper
list
structures).
Semantic metadata is intended to enrich content for use in publishing workflows and for author-defined purposes. It also allows Reading Systems to learn more about the structure and content of a document (e.g., to enable skippability and escapability in Media Ovelays).
This
specification
defines
a
method
for
semantic
inflection
using
the
attribute
axis
:
instead
of
adding
new
elements,
the
epub:type
attribute
can
be
appended
to
existing
elements
to
inflect
the
desired
semantics.
epub:type
Attribute
type
http://www.idpf.org/2007/ops
Global attribute . MAY be specified on all elements.
A white space-separated list of property values, with restrictions as defined in § C.1 Vocabulary Association Mechanisms .
White space is the set of characters as defined in [ XML ].
The
epub:type
attribute
inflects
semantics
on
the
element
on
which
it
appears.
Its
value
is
one
or
more
white
space-separated
terms
stemming
from
external
vocabularies
associated
with
the
document
instance.
The
inflected
semantic
MUST
express
a
subclass
of
the
semantic
of
the
carrying
element.
In
the
case
of
semantically
neutral
elements,
such
as
the
[
HTML
]
div
and
span
elements,
the
inflected
semantic
MUST
NOT
attach
a
meaning
that
is
already
conveyed
by
an
existing
element
(e.g.,
that
a
div
represents
a
paragraph
or
section).
The
default
vocabulary
for
the
epub:type
attribute
is
the
Structural
Semantics
Vocabulary
.
Unprefixed
terms
that
are
not
part
of
the
this
vocabulary
MAY
be
included,
but
their
use
is
discouraged.
The
use
of
prefixes
is
the
preferred
method
for
adding
custom
semantics.
Refer
to
§
C.1
Vocabulary
Association
Mechanisms
for
more
information.
This appendix defines a general set of mechanisms by which attributes in this specification can reference terms from vocabularies, as well as EPUB-specific vocabularies that are used with the attributes.
EPUB
defines
a
formal
method
of
referencing
terms
and
properties
defined
in
metadata
and
semantic
vocabularies
using
the
property
data
type
.
The
epub:type
attribute
uses
this
data
type
in
EPUB
Content
Documents
and
Media
Overlay
Documents
to
add
semantic
inflections
,
for
example,
while
the
property
and
rel
attributes
use
the
data
type
to
define
properties
and
relationships
in
the
Package
Document
.
A property value is similar to a CURIE [ RDFA-CORE ] — it represents an IRI [ RFC3987 ] in compact form. The expression 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 reduce the complexity for authoring, each attribute that takes a property data type also defines a default vocabulary . Terms and properties referenced from the default vocabularies do not include a prefix as the mapping Reading Systems use to map to a IRI is predefined.
The power of the property data type lies in its easy extensibility. To incorporate new terms and properties, authors only need to declare a prefix . In another authoring convenience, this specification also reserves prefixes for many commonly-used publishing vocabularies (i.e., they do not have to be declared).
Additional details on the property data type and vocabulary association mechanism are provided in the following sections.
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-CORE ], and represents a subset of CURIEs.
After processing [ EPUB-RS-33 ], 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.
An empty string does not represent a valid property value, even though it is valid to the definition above.
A default vocabulary is one that does not require a prefix to be declared in order to use its terms and properties where a property value is expected. Terms and properties from a default vocabulary MUST always be unprefixed.
The
IRIs
associated
with
these
vocabularies
MUST
NOT
be
assigned
a
prefix
using
the
prefix
attribute.
Refer to the definition of each attribute that takes a property data type for more information about its default vocabulary.
prefix
Attribute
The
prefix
attribute
defines
prefix
mappings
for
use
in
property
values
.
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
prefix
attribute
MUST
only
be
attached
to
the
root
element
of
the
respective
format.
The attribute is not namespaced when used in the Package Document .
The
attribute
MUST
be
declared
in
the
namespace
http://www.idpf.org/2007/ops
when
declared
in
EPUB
Content
Documents
and
Media
Overlay
Documents
.
Note
that
for
embedded
SVG
,
prefixes
MUST
be
declared
on
the
[
HTML
]
root
html
element
.
To
avoid
conflicts,
the
prefix
attribute
MUST
NOT
be
used
to
declare
a
prefix
that
maps
to
the
default
vocabulary
.
The prefix '_' MUST NOT be declared as it is reserved for future compatibility with RDFa [ RDFA-CORE ] 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
[
DC11
]
elements
allowed
in
the
Package
Document
metadata
.
Although reserved prefixes are an authoring convenience, reliance on them can lead to interoperability issues. Validation tools will often reject new prefixes until the tools are updated, for example. Authors are strongly encouraged to declare all prefixes they use to avoid such issues.
Authors
MAY
use
reserved
prefixes
in
attributes
that
expect
a
property
value
without
declaring
them
in
a
prefix
attribute
.
Reserved
prefixes
SHOULD
NOT
be
overridden
in
the
prefix
attribute
.
The reserved prefixes availabe for use is context dependent:
Authors MAY use the following prefixes in Package Document attributes without having to declare them.
| Prefix | IRI |
|---|---|
| a11y | http://www.idpf.org/epub/vocab/package/a11y/# |
| dcterms | http://purl.org/dc/terms/ |
| marc | http://id.loc.gov/vocabulary/ |
| media | http://www.idpf.org/epub/vocab/overlays/# |
| onix | http://www.editeur.org/ONIX/book/codelists/current.html# |
| rendition | http://www.idpf.org/vocab/rendition/# |
| schema | http://schema.org/ |
| xsd | http://www.w3.org/2001/XMLSchema# |
Authors
MAY
use
the
following
reserved
prefixes
in
the
epub:type
attribute
without
having
to
declare
them.
| Prefix | IRI |
|---|---|
| msv | http://www.idpf.org/epub/vocab/structure/magazine/# |
| prism | http://www.prismstandard.org/specifications/3.0/PRISM_CV_Spec_3.0.htm# |
This section is non-normative.
The
properties
in
this
vocabulary
are
usable
in
the
meta
element's
property
attribute.
Properties
without
a
prefix
are
referenceable
using
the
base
IRI
http://idpf.org/epub/vocab/package/meta/#
.
meta
Properties
The
following
tables
define
properties
for
use
in
the
meta
element's
property
attribute.
Unless
indicated
otherwise
in
its
“Extends”
field,
the
properties
defined
in
this
section
are
used
to
define
subexpressions
:
in
other
words,
a
meta
element
carrying
a
property
defined
in
this
section
MUST
have
a
refines
attribute
referencing
a
resource
or
expression
being
augmented.
In each property definition, the Allowed values field indicates the expected type of value (using [ XMLSCHEMA-2 ] datatypes), the Cardinality field indicates the number of times the property MAY be attached to another property, and the Extends field identifies the properties it MAY be attached to.
| Name: |
alternate-script
|
|---|---|
| Description: |
The
This
property
is
typically
attached
to
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
more
|
| Extends: | All properties. |
| Name: |
belongs-to-collection
|
|---|---|
| Description: |
The
It
is
also
possible
chain
these
properties
using
the
To
allow
Reading
System
to
organize
collections
and
avoid
naming
collisions
(e.g.,
unrelated
collections
might
share
a
similar
name,
or
different
editions
of
a
collection
could
be
released),
an
identifier
SHOULD
be
provided
that
uniquely
identifies
the
instance
of
the
collection.
The
The
collection
MAY
more
precisely
define
its
nature
by
attaching
a
The
position
of
the
EPUB
Publication
within
the
collection
MAY
be
provided
by
attaching
a
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
more
|
| Extends: | Applies to the EPUB Publication, and can refine other instances of itself. |
| Name: |
collection-type
|
|---|---|
| Description: |
The
When
the
When a scheme is not specified, Reading Systems SHOULD recognize the following collection type values:
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
one
|
| Extends: |
belongs-to-collection
|
| Name: |
display-seq
|
|---|---|
| Description: |
The
This property only applies where precedence rules have not already been defined (e.g., precedence is given to creators based on their appearance in document order). |
| Allowed value(s): |
xsd:unsignedInt
|
| Cardinality: |
zero
or
one
|
| Extends: | All properties. |
| Name: |
file-as
|
|---|---|
| Description: |
The
file-as
property
provides
the
normalized
form
of
the
associated
property
for
sorting.
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
one
|
| Extends: | All properties. |
| Name: |
group-position
|
|---|---|
| Description: |
The
The
An EPUB Publication can belong to more than one group. |
| Allowed value(s): |
A
single
xsd:unsignedInt
or
series
of
decimal-separated
numbers
(e.g.,
1
or
2.2.1
).
|
| Cardinality: |
zero
or
one
|
| Extends: | All properties. |
| Name: |
identifier-type
|
|---|---|
| Description: |
The
When
the
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
one
|
| Extends: |
identifier
,
source
|
| Name: |
meta-auth
|
|---|---|
| Description: |
The
Use
of
the
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
one
|
| Extends: | All properties. |
| Name: |
role
|
|---|---|
| Description: |
The
When
the
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
one
|
| Extends: |
contributor
,
creator
|
| Name: |
source-of
|
|---|---|
| Description: |
The
This
specification
defines
the
|
| Allowed value(s): |
pagination
|
| Cardinality: |
zero
or
one
|
| Extends: |
dc:source
|
See [ EPUBA11yTech ] for information on how to provide accessible page navigation.
| Name: |
term
|
|---|---|
| Description: |
The
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
one
|
| Extends: |
subject
|
| Name: |
title-type
|
|---|---|
| Description: |
The
When
the
|
| Allowed value(s): |
xsd:string
|
| Cardinality: |
zero
or
one
|
| Extends: |
title
|
This section is non-normative.
The
properties
in
this
vocabulary
are
usable
in
the
metadata
link
element's
rel
and
properties
attributes.
Link
properties
without
a
prefix
are
referenceable
using
the
base
IRI
http://idpf.org/epub/vocab/package/link/#
.
The
following
values
can
be
used
in
the
link
element
rel
attribute
to
establish
the
relationship
of
the
resource
referenced
in
the
href
attribute
.
| Name: |
acquire
|
|---|---|
| Description: |
The
acquire
keyword
is
used
with
EPUB
Previews
to
identify
where
the
full
version
of
the
EPUB
Publication
can
be
acquired.
|
| Cardinality: |
Zero
or
more
|
| Extends: |
Only
applies
to
the
EPUB
Publication
or
collection.
MUST
NOT
be
used
when
the
refines
attribute
is
present.
|
| Example: |
<link
rel="acquire"
href="http://example.org/book/9781448103706"
media-type="text/html"/>
|
| Name: |
alternate
|
|---|---|
| Description: |
The
|
| Cardinality: |
Zero
or
more
|
| Extends: |
Only
applies
to
the
EPUB
Publication
or
collection.
MUST
NOT
be
used
when
the
refines
attribute
is
present.
|
| Example: |
<link
rel="alternate"
href="package.json"
media-type="application/json-ld"/>
|
| Name: |
marc21xml-record
|
|---|---|
| Description: |
Use
of
the
marc21xml-record
keyword
is
deprecated.
It
is
replaced
by
the
record
keyword
with
the
media-type
attribute
value
"
application/marcxml+xml
".
|
| Cardinality: |
Zero
or
one
|
| Extends: |
Only
applies
to
the
EPUB
Publication
or
collection.
MUST
NOT
be
used
when
the
refines
attribute
is
present.
|
| Example: |
<link
rel="marc21xml-record"
href="pub/meta/nor-wood-marc21.xml"/>
|
| Name: |
mods-record
|
|---|---|
| Description: |
Use
of
the
mods-record
keyword
is
deprecated.
It
is
replaced
by
the
record
keyword
with
the
media-type
attribute
value
"
application/mods+xml
".
|
| Cardinality: |
Zero
or
one
|
| Extends: |
Only
applies
to
the
EPUB
Publication
or
collection.
MUST
NOT
be
used
when
the
refines
attribute
is
present.
|
| Example: |
<link
rel="mods-record"
href="pub/meta/nor-wood-mods.xml"/>
|
| Name: |
onix-record
|
|---|---|
| Description: |
Use
of
the
onix-record
keyword
is
deprecated.
It
is
replaced
by
the
record
keyword
with
the
properties
attribute
value
onix
.
|
| Cardinality: |
Zero
or
one
|
| Extends: |
Only
applies
to
the
EPUB
Publication
or
collection.
MUST
NOT
be
used
when
the
refines
attribute
is
present.
|
| Example: |
<link
rel="onix-record"
href="pub/meta/nor-wood-onix.xml"/>
|
| Name: |
record
|
|---|---|
| Description: |
Indicates that the referenced resource is a metadata record.
The
media
type
of
the
record
is
identified
in
the
For a list of commonly-linked metadata record types, refer to the EPUB Linked Metadata Guide
If
the
type
of
record
cannot
be
identified
from
the
media
type,
an
identifier
property
can
be
assigned
in
the
|
| Cardinality: |
Zero
or
more
|
| Extends: |
Only
applies
to
the
EPUB
Publication
or
collection.
MUST
NOT
be
used
when
the
refines
attribute
is
present.
|
| Example: |
<link
rel="record"
href="book/52.atom"
media-type="application/atom+xml;type=entry;profile=opds-catalog"/>
|
| Name: |
voicing
|
|---|---|
| Description: |
Indicates that the referenced audio file provides an aural representation of the expression or resource (typically, the title or creator) specified by the refines attribute.
The
media
type
of
the
audio
file
is
identified
in
the
|
| Cardinality: |
Zero
or
more
|
| Extends: |
All
properties.
The
refines
attribute
MUST
be
present
when
this
value
is
used.
|
| Example: |
<link
refines="#title"
rel="voicing"
media-type="audio/mpeg"
href="title.mp3"
/>
|
| Name: |
xml-signature
|
|---|---|
| Description: |
Use
of
the
xml-signature
keyword
is
deprecated.
It
is
not
replaced
by
another
linking
method.
Identification
of
XML
signatures
will
be
addressed
in
a
future
version
of
EPUB.
|
| Cardinality: |
Zero
or
more
|
| Extends: | All properties. |
| Example: |
<link
refines="#meta-authority-01"
rel="xml-signature"
href="../META-INF/signatures.xml#MAI-Signature"/>
|
| Name: |
xmp-record
|
|---|---|
| Description: |
Use
of
the
xmp-record
keyword
is
deprecated.
It
is
replaced
by
the
record
keyword
with
the
properties
attribute
value
xmp
.
|
| Cardinality: |
Zero
or
one
|
| Extends: |
Only
applies
to
the
EPUB
Publication
or
collection.
MUST
NOT
be
used
when
the
refines
attribute
is
present.
|
| Example: |
<link
rel="xmp-record"
href="pub/meta/nor-wood-xmp.xml"/>
|
The
following
values
can
be
used
in
the
link
element's
properties
attribute
to
establish
the
type
of
record
a
referenced
resource
represents.
These
values
are
provided
for
record
formats
that
cannot
be
uniquely
identified
by
their
media
type.
| Name: |
onix
|
|---|---|
| Description: |
The
onix
property
indicates
the
referenced
resource
is
an
ONIX
record
[
ONIX
].
|
| Example: |
<link
rel="record"
href="pub/meta/nor-wood-onix.xml"
media-type="application/xml"
properties="onix"/>
|
| Name: |
xmp
|
|---|---|
| Description: |
The
xmp
property
indicates
the
referenced
resource
is
an
XMP
record
[
XMP
].
|
| Example: |
<link
rel="record"
href="pub/meta/nor-wood-xmp.xml"
media-type="application/xml"
properties="xmp"/>
|
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.
The
base
IRI
for
referencing
these
properties
is
http://www.idpf.org/vocab/rendition/#
.
The
"
rendition:
"
prefix
is
reserved
for
use
with
the
package
rendering
properties
and
does
not
have
to
be
declared
in
the
Package
Document.
rendition:flow
Property
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.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).
The
following
values
are
defined
for
use
with
the
rendition:flow
property:
Dynamically paginate all overflow content.
Render all Content Documents such that overflow content is scrollable, and the EPUB Publication represented by the given Rendition is presented as one continuous scroll from spine item to spine item (except where locally overridden ).
Note that Authors SHOULD NOT create publications in which different resources have different block flow directions, as continuous scrolled rendition in EPUB Reading Systems would be problematic.
Render all Content Documents such that overflow content is scrollable, and each spine item is presented as a separate scrollable document.
Render overflow content using the Reading System default method or a user preference, whichever is applicable.
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
[
CSSSnapshot
]
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.
Authors
MAY
specify
the
following
properties
locally
on
spine
itemref
elements
to
override
the
global
value
for
the
given
spine
item:
Only one of these overrides is allowed on any given spine item.
rendition:align-x-center
Property
The
rendition:align-x-center
property
specifies
that
the
given
spine
item
should
be
centered
horizontally
in
the
viewport
or
spread.
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.
The following properties belong to the Package Rendering Vocabulary. Refer to their respective definitions in § 5. Fixed Layouts for the details of their use.
| Properties | Defined in |
|---|---|
| § 5.2.1 Layout |
| § 5.2.2 Orientaton |
| § 5.2.3 Synthetic Spreads |
| § 5.2.4 Spread Placement |
| § 5.2.5 Viewport Dimensions (Deprecated) |
This section is non-normative.
The
properties
in
this
vocabulary
are
usable
in
the
manifest
item
element's
properties
attribute.
Properties
without
a
prefix
are
referenceable
using
the
base
IRI
http://idpf.org/epub/vocab/package/item/#
.
item
Properties
The
following
tables
define
properties
for
use
in
the
manifest
item
element
properties
attribute
.
The Applies to field indicates which Publication Resource type(s) the given property MAY be specified on, the Cardinality field indicates the number of times the property MUST appear within the Package Document scope, and the Usage field indicates usage conditions.
| Name: |
cover-image
|
|---|---|
| Description: |
The
cover-image
property
identifies
the
described
Publication
Resource
as
the
cover
image
for
the
Publication.
|
| Applies to: | All raster and vector image types |
| Cardinality: |
Zero
or
one
|
| Usage: | Optional. |
| Name: |
mathml
|
|---|---|
| Description: |
The
mathml
property
indicates
that
the
described
Publication
Resource
contains
one
or
more
instances
of
MathML
markup.
|
| Applies to: | EPUB Content Documents |
| Cardinality: |
Zero
or
more
|
| Usage: | MUST be set if and only if the criterion specified in the description is met. |
| Name: |
remote-resources
|
|---|---|
| Description: |
The
Refer to § 2.2.2 Resource Locations for more information. |
| Applies to: | All Publication Resources with the capability of internal referencing (e.g., XHTML Content Documents , SVG Content Documents , CSS Style Sheets and Media Overlay Documents ). |
| Cardinality: |
Zero
or
more
|
| Usage: | MUST be set if and only if the criterion specified in the description is met. |
| Name: |
scripted
|
|---|---|
| Description: |
The
scripted
property
indicates
that
the
described
Publication
Resource
is
a
Scripted
Content
Document
(i.e.,
contains
scripted
content
and/or
HTML
form
elements).
|
| Applies to: | EPUB Content Documents |
| Cardinality: |
Zero
or
more
|
| Usage: | MUST be set if and only if the criterion specified in the description is met. |
| Name: |
svg
|
|---|---|
| Description: |
The
This
property
MUST
be
set
when
SVG
markup
is
included
directly
in
the
resource
and
MAY
be
set
when
the
SVG
is
referenced
from
the
resource
(e.g.,
from
an
[
HTML
]
|
| Applies to: | XHTML Content Documents ; the value is implied for SVG Content Documents . |
| Cardinality: |
Zero
or
more
|
| Usage: | MUST be set if and only if the criterion specified in the description is met. |
| Name: |
switch
|
|---|---|
| Description: |
The
|
| Applies to: | XHTML Content Documents . |
| Cardinality: |
Zero
or
more
|
| Usage: | MUST be set if and only if the criterion specified in the description is met. |
The
mathml
,
remote-resources
,
scripted
and
switch
properties
MUST
be
specified
whenever
the
resource
referenced
by
an
item
matches
their
respective
definitions.
These
properties
do
not
apply
recursively
to
content
included
into
a
resource
(e.g.,
via
the
HTML
iframe
element).
For
example,
if
a
non-scripted
XHTML
Content
Document
embeds
a
scripted
Content
Document,
only
the
embedded
document's
manifest
item
properties
attribute
will
have
the
scripted
value.
manifest
item
element
that
represents
the
EPUB
Navigation
Document
.
<item
properties="nav"
id="c1"
href="c1.xhtml"
media-type="application/xhtml+xml"
/>
manifest
item
element
that
represents
the
cover
image.
<item
properties="cover-image"
id="ci"
href="cover.svg"
media-type="image/svg+xml"
/>
manifest
item
element
representing
a
Scripted
Content
Document
that
also
contains
embedded
MathML.
<item
properties="scripted
mathml"
id="c2"
href="c2.xhtml"
media-type="application/xhtml+xml"
/>
This section is non-normative.
The
properties
in
this
vocabulary
are
usable
in
the
spine
itemref
element's
properties
attribute.
Properties
are
referenceable
using
the
base
IRI
http://idpf.org/epub/vocab/package/itemref/#
.
itemref
Properties
The
following
tables
define
properties
for
use
in
the
itemref
element
properties
attribute
.
| Name: |
page-spread-left
|
|---|---|
| Description: |
The
page-spread-left
property
indicates
that
the
first
page
of
the
associated
item
element's
EPUB
Content
Document
represents
the
left-hand
side
of
a
two-page
spread.
|
| Name: |
page-spread-right
|
|---|---|
| Description: |
The
page-spread-right
property
indicates
that
the
first
page
of
the
associated
item
element's
EPUB
Content
Document
represents
the
right-hand
side
of
a
two-page
spread.
|
spine
.
<spine>
<itemref idref="title"/>
<itemref idref="ps-1-l" properties="page-spread-left"/>
<itemref idref="ps-1-r" properties="page-spread-right"/>
<itemref idref="toc"/>
…
</spine>
This section is non-normative.
The
properties
in
this
vocabulary
are
usable
in
the
meta
element's
property
attribute.
The
base
IRI
for
referencing
this
vocabulary
is
http://www.idpf.org/epub/vocab/overlays/#
.
The
prefix
"
media:
"
is
reserved
for
use
with
properties
in
this
vocabulary
and
does
not
have
to
be
declared
in
the
Package
Document.
| Name: |
active-class
|
|---|---|
| Description: | Author-defined CSS class name to apply to the currently-playing EPUB Content Document element. |
| Allowed value(s): |
xsd:string
|
| Cardinality: |
Zero
or
one
|
| Example: |
<meta
property="media:active-class">-epub-media-overlay-active</meta>
|
| Name: |
duration
|
|---|---|
| Description: | The duration of the entire presentation or of a specific Media Overlay. The specified durations account for the audio clips known at authoring time, and so exclude live streaming from external resources and speech synthesis. |
| Allowed value(s): |
MUST be a [ SMIL3 ] clock value . |
| Cardinality: | Exactly one for a given Rendition and for each Media Overlay. |
| Example: |
<meta
property="media:duration">1:36:20</meta>
|
| Name: |
narrator
|
|---|---|
| Description: | Name of the narrator. |
| Allowed value(s): |
xsd:string
|
| Cardinality: |
Zero
or
more
|
| Example: |
<meta
property="media:narrator">Joe
Speaker</meta>
|
| Name: |
playback-active-class
|
|---|---|
| Description: | Author-defined CSS class name to apply to the EPUB Content Document's document element when playback is active. |
| Allowed value(s): |
xsd:string
|
| Cardinality: |
Zero
or
one
|
| Example: |
<meta
property="media:playback-active-class">-epub-media-overlay-playing</meta>
|
While the EPUB Structural Semantics vocabulary is generally host language agnostic, it has been constructed primarily to enable semantic inflection of elements in the HTML vocabulary.
The HTML usage context fields indicate contexts in HTML documents where the given property is considered relevant. Authors may use the properties on HTML markup elements not specifically listed, but must ensure that the semantics they express represent a subset of the carrying element's semantics and do not attach an existing element's meaning to a semantically neutral element.
When processing HTML documents, Reading Systems may ignore such non-compliant properties, unless their usage context is explicitly overridden or extended by the host specification.
The Usage Details sections identify IDPF specifications that define or utilize the specified properties.
A section that introduces the work, often consisting of a marketing image, the title, author and publisher, and select quotes and reviews.
Preliminary material to the main content of a publication, such as tables of contents, dedications, etc.
The main content of a publication.
Ancillary material occurring after the main content of a publication, such as indices, appendices, etc.
A component of a collection.
A major structural division in a work that contains a set of related sections dealing with a particular subject, narrative arc or similar encapsulated theme.
A major thematic section of content in a work.
A major sub-division of a chapter.
A major structural division that may also appear as a substructure of a part (esp. in legislation).
Sections and components that typically occur in the publication bodymatter.
A short summary of the principle ideas, concepts and conclusions of the work, or of a section or excerpt within it.
HTML usage context: section , grouping content
An introductory section that precedes the work, typically not written by the author of the work.
HTML usage context: section , grouping content
An introductory section that precedes the work, typically written by the author of the work.
HTML usage context: section , grouping content
An introductory section that sets the background to a work, typically part of the narrative.
HTML usage context: section , grouping content
A preliminary section that typically introduces the scope or nature of the work.
HTML usage context: section , grouping content
A section in the beginning of the work, typically containing introductory and/or explanatory prose regarding the scope or nature of the work's content
HTML usage context: section , grouping content
A concluding section or statement that summarizes the work or wraps up the narrative.
HTML usage context: section , grouping content
A concluding section of narrative that wraps up or comments on the actions and events of the work, typically from a future perspective.
HTML usage context: section , grouping content
A closing statement from the author or a person of importance, typically providing insight into how the content came to be written, its significance, or related events that have transpired since its timeline.
HTML usage context: section , grouping content
A quotation set at the start of the work or a section that establishes the theme or sets the mood.
HTML usage context: section , grouping content
Preliminary sections and components, typically occuring in the publication frontmatter.
The title page of the work.
HTML usage context: section , grouping content
The half title page of the work.
HTML usage context: section , grouping content
The copyright page of the work.
HTML usage context: section , grouping content
Marketing section used to list related publications.
HTML usage context: section , grouping content
A section or statement that acknowledges significant contributions by persons, organizations, governments and other entities to the realization of the work.
HTML usage context: section , grouping content
Information relating to the publication or distribution of the work.
HTML usage context: section , grouping content
A formal statement authorizing the publication of the work.
HTML usage context: section , grouping content
A list of contributors to the work.
HTML usage context: section , grouping content
Acknowledgments of previously published parts of the work, illustration credits, and permission to quote from copyrighted material.
HTML usage context: section , grouping content
A set of corrections discovered after initial publication of the work, sometimes referred to as corrigenda.
HTML usage context: section , aside , grouping content
An inscription at the front of the work, typically addressed in tribute to one or more persons close to the author.
HTML usage context: section , grouping content
A record of changes made to a work.
HTML usage context: section , grouping content
A detailed analysis of a specific topic.
Inherits from: xhv:complementary
HTML usage context: sectioning content
Helpful information that clarifies some aspect of the content or assists in its comprehension.
Inherits from: xhv:complementary
HTML usage context: aside , phrasing content
Replaced by: tip
Content, both textual and graphical, that is offset in the margin.
Inherits from: xhv:complementary
HTML usage context: aside , phrasing content
Replaced by: aside
Notifies the user of consequences that might arise from an action or event. Examples include warnings, cautions and dangers.
HTML usage context: section , grouping content
A distinctively placed or highlighted quotation from the current content designed to draw attention to a topic or highlight a key point.
Inherits from: xhv:complementary
HTML usage context: aside
Secondary or supplementary content, typically formatted as an inset or box.
Inherits from: xhv:complementary
HTML usage context: aside
Replaced by: aside
Helpful information that clarifies some aspect of the content or assists in its comprehension.
Inherits from: xhv:complementary
HTML usage context: aside , phrasing content
A warning.
HTML usage context: section , grouping content
Replaced by: notice
The title appearing on the first page of a work or immediately before the text.
Inherits from: title
HTML usage context: heading content . This property should only appear once within the document scope.
The full title of the work, either simple, in which case it is identical to title , or compound, in which case it consists of a title and a subtitle .
Inherits from: title
Same as: http://purl.org/dc/terms/title
HTML usage context: heading content . This property should only appear once within the document scope.
The title of the work as displayed on the work's cover.
Inherits from: title
HTML usage context: heading content . This property should only appear once within the document scope.
The primary name of a document component, such as a list, table or figure.
HTML usage context: heading content , phrasing content descendants of heading content .
An explanatory or alternate title for the work, or a section or component within it.
Inherits from: title
HTML usage context: heading content , phrasing content descendants of heading content , paragraphs , divs
The text label that precedes an ordinal in a component title (e.g., 'Chapter', 'Part', 'Figure', 'Table').
Inherits from: title
HTML usage context: Phrasing content descendants of heading content , li and figcaption
An ordinal specifier for a component in a sequence of components (e.g., '1', 'IV', 'B-1').
Inherits from: title
HTML usage context: Phrasing content descendants of heading content , li and figcaption
A structurally insignificant heading that does not contribute to the hierarchical structure of the work.
HTML usage context: flow content , typically p , div or span
An explicit designation or description of a learning objective or a reference to an explicit learning objective.
HTML usage context: flow content , phrasing content
A collection of learning-objectives .
HTML usage context: sectioning content , grouping content
The understanding or ability a student is expected to achieve as a result of a lesson or activity.
HTML usage context: flow content
A collection of learing-outcomes .
HTML usage context: sectioning content , grouping content
A resource provided to enhance learning, or a reference to such a resource.
HTML usage context: flow content
A collection of learning-resources .
HTML usage context: sectioning content , grouping content
A formal set of expectations or requirements typically issued by a government or a standards body.
HTML usage context: sectioning content , phrasing content
A collection of learning-standards .
HTML usage context: sectioning content , grouping content
The component of a self-assessment problem that provides the answer to the question.
HTML usage context: aside , grouping content
A collection of answers .
HTML usage context: sectioning content , grouping content
A test, quiz, or other activity that helps measure a student's understanding of what is being taught.
HTML usage context: sectioning content
A collection of assessments .
HTML usage context: sectioning content
Instruction to the reader based on the result of an assessment.
HTML usage context: grouping content , phrasing content
A problem that requires the reader to input a text answer to complete a sentence, statement or similar.
HTML usage context: aside , grouping content
A problem with a free-form solution.
HTML usage context: aside , grouping content
A section of content structured as a series of questions and answers, such as an interview or list of frequently asked questions.
HTML usage context: lists or sectioning content
A problem that requires the reader to match the contents of one list with the corresponding items in another list.
HTML usage context: aside , grouping content
A problem with a set of potential answers to choose from ‒ some, all or none of which may be correct.
HTML usage context: aside , grouping content
A review exercise or sample.
See also: practices
HTML usage context: aside , grouping content
The component of a self-assessment problem that identifies the question to be solved.
HTML usage context: grouping content
A collection of practices .
HTML usage context: sectioning content
A problem with either a true or false answer.
HTML usage context: aside , grouping content
An individual frame, or drawing.
HTML usage context: li
Usage details: EPUB Region-Based Navigation
A group of panels (e.g., a strip).
HTML usage context: li
Usage details: EPUB Region-Based Navigation
An area in a comic panel that contains the words, spoken or thought, of a character.
HTML usage context: li
Usage details: EPUB Region-Based Navigation
An area of text in a comic panel . Used to represent titles, narrative text, character dialogue (inside a balloon or not) and similar.
HTML usage context: li
Usage details: EPUB Region-Based Navigation
An area of text in a comic panel that represents a sound.
HTML usage context: li
Usage details: EPUB Region-Based Navigation
Explanatory information about passages in the work.
Inherits from: xhv:complementary
HTML usage context: aside , phrasing content
Replaced by: Open Annotation in EPUB
A note. This property does not carry spatial positioning semantics, as do the footnote and endnote properties. It can be used to identify footnotes, endnotes, marginal notes, inline notes, and similar when legacy naming conventions are not desired.
HTML usage context: On the aside element when identifying a single note, or on descendants of sectioning content when identifying individual notes in a group (refer to footnotes and endnotes ).
Ancillary information, such as a citation or commentary, that provides additional context to a referenced passage of text.
See also: footnotes
HTML usage context: On the aside element when identifying a single footnote, or on descendants of sectioning content when identifying individual footnotes in a group (refer to footnotes and endnotes ).
One of a collection of notes that occur at the end of a work, or a section within it, that provides additional context to a referenced passage of text.
See also: endnotes
HTML usage context: On the aside element when identifying a single endnote, or on descendants of sectioning content when identifying individual endnotes in a group (refer to footnotes and endnotes ).
A note appearing in the rear (backmatter) of the work, or at the end of a section.
See also: rearnotes
HTML usage context: On the aside element when identifying a single rearnote, or on descendants of sectioning content when identifying individual rearnotes in a group (refer to footnotes and rearnotes ).
Replaced by: endnote
A collection of footnotes .
See also: footnote
HTML usage context: sectioning content
A collection of notes at the end of a work or a section within it.
See also: endnote
HTML usage context: sectioning content
A collection of notes appearing at the rear (backmatter) of the work, or at the end of a section.
See also: rearnote
HTML usage context: sectioning content
Replaced by: endnotes
A reference to an annotation.
Inherits from: xhv:link
See also: annotation
HTML usage context: a
Replaced by: Open Annotation in EPUB
A reference to a bibliography entry .
Inherits from: xhv:link
HTML usage context: a
A reference to a glossary definition .
Inherits from: xhv:link
HTML usage context: a
A reference to a note, typically appearing as a superscripted number or symbol in the main body of text.
Inherits from: xhv:link
See also: note
HTML usage context: a
A link that allows the user to return to a related location in the content (e.g., from a footnote to its reference or from a glossary definition to where a term is used).
Inherits from: xhv:link
HTML usage context: a
Terms for describing components at the phrasing level.
An acknowledgment of the source of integrated content from third-party sources, such as photos. Typically identifies the creator, copyright and any restrictions on reuse.
HTML usage context: phrasing content
A key word or phrase.
HTML usage context: phrasing content
A phrase or sentence serving as an introductory summary of the containing paragraph.
HTML usage context: phrasing content
A phrase or sentence serving as a concluding summary of the containing paragraph.
HTML usage context: phrasing content
A separator denoting the position before which a break occurs between two contiguous pages in a statically paginated version of the content.
HTML usage context: phrasing and flow content, where the value of the carrying elements title attribute takes precedence over element content for the purposes of representing the pagebreak value
A navigational aid that provides a list of links to the pagebreaks in the content.
HTML usage context: sectioning content
A structure containing data or content laid out in tabular form.
HTML usage context: Not Allowed
Media Overlays usage context: Identifies a seq or par as an escapable or skippable table structure.
A row of data or content in a tabular structure.
HTML usage context: Not Allowed
Media Overlays usage context: Identifies a seq or par as an escapable or skippable table row.
A single cell of tabular data or content.
HTML usage context: Not Allowed
Media Overlays usage context: Identifies a seq or par as an escapable or skippable table cell.
A structure that contains an enumeration of related content items.
HTML usage context: Not Allowed
Media Overlays usage context: Identifies a seq or par as an escapable or skippable list structure.
A single item in an enumeration.
HTML usage context: Not Allowed
Media Overlays usage context: Identifies a seq or par as an escapable or skippable list item.
A non-normative schema for Package Documents is available at https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/package-30.nvdl .
Validation using this schema requires a processor that supports [ NVDL ], [ RelaxNG-Schema ], [ ISOSchematron ] and [ XMLSCHEMA-2 ].
The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.
These schemas may be updated and corrected outside of formal revisions of this specification. As a result, they are subject to change at any time.
container.xml
The
schema
for
container.xml
files
is
available
at
https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/ocf-container-30.nvdl
.
Validation using this schema requires a processor that supports [ RelaxNG-Schema ] and [ XMLSCHEMA-2 ].
encryption.xml
The
schema
for
encryption.xml
files
is
included
in
[
XMLSEC-RNGSCHEMA-20130411
].
signatures.xml
The
schema
for
signatures.xml
files
is
included
in
[
XMLSEC-RNGSCHEMA-20130411
].
The schema for Media Overlays is available at https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/media-overlay-30.nvdl .
Validation using this schema requires a processor that supports [ NVDL ], [ RelaxNG-Schema ], [ ISOSchematron ] and [ XMLSCHEMA-2 ].
The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.
This section is non-normative.
The following example demonstrates the use of the OCF format to contain a signed and encrypted EPUB Publication within an OCF ZIP Container .
This section is non-normative.
The following are examples of allowed clock values:
5:34:31.396
=
5
hours,
34
minutes,
31
seconds
and
396
milliseconds
124:59:36
=
124
hours,
59
minutes
and
36
seconds
0:05:01.2
=
5
minutes,
1
second
and
200
milliseconds
0:00:04
=
4
seconds
09:58
=
9
minutes
and
58
seconds
00:56.78
=
56
seconds
and
780
milliseconds
76.2s
=
76.2
seconds
=
76
seconds
and
200
milliseconds
7.75h
=
7.75
hours
=
7
hours
and
45
minutes
13min
=
13
minutes
2345ms
=
2345
milliseconds
12.345
=
12
seconds
and
345
milliseconds
This section is non-normative.
application/oebps-package+xml
Media
Type
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 specifications are maintained and defined by the W3C ’s EPUB 3 Community Group .
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 Packages 3.2 specification 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 Packages 3.2 specification located at https://www.w3.org/publishing/epub32/epub-packages.html .
The
EPUB
Packages
3.2
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
Bluefire Reader
Calibre
Google Play Books
Kobo
Microsoft Edge
Readium
none
.opf
TEXT
A
registry
of
linking
schemes
is
maintained
at
http://www.idpf.org/epub/linking/
.
Some
of
these
schemes
define
custom
fragment
identifiers
that
resolve
to
application/oebps-package+xml
documents.
public-epub3@w3.org
COMMON
The published specification is a work product of the World Wide Web Consortium’s EPUB 3 Community Group. W3C has change control over this specification.
application/epub+zip
Media
Type
This section is non-normative.
This
appendix
registers
the
media
type
application/epub+zip
for
the
EPUB
Open
Container
Format
(OCF).
An OCF ZIP Container , or EPUB Container , file is a container technology based on the [ ZIP ] archive format. It is used to encapsulate the Renditions of EPUB Publications. OCF and its related standards are maintained and defined by the World Wide Web Consortium ( W3C ).
application
epub+zip
None.
None.
OCF
ZIP
Container
files
are
binary
files
encoded
in
the
application/zip
media
type.
All processors that read OCF ZIP Container files should rigorously check the size and validity of data retrieved.
In
addition,
because
of
the
various
content
types
that
can
be
embedded
in
OCF
ZIP
Container
files,
application/epub+zip
may
describe
content
that
poses
security
implications
beyond
those
noted
here.
However,
only
in
cases
where
the
processor
recognizes
and
processes
the
additional
content,
or
where
further
processing
of
that
content
is
dispatched
to
other
processors,
would
security
issues
potentially
arise.
In
such
cases,
matters
of
security
would
fall
outside
the
domain
of
this
registration
document.
Security
considerations
that
apply
to
application/zip
also
apply
to
OCF
ZIP
Container
files.
None.
This
media
type
registration
is
for
the
EPUB
Open
Container
Format
(OCF),
as
described
by
the
EPUB
Open
Container
Format
(OCF)
3.2
specification
located
at
https://www.w3.org/publishing/epub32/epub-ocf.html
.
The
EPUB
OCF
3.2
specification
supersedes
both
RFC
4839
and
the
Open
Container
Format
2.0.1
specification,
which
is
located
at
http://www.idpf.org/doc_library/epub/OCF_2.0.1_draft.doc
,
and
which
also
uses
the
application/epub+zip
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.
0:
PK
0x03
0x04
,
30:
mimetype
,
38:
application/epub+zip
OCF
ZIP
Container
files
are
most
often
identified
with
the
extension
.epub
.
ZIP
A
registry
of
linking
schemes
is
maintained
at
http://www.idpf.org/epub/linking/
.
Some
of
these
schemes
define
custom
fragment
identifiers
that
resolve
to
application/epub+zip
and
application/oebps-package+xml
documents.
public-epub3@w3.org
COMMON
The published specification is a work product of the World Wide Web Consortium ( W3C )’s EPUB 3 Community Group. The W3C has change control over this specification.
This section is non-normative.
EPUB 3 is developed by the W3C 's EPUB 3 Working Group .
The EPUB 3.X revision was led by:
In addition to the editors, this version of EPUB would not have been possible without significant contributions from:
A section of supplemental information located after the primary content that informs the content but is not central to it.
HTML usage context: sectioning content
A short section of production notes particular to the edition (e.g., describing the typeface used), often located at the end of a work.
HTML usage context: sectioning content , grouping content
A collection of credits .
HTML usage context: sectioning content , grouping content
A collection of keywords .
HTML usage context: sectioning content , grouping content
A navigational aid that provides a detailed list of links to key subjects, names and other important topics covered in the work.
HTML usage context: sectioning content , body
Usage details: EPUB Indexes – index property
Narrative or other content to assist users in using the index.
Required parent context: index
HTML usage context: sectioning content , header
Usage details: EPUB Indexes – index-headnotes property
List of symbols, abbreviations or special formatting used in the index, and their meanings.
Required parent context: index-headnotes
HTML usage context: sectioning content , dl
Usage details: EPUB Indexes – index-legend property
Collection of consecutive main entries that share a common characteristic, for example the starting letter of the main entries.
Required parent context: index
HTML usage context: sectioning content
Usage details: EPUB Indexes – index-group property
Collection of consecutive main entries or subentries.
Required parent context: index-entry , index-group and index
HTML usage context: ul ; this property is implied when the ul has an ancestor of index except within index-headnotes
Usage details: EPUB Indexes – index-entry-list property
One term with any attendant subentries, locators, cross references, and/or editorial note.
Required parent context: index-entry-list
HTML usage context: li ; this property is implied when parent ul is of type index-entry-list (implicit or explicit)
Usage details: EPUB Indexes – index-entry property
Word, phrase, string, glyph or image representing the indexable content.
Required parent context: index-xref-related , index-entry and index-xref-preferred
HTML usage context: phrasing content ; typically span
Usage details: EPUB Indexes – index-term property
Editorial note pertaining to a single entry.
Required parent context: index-entry
HTML usage context: flow content
Usage details: EPUB Indexes – index-editor-note property
A reference to an occurrence of the indexed content in the publication.
Required parent context: index-entry , index-locator-list and index-locator-range
HTML usage context: a ; this property is implied when parent context is index-locator-list or index-locator-range
Usage details: EPUB Indexes – index-locator property
Collection of sequential locators or locator ranges.
Required parent context: index-entry
HTML usage context: ul
Usage details: EPUB Indexes – index-locator-list property
A pair of locators that connects a term to a range of content rather than a single point.
Required parent context: index-locator-list and index-entry
HTML usage context: flow content
Usage details: EPUB Indexes – index-locator-range property
Reference from one term to one or more preferred terms or term categories in an index (analogous to "See xxx").
Required parent context: index-entry
HTML usage context: flow content
Usage details: EPUB Indexes – index-xref-preferred property
Reference from one term to one or more related terms or term categories in an index (analogous to "See also xxx").
Required parent context: index-entry
HTML usage context: flow content
Usage details: EPUB Indexes – index-xref-related property
Word, phrase, string, glyph or image representing a category of terms in the index.
Required parent context: index-xref-related and index-xref-preferred
HTML usage context: a
Usage details: EPUB Indexes – index-term-category property
Wrapper for a list of the term categories belonging to an index.
Required parent context: index-xref-related and index-xref-preferred
HTML usage context: a
Usage details: EPUB Indexes – index-term-categories property
A brief dictionary of new, uncommon or specialized terms used in the content.
HTML usage context: dl , sectioning content
A glossary term.
Required parent context: glossary
HTML usage context: The glossterm property is implied on dt elements within a dl element marked with the glossary property.
The definition of a term in a glossary .
Required parent context: glossary
HTML usage context: The glossdef property is implied on dd elements within a dl element marked with the glossary property.
A list of external references cited in the work, which may be to print or digital sources.
HTML usage context: sectioning content
A single reference to an external source in a bibliography . A biblioentry typically provides more detailed information than its reference(s) in the content (e.g., full title, author(s), publisher, publication date, etc.).
Required parent context: bibliography
HTML usage context: grouping content