EPUB 3.1

Recommended Specification 5 January 2017

This version

http://www.idpf.org/epub/31/spec/epub-spec-20170105.html

Latest version

http://www.idpf.org/epub3/latest

Previous version

http://www.idpf.org/epub/31/spec/epub-spec-20161130.html

Previous recommendation

http://www.idpf.org/epub/301/spec/epub-publications-20140626.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Errata

Editors

Markus Gylling, International Digital Publishing Forum (IDPF)

Tzviya Siegman, John Wiley & Sons

Matt Garrish, Invited Expert

The complete EPUB 3.1 specification is also available for download as an EPUB 3.0 and 3.1 Publication.

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Terminology

1.3. Typographic Conventions

1.4. Conformance Statements

2. Organization

2.1. Specifications

2.2. Road Map

3. Conformance

3.1. EPUB Publications

3.2. EPUB Reading Systems

4. Publication Resources

4.1. Core Media Types

4.1.1. Introduction

4.1.2. Supported Media Types

4.1.3. Foreign Resources

4.2. Resource Locations

4.3. XML Conformance

A. Obsolete Features

Index

Acknowledgements and Contributors

References

  1 Overview

  1.1 Purpose and Scope

This section is informative

This specification, EPUB 3.1, 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.

EPUB has been widely adopted as the format for digital books (ebooks), and EPUB 3.1 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.1 format will be utilized for a broad range of content, including books, magazines and educational, professional and scientific publications.

EPUB 3.1 is modular in nature: it consists of a family of specifications that define the core features and functionality of the standard. This specification represents the primary entry point to standard, but the specifications listed in Specifications are all a part of EPUB 3.1. An index to key concepts and definitions defined across these specifications is provided at the end of this specification.

The informative [EPUB3 Overview] provides a general introduction to EPUB 3.1. A list of technical changes from EPUB 3.0.1, the previous version of the standard, is also available in the informative [EPUB3 Changes].

  1.2 Terminology

The following terms are specific to EPUB 3.1. They are capitalized wherever used.

Only the first instance of a term in a section is linked to its definition.

Author

The person(s) or organization responsible for the creation of an EPUB Publication. The Author is not necessarily the creator of the content.

Content Display Area

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.

Core Media Type

A media type [RFC2046] that EPUB Reading Systems have to support. Refer to Publication Resources for more information.

Core Media Type Resource

A Publication Resource that has a Core Media Type so does not require the provision of a fallback (cf. Foreign Resource).

EPUB Container

The ZIP-based packaging and distribution format for EPUB Publications defined in OCF ZIP Container [OCF 3.1].

EPUB Content Document

A Publication Resource that conforms to one of the EPUB Content Document definitions (HTML or SVG).

An EPUB Content Document is a Core Media Type Resource, so can be included in the EPUB Publication without the provision of fallbacks.

EPUB Navigation Document

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 EPUB Navigation Document [Packages 3.1].

EPUB Package

A logical document entity consisting of a set of interrelated resources representing one Rendition of an EPUB Publication, as defined by a Package Document.

EPUB Publication

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.

EPUB Reading System (or Reading System)

A system that processes EPUB Publications for presentation to a user in a manner conformant with this specification.

Fixed-Layout Document

An EPUB Content Document directly referenced from the spine that has been designated pre-paginated in the Package Document, as defined in The rendition:layout Property [Packages 3.1].

The dimensions to use for rendering Fixed-Layout Documents are defined in Fixed Layouts [Content Docs 3.1].

Foreign Resource

A Publication Resource that is not a Core Media Type Resource. Foreign Resources are subject to the fallback requirements defined in Foreign Resources.

Local Resource

A resource that is located inside the EPUB Container.

Refer to Publication Resource Locations for media type specific rules for resource locations.

Manifest

A list of all Publication Resources that constitute the given Rendition of a EPUB Publication.

Refer to manifest [Packages 3.1] for more information.

Media Overlay Document

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 [Media Overlays 3.1].

Package Document

A Publication Resource that describes one Rendition of an EPUB Publication, as defined in Package Document [Packages 3.1]. The Package Document carries meta information about the Rendition, provides a manifest of resources and defines the default reading order.

Publication Resource

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 [Packages 3.1] and bundled in the EPUB Container file (unless specified otherwise in Publication Resource Locations).

Examples of resources that are not Publication Resources include those identified by the Package Document link [Packages 3.1] element and those identified in outbound hyperlinks that resolve to Remote Resources (e.g., referenced from the href attribute of an [HTML] a element).

Release Identifier

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 Release Identifier [Packages 3.1] for more information.

Remote Resource

A resource that is located outside of the EPUB Container, typically, but not necessarily, online.

Refer to Publication Resource Locations for media type specific rules for resource locations.

Rendition

One rendering of the content of an EPUB Publication, as expressed by an EPUB Package.

Scripted Content Document

An EPUB Content Document that includes scripting or an XHTML Content Document that contains [HTML] forms.

Refer to Scripting [Content Docs 3.1] for more information.

Spine

An ordered list of Publication Resources, typically EPUB Content Documents [Packages 3.1], representing the default reading order of the given Rendition of an EPUB Publication.

Refer to spine [Packages 3.1] for more information.

SVG Content Document

An EPUB Content Document that conforms to the constraints expressed in SVG Content Documents [Content Docs 3.1].

Synthetic Spread

The rendering of two adjacent pages simultaneously on a device screen.

Text-to-Speech (TTS)

The rendering of the textual content of an EPUB Publication as artificial human speech using a synthesized voice.

Top-level Content Document

An EPUB Content Document referenced from the spine, whether directly or via a fallback chain [Packages 3.1].

Unique Identifier

The Unique Identifier is the primary identifier for an EPUB Publication, as identified by the unique-identifier attribute [Packages 3.1]. 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.

Viewport

The region of an EPUB Reading System in which an EPUB Publication is rendered visually to a user.

XHTML Content Document

An EPUB Content Document that conforms to the profile of [HTML] defined in XHTML Content Documents [Content Docs 3.1].

XHTML Content Documents use the XHTML syntax defined in [HTML].

  1.3 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  1.4 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

  2 Organization

  2.1 Specifications

The EPUB 3.1 standard is modular in nature, with core features and functionality defined across a family of sub-specifications.

This specification represents the top-most specification in the family. It includes the conformance requirements for both EPUB Publications (the product of the standard) and EPUB Reading Systems (the applications that consume EPUB Publications and present their content to users).

The other specifications that comprise EPUB 3.1 are as follows:

EPUB Packages 3.1 [Packages 3.1] — defines requirements for each Rendition of the content.

EPUB Content Documents 3.1 [Content Docs 3.1] — defines profiles of XHTML, SVG and CSS for use in the context of EPUB Publications.

EPUB Media Overlays 3.1 [Media Overlays 3.1] — defines a format and a processing model for synchronization of text and audio.

EPUB Open Container Format (OCF) 3.1 [OCF 3.1] — defines a file format and processing model for encapsulating a set of related resources into a single-file (ZIP) EPUB Container.

EPUB Accessibility [EPUB Accessibility] — defines accessibility conformance and discovery metadata requirements for EPUB Publications.

Alternate Style Tags [Alt Style Tags] — defines a pattern for tagging alternate style sheets using microformats.

These specifications represent the formal list recognized as belonging to EPUB 3.1, and that contain functionality referenced as part of the standard.

The IDPF has also developed a set of specifications that complement the core functionality of EPUB 3.1, but whose support in Reading Systems and use in authoring is optional:

EPUB Canonical Fragment Identifiers [EPUB-CFI] — defines a standardized method for referencing arbitrary content within an EPUB Publication through the use of fragment identifiers.

EPUB Dictionaries and Glossaries [Dictionaries] — provides a framework for a rich user experience of dictionary publications.

EPUB Indexes [Indexes] — defines a consistent way of encoding the structure and content of indexes in EPUB Publications.

EPUB Multiple Renditions [Multiple Renditions] — defines the creation and rendering of EPUB Publications consisting of more than one Rendition.

EPUB Previews [Previews] — describes how preview content can be included in EPUB Publications.

EPUB Region-Based Navigation [Region Nav] — introduces conventions for region-based navigation through a visual rendition of an EPUB Publication based on regions of interest.

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 (but are not stable until they reach the status of Recommended Specifications).

  2.2 Road Map

This section is informative

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 [Packages 3.1].

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 [OCF 3.1].

The following example visually represents the structure of the EPUB 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 [Content Docs 3.1], and accessibility requirements are defined in [EPUB Accessibility].

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 [Media Overlays 3.1].

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.1 is provided in the informative [EPUB3 Overview].

  3 Conformance

  3.1 EPUB Publications

An EPUB Publication must meet all of the following criteria:

Packages

  It must include one or more EPUB Packages, each of which must conform to the requirements defined in [Packages 3.1].

Accessibility

  It should conform to the accessibility requirements defined in [EPUB Accessibility].

Publication Resources

  All Publication Resources must adhere to the constraints for Core Media Types and Foreign Resources and be located as per Publication Resource Locations.

Container

  It must be packaged in a EPUB Container as defined in [OCF 3.1].

  3.2 EPUB Reading Systems

An EPUB Reading System must meet all of the following criteria:

EPUB 3.1 Processing

  It must process the EPUB Container as defined in [OCF 3.1].

  It must process EPUB Packages as defined in [Packages 3.1].

  It must support all Core Media Type Resources.

  It may support an arbitrary set of Foreign Resource types, and must process fallbacks for unsupported Foreign Resources as defined in Foreign Resources if not.

  It must process XHTML Content Document as defined in XHTML Content Documents — Reading System Conformance [Content Docs 3.1].

  It must process SVG Content Documents as defined in SVG Content Documents — Reading System Conformance [Content Docs 3.1].

  If it has a Viewport, it must support visual rendering of XHTML Content Documents as defined in CSS Style Sheets — Reading System Conformance [Content Docs 3.1].

  If it has a Viewport, it must support the image Core Media Types [Core Media Types].

  If it has the capability to render pre-recorded audio, it must support the audio Core Media Types [Core Media Types] and should support Media Overlays [Media Overlays 3.1].

  If it supports Text-to-Speech (TTS) rendering, it should support Pronunciation Lexicons [Content Docs 3.1], [CSS3 Speech] and SSML attributes [Content Docs 3.1] in XHTML Content Documents.

note

It is recommended that Reading Systems support at least one of the [H.264] and [VP8] video codecs, but this is not a conformance requirement – a Reading System might support other video codecs, or none at all. Authors and Reading System developers need to take into consideration factors such as breadth of adoption, video playback quality, and technology usage royalty requirements when making a choice to include or implement video in either format, or both.

Accessibility

  It should meet the accessibility requirements for Reading Systems in [EPUB Accessibility].

Backward Compatibility

  It must attempt to process an EPUB Publication whose version is lower than "3.1".

  EPUB Publications with older version numbers will not always render exactly as intended unless processed according to their respective specifications. Reading Systems should support such EPUB Publications as defined by those specifications.

Forward Compatibility

  It should attempt to process any given Rendition of an EPUB Publication whose Package Document version attribute designates a version higher than "3.1".

XML Processing

  It must be a conformant non-validating processor [XML].

   It must be a conformant processor as defined in [XMLNS].

  It must be a conformant application as defined by [XML Base].

note

A conforming Reading System is not necessarily a single dedicated program or device, but might exist as a distributed system.

  4 Publication Resources

  4.1 Core Media Types

  4.1.1 Introduction

Each Rendition of an EPUB Publication typically consists of many Publication Resources. These resources are divided into two categories: those that EPUB Reading Systems have to support (Core Media Type Resources) and those that they do not (Foreign Resources).

Authors are free to use both types of resources to construct their EPUB Publications, but need to be aware that some Reading Systems might not render the Foreign Resources they use.

As EPUB Publications are designed to be fully consumable on any compliant Reading System, a system of fallbacks is therefore necessary to ensure that the use of Foreign Resources does not impact on the ability of the user to consume the content. This section lays out the set of Core Media Types that are supported across Reading Systems and identifies fallback mechanisms that can be used to satisfy the consumability requirement.

  4.1.2 Supported Media Types

Publication Resources that conform to a Core Media Type specification are Core Media Type Resources and can be included in an EPUB Publication without fallbacks.

Refer to [Core Media Types] for the current list of Core Media Types.

  4.1.3 Foreign Resources

Foreign Resources may be included in an EPUB Publication without a fallback provided they are not referenced from spine itemref elements [Packages 3.1] or directly rendered in their native format in EPUB Content Documents (e.g., via [HTML] embedded content and [SVG] image and foreignObject elements).

When a Foreign Resource is included in the spine or directly rendered in its native format in an EPUB Content Document, a Core Media Type fallback must be included. Fallbacks take one of the two following forms:

intrinsic fallback mechanisms provided by the format (e.g., ability to provide more than one media type or to display an alternate embedded message when a media type cannot be rendered). Refer to the [HTML] and [SVG] specifications for the intrinsic fallback capabilities their elements provide.

manifest fallbacks [Packages 3.1] are a feature of the Package Document that create a fallback chain to a Core Media Type Resources. They are used to create fallbacks for Foreign Resources in the spine [Packages 3.1] and when intrinsic fallback capabilities are not available (e.g., for the [HTML] img element).

  4.2 Resource Locations

All Publication Resources must be located in the EPUB Container, with the following exceptions:

  Audio resources [Core Media Types] 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, but the [HTML] and [SVG] script elements must not reference Remote Resources to ensure availability at runtime (i.e., from their src or href attributes, respectively).

  Font resources may be located outside the EPUB Container.

The following example shows a reference to an audio file in an XHTML Content Document that is located inside the EPUB Container.

<audio src="audio/ch01.mp4" controls="controls"/>

The following example shows a reference to an audio file in an XHTML Content Document that is located outside the EPUB Container.

<audio src="http://www.example.com/book/audio/ch01.mp4" controls="controls"/>

note

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.

note

The above rules for Publication Resource locations apply regardless of whether the given resource is a Core Media Type Resource or a Foreign Resource.

note

The inclusion of Remote Resources in an EPUB Publication is indicated via the remote-resources property [Manifest Vocab] on the manifest item element [Packages 3.1].

  4.3 XML Conformance

Any Publication Resource that is an XML-Based Media Type must meet the following constraints:

   It must be a conformant XML 1.0 Document as defined in Conformance of Documents [XMLNS].

   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.

  Appendix A. Obsolete Features

Features defined in this specification and its siblings are occasionally removed if they are no longer needed or have been replaced by another feature. Prior to removal, the features are marked as deprecated or superseded as an early warning to the EPUB community. A deprecated feature is one that is in the process of being removed from the current version of the specification, while a superseded feature is one that is being retained only for authoring content compatible with an older version.

If a feature is marked as deprecated, the following hold true:

The feature will be removed in a future version of the specification. The feature is marked as deprecated in order to give Authors and EPUB Reading System developers time to prepare for removal.

It is strongly recommended that Authors discontinue use of the feature in their EPUB Publications.

Reading Systems must continue to support the feature as it is defined until it is formally removed.

Validation tools must alert Authors that inclusion of the feature is deprecated when encountered in an EPUB Publication. It is recommended that the alert be lower in severity than an error or warning.

If a feature is marked as superseded, the following hold true:

The superseded feature may be removed in a future version of the specification, but there is no definite timeline for removal.

Authors may include the superseded feature for compatibility with older versions of the specification.

Reading Systems must not support the superseded feature in content that conforms to the current version of the specification.

Validation tools must not alert Authors about the presence of the superseded feature in an EPUB Publication, as it is valid for backwards compatibility. Validation tools must alert Authors if the superseded feature is not conformant to its definition or otherwise breaks a usage requirement.

A feature that is superseded and marked for removal differs from a superseded feature in the following ways:

The feature will be removed in a future version of the specification.

Validation tools must alert Authors about the presence of superseded features that are marked for removal. It is recommended that the alert be given the same severity as deprecated features.

  Index

This index is informative

This index identifies where key concepts are defined in EPUB 3.1, including element, attribute and property definitions.

accessibility [EPUB Accessibility]

accessible publications

authoring and consumption

discovery metadata

distribution concerns

optimized publications

core media types [EPUB 3.1]

foreign resources

manifest fallbacks [Packages 3.1]

supported media types

core specifications [EPUB 3.1]

CSS style sheets [Content Docs 3.1]

CSS snapshot support

prefixed properties

Reading System overrides

EPUB Navigation Document [Packages 3.1]

custom nav elements

hidden attribute

landmarks nav element

nav element restrictions

page-list nav element

toc nav element

fixed layouts [Packages 3.1]

content dimensions [Content Docs 3.1]

SVG initial containing block (viewBox)

XHTML initial containing block (viewport meta)

package metadata

rendition:layout property

rendition:orientation property

rendition:page-spread-center property

rendition:page-spread-left property

rendition:page-spread-right property

rendition:spread property

viewport rendering [Content Docs 3.1]

Media Overlays Documents [Media Overlays 3.1]

basic playback behaviors

audio playback

content rendering

timing and synchronization

escapability

interaction with content documents

embedded audio and video

navigation

text-to-speech playback

loading

navigation document playback

packaging

attaching to content documents

metadata

active-class property

duration property

narrator property

playback-active-class property

playback granularity

relationship to content documents

embedded media

navigation

text-to-speech playback

skippability

smil element

body element

par element

audio element

text element

seq element

head element

metadata element

semantic inflection (epub:type)

structure

styling

OCF abstract container [OCF 3.1]

file and directory structure

file name requirements

META-INF directory

container.xml file

link element

rootfile element

encryption.xml file

EncryptedData element

EncryptedKey element

encryption element

listing obfuscated resources

order of compression and encryption

Compression element

restricted files

manifest.xml file

metadata.xml file

rights.xml file

signatures.xml file

container signature

signature restrictions

relative path references

OCF ZIP container [OCF 3.1]

encryption

restricted files

media type identification (mimetype)

obfuscation (was font obfuscation)

algorithm

identifying resources

key

ZIP requirements

Package Document [Packages 3.1]

collection element

linking resources

metadata

roles

default vocabularies

fixed layout properties — see also fixed layouts

identifiers

release identifier

unique identifier

unique-identifier attribute

layout properties

rendition:align-x-center property

rendition:flow property

metadata element

core metadata requirements

dc:identifier element

identifier schemes

dc:language element

dc:title element

importance of order

dcterms:modified property (last modified date)

Dublin Core optional elements

contributors

creators

publication date

publication types

subjects

link element

link relationships

manifest requirements

linked metadata records

resource location

meta element

expressing properties

refines attribute (deprecated)

value scheme

manifest element

item element

durations

fallbacks

media overlay association

media type

properties

resource inclusion requirements

NCX (superseded)

package element

prefix declarations

version number

property data type

reserved prefixes

shared attributes

spine element

itemref element

linearity

referencing manifest items

page progression

resource inclusion requirements

registries

Collection Roles

Identifier Schemes

Optimized Publication Standards

Publication Types

Subject Authorities

remote resources [EPUB 3.1]

scripting [Content Docs 3.1]

contexts (container-constrained and spine-level)

epubReadingSystem object

description

hasFeature method

description

features

interface definition

properties

event model

security

SVG Content Documents [Content Docs 3.1]

restrictions

semantic inflection

SVG version conformance

terminology [EPUB 3.1]

vocabularies

Accessibility

Link

Manifest Properties

Media Overlays Metadata

Meta Properties

Publication Rendering (rendition: properties)

Spine Properties

Structural Semantics

XHTML Content Documents [Content Docs 3.1]

alternate style tags

custom attributes

discouraged constructs (rp and embed)

embedded MathML

fallback images

embedded SVG

application of CSS styles

foreign resource restrictions

HTML version conformance

pronunciation lexicons (PLS)

RDFa and microdata (semantic enrichment)

semantic inflection

default vocabulary

epub:type attribute

prefix declarations

reserved prefixes

Speech Synthesis Markup Language (SSML)

ssml:ph attribute

ssml:alphabet attribute

SVG

Unicode restrictions

XML conformance [EPUB 3.1]

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Audrain, Luc (Hachette Livre)

Bailey, Brent (Elsevier)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bogan, Robert (Baker & Taylor)

Bowers, Micah (Bluefire Productions)

Burrows, Phil (VitalSource/Ingram Content Group)

Challman, Lauren (Kaplan Publishing)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Cleghorn, Tom (Cambridge University Press)

Comerford, Rachel (Macmillan)

Conboy, Garth (Google)

Corona, Juan (Evident Point)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Davis, Greg (Pearson)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Duga, Brady (Google)

Gardeur, Hadrien (Feedbooks)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haase, David (Penguin Random House)

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Herman, Ivan (W3C) W3C Liaison

Idan, Ori (Helicon Books)

Jay, Michael (Educational Systemics)

Johnson, Rick (VitalSource/Ingram Content Group)

Jung, Eunmi (KERIS (Korea Education and Research Information Service))

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

Khramov, Yuri (Readium)

Kleinfeld, Sanders (O'Reilly)

Koike, Toshiaki (Voyager Japan)

Labordrie, Cyril (EDRLab)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Levantovsky, Vladimir (Monotype)

Levenson, Yonah (Pearson)

Lin, Beatrice (KERIS (Korea Education and Research Information Service))

Lui, Edwina (Kaplan Publishing)

McCoy, Bill (IDPF)

Mietkiewicz, Elie (Gutenberg Technology)

Mitchell, Chris (Hachette Book Group)

Moua, Nou (Kaplan Publishing)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Owens, Evan (Cenveo Publisher Services)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally)

Rosenthol, Leonard (Adobe Systems)

Shyne, Mary (Penguin Random House)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Swick, Ralph (W3C)

Tallent, Joshua (eBookArchitects)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Wright, Ric (Readium Foundation)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Brady, Laura

Etemad, Elika J. W3C CSS WG Liaison

Garrish, Matt

Glazman, Daniel

Hawkins, Kevin

Kaplansky, Jean

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[Alt Style Tags] Alternate Style Tags . Elika J. Etemad.

[CSS3 Speech] CSS3 Speech Module . Dave Raggett, et al..

[Content Docs 3.1] EPUB Content Documents 3.1 .

[Core Media Types] EPUB 3 Core Media Types.

[Dictionaries] EPUB Dictionaries and Glossaries .

[EPUB 3.1] EPUB 3.1 .

[EPUB Accessibility] EPUB Accessibility .

[EPUB-CFI] EPUB Canonical Fragment Identifier (epubcfi) Specification .

[HTML] HTML .

[Indexes] EPUB Indexes .

[Manifest Vocab] EPUB Manifest Properties Vocabulary .

[Media Overlays 3.1] EPUB Media Overlays 3.1 .

[Multiple Renditions] EPUB Multiple Renditions .

[OCF 3.1] Open Container Format 3.1 .

[Packages 3.1] EPUB Packages 3.1 .

[Previews] EPUB Previews .

[RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (RFC 2046) . N. Freed, N. Borenstein. November 1996.

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

[Region Nav] EPUB Region-Based Navigation .

[SVG] Scalable Vector Graphics (SVG) .

[Unicode] The Unicode Consortium. The Unicode Standard..

[XInclude] XML Inclusions (XInclude) Version 1.0 (Second Edition) . J. Marsh, et al. 15 November 2006.

[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . T. Bray, et al. 26 November 2008.

[XML Base] XML Base (Second Edition) . Jonathan Marsh, et al. 28 January 2009.

[XMLNS] Namespaces in XML (Third Edition) . T. Bray, et al. 8 December 2009.

Informative References

[EPUB3 Changes] EPUB 3.1 Differences from EPUB 3.0.1 .

[EPUB3 Overview] EPUB 3.1 Overview .

[H.264] H.264 : Advanced video coding for generic audiovisual services . 2016-02-13.

[VP8] VP8 Data Format and Decoding Guide (RFC 6386) . J. Bankoski, et al. November 2011.

EPUB 3.1 Overview

Informational Document 5 January 2017

This version

http://www.idpf.org/epub/31/spec/epub-overview-20170105.html

Latest version

http://www.idpf.org/epub3/latest/overview

Previous version

http://www.idpf.org/epub/31/spec/epub-overview-20161130.html

Previous recommendation

http://www.idpf.org/epub/301/spec/epub-overview-20140626.html

Document history

Changes to this document

Report an issue

Editors

Garth Conboy, Google Inc.

Matt Garrish, Invited Expert

Markus Gylling, International Digital Publishing Forum (IDPF)

William McCoy, International Digital Publishing Forum (IDPF)

MURATA Makoto, JEPA EPUB Study Group

Daniel Weck, DAISY Consortium

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

This document is informative.

Table of Contents

1. Introduction

1.1. Overview

2. Features

2.1. Package Document

2.2. Navigation

2.2.1. Reading Order

2.2.2. Navigation Document

2.3. Metadata

2.4. Content Documents

2.5. Fixed Layouts

2.6. Rendering and CSS

2.7. Multimedia

2.8. Fonts

2.9. Scripting

2.10. Text-to-speech

2.11. Container

3. Global Language Support

3.1. Metadata

3.2. Content Documents

3.3. CSS

3.4. Fonts

3.5. Text-to-speech

3.6. Container

4. Accessibility

4.1. Navigation

4.2. Semantic Markup

4.3. Dynamic Layouts

4.4. Aural Renditions and Media Overlays

4.5. Fallbacks

4.6. Scripting

Acknowledgements and Contributors

References

  1 Introduction

  1.1 Overview

This document provides a starting point for content authors and software developers wishing to understand the EPUB® 3.1 specifications. It consists entirely of informative overview material that describes the features available in EPUB 3.1.

Another informative document, EPUB 3.1 Changes from EPUB 3.0.1 [EPUB3 Changes], describes changes in EPUB 3.1 from the last version.

  2 Features

This section covers the major features of EPUB, including important components and topics that apply to the process of authoring EPUB Publications as a whole.

  2.1 Package Document

Every EPUB Publication contains at least one Rendition of its contents, each of which is represented by a Package Document.

The Package Document specifies all the resources required to render that representation of the content. The Package Document also defines a reading order for linear consumption, and associates metadata and navigation information for the Rendition.

The Package Document represents a significant improvement on a typical Web site. A Web site, for example, embeds references to its resources within its content, which, while a simple and flexible means of identifying resources, makes it difficult to enumerate all the resources required to render it. In addition, there is no standard way for a Web site to define that a sequence of pages make up a larger publication, which is precisely what EPUB's spine element [Packages 3.1] does (i.e., it provides an external declarative means to explicitly specify navigation through a collection of documents). Finally, the Package Document defines a standard way to represent metadata globally applicable to a collection of pages.

The Package Document also includes a collection element [Packages 3.1], which allows grouping of logically-related Publication Resources. This element exists to enable the development of specialized content identification, processing and rendering features, such as the ability to define embedded preview content, or assemble an index or dictionary from its constituent XHTML Content Documents.

The Package Document and other Rendition-specific constructs are specified in [Packages 3.1].

  2.2 Navigation

  2.2.1 Reading Order

A key concept of EPUB is that an EPUB Publication consists of multiple resources that can be completely navigated and consumed by a person or program in some specific order.

Many types of publication have an obvious reading order, or logical progression through their content. A novel is an example of a highly sequential document — it typically has a beginning, middle and end — but not all publications are so ordered: a cookbook or collection of photographic images might be considered to be more like a database. All documents do, however, have at least one logical ordering of all their top-level content items, whether by date, topic, location or some other criteria (e.g., a cookbook is typically ordered by type of recipe).

Each Rendition of an EPUB Publication defines at least one such logical ordering of all its top-level content (the spine [Packages 3.1]), as well as a declarative table of contents (the EPUB Navigation Document [EPUB 3.1]). EPUB Publications make these data structures available in a machine-readable way external to the content, simplifying their discovery and use.

EPUB Publications are not limited to the linear ordering of their contents, nor do they preclude linking in arbitrary ways — just like the Web, EPUB Publications are built on hypertext — but the basic consumption and navigation can be reliably accomplished in a way that is not true for a set of HTML pages.

  2.2.2 Navigation Document

Each Rendition of an EPUB Publication contains a special XHTML Content Document called the EPUB Navigation Document, which uses the [HTML] nav element to define human- and machine-readable navigation information.

The Navigation Document replaces the EPUB 2 NCX document [OPS2]. The Navigation Document, while maintaining the baseline accessibility and navigation support and features of the NCX, introduces new functionality and rendering features to enhance navigation for all users. Prime among these are better support for internationalization (as an XHTML document itself, the Navigation Document natively supports ruby annotations) and support for embedded grammars (MathML and SVG can be included within navigation links).

As XHTML Content Documents, Navigation Documents also provide a flexible means of tailoring the navigation display using CSS and the hidden attribute [Packages 3.1] while not impacting access to information for accessible Reading Systems.

The structure and semantics of Navigation Documents are defined in EPUB Navigation Document [Packages 3.1].

  2.3 Metadata

EPUB Publications provide a rich array of options for adding metadata. Each Rendition's Package Document includes a dedicated metadata section [Packages 3.1] for general information about the EPUB Publication, allowing titles, authors, identifiers and other information about the EPUB Publication to be easily accessed. It also provides the means to attach complete bibliographic records using the link element [Packages 3.1].

The Package Document also allows a Unique Identifier to be established for the EPUB Publication using the unique-identifier attribute [Packages 3.1]. The required last-modified date in the Package metadata section can be joined with this identifier to define a Release Identifier, which provides a means of distinguishing different versions of an EPUB Publication (see Publication Identifiers [Packages 3.1]). The Package Identifier addresses the issue of how to release an EPUB Publication without changing its Unique Identifier while still identifying it as a new version.

XHTML Content Documents also include the means of annotating document markup with rich metadata, making them more semantically meaningful and useful both for processing and accessibility purposes (XHTML Semantic Inflection [Content Docs 3.1]). Both RDFa and Microdata attributes can also be used in XHTML Content Documents, enabling content-level metadata expressions (XHTML Semantic Enrichment [Content Docs 3.1]).

  2.4 Content Documents

Each Rendition of an EPUB Publication contains one or more EPUB Content Documents, as defined in [EPUB 3.1]. These are XHTML or SVG documents that describe the readable content and reference associated media resources (e.g., images, audio and video clips).

XHTML Content Documents are defined by a profile of [HTML].

  2.5 Fixed Layouts

Although EPUB's history is steeped in enabling reflowable content, not all publications lend themselves easily to reflowing. Children's books, comics and manga, magazines and many other content forms require the ability to create page-precise layouts in order to be represented meaningfully.

EPUB 3.1 includes metadata that allows the creation of fixed-layout XHTML Content Documents [Packages 3.1], in addition to existing capabilities for fixed layouts in SVG. This metadata enables the dimensions of the page [Content Docs 3.1] to be controlled, creating a canvas on which elements can be absolutely positioned.

The metadata does not just flag whether content is to be fixed or reflowed, but also allows Authors to specify the desired orientation of pages [Packages 3.1], when to create synthetic spreads [Packages 3.1], and how to position pages [Packages 3.1] within those spreads, providing a broad range of control over the presentation of EPUB Publications.

  2.6 Rendering and CSS

A key concept of EPUB is that content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content. HTML was originally designed to support dynamic rendering of structured content, but over time HTML as supported in Web browsers has become focused on the needs of Web applications, and most popular Web sites now have fixed-format layouts.

EPUB Publications, however, are designed to maximize accessibility for the visually impaired, and Reading Systems typically perform text line layout and pagination on the fly, adapting to the size of the display area, the user's preferred font size, and other environmental factors. This behavior is not guaranteed in EPUB; images, vector graphics, video and other non-reflowable content might be included, and some Reading Systems might not paginate on the fly, or at all. Nevertheless, supporting dynamic adaptive layout and accessibility has been a primary design consideration throughout the evolution of the EPUB standard.

EPUB Content Documents can reference CSS Style Sheets, allowing Authors to define the desired rendering properties. EPUB 3.1 follows support for CSS as defined in the [CSS Snapshot].

EPUB 3.1 also supports CSS styles that enable both horizontal and vertical layout and both left-to-right and right-to-left writing. Refer to CSS in the Global Language Support section for more information.

EPUB 3.1 also includes the ability to provide multiple style sheets that allow users to select between day/night reading modes or change the rendering direction of the text. Refer to [Alt Style Tags] for more information.

  2.7 Multimedia

EPUB 3.1 supports audio and video embedded in XHTML Content Documents via the [HTML] audio and video elements, inheriting all the functionality and features these elements provide. For more information on audio and video formats, refer to [Core Media Types].

Another key multimedia feature in EPUB 3.1 is the inclusion of Media Overlay Documents [Media Overlays 3.1]. When pre-recorded narration is available for a Rendition of an EPUB Publication, Media Overlays provide the ability to synchronize that audio with the text of a Content Document (see also Aural Renditions and Media Overlays).

  2.8 Fonts

EPUB 3.1 supports two closely-related font formats — OpenType [OpenType] and WOFF [WOFF] [WOFF2] — to accommodate both traditional publishing workflows and emerging Web-based workflows. Word processing programs used to create EPUB Publications are likely to have access only to a collection of installed OpenType fonts, for example, whereas Web-archival EPUB generators will likely only have access to WOFF resources (which cannot be converted to OpenType without undesirable, and potentially unlicensed, stripping of WOFF metadata).

EPUB 3.1 also supports both obfuscated and regular font resources for both OpenType and WOFF font formats. Support for obfuscated font resources is required to accommodate font licensing restrictions for many commercially-available fonts.

  2.9 Scripting

EPUB strives to treat content declaratively — as data that can be manipulated, not programs to be executed — but does support scripting as defined in [HTML] and [SVG] (refer to Scripting [Content Docs 3.1] for more information).

It is important to note, however, that EPUB 3 does not require scripting support in Reading Systems, and scripting might be disabled for security reasons.

Authors need to be aware that scripting in an EPUB Publication can create security considerations that are different from scripting within a Web browser. For example, typical same-origin policies are not applicable to content that has been downloaded to a user's local system. Therefore, it is strongly encouraged that scripting be limited to container constrained contexts, as further described in Scripted Content Documents — Content Conformance [Content Docs 3.1].

In other words, consider limiting scripting to cases where it is essential to the user experience, since it greatly increases the likelihood that content will not be portable across all Reading Systems and creates barriers to accessibility and content reusability.

  2.10 Text-to-speech

EPUB 3.1 provides the following text-to-speech (TTS) facilities for controlling aspects of speech synthesis, such as pronunciation, prosody and voice characteristics:

Pronunciation Lexicons

The inclusion of generic pronunciation lexicons using the W3C PLS format [PLS] enables Authors to provide pronunciation rules that apply to the entire EPUB Publication. Refer to Pronunciation Lexicons [Content Docs 3.1] for more information.

Inline SSML Phonemes

The incorporation of SSML phonemes functionality [SSML] directly into a EPUB Content Document enables fine-grained pronunciation control, taking precedence over default pronunciation rules and/or referenced pronunciation lexicons (as provided by the PLS format mentioned above). Refer to SSML Attributes [Content Docs 3.1] for more information.

  2.11 Container

An EPUB Publication is transported and interchanged as a single file (a "portable document") that contains the Package Documents, all Content Documents and all other required resources for processing the included Renditions. The single-file container format for EPUB is based on the widely adopted ZIP format, and an XML document that identifies the location of the Package Document for each Rendition in the ZIP archive is located at a pre-defined location within the archive.

This approach provides a clear contract between any creator of an EPUB Publication and any system which consumes such EPUB Publications, as well as a reliable representation that is independent of network transport or file system specifics.

An EPUB Publication's representation as a container file is specified in [OCF 3.1].

  3 Global Language Support

  3.1 Metadata

EPUB 3.1 supports alternate representations of all text metadata items in the package metadata section to improve global distribution of EPUB Publications. The opf:alt-rep attribute [Packages 3.1] provides the ability to include and identify alternate script renderings of language-specific metadata.

Using this attribute, a Japanese EPUB Publication could, for example, include an alternate Roman-script representation of the author's name and/or an alternative representations of the title in a Romance language.

The page-progression-direction attribute also allows the content flow direction to be globally specified for all Content Documents to facilitate rendering (see the page-progression-direction [Packages 3.1]).

  3.2 Content Documents

XHTML Content Documents leverage the HTML directionality features to improve support for bidirectional content rendering: the bdi element allows an instance of directional text to be isolated from the surrounding content, the bdo element allows directionality to be overridden for its child content and the dir attribute allows the directionality of any element to be explicitly set.

XHTML Content Documents also support ruby annotations for pronunciation support (which makes them supported in Navigation Document links, as well).

SVG Content Documents support the rendering of bidirectional text, but do not include support for ruby.

  3.3 CSS

EPUB 3.1's support for CSS3 modules enables typography for many different languages and cultures. Some specific enhancements include:

support for vertical writing, which also provides Reading Systems the ability to allow users to toggle direction;

better handling of emphasis, such as the inclusion of bōten;

better control over line breaking, so that breaks can occur at the character level for languages that do not use spaces to delimit new words; and

better control over hyphenation, to further facilitate line breaking.

  3.4 Fonts

EPUB 3.1 does not require that Reading Systems come with any particular set of built-in system fonts. As occurs in Web contexts, users in a particular locale might have installed fonts that omit characters required for other locales, and Reading Systems might utilize intrinsic fonts or font engines that do not utilize operating system installed fonts. As a result, the text content of an EPUB Publication might not natively render as intended on all Reading Systems.

To address this problem, EPUB 3.1 supports the embedding of fonts to facilitate the rendering of text content, and this practice is advised in order to ensure content is rendered as intended.

Support for embedded fonts also ensures that characters and glyphs unique to an EPUB Publication can be embedded for proper display.

  3.5 Text-to-speech

EPUB 3.1's support for PLS documents and SSML attributes increases the pronunciation control that Authors have over the rendering of any natural language in text-to-speech-enabled Reading Systems. Refer to Text-to-speech in the Features section for more information on these capabilities.

The combination of CSS Speech and inline SSML phonemes also allows fine control over ruby.

  3.6 Container

The OCF container format supports UTF-8, allowing for internationalized file and directory naming of content resources.

  4 Accessibility

A major goal of EPUB is to facilitate content accessibility, and a variety of features in EPUB 3.1 support this requirement. This section reviews these features, detailing some established best practices for ensuring that EPUB Publications are accessible where applicable.

EPUB 3.1 also includes an Accessibility specification [EPUB Accessibility] that leverages the extensive work done to make Web content accessible in [WCAG 2.0]. The specification defines requirements for the production of EPUB Publications that can be accessed by a wide range of users. It is accompanied by a techniques document that outlines best practices for meeting the requirements.

It is important to note that while accessibility is important in its own right, accessible content is also more valuable content: an accessible EPUB Publication will be adaptable to more devices and be easier to reuse, in whole or in part, via human and automated workflows. The EPUB Working Group strongly recommends that Authors ensure that they generate accessible content.

  4.1 Navigation

EPUB 3.1 improves on NCX documents with the addition of EPUB Navigation Documents. As noted in Navigation Document above, the navigation features represent a more universal and flexible navigation system.

The Navigation Document can also be reused in the body of an EPUB Publication by including it in the spine. To avoid the situation in highly structured documents where it might not be desirable to display the complete table of contents to users in the body, the display level can be modified using the [HTML] hidden attribute. This attribute is ignored by Reading Systems when they render the table of contents outside the spine (e.g., in their own specialized views), which avoids minimizing the information that is available.

Authors are also encouraged to supply additional nav elements if their EPUB Publications contain non-structural points of interest, such as figures, tables, etc. in order to further enhance access to the content.

  4.2 Semantic Markup

[HTML] supports a number of elements that make markup more semantically meaningful (e.g., section, nav and aside) and introduces more clearly defined semantics for some HTML4 elements. Make use of these elements, in conjunction with best practices for authoring well-structured Web content, when creating EPUB XHTML Content Documents. These additions allow content to be better grouped and defined, both for representing the structure of documents and to facilitate their logical navigation. XHTML Content Documents also natively support the inclusion of ARIA role and state attributes and events, enhancing the ability of Assistive Technologies to interact with the content.

EPUB 3.1 includes the epub:type attribute, which is meant to be functionally equivalent to the W3C Role Attribute [Role]. This attribute allows any element in an XHTML Content Document to include additional information about its purpose and meaning within the work, using controlled vocabularies and terms. Refer to XHTML Semantic Inflection [Content Docs 3.1] for more information.

  4.3 Dynamic Layouts

The design center of EPUB is dynamic layout: content is typically intended to be formatted on the fly rather than being typeset in a paginated manner in advance (i.e., expecting a particular sized "page"). This core capability is useful, for example, for optimizing rendering onto different sized device screens or window sizes, and it facilitates and simplifies content accessibility.

While it is possible to incorporate more highly formatted content in EPUB — for example via bitmap images or SVG graphics, or even use of CSS explicit positioning and/or table elements to achieve particular visual layouts — Authors are strongly discouraged from utilizing such techniques. They are not reliable in EPUB since many Reading Systems render content in a paginated manner rather than creating a single scrolling Viewport and since each Reading System might define its own pagination algorithm. If these techniques are necessary to convey the content of the publication, consider including fallbacks [EPUB 3.1] (e.g., for graphic novels).

In general, it is preferable to achieve visual richness by using CSS Style Sheets without absolute sizing or positioning.

  4.4 Aural Renditions and Media Overlays

Aural renderings of content are important for accessibility and are a desirable feature for many other users. A baseline to facilitate aural rendering is to utilize semantic HTML designed for dynamic layout. Refer to Text-to-speech for more information on how to use the native facilities that EPUB XHTML Documents include.

[Media Overlays 3.1] provides the ability to synchronize the text and audio content of an EPUB Publication, a feature already familiar to readers of DAISY Digital Talking Books. Overlays transcend the accessibility domain in their usefulness: the synchronization of text and audio as a tool for learning to read, for example, being of benefit in many circumstances.

  4.5 Fallbacks

Not all formats are accessible in their native format, and not all users prefer to read in the default format provided. EPUB defines a variety of means for providing fallbacks so that alternate renderings can be made available in these cases.

Publication- and content-level fallbacks are defined in Foreign Resources [EPUB 3.1]. These fallback mechanisms enable the inclusion of Foreign Resources in an EPUB Publication and ensure compatibility of EPUB 3.1 content across Reading Systems with varying capabilities (e.g., they allow the inclusion of multiple video formats, and the inclusion of XHTML fallbacks to SVG Content Documents for EPUB 2 Reading Systems).

In addition, multiple instances of a complete work can be delivered in a single EPUB Publication by defining multiple rootfile elements in the OCF container file (as described in Container File (container.xml) [OCF 3.1]). These alternate Rendition fallbacks might be used, for example, so that a formatted graphic novel defined via a sequence of SVG pages can be accompanied by an accessible text version defined via XHTML.

  4.6 Scripting

EPUB 3.1 adopts a progressive enhancement approach for scripted content, whereby scripting has to not interfere with the integrity of the document (i.e., not result in information loss when scripting is not available). Consequently, although documents that do employ scripting can provide fallbacks [Content Docs 3.1] to further facilitate access to their contents, the documents have to be accessible without them.

Ensure that you always implement best practices for accessible scripting in Web documents, such as provided in [WAI-ARIA], and reserve the use of scripting for situations in which interactivity is critical to the user experience.

  Acknowledgements and Contributors

This section is informative

EPUB 3.1

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Active members of the working group at the time of publication of revision 3.0 were:

IDPF Members

Albert, Paolo (PubCoder)

Audrain, Luc (Hachette Livre)

Bailey, Brent (Elsevier)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bogan, Robert (Baker & Taylor)

Bowers, Micah (Bluefire Productions)

Burrows, Phil (VitalSource/Ingram Content Group)

Challman, Lauren (Kaplan Publishing)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Cleghorn, Tom (Cambridge University Press)

Comerford, Rachel (Macmillan)

Conboy, Garth (Google)

Corona, Juan (Evident Point)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Davis, Greg (Pearson)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Duga, Brady (Google)

Gardeur, Hadrien (Feedbooks)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haase, David (Penguin Random House)

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Herman, Ivan (W3C) W3C Liaison

Idan, Ori (Helicon Books)

Jay, Michael (Educational Systemics)

Johnson, Rick (VitalSource/Ingram Content Group)

Jung, Eunmi (KERIS (Korea Education and Research Information Service))

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

Khramov, Yuri (Readium)

Kleinfeld, Sanders (O'Reilly)

Koike, Toshiaki (Voyager Japan)

Labordrie, Cyril (EDRLab)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Levantovsky, Vladimir (Monotype)

Levenson, Yonah (Pearson)

Lin, Beatrice (KERIS (Korea Education and Research Information Service))

Lui, Edwina (Kaplan Publishing)

McCoy, Bill (IDPF)

Mietkiewicz, Elie (Gutenberg Technology)

Mitchell, Chris (Hachette Book Group)

Moua, Nou (Kaplan Publishing)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Owens, Evan (Cenveo Publisher Services)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally)

Rosenthol, Leonard (Adobe Systems)

Shyne, Mary (Penguin Random House)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Swick, Ralph (W3C)

Tallent, Joshua (eBookArchitects)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Wright, Ric (Readium Foundation)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Brady, Laura

Etemad, Elika J. W3C CSS WG Liaison

Garrish, Matt

Glazman, Daniel

Hawkins, Kevin

Kaplansky, Jean

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

EPUB 3.0

Version 3.0 of this specification was prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group under the leadership of:

Gylling, Markus (International Digital Publishing Forum (IDPF)) Chair

Conboy, Garth (Google Inc.) Vice-chair

Duga, Brady (Google Inc.) Vice-chair, Subgroup Lead

McCoy, Bill (International Digital Publishing Forum (IDPF)) Secretary

Kasdorf, Bill (Apex CoVantage) Subgroup Lead

MURATA, Makoto (JEPA EPUB Study Group) Subgroup Lead

Sorotokin, Peter (Adobe) Subgroup Lead

Active members of the working group at the time of publication of revision 3.0 were:

IDPF Members

Abrams, Willie (Ingram Digital)

Acton, Daniel (Google)

Allesi, Ana Maria (HarperCollins)

Amos, Dan (DNAML (DNL eBooks))

Arany, Steve (John Wiley & Sons)

Artin, Michael (Barnes & Noble)

Badger, Brandon (Google)

Ballard, Kevin (Apple Inc.)

Beard, Elliot (HarperCollins)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bell, Jeff (Microsoft)

Bide, Mark (EDItEUR)

Bogaty, Nick (Adobe)

Bowers, Micah (Bluefire Productions)

Brantley, Peter (Internet Archive)

Breglio, Melissa (Apple Inc.)

Broome, Karen (Sony)

Brugge, John (Benetech)

Carbonell, Oliver (Sony)

Chang, Phobos (Chinese Foundation for Digitization Technology)

Chen, Mei-Li (Institute for Information Industry)

Chen, Peter (ITRI)

Choi, Soo (HarperCollins)

Chow, King-Wai (ASTRI (Hong Kong Applied Science & Technology Research Institute))

Clutter, Mat (Random House)

Conboy, Garth (Google)

Cramer, Dave (Hachette Book Group)

Cronin, Margot (Bowker)

Daly, Liza (Threepress)

De Meulemeester, Eric (Jouve/Publishing Dimensions)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Dougherty, Casey (Apple Inc.)

Drake, Jama (Impelsys)

Duga, Brady (Google)

Elliott, Ray (Crossway)

Fahlgren, Keith (Threepress)

Fain, Guy (Crossway)

Freese, Eric (Aptara)

Gardeur, Hadrien (Feedbooks)

Gold, Eric (Digital Divide Data)

Goodwin, Jonathan (Appfoundry)

Gopinath, Anith (Impelsys)

Gosling, Andreas (Penguin)

Grazioli, Frank (John Wiley & Sons)

Gunn, Dave (RNIB)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haas, Matt (Pearson)

Hadfield, Tom (CourseSmart)

Hagino, Masaaki (Voyager Japan)

Hawkins, Kevin (University of Michigan Library)

Hayashi, Junichi (Voyager Japan)

Heiberger, Richard (HarperCollins)

Hepp, Mike (Dartmouth Journal Services)

Herren, Matthew (BlankPage)

Hisashi, Saiga (Sharp)

Hoda, Hisashi (Voyager Japan)

Howard, William (Easypress)

Hughes, Dan (Liguori Publications)

Hulse, Leslie (HarperCollins)

Imsieke, Gerrit (le-tex)

Jain, Anupam (Innodata Isogen)

Jie, Fan (Gansu DUZHE Digital Sci&Tech)

Johnson, Rick (Ingram Digital)

Jung, Kanghee (Incube Technologies)

Kakar, Samir (Aptara)

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Kasher, Bob (BookMasters and Newgen Imaging)

Kato, Kazuyuki (East Co.)

Keating, Patrick (Bluefire Productions)

Kerscher, George (DAISY Consortium)

Kida, Yasuo (Apple Inc.)

Kim, Jean (Barnes & Noble)

Kim, HyunYoung (Incube Technologies)

Kim, Terry (INKA Entworks)

Kitagawa, Masahiro (Impress Holdings)

Koike, Toshiaki (Voyager Japan)

Kok, Dan (Crossway)

Kotrch, Steve (Simon & Schuster)

Larroque, Benoit (Feedbooks)

Levantovsky, Vladimir (Monotype Imaging)

Lu, Cho-Chin (Institute for Information Industry)

Lynch, Ryan (Apple Inc.)

MacFarlane, James (Easypress)

Makower, Dave (Apple Inc.)

Mandelbaum, David (Barnes & Noble)

Manis, Will (Metaplates)

McCloy-Kelley, Liisa (Random House)

McCoy, Bill (IDPF)

Menzies, Tracey (HarperCollins)

Mitchell, Chris (Random House)

Moore, Helen (HarperCollins)

Muller, Eric (Adobe)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Nagai, Yoshinori (Sharp)

Novelli, Joe (Sony)

O'Connor, Edward (Apple Inc.)

Ohmura, Yoshinori (Impress Holdings)

Olenick, Michael (Bowker)

Oshiyama, Taka (East Co.)

Pagano, Pat (Barnes & Noble)

Picco, Marty (AppFoundry)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally (formerly RFB&D))

Rao, Vishnu (Sharp Laboratories)

Rivlin, John (Google)

Rubino, Frank (Kaplan Publishing)

Ruffino, Daniel (Penguin)

Rui Hua, Wang (Gansu DUZHE Digital Sci&Tech)

Ruse, Tyler (LibreDigital)

Sanicola, Daniel (Penguin)

Schirmer, Lorenz (Monotype Imaging)

Severdia, Ron (Metrodigi, Inc.)

Shiohama, Daihei (Voyager Japan)

Shrivastava, Abhishek (CourseSmart)

Siegman, Tzviya (John Wiley & Sons)

Slavin, Wayne (Barnes & Noble)

Slye, Christopher (Adobe)

Smith, Michael (IDPF)

Soiffer, Neil (Design Science)

Sorotokin, Peter (Adobe)

Stevenson, Tobias (eBookArchitects)

Tahara, Kyoji (Toppan Printing)

Takase, Hiroshi (East Co.)

Tallent, Joshua (eBookArchitects)

Tanabe, Shu (Toppan Printing)

Thomas, Vinu (Impelsys)

Tsumagari, Koichiro (Voyager Japan)

Valentine, Chelsea (LibreDigital)

Vangage, Peter (Harlequin)

Vido, Ariel (Geografica Editora)

Wait, John (Pearson)

Walkley, George (Hachette Book Group)

Watters, Kevin (Harlequin)

Webster, Roger (Barnes & Noble)

Weck, Daniel (DAISY Consortium)

Wei, Selena (Chinese Foundation for Digitization Technology)

White, Russell (Random House)

Wiles, Alexis (Overdrive, Inc.)

Witwer, Adam (O'Reilly)

Wright, Rick (Adobe)

Young, Liz (Crossway)

Zu, Alex (ASTRI (Hong Kong Applied Science & Technology Research Institute))

Invited Experts/Observers

Bowes, Rick

Cazenove, Rhys

Collingridge, Peter

Cook, Mike

Etemad, Elika J. W3C CSS WG Liaison

Forster, Karen

Freed, Geoff

Fujisawa, Jun

Garrish, Matt

Gould, Bryan

Görner, Martin

Hsieh, Michael

Ishii, Koji

Johar, Kenny

Karlsson, Mattias

Kennedy, Dianne

Kilborn, Peter

Koppel, Josh

Lee, Tommy

Lu, Kenny

Lubeck, Scott

Masanori, Kusunoki

McKinney, Steven

Murakami, Shinyu

Ning, Elliott

Noring, Jon

Norton, Paul

Oishi, Yasuharu

Passey, Lee

Rosmaita, Gregory

Seaman, David

Shan, Walter

Smith(tm), Michael (W3C) W3C Liaison

Sperberg, Roger

Walsh, Norman

Zergaoui, Mohamed

EPUB 2.0.1

Version 2.0.1 of this specification was prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group under the leadership of:

Conboy, Garth ( eBook Technologies ) Working Group Vice-chair

Kerscher, George ( DAISY Consortium ) Working Group Chair

Active members of the working group at the time of publication of revision 2.0.1 were:

Wiles, Alexis ( OverDrive )

Wise, Alicia ( Publishers Licensing Society )

Moghaddami, Amir ( National Library and Archives of Iran )

Gosling, Andreas ( Penguin UK )

Williams, Andy ( Cambridge University Press )

Jain, Anupam ( Innodata Isogen )

Trafford, Ben ( Invited Expert )

Larroque, Benoit ( Feedbooks )

McCoy, Bill ( Invited Expert )

Kasdorf, Bill ( Apex CoVantage )

Kasher, Bob ( The BookMasters Group )

Duga, Brady ( eBook Technologies )

Laws, Byron ( PreMedia Global )

Zekri, Catherine ( University of Montreal )

Kennedy, Chris ( Pearson Education )

Podolsky, Corey ( Entourage Systems Inc. )

Mussinelli, Cristina ( AIE )

Daihei, Shiohama ( Voyager Japan )

Amos, Dan ( DNAML )

Galperin, Dan ( Kobo )

Kok, Dan ( Crossway Books and Bibles )

Cramer, Dave ( Hachette Book Group USA )

Gunn, Dave ( RNIB Centre for Accessible Information )

Mandelbaum, David ( Barnes&Noble.com )

Roberts, Deidra ( World Health Organization )

Goyette, Donald ( McGraw-Hill Professional )

Freese, Eric ( Aptara )

Gold, Eric ( Digital Divide Data )

Muller, Eric ( Adobe )

Shepherd, Gregory ( Cengage Learning )

Fain, Guy ( Crossway Books & Bibles )

Gardeur, Hadrien ( Feedbooks )

Hoda, Hisashi ( Voyager Japan )

Fernández Galván, Ignacio

Viente, Israel ( Mendele He-Books )

Link, Jim ( Macmillan Publishing Solutions )

MacFarlane, James ( Easypress Technologies )

Rura, Jim ( Educational Testing Service )

Crossman, John ( Benetech )

Prabhu, John ( HOV Services )

Rivlin, John ( eBook Technologies )

Wait, John ( Pearson Education )

Noring, Jon ( Invited Expert )

Tallent, Joshua ( eBook Architects )

Broome, Karen ( Sony )

Fahlgren, Keith ( Threepress Consulting )

Johar, Kenny ( Vision Australia )

Casey, Laurie ( Pearson )

Rzedzicki, Lech ( Pearson UK )

McCloy-Kelley, Liisa ( Random House )

Humphreys, Lindy ( Wiley/ Blackwell Books )

Daly, Liza ( Theepress Consulting )

Murata, Makoto ( JEPA EPUB Study Group )

Croella, Marco ( Simplicissimus Book Farm )

Gylling, Markus ( DAISY Consortium )

Karlsson, Mattias ( Dolphin Computer Access AB )

Smith, Michael ( IDPF )

Soiffer, Neil ( Design Science )

Genner, Noah ( BookNet Canada )

Pagano, Pat ( HarperCollins )

Payton, Patricia ( Bowker )

Barry, Patrick ( The Educational Company of Ireland )

Berube, Patrick ( LEARN )

Durrant, Paul ( Durrant Software Limited )

Norton, Paul ( Invited Expert )

Reid, Penelope ( EPUB User Group (UK) )

Huang, Perce ( Far EasTone Telecommunications )

Brantley, Peter ( Internet Archive )

Sorotokin, Peter ( Adobe )

Heiberger, Richard ( HarperCollins Publishers )

Kwan, Richard ( Invited Expert )

White, Russell ( Random House )

Kakar, Samir ( Aptara )

Pamarty, Satya ( codeMantra )

Cook, Scott ( codeMantra )

Ramsey, Sean ( LibreDigital )

Padgett, Siobahn ( Hachette BG USA )

Arany, Steve ( John Wiley & Sons )

Kanai, Takeshi ( Sony )

Swiderski, Thad ( LibreDigital )

Middleton, Tim ( BookNet Canada )

Conti, Trudy ( Follett )

Ruse, Tyler ( LibreDigital )

Howard, William ( EasyPress Technologies )

EPUB 1.0

Version 1.0 of this specification was prepared by the International Digital Publishing Forum’s Unified OEBPS Container Format Working Group under the leadership of:

Conboy, Garth ( eBook Technologies ) Working Group Co-Chair

Rivlin, John ( eBook Technologies ) Working Group Co-Chair

Ferraiolo, Jon ( IBM ) Working Group Vice-Chair

Bogaty, Nick ( IDPF ) Working Group Secretary

Active members of the working group at the time of publication of revision 1.0 were:

Allen, Kelley L. ( Random House )

Ancin, Angel ( iRex Technologies )

Bandy, Ryan ( Random House )

Bellaver, Richard ( Ball State University )

Brethes, Thierry ( Mobipocket )

Carter, Janice ( Benetech/Bookshare.org )

Cohn, Richard ( Adobe Systems Inc. )

De Young, Neil ( Hachette Book Group USA )

Do, Linh N. ( Random House, Inc. )

Freed, Geoff ( WGBH )

Gang, Liang ( TriWorks Asia )

Ghali, Peter ( Motricity, ereader.com )

Hakkinen, Markku T. ( DAISY Consortium )

Harrison, Gillian ( NetLibrary )

Hevenstone, Jonathan ( Publishing Dimensions )

Horner, Theresa ( HarperCollins )

Iannone, Karen ( Houghton Mifflin )

Israel, Claire ( Simon & Schuster )

Karlsson, Mattias ( Dolphin Computer Access )

Kasdorf, Bill ( Apex Publishing )

Kerscher, George ( DAISY Consortium )

Kotrch, Steve ( Simon & Schuster )

McCoy, Bill ( Adobe Systems, Inc. )

McKenna, Bill ( Follett )

Melton, Bonnie ( Houghton Mifflin College Division )

Noring, Jon ( OpenReader Consortium )

Osayande, Sayu ( Motricity, ereader.com )

Passey, Lee

Potash, Steve ( OverDrive )

Ruse, Tyler ( Codemantra )

Smith, Mike ( Harlequin )

Sugeno, Kimi ( John Wiley & Sons )

Varnell, Gary ( Osoft.com )

Wang, Xin ( ContentGuard, Inc. )

Weinstein, Andrew ( Lightning Source )

Whitcomb, Tom ( NetLibrary )

Williams, Andy ( Cambridge University Press )

Willner, Eli ( Green Point Technology Services )

  References

Normative References

[Alt Style Tags] Alternate Style Tags . Elika J. Etemad.

[CSS Snapshot] CSS Snapshot .

[Content Docs 3.1] EPUB Content Documents 3.1 .

[Core Media Types] EPUB 3 Core Media Types.

[EPUB 3.1] EPUB 3.1 .

[EPUB Accessibility] EPUB Accessibility .

[HTML] HTML .

[Media Overlays 3.1] EPUB Media Overlays 3.1 .

[OCF 3.1] Open Container Format 3.1 .

[OPS2] Open Publication Structure 2.0.1 .

[OpenType] ISO/IEC 14496-22:2015 - Information technology -- Coding of audio-visual objects -- Part 22: Open Font Format . 2015-10-01.

[PLS] Pronunciation Lexicon Specification 1.0 (PLS) . Paolo Baggia. 14 October 2008.

[Packages 3.1] EPUB Packages 3.1 .

[SSML] Speech Synthesis Markup Language (SSML) Version 1.1 . Daniel C. Burnett, et al. 7 September 2010.

[SVG] Scalable Vector Graphics (SVG) .

[WAI-ARIA] Accessible Rich Internet Applications (WAI-ARIA) 1.0 . James Craig, et al. 20 March 2014.

[WCAG 2.0] Web Content Accessibility Guidelines (WCAG) 2.0 . Ben Caldwell, et al.

[WOFF] WOFF File Format 1.0 . Jonathan Kew, et al. 13 December 2012.

[WOFF2] WOFF File Format 2.0 . Vladimir Levantovsky, et al.

Informative References

[EPUB3 Changes] EPUB 3.1 Differences from EPUB 3.0.1 .

[Role] Role Attribute . An attribute to support the role classification of elements. McCarron, et al. 28 March 2013.

EPUB Packages 3.1

Recommended Specification 5 January 2017

This version

http://www.idpf.org/epub/31/spec/epub-packages-20170105.html

Latest version

http://www.idpf.org/epub3/latest/packages

Previous version

http://www.idpf.org/epub/31/spec/epub-packages-20161130.html

Previous recommendation

http://www.idpf.org/epub/301/spec/epub-publications-20140626.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Errata

Editors

Markus Gylling, International Digital Publishing Forum (IDPF)

William McCoy, International Digital Publishing Forum (IDPF)

Matt Garrish, Invited Expert

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Terminology

1.3. Typographic Conventions

1.4. Conformance Statements

1.5. Prefix Mappings

2. Conformance

2.1. Package Conformance

2.2. Reading System Conformance

3. Package Document

3.1. Introduction

3.2. Content Conformance

3.3. Reading System Conformance

3.4. Package Document Definition

3.4.1. The package Element

3.4.2. Shared Attributes

3.4.3. Metadata

3.4.3.1. The metadata Element

3.4.3.2. DCMES Required Elements

3.4.3.2.1. The identifier Element

3.4.3.2.2. The title Element

3.4.3.2.3. The language Element

3.4.3.3. DCMES Optional Elements

3.4.3.3.1. General Definition

3.4.3.3.2. The contributor Element

3.4.3.3.3. The creator Element

3.4.3.3.4. The date Element

3.4.3.3.5. The subject Element

3.4.3.3.6. The type Element

3.4.3.4. The meta Element

3.4.3.5. The link Element

3.4.4. Manifest

3.4.4.1. The manifest Element

3.4.4.2. The item Element

3.4.4.3. Manifest Fallbacks

3.4.5. Spine

3.4.5.1. The spine Element

3.4.5.2. The itemref Element

3.4.6. Collections

3.4.6.1. The collection Element

4. Package Metadata

4.1. Publication Identifiers

4.1.1. Unique Identifier

4.1.2. Release Identifier

4.2. Vocabulary Association Mechanisms

4.2.1. Introduction

4.2.2. Default Vocabularies

4.2.3. Reserved Prefixes

4.2.4. The prefix Attribute

4.2.5. The property Data Type

4.2.5.1. Syntax

4.2.5.2. Processing

4.3. Package Rendering Metadata

4.3.1. Introduction

4.3.2. General Properties

4.3.2.1. The rendition:flow Property

4.3.2.1.1. Usage

4.3.2.1.2. Allowed Values

4.3.2.1.3. Spine Overrides

4.3.2.1.4. Examples

4.3.2.2. The rendition:align-x-center Property

4.3.3. Fixed-Layout Properties

4.3.3.1. Introduction

4.3.3.2. The rendition:layout Property

4.3.3.2.1. Usage

4.3.3.2.2. Allowed Values

4.3.3.2.3. Spine Overrides

4.3.3.2.4. Examples

4.3.3.3. The rendition:orientation property

4.3.3.3.1. Usage

4.3.3.3.2. Allowed Values

4.3.3.3.3. Spine Overrides

4.3.3.3.4. Examples

4.3.3.4. The rendition:spread Property

4.3.3.4.1. Usage

4.3.3.4.2. Allowed Values

4.3.3.4.3. Spine Overrides

4.3.3.4.4. Examples

4.3.3.5. The rendition:page-spread-* Properties

4.3.3.5.1. Usage

4.3.3.5.2. Examples

5. EPUB Navigation Document

5.1. Introduction

5.2. Content Conformance

5.3. Reading System Conformance

5.4. EPUB Navigation Document Definition

5.4.1. The nav Element: Restrictions

5.4.2. The nav Element: Types

5.4.2.1. Introduction

5.4.2.2. The toc nav Element

5.4.2.3. The page-list nav Element

5.4.2.4. The landmarks nav Element

5.4.2.5. Other nav Elements

5.4.3. The hidden attribute

A. Obsolete Features

A.1. Deprecated Features

A.1.1. The refines Attribute

A.1.2. The rendition:spread portrait Value

A.1.3. The rendition:viewport Property

A.2. Superseded Features

A.2.1. NCX

A.2.2. The toc Attribute

B. Package Document Schema

C. The application/oebps-package+xml Media Type

Acknowledgements and Contributors

References

  1 Overview

  1.1 Purpose and Scope

This section is informative

This specification, EPUB Packages 3.1, defines semantics and conformance requirements for an EPUB® Package. Each Package represents one Rendition of an EPUB Publication, and is defined by a Package Document that describes the content of the Rendition and sets the requirements for how Publication Resources are associated.

This specification also defines the EPUB Navigation Document, a machine- and human-readable specialization of an EPUB Content Document that provides navigation aids such as the table of contents.

This specification is one of a family of specifications that compose [EPUB 3.1], an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3.1.

Refer to [EPUB3 Changes] for more information on the differences between this specification and its predecessor.

  1.2 Terminology

Terms with meanings specific to EPUB 3.1 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [EPUB 3.1].

Only the first instance of a term in a section is linked to its definition.

  1.3 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  1.4 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

  1.5 Prefix Mappings

For convenience, the following reserved prefix mappings are used in this specification.

Prefix mappings

prefix | URI
dcterms | http://purl.org/dc/terms/
opf | http://www.idpf.org/2007/opf
rendition | http://www.idpf.org/vocab/rendition/#

  2 Conformance

  2.1 Package Conformance

A conformant EPUB Package must meet all of the following criteria:

Package Document

  It must contain exactly one Package Document, which must conform to the content requirements defined in Package Document — Content Conformance.

Publication Resources

  All Publication Resources associated with the Package must be listed in the Package Document (as defined in manifest).

EPUB Navigation Document

  It must contain exactly one EPUB Navigation Document, which must conform to the content requirements defined in EPUB Navigation Documents — Content Conformance.

Content Documents

  It must contain one or more EPUB Content Documents, each of which must conform to the content requirements defined in [Content Docs 3.1].

CSS Style Sheets

  It may contain zero or more CSS Style Sheets, each of which must conform to the content requirements defined in CSS Style Sheets — Content Conformance [Content Docs 3.1].

Pronunciation Lexicons

  It may contain zero or more PLS Documents, each of which must conform to the content requirements defined in PLS Documents — Content Conformance [Content Docs 3.1].

Media Overlay Documents

  It may contain zero or more Media Overlay Documents, each of which must conform to the content requirements defined in [Media Overlays 3.1].

Additional Resources

  It may contain zero or more Publication Resources in addition to those listed above, each of which must adhere to the requirements in Publication Resources [EPUB 3.1].

  2.2 Reading System Conformance

An EPUB Reading System must meet all of the following criteria:

  It must process the Package Document as defined in Package Document — Reading System Conformance, and honor all presentation logic expressed through the Package Document (e.g., the reading order, fallback chains, page progression direction and fixed layouts).

  It must process the EPUB Navigation Document as defined in EPUB Navigation Documents — Reading System Conformance.

  It must not use any resources not listed in the Package Document in the processing of the Package (e.g., META-INF files [OCF 3.1] and resources specific to other Renditions of the EPUB Publication).

  3 Package Document

  3.1 Introduction

This section is informative

The Package Document is an XML document that consists of a set of elements that each encapsulate information about a particular aspect of the EPUB Package. These elements serve to centralize metadata, detail the individual resources that compose the Package and provide the reading order and other information necessary to render the Rendition.

The following list summarizes the information found in the Package Document:

Metadata — mechanisms to include and/or reference metadata applicable to the given Rendition of the EPUB Publication.

A manifest — identifies (via IRI) and describes (via MIME media type) the set of resources that collectively compose the given Rendition.

A spine — an ordered sequence of ID references to top-level resources in the manifest from which all other resources in the set can be reached or utilized. The spine defines the default reading order of the given Rendition.

Collections — a method of encapsulating and identifying subcomponents within the Package.

Manifest fallback chains — a mechanism that defines an ordered list of top-level resources as content equivalents. A Reading System can then choose between the resources based on which it is capable of rendering.

  3.2 Content Conformance

A Package Document must meet all of the following criteria:

Document Properties

   It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

  It must be valid to the Package Document schema, as defined in Appendix B, Package Document Schema, and conform to all content conformance constraints expressed in Package Document Definition.

File Properties

  The Package Document filename should use the file extension .opf.

Package Documents have the MIME media type application/oebps-package+xml [RFC4839].

  3.3 Reading System Conformance

An EPUB Reading System must meet all of the following criteria:

Processing

  It must process the Package Document in conformance with all Reading System conformance constraints expressed in Package Document Definition.

  It should process rendering metadata, as expressed in Package Rendering Metadata

  It must process fixed layout metadata, as expressed in Fixed-Layout Properties

  It must ignore proprietary metadata properties that pertain to layout expressions if they conflict behaviorally with the property semantics defined in Fixed-Layout Properties.

  3.4 Package Document Definition

All [XML] elements defined in this section are in the http://www.idpf.org/2007/opf namespace [XMLNS] unless otherwise specified.

When an element defined in this section has mandatory text content, that content is referred to as the value of the element in the explanatory descriptions.

  3.4.1 The 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).

Element Name

package

Usage

The package element is the root element of the Package Document.

Attributes

dir [optional]

id [optional]

prefix [optional]

xml:lang [optional]

unique-identifier [required]

version [required]

Content Model

In this order:

metadata [exactly 1]

manifest [exactly 1]

spine [exactly 1]

collection [0 or more]

The version attribute specifies the EPUB specification version to which the given EPUB Package conforms. The attribute must have the value "3.1" to indicate compliance with this version of the specification.

The unique-identifier attribute takes an IDREF [XML] that identifies the dc:identifier element that provides the preferred, or primary, identifier. Refer to Publication Identifiers for more information.

The prefix attribute provides a declaration mechanism for prefixes not reserved by this specification. Refer to The prefix Attribute for more information.

  3.4.2 Shared Attributes

This section provides definitions for shared attributes (i.e., attributes that are allowed on two or more elements).

Attributes with the prefix "opf:" are in the namespace http://www.idpf.org/2007/opf.

dir

Specifies the base text direction of the content and attribute values of the carrying element and its descendants.

Inherent directionality specified using [Unicode] takes precedence over this attribute.

Allowed values are ltr (left-to-right) and rtl (right-to-left).

<package … dir="ltr">

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:description, dc:publisher, dc:relation, dc:rights, dc:subject, dc:title, meta and package.

href

An absolute or relative IRI reference [RFC3987] to a resource.

<link rel="record"
      href="meta/9780000000001.xml"
      media-type="application/marc"/>

Allowed on: item and link.

id

The ID [XML] of the element, which must be unique within the document scope.

<dc:identifier id="pub-id">urn:isbn:97800000000001</dc:identifier>

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:date, dc:description, dc:format, dc:identifier, dc:language, dc:publisher, dc:relation, dc:rights, dc:source, dc:subject, dc:title, dc:type, item, itemref, link, manifest, meta, package and spine.

media-type

A media type [RFC2046] that specifies the type and format of the referenced resource.

<link rel="record"
      href="http://example.org/meta/12389347?format=xmp"
      media-type="application/xml"
      properties="xmp"/>

Allowed on: item and link.

opf:alt-rep

Provides an alternative representation of the element's value in the language and optional script identified by the opf:alt-rep-lang attribute.

<dc:creator opf:alt-rep-lang="ja" opf:alt-rep="村上 春樹">
    Haruki Murakami
</dc:creator>

Allowed on: dc:contributor, dc:creator, dc:publisher, dc:title and meta.

note

As attributes cannot be repeated, only a single alternative representation can be declared for any element.

opf:alt-rep-lang

Specifies the language and optional script of the value of the opf:alt-rep attribute. The value of the attribute must be a language identifier as defined by [BCP 47].

<dc:creator opf:alt-rep-lang="ja" opf:alt-rep="村上 春樹">
    Haruki Murakami
</dc:creator>

The attribute is required whenever opf:alt-rep is used on an element. It must not appear on its own.

opf:file-as

Provides the normalized form of the element's value for sorting.

<dc:creator opf:file-as="Murakami, Haruki">Haruki Murakami</dc:creator>

Reading Systems must trim all leading and trailing white space from the attribute value, as defined by the XML specification [XML], prior to processing.

Allowed on: dc:contributor, dc:creator, dc:publisher, dc:title and meta.

opf:role

Identifies the role of a creator or contributor. The value must be a three-letter lowercase code from [MARC Relators].

<dc:creator opf:role="aut">Haruki Murakami</dc:creator>

Allowed on: dc:contributor and dc:creator.

opf:scheme

Identifies the type of identifier.

<dc:identifier opf:scheme="isbn">9780123456789</dc:identifier>

Allowed on: dc:identifier and dc:source.

properties

A space-separated list of property values.

Refer to each element's definition for the reserved vocabulary that can be used with the attribute.

<item id="nav"
    href="nav.xhtml"
    properties="nav"
    media-type="application/xhtml+xml"/>

Allowed on: item, itemref and link.

xml:lang

Specifies the language used in the contents and attribute values of the carrying element and its descendants, as defined in section 2.12 Language Identification of [XML].

<package … xml:lang="ja">
   …
</package>

Allowed on: collection, dc:contributor, dc:coverage, dc:creator, dc:description, dc:publisher, dc:relation, dc:rights, dc:subject, dc:title, meta and package.

  3.4.3 Metadata

  3.4.3.1 The metadata Element

The metadata element encapsulates meta information for the given Rendition.

Element Name

metadata

Usage

Required first child of package.

Attributes

None

Content Model

In any order:

dc:identifier [1 or more]

dc:title [1 or more]

dc:language [1 or more]

DCMES Optional Elements [0 or more]

meta [1 or more]

link [0 or more]

The Package Document metadata element has two primary functions:

to provide a minimal set of meta information for Reading Systems to use to internally catalogue an EPUB Publication and make it available to a user (e.g., to present in a bookshelf).

to provide access to all rendering metadata needed to control the layout and display of the Rendition's content (e.g., fixed-layout properties).

The Package Document is not designed to provide complex metadata encoding capabilities. If more detailed information about an EPUB Publication is needed, metadata records can be associated using the link element (e.g., that conform to an international standard such as [ONIX] or are created for custom purposes). This approach allows the metadata to be processed in its native form, avoiding the potential problems and information loss caused by translating to use the minimal Package Document structure.

In keeping with this philosophy, the Package Document only has the following minimal metadata requirements: it must include the [DCMES] title, identifier and language elements together with the [DCTERMS] modified property. All other metadata is optional.

The following example shows the minimal set of metadata that Authors have to include in the Package Document.

<package … unique-identifier="pub-id">
    …
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
        <dc:title>Norwegian Wood</dc:title>
        <dc:language>en</dc:language>
        <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
    </metadata>
    …
</package>

The meta element provides a generic mechanism for including metadata properties from any vocabulary. It is typically used to include rendering metadata defined in IDPF specifications, but may be used for any metadata purposes.

note

See [EPUB Accessibility] for accessibility metadata recommendations.

  3.4.3.2 DCMES Required Elements

  3.4.3.2.1 The identifier Element

The [DCMES] identifier element contains an identifier associated with the given Rendition, such as a UUID, DOI or ISBN.

Element Name

dc:identifier

Namespace

http://purl.org/dc/elements/1.1/

Usage

Required child of metadata.

Attributes

id [optional]

opf:scheme [optional]

Content Model

Text

The metadata section must include an identifier element that contains an unambiguous identifier for the Rendition. This identifier must be marked as the Unique Identifier via the package element unique-identifier attribute.

The following example shows the unique identifier element for an EPUB Publication.

<package … unique-identifier="pub-id">
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier id="pub-id">
            urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809
        </dc:identifier>
        …
    </metadata>
</package>

The Unique Identifier for each Rendition may differ, and a Rendition may include additional identifier elements.

To differentiate different versions of the same EPUB Publication, this specification makes a distinction between the Unique Identifier for an EPUB Publication and the Release Identifier that uniquely identifies a specific version of it.

To identify a specific version of a packaged EPUB Publication, a Release Identifier can be constructed by combining the Unique Identifier with the last modified date of the Rendition. For more information on the semantics and requirements of the Release Identifier, refer to Release Identifier.

The following example shows the two components of the Release Identifier.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:identifier id="pub-id">
        urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809
    </dc:identifier>
    <meta property="dcterms:modified">2016-01-01T00:00:01Z</meta>
    …
</metadata>

Whenever a Rendition is modified, it must include a new last modified date.

To determine whether an identifier conforms to an established system or has been granted by an issuing authority, Reading Systems should attempt to parse the value of the element.

For additional precision (e.g., if the scheme cannot be determined from the value or could lead to an ambiguous result), Authors may attach an opf:scheme attribute to assist in Reading System identification. This attribute identifies the system or authority that generated or assigned the value of the element. Its value must be either:

a reserved identifier value [ID Registry] (case-insensitive); or

an absolute IRI [RFC3987] that identifies the scheme. The IRI should refer to a resource that provides more information about the scheme.

The following example shows the opf:scheme attribute used to indicate a dc:identifier element contains an ISBN.

<dc:identifier opf:scheme="isbn">9780123456789</dc:identifier>

When included, the opf:scheme value should take precedence over value parsing the identifier. This specification does not require or endorse the use of any particular scheme for identifiers.

Reading Systems must trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.

This specification imposes no additional restrictions or the requirements of the identifier except that it must be at least one character in length after white space has been trimmed. It is strongly recommended that the identifier be a fully qualified URI, however.

  3.4.3.2.2 The title Element

The [DCMES] title element represents an instance of a name given to the EPUB Publication.

Element Name

dc:title

Namespace

http://purl.org/dc/elements/1.1/

Usage

Required child of metadata.

Attributes

opf:alt-rep [optional]

opf:alt-rep-lang [conditionally required]

dir [optional]

opf:file-as [optional]

id [optional]

xml:lang [optional]

Content Model

Text

The metadata section must include at least one title element containing the title for the EPUB Publication.

The following example shows a multi-part title.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
          xmlns:opf="http://www.idpf.org/2007/opf">
    <dc:title opf:file-as="Fellowship of the Ring">
        THE LORD OF THE RINGS, Part One: The Fellowship of the Ring
    </dc:title>
    …
</metadata>

Reading Systems must recognize the first title element in document order as the main title of the EPUB Publication (i.e., the primary one to present to users). This specification does not define how to process additional title elements.

The title for each Rendition may differ.

Reading Systems must trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.

This specification imposes no additional restrictions or requirements on the title except that it must be at least one character in length after white space has been trimmed.

  3.4.3.2.3 The language Element

The [DCMES] language element specifies the language of the content of the given Rendition.

Element Name

dc:language

Namespace

http://purl.org/dc/elements/1.1/

Usage

Required child of metadata. Repeatable.

Attributes

id [optional]

Content Model

Text

The metadata section must include at least one language element with a value conforming to [BCP 47].

The following example shows an EPUB Publication is in U.S. English.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:language>en-US</dc:language>
    …
</metadata>

Additional language elements may be included for multilingual Publications, but each element's value must conform to [BCP 47].

Languages for each Rendition may differ.

Reading Systems must trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.

  3.4.3.3 DCMES Optional Elements

  3.4.3.3.1 General Definition

With the exception of identifier, language and title, all other [DCMES] elements are designated as optional. These elements conform to the following generalized definition:

Element Name

contributor | coverage | creator | date | description | format | publisher | relation | rights | source | subject | type

Namespace

http://purl.org/dc/elements/1.1/

Usage

Optional child of metadata. Repeatable.

Attributes

opf:alt-rep [optional] – only allowed on contributor, creator, and publisher.

opf:alt-rep-lang [conditionally required] – only allowed on contributor, creator, and publisher.

dir [optional] – only allowed on contributor, coverage, creator, description, publisher, relation, rights and subject.

opf:file-as [optional] – only allowed on contributor, creator, and publisher.

id [optional] – allowed on any element.

opf:role [optional] – only allowed on contributor and creator.

opf:scheme [optional] – only allowed on identifier and source.

xml:lang [optional] – only allowed on contributor, coverage, creator, description, publisher, relation, rights and subject.

Content Model

Text

The optional [DCMES] metadata for each Rendition may differ.

Reading Systems must trim all leading and trailing white space from the element value, as defined by the XML specification [XML], before processing the value.

The value of all optional [DCMES] elements must be at least one character in length after white space has been trimmed.

This specification does not modify the [DCMES] element definitions except as noted in the following sections.

  3.4.3.3.2 The contributor Element

The [DCMES] contributor element is used to represent the name of a person, organization, etc. that played a secondary role in the creation of the content of an EPUB Publication.

The requirements for the contributor element are identical to those for the creator element in all other respects.

  3.4.3.3.3 The creator Element

The [DCMES] creator element represents the name of a person, organization, etc. responsible for the creation of the content of the Rendition.

The creator element should contain the name of the creator as a Reading System will present it to a user. The opf:file-as attribute may be attached to include a normalized form of the name, and the opf:alt-rep attribute may be used to represent a creator's name in another language or script (as indicated in the opf:alt-rep-lang attribute).

The role attribute may be attached to distinguish the role the creator played in the creation of the content (e.g., an author or illustrator).

The following example shows how a creator name can be included to facilitate sorting and rendering.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
          xmlns:opf="http://www.idpf.org/2007/opf">
    …
    <dc:creator id="creator" opf:file-as="Murakami, Haruki">
        Haruki Murakami
    </dc:creator>
    …
</metadata>

If an EPUB Publication has more than one creator, each should be included in a separate creator element.

When determining display priority, Reading Systems must use the document order of creator elements in the metadata section, where the first creator element encountered is the primary creator. If a Reading System exposes creator metadata to the user, it should include all the creators listed in the metadata section whenever possible (e.g., when not constrained by display considerations).

In the following example, Lewis Carroll is the primary creator as he is listed first.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:creator id="creator01">Lewis Carroll</dc:creator>
    <dc:creator id="creator02">John Tenniel</dc:creator>
    …
</metadata>

Secondary contributors should be represented using the contributor element.

  3.4.3.3.4 The date Element

The [DCMES] date element must be used only to define the publication date of the EPUB Publication. The publication date is not the same as the last modified date (the last time the Rendition was changed).

It is recommended that the date string conform to [ISO8601], particularly the subset expressed in W3C Date and Time Formats [DateTime], as such strings are both human and machine readable.

The following example shows a publication date.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <dc:date>2000-01-01T00:00:00Z</dc:date>
    …
</metadata>

Additional dates should be expressed using the specialized date properties available in the [DCTERMS] vocabulary, or similar.

The publication date may be common to all instances of an EPUB Publication or may change from instance to instance (e.g., if the EPUB Publication gets generated on demand).

Only one date element is allowed.

  3.4.3.3.5 The subject Element

The [DCMES] subject element identifies the subject of the EPUB Publication.

In addition to the attributes listed in the general definition, the element takes an optional opf:authority attribute that identifies the system or scheme the element's value is drawn from. The value of the attribute must be either:

a reserved authority value [Authority Registry] (case-insensitive); or

an absolute IRI [RFC3987] that identifies the scheme. The IRI should refer to a resource that provides more information about the scheme.

When a scheme is identified in the opf:authority attribute, the subject code must be included in an opf:term attribute. The value of the element should be the human-readable heading or label, but may be the code value if the subject taxonomy does not provide a separate descriptive label.

The following example shows a BISAC code and heading.

<dc:subject opf:authority="BISAC" opf:term="FIC024000">
    FICTION / Occult &amp; Supernatural
</dc:subject>

The following example shows the use of an IRI for the scheme.

<dc:subject opf:authority="http://www.ams.org/msc/msc2010.html"
            opf:term="11">
    Number Theory
</dc:subject>

The opf:term attribute must not occur on a subject element that does not specify a scheme.

The values of the subject element and opf:term attribute are case sensitive only when the designated scheme requires.

  3.4.3.3.6 The type Element

The [DCMES] type element is used to indicate that the given EPUB Publication is of a specialized type (e.g., annotations or a dictionary packaged in EPUB format).

The IDPF maintains an informative registry of specialized EPUB Publication types for use with this element in [Types Registry].

  3.4.3.4 The meta Element

The meta element provides a generic means of including package metadata.

Element Name

meta

Usage

As child of the metadata element. Repeatable.

Attributes

opf:alt-rep [optional]

opf:alt-rep-lang [conditionally required]

dir [optional]

opf:file-as [optional]

id [optional]

property [required]

refines [optional] [SUPERSEDED]

scheme [optional]

xml:lang [optional]

Content Model

Text

Each meta element defines a metadata expression that establishes some aspect of the EPUB Publication. The property attribute takes a property data type value that defines the statement being made in the expression; the text content of the element represents the assertion. (Refer to Vocabulary Association Mechanisms for more information.)

This specification reserves the [Meta Vocab] for use with the property attribute. Terms from any other vocabulary may be used provided they have a prefix (refer to Reserved Prefixes for a list of prefixes that do not have to be declared).

The following example shows various property declarations using reserved prefixes.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    …
    <meta property="dcterms:modified">2016-02-29T12:34:56Z</meta>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="media:active-class">-epub-media-overlay-active</meta>
    …
</metadata>

The scheme attribute identifies the system or scheme that the element's value is drawn from. The value of the attribute must be a property data type that resolves to the resource that defines the scheme. If a Reading System does not recognize the scheme attribute value, it should treat the value of the element as a string.

Reading Systems should ignore all meta elements whose property attributes define expressions they do not recognize. A Reading System must not fail when encountering unknown expressions.

Unless an individual property explicitly defines a different white space normalization algorithm, Reading Systems must trim all leading and trailing white space from the meta element values, as defined by the XML specification [XML], before further processing them.

Every meta element must express a value that is at least one character in length after white space normalization.

  3.4.3.5 The link Element

The link element is used to associate resources with the given Rendition, such as metadata records.

Element Name

link

Usage

As a child of metadata. Repeatable.

Attributes

href [required]

id [optional]

media-type [conditionally required]

properties [optional]

rel [required]

Content Model

Empty

The metadata element may contain zero or more link elements, each of which identifies the location of a linked resource in its required href attribute

Linked resources are not Publication Resources and must not be listed in the manifest. A linked resource may be embedded in a Publication Resource that is listed in the manifest, however, in which case it must adhere to Core Media Type requirements [EPUB 3.1] (e.g., an EPUB Content Document could contain a metadata record serialized as [RDFa 1.1] or [JSON-LD]).

The following example shows a reference to a metadata record embedded in a script element inside an XHTML Content Document. Note that the media type of the embedded record is obtained from type attribute on the script element; it is not specified in the link element.

<metadata>
    …
    <link rel="record"
          href="front.xhtml#meta-json"
          media-type="application/xhtml+xml"/>
    …
</metadata>

Linked resources may be located locally or remotely, but Authors need to be aware that retrieval of Remote Resources by Reading Systems is optional (i.e., the resource might not be available).

The media-type attribute is optional when a linked resource is located outside the EPUB Container, as more than one media type could be served from the same IRI. The attribute is required for all Local Resources.

The required rel attribute takes a space-separated list of property values that establish the relationship the resource has with the Rendition.

The following example shows the link element used to associate a local MARC XML record.

<link rel="record"
      href="meta/9780000000001.xml"
      media-type="application/marc"/>

Reading System do not have to use or present linked resources, even if they recognize the relationship defined in the rel attribute.

The value of the media-type attribute is not always sufficient to identify the type of linked resource (e.g., many XML-based record formats use the media type "application/xml"). To aid Reading Systems in the identification of such generic resources, the properties attribute can be attached with a semantic identifier.

The following example shows the properties attribute used to identify a remote XMP record.

<link rel="record"
      href="http://example.org/meta/12389347?format=xmp"
      media-type="application/xml"
      properties="xmp"/>

The list of reserved relationships and properties recognized by this specification is defined in [Link Vocab].

Authors may add relationships and properties from other vocabularies via the metadata extensibility mechanism defined in this specification. Authors also may create new values by defining their own prefixes. Refer to Vocabulary Association Mechanisms for more information.

The following example shows the link element used to associate an informational web page. Note that as foaf is not a predefined prefix, it has to be declared in the prefix attribute.

<package … prefix="foaf: http://xmlns.com/foaf/spec/">
    <metadata>
        …
        <link rel="foaf:homepage"
              href="http://example.org/book-info/12389347" />
        …
    </metadata>
    …
</package>

In the case of a linked metadata record, Reading Systems must not skip processing the metadata expressed in the Package Document and only use the information expressed in the record. Linked records are intended to enhance the information available to Reading Systems, and the package metadata typically contains important rendering information. Reading Systems may compile metadata from multiple linked records; they do not have to select only one record.

When it comes to resolving discrepancies and conflicts between metadata expressed in the Package Document and in linked metadata records, Reading Systems must use the document order of link elements in the Package Document to establish precedence (i.e., metadata in the first linked record encountered has the highest precedence and metadata in the Package Document the lowest, regardless of whether the link elements occur before within or after the package metadata elements).

The following example shows that a remote record that has higher precedence than a local record, which in turn has higher precedence than the metadata found in the metadata element.

<metadata>
    …
    <link rel="record"
          href="http://example.org/onix/12389347"
          media-type="application/xml"
          properties="onix" />

    <link rel="record"
          href="meta/meta.jsonld"
          media-type="application/ld+json" />
    …
</metadata>

Reading Systems must ignore any instructions contained in linked resources related to the layout and rendering of the EPUB Publication.

note

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.

  3.4.4 Manifest

  3.4.4.1 The manifest Element

The manifest element provides an exhaustive list of the Publication Resources that constitute the given Rendition, each represented by an item element.

Element name

manifest

Usage

Required second child of package, following metadata.

Attributes

id [optional]

Content Model

item [1 or more]

note

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.

  3.4.4.2 The item Element

The item element represents a Publication Resource.

Element Name

item

Usage

As a child of manifest. Repeatable.

Attributes

duration [conditionally required]

fallback [conditionally required]

href [required]

id [required]

media-overlay [optional]

media-type [required]

properties [optional]

Content Model

Empty

Each item element in the manifest identifies a Publication Resource by the IRI [RFC3987] provided in its href attribute. The IRI may be absolute or relative. In the case of relative IRIs, Reading Systems must use the IRI of the Package Document as the base when resolving these to absolute IRIs. The resulting absolute IRI must be unique within the manifest scope.

All Publication Resources must be referenced from the manifest, regardless of whether they are Local or Remote Resources. Refer to Publication Resource Locations [EPUB 3.1] for media type-specific requirements regarding resource locations.

Note that the manifest is not self-referencing: it must not include an item element that refers to the Package Document itself.

The Publication Resource identified by an item element must conform to the applicable specification(s) as inferred from the MIME media type provided in the media-type attribute. Core Media Type Resources must use the media type designated in [Core Media Types].

The fallback attribute takes an IDREF [XML] that identifies a fallback for the Publication Resource referenced from the item element. Fallbacks may be provided for Core Media Type Resources (e.g., to provide a static alternative to a Scripted Content Document). Fallback requirements for Foreign Resources are defined in Manifest Fallbacks.

This specification reserves the [Manifest Vocab] for use with the properties attribute. Terms from other vocabularies may be used provided they have a prefix (refer to Reserved Prefixes for a list of prefixes that do not have to be declared).

Authors must declare all applicable descriptive metadata properties for each Publication Resource in this attribute, as Reading Systems may optimize the rendering depending on the properties that have been set (e.g., disable a rendering process or use a fallback). Reading Systems must ignore all descriptive metadata properties that they do not recognize.

Exactly one item must be declared as the EPUB Navigation Document using the nav property.

The media-overlay attribute takes an IDREF [XML] that identifies the Media Overlay Document for the resource described by this item. Refer to Packaging [Media Overlays 3.1] for more information.

The duration attribute takes a [SMIL] clock value that provides the total duration of the audio media referenced from a Media Overlay Document or, in the case of timed media, the total duration of the referenced media file. Refer to Package Metadata [Media Overlays 3.1] for more information.

note

The order of item elements in the manifest is not significant. The presentation sequence of content documents is provided in the spine.

Examples

The following example shows a manifest that contains only Core Media Type Resources.

<manifest>
    <item id="nav"
          href="nav.xhtml"
          properties="nav"
          media-type="application/xhtml+xml"/>
    <item id="intro"
          href="intro.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c1"
          href="chap1.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c1-answerkey"
          href="chap1-answerkey.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c2"
          href="chap2.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c2-answerkey"
          href="chap2-answerkey.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c3"
          href="chap3.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="c3-answerkey"
          href="chap3-answerkey.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="notes"
          href="notes.xhtml"
          media-type="application/xhtml+xml"/>
    <item id="cover"
          href="./images/cover.svg"
          properties="cover-image"
          media-type="image/svg+xml"/>
    <item id="f1"
          href="./images/fig1.jpg"
          media-type="image/jpeg"/>
    <item id="f2"
          href="./images/fig2.jpg"
          media-type="image/jpeg"/>
    <item id="css"
          href="./style/book.css"
          media-type="text/css"/>
    <item id="pls"
          href="./speech/dict.pls"
          media-type="application/pls+xml"/>
</manifest>

The following example shows a manifest that references two Foreign Resources, and therefore uses the fallback chain mechanism to supply content alternatives. The fallback chain terminates with a Core Media Type.

<manifest>
    <item id="item1"
          href="chap1_docbook.xml"
          media-type="application/docbook+xml"
          fallback="fall1"/>
    <item id="fall1"
          href="chap1.xml"
          media-type="application/z3998-auth+xml"
          fallback="fall2" />
    <item id="fall2"
          href="chap1.xhtml"
          media-type="application/xhtml+xml"/>
    …
</manifest>

The following example shows a reference to a remote audio file that has to be referenced from the manifest (the audio is rendered inline in the XHTML Content Document so it is a Publication Resource).

XHTML:
<audio src="http://www.example.com/book/audio/ch01.mp4" controls="controls"/>

Manifest:
<item id="audio01"
      href="http://www.example.com/book/audio/ch01.mp4"
      media-type="audio/mp4"/>

The following example shows a link to the same audio file, but in this case it is not be listed in the manifest (hyperlinked Remote Resources are not Publication Resources). The audio file would only be listed in the manifest if the Author has also referenced it from an [HTML] embedded content element, as above (i.e., in a context where it is used as a Publication Resource).

XHTML:
<a href="http://www.example.com/book/audio/ch01.mp4">Go to audio file</a>

Manifest:
No Entry

The following example shows a link to a local version of the audio file. Because audio files are not EPUB Content Documents, it requires a fallback to an EPUB Content Document (it also has to be listed in the spine).

XHTML:
<a href="audio/ch01.mp4">Open Audio File</a>

Manifest:
<item id="audio01"
      href="audio/ch01.mp4"
      media-type="audio/mp4"
      fallback="#audio01-xhtml"/>

  3.4.4.3 Manifest Fallbacks

Foreign Resources may be referenced in contexts in which an intrinsic fallback cannot be provided (e.g., directly from spine itemref elements; from [HTML] img, iframe and link elements in XHTML Content Documents; and from @import rules in CSS Style Sheets). Manifest fallbacks must be provided in such cases.

Manifest fallbacks are provided using the fallback attribute on the manifest item element that represents the Publication Resource. The fallback attribute's IDREF [XML] value must resolve to another item in the manifest. This fallback item may itself specify another fallback item, and so on.

The ordered list of all the ID references that can be reached starting from a given item's fallback attribute represents the fallback chain for that item. The order of the resources in the fallback chain represents the Author's preferred fallback order.

A Reading System that does not support the Media Type of a given Publication Resource must traverse the fallback chain until it has identified at least one supported Publication Resource to be used in place of the unsupported resource. If the Reading System supports multiple Publication Resources in the fallback chain, it may select the resource to use based on specific properties of that resource, otherwise it should honor the Author's preferred fallback order.

Fallback chains must conform to one of the following requirements, as appropriate:

For Foreign Resources referenced directly from spine itemref elements, the chain must contain at least one EPUB Content Document.

For Foreign Resources for which an intrinsic fallback cannot be provided, the chain must contain at least one Core Media Type Resource.

Fallback chains must not contain any circular- or self-references to item elements in the chain.

Fallbacks may also be provided for Top-Level Content Documents that are EPUB Content Documents; a Reading System may choose to utilize such fallbacks in order to find the optimal version of a Content Document to render in a given context. An example of when this feature can be utilized is when providing fallbacks for scripted content [Content Docs 3.1].

  3.4.5 Spine

  3.4.5.1 The spine Element

The spine element defines an ordered list of manifest item references that represent the default reading order of the given Rendition.

Element name

spine

Usage

Required third child of package, following manifest.

Attributes

id [optional]

page-progression-direction [optional]

toc [optional] [OBSOLETE]

Content Model

itemref [1 or more]

Reading Systems must provide a means of rendering the Rendition in the order defined in the spine, which includes: 1) recognizing the first primary itemref as the beginning of the default reading order; and, 2) rendering successive primary items in the order given in the spine.

All Publication Resources that are hyperlinked to from Publication Resources in the spine must themselves be listed in the spine, where hyperlinking is defined to be any linking mechanism that requires the user to navigate away from the current resource. Common hyperlinking mechanisms include the href attribute of the [HTML] a and area elements and scripted links (e.g., using DOM Events and/or form elements). The requirement to list hyperlinked resources applies recursively (i.e., all Publication Resources hyperlinked from hyperlinked Publication Resources also have to be listed, and so on.).

All Publication Resources hyperlinked to from the EPUB Navigation Document also must be listed in the spine, regardless of whether the Navigation Document is itself listed the spine.

note

As Remote Resources referenced from hyperlinks are not Publication Resources, they are not subject to the requirement to include in the spine (e.g., Web pages and resources).

Embedded Publication Resources (e.g., via the [HTML] iframe element) do not have to be listed in the spine.

The page-progression-direction attribute sets the global direction in which the content flows. Allowed values are ltr (left-to-right), rtl (right-to-left) and default. When the default value is specified, the Author is expressing no preference and the Reading System can choose the rendering direction. The default value must be assumed when the attribute is not specified.

Although the page-progression-direction attribute sets the global flow direction, individual Content Documents and parts of Content Documents may override this setting (e.g., via the writing-mode CSS property). Reading Systems may also provide mechanisms to override the default direction (e.g., buttons or settings that allow the application of alternate style sheets).

Reading Systems must ignore the page progression direction defined in pre-paginated XHTML Content Documents. The page-progression-direction attribute defines the flow direction from one fixed-layout page to the next.

  3.4.5.2 The 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.

Element Name

itemref

Usage

As a child of spine. Repeatable.

Attributes

id [optional]

idref [required]

linear [optional]

properties [optional]

Content Model

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.

note

Although EPUB Publications have to include an EPUB Navigation Document, it is not mandatory to include it in the spine.

The linear attribute indicates whether the referenced item contains content that contributes to the primary reading order and has to be read sequentially ("yes") or auxiliary content that enhances or augments the primary content and can be accessed out of sequence ("no"). Examples of auxiliary content include: notes, descriptions and answer keys.

The linear attribute allows Reading Systems to distinguish content that a user needs to access as part of the default reading order from supplementary content which might, for example, be presented in a popup window or omitted from an aural rendering.

When rendering an EPUB Publication, a Reading System may either suppress non-linear content so that it does not appear in the default reading order, or ignore the linear attribute in order to provide users access to the entire content of the EPUB Publication. This specification does not mandate which model Reading Systems have to use. A Reading System may also provide the option for users to toggle between the two models.

Each Rendition must include at least one itemref whose linear attribute value is either explicitly or implicitly set to "yes". An itemref that omits the linear attribute is assumed to have the value "yes".

Authors must provide a means of accessing all non-linear content (e.g., hyperlinks in the content or from the EPUB Navigation Document).

This specification reserves the [Spine Vocab] for use with the properties attribute. Terms from any other vocabulary may be used provided they have a prefix (refer to Reserved Prefixes for a list of prefixes that do not have to be declared).

All applicable descriptive metadata properties defined in [Spine Vocab] should be declared.

Reading Systems must ignore all metadata properties expressed in the properties attribute that they do not recognize.

Examples

The following example shows a spine element corresponding to the manifest example above.

<spine page-progression-direction="ltr">
    <itemref idref="intro"/>
    <itemref idref="c1"/>
    <itemref idref="c1-answerkey" linear="no"/>
    <itemref idref="c2"/>
    <itemref idref="c2-answerkey" linear="no"/>
    <itemref idref="c3"/>
    <itemref idref="c3-answerkey" linear="no"/>
    <itemref idref="notes" linear="no"/>
</spine>

  3.4.6 Collections

  3.4.6.1 The collection Element

The collection element defines a related group of resources.

Element Name

collection

Usage

Optional sixth element of package. Repeatable.

Attributes

dir [optional]

id [optional]

role [required]

xml:lang [optional]

Content Model

In this order: metadata [0 or 1], ( collection [1 or more] or ( collection [0 or more], link [1 or more] ))

The collection element allows resources to be assembled into logical groups for a variety of potential uses: enabling content that has been split across multiple EPUB Content Documents to be reassembled back into a meaningful unit (e.g., an index split across multiple documents), identifying resources for specialized purposes (e.g., preview content), or collecting together resources that present additional information about the given Rendition.

The collection element, as defined in this section, represents a generic framework from which specializations are intended to be derived (e.g., through IDPF sub-specifications). Such specializations must define the purpose of the collection element within a Rendition, as well as all requirements for its valid production and use (specifically any requirements that differ from the general framework presented below).

Each specialization must define a role value that uniquely identifies all conformant collection elements. The role of each collection element in the Package Document must be identified in its role attribute, whose value must be one or more NMTOKENs [XSD-DATATYPES] and/or absolute IRIs [RFC3987]. The use of NMTOKEN values is reserved for IDPF-defined roles, which are maintained in the [Role Registry]. NMTOKEN values not defined in the registry are not valid. No roles are defined in this section.

Third parties may define custom roles for the collection element, but such roles must be identified using absolute IRIs. Custom roles must not incorporate the string "idpf.org" in the host component of their identifying IRI.

note

To facilitate interoperability of custom roles across Reading Systems, implementers are strongly encouraged to document their use of the collection element in [Role Extensions].

The optional metadata element child of collection is an adaptation of the package metadata element, with the following differences in syntax and semantics:

No metadata is mandatory by default.

Package-level restrictions on the use of metadata elements may be overridden.

A collection may define sub-collections through the inclusion of one or more child collection elements.

The link element child of collection is an adaptation of the metadata link element, with the following differences in syntax and semantics:

The rel attribute is optional.

The properties attribute also accepts manifest item properties [Manifest Vocab] without a prefix (e.g., so that a collection can declare its own Navigation Document or cover image).

Each link element must reference a resource that is a member of the group. The order of link elements is not significant.

Specializations of the collection element may tailor the requirements defined above to better reflect their needs (e.g., requiring metadata, imposing further restrictions on the use of elements and attributes, or making the order of link elements significant). However, the resulting content model must represent a valid subset of the one defined in this section (e.g., specializations cannot introduce new elements or attributes, or re-introduce those expressly forbidden above). Specializations must not define collections in a way that overrides the requirements of the manifest and spine.

In the context of this specification, support for collections in Reading Systems is optional. Reading Systems must ignore collection elements that define unrecognized roles.

The rendering of a Rendition must not be dependent on the recognition of collection elements. The content must remain consumable by a user without any information loss or other significant deterioration.

Examples

The following example shows the assembly of two XHTML Content Documents that represent a single unit.

<package …>
    …
    <collection role="http://example.org/roles/unit">
        <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
            <dc:title>Foo Bar</dc:title>
        </metadata>
        <link href="EPUB/xhtml/foo-1.xhtml"/>
        <link href="EPUB/xhtml/foo-2.xhtml"/>
    </collection>
    …
</package>

  4 Package Metadata

  4.1 Publication Identifiers

  4.1.1 Unique Identifier

The Author is responsible for including a primary identifier in the Package Document metadata that is unique to one and only one EPUB Publication. This Unique Identifier, whether chosen or assigned, must be stored in the dc:identifier element and be referenced as the Unique Identifier in the package element unique-identifier attribute.

Although not static, changes to the Unique Identifier for an EPUB Publication should be made as infrequently as possible. New identifiers should not be issued when updating metadata, fixing errata or making other minor changes to the EPUB Publication.

Reading Systems must not depend on the Unique Identifier being unique to one and only one EPUB Publication. Determining whether two EPUB Publications with the same Unique Identifier represent different versions of the same publication (see Release Identifier), or different publications, might require inspecting other metadata, such as the titles or authors.

  4.1.2 Release Identifier

The Unique Identifier of an EPUB Publication typically should not change with each minor revision to the package or its contents, as Unique Identifiers are intended to have maximal persistence both for referencing and distribution purposes. Each release of an EPUB Publication normally requires that the new version be uniquely identifiable, however, which results in the contradictory need for reliable Unique Identifiers that are changeable.

To redress this problem of identifying minor modifications and releases without changing the Unique Identifier, this specification defines the semantics for a Release Identifier, or means of distinguishing and sequentially ordering EPUB Publications with the same Unique Identifier.

The Release Identifier is not an actual property in the package metadata section, but is a value that can be obtained from two other mandatory pieces of metadata: the Unique Identifier and the last modification date of the Rendition. When the taken together, the combined value represents a unique identity that can be used to distinguish any particular version of an EPUB Publication from another.

To ensure that a Release Identifier can be constructed, each Rendition must include exactly one [DCTERMS] modified property containing its last modification date. The value of this property must be an [XSD-DATATYPES] dateTime conformant date of the form:

CCYY-MM-DDThh:mm:ssZ

The last modification date must be expressed in Coordinated Universal Time (UTC) and must be terminated by the "Z" (Zulu) time zone indicator.

Although not a part of the package metadata, for referencing and other purposes all string representations of the identifier must be constructed using the at sign (@) as the separator (i.e., of the form "id@date"). Whitespace must not be included when concatenating the strings.

The following example shows how a Unique Identifier and modification date are combined to form the Release Identifier.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>
    <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>
    …
</metadata>

results in the Package ID:

urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809@2011-01-01T12:00:00Z

Note that it is possible that the separator character may occur in the Unique Identifier, as these identifiers may be any string value. The Release Identifier consequently must be split on the last instance of the at sign when decomposing it into its component parts.

The Release Identifier does not supersede the Unique Identifier, but represents the means by which different versions of the same EPUB Publication can be distinguished and identified in distribution channels and by Reading Systems. The sequential, chronological order inherent in the format of the timestamp also places EPUB Publications in order without requiring knowledge of the exact identifier that came before.

The Release Identifier consequently allows a set of EPUB Publications to be inspected to determine if they represent the same version of the same Publication, different versions of a single EPUB Publication, or any combination of differing and similar EPUB Publications.

note

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.

  4.2 Vocabulary Association Mechanisms

  4.2.1 Introduction

This section is informative

The property, properties, rel and scheme attributes use the property data type to represent terms from metadata vocabularies. Similar to a CURIE [RDFa 1.1], the property data type represents an IRI [RFC3987] in compact form and simplifies the authoring of metadata from standardized vocabularies.

A property value is an expression that consists of a prefix and a reference, where the prefix — whether literal or implied — is a shorthand mapping of an IRI that typically resolves to a term vocabulary. When the prefix is converted to its IRI representation and combined with the reference, the resulting IRI normally resolves to a fragment within that vocabulary that contains human- and/or machine-readable information about the term.

To assist Reading Systems in processing property values, this specification defines three mechanisms to establish the IRI a prefix maps to:

default vocabularies — define the mapping when a property value does not include a prefix;

reserved prefixes — these mappings are predefined (i.e., all Reading Systems recognize them) and can be used without having to be declared; and

the prefix attribute — a declarative means of creating new prefix mappings on the root package element.

  4.2.2 Default Vocabularies

A default vocabulary is a vocabulary that does not require a prefix to be declared in order to use its terms, and whose terms must always be unprefixed.

As the Package Document has multiple unrelated uses for metadata terms, a single default vocabulary is not defined for all attributes. Instead, different default vocabularies are defined for use in attributes that accept a property data type as follows:

The EPUB Meta Properties Vocabulary [Meta Vocab] is defined to be the default vocabulary for the meta properties attribute.

If the attribute's value does not include a prefix, the following IRI [RFC3987] stem must be used to generate the resulting IRI: http://idpf.org/epub/vocab/package/meta/#

The EPUB Metadata Link Vocabulary [Link Vocab] is defined to be the default vocabulary for the link rel and properties attributes.

If any of these attributes' values do not include a prefix, the following IRI [RFC3987] stem must be used to generate the resulting IRI for them: http://idpf.org/epub/vocab/package/link/#

The EPUB Manifest Properties Vocabulary [Manifest Vocab] is defined to be the default vocabulary for the item properties attribute.

If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem must be used to generate the resulting IRI for them: http://idpf.org/epub/vocab/package/item/#

The EPUB Spine Properties Vocabulary [Spine Vocab] is defined to be the default vocabulary for the itemref properties attribute.

If any of the attribute's values do not include a prefix, the following IRI [RFC3987] stem must be used to generate the resulting IRI for them: http://idpf.org/epub/vocab/package/itemref/#

The IRIs associated with these vocabularies must not be assigned a prefix using the prefix attribute.

  4.2.3 Reserved Prefixes

This specification reserves a set of prefixes that Authors may use in package metadata without having to declare. These prefixes are defined in [Reserved Prefixes].

The prefixes defined in this document are maintained and updated separately of this specification and are subject to change at any time.

Reading Systems must resolve all reserved prefixes used in Package Documents using their predefined URIs unless a local prefix is declared. Reserved prefixes should not be overridden in the prefix attribute, but Reading Systems must use such local overrides when encountered.

As changes to the reserved prefixes and updates to Reading Systems are not always going happen in synchrony, Reading Systems must not fail when encountering unrecognized prefixes (i.e., not reserved and not declared using the prefix attribute).

  4.2.4 The prefix Attribute

The prefix attribute defines additional prefix mappings not reserved by this specification.

The value of the prefix attribute is a white space-separated list of one or more prefix-to-IRI mappings of the form:

(EBNF productions ISO/IEC 14977)
All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F).

prefixes | = | mapping , { whitespace, { whitespace } , mapping } ; |
mapping | = | prefix , ":" , space , { space } , ? xsd:anyURI ? ; |
prefix | = | ? xsd:NCName ? ; |
space | = | #x20 ; |
whitespace | = | (#x20 | #x9 | #xD | #xA) ; |

The following example shows prefixes for the Friend of a Friend (foaf) and DBPedia (dbp) vocabularies being declared using the prefix attribute.

<package …
	prefix="foaf: http://xmlns.com/foaf/spec/
		 dbp: http://dbpedia.org/ontology/">
	…
</package>

To avoid conflicts, the prefix attribute must not be used to declare a prefix that maps to the default vocabulary. If the prefix attribute includes a declaration for a predefined prefix, Reading Systems must use the URI mapping defined in the prefix attribute, regardless of whether of it maps to the same URI as the predefined prefix.

The prefix '_' must not be declared as it is reserved for future compatibility with RDFa [RDFa 1.1] processing.

For future compatibility with alternative serializations of the Package Document, a prefix for the Dublin Core /elements/1.1/ namespace [DCTERMS] must not be declared in the prefix attribute. Authors must use only the [DCMES] elements allowed in the Package Document metadata.

  4.2.5 The property Data Type

  4.2.5.1 Syntax

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.

(EBNF productions ISO/IEC 14977)
All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F).

property
=
[ prefix , ":" ] , reference;

prefix
=
? xsd:NCName ? ;

reference
=
? irelative-ref ? ;
/* as defined in [RFC3987] */

The property data type is derived from the CURIE data type defined in [RDFa 1.1], and represents a subset of CURIEs.

The following example shows a property value composed of the prefix dcterms and the reference modified.

<meta property="dcterms:modified">2011-01-01T12:00:00Z</meta>

After processing, this property would expand to the following IRI:

http://purl.org/dc/terms/modified

as the dcterms: prefix is a reserved prefix that maps to the IRI "http://purl.org/dc/terms/".

When a prefix is omitted from a property value, the expressed reference represents a term from the default vocabulary for that attribute.

The following example shows the [Manifest Vocab] mathml property on a manifest item element:

<item … properties="mathml"/>

This property expands to:

http://idpf.org/epub/vocab/package/item/#mathml

when the IRI for the vocabulary is concatenated with the reference.

An empty string does not represent a valid property value, even though it is valid to the definition above.

  4.2.5.2 Processing

A Reading System must use the following rules to create an IRI [RFC3987] from a property:

If the property consists only of a reference, the IRI is obtained by concatenating the IRI stem associated with the default vocabulary to the reference.

If the property consists of a prefix and reference, the IRI is obtained by concatenating the IRI stem associated with the prefix to the reference. If no matching prefix has been defined, the property is invalid and must be ignored.

The resulting IRI must be valid to [RFC3987]. Reading Systems do not have to resolve this IRI, however.

  4.3 Package Rendering Metadata

  4.3.1 Introduction

This section is informative

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.

  4.3.2 General Properties

  4.3.2.1 The rendition:flow Property

  4.3.2.1.1 Usage

When the rendition:flow property [Rendition Vocab] is specified on a meta element, it indicates the Author's global preference for overflow content handling (i.e., for all spine items). Authors may indicate a preference for dynamic pagination or scrolling. For scrolled content, it is also possible to specify whether consecutive EPUB Content Documents are to be rendered as a continuous scrolling view or whether each is to be rendered separately (i.e., with a dynamic page break between each).

If a Reading System supports the specified rendering, it should use that method to handle overflow content, but may provide the option for users to override the requested rendering.

The default value auto must be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the metadata section. Reading Systems may support only this default value.

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

Note that when two reflowable EPUB Content Documents occur sequentially in the spine, the default rendering for their [HTML] body elements is consistent with the page-break-before property [CSS Snapshot] having been set to always. In addition to using the rendition:flow property, Authors may override this behavior through an appropriate style sheet declaration, if the Reading System supports such overrides.

The rendition:flow property must not be declared more than once.

  4.3.2.1.2 Allowed Values

The following values are defined for use with the rendition:flow property:

paginated

The Reading System should dynamically paginate all overflow content.

scrolled-continuous

The Reading System should render all Content Documents such that overflow content is scrollable, and the EPUB Publication represented by the given Rendition should be presented as one continuous scroll from spine item to spine item (except where locally overridden).

note

It is expected that a future version of this specification will provide more information about Reading System behaviors for scrolled-continuous.

scrolled-doc

The Reading System should render all Content Documents such that overflow content is scrollable, and each spine item should be presented as a separate scrollable document.

auto

The Author does not have a preference for overflow handling. The Reading System may render overflow content using its default method or a user preference, whichever is applicable.

  4.3.2.1.3 Spine Overrides

The rendition:flow-auto, rendition:flow-paginated, rendition:flow-scrolled-continuous and rendition:flow-scrolled-doc properties [Rendition Vocab] may be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.

Only one of these overrides is allowed on any given spine item.

For the rendition:flow-scrolled-continuous property, the scroll direction is defined relative to the block flow direction of the root element of the XHTML Content Document referenced by the itemref element. The scroll direction is vertical if the block flow direction is downward (top-to-bottom). It is horizontal if the block flow direction of the root element is rightward (left-to-right) or leftward (right-to-left).

  4.3.2.1.4 Examples

The following example demonstrates an Author's intent to have a paginated Rendition with a scrollable table of contents.

<metadata>
    <meta property="rendition:flow">paginated</meta>
</metadata>

<spine>
    <itemref idref="toc" properties="rendition:flow-scrolled-doc"/>
    <itemref idref="c01"/>
</spine>

  4.3.2.2 The rendition:align-x-center Property

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

For reflowable content, Reading Systems that support this property must center each virtual page.

This version of this specification does not define a default rendering behavior when this property is not supported or specified. Reading Systems may render spine items by their own design.

note

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.

  4.3.3 Fixed-Layout Properties

  4.3.3.1 Introduction

This section is informative

EPUB documents, unlike print books or PDF files, are designed to change. The content flows, or reflows, to fit the screen and to fit the needs of the user. As noted in Rendering and CSS [EPUB3 Overview] “content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content”

But this principle doesn’t work for all types of documents. Sometimes content and design are so intertwined they cannot be separated. Any change in appearance risks changing the meaning, or losing all meaning. Fixed-Layout Documents give Authors greater control over presentation when a reflowable EPUB is not suitable for the content.

This section defines a set of metadata properties to allow declarative expression of intended rendering behaviors of Fixed-Layout Documents in the context of EPUB 3.1.

note

EPUB 3.1 affords multiple mechanisms for representing fixed-layout content. When fixed-layout content is necessary, the Author's choice of mechanism will depend on many factors including desired degree of precision, file size, accessibility, etc. This section does not attempt to dictate the Author's choice of mechanism.

  4.3.3.2 The rendition:layout Property

  4.3.3.2.1 Usage

When the rendition:layout property [Rendition Vocab] is specified on a meta element, it indicates that the paginated or reflowable layout style applies globally for the Rendition (i.e., for all spine items).

The default value reflowable must be assumed by EPUB Reading Systems as the global value if no meta element carrying this property occurs in the metadata section.

When the rendition:layout property is set to pre-paginated, Reading Systems must not include space between the adjacent content slots when rendering Synthetic Spreads.

When the property is set to pre-paginated for a spine item, its content dimensions must be set as defined in Fixed Layouts [Content Docs 3.1].

The rendition:layout property must not be declared more than once.

note

Refer to rendition:viewport property for how to additionally declare the dimensions within the package metadata to facilitate Reading System optimization of the rendering.

  4.3.3.2.2 Allowed Values

The following values are defined for use with the rendition:layout property:

reflowable

The given Rendition is not pre-paginated. Reading Systems may apply dynamic pagination when rendering.

pre-paginated

The given Rendition is pre-paginated. Reading Systems must produce exactly one page per spine itemref when rendering.

note

Reading Systems typically restrict or deny the application of user or user agent style sheets to pre-paginated documents, since, as a result of intrinsic properties of such documents, dynamic style changes are highly likely to have unintended consequences. Authors need to take into account the negative impact on usability and accessibility that these restrictions have when choosing to use pre-paginated instead of reflowable content. Refer to Guideline 1.4 - Provide text configuration [UAAG 2.0] for related information.

  4.3.3.2.3 Spine Overrides

The rendition:layout-pre-paginated and rendition:layout-reflowable properties [Rendition Vocab] may be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.

Only one of these overrides is allowed on any given spine item.

  4.3.3.2.4 Examples

The following example demonstrates fully fixed-layout content, using [Media Queries] to apply different style sheets for three different device categories. Note that the Media Queries only affect the style sheet applied to the document; the size of the content area set in the viewport meta tag is static.

Package Document

<meta property="rendition:layout">pre-paginated</meta>

XHTML

<head>
    <meta name="viewport" content="width=1200, height=900"/>

    <link rel="stylesheet" href="eink-style.css" media="(max-monochrome: 3)"/>
    <link rel="stylesheet" href="skinnytablet-style.css" media="((color) and
        (max-height:600px) and (orientation:landscape), (color) and (max-width:600px)
        and (orientation:portrait))"/>
    <link rel="stylesheet" href="fattablet-style.css" media="((color) and
        (min-height:601px) and (orientation:landscape), (color) and (min-width:601px)
        and (orientation:portrait)"/>
</head>

  4.3.3.3 The rendition:orientation property

  4.3.3.3.1 Usage

When the rendition:orientation property [Rendition Vocab] is specified on a meta element, it indicates that the intended orientation applies globally for the given Rendition (i.e., for all spine items).

The default value auto must be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the metadata section.

The rendition:orientation property must not be declared more than once.

  4.3.3.3.2 Allowed Values

The following values are defined for use with the rendition:orientation property:

landscape

The given Rendition is intended for landscape rendering.

portrait

The given Rendition is intended for portrait rendering.

auto

The given Rendition is not orientation constrained.

Reading Systems that support multiple orientations should convey the intended orientation to the user, unless the given value is auto. The means by which the intent is conveyed is implementation-specific.

  4.3.3.3.3 Spine Overrides

The rendition:orientation-landscape, rendition:orientation-portrait and rendition:orientation-auto properties [Rendition Vocab] may be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.

Only one of these overrides is allowed on any given spine item.

  4.3.3.3.4 Examples

The following example demonstrates fully fixed-layout content intended to be rendered without synthetic spreads, and locked to landscape orientation.

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:spread">none</meta>

    <meta property="rendition:orientation">landscape</meta>
</metadata>

  4.3.3.4 The rendition:spread Property

  4.3.3.4.1 Usage

When the rendition:spread property is specified on a meta element, it indicates that the intended Synthetic Spread behavior applies globally for the given Rendition (i.e., for all spine items).

The default value auto must be assumed by Reading Systems as the global value if no meta element carrying this property occurs in the metadata section.

The rendition:spread property must not be declared more than once.

  4.3.3.4.2 Allowed Values

The following values are defined for use with the rendition:spread property:

none

Reading Systems must not incorporate spine items in a Synthetic Spread.

landscape

Reading Systems should render a Synthetic Spread for spine items only when the device is in landscape orientation.

both

Reading Systems should render a Synthetic Spread regardless of device orientation.

auto

No explicit Synthetic Spread behavior is defined. Reading Systems may use Synthetic Spreads in specific or all device orientations as part of a Content Display Area utilization optimization process.

note

When Synthetic Spreads are used in the context of HTML and SVG Content Documents, the dimensions given via the viewport meta element [Content Docs 3.1] and viewBox attribute [Content Docs 3.1] represents the size of one page in the spread, respectively.

note

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.

  4.3.3.4.3 Spine Overrides

The rendition:spread-landscape, rendition:spread-both, rendition:spread-auto and rendition:spread-none properties [Rendition Vocab] may be specified locally on spine itemref elements, and will, in such cases, override the global value for the given spine item.

Only one of these overrides is allowed on any given spine item.

  4.3.3.4.4 Examples

The following example demonstrates fully fixed-layout content intended to be rendered using synthetic spreads in landscape orientation, and with no spreads in portrait orientation.

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:spread">landscape</meta>
</metadata>

The following example demonstrates reflowable content with a single fixed-layout title page, where the fixed-layout page is intended for right-hand spread slot if the device renders Synthetic Spreads.

<metadata>
    <meta property="rendition:layout">reflowable</meta>
    <meta property="rendition:spread">auto</meta>
</metadata>

<spine>
    <itemref idref="titlepage" properties="page-spread-right rendition:layout-pre-paginated"/>
</spine>

  4.3.3.5 The rendition:page-spread-* Properties

  4.3.3.5.1 Usage

When a Reading System renders a Synthetic Spread, the default behavior is to populate the spread by rendering the next EPUB Content Document in the next available unpopulated viewport, where the next available viewport is determined by the given page progression direction or by local declarations within Content Documents. By providing one of the rendition:page-spread-left, rendition:page-spread-right or rendition:page-spread-center properties [Rendition Vocab] on a spine itemref element, an Author may override this automatic population behavior by forcing that document to be placed in a particular viewport.

The rendition:page-spread-left property indicates that the given spine item should be rendered in the left-hand slot in the spread, and rendition:page-spread-right that it should be rendered in the right-hand slot. The rendition:page-spread-center property indicates that the synthetic spread mode should be overridden and a single viewport rendered and positioned at the center of the screen.

The rendition:page-spread-left, rendition:page-spread-right and rendition:page-spread-center properties apply to both pre-paginated and reflowable content, and they only apply when the Reading System is creating Synthetic Spreads.

The rendition:page-spread-* properties take precedence over whatever value of the page-break-before property [CSS Snapshot] has been set for an XHTML Content Document.

note

The presence of rendition:page-spread-center does not change the viewport dimensions. In particular, it does not indicate that a viewport with the size of the whole spread has to be created. This is important so that the scale factor stays consistent between regular and center-spread pages.

When a reflowable spine item follows a pre-paginated one, the reflowable one should start on the next page (as defined by the page-progression-direction) when it lacks a rendition:page-spread-* property value. If the reflowable spine item has a rendition:page-spread-* specification, it must be honored (e.g., by inserting a blank page).

Similarly, when a pre-paginated spine item follows a reflowable one, the pre-paginated one should start on the next page (as defined by the page-progression-direction) when it lacks a rendition:page-spread-* property value. If the pre-paginated spine item has a rendition:page-spread-* specification, it must be honored (e.g., by inserting a blank page).

Although Authors often indicate to use a spread in certain device orientations, the content itself does not represent true spreads (i.e., two consecutive pages that have to be rendered side-by-side for readability, such as a two-page map). To indicate that two consecutive pages represent a true spread, Authors should use the rendition:page-spread-left and rendition:page-spread-right properties on the spine items for the two adjacent EPUB Content Documents, and omit the properties on spine items where one-up or two-up presentation is equally acceptable. When a Reading System encounters two spine items that represent a true spread, it should create the spread with no space between the adjacent pages.

Only one page-spread-* property can be declared on any given spine item.

note

The rendition:page-spread-left and rendition:page-spread-right properties are aliases for the page-spread-left and spread-right properties [Spine Vocab]. They allow the use of a single vocabulary for all fixed-layout properties. Authors can use either property set, but older Reading Systems might only recognize the unprefixed versions. The [Spine Vocab] is no longer being extended for package rendering metadata, so an unprefixed page-spread-center is not available.

  4.3.3.5.2 Examples

The following example demonstrates reflowable content with a two-page fixed-layout center plate that is intended to be rendered using synthetic spreads in any device orientation. Note that the author has left spread behavior for the other (reflowable) parts of the Rendition undefined, since the global value of rendition:spread is initialized to auto by default.

<spine page-progression-direction="ltr">
    …
    <itemref idref="center-plate-left"
             properties="rendition:spread-both rendition:page-spread-left"/>
    <itemref idref="center-plate-right"
             properties="rendition:spread-both rendition:page-spread-right"/>
    …
</spine>

The following example demonstrates fixed-layout content, where synthetic spreads, when used, have to be disabled for a center plate. Note that the rendition:spread declaration none expression is not needed on the center plate item, as the rendition:page-spread-center property already specifies semantics that dictates that synthetic spreads be disabled.

<metadata>
    <meta property="rendition:layout">pre-paginated</meta>
    <meta property="rendition:spread">auto</meta>
</metadata>
<spine>
    <itemref idref="center-plate" properties="rendition:page-spread-center"/>
</spine>

  5 EPUB Navigation Document

  5.1 Introduction

This section is informative

The EPUB Navigation Document is a mandatory component of an EPUB Package. It provides the Author with a mechanism to include a human- and machine-readable global navigation layer, thereby ensuring increased usability and accessibility for the user.

The EPUB Navigation Document is an adaptation of an XHTML Content Document and is, by definition, a valid XHTML Content Document instance. All Content and Reading System conformance requirements that apply to XHTML Content Documents also apply to the EPUB Navigation Document.

The navigation features of this adaptation are expressed through specializations of the [HTML] nav element. Each nav element in an EPUB Navigation Document represents a data island — an embedded source of specialized information within the general markup — from which Reading Systems can retrieve navigational information. Unlike typical XML data islands, however, the information within the nav element remains human readable as an [HTML] document.

To facilitate machine readability, the content model of nav elements in EPUB Navigation Documents is restricted relative to what is allowed in general XHTML Content Documents.

Note that the EPUB Navigation Document is not exclusively for machine processing. Formulating the document as an XHTML Content Document enables its reuse in the linear reading order, avoiding the creation of additional tables of contents (i.e., it can also be added to the spine). The visual display of components defined in the EPUB Navigation Document can be controlled using the hidden attribute, which has no effect outside of spine rendering (i.e., hiding a component from rendering in the spine does not hide it from Reading System presentation in a custom control).

When designing an EPUB Navigation Document for such dual use, however, be aware that machine extraction of the content can result in loss of formatting control. Scripting, styling and other HTML formatting can be stripped by a Reading System as it generates a custom control, such as the table of contents, from the markup. If such formatting and functionality is used, then the EPUB Navigation Document also needs to be included in the linear reading order. Another design consideration is to use progressive enhancement [Content Docs 3.1] techniques for scripting and styling of the navigation document, such that that the content will retain its integrity when rendered in a non-browser context.

  5.2 Content Conformance

A conformant EPUB Navigation Document must meet all of the following criteria:

Document Properties

  It must conform to the content conformance constraints for XHTML Content Documents defined in XHTML Content Documents — Content Conformance [Content Docs 3.1].

  It must conform to the content conformance constraints specific to EPUB Navigation Documents defined in EPUB Navigation Document Definition.

  As a conforming XHTML Content Document, it may be included in the spine.

  5.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing EPUB Navigation Documents:

  When requested by a user, it must provide access to the links and link labels in the nav elements of the EPUB Navigation Document in a fashion that allows the user to activate the links.

  When a link is activated, it must relocate the application's current reading position to the destination identified by that link.

  It must honor the above requirements irrespective of whether the EPUB Navigation Document is part of the spine.

  5.4 EPUB Navigation Document Definition

  5.4.1 The nav Element: Restrictions

When a nav element carries the epub:type attribute [Content Docs 3.1] in an EPUB Navigation Document, this specification restricts the content model of the element and its descendants as follows:

Content Model

nav

In this order:

HTML Heading content [0 or 1]

ol [exactly 1]

ol

In this order:

li [1 or more]

li

In this order:

(span or a) [exactly 1]

ol [conditionally required]

span and a

In any order:

HTML Phrasing content [1 or more]

Note that there are no restrictions on the attributes allowed on these elements.

Refer the definition below for additional requirements.

The content model of the nav element is interpreted as follows:

  The ol child of the nav element represents the primary level of content navigation.

  Each list item of the ordered list represents a heading, structure or other item of interest. A child a element describes the target that the link points to, while a span element serves as a heading for breaking down lists into distinct groups (for example, a large list of illustrations can be segmented into several lists, one for each chapter).

  The child a or span element must provide a non zero-length text label after concatenation of all child content and application of white space normalization rules. Although non-textual descendant elements may be rendered directly to users, text content included in title or alt attributes must be used when determining compliance with this requirement.

  If an a or span element contains instances of HTML embedded content that do not provide intrinsic text alternatives, the element must also include a title attribute with an alternate text rendering of the link label.

  The IRI reference provided in the href attribute of the a element must adhere to the following requirements:

  In the case of the toc nav, landmarks nav and page-list nav, it must resolve to an Top-level Content Document or fragment therein.

  For all other nav types, it may reference any resource, regardless of whether it is a Publication Resource, or whether it is Local or Remote Resource.

  An a element may be followed by an ol ordered list representing a subsidiary content level below that heading (e.g., all the subsection headings of a section).

  A span element must be followed by an ol ordered list; it cannot be used in "leaf" li elements.

  Regardless of whether an a or span element precedes it, every sublist must adhere to the content requirements defined in this section for constructing the primary navigation list.

IDPF specifications may introduce further restrictions on the content model defined above for nav elements in the EPUB Navigation Document.

The following example shows the basic patterns of a navigation element.

<nav epub:type="…">
  <h1>…</h1>
  <ol>
    <li>
      <a href="chap1.xhtml">A basic leaf node</a>
    </li>
    <li>
      <a href="chap2.xhtml">A linked heading</a>
      <ol>
        …
      </ol>
    <li>
      <span>An unlinked heading</span>
      <ol>
        …
      </ol>
    </li>
  </ol>
</nav>

In the context of this specification, the default display style of list items within nav elements must be equivalent to the list-style: none property [CSS Snapshot]. Reading Systems must not show list item numbering on these lists when presenting the Navigation Document outside of the spine, regardless of their support for CSS. Authors may specify alternative list styling using CSS for rendering of the document in the spine.

  5.4.2 The nav Element: Types

  5.4.2.1 Introduction

This section is informative

The nav elements defined in an EPUB Navigation Document are distinguished semantically by the value of their epub:type attribute [Content Docs 3.1].

This specification defines three types of navigation aid:

toc

Identifies the nav element that contains the table of contents. The toc nav is the only navigation aid that has to be included in the EPUB Navigation Document.

page-list

Identifies the nav element that contains a list of pages for a print or other statically-paginated source for the EPUB Publication.

landmarks

Identifies the nav element that contains a list of points of interest.

Additional navigation types can be included in the EPUB Navigation Document. See Other nav Elements for more information.

  5.4.2.2 The toc nav Element

The toc nav element defines the primary navigational hierarchy of the given Rendition. It conceptually corresponds to a table of contents in a printed work (i.e., it provides navigation to the major structural sections of the publication).

The references in the toc nav element must be ordered such that they reflect both:

the order of the referenced EPUB Content Documents in the spine;

the order of the targeted elements within their respective EPUB Content Documents.

The toc nav element must occur exactly once in an EPUB Navigation Document.

  5.4.2.3 The page-list nav Element

The page-list nav element provides navigation to positions in the content that correspond to the locations of page boundaries present in a print source being represented by the EPUB Publication.

The page-list nav element is optional in EPUB Navigation Documents and must not occur more than once.

The page references within the page-list nav must be ordered so that they match both the order of the targeted EPUB Content Documents in the spine and the order of each page within its respective EPUB Content Document.

The page-list nav element should contain only a single ol descendant (i.e., no nested sublists).

The destinations of the page-list references may be identified in their respective EPUB Content Documents using the pagebreak term [Structure Vocab].

  5.4.2.4 The landmarks nav Element

The landmarks nav element identifies fundamental structural components in the given Rendition in order to enable Reading Systems to provide the user efficient access to them.

The epub:type attribute [Content Docs 3.1] is required on a element descendants of the landmarks nav element. The structural semantics of each link target within the landmarks nav element is determined by the value of this attribute.

The following example shows a landmarks nav element with structural semantics drawn from the EPUB Structural Semantics Vocabulary.

<nav epub:type="landmarks">
    <h2>Guide</h2>
    <ol>
        <li><a epub:type="toc" href="#toc">Table of Contents</a></li>
        <li><a epub:type="loi" href="content.html#loi">List of Illustrations</a></li>
        <li><a epub:type="bodymatter" href="content.html#bodymatter">Start of Content</a></li>
    </ol>
</nav>

The landmarks nav must not include multiple entries with the same epub:type value that reference the same resource, or fragment thereof.

The landmarks nav element is optional in EPUB Navigation Documents and must not occur more than once.

  5.4.2.5 Other nav Elements

EPUB Navigation Documents may include one or more nav elements in addition to the toc, page-list and landmarks nav elements defined in the preceding sections. These additional nav elements should have an epub:type attribute to provide a machine-readable semantic, and must have a human-readable heading as their first child.

This specification imposes no restrictions on the semantics of any additional nav elements: they may be used to represent navigational semantics for any information domain, and they may contain link targets with homogeneous or heterogeneous semantics.

The following example shows a custom list of tables navigation element.

<nav aria-labelledby="lot">
    <h2 id="lot">List of tables</h2>
    <ol>
        <li><span>Tables in Chapter 1</span>
            <ol>
                <li><a href="chap1.xhtml#table-1.1">Table 1.1</a>
                </li>
                <li><a href="chap1.xhtml#table-1.2">Table 1.2</a></li>
            </ol>
        </li>
    	…
    </ol>
</nav>

  5.4.3 The hidden attribute

In some cases, Authors might wish to hide parts of the navigation data within the content flow (i.e., the Reading System's principal rendering of the spine contents). A typical example is the list of page breaks, which usually is not rendered as part of the content flow but is instead exposed to the user separately in a dedicated navigation user interface.

While the display property [CSS Snapshot] can be used to control the visual rendering of EPUB Navigation Documents in Reading Systems with Viewports, not all Reading Systems provide such an interface. To control rendering across all Reading Systems, authors must use the [HTML] hidden attribute to indicate which (if any) portions of the navigation data are excluded from rendering in the content flow. The hidden attribute has no effect on how navigation data is rendered outside of the content flow (such as in dedicated navigation user interfaces provided by Reading Systems).

The following example shows a partial page-list nav element. The presence of the hidden attribute on the root indicates that the entire list is excluded from rendering in the content flow.

<nav epub:type="page-list" hidden="">
    <h2>Pagebreaks of the print version, third edition</h2>
    <ol>
        <li><a href="frontmatter.xhtml#pi">I</a></li>
        <li><a href="frontmatter.xhtml#pii">II</a></li> … <li><a href="chap1.xhtml#p1">1</a></li>
        <li><a href="chap1.xhtml#p2">2</a></li> … </ol>
</nav>

The following example shows a partial toc nav element where the hidden attribute is used to limit content flow rendering to the two topmost hierarchical levels.

<nav epub:type="toc" id="toc">
  <h1>Table of contents</h1>
  <ol>
    <li>
      <a href="chap1.xhtml">Chapter 1</a>
      <ol>
        <li>
          <a href="chap1.xhtml#sec-1.1">Chapter 1.1</a>
          <ol hidden="">
            <li>
              <a href="chap1.xhtml#sec-1.1.1">Section 1.1.1</a>
            </li>
            <li>
              <a href="chap1.xhtml#sec-1.1.2">Section 1.1.2</a>
            </li>
          </ol>
         </li>
         <li>
           <a href="chap1.xhtml#sec-1.2">Chapter 1.2</a>
         </li>
       </ol>
     </li>
    <li>
      <a href="chap2.xhtml">Chapter 2</a>
    </li>
  </ol>
</nav>

  Appendix A. Obsolete Features

This appendix lists deprecated and superseded [EPUB 3.1] features of this specification.

  A.1 Deprecated Features

  A.1.1 The refines Attribute

Use of the meta refines attribute is deprecated. It is replaced by the duration, opf:alt-rep, opf:authority, opf:file-as, opf:role, opf:scheme and opf:term attributes.

For more information about this attribute, refer to its definition in [Publications 3.0.1].

  A.1.2 The rendition:spread portrait Value

Use of the portrait value with the rendition:spread property is deprecated.

The rendition:spread-portrait spine override is similarly deprecated.

For more information about this value, refer to its definition in [Publications 3.0.1].

  A.1.3 The rendition:viewport Property

Use of the rendition:viewport property is deprecated.

For more information about this property, refer to its definition in [Publications 3.0.1].

  A.2 Superseded Features

  A.2.1 NCX

The [OPF2] NCX file is superseded and marked for removal.

The NCX provides a measure of backwards compatibility for EPUB 2 Reading Systems, but has no function in EPUB 3. It is replaced by the EPUB Navigation Document. EPUB 3 Reading Systems must ignore the NCX.

  A.2.2 The toc Attribute

The spine toc attribute is superseded and marked for removal.

This attribute allows the [OPF2] NCX to be identified.

  Appendix B. Package Document Schema

The schema for Package Documents is available at http://www.idpf.org/epub/31/schema/package-31.nvdl.

Validation using this schema requires a processor that supports [NVDL], [RelaxNG], [ISO Schematron] and [XSD-DATATYPES].

note

The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.

  Appendix C. The 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 standards are maintained and defined by the International Digital Publishing Forum (IDPF).

MIME media type name:

application

MIME subtype name:

oebps-package+xml

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

Package Documents are UTF-8 or UTF-16 encoded XML.

Security considerations:

Package Documents contain well-formed XML conforming to the XML 1.0 specification.

Clearly, it is possible to author malicious files which, for example, contain malformed data. Most XML parsers protect themselves from such attacks by rigorously enforcing conformance.

All processors that read Package Documents should rigorously check the size and validity of data retrieved.

There is no current provision in the EPUB Publications 3.0 standard for encryption, signing, or authentication within the Package Document format.

Interoperability considerations:

None.

Published specification:

This media type registration is for the EPUB Package Document, as described by the EPUB Publications 3.0 specification located at http://www.idpf.org/epub/30/spec/epub30-publications.html.

The EPUB Publications 3.0 specification supersedes the Open Packaging Format 2.0.1 specification, which is located at http://www.idpf.org/epub/20/spec/OPF_2.0.1_draft.htm and which also uses the application/oepbs-package+xml media type.

Applications which use this media type:

This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive.

Adobe Digital Editions

Aldiko

Azardi

Apple iBooks

Barnes & Noble Nook

Calibre

Google Books

Ibis Reader

MobiPocket reader

Sony Reader

Stanza

Additional information:

Magic number(s):

none

File extension(s):

.opf

Macintosh File Type Code(s):

TEXT

Fragment Identifiers:

The IDPF maintains a registry of linking schemes at http://www.idpf.org/epub/linking/. Some of these schemes define custom fragment identifiers that resolve to application/oebps-package+xml documents.

Person & email address to contact for further information:

William McCoy, bmccoy@idpf.org

Intended usage:

COMMON

Author/Change controller:

International Digital Publishing Forum (http://www.idpf.org)

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Audrain, Luc (Hachette Livre)

Bailey, Brent (Elsevier)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bogan, Robert (Baker & Taylor)

Bowers, Micah (Bluefire Productions)

Burrows, Phil (VitalSource/Ingram Content Group)

Challman, Lauren (Kaplan Publishing)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Cleghorn, Tom (Cambridge University Press)

Comerford, Rachel (Macmillan)

Conboy, Garth (Google)

Corona, Juan (Evident Point)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Davis, Greg (Pearson)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Duga, Brady (Google)

Gardeur, Hadrien (Feedbooks)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haase, David (Penguin Random House)

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Herman, Ivan (W3C) W3C Liaison

Idan, Ori (Helicon Books)

Jay, Michael (Educational Systemics)

Johnson, Rick (VitalSource/Ingram Content Group)

Jung, Eunmi (KERIS (Korea Education and Research Information Service))

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

Khramov, Yuri (Readium)

Kleinfeld, Sanders (O'Reilly)

Koike, Toshiaki (Voyager Japan)

Labordrie, Cyril (EDRLab)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Levantovsky, Vladimir (Monotype)

Levenson, Yonah (Pearson)

Lin, Beatrice (KERIS (Korea Education and Research Information Service))

Lui, Edwina (Kaplan Publishing)

McCoy, Bill (IDPF)

Mietkiewicz, Elie (Gutenberg Technology)

Mitchell, Chris (Hachette Book Group)

Moua, Nou (Kaplan Publishing)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Owens, Evan (Cenveo Publisher Services)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally)

Rosenthol, Leonard (Adobe Systems)

Shyne, Mary (Penguin Random House)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Swick, Ralph (W3C)

Tallent, Joshua (eBookArchitects)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Wright, Ric (Readium Foundation)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Brady, Laura

Etemad, Elika J. W3C CSS WG Liaison

Garrish, Matt

Glazman, Daniel

Hawkins, Kevin

Kaplansky, Jean

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[Authority Registry] EPUB Subject Authorities Registry.

[BCP 47] Tags for Identifying Languages; Matching of Language Tags. A. Phillips, et al. September 2009.

[CSS Snapshot] CSS Snapshot .

[Content Docs 3.1] EPUB Content Documents 3.1 .

[Core Media Types] EPUB 3 Core Media Types.

[DCMES] Dublin Core Metadata Element Set, Version 1.1 .

[DCTERMS] DCMI Metadata Terms .

[DateTime] Date and Time Formats . Misha Wolf, et al. 15 September 1997.

[EPUB 3.1] EPUB 3.1 .

[EPUB Accessibility] EPUB Accessibility .

[HTML] HTML .

[ID Registry] EPUB Identifiers Registry.

[ISO Schematron] ISO/IEC 19757-3: Rule-based validation — Schematron . 2006-06-01.

[ISO8601] ISO 8601:2004 Data elements and interchange formats -- Information interchange -- Representation of dates and times . 2004-12-01.

[Link Vocab] EPUB Metadata Link Vocabulary .

[MARC Relators] MARC Code List for Relators.

[Manifest Vocab] EPUB Manifest Properties Vocabulary .

[Media Overlays 3.1] EPUB Media Overlays 3.1 .

[Media Queries] Media Queries .

[Meta Vocab] EPUB Meta Properties Vocabulary .

[NVDL] ISO/IEC 19757-4: NVDL (Namespace-based Validation Dispatching Language) . 2006-06-01.

[OCF 3.1] Open Container Format 3.1 .

[ONIX] ONIX for Books .

[OPF2] Open Packaging Format 2.0.1 .

[Publications 3.0.1] EPUB Publications 3.0.1 .

[RDFa 1.1] RDFa Core 1.1 - Second Edition . Syntax and processing rules for embedding RDF through attributes. Ben Adida, et al. 22 August 2013.

[RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (RFC 2046) . N. Freed, N. Borenstein. November 1996.

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . M Duerst, et al. January 2005.

[RFC4839] Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) (RFC 4839) . G Conboy, et al. April 2007.

[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG. Second Edition . 2008-12-15.

[Rendition Vocab] EPUB Package Rendering Vocabulary .

[Reserved Prefixes] EPUB Package Document Reserved Prefixes.

[Role Registry] EPUB Collection Roles Registry.

[SMIL] SMIL Version 3.0 . D. Bulterman, et al. 01 December 2008.

[Spine Vocab] EPUB Spine Properties Vocabulary .

[Structure Vocab] EPUB 3 Structural Semantics Vocabulary .

[UAAG 2.0] User Agent Accessibility Guidelines 2.0 . Ian Jacobs, et al. 17 December 2002.

[Unicode] The Unicode Consortium. The Unicode Standard..

[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . T. Bray, et al. 26 November 2008.

[XMLNS] Namespaces in XML (Third Edition) . T. Bray, et al. 8 December 2009.

[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition . Paul V. Biron et al. 28 October 2004.

Informative References

[EPUB3 Changes] EPUB 3.1 Differences from EPUB 3.0.1 .

[EPUB3 Overview] EPUB 3.1 Overview .

[JSON-LD] JSON-LD 1.0: A JSON-based Serialization for Linked Data. Manu Sporny, et al. 16 January 2014..

[Role Extensions] EPUB Collection Element Role Extensions.

[Types Registry] EPUB Publication Types Registry.

EPUB Content Documents 3.1

Recommended Specification 5 January 2017

This version

http://www.idpf.org/epub/31/spec/epub-contentdocs-20170105.html

Latest version

http://www.idpf.org/epub3/latest/contentdocs

Previous version

http://www.idpf.org/epub/31/spec/epub-contentdocs-20161130.html

Previous recommendation

http://www.idpf.org/epub/301/spec/epub-contentdocs-20140626.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Errata

Editors

Markus Gylling, International Digital Publishing Forum (IDPF)

William McCoy, International Digital Publishing Forum (IDPF)

Dave Cramer, Hachette Book Group

Elika J. Etemad, Invited Expert

Matt Garrish, Invited Expert

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Relationship to Other Specifications

1.2.1. Relationship to HTML

1.2.2. Relationship to SVG

1.2.3. Relationship to CSS

1.3. Terminology

1.4. Typographic Conventions

1.5. Conformance Statements

1.6. Namespace prefix mapping

2. XHTML Content Documents

2.1. Introduction

2.2. Content Conformance

2.3. Reading System Conformance

2.4. HTML Extensions

2.4.1. Semantic Inflection

2.4.1.1. Introduction

2.4.1.2. The epub:type Attribute

2.4.1.3. Vocabulary Association

2.4.1.4. Processing Requirements

2.4.2. Semantic Enrichment

2.4.2.1. Introduction

2.4.2.2. RDFa

2.4.2.3. Microdata

2.4.3. SSML Attributes

2.4.3.1. Introduction

2.4.3.2. The ssml:ph attribute

2.4.3.3. The ssml:alphabet attribute

2.4.4. Alternate Style Tags

2.4.5. Custom Attributes

2.5. HTML Deviations and Constraints

2.5.1. Embedded MathML

2.5.1.1. Introduction

2.5.1.2. Content Conformance

2.5.1.3. Reading System Conformance

2.5.1.4. Fallback Content

2.5.2. Embedded SVG

2.5.2.1. Embedded SVG and CSS

2.5.3. Unicode Restrictions

2.5.4. Discouraged Constructs

2.5.4.1. The rp Element

2.5.4.2. The embed Element

2.5.5. Foreign Resource Restrictions

3. SVG Content Documents

3.1. Introduction

3.2. Content Conformance

3.3. Restrictions on SVG

3.4. Reading System Conformance

3.5. Semantic Inflection

4. CSS Style Sheets

4.1. Introduction

4.2. Content Conformance

4.3. Reading System Conformance

4.4. Prefixed Properties

4.4.1. CSS Writing Modes

4.4.2. CSS Text Level 3

4.4.3. CSS Text Decoration Level 3

4.5. Reading System Overrides

5. Scripting

5.1. Scripting Contexts

5.2. Content Conformance

5.3. Reading System Conformance

5.4. Security Considerations

5.5. Event Model Considerations

6. Fixed Layouts

6.1. Introduction

6.2. Content Conformance

6.3. Reading System Conformance

6.4. Viewport Rendering

6.5. Initial Containing Block Dimensions

6.5.1. Expressing in HTML

6.5.2. Expressing in SVG

7. Pronunciation Lexicons

7.1. Introduction

7.2. EPUB Publication Conformance

7.3. Content Conformance

7.4. Reading System Conformance

A. JavaScript epubReadingSystem Object

A.1. Interface Definition

A.2. Description

A.3. Properties

A.4. Methods

A.4.1. hasFeature

A.4.1.1. Description

A.4.1.2. Features

B. Obsolete Features

B.1. Deprecated Features

B.1.1. The rendition:viewport Property for ICB Dimensions

B.1.2. The epubReadingSystem Object layoutStyle property

Acknowledgements and Contributors

References

  1 Overview

  1.1 Purpose and Scope

This section is informative

This specification, EPUB Content Documents 3.1, defines profiles of HTML, SVG, and CSS for use in the context of EPUB® Publications.

This specification is one of a family of specifications that compose [EPUB 3.1], an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3.1.

Refer to [EPUB3 Changes] for more information on the differences between this specification and its predecessor.

  1.2 Relationship to Other Specifications

This section is informative

  1.2.1 Relationship to HTML

This specification does not reference a specific version of W3C [HTML], but instead uses an undated reference that will always point to the latest recommendation. This approach ensures that EPUB will always keep pace with changes to the HTML standard. Authors and Reading System developers will need to keep track of changes to HTML, and ensure that their processes and systems are kept up to date.

caution

As HTML evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. IDPF anticipates 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.

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 W3C HTML document model that Authors can include in XHTML Content Documents.

This specification does not require EPUB Reading Systems to support scripting, HTML forms or the HTML DOM. Reading Systems conformant with this specification are only expected to be able to process a conforming EPUB Content Document. As support for scripting and HTML forms is not compulsory, a conformant Reading System might not be a fully-conformant HTML user agent.

  1.2.2 Relationship to SVG

This specification does not reference a specific version of [SVG], but instead uses an undated reference that will always point to the latest recommendation. 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 and systems are kept up to date.

caution

As SVG evolves, it is possible that features that were valid in previous versions could become obsolete or be removed. IDPF anticipates 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.

  1.2.3 Relationship to CSS

EPUB 3.1 supports CSS as defined by the CSS Working Group Snapshot [CSS Snapshot]. EPUB 3.1 also maintains some prefixed CSS properties, to ensure consistent support for global languages.

  1.3 Terminology

Terms with meanings specific to EPUB 3.1 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [EPUB 3.1].

Only the first instance of a term in a section is linked to its definition.

  1.4 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  1.5 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

  1.6 Namespace prefix mapping

For convenience, the following namespace prefixes [XMLNS] 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 mappings

prefix | URI
epub | http://www.idpf.org/2007/ops
pls | https://www.w3.org/2005/01/pronunciation-lexicon
ssml | https://www.w3.org/2001/10/synthesis

  2 XHTML Content Documents

  2.1 Introduction

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.

  2.2 Content Conformance

An XHTML Content Document must meet all of the following criteria:

Document Properties

  It must be an [HTML] document that conforms to the XHTML syntax.

  It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

  For all document constructs used that are defined by [HTML], it must conform to the conformance criteria defined for those constructs in that specification, unless explicitly overridden in HTML Deviations and Constraints.

  It may include extensions to the [HTML] grammar as defined in HTML Extensions, and must conform to all content conformance constraints defined therein.

note

The recommendation that EPUB Publications follow the accessibility requirements in [EPUB Accessibility] applies to XHTML Content Documents. See Accessibility [EPUB 3.1].

File Properties

  The XHTML Content Document filename should use the file extension .xhtml

  2.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing XHTML Content Documents:

  Unless explicitly defined by this specification as overridden, it must process XHTML Content Documents using semantics defined by the [HTML] specification and honor any applicable user agent conformance constraints expressed therein.

  It must meet all Reading System conformance criteria defined in HTML Extensions.

  It must recognize and adapt behaviorally to the constraints defined in HTML Deviations and Constraints.

  It must meet the Reading System conformance criteria defined in Scripted Content Documents — Reading System Conformance.

  It must support visual rendering of XHTML Content Documents as defined in CSS Style Sheets — Reading System Conformance.

  It should recognize embedded ARIA markup and support exposure of any given ARIA roles, states and properties to platform accessibility APIs [WAI-ARIA].

  2.4 HTML Extensions

This section defines EPUB 3.1 XHTML Content Document extensions to the underlying [HTML] document model.

note

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.1.

  2.4.1 Semantic Inflection

  2.4.1.1 Introduction

This section is informative

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 not intended for direct human consumption; it instead provides a controlled way for Reading Systems to learn more about the structure and content of a document, providing them the opportunity to enhance the reading experience for users.

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.

  2.4.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 [Packages 3.1] values, with restrictions as defined in Vocabulary Association.

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, as defined in Vocabulary Association.

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). Reading Systems must ignore inflected semantics that conflict with the carrying element.

As the [HTML] head element contains metadata for the document, structural semantics expressed on this element or any descendant of it have no meaning. Reading Systems must ignore such semantics.

Examples

The following example shows how a preamble could be marked up with the epub:type attribute on its containing [HTML] section element.

<html … xmlns:epub="http://www.idpf.org/2007/ops">
    …
    <section epub:type="preamble">
        …
    </section>
    …
</html>

The following example shows the epub:type attribute used to add glossary semantics on an [HTML] definition list.

<html … xmlns:epub="http://www.idpf.org/2007/ops">
    …
    <dl epub:type="glossary">
        …
    </dl>
    …
</html>

The following example shows the epub:type attribute used to add pagebreak semantics.

<html … xmlns:epub="http://www.idpf.org/2007/ops">
   …
  <p> … <span epub:type="pagebreak" title="234" id="p234"/> … </p>
   …
</html>

  2.4.1.3 Vocabulary Association

This specification adopts the vocabulary association mechanisms defined in Vocabulary Association Mechanisms [Packages 3.1], with the following modifications:

Default Vocabulary

The default vocabulary for Content Documents is defined to be the EPUB 3 Structural Semantics Vocabulary.

Reserved Prefixes

The reserved prefixes that Authors may use in the epub:type attribute without having to declare are defined in [Reserved Prefixes].

The prefix Attribute

The prefix attribute definition is unchanged, but the attribute is defined to be in the namespace http://www.idpf.org/2007/ops when used in EPUB Content Documents.

The prefix attribute is only valid on the [HTML] root html element.

  2.4.1.4 Processing Requirements

A Reading System must process the epub:type attribute as follows:

  It may associate behaviors with none, some or all of the terms defined in the default vocabulary.

  It may associate behaviors with terms from other vocabularies.

  It must ignore terms that it does not recognize.

When Reading System behavior associated with a given epub:type value conflicts with an element's native behavior, the behavior associated with the element must be given precedence.

  2.4.2 Semantic Enrichment

  2.4.2.1 Introduction

This section is informative

Unlike semantic inflection, which is about refining the structures within the markup, semantic enrichment enables the layering of meaning into the content in order to facilitate machine processing.

The [Microdata] and [RDFa 1.1] specifications both define sets of attributes that can be used in XHTML Content Documents to semantically enrich the content.

  2.4.2.2 RDFa

The use of [RDFa 1.1] attributes is allowed in XHTML Content Documents, but any usage must conform to the requirements defined in [HTML+RDFa11].

The [RDFa 1.1] specification defines changes to the [HTML] content model when RDFa attributes are used. This modified content model is valid in XHTML Content Documents.

EPUB Reading System support for the attribute processing model [RDFa 1.1] is optional.

  2.4.2.3 Microdata

The use of [Microdata] attributes is allowed in XHTML Content Documents, but any usage 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.

EPUB Reading System support for the attribute processing model is optional, as is the conversion to JSON [Microdata]. Furthermore, the DOM API [Microdata] is also optional, even if the attribute processing model is supported.

  2.4.3 SSML Attributes

  2.4.3.1 Introduction

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.

note

For more information on EPUB 3.1 features related to synthetic speech, refer to Text-to-speech [EPUB3 Overview].

  2.4.3.2 The 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.

Attribute Name

ph

Namespace

https://www.w3.org/2001/10/synthesis

Usage

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.

Value

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).

Reading Systems that support the SSML Attributes and PLS Documents must honor the defined precedence rules for these two constructs.

  2.4.3.3 The ssml:alphabet attribute

The ssml:alphabet attribute specifies which phonemic/phonetic pronunciation alphabet is used in the value of the ssml:ph attribute.

Attribute Name

alphabet

Namespace

https://www.w3.org/2001/10/synthesis

Usage

Global attribute. May be specified on any element.

Value

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.

note

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.

Reading Systems that support the SSML Attributes feature of this specification should support the IPA alphabet [IPA], as expressed by the value "ipa".

  2.4.4 Alternate Style Tags

In accordance with [Alt Style Tags] , the link element class attribute may include any of the following values: horizontal, vertical, day and night. These values inherit the semantics defined by that specification for their use.

Reading Systems should select and utilize such tagged style sets as appropriate, and as described in that specification.

  2.4.5 Custom Attributes

Reading Systems may introduce functionality not defined in this specification to enhance the rendering of EPUB Publications. To facilitate this experimentation, vendors may define custom attributes for use in XHTML Content Documents.

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 [XMLNS] 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.

note

To facilitate interoperability of custom attributes across Reading Systems, vendors are strongly encouraged to document any extensions they implement in [Attribute Extensions].

  2.5 HTML Deviations and Constraints

This section defines deviations from, and constraints on, the underlying [HTML] document model applicable to EPUB 3.1 XHTML Content Documents.

  2.5.1 Embedded MathML

  2.5.1.1 Introduction

This section is informative

XHTML Content Documents support embedded [MATHML] but limit its usage to a restricted subset of the full MathML markup language.

This subset is designed to ease the implementation burden on Reading Systems and to promote accessibility, while retaining compatibility with [HTML] user agents.

note

The mathml property [Manifest Vocab] of the manifest item element indicates that an XHTML Content Document contains embedded MathML.

  2.5.1.2 Content Conformance

Any occurrence of MathML markup in XHTML Content Documents must conform to the constraints expressed in the MathML specification [MATHML], with the following additional restrictions:

Presentation MathML

  The math element must contain only Presentation MathML, with the exception of the annotation-xml element as defined below.

Content MathML

  Content MathML may be included within MathML markup in XHTML Content Documents, and, when present, must occur within an annotation-xml child element of an 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.

Deprecated MathML

  Elements and attributes marked as deprecated in [MATHML] must not be included within MathML markup in XHTML Content Documents.

XHTML Content Document fragments

  XHTML Content Document fragments may be included within MathML markup in XHTML Content Documents, and, when present, must occur within an annotation-xml child element of an semantics element.

  When an XHTML Content Document fragment is included as per the above paragraph, the given annotation-xml element's encoding attribute must be set to application/xhtml+xml and its name attribute must be set to alternate-representation.

  Any included XHTML Content Document fragments must not themselves contain MathML markup.

  Any included XHTML Content Document fragments must conform to the content model in which the ancestor math element occurs, such that if the math element is replaced by the given XHTML Content Document fragment the document remains valid.

  2.5.1.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing MathML embedded in XHTML Content Documents:

  It must support processing of Presentation MathML using semantics defined by [MATHML].

  It may support processing of Content MathML found in an xml-annotation element using semantics defined by [MATHML].

  If it has a Viewport, it must support visual rendering of Presentation MathML.

  2.5.1.4 Fallback Content

As Reading System support for MathML rendering is inconsistent, Authors are encouraged to provide a fallback image using the altimg attribute on the math element. It is recommended that the dimension and alignment attributes (altimg-width, altimg-height and altimg-valign) be used in conjunction with the altimg attribute.

note

Fallback images have conform to the constraints for Publication Resources defined in EPUB Publication Conformance [EPUB 3.1].

  2.5.2 Embedded SVG

XHTML Content Documents support the embedding of SVG document fragments 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) [SVG].

The content conformance constraints for SVG embedded in XHTML Content Documents are the same as defined for SVG Content Documents in Restrictions on SVG.

Reading Systems must process SVG embedded in XHTML Content Documents as defined in SVG Content Documents — Reading System Conformance.

note

The svg property [Manifest Vocab] of the manifest item element indicates that an XHTML Content Document contains embedded SVG.

  2.5.2.1 Embedded SVG and CSS

For the purposes of styling SVG embedded in XHTML Content Documents by reference, Reading Systems must not apply CSS style rules of the containing document to the referenced SVG document.

For the purposes of styling SVG embedded in XHTML Content Documents by inclusion, Reading Systems must apply applicable CSS rules of the containing document to the included SVG elements.

note

SVG included by reference is processed as a separate document, and can include its own CSS style rules just like an SVG Content Document would. Note that this is consistent with situations where an [HTML] object element references an external [HTML] element.

  2.5.3 Unicode Restrictions

This section lists restrictions on the Unicode character repertoire.

Private Use Characters and Embedded Fonts

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 [CSS3 Fonts] that contains an appropriate glyph for that code point.

  2.5.4 Discouraged Constructs

This section is informative

  2.5.4.1 The rp Element

The [HTML] rp element is intended to provide a fallback for older version Reading Systems that do not recognize ruby markup (i.e., a parenthesis display around ruby markup). As EPUB 3.1 Reading Systems are ruby-aware, and can provide fallbacks, the use of rp elements is discouraged.

  2.5.4.2 The embed Element

Since the [HTML] embed element does not include intrinsic facilities to provide fallbacks for Reading Systems that do not support scripting, Authors are discouraged from using the element when the referenced resource includes scripting. The object element can be used instead, as it includes intrinsic fallback capabilities.

  2.5.5 Foreign Resource Restrictions

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.

Flow content may be embedded within the [HTML] 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 Core Media Type fallback.

The following [HTML] elements are exempt from Core Media Type requirements [EPUB 3.1]:

link — when its rel attribute has the value "pronunciation"

track

video — including any child source elements

Foreign Resources may be referenced from the above elements without the provision of a Core Media Type fallback.

note

Refer to manifest fallbacks [Packages 3.1] for the provision of fallbacks for elements without intrinsic mechanisms, such as the [HTML] iframe and img elements.

  3 SVG Content Documents

caution

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.

  3.1 Introduction

This section is informative

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., 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.

note

This section defines conformance requirements for SVG Content Documents. Refer to Embedded SVG for conformance requirements for SVG embedded in XHTML Content Documents.

  3.2 Content Conformance

An SVG Content Document must meet all of the following criteria:

Document Properties

   It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

  It may include references to Foreign Resources provided a fallback to a Core Media Type Resource is included.

  It must be an SVG document fragment [SVG], and conform to all content conformance constraints expressed in Restrictions on SVG.

note

The recommendation that EPUB Publications follow the accessibility requirements in [EPUB Accessibility] applies to SVG Content Documents. See Accessibility [EPUB 3.1].

File Properties

  The SVG Content Document filename should use the file extension .svg.

  3.3 Restrictions on SVG

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.

  Its content must be a valid document fragment that conforms to the XHTML Content Document model defined in XHTML Content Documents — Content Conformance.

  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.

  3.4 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing SVG Content Documents and SVG embedded in XHTML Content Documents:

  Unless explicitly defined by this specification as overridden, it must process SVG Content Documents using semantics defined by the [SVG] specification and honor any applicable user agent conformance constraints expressed therein.

  It must meet the Reading System conformance criteria defined in Scripted Content Documents — Reading System Conformance.

  If it has a Viewport, it must support the visual rendering of SVG using CSS as defined in Styling [SVG], and it should support all properties defined in Property Index [SVG]. In the case of embedded SVG, it must also conform to the constraints defined in Embedded SVG and CSS.

  It should support user selection and searching of text within SVG elements.

  It must recognize the value "http://www.idpf.org/2007/ops" of the requiredExtensions attribute as representing the occurrence of XHTML Content Document fragments (e.g., when the attribute is included on the foreignObject element or children of the switch element).

  3.5 Semantic Inflection

The syntax and semantics defined in XHTML Semantic Inflection are inherited for use of the epub:type and epub:prefix attributes in SVG Content Documents.

The use of the epub:prefix attribute is only valid on the root svg element in SVG Content Documents. Prefixes used in embedded SVG must be declared on the [HTML] root html element, as defined in XHTML Semantic Inflection.

  4 CSS Style Sheets

  4.1 Introduction

This section is informative

CSS has been an integral part of the Open Web Platform for nearly two decades — 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.

  4.2 Content Conformance

A conformant CSS style sheet must meet all of the following criteria:

  It may include any CSS properties, with the following exceptions:

  It must not use the direction property [CSS3 Writing Modes]. Use the [HTML] dir attribute to set the inline base direction.

  It must not use the unicode-bidi property [CSS3 Writing Modes]. Use [HTML] bdo elements and dir attributes to control bidirectionality.

  It may include the prefixed properties defined in CSS Style Sheets — Prefixed Properties.

  It must be encoded in UTF-8 or UTF-16 [Unicode].

note

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).

  4.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing CSS Style Sheets:

  It must support the official definition of CSS as described in the [CSS Snapshot].

  It should support all applicable modules in [CSS Snapshot] that have reached at least Candidate Recommendation status [W3C Process] (and are widely implemented).

  It must support all prefixed properties defined in CSS Style Sheets — Prefixed Properties.

  In addition to supporting CSS properties as defined above, its user agent style sheet should support the [HTML] suggested default rendering.

  It should respect Author CSS and user styles as defined in Reading System Overrides.

Reading System developers are encouraged to implement CSS support at the level of major browsers.

  4.4 Prefixed Properties

caution

Authors are strongly encouraged to use unprefixed properties, and Reading Systems to support current CSS specifications. The widely-used prefixed properties from [Content Docs 3.0.1] 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.

  4.4.1 CSS Writing Modes

The following table lists the -epub- prefixed properties for [CSS3 Writing Modes]. 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 [CSS3 Writing Modes-20151215].

CSS Writing Modes Properties

Property | Value | Prior EPUB Mapping | Mapping to [CSS3 Writing Modes-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>

  4.4.2 CSS Text Level 3

CSS Text Level 3 Properties

Property | Value | Mapping to [CSS3 Text-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

  4.4.3 CSS Text Decoration Level 3

CSS Text Decoration Level 3 Properties

Property | Value | Mapping to [CSS3 Text Decoration]
-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 [CSS3 Values and Units].

  4.5 Reading System Overrides

EPUB Reading Systems should apply Author style sheets as written to EPUB Content Documents. If a Reading System allows, users should be able to override Author style sheets as desired. EPUB Reading Systems should not override Author style sheets unless strictly necessary.

If a Reading System has to override an Author style sheet, it should do so in a way that preserves the Cascade: through a user agent style sheet, the getOverrideStyle method [DOM2 Style], or [HTML] style attributes.

Developers of Reading Systems are strongly encouraged to publicly document their user agent style sheets and how they interact with Author style sheets.

  5 Scripting

  5.1 Scripting Contexts

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.

This specification defines two contexts in which scripts may appear:

spine-level

An instance of the [HTML] script or [SVG] script element included in a Top-level Content Document.

container-constrained

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 Content Conformance and Reading System Conformance for some specific requirements that have to be adhered to (not all Reading Systems will provide the same scripting functionality).

Example

Consider the following example Package Document:

<package …>
    …
    <manifest>
        …
        <item id="chap01"
            href="scripted01.xhtml"
            media-type="application/xhtml+xml"
            properties="scripted"/>
        <item id="inset01"
            href="scripted02.xhtml"
            media-type="application/xhtml+xml"
            properties="scripted"/>
        <item id="slideshowjs"
            href="slideshow.js"
            media-type="text/javascript"/>
    </manifest>

    <spine …>
        <itemref idref="chap01"/>
        …
    </spine>
    …
</package>

and the following file scripted01.xhtml:

<html …>
    <head>
        …
        <script type="text/javascript">
            alert("Reading System name: " + navigator.epubReadingSystem.name);
        </script>
    </head>
    <body>
        …
        <iframe src="scripted02.xhtml" … />
        …
    </body>
</html>

and the following file scripted02.xhtml:

<html …>
    <head>
        …
        <script type="text/javascript" href="slideshow.js"></script>
    </head>
    <body>
        …
    </body>
</html>

From these examples, it is true that:

the code in the script element in the head in scripted01.xhtml is a spine-level script because the document is referenced from the spine;

the code in the script element in scripted02.xhtml is a container-constrained script because the HTML file it occurs in is included in scripted01.xhtml via the iframe element.

  5.2 Content Conformance

Container-constrained scripts

  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.

Spine-level scripts

  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 document content must retain its integrity, remaining consumable by the user without any information loss or other significant deterioration.

Accessibility

  EPUB Content Documents that include scripting should employ relevant [WAI-ARIA] accessibility techniques to ensure that the content remains consumable by all users.

Fallbacks

  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 [Packages 3.1] fallback.

  Authors must ensure that any output scripts generate meets Core Media Type requirements [EPUB 3.1].

note

The scripted property [Manifest Vocab] of the manifest item element indicates that an EPUB Content Document is a Scripted Content Document.

  5.3 Reading System Conformance

A Reading System that supports scripting must meet the following criteria:

  It should support container-constrained scripting in reflowable EPUB Content Documents.

  It should support spine-level scripting in fixed-layout documents.

  It should support spine-level scripting in reflowable EPUB Content Documents that use the "scrolled-doc" or "scrolled-continuous" presentation modes defined by the rendition:flow property [Packages 3.1]. Similarly, if it supports spine-level scripting in reflowable EPUB Content Documents, it must implement the "scrolled-doc" presentation mode and should implement the "scrolled-continuous" presentation mode.

  It may support scripting in other contexts, but this specification does not address such scripting. As a result, the use of scripting in these contexts might not be consistent across Reading Systems.

  It may render Scripted Content Documents as an interactive, scripted user agent according to [HTML].

  It must not allow a container-constrained script to modify the DOM of the parent Content Document or other contents in the EPUB Publication, and must not allow it to manipulate the size of its containing rectangle. (Note: Even if a script is not container-constrained, the Reading System may impose restrictions on modifications (see also the dom-manipulation feature).)

  It may place additional limitations on the capabilities provided to scripts during execution (e.g., limiting networking).

  It must implement the JavaScript navigator extension object epubReadingSystem defined in Appendix A, JavaScript epubReadingSystem Object. It also must support the dom-manipulation and layout-change features defined in Features in container-constrained scripting contexts.

A Reading System that does not support scripting must meet the following criteria:

  It must process fallbacks for scripted content as defined in Fallbacks for Scripted Content Documents.

note

Reading Systems might render Scripted Content Documents in a manner that disables other EPUB capabilities and/or provides a different rendering and user experience (e.g., by disabling pagination).

Authors choosing to restrict the usage of scripting to the container-constrained model will ensure a more consistent user experience between scripted and non-scripted content (e.g., consistent pagination behavior).

Authors are advised to use declarative techniques whenever practical to increase the interoperability, longevity and accessibility of their EPUB Publications, and avoid the inclusion of scripting whenever practical.

  5.4 Security Considerations

This section is informative

All EPUB Authors and EPUB Reading System developers have to be aware of the security issues that arise when scripted content is executed by a Reading System. As the underlying scripting model employed by Reading Systems and browsers is the same, the same kinds of issues encountered in Web contexts have to be taken into consideration.

Each Reading System has to establish if the scripts in a particular document are to be trusted or not. It is advised that all scripts be treated as untrusted (and potentially malicious), and that all vectors of attack be examined and protected against. In particular, the following need to be considered:

an attack against the runtime environment (e.g., stealing files from a user's hard drive);

an attack against the Reading System itself (e.g., stealing a list of a user's books or causing unexpected behavior);

an attack of one Content Document against another (e.g., stealing data that originated in a different document);

an attack of an unencrypted script against an encrypted portion of a document (e.g., an injected malicious script extracting protected content);

an attack against the local network (e.g., stealing data from a server behind a firewall).

The following recommendations are provided as a guide to handling untrusted scripts:

Reading Systems need to behave as if a unique domain were allocated to each Content Document, as browser-based security relies heavily on document URLs and domains. Adopting this approach will isolate documents from each other and from other Internet domains, thereby limiting access to external URLs, cookies, DOM storage, etc.

Reading Systems that enable scripting and network access also need to consider including methods to notify the user that network activity is occurring and/or that allow them to disable it.

note

In practice, Reading Systems might share domains across documents, but they still need to maintain isolation between documents.

If parts of a document are encrypted and parts are not, or if different encryption keys are used for different parts of the document, a unique per-document domain might not provide sufficient protection.

If a Reading System allows persistent data to be stored, that data needs to be treated as sensitive. Scripts might save persistent data through cookies and DOM storage, but Reading Systems might block such attempts. Reading Systems that do allow data to be stored have to ensure that it is not made available to other unrelated documents (e.g., ones that could have been spoofed). In particular, checking for a matching document identifier (or similar metadata) is not a valid method to control access to persistent data.

Reading Systems that allow local storage also need to provide methods for users to inspect, disable, or delete that data. The data needs to be destroyed if the corresponding EPUB Publication is deleted.

Note that compliance with these recommendations does not guarantee protection from the possible attacks listed above; developers have to examine each potential vulnerability within the context of their Reading System.

  5.5 Event Model Considerations

This section is informative

Reading Systems need to follow the DOM Event model as per [HTML] and pass UI events to the scripting environment before performing any default action associated with these events. Reading System implementers need to ensure that scripts cannot disable critical functionality (such as navigation) to constrain the extent to which a potentially malicious script could impact their Reading Systems. As a result, although the scripting environment needs to be able to cancel the default action of any event, some events either might not be passed through or might not be cancelable.

Authors need to take into account the wide variety of possible Reading System implementations when adding scripting functionality to their EPUB Publications (e.g., not all devices have physical keyboards, and in many cases a soft keyboard is activated only for text input elements). Consequently, relying on keyboard events alone is not advised; alternative ways to trigger a desired action always need to be provided.

  6 Fixed Layouts

  6.1 Introduction

This section is informative

This section defines rules for the expression and interpretation of dimensional properties of EPUB Content Documents marked as pre-paginated in the Package Document.

This specification does not define how the initial containing block [CSS Snapshot] will be placed within the Reading System Content Display Area.

note

Refer to Fixed-Layout Properties [Packages 3.1] for information on how to designate that a Rendition, or its individual spine items, are to be rendered in a pre-paginated manner (i.e., with fixed width and height dimensions).

  6.2 Content Conformance

A conformant Fixed-Layout Document must meet all of the following criteria:

It must specify its initial containing block [CSS Snapshot] as defined in Initial Containing Block Dimensions.

  6.3 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing Fixed-Layout Documents:

  It should allocate the full Content Display Area for the document, as defined in Viewport Rendering.

  It must use the dimensions expressed in the viewport meta tag to render XHTML Content Documents, as defined in Expressing the ICB in HTML.

  It must use the dimensions as defined in Expressing the ICB in SVG to render SVG Content Documents.

  6.4 Viewport Rendering

When rendering Fixed-Layout Documents, the default intent is that the Content Display Area should occupy as much of the available Viewport area as possible. Reading Systems should not inject additional content such as border, margins, headers or footers into the Viewport or the application area surrounding the Viewport.

note

The exposure of Reading System control widgets to the user is implementation-specific and not included in the above behavioral expectations.

  6.5 Initial Containing Block Dimensions

  6.5.1 Expressing in HTML

For XHTML Content Documents, the initial containing block [CSS Snapshot] dimensions must be expressed in a viewport meta tag using the syntax defined in [CSS Device Adaptation]. In this version of this specification, only the width and height expressions must be recognized by Reading Systems.

The following example shows a viewport meta tag.

<head>
   …
   <meta name="viewport" content="width=1200, height=600"/>
   …
</head>

Reading Systems must clip XHTML content to the initial containing block (ICB) dimensions declared in the viewport meta tag — content positioned outside of the initial containing block will not be visible. When the ICB aspect ratio does not match the aspect ratio of the Reading System Content Display Area, Reading Systems may position the ICB inside the area to accommodate the user interface; in other words, added letter-boxing space may appear on either side (or both) of the content.

  6.5.2 Expressing in SVG

For SVG Content Documents, the root svg element must include one or both of:

the viewBox attribute;

the height and width (and optional x and y) attributes.

It is recommended to use only the viewBox attribute to ensure proper rescaling of the SVG Content Document, as needed.

The following example shows a viewBox attribute declaration for an SVG Content Document with an aspect ratio of 844 pixels wide by 1200 pixels high.

<svg xmlns="http://www.w3.org/2000/svg"
     version="1.1"
     viewBox="0 0 844 1200">
   …
</svg>

If only the [SVG] viewBox attribute is present, the coordinate system it defines is mapped to the Viewport, keeping the aspect ratio, thereby establishing the initial containing block (ICB) in pixels [CSS Snapshot]. The result of this mapping is typically the bounds of the Viewport.

If only the x, y, height and width attributes are present, they should be defined in pixel values (establishing the ICB). Note that if the pixel values defined by x, y, height and width attributes exceed the Viewport's pixel values, the graphic will be clipped on the Viewport boundaries (i.e., the graphics will not be rescaled).

If the coordinate system is defined by the viewBox and the width/height values, the coordinate system defined by the viewBox is mapped on the boundaries as described in the previous item.

note

See [SVG] for more details on the interplay between viewBox and the width/height values.

  7 Pronunciation Lexicons

  7.1 Introduction

This section is informative

The W3C Pronunciation Lexicon Specification [PLS] defines syntax and semantics for XML-based pronunciation lexicons to be used by Automatic Speech Recognition and Text-to-Speech (TTS) engines.

The following sections define conformance criteria for PLS documents when included in EPUB Publications, and rules for associating PLS Documents with XHTML Content Documents.

note

For more information on EPUB 3.1 features related to synthetic speech, refer to Text-to-speech [EPUB3 Overview].

  7.2 EPUB Publication Conformance

A conformant Rendition of an EPUB Publication must meet all of the following criteria for inclusion of PLS Documents:

  PLS Documents may be associated with XHTML Content Documents. Each XHTML Content Document may contain zero or more PLS Document associations.

  PLS Documents must be associated with the XHTML Content Document to which they apply using the [HTML] link element with its rel attribute set to "pronunciation" and its type attribute set to the PLS media type "application/pls+xml".

  The link element hreflang attribute should be specified on each PLS link, and its value must match the language for which the pronunciation lexicon is relevant [PLS] when specified.

  PLS Documents must meet the content conformance criteria defined in PLS Documents — Content Conformance.

  PLS Documents must be represented and located as defined in EPUB Package — Conformance [Packages 3.1].

Examples

The following example shows two PLS Documents (one for Chinese and one for Mongolian) associated with an XHTML Content Document.

<html … >
    <head>
        …
        <link rel="pronunciation" type="application/pls+xml" hreflang="zh" href="../speech/zh.pls"/>
        <link rel="pronunciation" type="application/pls+xml" hreflang="mn" href="../speech/mn.pls"/>
    </head>
    …
</html>

  7.3 Content Conformance

A PLS Document must meet all of the following criteria:

Document Properties

   It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

  It must be valid to the RELAX NG schema for PLS documents available at the URI https://www.w3.org/TR/2008/REC-pronunciation-lexicon-20081014/ [PLS].

File Properties

  The PLS Document filename should use the file extension .pls.

  7.4 Reading System Conformance

A conformant EPUB Reading System must meet all of the following criteria for processing PLS Documents:

  Reading Systems with Text-to-Speech (TTS) capabilities should support PLS.

  Reading Systems that support PLS must process PLS documents as defined in [PLS].

  Reading Systems that support PLS must apply the supplied pronunciation instructions to all text nodes in the current XHTML Content Document whose language [HTML] matches the language for which the pronunciation lexicon is relevant [PLS]. The algorithm for matching language tags is defined in BCP47.

   When a pronunciation rule is specified more than once for a given string target in a given language, the last occurrence of the rule takes precedence, in such a way that any previously-defined pronunciation rule gets overridden.

  Reading Systems that support PLS and the SSML Attributes must let any pronunciation instructions provided via the ssml:ph attribute take precedence in cases where a pls:grapheme matches a text node of an element that carries the ssml:ph attribute.

  Appendix A. JavaScript epubReadingSystem Object

  A.1 Interface Definition

This specification extends the [HTML] Navigator object as follows.

[Exposed=(Window)]
interface EpubReadingSystem {
    [Unforgeable] readonly attribute DOMString name;
    [Unforgeable] readonly attribute DOMString version;
    [Unforgeable] boolean hasFeature(DOMString feature, optional DOMString version);
};

partial interface Navigator {
    [Unforgeable, SameObject] readonly attribute EpubReadingSystem epubReadingSystem;
};

[WEB IDL] notation.

note

This specification does not define an epubReadingSystem property extension for the WorkerNavigator object [Web Workers]. Reading Systems therefore do not have to expose the epubReadingSystem object in the scripting context of Workers, and Authors cannot rely on its presence.

  A.2 Description

The epubReadingSystem object provides an interface through which a Scripted Content Document can query information about a user's Reading System.

The object exposes properties of the Reading System (its name and version), and provides the hasFeature method which can be invoked to determine the features it supports.

Example JavaScript function that displays the name of the current Reading System.

alert("Reading System name: " + navigator.epubReadingSystem.name);

Reading Systems must expose the epubReadingSystem object on the navigator object of all loaded Scripted Content Documents, including any nested container-constrained scripting contexts. Reading Systems must ensure that the epubReadingSystem object is available no later than when the DOMContentLoaded event is triggered [HTML].

note

Reading systems implementations might create cloned instances of the epubReadingSystem object in Scripted Content Documents for technical feasibility reasons. In such cases, the Reading System has to ensure that the object’s state — as reflected by the values of its properties and methods — is consistently maintained across all copied instances.

  A.3 Properties

The following properties must be made available for retrieving information about the Reading System.

Required epubReadingSystem properties

Name | Description
name | Returns a String value representing the name of the Reading System (e.g., "iBooks", "Kindle").
version | Returns a String value representing the version of the Reading System (e.g., "1.0", "2.1.1").

  A.4 Methods

  A.4.1 hasFeature

  A.4.1.1 Description

The hasFeature method returns a boolean value indicating whether any version of the specified feature is supported, or undefined if the specified feature is not recognized.

The optional version parameter is included for querying custom features that could change in incompatible ways over time. The return value indicates support only for the specified version of the feature.

Authors should not include the version parameter when querying features defined in this specification — these features are considered versionless. If a Reading System supports a feature defined in this specification, it must ignore any supplied version parameter and return a true value.

Example JavaScript function that displays whether the current Reading System supports scripted manipulation of the DOM.

var feature = "dom-manipulation";

var conformTest = navigator.epubReadingSystem.hasFeature(feature);

alert("Feature " + feature + " supported?: " + conformTest);

  A.4.1.2 Features

The following table lists the set of features that Reading Systems that support the epubReadingSystem object must recognize (i.e., provide a return value for). Support for these features is optional.

Required epubReadingSystem features

Name | Description
dom-manipulation | Scripts may make structural changes to the document’s DOM (applies to spine-level scripting only).
layout-changes | Scripts may modify attributes and CSS styles that affect content layout (applies to spine-level scripting only).
touch-events | The device supports touch events and the Reading System passes touch events to the content.
mouse-events | The device supports mouse events and the Reading System passes mouse events to the content.
keyboard-events | The device supports keyboard events and the Reading System passes keyboard events to the content.
spine-scripting | Indicates whether the Reading System supports spine-level scripting (e.g., so a container-constrained script can determine whether any actions that depend on scripting support in a Top-level Content Document have any chance of success before attempting them).

Additional features may be added by Reading System developers, but future versions of this specification might append to this list in ways that could conflict or be incompatible with any such custom additions.

  Appendix B. Obsolete Features

This appendix lists deprecated and superseded [EPUB 3.1] features of this specification.

  B.1 Deprecated Features

  B.1.1 The rendition:viewport Property for ICB Dimensions

Use of the rendition:viewport property [Packages 3.1] is now deprecated. As this feature has always been optional, Reading System support is not changed. Developers are advised that the feature will be removed in a future version.

  B.1.2 The epubReadingSystem Object layoutStyle property

Use of the layoutStyle property is deprecated.

For more information about this property, refer to its definition in [Content Docs 3.0.1].

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Audrain, Luc (Hachette Livre)

Bailey, Brent (Elsevier)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bogan, Robert (Baker & Taylor)

Bowers, Micah (Bluefire Productions)

Burrows, Phil (VitalSource/Ingram Content Group)

Challman, Lauren (Kaplan Publishing)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Cleghorn, Tom (Cambridge University Press)

Comerford, Rachel (Macmillan)

Conboy, Garth (Google)

Corona, Juan (Evident Point)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Davis, Greg (Pearson)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Duga, Brady (Google)

Gardeur, Hadrien (Feedbooks)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haase, David (Penguin Random House)

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Herman, Ivan (W3C) W3C Liaison

Idan, Ori (Helicon Books)

Jay, Michael (Educational Systemics)

Johnson, Rick (VitalSource/Ingram Content Group)

Jung, Eunmi (KERIS (Korea Education and Research Information Service))

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

Khramov, Yuri (Readium)

Kleinfeld, Sanders (O'Reilly)

Koike, Toshiaki (Voyager Japan)

Labordrie, Cyril (EDRLab)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Levantovsky, Vladimir (Monotype)

Levenson, Yonah (Pearson)

Lin, Beatrice (KERIS (Korea Education and Research Information Service))

Lui, Edwina (Kaplan Publishing)

McCoy, Bill (IDPF)

Mietkiewicz, Elie (Gutenberg Technology)

Mitchell, Chris (Hachette Book Group)

Moua, Nou (Kaplan Publishing)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Owens, Evan (Cenveo Publisher Services)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally)

Rosenthol, Leonard (Adobe Systems)

Shyne, Mary (Penguin Random House)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Swick, Ralph (W3C)

Tallent, Joshua (eBookArchitects)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Wright, Ric (Readium Foundation)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Brady, Laura

Etemad, Elika J. W3C CSS WG Liaison

Garrish, Matt

Glazman, Daniel

Hawkins, Kevin

Kaplansky, Jean

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[Alt Style Tags] Alternate Style Tags . Elika J. Etemad.

[BCP 47] Tags for Identifying Languages; Matching of Language Tags. A. Phillips, et al. September 2009.

[CSS Snapshot] CSS Snapshot .

[CSS3 Fonts] CSS Fonts Module Level 3 . John Daggett.

[CSS3 Text Decoration] CSS Text Decoration Module Level 3 . Elika J. Etemad, et al.

[CSS3 Text-20160119] CSS Text Level 3 (20160119) . Elika J. Etemad, et al.

[CSS3 Values and Units] CSS Values and Units Module Level 3 . Tab Atkins et al.

[CSS3 Writing Modes] CSS Writing Modes Module Level 3 . Elika J. Etemad, et al.

[CSS3 Writing Modes-20151215] CSS Writing Modes Module Level 3 (20151215) . Elika J. Etemad, et al. 15 December 2015.

[Content Docs 3.0.1] EPUB Content Documents 3.0.1 .

[DOM2 Style] Document Object Model (DOM) Level 2 Style Specification, Version 1.0. Chris Wilson, et al. 13 November 2000.

[EPUB 3.1] EPUB 3.1 .

[EPUB Accessibility] EPUB Accessibility .

[HTML] HTML .

[HTML+RDFa11] HTML+RDFa 1.1 . Support for RDFa in HTML4 and HTML5. Manu Sporny. 22 August 2013.

[MATHML] Mathematical Markup Language (MathML) Version 3.0 . David Carlisle, et al. 21 October 2010.

[Manifest Vocab] EPUB Manifest Properties Vocabulary .

[Microdata] HTML Microdata (20121025) . Ian Hickson. 25 October 2012.

[PLS] Pronunciation Lexicon Specification 1.0 (PLS) . Paolo Baggia. 14 October 2008.

[Packages 3.1] EPUB Packages 3.1 .

[RDFa 1.1] RDFa Core 1.1 - Second Edition . Syntax and processing rules for embedding RDF through attributes. Ben Adida, et al. 22 August 2013.

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

[Reserved Prefixes] EPUB Content Documents Reserved Prefixes.

[SSML] Speech Synthesis Markup Language (SSML) Version 1.1 . Daniel C. Burnett, et al. 7 September 2010.

[SVG] Scalable Vector Graphics (SVG) .

[Structure Vocab] EPUB 3 Structural Semantics Vocabulary .

[Unicode] The Unicode Consortium. The Unicode Standard..

[W3C Process] World Wide Web Consortium Process Document . Charles McCathie-Nevile. 1 September 2015.

[WAI-ARIA] Accessible Rich Internet Applications (WAI-ARIA) 1.0 . James Craig, et al. 20 March 2014.

[WEB IDL] WebIDL Level 1 (20160308).

[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . T. Bray, et al. 26 November 2008.

[XMLNS] Namespaces in XML (Third Edition) . T. Bray, et al. 8 December 2009.

Informative References

[Attribute Extensions] EPUB Custom Attribute Extensions for Content Documents.

[CSS Device Adaptation] CSS Device Adaptation Module Level 1.

[EPUB3 Changes] EPUB 3.1 Differences from EPUB 3.0.1 .

[EPUB3 Overview] EPUB 3.1 Overview .

[IPA] IPA Chart . International Phonetic Association. 2005.

[Web Workers] Web Workers.

EPUB Media Overlays 3.1

Recommended Specification 5 January 2017

This version

http://www.idpf.org/epub/31/spec/epub-mediaoverlays-20170105.html

Latest version

http://www.idpf.org/epub3/latest/mediaoverlays

Previous version

http://www.idpf.org/epub/31/spec/epub-mediaoverlays-20161130.html

Previous recommendation

http://www.idpf.org/epub/301/spec/epub-mediaoverlays-20140626.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Errata

Editors

Marisa DeMeglio, DAISY Consortium

Daniel Weck, DAISY Consortium

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Relationship to Other Specifications

1.2.1. Relationship to SMIL

1.3. Terminology

1.4. Typographic Conventions

1.5. Conformance Statements

1.6. Namespace prefix mappings

2. Media Overlay Document Definition

2.1. Introduction

2.2. Content Conformance

2.3. Reading System Conformance

2.4. Media Overlay Document Definition

2.4.1. The smil Element

2.4.2. The head Element

2.4.3. The metadata Element

2.4.4. The body Element

2.4.5. The seq Element

2.4.6. The par Element

2.4.7. The text Element

2.4.8. The audio Element

3. Creating Media Overlays

3.1. Introduction

3.2. Relationship to the EPUB Content Document

3.2.1. Structure

3.2.2. Granularity

3.2.3. Embedded Media

3.2.4. Text-to-Speech

3.3. Semantic Inflection

3.4. Associating Style Information

3.5. Packaging

3.5.1. Including Media Overlays

3.5.2. Package Metadata

4. Playback Behaviors

4.1. Loading the Media Overlay

4.2. Basic Playback

4.2.1. Timing and Synchronization

4.2.2. Rendering Audio

4.2.3. Rendering EPUB Content Document Elements

4.3. Interacting with the EPUB Content Document

4.3.1. Navigation

4.3.2. Embedded Audio and Video

4.3.3. Text-to-Speech

4.4. Skippability and Escapability

4.4.1. Skippability

4.4.2. Escapability

5. EPUB Navigation Document

A. Media Overlays Schema

B. Examples of Clock Values

Acknowledgements and Contributors

References

  1 Overview

  1.1 Purpose and Scope

This section is informative

This specification, EPUB Media Overlays 3.1, defines a usage of [SMIL] (Synchronized Multimedia Integration Language), the Package Document, CSS Style Sheets, and EPUB® Content Documents for representation of audio synchronized with the EPUB Content Document.

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).

This specification is one of a family of specifications that compose [EPUB 3.1], an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3.1.

Refer to [EPUB3 Changes] for more information on the differences between this specification and its predecessor.

  1.2 Relationship to Other Specifications

This section is informative

  1.2.1 Relationship to SMIL

This specification relies on a subset of [SMIL], from which the EPUB Media Overlays elements and attributes defined in Media Overlay Document Definition are derived.

  1.3 Terminology

Terms with meanings specific to EPUB 3.1 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [EPUB 3.1].

Only the first instance of a term in a section is linked to its definition.

  1.4 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  1.5 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

  1.6 Namespace prefix mappings

For convenience, the following namespace prefixes [XMLNS] are used in this specification without explicitly being declared. To use any of these prefixes, a declaration is required.

Prefix mappings

prefix | URI
epub | http://www.idpf.org/2007/ops

  2 Media Overlay Document Definition

  2.1 Introduction

This section is informative

Synchronized audio narration is found in mainstream ebooks, educational tools and ebooks formatted for persons with print disabilities. In EPUB 3.1, 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 [SMIL], a W3C recommendation for representing synchronized multimedia information in XML.

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.

  2.2 Content Conformance

A Media Overlay Document must meet all of the following criteria:

Document Properties

   It must meet the conformance constraints for XML documents defined in XML Conformance [EPUB 3.1].

  It must be valid to the Media Overlays schema as defined in Appendix A, Media Overlays Schema and conform to all content conformance constraints expressed in Media Overlay Document Definition.

  It must be authored to reflect the structure of the EPUB Content Document with which it is associated, as stated in Structure.

  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.

  Authors should avoid using scripts to control audio and video embedded in the EPUB Content Document, as stated in Embedded Media.

  It should use semantic markup where appropriate, as described in Semantic Inflection.

  It must be packaged with the EPUB Publication as shown in Packaging.

File Properties

  The Media Overlay Document filename should use the file extension .smil.

  2.3 Reading System Conformance

EPUB Reading System support for Media Overlays is optional. A Reading System that supports Media Overlays must meet the following criteria:

  It must process the Media Overlay Document in conformance with all Reading System conformance constraints expressed in Media Overlay Document Definition.

  It must support XHTML Content Documents, and it may support SVG Content Documents.

  It must render Media Overlay elements as described in Basic Playback.

  It must allow user navigation while a Media Overlay is being played, as discussed in Navigation.

  It must adhere to rules regarding referenced audio and video embedded in the EPUB Content Document, as stated in Embedded Audio and Video.

  Text-to-Speech-capable Reading Systems should conform to Reading System Text-to-Speech Conformance Requirements [EPUB 3.1].

  It should offer the skippability and escapability features described in Skippability and Escapability.

A Reading System that does not support Media Overlays must meet the following criteria:

  It must ignore both the media-overlay attribute on Manifest item elements and the manifest item elements where the media-type attribute value equals application/smil+xml.

  2.4 Media Overlay Document Definition

All elements [XML] defined in this section are in the https://www.w3.org/ns/SMIL namespace [XMLNS] unless otherwise specified.

  2.4.1 The smil Element

The smil element is the root element of all Media Overlay Documents.

Element Name

smil

Usage

The smil element is the root element of the Media Overlay Document.

Attributes

version [required]

Specifies the version number of the [SMIL] 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 Semantic Inflection for more information.

Content Model

In this order:

head [0 or 1]

body [exactly 1]

  2.4.2 The head Element

The head element is the container for metadata in the Media Overlay Document.

Element Name

head

Usage

The head element is the optional first child of the smil element.

Attributes

None

Content Model

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.

  2.4.3 The 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.

Element Name

metadata

Usage

As a child of the head element.

Attributes

None

Content Model

[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.

  2.4.4 The 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.

Element Name

body

Usage

The body element is the required second child of the smil element.

Attributes

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 [Packages 3.1] types. Refer to 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].

Content Model

In any order:

seq [0 or more]

par [0 or more]

At least one par or seq is required.

  2.4.5 The seq Element

The seq element contains media objects which are to be rendered sequentially.

Element Name

seq

Usage

One or more seq elements may occur as children of the body element and of the seq element.

Attributes

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 [Packages 3.1] types. Refer to 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 Structure for more information.

Content Model

In any order:

seq [0 or more]

par [0 or more]

At least one par or seq is required.

  2.4.6 The par Element

The par element contains media objects which are to be rendered in parallel.

Element Name

par

Usage

One or more par elements may occur as children of the body and seq elements.

Attributes

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 [Packages 3.1] types. Refer to Semantic Inflection for more information.

id [optional]

The ID [XML] of the element, which must be unique within the document scope.

Content Model

In any order:

text [exactly 1]

audio [0 or 1]

The audio element is optional only if its sibling text element refers to audio or video media (see Embedded Media), or to textual content intended for rendering via Text-to-Speech (TTS).

  2.4.7 The 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 Embedded Media).

Element Name

text

Usage

As a required child of the par element.

Attributes

src [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].

id [optional]

The ID [XML] of the element, which must be unique within the document scope.

Content Model

Empty

  2.4.8 The audio Element

The audio element represents a clip of audio media.

Element Name

audio

Usage

A required child of the par element unless its sibling text element refers to audio or video media, in which case it is optional (see Embedded Media).

Attributes

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 Types [EPUB 3.1] 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 [SMIL] clock value.

See Appendix B, Examples of Clock Values.

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 [SMIL] clock value.

See Appendix B, Examples of Clock Values.

The chronological offset of the terminating position must be after the starting offset specified in the clipBegin attribute.

Content Model

Empty

  3 Creating Media Overlays

  3.1 Introduction

This section is informative

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 SMIL 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 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.

The following example shows the Media Overlays markup for a single phrase or sentence.

<par>
    <text src="chapter1.xhtml#sentence1"/>
    <audio src="chapter1_audio.mp3" clipBegin="23s" clipEnd="30s"/>
</par>

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.

The following example shows a basic Media Overlay Document containing a sequence of phrases. The body element acts as the main sequence for the whole document.

<smil xmlns="http://www.w3.org/ns/SMIL"
      version="3.0">
    <body>
        <par id="par1">
            <text src="chapter1.xhtml#sentence1"/>
            <audio src="chapter1_audio.mp3" clipBegin="0s" clipEnd="10s"/>
        </par>
        <par id="par2">
            <text src="chapter1.xhtml#sentence2"/>
            <audio src="chapter1_audio.mp3" clipBegin="10s" clipEnd="20s"/>
        </par>
        <par id="par3">
            <text src="chapter1.xhtml#sentence3"/>
            <audio src="chapter1_audio.mp3" clipBegin="20s" clipEnd="30s"/>
        </par>
    </body>
</smil>

par elements can also be added to seq elements to define more complex structures such as parts and chapters (see Structure).

  3.2 Relationship to the EPUB Content Document

note

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.

  3.2.1 Structure

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#s01" 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>

note

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 Skippability and Escapability), or customizing the reading mode to suit structures such as tables.

The following example shows the EPUB Content Document that corresponds to the previous Media Overlay example.

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:epub="http://www.idpf.org/2007/ops"
      xml:lang="en"
      lang="en">
    <head>
        <title>Media Overlays Example of EPUB Content Document</title>
    </head>
    <body id="sec1">
        <section id="sectionstart" epub:type="chapter">
            <h1 id="section1_title">The Section Title</h1>
            <p id="text1">The first phrase of the main text body.</p>
            <p id="text2">The second phrase of the main text body.</p>
            <figure id="figure">
                <img id="photo"
                     src="photo.png"
                     alt="a photograph for which there is a caption" />
                <figcaption id="caption">The photo caption</figcaption>
            </figure>
            <p id="text3">The third phrase of the main text body.</p>
            <p id="text4">The fourth phrase of the main text body.</p>
        </section>
    </body>
</html>

  3.2.2 Granularity

This section is informative

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.

  3.2.3 Embedded Media

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.

  3.2.4 Text-to-Speech

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 audio sibling 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.

  3.3 Semantic Inflection

In order to express semantic inflections, the epub:type attribute [Content Docs 3.1] 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 Semantic Inflection [Content Docs 3.1] 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 Note.

The following example shows the semantic markup for a Media Overlay containing a figure.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>
        <seq id="id1" epub:textref="chapter1.xhtml#figure" epub:type="figure">
            <par id="id2">
                <text src="chapter1.xhtml#figuretitle"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:15.000" clipEnd="0:24:18.123"/>
            </par>
            <par id="id3">
                <text src="chapter1.xhtml#figurecaption"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:18.123" clipEnd="0:24:38.530"/>
            </par>
            <par id="id4">
                <text src="chapter1.xhtml#figuretext1"/>
                <audio src="chapter1_audio.mp3" clipBegin="0:24:38.530" clipEnd="0:25:00.515"/>
            </par>
        </seq>
    </body>
</smil>

This specification adopts the vocabulary association mechanisms defined in Vocabulary Association [Content Docs 3.1] 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 on the root smil element.

  3.4 Associating Style Information

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 [Overlays Vocab]. The class names are then discoverable by Reading Systems.

This example demonstrates how Authors can associate style information with the currently-playing EPUB Content Document.

note

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.

The author-defined CSS class names, declared using the metadata properties active-class and playback-active-class [Overlays Vocab] in the Package Document:

<meta property="media:active-class">-epub-media-overlay-active</meta>
<meta property="media:playback-active-class">-epub-media-overlay-playing</meta>

The CSS Style Sheet containing the author-defined class names:

/* emphasize the active element */
.-epub-media-overlay-active {
    background-color: yellow;
    color: black !important;
}

/* fade out the inactive text */
html.-epub-media-overlay-playing * {
    color: gray;
}

The relevant EPUB Content Document excerpt:

<html>
    …
    <span id="txt1">This is the first phrase.</span>
    <span id="txt2">This is the second phrase.</span>
    <span id="txt3">This is the third phrase.</span>
    …
</html>

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.

  3.5 Packaging

  3.5.1 Including Media Overlays

Manifest item elements [Packages 3.1] that reference EPUB Content Documents may specify a Media Overlay via the media-overlay attribute. The attribute must reference the ID [XML] of the manifest item for the corresponding Media Overlay Document.

Manifest items for Media Overlay Documents must have the media type application/smil+xml.

The duration of an EPUB Content Document must be specified in a duration attribute [Packages 3.1] on its manifest item.

The following example shows how to include Media Overlays in the manifest of a Package Document.

<manifest>
   <item id="ch1"
         href="chapter1.xhtml"
         media-type="application/xhtml+xml"
         media-overlay="ch1_audio"
         duration="0:32:29"/>

   <item id="ch1_audio"
         href="chapter1_audio.smil"
         media-type="application/smil+xml"/>
   …
</manifest>

If an EPUB Content Document is wholly or partially referenced by a Media Overlay, then its manifest item entry must include a media-overlay attribute.

The media-overlay attribute must not be attached to manifest item elements that do not reference EPUB Content Documents.

  3.5.2 Package Metadata

The Package Document must include the duration of the entire Rendition in a meta element with the duration [Overlays Vocab] property.

Authors also may include narrator [Overlays Vocab] 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 following example shows a Package Document with metadata about Media Overlays.

<metadata>
   …
   <meta property="media:duration">1:36:20</meta>
   <meta property="media:narrator">Joe Speaker</meta>
   <meta property="media:active-class">-epub-media-overlay-active</meta>
   <meta property="media:playback-active-class">-epub-media-overlay-playing</meta>
   …
</metadata>

note

The prefix media: is reserved by [Packages 3.1] for the inclusion of these properties in package metadata.

  4 Playback Behaviors

  4.1 Loading the Media Overlay

When an EPUB Reading System loads a Package Document, it must refer to the Manifest item elements' media-overlay attributes to discover the corresponding Media Overlays for EPUB Content Documents. Playback must start at the Media Overlay element which corresponds to the desired EPUB Content Document starting point. Note that the start of an EPUB Content Document may correspond to an element at the start or in the middle of a Media Overlay. When the Media Overlay Document has finished playing, the Reading System should load the next EPUB Content Document (as specified in the Package Document spine) and also load its corresponding Media Overlay Document, provided that one is given.

  4.2 Basic Playback

  4.2.1 Timing and Synchronization

Reading Systems must render immediate children of the body element in a sequence. A seq element's children must be rendered in sequence, and playback completes when the last child has finished playing. A par element's children must be rendered in parallel (with each starting at the same time), and playback completes when all the children have finished playing. When the body element's last child has finished playing, playback of the Media Overlay Document is done.

  4.2.2 Rendering Audio

When presented with a Media Overlay audio element, Reading Systems must play the audio resource referenced by the src attribute, starting at the clip offset time given by the clipBegin attribute and ending at the clip offset time given by the clipEnd attribute. The following rules must be observed:

If clipBegin is not specified, its value is assumed to be "0".

If clipEnd is not specified, its value is assumed to be the full duration of the physical media.

If clipEnd exceeds the full duration of the physical media, then its value is assumed to be the full duration of the physical media.

User-controllable audio playback options should include timescale modification, in which the playback rate is altered without distorting the pitch. The suggested range is half-speed to double-speed.

  4.2.3 Rendering EPUB Content Document Elements

When presented with a Media Overlay text element, Reading Systems should ensure the EPUB Content Document element referenced by the src attribute is visible in the Viewport. During Media Overlays playback, Reading Systems with a Viewport should add the class names given by the metadata properties active-class and playback-active-class [Overlays Vocab] to the appropriate elements in the EPUB Content Document. Conversely, the class names should be removed when the playback state changes, as described in Associating Style Information.

The active-class and playback-active-class metadata properties are optional, and if omitted, Reading System behavior is implementation-specific.

  4.3 Interacting with the EPUB Content Document

  4.3.1 Navigation

Because the Media Overlay is closely linked to the EPUB Content Document, it is very easy for Reading Systems to locate a position in the EPUB Content Document based on the current position in the Media Overlay playback. If the user pauses synchronized playback and navigates to a different part of the EPUB Publication, synchronized playback must resume at that point. For example, if a specific page number in the EPUB Content Document is the desired location, then this same point is located in the Media Overlay and playback started there.

This same approach allows for synchronizing the Media Overlay playback with user selection of a navigation point in the EPUB Navigation Document. The Reading System loads the Media Overlay for that file and finds the correct point for starting playback based on the ID [XML] of the navigation point target.

note

A Media Overlay Document can be associated directly with a Navigation Document in order to provide synchronized playback of its contents, regardless of whether the XHTML Content Document in which it resides is included in the spine. See EPUB Navigation Document for more information.

note

Media Overlay Document elements can be associated with EPUB Content Document structures such as tables. Reading Systems need to ensure that Media Overlay playback remains synchronized with user navigation of table rows and cells. The Reading System might also play the corresponding table header preceding the contents of the cell.

  4.3.2 Embedded Audio and Video

An EPUB Content Document with which a Media Overlay is associated may itself contain embedded video and audio media, which may be pointed to by Media Overlay elements. Unlike text and images, video and audio media has an intrinsic duration. Consequently, when a Reading System renders the synchronization described by a Media Overlay, the default playback behavior of audio and video media embedded within the associated EPUB Content Document must be overridden.

Note that the rules below apply only to referenced [HTML] video or audio elements within the associated EPUB Content Document. That is to say, the rules apply to only those elements pointed to by text elements within the Media Overlay (i.e., via the src attribute). Embedded media that is not referenced by Media Overlay elements is not subject to these rules.

All referenced audio and video media embedded within an EPUB Content Document must have their public playback interface deactivated (typically: play/pause control, time slider, volume level, etc.). This behavior is necessary to avoid interference between the scheduled playback sequence defined by the Media Overlay, and the arbitrary playback behavior due to user interaction or script execution. As a result, when the Reading System is in playback mode, it should:

Hide the individual video/audio UI controls from the page, which overrides the default behavior defined by the [HTML] controls attribute.

Prevent scripts embedded within the EPUB Content Document from invoking the JavaScript audio/video playback API (i.e., authored as part of the default behavior). It is recommended that content producers avoid publishing embedded scripts dedicated to controlling the playback of embedded audio/video media. The published Media Overlay can then retain full control of the synchronized presentation without any risk of interference from script-enabled custom behaviors.

All referenced audio and video media embedded within an EPUB Content Document must be initialized to their "stopped" state, and be ready to be played from the zero-position within their content stream (possibly displaying the image specified using the [HTML] poster attribute). This requirement overrides the default behavior defined by the [HTML] autoplay attribute.

When an EPUB Content Document element becomes active, the CSS Style Sheet visual highlighting rules apply regardless of the content type referred to by that element's src attribute (e.g., the CSS class name defined by the active-class [Overlays Vocab] metadata property should be applied to visible video and audio player controls within the host EPUB Content Document).

In addition to the default behavior of Media Overlay activation for textual fragments and images, audio and video playback must be started and stopped according to the duration implied by the authored Media Overlay synchronization (as per the standard [SMIL] timing model). There are two possible scenarios:

When a Media Overlay text element has no audio sibling within its par parent container, the referenced EPUB Content Document audio or video media must play until it ends, at which point the text element's lifespan terminates. In this case, the implicit duration of the text element (and by inference, of the parent par container) is that of the referenced audio or video clip.

When a Media Overlay text element has an audio sibling within its par parent container, the playback duration of the referenced EPUB Content Document audio or video media must be constrained by the duration of the audio sibling. In this case, the actual duration of the parent par container is that of the child audio clip, regardless of the duration of the video or audio media pointed to by the text element. This behavior can result in embedded video or audio media ending playback prematurely (before reaching its full duration), or ending before the playback of the parallel Media Overlay audio is finished (in which case the last-played video frame should remain visible until the parent par container finally ends). This behavior is equivalent of the Media Overlay audio element implicitly carrying the behavior of the [SMIL] endsync attribute.

Furthermore, Reading Systems should expose user controls for the volume levels of each independent audio track (i.e., from the audio element of the Media Overlay, and from the embedded audio or video media within the EPUB Content Document), so that audio output can be adjusted to match listeners' requirements. Note that having overlapping audio tracks is typically an authoring-time concern: content producers usually add a layer of audio information over a video track for description purposes. It is recommended that overlapping audio situations are carefully examined and dealt with at production stage, as Reading Systems are not required to handle simultaneous volume levels in any particular way.

When a text element becomes inactive in the Media Overlay, and when it points to embedded video or audio media, that referenced media must be reset to its initial "stopped" state, ready to be played from the zero-position within their content stream (possibly displaying the poster image specified using the [HTML] markup).

  4.3.3 Text-to-Speech

When a Media Overlay text element with no audio sibling element references text within the target EPUB Content Document, Reading Systems capable of Text-to-Speech (TTS) should render the referenced text using TTS.

As per Reading System conformance requirements, the speech-related information provided in the target EPUB Content Document should be used to play the audio stream as part of the Media Overlay rendering. See Reading System Text-to-Speech Conformance Requirements [EPUB 3.1].

The Media Overlay text element's lifespan corresponds to the rendering time of the associated speech synthesis. The implicit duration of the text element (and by inference, of the parent par element) is therefore determined by the execution of the Text-to-Speech engine, and cannot be known at authoring time (factors like speech rate, pauses and other prosody parameters influence the audio output).

  4.4 Skippability and Escapability

  4.4.1 Skippability

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 should 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 example shows a Media Overlay Document with a pagebreak. A Reading System could offer the user the option of turning on and off the page break/page number announcements, which are often cumbersome to listen to.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>
        <!-- a paragraph -->
        <par id="id1">
            <text src="chapter1.xhtml#para1"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:23:22.000"
                   clipEnd="0:24:15.000"/>
        </par>

        <!-- a page number -->
        <par id="id2" epub:type="pagebreak">
            <text src="chapter1.xhtml#pgbreak1"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:24:15.000"
                   clipEnd="0:24:18.123"/>
        </par>

        <!-- another paragraph -->
        <par id="id3">
            <text src="chapter1.xhtml#para2"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:24:18.123"
                   clipEnd="0:25:28.530"/>
        </par>
    </body>
</smil>

The following example shows an EPUB Content Document with a pagebreak.

<html … >
    …
    <body>
        <p id="para1">This is the paragraph before the pagebreak … </p>

        <span id="pgbreak1" epub:type="pagebreak" title="234"/>

        <p id="para2">This is the paragraph after the pagebreak …</p>
    </body>
</html>

The following non-exhaustive list represents terms from the [Structure Vocab] for which Reading Systems might offer the option of skippability:

footnote

endnote

pagebreak

Reading System support for skippability based on epub:type values should not be assumed.

  4.4.2 Escapability

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).

Reading Systems should allow escaping of nested structures. Reading Systems must determine the start of nested structures by the value of the epub:type attribute and should offer users the option to skip playback of that structure and resume with whatever content comes after it.

The following example shows the Media Overlay Document for an EPUB Content Document containing a paragraph, a table, and another paragraph. A Reading System that supported escapability would give the user the option to interrupt playback of the table to continue playing the next paragraph.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>
        <!-- a paragraph, part of the regular document text -->
        <par id="id1">
            <text src="c01.xhtml#para1"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:23:22.000"
                   clipEnd="0:24:15.000"/>
        </par>

        <!-- a table with two nested rows -->
        <seq id="id2" epub:textref="c01.xhtml#t1" epub:type="table">
            <seq id="id3" epub:textref="c01.xhtml#tr1" epub:type="table-row">
                <par id="id4" epub:type="table-cell">
                    <text src="c01.xhtml#td1"/>
                    <audio src="chapter1_audio.mp3"
                           clipBegin="0:24:15.000"
                           clipEnd="0:24:18.123"/>
                </par>
                <par id="id5" epub:type="table-cell">
                    <text src="c01.xhtml#td2"/>
                    <audio src="chapter1_audio.mp3"
                           clipBegin="0:24:18.123"
                           clipEnd="0:25:28.530"/>
                </par>
                <par id="id6" epub:type="table-cell">
                    <text src="c01.xhtml#td3"/>
                    <audio src="chapter1_audio.mp3"
                           clipBegin="0:25:28.530"
                           clipEnd="0:25:45.515"/>
                </par>
            </seq>
            <seq id="id7" epub:textref="c01.xhtml#tr2" epub:type="table-row">
                <par id="id8" epub:type="table-cell">
                    <text src="c01.xhtml#td4"/>
                    <audio src="chapter1_audio.mp3"
                           clipBegin="0:25:45.515"
                           clipEnd="0:26:45.700"/>
                </par>
                <par id="id9" epub:type="table-cell">
                    <text src="chapter1.xhtml#td5"/>
                    <audio src="chapter1_audio.mp3"
                           clipBegin="0:26:45.700"
                           clipEnd="0:28:02.033"/>
                </par>
                <par id="id10" epub:type="table-cell">
                    <text src="chapter1.xhtml#td6"/>
                    <audio src="chapter1_audio.mp3"
                           clipBegin="0:28:02.033"
                           clipEnd="0:28:52.207"/>
                </par>
            </seq>
        </seq>

        <!-- another paragraph -->
        <par id="id11">
            <text src="c01.xhtml#para2"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:28:52.207"
                   clipEnd="0:30:01.000"/>
        </par>
    </body>
</smil>

The following non-exhaustive list represents terms from the [Structure Vocab] for which Reading Systems might offer the option of escapability:

table

table-row

table-cell

list

list-item

figure

  5 EPUB Navigation Document

The EPUB Navigation Document is an XHTML Content Document and can therefore be associated with an audio Media Overlay. Unlike traditional XHTML Content Documents, however, Reading Systems have to present the EPUB Navigation Document to users even when it is not included in the spine (see EPUB Navigation Documents — Reading System Conformance [Packages 3.1]). As a result, the method in which an associated Media Overlay behaves can change depending on the context:

When included in the spine, playback of the EPUB Navigation Document's Media Overlay obeys the same conformance requirements as with any other XHTML Content Document.

When exposed in a presentation context that allows users to access and activate the links, Reading Systems may implement additional presentation behaviours to expose audio feedback when navigation links are accessed.

note

Specific implementation details are beyond the scope of this specification. The DAISY Media Overlays Playback Requirements document describes best practices for Authors, and provides recommendations for Reading System developers.

  Appendix A. Media Overlays Schema

The schema for Media Overlays is available at http://www.idpf.org/epub/31/schema/media-overlay-31.nvdl.

Validation using this schema requires a processor that supports [NVDL], [RelaxNG], [ISO Schematron] and [XSD-DATATYPES].

note

The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone.

  Appendix B. Examples of Clock Values

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

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Audrain, Luc (Hachette Livre)

Bailey, Brent (Elsevier)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bogan, Robert (Baker & Taylor)

Bowers, Micah (Bluefire Productions)

Burrows, Phil (VitalSource/Ingram Content Group)

Challman, Lauren (Kaplan Publishing)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Cleghorn, Tom (Cambridge University Press)

Comerford, Rachel (Macmillan)

Conboy, Garth (Google)

Corona, Juan (Evident Point)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Davis, Greg (Pearson)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Duga, Brady (Google)

Gardeur, Hadrien (Feedbooks)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haase, David (Penguin Random House)

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Herman, Ivan (W3C) W3C Liaison

Idan, Ori (Helicon Books)

Jay, Michael (Educational Systemics)

Johnson, Rick (VitalSource/Ingram Content Group)

Jung, Eunmi (KERIS (Korea Education and Research Information Service))

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

Khramov, Yuri (Readium)

Kleinfeld, Sanders (O'Reilly)

Koike, Toshiaki (Voyager Japan)

Labordrie, Cyril (EDRLab)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Levantovsky, Vladimir (Monotype)

Levenson, Yonah (Pearson)

Lin, Beatrice (KERIS (Korea Education and Research Information Service))

Lui, Edwina (Kaplan Publishing)

McCoy, Bill (IDPF)

Mietkiewicz, Elie (Gutenberg Technology)

Mitchell, Chris (Hachette Book Group)

Moua, Nou (Kaplan Publishing)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Owens, Evan (Cenveo Publisher Services)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally)

Rosenthol, Leonard (Adobe Systems)

Shyne, Mary (Penguin Random House)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Swick, Ralph (W3C)

Tallent, Joshua (eBookArchitects)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Wright, Ric (Readium Foundation)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Brady, Laura

Etemad, Elika J. W3C CSS WG Liaison

Garrish, Matt

Glazman, Daniel

Hawkins, Kevin

Kaplansky, Jean

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[Content Docs 3.1] EPUB Content Documents 3.1 .

[EPUB 3.1] EPUB 3.1 .

[HTML] HTML .

[ISO Schematron] ISO/IEC 19757-3: Rule-based validation — Schematron . 2006-06-01.

[NVDL] ISO/IEC 19757-4: NVDL (Namespace-based Validation Dispatching Language) . 2006-06-01.

[Overlays Vocab] EPUB 3.1 Media Overlays Vocabulary .

[Packages 3.1] EPUB Packages 3.1 .

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . M Duerst, et al. January 2005.

[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG. Second Edition . 2008-12-15.

[SMIL] SMIL Version 3.0 . D. Bulterman, et al. 01 December 2008.

[Structure Vocab] EPUB 3 Structural Semantics Vocabulary .

[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . T. Bray, et al. 26 November 2008.

[XMLNS] Namespaces in XML (Third Edition) . T. Bray, et al. 8 December 2009.

[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition . Paul V. Biron et al. 28 October 2004.

Informative References

[EPUB3 Changes] EPUB 3.1 Differences from EPUB 3.0.1 .

[EPUB3 Overview] EPUB 3.1 Overview .

[XPTRSH] XPointer Shorthand Notation . 25 March 2003.

EPUB Open Container Format (OCF) 3.1

Recommended Specification 5 January 2017

This version

http://www.idpf.org/epub/31/spec/epub-ocf-20170105.html

Latest version

http://www.idpf.org/epub3/latest/ocf

Previous version

http://www.idpf.org/epub/301/spec/epub-ocf-20161130.html

Previous recommendation

http://www.idpf.org/epub/31/spec/epub-ocf-20140626.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Errata

Editors

James Pritchett, Learning Ally (formerly Recording for the Blind & Dyslexic)

Markus Gylling, International Digital Publishing Forum (IDPF)

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Terminology

1.3. Typographic Conventions

1.4. Conformance Statements

2. OCF Conformance

2.1. Container Conformance

2.2. Reading System Conformance

3. OCF Abstract Container

3.1. Introduction

3.2. File and Directory Structure

3.3. Relative IRIs for Referencing Other Components

3.4. File Names

3.5. META-INF Directory

3.5.1. Inclusion

3.5.2. Reserved Files

3.5.2.1. Container File (container.xml)

3.5.2.2. Encryption File (encryption.xml)

3.5.2.3. Manifest File (manifest.xml)

3.5.2.4. Metadata File (metadata.xml)

3.5.2.5. Rights Management File (rights.xml)

3.5.2.6. Digital Signatures File (signatures.xml)

4. OCF ZIP Container

4.1. Introduction

4.2. ZIP File Requirements

4.3. OCF ZIP Container Media Type Identification

5. Resource Obfuscation

5.1. Introduction

5.2. Obfuscation Key

5.3. Obfuscation Algorithm

5.4. Specifying Obfuscated Resources

A. Schemas

A.1. Schema for container.xml

A.2. Schema for encryption.xml

A.3. Schema for signatures.xml

B. Example

C. The application/epub+zip Media Type

Acknowledgements and Contributors

References

  1 Overview

  1.1 Purpose and Scope

This section is informative

This specification, EPUB Open Container Format (OCF) 3.1, defines a file format and processing model for encapsulating the set of related resources that comprise an EPUB® Publication into a single-file container, the EPUB Container.

This specification defines the rules for structuring the file collection in the abstract (the "abstract container") and the rules for the representation of this abstract container within a ZIP archive (the "ZIP container"). The rules for ZIP containers build upon the ZIP technologies used by [ODF]. OCF also defines a standard method for obfuscating embedded resources, such as fonts, for those EPUB Publications that require this functionality.

This specification is one of a family of specifications that compose [EPUB 3.1], an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3.1.

Refer to [EPUB3 Changes] for more information on the differences between this specification and its predecessor.

  1.2 Terminology

Terms with meanings specific to EPUB 3.1 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [EPUB 3.1].

Only the first instance of a term in a section is linked to its definition.

In addition, the following terminology is defined for use in this specification:

Codec

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.

Default Rendition

The Rendition listed in the first rootfile element in the container.xml file.

File Name

The name of any type of file within an OCF Abstract Container, whether a directory or a file within a directory.

Non-Codec

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.).

OCF Abstract Container

The OCF Abstract Container defines a file system model for the contents of the OCF ZIP Container, as defined in OCF Abstract Container.

OCF Processor

A software application that processes OCF ZIP Containers according to the requirements of this specification.

OCF ZIP Container

The ZIP-based packaging and distribution format for EPUB Publications, as defined in OCF ZIP Container.

OCF ZIP Container and EPUB Container are synonymous.

Path Name

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.

Root Directory

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.

  1.3 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  1.4 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

  2 OCF Conformance

  2.1 Container Conformance

  An OCF Abstract Container must meet the conformance constraints defined in OCF Abstract Container.

  An OCF ZIP Container must meet the conformance constraints defined in OCF ZIP Container.

  2.2 Reading System Conformance

An EPUB Reading System must meet all of the following criteria:

  It must process the OCF ZIP Container in conformance with all Reading System conformance constraints expressed in OCF ZIP Container.

  If it has a Viewport, it must support deobfuscation of resources as defined in Resource Obfuscation.

  3 OCF Abstract Container

  3.1 Introduction

This section is informative

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 META-INF Directory.

  3.2 File and Directory Structure

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 META-INF Directory.

The file name mimetype in the Root Directory is reserved for use by OCF ZIP Containers, as explained in 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.

It is recommended that the contents of the EPUB Publication be stored within its own dedicated directory under the Root Directory.

  3.3 Relative IRIs for Referencing Other Components

Files within the OCF Abstract Container must reference each other via relative IRI references ([RFC3987] and [RFC3986]).

The following example shows how a file named image1.jpg in the same directory as an XHTML Content Document can be referenced from an [HTML] img element.

<img src="image1.jpg" alt="…" />

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 [CSS Snapshot].

note

Some language specifications reference Requests For Comments [RFC] that preceded [RFC3987], in which case the earlier RFC applies for content in that particular language.

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).

  3.4 File Names

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. This specification does not specify how an OCF Processor that is unable to represent OCF File and Path Names would compensate for this incompatibility.

In the context of an OCF Abstract Container, File and Path Names are case sensitive and must meet all of the following criteria:

  File Names must be UTF-8 [Unicode] encoded.

  File Names must not exceed 255 bytes.

  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)

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].

note

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.

  3.5 META-INF Directory

  3.5.1 Inclusion

All OCF Abstract Containers must include a directory called META-INF in their Root Directory.

This directory contains the files specified in META-INF Reserved Files. Files other than the ones listed in that section may be included in the META-INF directory; OCF Processors must not fail when encountering such files.

  3.5.2 Reserved Files

  3.5.2.1 Container File (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 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.

An OCF Processor must consider the first rootfile element within the rootfiles element to represent the Default Rendition for the contained EPUB Publication. Reading Systems are required to present the Default Rendition, but may present other Renditions in the container.

The following example shows a sample container.xml for an EPUB Publication with the root file EPUB/My Crazy Life.opf (the Package Document):

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="EPUB/My_Crazy_Life.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

The following example shows SVG and XHTML Renditions bundled in the same container:

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="SVG/Sandman.opf"
            media-type="application/oebps-package+xml" />
        <rootfile full-path="XHTML/Sandman.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

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 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.

OCF Processors must ignore foreign elements and attributes within a container.xml file.

  3.5.2.2 Encryption File (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 [XML ENC Core]. 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 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 [XML ENC Core] 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 IDPF 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 [XML SIG 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.

In the following example, adapted from Section 2.2.1 of [XML ENC Core] the resource image.jpeg is encrypted using a symmetric key algorithm (AES) and the symmetric key is further encrypted using an asymmetric key algorithm (RSA) with a key of John Smith.

<encryption
    xmlns ="urn:oasis:names:tc:opendocument:xmlns:container"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <enc:EncryptedKey Id="EK">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo>
            <ds:KeyName>John Smith</ds:KeyName>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherValue>xyzabc</enc:CipherValue>
        </enc:CipherData>
    </enc:EncryptedKey>
    <enc:EncryptedData Id="ED1">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK"
                Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="image.jpeg"/>
        </enc:CipherData>
    </enc:EncryptedData>
</encryption>

Order of Compression and Encryption

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).

Element Name

Compression

Namespace

http://www.idpf.org/2016/encryption#compression

Usage

Optional child of EncryptionProperty.

Attributes

Method [required]

Identifies the compression method used.

Value is either "0" (no compression) or "8" (Deflate algorithm).

OriginalLength [required]

Represents the size of the initial resource (number of bytes).

Value is a positive integer.

Content Model

Empty

The following example shows an MP4 file that that has been Deflate compressed and whose original size was 3500000 bytes.

<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
        ...
        <enc:CipherData>
            <enc:CipherReference URI="OEPBS/video.mp4"/>
        </enc:CipherData>
        <enc:EncryptionProperties>
            <enc:EncryptionProperty xmlns:ns="http://www.idpf.org/2016/encryption#compression">
                <ns:Compression Method="8" OriginalLength="3500000"/>
            </enc:EncryptionProperty>
        </enc:EncryptionProperties>
        ...
    </enc:EncryptedData>
</encryption>

  3.5.2.3 Manifest File (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.

  3.5.2.4 Metadata File (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 [XMLNS]. 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 IDPF-defined EPUB extension specifications.

  3.5.2.5 Rights Management File (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 [XMLNS] 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.

  3.5.2.6 Digital Signatures File (signatures.xml)

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 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 [XML DSIG Core]. 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.

note

Each Signature in the signatures.xml file identifies by IRI the data to which the signature applies, using the [XML DSIG Core] 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 [XML DSIG Core] 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.

note

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 [XML DSIG Core] 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 [XML DSIG Core] specification describes how additional information can be added to a signature, such as by use the SignatureProperties element.

The following XML expression shows the content of an example signatures.xml file, and is based on the examples found in Section 2 of [XML DSIG Core]. It contains one signature, and the signature applies to two resources, EPUB/book.xhtml and EPUB/images/cover.jpeg, in the container.

<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <Signature Id="sig" xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
            <CanonicalizationMethod
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
            <Reference URI="#Manifest1">
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue>…</SignatureValue>
        <KeyInfo>
            <KeyValue>
                <DSAKeyValue>
                    <P>…</P><Q>…</Q><G>…</G><Y>…</Y>
                </DSAKeyValue>
            </KeyValue>
        </KeyInfo>
        <Object>
            <Manifest Id="Manifest1">
                <Reference URI="EPUB/book.xhtml">
                    <Transforms>
                        <Transform
                            Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="EPUB/images/cover.jpeg">
                    <Transforms>
                        <Transform
                            Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
            </Manifest>
        </Object>
    </Signature>
</signatures>

  4 OCF ZIP Container

  4.1 Introduction

This section is informative

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.

  4.2 ZIP File Requirements

An OCF ZIP Container uses the ZIP format as specified by [ZIP APPNOTE 6.3.3], 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 APPNOTE 6.3.3] that allow ZIP files to be split across multiple storage media. OCF Processors must treat any OCF files that specify that the ZIP file is split across multiple storage media as being in error.

   OCF ZIP Containers must include only stored (uncompressed) and Deflate-compressed ZIP entries within the ZIP archive. OCF Processors must treat any OCF Containers that use compression techniques other than Deflate as being in error.

  OCF ZIP Containers may use the ZIP64 extensions defined as "Version 1" in section V, subsection G of the application note [ZIP APPNOTE 6.3.3] and should use only those extensions when the content requires them. OCF Processors must support the ZIP64 extensions defined as "Version 1".

  OCF ZIP Containers must not use the encryption features defined by the ZIP format; instead, encryption must be done using the features described in Encryption File (encryption.xml). OCF Processors must treat any other OCF ZIP Containers that use ZIP encryption features as being in error.

  It is not a requirement that OCF Processors preserve information from an OCF ZIP Container through load and save operations that is not defined within the OCF Abstract Container; in particular, an OCF Processor does not have to preserve CRC values, comment fields or fields that hold file system information corresponding to a particular operating system (e.g., External file attributes and Extra field).

  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). OCF Processors must treat any other values as being in error.

  In the local file header table, OCF ZIP Containers must set the compression method field to the values 0 or 8. OCF Processors must treat any other values as being in error.

  OCF Processors must treat OCF ZIP Containers with an Archive decryption header or an Archive extra data record as being in error.

  4.3 OCF ZIP Container Media Type Identification

The first file in the OCF ZIP Container must be the mimetype file. The contents of this file must be the MIME media type [RFC2046] string application/epub+zip encoded in US-ASCII [US-ASCII].

The contents of the mimetype file must not contain any leading padding or white space, must not begin with the Unicode signature (or Byte Order Mark), and the case of the media type string must be exactly as presented above. The mimetype file additionally must not be compressed or encrypted, and there must not be an extra field in its ZIP header.

note

Refer to Appendix C, The application/epub+zip Media Type for further information about the application/epub+zip media type.

  5 Resource Obfuscation

  5.1 Introduction

This section is informative

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, or by the IDPF, that this constitutes encryption, nor does it guarantee that the resource will be secure from copyright infringement. It is the hope of the IDPF, 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.

  5.2 Obfuscation Key

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 [SHA-1]. This digest is then directly used as the key for the algorithm.

  5.3 Obfuscation 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 Encryption File (encryption.xml) to compress resources before encrypting them.

The following pseudo-code exemplifies the obfuscation algorithm.

set ocf to OCF container file
set source to file
set destination to obfuscated file
set keyData to key for file
set outer to 0
while outer < 52 and not (source at EOF)
    set inner to 0
    while inner < 20 and not (source at EOF)
        read 1 byte from source     //Assumes read advances file position
        set sourceByte to result of read
        set keyByte to byte inner of keyData
        set obfuscatedByte to (sourceByte XOR keyByte)
        write obfuscatedByte to destination
        increment inner
    end while
    increment outer
end while
if not (source at EOF) then
    read source to EOF
    write result of read to destination
end if
Deflate destination
store destination as source in ocf

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.

note

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.

  5.4 Specifying Obfuscated Resources

Although not technically encrypted data, all obfuscated resources must have an entry in the encryption.xml file accompanying the EPUB Publication (see Encryption File (encryption.xml)).

An EncryptionMethod element must be included for each obfuscated resource. Each must include a child EncryptedData 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.

The following example shows an entry for an obfuscated font in the encryption.xml file.

<encryption
    xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
    <enc:EncryptedData>
        <enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding"/>
        <enc:CipherData>
            <enc:CipherReference URI="EPUB/Fonts/BKANT.TTF"/>
        </enc:CipherData>
    </enc:EncryptedData>
</encryption>

To prevent trivial copying of the embedded resource to other EPUB Publications, the obfuscation key must not be provided in the encryption.xml file.

  Appendix A. Schemas

  A.1 Schema for container.xml

The schema for container.xml files is available at http://www.idpf.org/epub/31/schema/ocf-container-31.rnc.

Validation using this schema requires a processor that supports [RelaxNG] and [XSD-DATATYPES].

  A.2 Schema for encryption.xml

The schema for encryption.xml files is included in [XML Sec RNG Schemas].

  A.3 Schema for signatures.xml

The schema for signatures.xml files is included in [XML Sec RNG Schemas].

  Appendix B. Example

The following example demonstrates the use of this OCF format to contain a signed and encrypted EPUB Publication within an OCF ZIP Container.

Ordered list of files in the OCF ZIP Container

mimetype
META-INF/container.xml
META-INF/signatures.xml
META-INF/encryption.xml
EPUB/As You Like It.opf
EPUB/book.html
EPUB/nav.html
EPUB/images/cover.png

The contents of the mimetype file

application/epub+zip

The contents of the META-INF/container.xml file

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles>
        <rootfile full-path="EPUB/As_You_Like_It.opf"
            media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

The contents of the META-INF/signatures.xml file

<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <Signature Id="AsYouLikeItSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">

        <!--
             SignedInfo is the information that is actually signed.
             In this case the SHA1 algorithm is used to sign the
             canonical form of the XML documents enumerated in the
             Object element below
        -->
        <SignedInfo>
            <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
            <Reference URI="#AsYouLikeIt">
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>…</DigestValue>
            </Reference>
        </SignedInfo>

        <!--
             The signed value of the digest above using the DSA
             algorithm
        -->
        <SignatureValue>…</SignatureValue>

        <!-- The key to use to validate the signature -->
        <KeyInfo>
            <KeyValue>
                <DSAKeyValue>
                    <P>…</P>
                    <Q>…</Q>
                    <G>…</G>
                    <Y>…</Y>
                </DSAKeyValue>
            </KeyValue>
        </KeyInfo>

        <!--
             The list documents to sign. Note that the canonical
             form of XML documents is signed while the binary form
             of the other documents is used
        -->
        <Object>
            <Manifest Id="AsYouLikeIt">
                <Reference URI="EPUB/As You Like It.opf">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="EPUB/book.html">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
                <Reference URI="EPUB/images/cover.png">
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue></DigestValue>
                </Reference>
            </Manifest>
        </Object>
    </Signature>
</signatures>

The contents of the META-INF/encryption.xml file

<?xml version="1.0"?>
<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <!--
         The RSA encrypted AES-128 symmetric key used to encrypt
         the data
    -->
    <enc:EncryptedKey Id="EK">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo>
            <ds:KeyName>John Smith</ds:KeyName>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherValue>xyzabc…</enc:CipherValue>
        </enc:CipherData>
    </enc:EncryptedKey>

    <!--
         Each EncryptedData block identifies a single document
         that has been encrypted using the AES-128 algorithm.
         The data remains stored in its encrypted form in the
         original file within the container.
    -->
    <enc:EncryptedData Id="ED1">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="EPUB/book.html"/>
        </enc:CipherData>
    </enc:EncryptedData>

    <enc:EncryptedData Id="ED2">
        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
        <ds:KeyInfo>
            <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        </ds:KeyInfo>
        <enc:CipherData>
            <enc:CipherReference URI="EPUB/images/cover.png"/>
        </enc:CipherData>
    </enc:EncryptedData>

</encryption>

The contents of the EPUB/As You Like It.opf file

<?xml version="1.0"?>
<package version="3.1"
         xml:lang="en"
         xmlns="http://www.idpf.org/2007/opf"
         unique-identifier="pub-id">

    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
        <dc:identifier
              id="pub-id">urn:uuid:B9B412F2-CAAD-4A44-B91F-A375068478A0</dc:identifier>

        <dc:language>en</dc:language>

        <dc:title>As You Like It</dc:title>

        <dc:creator id="creator">William Shakespeare</dc:creator>

        <meta property="dcterms:modified">2000-03-24T00:00:00Z</meta>

        <dc:publisher>Project Gutenberg</dc:publisher>

        <dc:date>2000-03-24</dc:date>

        <meta property="dcterms:dateCopyrighted">9999-01-01</meta>

        <dc:identifier
              id="isbn13">urn:isbn:9780741014559</dc:identifier>

        <dc:identifier id="isbn10">0-7410-1455-6</dc:identifier>

        <link rel="xml-signature"
              href="../META-INF/signatures.xml#AsYouLikeItSignature"/>
    </metadata>

    <manifest>
        <item id="r4915"
              href="book.html"
              media-type="application/xhtml+xml"/>
        <item id="r7184"
              href="images/cover.png"
              media-type="image/png"/>
        <item id="nav"
              href="nav.html"
              media-type="application/xhtml+xml"
              properties="nav"/>
    </manifest>

    <spine>
        <itemref idref="r4915"/>
    </spine>
</package>

  Appendix C. The application/epub+zip Media Type

This appendix registers the media type application/epub+zip for the EPUB Open Container Format (OCF).

An OCF 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 International Digital Publishing Forum (IDPF).

MIME media type name:

application

MIME subtype name:

epub+zip

Required parameters:

None.

Optional parameters:

None.

Encoding considerations:

OCF files are binary files in ZIP (http://www.iana.org/assignments/media-types/application/zip) format.

Security considerations:

All processors that read OCF 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 files, it is possible that application/epub+zip may describe content that has security implications beyond those described here. However, only in the case 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. And in that case, they would fall outside the domain of this registration document.

Security considerations that apply to application/zip also apply to OCF files.

Interoperability considerations:

None.

Published specification:

This media type registration is for the EPUB Open Container Format (OCF), as described by the EPUB Open Container Format (OCF) 3.0 specification located at http://www.idpf.org/epub/30/spec/epub30-ocf.html.

The EPUB OCF 3.0 specification supersedes 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.

Applications which use this media type:

This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive.

Adobe Digital Editions

Aldiko

Azardi

Apple iBooks

Barnes & Noble Nook

Calibre

Google Books

Ibis Reader

MobiPocket reader

Sony Reader

Stanza

Additional information:

Magic number(s):

0: PK 0x03 0x04, 30: mimetype, 38: application/epub+zip

File extension(s):

OCF files are most often identified with the extension .epub.

Macintosh File Type Code(s):

ZIP

Fragment Identifiers:

The IDPF maintains a registry of linking schemes at http://www.idpf.org/epub/linking/. Some of these schemes define custom fragment identifiers that resolve to application/epub+zip and application/oebps-package+xml documents.

Person & email address to contact for further information:

William McCoy, bmccoy@idpf.org

Intended usage:

COMMON

Author/Change controller:

International Digital Publishing Forum (http://www.idpf.org)

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Audrain, Luc (Hachette Livre)

Bailey, Brent (Elsevier)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bogan, Robert (Baker & Taylor)

Bowers, Micah (Bluefire Productions)

Burrows, Phil (VitalSource/Ingram Content Group)

Challman, Lauren (Kaplan Publishing)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Cleghorn, Tom (Cambridge University Press)

Comerford, Rachel (Macmillan)

Conboy, Garth (Google)

Corona, Juan (Evident Point)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Davis, Greg (Pearson)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Duga, Brady (Google)

Gardeur, Hadrien (Feedbooks)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haase, David (Penguin Random House)

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Herman, Ivan (W3C) W3C Liaison

Idan, Ori (Helicon Books)

Jay, Michael (Educational Systemics)

Johnson, Rick (VitalSource/Ingram Content Group)

Jung, Eunmi (KERIS (Korea Education and Research Information Service))

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

Khramov, Yuri (Readium)

Kleinfeld, Sanders (O'Reilly)

Koike, Toshiaki (Voyager Japan)

Labordrie, Cyril (EDRLab)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Levantovsky, Vladimir (Monotype)

Levenson, Yonah (Pearson)

Lin, Beatrice (KERIS (Korea Education and Research Information Service))

Lui, Edwina (Kaplan Publishing)

McCoy, Bill (IDPF)

Mietkiewicz, Elie (Gutenberg Technology)

Mitchell, Chris (Hachette Book Group)

Moua, Nou (Kaplan Publishing)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Owens, Evan (Cenveo Publisher Services)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally)

Rosenthol, Leonard (Adobe Systems)

Shyne, Mary (Penguin Random House)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Swick, Ralph (W3C)

Tallent, Joshua (eBookArchitects)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Wright, Ric (Readium Foundation)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Brady, Laura

Etemad, Elika J. W3C CSS WG Liaison

Garrish, Matt

Glazman, Daniel

Hawkins, Kevin

Kaplansky, Jean

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[CSS Snapshot] CSS Snapshot .

[EPUB 3.1] EPUB 3.1 .

[HTML] HTML .

[RFC2046] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (RFC 2046) . N. Freed, N. Borenstein. November 1996.

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

[RFC3986] Uniform Resource Identifier (URI): Generic Syntax (RFC 3986) . Berners-Lee, et al. January 2005.

[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . M Duerst, et al. January 2005.

[RelaxNG] ISO/IEC 19757-2: Regular-grammar-based validation — RELAX NG. Second Edition . 2008-12-15.

[SHA-1] Federal Information Processing Standards Publication 180-3: Secure Hash Standard (SHS) . October 2008.

[TR15] Unicode Normalization Forms .

[US-ASCII] "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986..

[Unicode] The Unicode Consortium. The Unicode Standard..

[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition) . T. Bray, et al. 26 November 2008.

[XML DSIG Core] XML-Signature Syntax and Processing Version 1.1 . M. Bartel, et al. 11 April 2013.

[XML ENC Core] XML Encryption Syntax and Processing Version 1.1 . D. Eastlake, et al. 11 April 2013.

[XML SIG Decrypt] Decryption Transform for XML Signature . M. Hughes, et al. 10 December 2002.

[XML Sec RNG Schemas] XML Security RELAX NG Schemas (W3C Working Group Note) . Makoto Murata, et al. 11 April 2013.

[XMLNS] Namespaces in XML (Third Edition) . T. Bray, et al. 8 December 2009.

[XSD-DATATYPES] XML Schema Part 2: Datatypes Second Edition . Paul V. Biron et al. 28 October 2004.

[ZIP APPNOTE 6.3.3] ZIP File Format Specification . September 1, 2012. PKWARE, Inc..

Informative References

[EPUB3 Changes] EPUB 3.1 Differences from EPUB 3.0.1 .

[EPUB3 Overview] EPUB 3.1 Overview .

[ODF] Open Document Format for Office Applications (OpenDocument) v1.0 . 1 May 2005.

[RFC] Request for Comments.

EPUB Accessibility 1.0

Conformance and Discovery Requirements for EPUB Publications

Recommended Specification 5 January 2017

This version

http://www.idpf.org/epub/a11y/accessibility-20170105.html

Latest version

http://www.idpf.org/epub/latest/accessibility

Previous version

http://www.idpf.org/epub/a11y/accessibility-20161130.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Errata

Editors

Matt Garrish, Invited Expert

George Kersher, DAISY Consortium

Charles LaPierre, Benetech

Avneesh Singh, DAISY Consortium

Authors

Romain Deltour, DAISY Consortium

Markus Gylling, International Digital Publishing Forum (IDPF)

Bernhard Heinser, Access for All

Jean Kaplansky, Invited Expert

Madeleine Rothberg, Invited Expert

Tzviya Siegman, John Wiley & Sons

Jason White, Invited Expert

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Success Techniques

1.3. Application to Older Specifications

1.4. Terminology

1.5. Typographic Conventions

1.6. Conformance Statements

2. Conformance

2.1. Discoverable EPUB Publications

2.2. Accessible EPUB Publications

2.3. Optimized EPUB Publications

2.4. Distribution

3. Discovery

3.1. Introduction

3.2. Package Metadata

3.3. Linked Metadata Records

4. Accessible Publications

4.1. Introduction

4.2. Relationship to WCAG

4.3. WCAG Conformance

4.3.1. WCAG Conformance Requirements

4.3.2. Evaluating WCAG Conformance

4.3.2.1. Page and Publication

4.3.2.2. Applying the Conformance Criteria

4.4. EPUB Requirements

4.4.1. Page Navigation

4.4.1.1. Objective

4.4.1.2. Understanding this Objective

4.4.1.3. Meeting this Objective

4.4.1.4. Relationship to WCAG

4.4.2. Media Overlays Playback

4.4.2.1. Objective

4.4.2.2. Understanding this Objective

4.4.2.3. Meeting this Objective

4.4.2.4. Relationship to WCAG

4.5. Conformance Reporting

5. Optimized Publications

6. Distribution

A. Authoring and Consumption

A.1. Introduction

A.2. Authoring Tool Conformance

A.3. Distribution System Conformance

A.4. Reading System Conformance

Acknowledgements and Contributors

References

  1 Overview

  1.1 Purpose and Scope

This section is informative

This specification, EPUB Accessibility, addresses two key needs in the EPUB® ecosystem:

evaluation and certification of accessible EPUB Publications;

discovery of the accessible qualities of EPUB Publications.

Although it has always been possible to create EPUB Publications with a high degree of accessibility, this specification sets formal requirements to meet to certify content as accessible. These requirements provide Authors a clear set of guidelines to evaluate their content against, and allow certification of quality.

The inclusion of accessibility metadata, on the other hand, facilitates informed decisions about the usability of an EPUB Publication. Consumers can review the qualities of the content and decide whether an EPUB Publication is appropriate for their needs, regardless of whether it meets the bar of being certified broadly accessible.

This specification defines three categories of compliance for EPUB Publications:

Discoverable — an EPUB Publication that meets the discovery metadata requirements of this specification but does not meet the accessibility requirements. Conformance is defined in Discoverable EPUB Publications.

Accessible — an EPUB Publication that meets all discovery, [WCAG 2.0] and EPUB accessibility requirements. Conformance is defined in Accessible EPUB Publications.

Optimized — an EPUB Publication that meets the discovery requirements for Optimizations. Conformance is defined in Optimized EPUB Publications.

This specification does not target a single version of EPUB. It is designed to be applicable to EPUB Publications that conform to any version or profile, including future versions of the standard.

Ideally, these guidelines will be instructive in evaluating any digital publication built on Open Web technologies, although ensuring such application is outside the scope of this specification.

note

For additional background on the decisions that went into this specification, refer to the informative [Accessibility FAQ].

  1.2 Success Techniques

This specification takes an abstract approach to the accessibility requirements for EPUB Publications, similar to how [WCAG 2.0] separates its accessibility guidelines from the techniques to achieve them. This approach allows the guidelines to remain stable even as the format evolves.

To facilitate this approach, the companion [EPUB Accessibility Techniques] document outlines conformance techniques. The techniques explain how to meet the requirements of this specification for different versions of EPUB.

  1.3 Application to Older Specifications

This section is informative

This specification is designed to be applicable to any EPUB Publication, even if the content conforms to an older specification that does not make reference to this one (i.e., specifications prior to [EPUB 3.1]).

Authors of such EPUB Publications are encouraged to create content in conformance with the accessibility requirements of this specification, even though it is not normatively required.

  1.4 Terminology

Assistive Technology

This specification adopts the meaning of an assistive technology from [WCAG 2.0].

Note that an assistive technology is not always a separate application from a Reading System. Reading Systems often integrate features of standalone assistive technologies, such as text-to-speech playback.

Author

The person(s) or organization responsible for the creation of an EPUB Publication. The Author is not necessarily the creator of the content.

Discoverable EPUB Publication

An EPUB Publication that includes a description of its accessible qualities in its Package Document metadata, as defined in Discovery.

Inclusion of this metadata allows users to make informed decisions about the usability of the EPUB Publication, even in cases where the content does not meet the accessibility requirements of this specification.

Distribution System

A system that provides users access to obtain EPUB Publications, such as an online bookstore or public library.

EPUB Authoring Tool

This specification adapts the meaning of authoring tool from [ATAG 2.0]. An EPUB Authoring Tool differs only in that it is has to be able to create or modify an EPUB Publication.

EPUB Content Document

A document that conforms to one of the EPUB Content Document definitions.

EPUB Publication

A collection of one or more Renditions that represents a single intellectual or artistic work.

Optimized EPUB Publication

An EPUB Publication whose content is enhanced to be accessible by users with a specific need (e.g., dyslexia) or preferred reading modality (e.g., audio, tactile), so does not meet the broader accessibility requirements of [WCAG 2.0]. See Optimized Publications.

Package Document

The Package Document describes one Rendition of an EPUB Publication. It carries meta information, provides a manifest of resources and defines the default reading order.

Reading System

A system that processes EPUB Publications for presentation to a user.

Rendition

A logical document entity that represents one rendering of an EPUB Publication.

note

Some terms have more precise meanings for a given version of EPUB. Refer to the appropriate specification for more information.

  1.5 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  1.6 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendixes applies to all child content and subsections they contain.

All examples in this specification are informative.

  2 Conformance

  2.1 Discoverable EPUB Publications

A Discoverable EPUB Publication must meet the following criteria:

  It must include discovery metadata as defined in Discovery.

  2.2 Accessible EPUB Publications

An EPUB Publication must meet the following criteria to be accessible per this specification:

  It must meet the requirements for Discoverable EPUB Publications.

  It must meet the requirements for [WCAG 2.0] conformance defined in WCAG Conformance Requirements.

  It must meet the requirements for EPUB Publications defined in EPUB Requirements.

  It must include accessibility conformance metadata as defined in Conformance Reporting.

  2.3 Optimized EPUB Publications

An Optimized EPUB Publication must meet the following criteria:

  It must meet the requirements for Discoverable EPUB Publications.

  It must identify the standard or guidelines it conforms to as defined in Optimized Publications.

  2.4 Distribution

Regardless of the type or level of accessibility an EPUB Publication achieves, it must be distributed accessibly, as defined in Distribution.

  3 Discovery

  3.1 Introduction

This section is informative

Unlike Web pages, EPUB Publications are designed to be distributed through many channels for personal consumption — a model that has made EPUB a successful format for ebooks and other types of digital publications. A consequence of this model, however, is that specific details about the accessibility of a publication need to travel with it.

An online bookstore aggregating content from publishers and authors, for example, does not know the production quality that went into each submission, so can only convey to consumers what is present in each publication's metadata.

Ensuring that the accessible qualities of an EPUB Publication can be discovered by any interested party is therefore a primary concern. Users need to be able to gauge the usability of an EPUB Publication when they purchase, borrow or otherwise obtain it, a determination that requires knowing the any affordances made to meet the accessibility requirements.

Similarly, content that does not meet the requirements of this specification, while not broadly accessible, might still meet the needs of individual users. Only through the inclusion of rich metadata can a user decide if the content is suitable for them.

  3.2 Package Metadata

Every conformant EPUB Publication must include the following [schema.org] accessibility metadata:

  accessMode — a human sensory perceptual system or cognitive faculty necessary to process or perceive the content (e.g., textual, visual, auditory, tactile).

  accessibilityFeature — features and adaptations that contribute to the overall accessibility of the content (e.g., alternative text, extended descriptions, captions).

  accessibilityHazard — any potential hazards that the content presents (e.g., flashing, motion simulation, sound).

  accessibilitySummary — a human-readable summary of the overall accessibility, which includes a description of any known deficiencies (e.g., lack of extended descriptions, specific hazards).

Inclusion of the following [schema.org] accessibility metadata is recommended:

  accessModeSufficient — a set of one or more access modes sufficient to consume the content without significant loss of information. An EPUB Publication might have more than one set of sufficient access modes for its consumption depending on the types of content it includes (i.e., unlike accessMode, this property takes into account any affordances for content that is not broadly accessible, such as the inclusion of transcripts for audio content).

Inclusion of the following [schema.org] accessibility metadata is optional:

  accessibilityAPI — indicates the resource is compatible with the specified accessibility API. This property is typically only used to indicate that the use of scripting in an EPUB Publication follows [WAI-ARIA 1.1] authoring practices, as compatibility with operating system accessibility APIs is a concern for Reading Systems.

  accessibilityControl — identifies input methods that can be used to access the content (e.g., keyboard, mouse).

note

See Discovery Metadata Techniques [EPUB Accessibility Techniques] for more information on these properties and how to include them in different versions of EPUB.

See also DIST-002: Include accessibility metadata in distribution records [EPUB Accessibility Techniques] for more information on including accessibility metadata in other formats.

note

The above recommendations cover all [schema.org] accessibility properties at the time of publication. If new properties are added in the future, Authors are encouraged to include them, as applicable, until such time as this specification can be updated.

Inclusion of accessibility metadata from other vocabularies is optional.

  3.3 Linked Metadata Records

Accessibility metadata can also be included in linked records [Packages], but the inclusion of such metadata solely in a linked record does not satisfy the discovery requirements of this specification.

note

The precedence given to linked records varies depending on the version of EPUB (linked records have higher precedence than the package metadata in [EPUB 3.1], but lower precedence in earlier versions). As a result, Authors need to take care to ensure that accessibility metadata in the Package Document and any linked records do not contain contradictory statements, as it can affect the information a Reading System presents to the user.

  4 Accessible Publications

  4.1 Introduction

This section is informative

EPUB is built on the Open Web Platform, with HTML, CSS, JavaScript and SVG the core technologies used for content authoring. The use of these technologies means that EPUB Publications can be authored with a high degree of accessibility simply through the proper application of established Web accessibility techniques.

The primary source for the production of accessible Web content is the W3C Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG 2.0]. This specification leverages the extensive work done in [WCAG 2.0] to establish benchmarks for accessible content, and the same four high-level content principles — Perceivable, Operable, Understandable and Robust — are central to creating accessible EPUB Publications.

This section defines how to apply the conformance criteria defined in [WCAG 2.0] and also addresses qualities unique to EPUB Publications.

EPUB Publications authored to comply with the requirements in this section will have a high degree of accessibility for users with a wide variety of reading needs and preferences.

  4.2 Relationship to WCAG

This section is informative

[WCAG 2.0] and [WCAG 2.0 Techniques] provide extensive coverage of issues and solutions for Web content accessibility — from tables to embedded multimedia to rich semantics. They represent the foundation that this specification builds upon.

This specification does not repeat the requirements or techniques introduced in those documents, as it risks breaking compatibility between the two standards (e.g., putting guidance out of sync, or in conflict). At the same time, although the requirements are not individually called out, it does not diminish their importance in creating accessible EPUB Publications.

This specification instead adds an additional set of requirements for EPUB Publications. These requirements are no more or less important than those covered in WCAG; they are simply necessary to follow for EPUB Publications. (The relationship to WCAG is explained for each requirement in its respective section.)

The same is true of the techniques in the [EPUB Accessibility Techniques] document. It provides coverage of techniques that are unique to EPUB Publications, or that need clarification in the context of an EPUB Publication. It does not mean that the rest of the WCAG techniques are not applicable.

As a result, although this section can be read without deep knowledge of WCAG conformance, to implement the accessibility requirements of this specification will require an understanding of [WCAG 2.0].

note

Because this specification adds requirements that are not a part of WCAG, an EPUB Publication can conform to [WCAG 2.0] without conforming to this specification. An EPUB Publication that does not meet the requirements for EPUB Publications is not accessible to this specification, however.

The IDPF plans to work with W3C and the Web Accessibility Initiative to harmonize the requirements for EPUB Publications with WCAG.

  4.3 WCAG Conformance

  4.3.1 WCAG Conformance Requirements

EPUB Publications must meet [WCAG 2.0] Level A to be conformant with this specification, but it is recommended that they meet Level AA.

Although this specification only requires Level A conformance, local and national laws can influence the level of conformance an EPUB Publication has to meet to be considered accessible. Level AA conformance is often cited as the benchmark for accessibility in legal frameworks and policies, for example. Additionally, any procurer or distributor of EPUB Publications can demand higher conformance requirements than the baseline defined here.

Authors consequently need to ensure they understand the requirements their content has to meet to be considered accessible in any jurisdiction or distribution context, including seeking any necessary legal advice. Minimum conformance with this specification does not supersede such requirements, and does not offer protection from any legal liability that might arise.

  4.3.2 Evaluating WCAG Conformance

  4.3.2.1 Page and Publication

The [WCAG 2.0] Principles focus on the evaluation of individual Web pages, but an EPUB Publication more closely resembles what [WCAG 2.0] refers to as a set of Web pages: "[a] collection of Web pages that share a common purpose".

Consequently, when evaluating the accessibility of an EPUB Publication, individual pages — or Content Documents, as they are known in EPUB nomenclature — cannot be reviewed in isolation. Rather, their overall accessibility as parts of a larger work also has to be evaluated.

For example, it is not sufficient for individual Content Documents to have a logical reading order if the publication presents them in the wrong order. Likewise, including a title for every Content Document is complementary to providing a title for the publication: the overall accessibility is affected if either is missing.

The [WCAG 2.0] guidelines for content to be perceivable, operable, understandable and robust therefore must be evaluated against the full EPUB Publication, not only to each Content Document within it.

More information about applying these guidelines to EPUB Publications is available in the [EPUB Accessibility Techniques].

  4.3.2.2 Applying the Conformance Criteria

When evaluating an EPUB Publication, the [WCAG 2.0] Conformance Criteria are applied as follows:

  When determining compliance with a Conformance Level, the EPUB Publication as a whole must meet the conformance requirements of the level claimed.

  Authors must not use EPUB's fallback mechanisms to provide a conforming alternate version [WCAG 2.0], as there is no reliable way for users to access such fallbacks. If fallbacks are used, both the primary content and its fallback(s) must meet the requirements for the conformance level claimed. EPUB-specific fallback mechanisms include manifest fallbacks, bindings and content switching via the epub:switch element.

  When determining compliance with the "Full Pages" requirement (i.e., that parts of a page cannot be excluded when making a conformance claim), the entirety of each content document must achieve the conformance level and every content document in the publication must meet the stated conformance level.

  4.4 EPUB Requirements

  4.4.1 Page Navigation

  4.4.1.1 Objective

Provide navigation to static page break locations.

  4.4.1.2 Understanding this Objective

This section is informative

Statically paginated content is still ubiquitous, as print continues to be the most consumed medium for books both among the general reading public and in educational settings. Print is not the only source of static pagination, either: static page boundaries are also present in fixed-layout digital publications.

As a result, a non-visual reader in an environment where statically-paginated content is used is disadvantaged relative to his or her peers by not being able to easily locate the same locations in the publication (e.g., if a teacher instructs students to all turn to a specific page).

The inclusion of page boundary locations helps bridge this disparity by ensuring that those using reflowable media are not disadvantaged by their choice.

Providing page navigation also helps in reflowable publications that do not have a statically paginated equivalent. The default pagination of these publications by Reading Systems is not static, since it changes depending on the viewport size and user's font settings. As a result, coordinating locations among users of the same EPUB Publication can be complicated without static references.

  4.4.1.3 Meeting this Objective

Authors should include page navigation in an EPUB Publication whenever any of the following cases is true:

  the EPUB Publication is identified as the dynamically-paginated equivalent of a statically-paginated publication (e.g., included in a print/digital bundle).

  the EPUB Publication is offered as an alternative to a statically-paginated publication in an environment where the use of both versions can be reasonably predicted (e.g., education).

  the EPUB Publication and a statically-paginated publication are generated from a workflow that allows the retention of page break locations across formats.

Authors may include page navigation in reflowable EPUB Publications without statically paginated equivalents.

A conformant EPUB Publication must meet the following criteria when it includes page navigation:

  It must provide a means of locating the page break locations.

  It may include page break markers.

  It must identify the source of the page breaks.

In addition, if page numbers are read aloud in a synchronized text-audio playback of the content (e.g., EPUB 3 Media Overlays), Authors must identify the page numbers in the markup that controls the playback.

See Page Markers [EPUB Accessibility Techniques] for more information on the inclusion of page navigation in EPUB Publications.

  4.4.1.4 Relationship to WCAG

This section is informative

The inclusion of page navigation represents one method of achieving the [WCAG 2.0] Multiple Ways success criterion, as it provides another meaningful way for users to access the content (e.g., in addition to the table of contents, linear reading order and any other navigation aids).

Given the importance of page navigation in mixed print/digital environments, the requirement to include this feature has higher precedence than it would be given solely as one of many ways to meet the Multiple Ways success criterion.

  4.4.2 Media Overlays Playback

This section is informative

  4.4.2.1 Objective

Structure Media Overlays to provide more accessible playback experiences.

  4.4.2.2 Understanding this Objective

Media Overlays provide an accessible playback experience for anyone who benefits from having text and audio synchronized. They are also useful to users who only require audio playback, or only benefit from reading with text highlighting. Media Overlays also enable a seamless playback experience from beginning to end of an EPUB Publication for all these users.

The most basic Media Overlay Documents [Media Overlays] provide only minimal instructions to Reading Systems, however. They indicate the text to highlight and the audio clip that corresponds to the text. The result is that users only have basic start and stop options available.

Authors need to add structure and semantics to Media Overlay Documents to allow Reading Systems to present more usable experiences. With richer markup, a Reading System could provide the ability to skip past secondary content that interferes with the primary narrative, escape users from deeply nested structures like tables, and allow them to navigate through the sections of the publication without having to go to the table of contents.

  4.4.2.3 Meeting this Objective

Media Overlay Documents do not have to meet any additional requirements beyond those defined in [Media Overlays] to be conformant with this specification.

To improve the usability of Media Overlays, however, Authors are encouraged to ensure their EPUB Publications meet the following criteria:

  Identify all skippable structures [Media Overlays] in the Media Overlay Documents.

  Identify all escapable structures [Media Overlays] in the Media Overlay Documents.

  Include a Media Overlay Document for the EPUB Navigation Document [Media Overlays].

note

A future version of this specification might introduce stricter conformance requirements for Media Overlay Documents.

  4.4.2.4 Relationship to WCAG

Adding structure and semantics to Media Overlay Documents broadly falls under the objective of the [WCAG 2.0] Info and Relationships success criterion. Without structured and semantically meaningful playback sequences, the effect is to deprive users rich navigation of the content.

  4.5 Conformance Reporting

To indicate that an EPUB Publication conforms to the accessibility requirements of this specification, it must include a conformsTo property [DCTERMS] and an a11y:certifiedBy property [Accessibility Vocab].

The value of the conformsTo property must be one of the following IRIs:

http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-a

The EPUB Publication meets all accessibility requirements and achieves [WCAG 2.0] Level A conformance.

http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa

The EPUB Publication meets all accessibility requirements and achieves [WCAG 2.0] Level AA conformance.

http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aaa

The EPUB Publication meets all accessibility requirements and achieves [WCAG 2.0] Level AAA conformance.

The a11y:certifiedBy property specifies the name of the party that certified the content. The certifier of the content could be the same party that created the EPUB Publication, but can also be a third party accessibility certifier.

The following example shows an EPUB 3 Publication that has been self-certified by the publisher (the values of the dc:publisher and a11y:certifiedBy property are the same).

<metadata>
  …
  <dc:publisher>Acme Publishing Inc.</dc:publisher>
  <meta property="a11y:certifiedBy">Acme Publishing Inc.</meta>
  <link rel="dcterms:conformsTo" href="http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa"/>
  …
</metadata>

The following example shows an EPUB 3 Publication that has been certified by a third party (the values of the dc:publisher and a11y:certifiedBy property differ).

<metadata>
  …
  <dc:publisher>Acme Publishing Inc.</dc:publisher>
  <meta property="a11y:certifiedBy">Foo's Accessibility Testing</meta>
  <link rel="dcterms:conformsTo" href="http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa"/>
  …
</metadata>

The following example shows an EPUB 3 Publication that has been self-certified by the author.

<metadata>
  …
  <dc:creator>Jane Doe</dc:creator>
  <meta property="a11y:certifiedBy">Jane Doe</meta>
  <link rel="dcterms:conformsTo" href="http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa"/>
  …
</metadata>

The following example shows a self-certified EPUB 2 Publication.

<metadata>
  …
  <dc:publisher>Acme Publishing Inc.</dc:publisher>
  <meta name="dcterms:conformsTo" content="http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa"/>
  <meta name="a11y:certifiedBy" content="Acme Publishing Inc."/>
  …
</metadata>

note

If an EPUB Publication is certified by an organization, users will typically want to know the name of that organization. Including the name of the individual(s) who carried out the assessment, instead of the name of the certifying organization, is generally discouraged, as it can diminish the trust the user has in the claim.

If the party that certifies the content has been issued a credential or badge that establishes their authority to certify content accessible, that information can be supplied in an a11y:certifierCredential property [Accessibility Vocab].

The following example shows a credential.

<meta property="a11y:certifierCredential">A+ Accessibility Rating</meta>

If the party that certifies the content has provided a detailed report of its assessment, a link to the assessment can be provided in an a11y:certifierReport property [Accessibility Vocab].

The following example shows a link to a remotely-hosted accessibility report.

<link rel="a11y:certifierReport"
      href="http://www.example.com/a11y/report/9780000000001"/>

The following example shows a link to a locally-hosted accessibility report.

<link rel="a11y:certifierReport" href="reports/a11y.xhtml"/>

note

As each metadata format is unique in what it can express, this specification does not mandate how conformance metadata is expressed outside of the Package Document.

note

This specification does not define a conformance level for EPUB Publications that only meet the discovery metadata requirements, as the usability of such content by any given user can only be determined from the accessibility metadata. Reporting requirements for Optimized Publications are defined in the next section.

  5 Optimized Publications

Although [WCAG 2.0] provides a general set of guidelines for making content broadly accessible, conformant content is not always optimal for specific user groups. Conversely, content optimized for a specific need or reading modality is often not conformant to [WCAG 2.0] because it is not designed for a broad audience.

For example, an EPUB Publication with synchronized text and audio might contain a full audio recording of the content but limit the text content to only the major headings. In this case, the EPUB Publication is consumable by users who needs to hear the content (i.e., they can listen to the full publication and can navigate between headings), but it is not usable by anyone who cannot hear the audio.

In other words, when an EPUB Publication is optimized for specific reading modalities, the failure to achieve a WCAG conformance level does not make it any less accessible to the intended audience.

To account for this discrepancy, this specification places importance on the inclusion of discovery metadata. An Optimized EPUB Publication is discoverable to its intended audience through the inclusion of rich metadata, even if it is not identified as broadly accessible per this specification.

In addition to the metadata requirements defined in Discovery, an optimized EPUB Publication must identify the standard or guidelines the content adheres to in a [DCTERMS] conformsTo property. The value of this property must be an IRI [RFC3987] that references the standard or guidelines it follows.

The following example shows a conformance statement for an EPUB 3 Publication that conforms to the [DAISY Audio] guidelines.

<package …>
   <metadata>
      …
      <link rel="dcterms:conformsTo" href="http://www.daisy.org/guidelines/epub/navigable-audio-only-epub3-guidelines"/>
      …
   </metadata>
   …
</package>

If the IRI is not sufficient for a user to understand conformance (e.g., the guidelines are not publicly available), more information about how the content has been optimized should be provided in the accessibility summary.

The following example shows an accessibility summary for an EPUB Publication optimized for braille rendering.

<meta property="schema:accessibilitySummary">
    This publication is optimized for braille readers. It will not be
    usable by persons who cannot read braille. The publication is designed
    for braille reading devices capable of displaying 6 character cells and
    40 character line lengths. The text is not contracted, and follows
    Unified English Braille formatting conventions. All characters are
    encoded using the Unicode braille character set.
</meta>

The following example shows an accessibility summary for an EPUB Publication optimized for audio rendering.

<meta property="schema:accessibilitySummary">
    This publication is an audio book. It will not be usable by persons who
    cannot hear the audio. The publication is recorded by a professional
    narrator. There is navigation to the beginning of each chapter. The text
    of the publication is not included. Images are not included, but the
    photo captions are narrated at the end of the chapter where they occur.
</meta>

note

This specification does not define or recommend standards or guidelines for the production of optimized content. An informative registry of optimization standards is maintained separately from this specification, but no endorsement of them is implied.

  6 Distribution

The creation of an accessible EPUB Publication does not in itself guarantee that the content will be obtainable or consumable by users. Depending on the Distribution System used, other factors will influence the overall accessibility of the EPUB Publication.

This specification distinguishes factors that an Author has influence over from those that they do not. For example, an accessible interface for locating and obtaining content is an essential part of the distribution process, as is the ability to search and review accessibility metadata. Such interfaces are typically out of the control of content Authors, however, as distribution of EPUB Publications is often done through third parties. But even when Authors control their Distribution Channel, the accessibility of these applications is outside the scope of this specification, as such considerations are not appplicable to the EPUB Publications themselves.

At the same time, there are decisions Authors have to make when their content is ingested into Distribution Systems, such as what digital rights to apply. Although these decisions are not part of the preparation of the content, their potential impact on users requires special attention.

To minimize the effects of distribution on accessibility, Authors therefore must adhere to the following distribution practices:

  if digital rights management protection is applied to an EPUB Publication, the Author must not impose restrictions that impair access by Assistive Technologies.

  if a distributor requires that a distribution record (e.g., ONIX) accompany an EPUB Publication, the Author must include any accessibility metadata in the record that the format allows.

note

For more information about the accessibility of Distribution Systems, refer to Distribution System Conformance.

  Appendix A. Authoring and Consumption

  A.1 Introduction

Although this specification focuses on content requirements for accessible EPUB Publications, there are two additional considerations in making EPUB Publications available to everyone: the ability for anyone to be able to create an EPUB Publication and the ability for anyone to consume the content.

Although these needs are not the primary focus of this specification, this appendix provides conformance requirements for the creation of accessible Authoring Tools, Distribution Systems and Reading Systems. Developers who meet or exceed these requirements will make their applications usable by a wide variety of users.

note

This appendix could be superseded by specifications dedicated to these concerns in the future.

  A.2 Authoring Tool Conformance

A conformant EPUB Authoring Tool must meet the following criteria:

  It must meet the requirements for [ATAG 2.0] Level A conformance, with the following clarifications for Part B:

  It must include support for the EPUB-specific requirements defined in EPUB Requirements where [ATAG 2.0] references the generation of accessible web content (as applicable to the content it can generate).

  It must support [WCAG 2.0] accessibility requirements as they relate to EPUB Publications, including support for adding discovery metadata as defined in Package Metadata. See Page and Publication for more information.

  It should meet the requirements for [ATAG 2.0] Level AA conformance, with the same clarifications defined in the preceding criterion.

  A.3 Distribution System Conformance

A conformant Distribution System must meet the following criteria:

  Its user interface must conform to [WCAG 2.0] Level AA.

  It must provide the ability to narrow search results by the available accessibility metadata.

  A.4 Reading System Conformance

A conformant Reading System must meet the following criteria:

  It must pass all the [A11Y Test Suite] Fundamental Accessible Reading System Tests.

  It should meet the requirements for [UAAG 2.0] Level AA conformance.

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB Accessibility specification and techniques were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Work on these documents was undertaken by an accessibility subgroup led by:

LaPierre, Charles ( Benetech )

Singh, Avneesh ( DAISY Consortium )

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Comerford, Rachel (Macmillan)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Deltour, Romain (DAISY Consortium)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Johnson, Rick (VitalSource/Ingram Content Group)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Mietkiewicz, Elie (Gutenberg Technology)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Prabhu, John (HOV Services)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Garrish, Matt

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[A11Y Test Suite] EPUB Accessibility Tests .

[ATAG 2.0] Authoring Tools Accessibility Guidelines (ATAG) 2.0 . Jan Richards, et al.

[Accessibility Vocab] EPUB Accessibility Vocabulary .

[DCTERMS] DCMI Metadata Terms .

[EPUB 3.1] EPUB 3.1 .

[Media Overlays] EPUB Media Overlays 3.1 .

[Packages] EPUB Packages 3 .

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . M Duerst, et al. January 2005.

[UAAG 2.0] User Agent Accessibility Guidelines 2.0 . Ian Jacobs, et al. 17 December 2002.

[WAI-ARIA 1.1] Accessible Rich Internet Applications (WAI-ARIA) 1.1 . Joanmarie Diggs, et al.

[WCAG 2.0] Web Content Accessibility Guidelines (WCAG) 2.0 . Ben Caldwell, et al.

[WCAG 2.0 Techniques] Techniques for WCAG 2.0. . Michael Cooper, et al.

[schema.org] schema.org.

Informative References

[Accessibility FAQ] EPUB Accessibility Frequently Asked Questions.

[DAISY Audio] Navigable audio-only EPUB 3 Guidelines .

[EPUB Accessibility Techniques] EPUB Accessibility Techniques .

[EPUB3 Overview] EPUB 3.1 Overview .

Alternate Style Tags 1.1

Recommended Specification 5 January 2017

This version

http://www.idpf.org/epub/altss-tags/altss-tags-20170105.html

Latest version

http://www.idpf.org/epub/altss-tags/

Previous version

http://www.idpf.org/epub/altss-tags/altss-tags-20161130.html

Previous recommendation

http://www.idpf.org/epub/altss-tags/altss-tags-20140626.html

Document history

Changes to this document

Report an issue

Errata

Editors

Elika J. Etemad, Invited Expert

Copyright © 2011 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

Table of Contents

1. Introduction

2. Conformance

3. Style Sets

4. Tagging Style Sets

A. Vertical Text Style Set Tags

B. Night Vision Style Set Tags

C. Acknowledgements

References

  1 Introduction

This section is informative

This module defines a pattern for tagging alternate style sheets using a microformat. It can be used to define standardized classes that can be hooked into the browser UI. Sample use cases include horizontal-vertical layout switches in Japanese ebook readers; automatically selecting high-contrast styles; and other accessibility concerns.

HTML 4.0 defines the linking of external style sheets using the link element. Although typically a style sheet is linked in unconditionally, HTML 4 also defines alternate style sets, which are named, mutually-exclusive sets of style sheets that the reader can use to alter the display.

Until now, few [HTML] user agents have exposed alternate styles in a meaningful way. However, alternate styles are a very simple way to allow the user to alter a document's presentation to his or her preferences and accessibility needs.

This specification takes advantage of the class attribute of the HTML link element (introduced in [HTML], but supported in many user agents for much longer) to define style tags: a markup pattern for tagging style sheets with standardized class names. These class names can be used by a UA to offer special UI access to such tagged style sets.

The original impetus for this proposal was to offer standard controls for switching between horizontal and vertical layouts in Japanese ebook readers; this use case is addressed in Appendix A, Vertical Text Style Set Tags.

  2 Conformance

None of this specification applies if the UA has unilaterally turned author style sheets off. (This ability is mandated by HTML and CSS.) In this case, of course, all style sheets are disabled.

The [CSSOM] has more low-level controls for controlling whether a given style sheet is enabled or disabled; scripting the CSSOM may alter the behavior defined here.

note

Future versions of this specification will define error handling rules and interaction with [CSSOM].

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections and appendixes of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendices applies to all child content and subsections they contain.

All examples in this specification are informative.

  3 Style Sets

This section is informative

This is an informative summary of HTML's declarative alternate style set mechanism, with a few slight changes to terminology.

HTML 4 defines two types of style sheets in its linking mechanism: persistent style sheets and alternate style sheets.

A persistent style sheet is one that is always enabled, regardless of which alternate style set is enabled. A persistent style sheet is indicated by omitting the title attribute from the link or style element that imports it.

An alternate style sheet is one that is part of an alternate set, and can be enabled or disabled as part of that set. An alternate style sheet is indicated by setting a non-empty value for the title attribute of the link or style that imports it. Except for style sheets belonging to a preferred style set (see below), alternate style sheets have to have an alternate value in the rel attribue value addition to the stylesheet value.

HTML allows the grouping of multiple alternate style sheets into a single, named alternate style set. All alternate style sheets with the same title value belong to the same style set.

The author can indicate whether an alternate style set is preferred by omitting the alternate value from the rel attribute of each of its component alternate style sheets. If no preferred style sets are defined, the default preferred style set is an unnamed set containing no alternate style sheets.

By default, the first preferred style set is loaded. The author can override this behavior with the Default-Style meta or HTTP header as defined in [HTML401].

  4 Tagging Style Sets

A style sheet can be tagged by adding the tag's name to the class attribute of the link or style element that imports it. Tagging a style sheet with a standard style tag (one defined by a specification referencing this specification) indicates that it implements the functionality described by the style tag's definition. Both alternate style sheets and persistent style sheets may be tagged in this way.

A style set can be tagged by tagging any one of its component style sheets. Tagging a style set indicates that it offers the functionality described by the style tag's definition.

Authors using standard tags should tag all alternate style sheets within a style set with the same set of standard tags.

note

Future versions of this specification might allow UAs to selectively disable tagged style sheets within a style set. Therefore all alternate style sheets that need to be enabled or disabled together have to have the same set of standard tags.

If two style sheets within a style set are tagged with mutually exclusive tags, both tags are ignored.

A specification that defines style tags may indicate that a particular tag is assumed to be the default for untagged style sets.

  Appendix A. Vertical Text Style Set Tags

The following style tags are defined by this appendix:

horizontal

This style set provides a primarily horizontal presentation of text. This tag is mutually exclusive with vertical.

vertical

This style set provides a primarily vertical presentation of text. This tag is mutually exclusive with horizontal.

The UA may guess whether an untagged style set is horizontal or vertical, or may instead assign such a style set an indeterminate state.

Examples

The following examples use XHTML syntax; to use HTML syntax, simply drop the slash before the > in the tags.

In the following example, the author provides a style sheet for a primarily horizontal-text presentation of the document:

   <link rel="stylesheet" href="horizontal.css" class="horizontal"/>

The UA, knowing that only a horizontal version is provided, would have to synthesize a vertical style if one is needed.

In the following example, the author provides a style sheet for a primarily vertical-text presentation of the document:

   <link rel="stylesheet" href="vertical.css" class="vertical"/>

The UA, knowing that only a vertical version is provided, would have to synthesize a horizontal style if one is needed.

In the following example, the author provides style sheets for both horizontal-text and vertical-text presentations of the document:

  <link rel="stylesheet" href="horizontal.css" class="horizontal" title="横組"/>
  <link rel="alternate stylesheet" href="vertical.css" class="vertical" title="縦組"/>

Since only the second style set is marked with the alternate value of the rel attribute, the author has indicated a preference for the horizontal style set which, in the absence of a user override, should be used by default.

In the following example, the author provides style sheets for both horizontal-text and vertical-text presentations of the document:

  <link rel="alternate stylesheet" href="horizontal.css" class="horizontal" title="横組"/>
  <link rel="stylesheet" href="vertical.css" class="vertical" title="縦組"/>

Since only the first style set is marked with the alternate value of the rel attribute, the author has indicated a preference for the vertical style set which, in the absence of a user override, should be used by default.

In the following example, the author provides style sheets for both horizontal-text and vertical-text presentations of the document:

  <link rel="stylesheet" href="horizontal.css" class="horizontal" title="横組"/>
  <link rel="stylesheet" href="vertical.css" class="vertical" title="縦組"/>

Since neither is marked with the alternate value of the rel attribute, both are preferred presentations by the author. Since the horizontal presentation is provided first, in the absence of a user preference to the contrary, it will be used by default.

  Appendix B. Night Vision Style Set Tags

The following style tags are defined by this appendix:

day

This style set provides a color scheme suited for daytime use (light background, dark text). This tag is mutually exclusive with night.

night

This style set provides a color scheme suited for nighttime use (dark background, light text). This tag is mutually exclusive with day.

Examples

In the following example, the author provides style sheets for both both day vision and night vision presentations of the document. Both horizontal-text and vertical-text presentations are available, but the horizontal presentation is preferred:

  <link rel="alternate stylesheet" href="vertical.css" class="vertical" title="Vertical Day"
  <link rel="alternate stylesheet" href="day.css"      class="day"      title="Vertical Day"/>
  <link rel="alternate stylesheet" href="vertical.css" class="vertical" title="Vertical Night"/>
  <link rel="alternate stylesheet" href="night.css"    class="night"    title="Vertical Night"/>
  <link rel="stylesheet" href="horizontal.css" class="horizontal" title="Horizontal Day"/>
  <link rel="stylesheet" href="day.css"        class="day"        title="Horizontal Day"/>
  <link rel="stylesheet" href="horizontal.css" class="horizontal" title="Horizontal Night"/>
  <link rel="stylesheet" href="night.css"      class="night"      title="Horizontal Night"/>

Of the preferred style sets, the day vision variant is listed first, and so in the absence of other preferences will be loaded by default.

The same effect can be created with fewer link tags by using @import statements:

  <link rel="alternate stylesheet" href="vertical-day.css"   class="vertical day"   title="Vertical Day"/>
  <link rel="alternate stylesheet" href="vertical-night.css" class="vertical night" title="Vertical Night"/>
  <link rel="stylesheet" href="horizontal-day.css"   class="horizontal day"   title="Horizontal Day"/>
  <link rel="stylesheet" href="horizontal-night.css" class="horizontal night" title="Horizontal Night"/>

where vertical-day.css is

  @import "vertical.css";
  @import "day.css";

and vertical-night.css is

  @import "vertical.css";
  @import "night.css";

and horizontal-day.css is

  @import "horizontal.css";
  @import "day.css";

and vertical-night.css is

  @import "horizontal.css";
  @import "night.css";

  Appendix C. Acknowledgements

This draft resulted from discussion in the W3C CSS Working Group and the IDPF EPUB Working Group and would not exist without the particular suggestion of Anne van Kesteren.

  References

Normative References

[HTML] HTML .

[HTML401] HTML 4.01 Specification . Dave Raggett, et al. 24 December 1999.

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.

Informative References

[CSSOM] CSSOM . Anne van Kesteren.

EPUB 3.1 Changes from EPUB 3.0.1

Informational Document 5 January 2017

This version

http://www.idpf.org/epub/31/spec/epub-changes-20170105.html

Latest version

http://www.idpf.org/epub3/latest/changes

Previous version

http://www.idpf.org/epub/31/spec/epub-changes-20161130.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Editors

Markus Gylling, International Digital Publishing Forum (IDPF)

Matt Garrish, Invited Expert

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents might supersede this document.

This document was produced by the EPUB Working Group under the EPUB Working Group Charter approved on 8 July 2015.

This document has been reviewed by the IDPF membership and is endorsed by the IDPF Board as a Recommended Specification. This document is considered stable and can be referenced from other specifications and documents.

Feedback on this document can be provided to the EPUB Working Group's mailing list or issue tracker.

This document is governed by the IDPF Policies and Procedures.

Table of Contents

1. Introduction

1.1. EPUB Revision History

2. Specification Reorganization

3. EPUB 3.1

3.1. Accessibility Support

3.2. New Core Media Types

3.3. Clarification of Foreign Resource Fallbacks

3.4. Remotely-Hosted Resources

3.5. Removed support for EPUBCFI for linking

4. Packages 3.1

4.1. The refines attribute

4.2. Linked Metadata Records

4.3. Removal of the OPF2 meta Element

4.4. NCX is Marked for Removal

4.5. Removal of the guide Element

4.6. Removal of the bindings Element

5. Content Documents 3.1

5.1. Undated References to HTML and SVG

5.2. Replacement of EPUB Style Sheets with CSS References

5.3. Prioritization of Author and User Styles

5.4. Scripting Support Clarifications

5.5. Removal of the switch Element

5.6. Removal of the trigger Element

5.7. epubReadingSystem Object Clarifications

6. Open Container Format (OCF) 3.1

6.1. Encryption

7. Media Overlays

7.1. Package Metadata Expressions

8. EPUB Accessibility

9. EPUB Canonical Fragment Identifiers

10. Alternate Style Tags

Acknowledgements and Contributors

References

  1 Introduction

EPUB® is an interchange and delivery format for digital publications, based on XML and Web Standards. An EPUB Publication can be thought of as a reliable packaging of Web content that represents a digital book, magazine, or other type of publication, and that can be distributed for online and offline consumption.

This document, EPUB 3.1 Changes from EPUB 3.0.1, describes changes made in the first major revision of the EPUB 3.0 specifications, highlighting key changes and additions.

This document is non-normative. Consult the EPUB specifications for definitive information on EPUB 3.

Unless otherwise specified, terms used herein have the meaning defined in Terminology [EPUB 3.1].

  1.1 EPUB Revision History

EPUB had its roots in the interchange format known as the Open EBook Publication Structure (OEBPS). OEBPS 1.0 was approved in 1999 by the Open eBook Forum, an organization that later became the International Digital Publishing Forum (IDPF). Subsequent revisions 1.1 and 1.2 were approved by the IDPF in 2001 and 2002 respectively.

It was realized that a need existed for a format standard that could be used for delivery as well as interchange, and work began in late 2005 on a single-file container format for OEPBS, which was approved by the IDPF as the OEBPS Container Format (OCF) in 2006. Work on a 2.0 revision of OEBPS began in parallel which was approved as the renamed EPUB 2.0 in October, 2007, consisting of a triumvirate of specifications: Open Package Format (OPF), Open Publication Format (OPF) together with OCF. EPUB 2.0.1, a maintenance update to the 2.0 specification set primarily intended clarify and correct errata in the specifications, was approved in September, 2010. [OPF2] [OPS2] [OCF2]

Work on a major revision of the EPUB specifications began in 2010, with the goal of aligning EPUB more closely with HTML, and in the process bringing new, native multimedia features, sophisticated CSS layout rendering and font embedding, scripted interactivity, enhanced global language support, and improved accessibility. A new specification, EPUB Media Overlays was also introduced, enabling text and audio synchronization in EPUB Publications. To better align the specification names with the standard, the Open Package Format specification was renamed EPUB Publications and the Open Publication Format specification was renamed EPUB Content Documents. The EPUB 3.0 specifications were approved in October, 2011. [Publications 3.0] [Content Docs 3.0] [OCF 3.0] [Media Overlays 3.0]

The EPUB 3.0.1 revision was undertaken in 2013-14. Although introducing mostly minor fixes and updates, it did see the integration of Fixed Layout Documents, which give Authors greater control over presentation when a reflowable EPUB is not suitable for the content. [Publications 3.0.1] [Content Docs 3.0.1] [OCF 3.0.1] [Media Overlays 3.0.1]

  2 Specification Reorganization

To simplify reading and referencing of the EPUB standard, a major reorganization of the specifications was undertaken in this revision. Foremost among the changes, a new umbrella EPUB 3.1 specification was introduced as the primary point of entry. EPUB Publication and Reading System requirements that were formerly defined in [Publications 3.0.1] were moved to this new top-level specification, as was the section on Publication Resources. All common terminology was collected into this top-level specification, as well, to provide a common point of reference. An index of key concepts and terms was also added to aid navigation of the various sub-specifications.

[Publications 3.0.1] was renamed to EPUB Packages 3.1 to better reflect that it defines Renditions of content through the Package Document. The EPUB Navigation Document definition was moved from [Content Docs 3.0.1] to this specification as it is a central component of a Package and not a general feature of EPUB Content Documents. Property definitions previously defined within this specification were moved out to external vocabularies.

[Media Overlays 3.1] also saw its embedded property definitions removed to a separate vocabulary, but was otherwise unchanged structurally.

[Content Docs 3.1] underwent mostly cosmetic changes outside of the removal of the EPUB Navigation Document definition. Some sections were renamed to better reflect that they are not unique document types but ways of enhancing content documents (e.g., the section "Scripted Content Documents" was changed to "Scripting"), but otherwise the arrangement of sections remains largely unchanged.

[OCF 3.1] similarly underwent some minor editorial and structure cleanup, but no sections were added or removed.

  3 EPUB 3.1

note

Refer to the issue tracker for a complete list of clarifications, typos and other issues in the EPUB 3.1 specification addressed in this revision.

  3.1 Accessibility Support

EPUB 3.1 adds a recommendation that all EPUB Publications conform to the new EPUB Accessibility Specification [EPUB Accessibility]. The accessibility specification makes recommendations for the inclusion of discovery metadata along with [WCAG 2.0] support in content.

EPUB Reading Systems are also recommended to meet the requirements in [EPUB Accessibility].

  3.2 New Core Media Types

EPUB 3.1 adds the WOFF 2.0 and SFNT font formats as Core Media Types [Core Media Types].

  3.3 Clarification of Foreign Resource Fallbacks

EPUB 3.1 adds an additional clarification that foreign resources do not require fallbacks if they are not in the spine and not embedded in EPUB Content Documents.

This change will allow authors to include data files for use by scripts without unnecessary fallbacks, among other benefits.

  3.4 Remotely-Hosted Resources

EPUB 3.1 allows fonts and resources used by scripts to be hosted outside the EPUB Container.

  3.5 Removed support for EPUBCFI for linking

EPUB 3.1 removes the requirement for Reading Systems to support EPUB Canonical Fragment Identifiers [EPUB-CFI] for hyperlinking (cf. the EPUB 3.0.1 EPUBCFI requirement).

  4 Packages 3.1

note

Refer to the issue tracker for a complete list of clarifications, typos and other issues in the EPUB Packages specification addressed in this revision.

  4.1 The refines attribute

Use of the refines attribute [Packages 3.1] is now deprecated. The following attributes have been added to replace the functionality it provided to Reading Systems: duration, opf:alt-rep, opf:authority, opf:file-as, opf:role, opf:scheme and opf:term.

note

The new opf:scheme attribute is similar in name and purpose to the existing scheme attribute allowed on the meta tag, but is limited to identifying identifier schemes. The attribute was previously allowed in EPUB 2, and compatibility was a consideration in retaining the prefixed name, as was keeping all attributes allowed on the [DCMES] elements in the opf: namespace. These benefits were seen to outweigh any initial authoring confusion that might arise.

  4.2 Linked Metadata Records

EPUB 3.1 also changes the precedence order of linked records, prioritizing bibliographic information in linked records over the information included directly in the Package Document metadata element.

note

A protocol for retrieving remote records was under development in an appendix in the last draft. That work has been removed and will be continued in a separate document.

  4.3 Removal of the OPF2 meta Element

EPUB 3.1 removes the [OPF2] meta element (cf. OPF2 meta element in EPUB 3.0.1).

  4.4 NCX is Marked for Removal

The EPUB 2 NCX file for navigation is now marked for removal (cf. EPUB 3.0.1 NCX). Support for it will be removed in the next major revision of EPUB.

  4.5 Removal of the guide Element

EPUB 3.1 removes the deprecated guide element (cf. EPUB 3.0.1 guide element).

  4.6 Removal of the bindings Element

EPUB 3.1 does not support the use of bindings in the Package Document to provide an alternative scripted fallback for foreign resources embedded in an object element (cf. EPUB 3.0.1 bindings).

The [HTML] object element's intrinsic fallback mechanism (embedded content) can be used to provide a Core Media Type fallback.

  5 Content Documents 3.1

note

Refer to the issue tracker for a complete list of clarifications, typos and other issues in the EPUB Content Documents specification addressed in this revision.

  5.1 Undated References to HTML and SVG

EPUB 3.0.1 used dated reference to HTML 5.0 and SVG 1.1, which tied the specification to those specific versions. Under this model, a new revision was required each time a version of HTML or SVG was introduced.

To ensure that that EPUB 3.1 remains up to date with the latest recommended versions of these specifications, the dated references have been replaced with undated references in EPUB 3.1. This change means that as new recommended versions of HTML and SVG are published, they are immediately valid for use in EPUB Publications.

For more information, see Relationship to HTML and Relationship to SVG.

  5.2 Replacement of EPUB Style Sheets with CSS References

EPUB 3.1 removes the EPUB Style Sheets profile. In its place, more general CSS support requirements are being defined:

CSS support is now required for visual Reading Systems.

Rather than a CSS profile, EPUB 3.1 uses the “official definition” of CSS from the CSS Working Group Snapshot.

The restriction on the use of position: fixed is removed.

The restriction on the use of position: absolute is removed.

All -epub- prefixed properties from CSS Speech are removed due to lack of implementations.

The -epub-ruby-position property is removed.

The -epub-text-combine-horizontal property is removed.

The -epub-fullsize-kana property is removed.

The -epub-text-emphasis shorthand property is removed.

The use-glyph-orientation and sideways-left values of -epub-text-orientation are removed.

  5.3 Prioritization of Author and User Styles

EPUB 3.1 adds guidance that Reading Systems should prioritize the style choices of Authors and users over its own user agent styles through the addition of Reading System conformance requirements and a subsection on overriding styles.

  5.4 Scripting Support Clarifications

EPUB 3.1 makes the following changes to scripting support:

Container-constrained scripting is limited to the [HTML] iframe element (removed embed and object).

Reading Systems should support container-constrained scripting (down from "must" because of security and privacy concerns around scripting)

Reading Systems should support spine-level scripting in fixed layout documents and the "scrolled-doc" and "scrolled-continuous" interfaces defined by the rendition:flow property

If a Reading System supports spine-level scripting in reflowable documents, it must support the "scrolled-doc" interface and should support the "scrolled-continuous" interface.

  5.5 Removal of the switch Element

EPUB 3.1 does not support the inclusion of the switch element for conditional display of content (cf. EPUB 3.0.1 switch element).

Authors are instead directed to the existing guidance on the use of the MathML altimg attribute.

  5.6 Removal of the trigger Element

EPUB 3.1 does not support the inclusion of the trigger element for declarative control of audio and video content (cf. EPUB 3.0.1 trigger element).

Authors are advised to use the native controls provided by the [HTML] audio and video elements.

  5.7 epubReadingSystem Object Clarifications

An IDL definition was added for the epubReadingSystem object.

The requirements for making the object available in the different scripting contexts, including in nested contexts, were also clarified.

  6 Open Container Format (OCF) 3.1

note

Refer to the issue tracker for a complete list of clarifications, typos and other issues in the OCF specification addressed in this revision.

  6.1 Encryption

The order of encryption and compression has been clarified. The new rules clarify that compression is not necessary when it is not beneficial to reducing the size of a resource. A new Compression element has been added to the encryption.xml schema to indicate whether a resource has been compressed and its original byte size.

  7 Media Overlays

note

Refer to the issue tracker for a complete list of clarifications, typos and other issues in the Media Overlays specification addressed in this revision.

  7.1 Package Metadata Expressions

The deprecation of the refines attribute in the Packages 3.1 specification has impacted the way that Media Overlays metadata gets expressed. In particular, the new duration attribute [Packages 3.1] is now attached to manifest items to indicate their total playback time (the total duration is still set in the package metadata, as before). Narrators can only be identified for the publication as a whole, not for each individual XHTML Content Document.

  8 EPUB Accessibility

The EPUB 3.1 revision introduces the [EPUB Accessibility] specification, which details how to make EPUB Publications accessible and discoverable. This specification leverages the work of [WCAG 2.0] and also adds requirements for EPUB Publications. It is accompanied by the informative [EPUB Accessibility Techniques] document that describes best practices for meeting the requirements.

This specification is designed to be applicable to older versions of EPUB. It can be used immediately by Authors to check whether their EPUB 3.0.1 or 2.0.1 Publications are accessible.

  9 EPUB Canonical Fragment Identifiers

Refer to the issue tracker for a complete list of clarifications, typos and other issues in the EPUB Canonical Fragment Identifiers specification addressed in this revision.

  10 Alternate Style Tags

Refer to the issue tracker for a complete list of clarifications, typos and other issues in the Alternate Style Tags specification addressed in this revision.

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB 3.1 specifications were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Audrain, Luc (Hachette Livre)

Bailey, Brent (Elsevier)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Belfanti, Paul (Pearson)

Bell, Graham (EDItEUR)

Bogan, Robert (Baker & Taylor)

Bowers, Micah (Bluefire Productions)

Burrows, Phil (VitalSource/Ingram Content Group)

Challman, Lauren (Kaplan Publishing)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Cleghorn, Tom (Cambridge University Press)

Comerford, Rachel (Macmillan)

Conboy, Garth (Google)

Corona, Juan (Evident Point)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Davis, Greg (Pearson)

DeMeglio, Marisa (DAISY Consortium)

Deltour, Romain (DAISY Consortium)

Duga, Brady (Google)

Gardeur, Hadrien (Feedbooks)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Haase, David (Penguin Random House)

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Herman, Ivan (W3C) W3C Liaison

Idan, Ori (Helicon Books)

Jay, Michael (Educational Systemics)

Johnson, Rick (VitalSource/Ingram Content Group)

Jung, Eunmi (KERIS (Korea Education and Research Information Service))

Kanai, Takeshi (Sony)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

Khramov, Yuri (Readium)

Kleinfeld, Sanders (O'Reilly)

Koike, Toshiaki (Voyager Japan)

Labordrie, Cyril (EDRLab)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Levantovsky, Vladimir (Monotype)

Levenson, Yonah (Pearson)

Lin, Beatrice (KERIS (Korea Education and Research Information Service))

Lui, Edwina (Kaplan Publishing)

McCoy, Bill (IDPF)

Mietkiewicz, Elie (Gutenberg Technology)

Mitchell, Chris (Hachette Book Group)

Moua, Nou (Kaplan Publishing)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Owens, Evan (Cenveo Publisher Services)

Prabhu, John (HOV Services)

Pritchett, James (Learning Ally)

Rosenthol, Leonard (Adobe Systems)

Shyne, Mary (Penguin Random House)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Swick, Ralph (W3C)

Tallent, Joshua (eBookArchitects)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Wright, Ric (Readium Foundation)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Brady, Laura

Etemad, Elika J. W3C CSS WG Liaison

Garrish, Matt

Glazman, Daniel

Hawkins, Kevin

Kaplansky, Jean

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[Content Docs 3.0] EPUB Content Documents 3.0 .

[Content Docs 3.0.1] EPUB Content Documents 3.0.1 .

[Content Docs 3.1] EPUB Content Documents 3.1 .

[Core Media Types] EPUB 3 Core Media Types.

[DCMES] Dublin Core Metadata Element Set, Version 1.1 .

[EPUB 3.1] EPUB 3.1 .

[EPUB Accessibility] EPUB Accessibility .

[EPUB-CFI] EPUB Canonical Fragment Identifier (epubcfi) Specification .

[HTML] HTML .

[Media Overlays 3.0] EPUB Media Overlays 3.0 .

[Media Overlays 3.0.1] EPUB Media Overlays 3.0.1 .

[Media Overlays 3.1] EPUB Media Overlays 3.1 .

[OCF 3.0] Open Container Format 3.0 .

[OCF 3.0.1] Open Container Format 3.0.1 .

[OCF 3.1] Open Container Format 3.1 .

[OCF2] Open Container Format 2.0.1 .

[OPF2] Open Packaging Format 2.0.1 .

[OPS2] Open Publication Structure 2.0.1 .

[Packages 3.1] EPUB Packages 3.1 .

[Publications 3.0] EPUB Publications 3.0 .

[Publications 3.0.1] EPUB Publications 3.0.1 .

[WCAG 2.0] Web Content Accessibility Guidelines (WCAG) 2.0 . Ben Caldwell, et al.

Informative References

[EPUB Accessibility Techniques] EPUB Accessibility Techniques .

[EPUB3 Overview] EPUB 3.1 Overview .

EPUB Accessibility Techniques 1.0

Informational Document 5 January 2017

This version

http://www.idpf.org/epub/a11y/techniques/techniques-20170105.html

Latest version

http://www.idpf.org/epub/latest/accessibility/techniques

Previous version

http://www.idpf.org/epub/a11y/techniques/techniques-20161130.html

Document history

Changes to this document

Issues addressed in this revision

Report an issue

Editors

Matt Garrish, Invited Expert

George Kersher, DAISY Consortium

Charles LaPierre, Benetech

Avneesh Singh, DAISY Consortium

Authors

Romain Deltour, DAISY Consortium

Markus Gylling, International Digital Publishing Forum (IDPF)

Bernhard Heinser, Access for All

Madeleine Rothberg, Invited Expert

Tzviya Siegman, John Wiley & Sons

Jason White, Invited Expert

Copyright © 2010-2017 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).

EPUB is a registered trademark of the International Digital Publishing Forum.

Table of Contents

1. Overview

1.1. Purpose and Scope

1.2. Terminology

1.3. Typographic Conventions

2. About the Techniques

3. Discovery Metadata Techniques

META-001: Identify primary access modes

META-002: Identify sufficient access modes

META-003: Identify accessibility features

META-004: Identify accessibility hazards

META-005: Include an accessibility summary

META-006: Identify ARIA Conformance

META-007: Identify Input Control Methods

Examples

4. WCAG Techniques

4.1. General Guidance

Helpful Resources

4.2. Content Access

ACCESS-001: Ensure linear reading order of the publication

ACCESS-002: Provide multiple ways to access the content

Note About the Table of Contents

4.3. Semantics

SEM-001: Include ARIA and EPUB semantics

Helpful Resources

SEM-002: Do not repeat semantics across chunked content

SEM-003: Include EPUB landmarks

Helpful Resources

4.4. Titles and Headings

TITLES-001: Include publication and document titles

TITLES-002: Ensure numbered headings reflect publication hierarchy

4.5. Descriptions

DESC-001: Include alternative text descriptions

Helpful Resources

4.6. Text

4.6.1. TEXT-001 - Use Unicode for text content

4.7. Accessible Alternatives

5. EPUB Techniques

5.1. Page Markers

PAGE-001: Provide page break markers

PAGE-002: Identify pages in audio playback

PAGE-003: Provide a page list

PAGE-004: Identify the pagination source

6. Distribution Techniques

DIST-001: Do not restrict access through digital rights management

DIST-002: Include accessibility metadata in distribution records

Helpful Resources

Acknowledgements and Contributors

References

  1 Overview

  1.1 Purpose and Scope

This section is informative

This document, EPUB Accessibility Techniques, provides guidance on how to meet the [EPUB Accessibility] discovery and accessibility requirements for EPUB® Publications.

This document does not cover techniques and best practices already addressed in [WCAG 2.0] and [WAI-ARIA 1.1] for which no substantive differences in application exist.

  1.2 Terminology

Assistive Technology

This specification adopts the meaning of an assistive technology from [WCAG 2.0].

Note that an assistive technology is not always a separate application from a Reading System. Reading Systems often integrate features of standalone assistive technologies, such as text-to-speech playback.

Author

The person(s) or organization responsible for the creation of an EPUB Publication. The Author is not necessarily the creator of the content.

Default Rendition

The Rendition listed in the first rootfile element in the META-INF/container.xml file.

EPUB Content Document

A document that conforms to one of the EPUB Content Document definitions.

EPUB Navigation Document

A specialized XHTML Content Document that contains human- and machine-readable global navigation information.

EPUB Publication

A collection of one or more Renditions that represents a single intellectual or artistic work.

Package Document

The Package Document describes one Rendition of an EPUB Publication. It carries meta information, provides a manifest of resources and defines the default reading order.

Reading System

A system that processes EPUB Publications for presentation to a user.

Rendition

A logical document entity that represents one rendering of an EPUB Publication.

note

Some terms have more precise meanings for a given version of EPUB. Refer to the appropriate specification for more information.

  1.3 Typographic Conventions

The following typographic conventions are used in this specification:

markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine-readable values (string, characters, media types) and file names are in red monospace font.

markup link

Links to markup and code definitions are in underlined red monospace font.

http://www.idpf.org/

URIs are in navy blue monospace font.

hyperlink

Hyperlinks are underlined and blue.

[reference]

Normative and informative references are enclosed in square brackets.

Term

Terms defined in the Terminology are in capital case.

Term Link

Links to term definitions have a dotted blue underline.

Normative element, attribute and property definitions are in blue boxes.

Informative markup examples are in light gray boxes.

note

Informative notes are in green boxes with a "Note" header.

caution

Informative cautionary notes are in red boxes with a "Caution" header.

  2 About the Techniques

The accessibility techniques described in this document are advisory in nature. They are intended to help Authors create EPUB Publications that conform to the requirements in [EPUB Accessibility], but they are not all applicable in all situations and there may be other ways to meet the requirements of that specification. As a result, this document should not be read as providing prescriptive requirements.

These techniques also do not address issues in digital publishing for which no universally accessible solutions exist. The W3C's Digital Publishing Interest Group has published a note that outlines many of these issues [W3C Accessibility Note]. As solutions become available, they will be incorporated into the appropriate document, whether this one or one it refers to.

If Authors encounter issues that are not covered in these or related techniques, they are encouraged to report the issue to the appropriate community for guidance on how to meet accessibility standards. The W3C Web Accessibility Interest Group has a public mailing list where issues meeting [WCAG 2.0] and [WAI-ARIA 1.1] requirements can be raised. The IDPF similarly has an accessibility forum where EPUB-related issues can be raised.

  3 Discovery Metadata Techniques

  META-001: Identify primary access modes

An access mode is defined as a "human sense perceptual system or cognitive faculty through which a user may process or perceive the content of a digital resource." [ISO24751-3] For example, if an EPUB Publication contains images and video, visual perception is required to consume the content exactly as it was created.

There are four access modes that are typically specified for EPUB Publications:

textual — the publication contains text content (headings, paragraphs, etc.).

visual — the publication contains visual content such as images, graphics, diagrams, animations and video.

auditory — the publication contains auditory content such as standalone audio clips and audio soundtracks for video content.

tactile — the publication contains tactile content such as embedded braille and tactile diagrams.

In order for a user to determine whether an EPUB Publication is suitable for their needs, they need to know which of these access modes are required to consume the content. List all applicable access modes in the [schema.org] accessMode property, repeating the property for each applicable mode.

The following example shows the metadata entries for an EPUB 3 Publication that has textual and visual access modes.

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>

Note that the access modes of the content do not reflect any adaptations that have been provided. For example, if a comic book also includes alternative text for each image, it does not have a textual access mode. See the following section on sufficient access modes for how to indicate that the available adaptations allow the content to be consumed in another mode.

Refer to the accessMode definition in [schema.org] for more information about this property and its values.

  META-002: Identify sufficient access modes

The access modes sufficient to consume an EPUB Publication express a broader picture of the potential usability than do the basic access modes. Where the basic access modes identify the default nature of the media used in the publication, sufficient access modes identify which modes, or sets of modes, a user requires to read the publication. Sufficient access modes take into account the affordances and adaptations that have been provided, allowing a user to determine whether the content will be usable regardless of its default nature.

Sufficient access modes are identified in the [schema.org] accessModeSufficient property. Repeat the property for each set of sufficient access modes.

For example, consider an EPUB Publication that contains graphics and charts, as well as descriptions for all these images. The publication has both textual and visual content, so the Author will include the following metadata entries to indicate this:

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>

This metadata does not make clear whether a textual access mode is sufficient to read the entire publication, or whether a visual one is, only that two modes are required by default. This discrepancy is why sufficiency is also important to know.

The first set of sufficiency metadata the Author inputs will establish the textual and visual requirement:

<meta property="schema:accessModeSufficient">textual,visual</meta>

The order in which the access modes are listed is not important. The only requirement is that they be separated by commas.

Since the Author has also included descriptions for all the images, she can also indicate that a purely textual access mode is sufficient to read the content:

<meta property="schema:accessModeSufficient">textual</meta>

Without this metadata, users would not have known that they could read the publication only via its text content.

The full set of entries in this example is as follows:

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>
<meta property="schema:accessModeSufficient">textual,visual</meta>
<meta property="schema:accessModeSufficient">textual</meta>

Note that sufficiency of access is often a subjective determination of the Author based on their understanding of what information is essential to comprehending the text. Some information loss occurs by not being able to view a video, for example, but the Author might regard the visual or auditory losses as inconsequential if a transcript provides all the necessary information to understand the concepts being conveyed.

Refer to the accessModeSufficient definition in [schema.org] for more information about this property and its values.

note

The accessModeSufficient property, as defined in [schema.org], allows more complicated expressions than can be represented in the EPUB 2 or 3 Package Document (e.g., defininition of lists of values and inclusion of a human-readable description). A future version of EPUB might allow for richer metadata, but the basic expression shown in this section is sufficient for discovery purposes.

  META-003: Identify accessibility features

Identifying all the accessibility features and adaptations included in an EPUB Publication allows users to determine whether the content is usable at a more fine-grained level than the access modes do.

For example, a math textbook might have a textual access mode, but that in itself does not indicate whether MathML markup is available. Whether a visual work only provides alternative text or whether it includes extended descriptions is also important to know when gauging its usability.

Accessibility features are identified in the [schema.org] accessibilityFeature property. Repeat this property for each feature.

The following example shows the metadata entries for an EPUB 3 Publication that has both MathML and alternative text.

<meta property="schema:accessibilityFeature">MathML</meta>
<meta property="schema:accessibilityFeature">alternativeText</meta>

The EPUB format requires that some accessibility features will always be present (e.g., a table of contents). Do not exclude these features from the accessibility metadata, as users typically are not aware what features are built into a format. Failing to include entries will reduce the discoverability of the publication when users search for specific features.

Refer to the accessibilityFeature definition in [schema.org] for more information about this property and its values.

  META-004: Identify accessibility hazards

There are three widely-recognized hazards that can affect readers of digital content:

flashing — if a resource flashes more than three times a second, it can cause seizures (e.g., videos and animations). See also [WCAG 2.0] Guideline 2.3.

motion simulation — if a resource simulates motion, it can cause a user to become nauseated (e.g., a video game drawn on the [HTML] canvas element).

sound — certain sound patterns, such as ringing and buzzing, can cause seizures.

Authors have to report whether or not their EPUB Publications contain resources that present any of these hazards to users, as they can have real physical effects.

Hazards are identified in the [schema.org] accessibilityHazard property. Repeat this property for each hazard.

Unlike other accessibility properties, the presence of hazards can be expressed both positively and negatively. This design decision was made because users most often search for content that is free from hazards that affect them, but also want to know what dangers are present in any publications they discover.

The following example shows the metadata entries for an EPUB 3 Publication that has a flashing hazard but no motion simulation or sound hazards.

<meta property="schema:accessibilityHazard">flashing</meta>
<meta property="schema:accessibilityHazard">noMotionSimulationHazard</meta>
<meta property="schema:accessibilityHazard">noSoundHazard</meta>

Do not skip reporting hazards just because an EPUB Publication does not contain any content that could present risks. Users cannot infer a meaning when no metadata is present. The value "none" can be used in such cases instead of repeating each non-hazard.

If an EPUB Publication contains a hazard, provide additional information about its source and nature in the accessibility summary.

If hazards cannot be definitively determined, report the value "unknown".

Refer to the accessibilityHazard definition in [schema.org] for more information about this property and its values.

  META-005: Include an accessibility summary

An accessibility summary provides a brief, human-readable description of the accessibility characteristics of an EPUB Publication, or lack thereof.

If an EPUB Publication does not meet the requirements for content accessibility in [EPUB Accessibility], the reason(s) it fails should be noted in the summary.

An accessibility summary is provided using the [schema.org] accessibilitySummary property.

The following example shows an accessibility summary for an EPUB 3 Publication that failed to meet the content accessibility requirements.

<meta property="schema:accessibilitySummary">
   The publication is missing alternative text for complex diagrams.
   The publication otherwise meets WCAG 2.0 Level A.
</meta>

The following example shows an accessibility summary for an EPUB 3 Publication with a motion simulation hazard.

<meta property="schema:accessibilitySummary">
   Chapter four contains a first-person interactive game that could cause
   motion sickness in certain individuals. The game is only provided for
   illustrative purposes, so readers unable to interact with it will not
   be at a disadvantage.
</meta>

Do not repeat this property unless it contains the summary in another language. In the case of multiple summaries, use the xml:lang attribute to differentiate the language.

Refer to the accessibilitySummary definition in [schema.org] for more information about this property.

  META-006: Identify ARIA Conformance

Users of Assistive Technologies are able to interact with EPUB Publications through the accessibility APIs built into whichever platform they use (Windows, Mac, iOS, Linux, etc.). These APIs allow the Assistive Technology to communicate with the Reading System to read the text or control the interface, as needed.

Authors of static content do not have to worry about this interaction, as the user's Reading System exposes the necessary information to the accessibility APIs (provided it has been developed to be accessible). Authors who create EPUB Publications that contain dynamic content — such as scripting and custom controls — do need to pay attention to the compatibility of such content, as Assistive Technologies may not receive sufficient information to provide an accessible interface.

In the case of scripted content, the static picture of the content that an Assistive Technology initially generates will not get updated unless the Author follows the accessibility practices in [WAI-ARIA 1.1]. Similarly, although Assistive Technologies have access to information about native [HTML] form elements (e.g., buttons and inputs), Authors often create custom elements whose state is opaque without correct use of [WAI-ARIA 1.1] roles, state and properties  (e.g., checkboxes made out of images). Users want to know that such content has been made compatible with Reading System that support ARIA.

ARIA compatibility is identified in the [schema.org] accessibilityAPI property.

The following example shows that an EPUB Publication contains scripted content that is ARIA compatible.

<meta property="schema:accessibilityAPI">ARIA</meta>

Refer to the accessibilityAPI definition in [schema.org] for more information about this property and its values.

  META-007: Identify Input Control Methods

Not everyone who reads an EPUB Publication uses the same input control methods. Not only will the device affect the input method (e.g., mobile or desktop), but so will the user's physical abilities. Users might use any number of input methods, from touch to mice to keyboards to voice controls and on.

As a result, all users need to know what input controls work with the content, as it will affect not only whether they can operate the content but on what devices.

Similar to the accessibility APIs, the input control methods that can be used to read an EPUB Publication are greatly influenced by the accessibility of the Reading System. It is only when Authors include dynamic content that they assume a responsibility for ensuring that such is accessible to different input control methods.

Compatible input controls are identified in the [schema.org] accessibilityControl property. Repeat this property for each input control method.

The following example shows that an EPUB Publication contains content that is touch, mouse and keyboard compatible.

<meta property="schema:accessibilityControl">fullTouchControl</meta>
<meta property="schema:accessibilityControl">fullMouseControl</meta>
<meta property="schema:accessibilityControl">fullKeyboardControl</meta>

Refer to the accessibilityControl definition in [schema.org] for more information about this property and its values.

  Examples

The following examples show the metadata that would be added to an EPUB Publication that has textual and visual access modes, is sufficient for reading by text, contains alternative text and MathML markup, and has a flashing hazard.

EPUB 3

<package … >
   <metadata>
      …
      <meta property="schema:accessMode">textual</meta>
      <meta property="schema:accessMode">visual</meta>
      <meta property="schema:accessModeSufficient">textual,visual</meta>
      <meta property="schema:accessModeSufficient">textual</meta>
      <meta property="schema:accessibilityFeature">transcript</meta>
      <meta property="schema:accessibilityFeature">MathML</meta>
      <meta property="schema:accessibilityFeature">alternativeText</meta>
      <meta property="schema:accessibilityHazard">flashing</meta>
      <meta property="schema:accessibilityHazard">noMotionSimulationHazard</meta>
      <meta property="schema:accessibilityHazard">noSoundHazard</meta>
      <meta property="schema:accessibilitySummary">
         The video in chapter 2 presents a flashing hazard. A transcript is
         provided that covers all the essential information contained in the
         video. The publication otherwise meets WCAG 2.0 Level A.
      </meta>
   </metadata>
   …
</package>

EPUB 2

<package … >
    <metadata>
       …
       <meta name="schema:accessMode" content="textual"/>
       <meta name="schema:accessMode" content="visual"/>
       <meta name="schema:accessModeSufficient" content="textual,visual"/>
       <meta name="schema:accessModeSufficient" content="textual"/>
       <meta name="schema:accessibilityFeature" content="transcript"/>
       <meta name="schema:accessibilityFeature" content="MathML"/>
       <meta name="schema:accessibilityFeature" content="alternativeText"/>
       <meta name="schema:accessibilityHazard" content="flashing"/>
       <meta name="schema:accessibilityHazard" content="noMotionSimulationHazard"/>
       <meta name="schema:accessibilityHazard" content="noSoundHazard"/>
       <meta name="schema:accessibilitySummary" content="The video in chapter 2 presents a flashing hazard. A transcript is provided that covers all the essential information contained in the video. The publication otherwise meets WCAG 2.0 Level AA."/>
    </metadata>
    …
</package>

  4 WCAG Techniques

  4.1 General Guidance

Techniques for meeting the requirements of the [WCAG 2.0] are defined in [WCAG 2.0 Techniques]. This document does not repeat these techniques.

In general, the differences between the application of WCAG techniques to Web pages and their application to EPUB Content Documents is minimal, but the following sections outline some key differences.

One point to note is that the WCAG techniques cover a greater range of technologies and content types than are typically found in an EPUB Publication, so many are not applicable.

The following sets of techniques are the most broadly applicable to EPUB Content Documents:

General Techniques

HTML and XHTML Techniques

CSS Techniques

Client-Side Scripting Techniques

ARIA Techniques

Other techniques will apply depending on the technologies used (e.g., a [SWF] video in EPUB 2) or any alternative formats embedded in the EPUB Publication (e.g., a PDF form).

  Helpful Resources

Authors not familiar with [WCAG 2.0 Techniques] may find the number of techniques daunting, as they are intended to provide broad coverage of possible solutions.

Assistance applying these techniques to EPUB Content Documents is available from the following sources:

EPUB 3 Accessibility Guidelines — compendium of best practices by content type, with links to the applicable WCAG techniques.

BISG Quickstart Guide to Accessible Publishing — includes a set of top practices for making content accessible.

  4.2 Content Access

  ACCESS-001: Ensure linear reading order of the publication

[WCAG 2.0] Success Criterion 1.3.2 specifies that each Web page have a meaningful order, but the content of an EPUB Publication typically spans multiple documents. It is consequently essential not only that each EPUB Content Document has a meaningful order, but that the order is meaningful from document to document.

Authors need to ensure that all EPUB Content Documents are included in the spine [Packages] and put in sequence so that the reading order is preserved.

The following example shows the linear progression of chapter references in an EPUB spine.

<package …>
   …
   <manifest>
      …
      <item id="chap01" href="xhtml/chapter01.xhtml" …/>
      <item id="chap02" href="xhtml/chapter02.xhtml" …/>
      <item id="chap03" href="xhtml/chapter03.xhtml" …/>
      …
   </manifest>
   <spine>
      …
      <itemref idref="chap01"/>
      <itemref idref="chap02"/>
      <itemref idref="chap03"/>
      …
   </spine>
</package>

Authors also need to ensure that they identify whether items in the spine contain primary or supplementary information using the linear attribute [Packages] so that the Reading System can optimally present such content.

The following example shows a non-linear answer key between two chapters.

<spine>
   …
   <itemref idref="chap01"/>
   <itemref idref="answers01" linear="no"/>
   <itemref idref="chap02"/>
   …
</spine>

  ACCESS-002: Provide multiple ways to access the content

[WCAG 2.0] Success Criterion 2.4.5 requires there be more than one way to locate a Web page within a set of Web pages. By default, EPUB Publications meet this WCAG requirement so long as Authors follow the EPUB requirements to include all EPUB Content Documents in the spine and ensure access to all non-linear documents [Packages].

The reason an EPUB Publication passes by meeting these requirements has to do with differences in how a user interacts with the set of documents in an EPUB Publication. In particular, although an EPUB Publication typically consists of many Content Documents, Reading Systems automatically provide the ability for the user to move seamlessly from one document to the next, so long as they are listed in the spine [Packages]. To the user, an EPUB Publication is a single document they have complete access to, not a set of disconnected pages that they need links to move through.

The required table of contents provides a second method to access the major headings of the publication. The user can jump to any heading and continue to navigate from there, regardless of how the publication is chunked.

Following these two requirements therefore satisfies the need for multiple ways to access the content. Reading Systems also typically provide search capabilities, something the Author cannot provide, so users also have a third option available in most cases.

Although Authors only need to follow EPUB requirements to meet this criteria, they are still encouraged to provide additional methods to improve access beyond the minimum. Some suggestions include:

adding at least one link to every Content Document in the spine to the table of contents, when feasible;

adding an index to locate major topics;

adding additional navigation aids to the EPUB Navigation Document (e.g., lists of figures and tables).

  Note About the Table of Contents

A common question about the EPUB table of contents is what completeness it needs to have with respect to the headings of the publication. Although the obvious answer seems like it should be a simple aggregation of all headings for all sections, practically there are a number of usability challenges to this approach.

Factors such as device screen sizes can make the table of contents for publications with a deep hierarchy of headings unreadable, so Authors will trim headings below a certain depth to improve the readability. Further, Reading Systems do not always provide structured access to the headings in the table of contents, or provide shortcuts to navigate the links. The result is that users have to listen to each link one at a time to find where they want to go, a tedious and time-consuming process.

Although it is expected that Reading Systems will improve access to the table of contents as accessibility support for EPUB evolves — making complete tables of contents usable by everyone — there are legitimate usability reasons why they are not provided now.

When Authors choose not to provide links to all the headings, however, they should optimize the linking they do provide for the best overall reading experience. Some considerations on how to achieve this include:

ensuring that there is at least one link to every EPUB Content Document — allowing the user to reach each document simplifies navigation to the minor headings within them;

only omitting minor headings from the table of contents — although a subjective decision, there is often a level of diminishing value for navigation (e.g., fourth level and lower headings often only delimit short subsections on a topic).

  4.3 Semantics

  SEM-001: Include ARIA and EPUB semantics

The [WAI-ARIA 1.1] role attribute is used to provide additional semantic information about the host markup to Assistive Technologies. The use of roles allows Assistive Technologies to automatically scan the markup and compile a list of landmarks for users, enabling quick access to key features of the content. Authors can attach this attribute to any element.

The following example shows a generic landmark role. The name to use for this landmark is specified by the [WAI-ARIA 1.1] aria-labelledby attribute.

<section role="region" aria-labelledby="puz01">
   <h2 id="puz01">Puzzles and Games<h2>
   …
</section>

The role attribute is similar in nature to the type attribute [Content Docs], which provides additional semantic information to enable EPUB Reading System behaviors.

The following example shows the epub:type attribute used to provide additional semantic information.

<section epub:type="learning-objectives">
   <h2>Objectives<h2>
   …
</section>

The key difference between these attributes is that the role attribute bridges accessibility while the type attribute provides hooks to enable Reading System behaviors. Omitting roles lessens the accessibility for users of Assistive Technologies, in other words, while omitting types diminishes certain functionality in Reading Systems (e.g., pop-up footnotes or special presentations of the content).

Since each attribute offers different advantages, it is recommended that both be used whenever applicable to provide the best reading experience for all readers.

It is often the case that the attributes will have have corresponding semantics. In these situations, it is recommended that both attributes be attached to an element.

The following example shows a footnote identified in both the epub:type and role attributes.

<aside epub:type="footnote" role="doc-footnote">
   …
</aside>

  Helpful Resources

The following documents list the semantics that are available for use with each attribute:

The Digital Publishing WAI-ARIA Module [DPUB Vocab] provides a set of core publishing roles, but any roles from [WAI-ARIA 1.1] can be used in the role attribute.

The EPUB Structural Semantics Vocabulary [Structure Vocab] provides the default values that can be used with the type attribute, but the attribute is extensible to allow semantics from other vocabularies.

The following documents explain the application of ARIA roles for Authors already familiar with the use of the EPUB 3 type attribute for semantic inflection:

EPUB Type to ARIA Roles Authoring Guide — guide to notable authoring differences between the two attributes.

EPUB Structural Semantics to ARIA Roles Mapping Guide — mapping table of semantics in the EPUB Structural Semantics Vocabulary to equivalent ARIA roles in [DPUB Vocab] and [WAI-ARIA 1.1].

  SEM-002: Do not repeat semantics across chunked content

Although EPUB Publications appear as single contiguous documents to users when read, they are typically composed of many individual EPUB Content Documents. This practice keeps the amount of markup that has to be rendered small to reduce the load time in Reading Systems (i.e., to minimize the time the user has to wait for a document to appear). It is rare, at least for books, for an EPUB Publication to contain only one Content Document with all the content in it.

When content is chunked in this way, it often requires the Author to make decisions about how best to restructure the information. A part, for example, will typically not include all the chapters that belong to it. The Author will instead separate the part heading from each chapter, putting each into a separate document.

Although visually these restructuring decisions can be hidden from readers, they impact the functionality of Assistive Technologies. In the case of [WAI-ARIA 1.1] roles, the result is that only the subset present in the currently-loaded EPUB Content Document are exposed to users. An Assistive Technology cannot provide a list of landmarks for the whole publication, as it cannot see outside the current document.

To counteract this destructuring effect, Authors sometimes think to re-add or re-identify structures in the belief that having this information in every document will be helpful to users (e.g., adding an extra [HTML] section element around a chapter to indicate it belongs to a part, or putting the part semantic on the body tag). All this practice does, however, is add repetition that is not only disruptive when reading, but can actually make the structure of the publication harder to follow. Authors are therefore advised not to attempt to rebuild structures in these ways.

For example, consider a book that has five parts and each part contains five chapters. Structurally, each chapter belongs to its part (i.e., is grouped with it), as in the following markup:

<section role="doc-part">
   <h1>Part 1</h1>

   <section role="doc-chapter">
      <h2>Chapter 1</h2>
      …
   </section>
   …
</section>

Since this would lead to a large content file, the part heading is typically split out into its own Content Document so that it will appear on its own page:

<html … >
   …
   <body role="doc-part">
      <h1>Part 1</h1>
   </body>
</html>

Each chapter is then separated into a separate Content Document:

<html … >
   …
   <body role="doc-chapter">
      <h2>Chapter 1</h2>
   </body>
</html>

It is not necessary to add a part wrapper to each chapter, as in the following example:

<html … >
   …
   <body role="doc-part">
      <section role="doc-chapter">
         <h2>Chapter 1</h2>
         …
      </section>
   </body>
</html>

Doing so introduces a new part landmark into each document, which will cause an Assistive Technology to inform the user that the landmark is available to navigate to.

  SEM-003: Include EPUB landmarks

[WAI-ARIA 1.1] landmarks are similar in nature to EPUB landmarks [Packages]: both are designed to provide users with quick access to the major structures of a document, such as chapters, glossaries and indexes. ARIA landmarks are compiled automatically by Assistive Technologies from the roles that have been applied to the markup, so Authors only need to follow the requirement to include roles for the landmarks to be made available to users.

Although automatic generation of ARIA landmarks simplifies authoring, it also means that ARIA landmarks are limited to how the EPUB Publication has been chunked up into Content Documents. An Assistive Technology can only present the landmarks available in the currently-loaded document; it cannot provide a complete picture of all the landmarks in a multi-document publication (see the previous section for more discussion about content chunking).

EPUB landmarks, on the other hand, are compiled by the Author prior to distribution, and are not directly linked to the use of the type attribute [Content Docs] in the content. They are designed to simplify linking to major sections of the publication in a machine-readable way, as Reading Systems do not scan the entire publication for landmarks, either. EPUB landmarks are typically not as numerous as ARIA landmarks, as Reading Systems only expose so many of these navigation aids.

Given these differences in application, however, it is important to include EPUB landmarks and not rely only on the presence of ARIA roles to facilitate navigation, and vice versa. Each aids navigation in its own way.

The EPUB specification does not require that Authors include a specific set of landmarks, but it is recommended to include a link to the start of the body matter as well as to any major reference sections (e.g., table of contents, endnotes, bibliography, glossary, index).

The following example shows the EPUB 3 landmarks as expressed in the EPUB Navigation Document.

<nav epub:type="landmarks">
   <ol>
      <li>
         <a epub:type="toc" href="toc.xhtml">
            Table of Contents
         </a>
      </li>
      <li>
         <a epub:type="bodymatter" href="chap01.xhtml">
            Start reading
         </a>
      </li>
      <li>
         <a epub:type="endnotes" href="notes.xhtml">
            Notes
         </a>
      </li>
      <li>
         <a epub:type="bibliography" href="bibliography.xhtml">
            Bibliography
         </a>
      </li>
      <li>
         <a epub:type="glossary" href="glossary.xhtml">
            Glossary
         </a>
      </li>
      <li>
         <a epub:type="index" href="index.xhtml">
            Index
         </a>
      </li>
   </ol>
</nav>

The following example shows the EPUB 2 landmarks as expressed in the Package Document guide element.

<guide>
   <reference type="toc" href="toc.xhtml" title="Table of Contents"/>
   <reference type="text" href="chap01.xhtml" title="Start reading"/>
   <reference type="endnotes" href="notes.xhtml" title="Notes"/>
   <reference type="bibliogrpahy" href="biblio.xhtml" title="Bibliography"/>
   <reference type="glossary" href="glossary.xhtml" title="Glossary"/>
   <reference type="index" href="index.xhtml" title="Index"/>
</guide>

  Helpful Resources

The following resources explain EPUB and ARIA landmarks in more detail.

EPUB 2 guide element

EPUB 3 landmarks nav

ARIA 1.1 landmarks

  4.4 Titles and Headings

  TITLES-001: Include publication and document titles

[WCAG 2.0] Success Criterion 2.4.2 requires that each Web page include a title. EPUB has a similar requirement for EPUB Publications: publications require a [DCMES] title element in the Package Document metadata. The [WCAG 2.0] requirement is not satisfied by the EPUB requirement, however.

When authoring an EPUB Publication each EPUB Content Document also requires a descriptive title that describes its content. If not provided, Assistive Technologies often will announce the name of the file to users.

The following example shows a title for an EPUB Content Document.

<html …>
   <head>
      <title>Chapter 1</title>
      …
   </head>
   <body>
      <h1>Chapter 1: Loomings</h1>
      …
   </body>
</html>

If the title includes structural context (e.g., the part heading a chapter belongs to, or the name of the publication), order the title such that the most precise description of the current document comes first.

The following example shows a structured title.

<html …>
   <head>
      <title>
         III. The Night Shadows —
         Book the First—Recalled to Life —
         A Tale of Two Cities
      </title>
      …
   </head>
   <body>
      <h1>III. The Night Shadows</h1>
      …
   </body>
</html>

For more information about titles, see Technique H25 [WCAG 2.0 Techniques].

  TITLES-002: Ensure numbered headings reflect publication hierarchy

To a user, an EPUB Publication appears as a single document that they read from beginning to end, even though the content is often split across numerous EPUB Content Documents. As a result, their natural expectation is that the headings reflect their position in the overall hierarchy of the publication, despite the publication not actually being a single document (e.g., if a part heading is expressed in an [HTML] h1 element, each chapter that belongs to the part will have an h2 heading).

[WCAG 2.0 Techniques] G141: Organizing a page using headings instructs Authors on correctly using numbered headings within a document, but with EPUB Publications the numbered headings also need to remain consistent across documents. Practically, this means that each EPUB Content Document does not have to begin with an h1 heading unless the first heading is a top-level heading — the first heading needs to have a numbered heading element that reflects its actual position in the publication.

Authors also to need chunk their content so that the first heading in a document always has the highest number. For example, if a document starts with an h3 heading, there shouldn't be an h2 heading later in the document (e.g., do not include the start of a new section with the trailing subsections of the previous). It is acceptable for there to be subsequent headings at the same level as the first (e.g., multiple subsections in one document could all have h3 headings).

The following example shows two consecutive EPUB Content Documents in a textbook. The first contains a section heading (h2) and the first two subsections (h3). The second contains the final two subsections (h3).

<html …>
   …
   <body>
      <section>
         <h2>Section 1.1 - Conquest</h2>

         <section>
            <h3>Section 1.1.1 - First Encounter</h3>
            …
         </section>

         <section>
            <h3>Section 1.1.2 - Tensions Rise</h3>
            …
         </section>
      </section>
   </body>
</html>

<html …>
   …
   <body>
      <section>
         <h3>Section 1.1.3 - War</h3>
         …
      </section>

      <section>
         <h3>Section 1.1.4 - Aftermath</h3>
         …
      </section>
   </body>
</html>

  4.5 Descriptions

  DESC-001: Include alternative text descriptions

[WCAG 2.0] Success Criterion 1.1.1 requires a text alternative for all non-text content. In the case of image content, the provision of alternative text (e.g., in an [HTML] alt attribute) is sufficient for meeting the requirements of the [EPUB Accessibility] specification.

Authors are strongly encouraged to include extended descriptions, but the utility of extended descriptions often depends on the needs of the user. Until the publishing ecosystem matures, making it easier for Authors to include extended descriptions and write them to optimally meet the needs of the greatest number of users, they are not required.

If extended descriptions are not included, note the omission in the accessibility summary.

note

The requirement for a text alternative does not apply to decorative images that contribute no information to the text. These are identified by an empty alt attribute.

caution

This guidance applies to the evaluation of EPUB Publications strictly for achieving conformance to the [EPUB Accessibility] specification. If an EPUB Publication is distributed in an environment where extended descriptions are required, this guidance for conformance will not be sufficient.

The use of alternative text as a sufficient description for all images may be removed in a future version of these techniques.

  Helpful Resources

The following documents provide guidance on including extended descriptions:

DIAGRAM Image Guidelines for EPUB 3 — recommendations for the inclusion of alternative text and extended descriptions.

  4.6 Text

  4.6.1 TEXT-001 - Use Unicode for text content

[WCAG 2.0] Success Criterion 1.1.1 requires that text equivalents be provided for all non-text content to meet Level A. In some regions (e.g., Asia), it is not uncommon to find images of individual text characters, despite the availability of Unicode character equivalents. This practice occurs for various reasons, such as ease of translation of older documents and for compatibility across Reading Systems.The use of images in most instances leads to the text not being accessible to non-visual users, however.

When individual characters are replaced by images, there is invariably a negative effect on text-to-speech playback, even when alternative text is provided (e.g., if single characters within a word are replaced by images, the word will not be read as a single unit of text). It is also problematic for visual users, as the images often scale poorly and the characters cannot be changed to different font families to meet user preferences.

The use of Unicode characters for all text content avoids this problem, allowing content to successfully meet the minimum requirement for Level A.

For compliance with Level AA, Authors are directed to Success Criterion 1.4.5 which further restricts the use of images of text to only a set of essential cases.

  4.7 Accessible Alternatives

As EPUB Publications can be composed of more than one Rendition, it is possible that different versions of the content will have different levels of accessibility. For example, an image-based version of the content that lacks alternative text or descriptions could be bundled with a WCAG-compliant text-based serialization. This type of accessible bundling is acceptable, as [WCAG 2.0] allows non-conforming content provided a conforming alternate version is available.

The [Multiple Renditions] specification defines a set of features for creating these types of EPUB Publications. In particular, it specifies a set of attributes that allow a Reading System to automatically select a preferred Rendition for the user, or to provide the user the option to manually select between the available options. This functionality technically meets the requirements of [WCAG 2.0] in terms of ensuring the user can access the accessible version.

In practice, however, the [Multiple Renditions] specification is not broadly supported in Reading Systems at the time of publication. As a result, a user who obtains an EPUB Publication that contains more than one Rendition will only have access to the Default Rendition. Unless this Rendition is the accessible one, the EPUB Publication might not be readable by them.

Authors therefore need to use their best discretion when implementing this functionality to meet accessibility requirements. EPUB Publications that contain multiple renditions are conformant to the [EPUB Accessibility] specification if at least one Rendition meets all the content requirements, but Authors at a minimum need to note that a Reading System that supports multiple renditions is required in their accessibility summary. Any other methods the Author can use to make this dependence known is advisable (e.g., in the distribution metadata).

This section will be updated with techniques for using multiple renditions when there is enough support in Reading Systems to broadly recommend their use.

  5 EPUB Techniques

  5.1 Page Markers

  PAGE-001: Provide page break markers

Both the EPUB Structural Semantics Vocabulary [Structure Vocab] and Digital Publishing WAI-ARIA 1.0 Module [DPUB Vocab] include a semantic for static page breaks: pagebreak and doc-pagebreak, respectively.

It is recommended that both semantics be applied to EPUB 3 content to ensure maximum compatibility with Reading Systems and Assistive Technologies.

The following example shows an HTML5 span element identified as a pagebreak.

<span id="page001" title="1" epub:type="pagebreak" role="doc-pagebreak"/>

A title or aria-label attribute is required on the element, as it provides the value that is announced to the user. Do not include the page number as text content, as this practice forces the user to hear it announced wherever it occurs (e.g., without any context in the middle of a sentence).

EPUB 2 does not include markup to identify static page break marks in the content. Page break destinations can be included to enable hyperlinking, but the page list is the only way a user can jump to the locations.

The following example shows an XHTML 1.1 span element used as a hyperlink destination.

<span id="page001"/>

Do not use the [HTML] a element to identify page break locations in EPUB 3 Publications. Although this element was previously defined as the anchor for a hyperlink destination, its purpose has been changed in [HTML] for use solely as a link.

  PAGE-002: Identify pages in audio playback

Readers rarely stop reading to review each new page number, so when page numbers are read aloud in the audio playback of a publication it is not only distracting, but can be confusing, as well (e.g., the number could be read out in the middle of a sentence).

To mitigate this potential annoyance to readers, Authors need to identify page announcements in the EPUB 3 media overlays document when they are included. Identification allows a Reading System to provide a playback experience where the numbers are automatically skipped.

To identify page numbers in EPUB 3 Publications, attach an epub:type attribute with the value "pagebreak" [Structure Vocab] to each par element [Media Overlays] that identifies a page number in the media overlay documents.

The following example shows a page number identified in a media overlays document.

<smil xmlns="http://www.w3.org/ns/SMIL"
      xmlns:epub="http://www.idpf.org/2007/ops"
      version="3.0">
    <body>
        <!-- a paragraph -->
        <par id="id1">
            <text src="chapter1.xhtml#para1"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:23:22.000"
                   clipEnd="0:24:15.000"/>
        </par>

        <!-- a page number -->
        <par id="id2" epub:type="pagebreak">
            <text src="chapter1.xhtml#pgbreak1"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:24:15.000"
                   clipEnd="0:24:18.123"/>
        </par>

        <!-- another paragraph -->
        <par id="id3">
            <text src="chapter1.xhtml#para2"/>
            <audio src="chapter1_audio.mp3"
                   clipBegin="0:24:18.123"
                   clipEnd="0:25:28.530"/>
        </par>
    </body>
</smil>

Note that as EPUB 2 does not provide text and audio synchronization, this technique does not apply.

  PAGE-003: Provide a page list

A page list — a list of hyperlinks to the static page break locations — is the most effective way for users to find static page locations. Without a page list, the user would have to navigate each page marker in the text, provided they are available and the Reading System provides such functionality.

When a page list is included, Reading Systems can provide users direct access to the list or use it to provide automatic page jump functionality.

The EPUB Navigation Document allows the inclusion of a page-list nav [Packages], while the EPUB 2 NCX file provides the same functionality through the pageList element [OPF2].

The following example shows an EPUB 3 page-list nav element that contains a list of links to the static page breaks.

<nav epub:type="page-list">
   <ol>
      <li><a href="georgia.xhtml#page001">1</a></li>
      <li><a href="georgia.xhtml#page002">2</a></li>
      <li><a href="georgia.xhtml#page003">3</a></li>
      …
   </ol>
</nav>

The following example shows an EPUB 2 NCX that contains a list of page break locations in its pageList.

<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/"
     version="2005-1"
     xml:lang="en-US">
   …
   <pageList>
      <pageTarget id="p1" type="normal" value="1">
         <navLabel><text>1</text></navLabel>
         <content src="content.html#p001"/>
      </pageTarget>
      <pageTarget id="p2" type="normal" value="2">
         <navLabel><text>2</text></navLabel>
         <content src="content.html#p002"/>
      </pageTarget>
   </pageList>
</ncx>

  PAGE-004: Identify the pagination source

Users typically want to know the source of the page break markers included in an EPUB Publication when they are derived from a static media. Considerations like which printing, by which publisher or imprint, and whether the pagination comes from the hard or soft cover edition will affect decisions about its usefulness (e.g., does it exactly match the pagination of a print book used in a classroom).

To allow users to determine the suitability of the pagination, identify the ISBN of the source work in the Package Document metadata.

The following example shows a dc:source element containing the ISBN of the print source of pagination. This example is valid for both EPUB 2 and 3.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
   …
   <dc:source>urn:isbn:9780375704024</dc:source>
   …
</metadata>

If an ISBN is not available, include as much information as possible about the source publication (e.g., the publisher, date, edition, and binding).

The following example shows a dc:source element containing a text description of the source.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
   …
   <dc:source>ACME Publishing, 1945, 2nd Edition, Softcover</dc:source>
   …
</metadata>

If the page break markers are unique to the EPUB Publication, do not identify a print source.

  6 Distribution Techniques

  DIST-001: Do not restrict access through digital rights management

EPUB Publications typically require preservation of the publisher's and author's intellectual property when distributed (e.g., so that they can be made available for individual sale through online bookstores or distributed through library systems). The most common way to address this need has been through the application of digital rights management (DRM) schemes to the packaged EPUB Publication. DRM enables a variety of security features that aren't native to the EPUB format, such as the ability to limit access to a single user and to limit the length of time the person can access the publication (e.g., library loans).

In general, DRM can be made to work interoperably with Assistive Technologies, but problems arise when DRM restrictions remove direct access to an EPUB Publication or restrict access to the content within it. Unless the Reading System implementing the DRM provides API level access to the content, it can prove difficult, or even impossible, to generate text-to-speech playback, or for a refreshable braille display to have access to the underlying text, as well as cause other accessibility issues.

The application of digital rights management therefore must not impair or impede the functionality of Assistive Technologies on EPUB Publications users have the right to access.

  DIST-002: Include accessibility metadata in distribution records

When an EPUB Publication is ingested into a distribution system, such as a bookstore or library, a metadata record is often provided separately to the distributor. In these scenarios, the metadata used to enable discovery of the publication typically comes from the distribution record alone, not from the metadata in the Package Document.

The result is that it is necessary to include as much accessibility metadata in distribution records as their vocabularies allow.

note

The use of distribution records does not remove the requirement to include accessibility metadata in the Package Document. The metadata in the Package Document ensures accessibility information is always available with the publication.

The following example shows an ONIX record with accessibility metadata that states that the EPUB Publication has no accessibility features disabled (10), a table of contents (11) and a correct reading order (13).

<ONIXMessage release="3.0">
   <Header>
      …
   </Header>
   <Product>
      …
      <DescriptiveDetail>
         <ProductFormFeature>
            <ProductFormFeatureType>09</ProductFormFeatureType>
            <ProductFormFeatureValue>10</ProductFormFeatureValue>
         </ProductFormFeature>
         <ProductFormFeature>
            <ProductFormFeatureType>09</ProductFormFeatureType>
            <ProductFormFeatureValue>11</ProductFormFeatureValue>
         </ProductFormFeature>
         <ProductFormFeature>
            <ProductFormFeatureType>09</ProductFormFeatureType>
            <ProductFormFeatureValue>13</ProductFormFeatureValue>
         </ProductFormFeature>
      </DescriptiveDetail>
      …
      <TitleDetail>
         <TitleType>01</TitleType>
         <TitleElement>
            <TitleElementLevel>01</TitleElementLevel>
            <TitleText>Accessible EPUB 3</TitleText>
         </TitleElement>
      </TitleDetail>
      …
   </Product>
</ONIXMessage>

  Helpful Resources

See the following resources for more information about including accessibility metadata in distribution records:

Accessibility Metadata Crosswalk

ONIX Code List 196

  Acknowledgements and Contributors

This section is informative

EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.

The EPUB Accessibility specification and techniques were prepared by the International Digital Publishing Forum’s EPUB Maintenance Working Group, operating under a charter approved by the membership in July 2015, under the leadership of:

Gylling, Markus (International Digital Publishing Forum) Chair (until August 2016)

Siegman, Tzviya (John Wiley & Sons) Chair

Conboy, Garth (Google Inc.) Vice-chair; Chair (beginning August 2016)

Duga, Brady (Google Inc.) Vice-chair

Work on these documents was undertaken by an accessibility subgroup led by:

LaPierre, Charles ( Benetech )

Singh, Avneesh ( DAISY Consortium )

Active members of the working group included:

IDPF Members

Albert, Paolo (PubCoder)

Baker, Mike (Houghton Mifflin Harcourt)

Balakrishnan, Ramu (MPS Limited)

Cho, Yong-Sang (KERIS (Korea Education and Research Information Service))

Comerford, Rachel (Macmillan)

Cramer, Dave (Hachette Book Group)

Creasy, Keith (American Printing House for the Blind, Inc.)

Deltour, Romain (DAISY Consortium)

Geffroy, Jean-Marie (Mantano)

Gusso, Lina (Pearson)

Gylling, Markus (International Digital Publishing Forum (IDPF))

Hanson, Lauren (Kaplan Publishing)

Harris, Eric (VitalSource/Ingram Content Group)

Heinser, Bernhard (Access for All)

Johnson, Rick (VitalSource/Ingram Content Group)

Kasdorf, Bill (Apex CoVantage)

Keating, Patrick (Bluefire Productions)

Kennedy, Naomi (Penguin Random House)

Kerscher, George (DAISY Consortium)

LaPierre, Charles (Benetech)

Leo, Arthic (Amnet Systems)

Mietkiewicz, Elie (Gutenberg Technology)

Murata, Makoto (JEPA EPUB Study Group)

Mussinelli, Christina (Associazione Italiana Editori)

Prabhu, John (HOV Services)

Siegman, Tzviya (John Wiley & Sons)

Singh, Avneesh (DAISY Consortium)

Soiffer, Neil (Design Science)

Thurston, Jonathan (Pearson)

Webster, Amaya (Benetech)

Weck, Daniel (DAISY Consortium)

Invited Experts/Observers

Andrews, David

Bonelli, Giuseppe

Garrish, Matt

Kudou, Tomoyuki

Leva, Paolo

Marquès Solé, Daniel

McGlone, Jonathan

Morris, Julie

Munchenburger, Manfred

Rasmussen, Lloyd

Reddy, Ramesh

Rothberg, Madeleine

Sheehan, John

White, Jason

For more detailed acknowledgements and information about contributors to each version of EPUB, refer to Acknowledgements and Contributors [EPUB3 Overview].

  References

Normative References

[Content Docs] EPUB Content Documents 3 .

[DCMES] Dublin Core Metadata Element Set, Version 1.1 .

[DPUB Vocab] Digital Publishing WAI-ARIA Module 1.0 . Matt Garrish, et al.

[EPUB Accessibility] EPUB Accessibility .

[HTML] HTML .

[ISO24751-3] ISO/IEC 24751-3:2008 Information technology -- Individualized adaptability and accessibility in e-learning, education and training -- Part 3: "Access for all" digital resource description. 2008-10-01.

[Media Overlays] EPUB Media Overlays 3.1 .

[OPF2] Open Packaging Format 2.0.1 .

[Packages] EPUB Packages 3 .

[Structure Vocab] EPUB 3 Structural Semantics Vocabulary .

[WAI-ARIA 1.1] Accessible Rich Internet Applications (WAI-ARIA) 1.1 . Joanmarie Diggs, et al.

[WCAG 2.0] Web Content Accessibility Guidelines (WCAG) 2.0 . Ben Caldwell, et al.

[WCAG 2.0 Techniques] Techniques for WCAG 2.0. . Michael Cooper, et al.

[schema.org] schema.org.

Informative References

[EPUB3 Overview] EPUB 3.1 Overview .

[Multiple Renditions] EPUB Multiple-Rendition Publications 1.0 . 26 August 2015.

[SWF] SWF File Format Specification Version 19 . 2012.

[W3C Accessibility Note] Digital Publishing and Accessibility in W3C Documents . 03 May 2016.