Lỗi the selected layout has an invalid media configuration
|
EPUB® 3 defines a distribution and interchange format for digital publications and documents. The EPUB format provides a means of representing, packaging, and encoding structured and semantically enhanced web content — including HTML, CSS, SVG, and other resources — for distribution in a single-file container. This specification defines the authoring requirements for and represents the third major revision of the standard. Status of This DocumentThis section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/. This document was published by the EPUB 3 Working Group as a Recommendation using the . W3C recommends the wide deployment of this specification as a standard for the Web. A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to for implementations. Future updates to this Recommendation may incorporate . This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains must disclose the information in accordance with . This document is governed by the 2 November 2021 W3C Process Document. Table of ContentsThis section is non-normative. EPUB 3 has been widely adopted as the format for digital books (ebooks), and this revision continues to increase the format's capabilities to better support a wider range of publication requirements, including complex layouts, rich media and interactivity, and global typography features. The expectation is that publishers will utilize the EPUB 3 format for a broad range of content, including books, magazines, and educational, professional, and scientific publications. This specification represents the core of EPUB 3 and includes the conformance requirements for — the product of the standard. The other specifications that comprise EPUB 3 are as follows:
These specifications represent the formal list recognized as belonging to EPUB 3 and that contain functionality normatively referenced as part of the standard. The development of extension specifications periodically adds new functionality to EPUB publications. Features and functionality defined outside of core revisions to the standard, while not formally recognized in this specification, are nonetheless available for and reading system developers to use. The non-normative [] provides a general introduction to EPUB 3. A list of technical changes from the previous version is also available in the . This section is non-normative. This section reviews the organization of this specification through the central product it defines: the . An EPUB publication is, in its most basic sense, a bundle of resources with instructions on how to render those resources to present the content in a logical order. The types of resources that are allowed in EPUB publication, as well as restrictions on their use, are defined in . A ZIP-based archive with the file extension 00 bundles the EPUB publication's resources for distribution. 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 01 file), but also provides a universally named directory of non-normative resources ( 02). Key among these resources is the 9 file, which directs reading systems to the available . Refer to for more information about the container format. An EPUB publication is typically represented by a single package document. This document includes metadata used by to present the content to the user, such as the title and author for display in a bookshelf as well as rendering metadata (e.g., whether the content is reflowable or has a fixed layout). It also provides a manifest of resources and includes a that lists the default sequence in which to render documents as a user progresses through the content. Refer to for the requirements for the package document. The actual content of an EPUB publication — what users are presented with when they begin reading — is built on the Open Web Platform and comes in two flavors: XHTML and SVG. Called , these documents typically reference many additional resources required for their proper rendering, such as images, audio and video clips, scripts, and style sheets. Refer to for detailed information about the rules and requirements to produce EPUB content documents, and [] for accessibility requirements. An EPUB publication also includes another key file called the . This document provides critical navigation capabilities, such as the table of contents, that allow users to navigate the content quickly and easily. The navigation document is a specialized type of which also allows EPUB creators to use it in the content (i.e., avoiding one table of contents for machine processing and another for user consumption). Refer to for more information about this document. EPUB publications by default are intended to reflow to fit the available screen space. It is also possible to create publications that have pixel-precise fixed layouts using images and/or CSS positioning. The metadata to control layouts are defined in . 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 highlight the text as it is narrated. Refer to for the definition of media overlay documents. While conceptually simple, an EPUB publication is more than just a collection of HTML pages and dependent assets in a ZIP package as presented here. Additional information about the primary features and functionality that EPUB publications provide to enhance the reading experience is available from the referenced specifications, and a more general introduction to the features of EPUB 3 is provided in the non-normative []. Refer to [] for the processing requirements for reading systems. Although it is not necessary that read that document to create EPUB publications, an understanding of how reading systems present the content can help craft publications for optimal presentation to users. This section is non-normative. Caution The technologies EPUB 3 builds on are constantly evolving. Some, typically referred to as "living" or "evergreen" standards, are subject to change daily and their impact on the validity of EPUB publications is immediate. Others are updated less frequently and the changes may not affect until EPUB 3 undergoes a new revision. In all cases, it is possible that previously valid features may become obsolete (e.g., due to a lack of support or because of security issues). should therefore be cautious about using any feature without broad support and keep their up to date. The [] standard is continuously evolving — there are no longer versioned releases of it. That standard, in turn, references various technologies that continue to evolve, such as MathML, SVG, CSS, and JavaScript. The benefit of this approach for EPUB is that always keep pace with changes to the web without the need for new revisions. , however, must keep track of the various changes to HTML and the technologies it references to ensure they keep their processes up to date. The inherits all definitions of semantics, structure and processing behaviors from HTML unless otherwise specified. In addition, this specification to the [] document model that EPUB creators may include in . This specification does not reference a specific version of [], but instead uses an undated reference. Whenever there is any ambiguity in this reference, the latest recommended specification is the authoritative reference. This approach ensures that EPUB will always keep pace with changes to the SVG standard. , however, must keep track of changes to the SVG standard to ensure they keep their processes up to date. EPUB 3 supports CSS as defined by the CSS Working Group Snapshot []. EPUB 3 also maintains some prefixed CSS properties, to ensure consistent support for global languages. EPUB 3 only supports Presentation Markup []. Content Markup is only allowed in . This specification relies on a subset of [], from which the media overlays elements and attributes defined in are derived. This specification refers to the [] standard for terminology and processing related to URLs expressed in . It is anticipated that new and revised web formats will adopt this standard, but until then this may put this specification in conflict with the internal requirements for some formats (e.g., valid relative paths), specifically with respect to the use of internationalized URLs. If a format does not allow internationalized URLs (i.e., URLs must conform to [] or earlier), that requirement takes precedence within those resources. This specification defines the following terms specific to EPUB 3. Note Only the first instance of a term in a section links to its definition. codec Codec refers to content that has intrinsic binary format qualities, such as video and audio media types designed for optimum compression or that provide optimized streaming capabilities. container resource A that is located within the , as opposed to a which is not. Refer to for media type-specific rules for resource locations. container root URL The [] of the representing the . It is implementation specific, but EPUB creators must assume it has properties defined in . content URL The of a file or directory in the , defined in . core media type resource A that conforms to one of the MIME media types [] listed in and, therefore, does not require the provision of a (cf. ). The designation "core media type resource" only applies when a resource is used in the rendering of and . A core media type resource cannot be used in the , for example, without a fallback unless it also has the media type of an EPUB content document. EPUB conformance checker An application that verifies the requirements of this specification against and reports on their conformance. EPUB container OCF ZIP container The ZIP-based packaging and distribution format for defined in . EPUB container and OCF ZIP container are synonymous. EPUB content document A referenced from the or a that conforms to either the or definitions. EPUB content documents contain all or part of the content of an (i.e., the textual, visual and/or audio content). can include EPUB content documents in the spine without the provision of . EPUB creator An individual, organization, or process that produces an . Note The creation of an EPUB publication often involves the work of many individuals, and may be split across multiple organizations (e.g., when a publisher outsources all or part of the work). Depending on the process used to produce an EPUB publication, responsibilities may fall on the organization (e.g., the publisher), the individuals preparing the publication (e.g., technical editors), or automatic procedures (e.g., as part of a publication pipeline). As a result, not every party or process may be responsible for ensuring every requirement is met, but there is always an EPUB creator responsible for the conformance of the final EPUB publication. Previous versions of this specification referred to the EPUB creator as the Author. EPUB manifest (or manifest) The section of the that lists the . Refer to for more information. EPUB navigation document A specialization of the that contains human- and machine-readable global navigation information. The EPUB navigation document conforms to the constraints expressed in . EPUB publication A logical document entity consisting of a set of interrelated packaged in an . An EPUB publication typically represents a single intellectual or artistic work, but this specification does not restrict the nature of the content. EPUB reading system (or reading system) A system that processes for presentation to a user in a manner conformant with this specification. EPUB spine (or spine) The section of the that defines an ordered list of and . This list represents the default reading order of the . Refer to for more information. exempt resource Exempt resources are a special class of that reading systems are not required to support the rendering of, but do not have to provide for. Refer to for more information. file name The name of any type of file within an , whether a directory or a file within a directory. file path The file path of a file or directory is its full path relative to the , as defined by the algorithm specified in . fixed-layout document An with fixed dimensions directly referenced from the . Fixed-layout documents are designated 06 in the , as defined in . foreign content document Any referenced from a When a foreign content document is referenced from a spine 5 element, it requires a manifest fallback chain with at least one EPUB content document. Note With the exception of XHTML and SVG, all are foreign content documents when referenced directly from the spine. foreign resource A with a MIME media type [] that does not match any of those listed in . Foreign resources are subject to the fallback requirements defined in . The designation "foreign resource" only applies to resources used in the rendering of and . Note Foreign resource and foreign content document are not interchangeable terms. The types of resources considered foreign when used in the spine is greater than the types of resources considered foreign when used in . linked resource A resource that is only referenced from a Linked resources are not but may be stored in the . They do not require fallbacks. media overlay document An XML document that associates the with pre-recorded audio narration to provide a synchronized playback experience, as defined in . 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 , as defined in . package document A that describes the rendering of an , as defined in . The package document carries meta information about the EPUB publication, provides a manifest of resources, and defines a default reading order. publication resource A resource that contains content or instructions that contribute to the logic and rendering of an . In the absence of this resource, may not render the EPUB publication as the intends. Examples of publication resources include the , , CSS Style Sheets, audio, video, images, embedded fonts, and scripts. EPUB creators must list publication resources in the package document and typically bundle them all in the (the exception being they may locate resources listed in outside the EPUB container). Note Resources on the web identified in outbound hyperlinks (e.g., referenced from the 3 attribute of an [] 11 element) are not publication resources. are also not publication resources — they are considered part of the resource they are embedded in. remote resource A that is located outside of the , typically, but not necessarily, on the web. Publication resources within the EPUB container are referred to as . Refer to for media type specific rules for resource locations. root directory The root directory represents the base of the file system. This directory is . scripted content document An that includes scripting or an that contains [] 12 elements. Refer to for more information. SVG content document An that conforms to the constraints expressed in . synthetic spread The rendering of two adjacent pages simultaneously on a device screen. top-level content document An or referenced from the , whether directly or via a . unique identifier The primary identifier for an . The unique identifier is the of the Significant revision, abridgement, etc. of the content requires a new unique identifier. viewport The region of an in which an is rendered visually to a user. XHTML content document An that conforms to the profile of [] defined in . XHTML content documents use the defined in []. As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [] [] when, and only when, they appear in all capitals, as shown here. All algorithm explanations are non-normative. This section is non-normative. In metadata examples, are used without declaration. References to Dublin Core elements [] use the 15 prefix. This prefix must be declared in the for their use to be valid ( 16) The 17 namespace prefix [] is also used on elements and attributes without always having an explicit declaration ( 18). An :
In addition, all publication resources MUST adhere to the requirements in . The rest of this specification covers specific conformance details. This section is non-normative. Due to the complexity of this specification and number of technologies used in , are advised to use an to verify the conformance of their content. EPUBCheck is the de facto EPUB conformance checker used by the publishing industry and has been updated with each new version of EPUB. It is integrated into a number of authoring tools and also available in alternative interfaces and other languages (for more information, refer to its Apps and Tools page). When verifying their EPUB publications, EPUB creators should ensure they do not violate the requirements of this specification (practices identified by the keywords "MUST", "MUST NOT", and "REQUIRED"). These types of issues will often result in EPUB publications not rendering or rendering in inconsistent ways. These issues are typically reported as errors or critical errors. EPUB creators should also ensure that their EPUB publications do not violate the recommendations of this specification (practices identified by the keywords "SHOULD", "SHOULD NOT", and "RECOMMENDED"). Failure to follow these practices does not result in an invalid EPUB publication but may lead to interoperability problems and other issues that impact the user reading experience. These issues are typically reported as warnings. Note Vendors, distributors, and other retailers of EPUB publications should consider the importance of recommended practices before basing their acceptance or rejection on a zero-issue outcome from an EPUB conformance checker. There will be legitimate reasons why EPUB creators cannot follow recommended practices in all cases. This section is non-normative. An is made up of many different categories of resources, not all of which are mutually exclusive. Some resources are , some are not. Some publication resources are allowed in the by default, while all others require fallbacks. Some resources can be used in rendering , while others can only be used with fallbacks. Trying to understand these differences by reading the technical definitions of each category of resource can be complex. To make the categorizations easier to understand, this introduction uses the concept of different planes to explain how resources are grouped and referred to. The three planes are:
The same resource may exist on more than one plane and will be referred to differently in this specification depending on which plane is being discussed. For example, a core media type resource used in the rendering of an EPUB content document (on the content plane) may also be a foreign content document if it is also listed in the spine (the spine plane). The following sections describe these planes in more detail. Note Refer to for a detailed example showing how resources fit into the different planes. To manifest plane defines all the resources of an . It is analogous to the , but includes resources not present in that list. The primary resources in this group are designated , which are all the resources used in rendering an EPUB publication to the user. always have to list these resources in the Publication resources are further classified by their use(s) in the and . The manifest plane also contains a set of . These resources are tangential to the direct rendering. They include, for example, metadata records and links to external content (e.g., where to purchase an EPUB publication). Unlike publication resources, they are not listed in the package document manifest (i.e., because they are not essential to rendering the EPUB publication). They are instead defined in Refer to for more information about linked resources. Resources in the manifest plane are also sometimes broken down by where they are located. Although most publication resources have to be located in the EPUB container (called ), EPUB 3 allows to be hosted outside the container. These exceptions were made to speed up the download and loading of EPUB publications, as these resources are typically quite large, and, in the case of fonts, not essential to the presentation. When remotely hosted, these publication resources are referred to as . Since linked resources are not essential to the rendering of an EPUB publication, there are no requirements on where they are located and consequently no special naming of them based on their location. They may be located within the EPUB container or outside it. Note Hyperlinked content outside the EPUB container (e.g., web pages) are not publication resources, and consequently are not listed in the manifest. Reading systems will normally open these links in a separate browser instance, not as part of the EPUB publication. The spine plane defines resources used in the default reading order established by the , which includes both . The spine instructs on how to load these resources as the user progresses through the . Although many resources may be bundled in an , they are not all allowed by default in the spine. EPUB 3 defines a special class of resources called that can use in the spine without any restrictions. EPUB content documents encompass both and . To use any other type of resource in the spine, called a , requires including a fallback to an EPUB content document. This extensibility model allows EPUB creators to experiment with formats while ensuring that reading systems are always able to render something for the user to read, as there is no guarantee of support for foreign content documents. A mechanism called allows EPUB creators to provide fallbacks for foreign content documents. In this model, the entry for the foreign content document must include a that points to the next possible resource for reading systems to try when they do not support its format. Although not common, a fallback resource can specify another fallback, thereby making chains many resources deep. The one requirement is that there must be at least one EPUB content document in a . Although they are not directly listed in the spine, all of the resources in the fallback chain are considered part of the spine, and by extension part of the spine plane, since any may be used by a reading system. Refer to for more information. Caution Although manifest fallbacks fulfill the technical requirements of EPUB, there is little practical support for them in reading systems. Their use is strongly discouraged as it can lead to unreadable publications. Note It is possible to provide manifest fallbacks for EPUB content documents, but this is not required or common. For example, a could have a fallback to an unscripted alternative for reading systems that do not support scripting. The content plane classifies resources that are used when rendering and . These types of resources include embedded media, CSS style sheets, scripts, and fonts. These resources fall into three categories based on their reading system support: , , and . A core media type resource is one that have to support, so it can be used without restriction in EPUB or foreign content documents. For more information about core media type resources, refer to . Note Being a core media type resource does not mean that reading systems will always render the resource, as not all reading systems support all features of EPUB 3. A reading system without a , for example, will not render visual content such as images. The opposite of core media type resources are foreign resources. These are resources that reading systems are not guaranteed to support the rendering of. As a result, similar to how using foreign content documents in the spine requires fallbacks to ensure their rendering, using foreign resources in content documents also requires fallbacks. These fallbacks are provided in one of two ways: using the capabilities of the host format or via manifest fallbacks. The preferred method is to use the fallback capabilities of the host format. Many HTML elements, for example, have intrinsic fallback capabilities. One example is the 24 element [], which allows to specify multiple alternative image formats. If an intrinsic fallback method is not available, it is also possible to use manifest fallbacks, but this method, as in the previous section, is discouraged. For more information about foreign resources, refer to . Falling between core media type resources and foreign resources are exempt resources. These are most closely associated with foreign resources, as there is no guarantee that reading systems will render them. But like core media types, they do not require fallbacks. Exempt resources tend to address specific cases for which there are no core media types defined, but for which providing a fallback would prove cumbersome or unnecessary. These include embedding video, adding accessibility tracks, and linking to resources from the [] element. Refer to for more information about these exceptions. Note A common point of confusion arising from core media type resources is the listing of XHTML and SVG as core media type resources with the requirement the markup conform to their respective EPUB content document definitions. This allows EPUB creators to embed both XHTML and SVG documents in EPUB content documents while keeping consistent requirements for authoring and reading system support. In practice, it means that EPUB creators can put XHTML and SVG core media type resources in the spine without any modification or fallback (they are also conforming XHTML and SVG content documents), but this is a unique case. All other core media type resources become foreign content documents when used in the spine (i.e., foreign content documents include all foreign resources and all core media type resources except for XHTML and SVG). MAY include that conform to the MIME media type [] specifications defined in the following table without fallbacks when they are used in and . These resources are classified as . With the exception of and , EPUB creators MUST provide for core media type resources referenced directly from the . In this case, they are . The columns in the table represent the following information:
26 [] GIF Images 27 [] JPEG Images 28 [] PNG Images 29 SVG documents 30 [], [] WebP Images Audio 31 [] MP3 audio 32 [], [] AAC LC audio using MP4 container 33 [] OPUS audio using OGG container Style 34 CSS Style Sheets. Fonts
42 [] WOFF2 fonts Other 43 HTML documents that use the [].
47 [] The NCX. 48 EPUB media overlay documents Note Inclusion as a core media type resource does not mean that all reading systems will support the rendering of a resource. Reading system support also depends on the capabilities of the application (e.g., a reading system with a must support image core media type resources, but a reading system without a viewport does not). Refer to [] for more information about which reading systems rendering capabilities require support for which core media type resources. The Working Group typically only includes formats as core media type resources when they have broad support in web browser cores — the rendering engines that EPUB 3 reading systems build upon. They are an agreement between reading system developers and EPUB creators to ensure the predictability of rendering of EPUB publications. A , unlike a is one which is not guaranteed support when used in an or . MUST provide fallbacks for foreign resources, where fallbacks take one of the following forms:
Note Refer to the [] and [] specifications for the intrinsic fallback capabilities their elements provide. also provides additional information about how fallbacks are interpreted for specific elements. An shares properties with both and . It is most similar to a in that it is not guaranteed support, but, like a core media type resource, does not require a fallback. There are only a small set of special cases for exempt resources. Video, for example, are exempt from fallbacks because there is no consensus on a core media type video format at this time (i.e., there is no format to fallback to). Similarly, audio and video tracks are exempt to allow to meet accessibility requirements using whatever format reading systems support best. The following list details cases of content-specific exempt resources, including any restrictions on where EPUB creators can use them. Fonts All font resources not already covered as are exempt resources. This exemption allows EPUB creators to use any font format without a fallback, regardless of reading system support expectations, as CSS rules will ensure a fallback font in case of no support. Refer to the [] for more information. Linked resources Any resource referenced from the [] element that is not already a core media type resource (e.g., CSS style sheets) is an exempt resource. Tracks All audio and video tracks (e.g., [] captions, subtitles and descriptions) referenced from the [] 51 element are exempt resources. Video All video codecs referenced from the [] 52 — including any child 53 elements — are exempt resources. Note Although reading systems are encouraged to support at least one of the H.264 [] and VP8 [] video codecs, support for video codecs is not a conformance requirement. EPUB creators must consider factors such as breadth of adoption, playback quality, and technology royalties when deciding which video formats to include. Note The exemptions made above do not apply to the . If an exempt resource is used in the spine, and it is not also an , it will require a fallback in that context. In addition to the content-specific exemptions, a resource is classified as an exempt resource if:
This exemption allows EPUB creators to include resources in the that are not for use by EPUB reading systems. The primary case for this exemption is to allow data files to travel with an , whether for scripts to use in their constituent EPUB content documents or for external applications to use (e.g., a scientific journal might include a data set with instructions on how to extract it from the EPUB container). It also allows EPUB creators to use foreign resources in foreign content documents without reading systems or having to understand the fallback capabilities of those resources (i.e., the requirement for a fallback for the foreign content document covers any rendering issues within it). As the resource is not referenced from an EPUB content document, it automatically becomes exempt from fallbacks. Manifest fallbacks are a feature of the that create a manifest fallback chain for a , allowing to select an alternative format they can render. Fallback chains are created using the on 2 that is a fallback for the current 2. The ordered list of all the references that a reading system can reach, starting from a given 2's 23 attribute, represents the full fallback chain for that 2. This chain also represents the preferred fallback order. There are two cases for manifest fallbacks: Spine fallbacks EPUB creators MUST specify a fallback chain for a to ensure that reading systems can always render the item. In this case, the chain MUST contain at least one . EPUB creators MAY provide fallbacks for EPUB content documents (e.g., to provide a ). When a fallback chain includes more than one EPUB content document, EPUB creators can use the to differentiate the purpose of each. Content fallbacks Note The original purpose for content fallbacks was to specify fallback images for the [] 65 element. As HTML now has intrinsic fallback mechanism for images, the use of content fallbacks is strongly discouraged. EPUB creators should always use the intrinsic fallback capabilities of [] and [] to provide fallback content. EPUB creators MUST provide a content fallback for when the elements that reference them do not have intrinsic fallback capabilities. In this case, the fallback chain MUST contain at least one . EPUB creators MAY also provide manifest fallbacks for core media type resources (e.g., to allow reading systems to select from more than one image format). Regardless of the type of manifest fallback specified, fallback chains MUST NOT contain self-references or circular references to 2 elements in the chain. Note As it is not possible to use manifest fallbacks for resources represented in , EPUB creators can only represent foreign resources as data URLs where an intrinsic fallback mechanism is available. The following sections provide additional clarifications about the intrinsic fallback requirements of specific elements. MUST NOT use embedded [] within a (i.e, or ) as an intrinsic fallback for audio . Only child 53 elements [] provide intrinsic fallback capabilities. Only older that do not recognize the 3 or the 4 elements (e.g., EPUB 2 reading systems) will render the embedded content. When reading systems support these elements but not the available media formats, they do not render the embedded content for the user. Note The requirement for fallbacks only applies to audio foreign resources referenced from 3 and 4 elements. Fallbacks are not required for video resources; they are . Due to the variety of sources that can specify in the [] 65 element, the following fallback conditions apply to its use:
Although data blocks have a separate MIME media type [] from their containing , it is not possible to provide intrinsic fallbacks as no such mechanisms are specified for the [] 84 element. It is also not possible to provide manifest fallbacks because data blocks cannot be defined as standalone files in the EPUB container but are always embedded as inline 6 elements. But, as the 6 element does not represent user content — are not rendered unless manipulated by script, and content rendered by scripts already has — requiring fallbacks for the raw data does not serve a useful purpose. Consequently, to ensure that can include data blocks for scripting purposes, they are exempt from fallback requirements. Note [] does not define data blocks as of publication, but the same exclusion would apply if a future update adds the concept. MAY host the following types of outside the :
EPUB creators MUST store all other resources within the EPUB container. Storing all resources inside the EPUB container is strongly encouraged whenever possible as it allows users access to the entire presentation regardless of connectivity status. When resources have to be located outside the EPUB container, EPUB creators are RECOMMENDED to reference them via the secure 87 URI scheme [rfc7230] to limit the threat of exposing their publications, and users, to network attacks. might not load referenced using insecure schemes such as 88. These rules for locating publication resource apply regardless of whether the given resource is a or a . The [] is used to encode resources directly into a URL string. The advantage of this scheme is that it allows to embed a resource within another, avoiding the need for an external file. EPUB creators MUST NOT use data URLs in the following scenarios where they can result in a or []:
Note These restrictions on the use of data URLs are to prevent security issues and also to ensure that can determine where to take a user next (i.e., because data URLs cannot be referenced from the ). The list of prohibited uses for data URLs is subject to change as the respective standards that allow their use evolve. A consequence of embedding is that the data in a data URL is not considered its own unique for manifest reporting purposes (i.e., only its containing publication resource gets listed). As this data has its own media type, however, it is still subject to . EPUB creators MUST therefore encode data URLs as or provide a fallback using the intrinsic fallback mechanisms of the host format. The is defined in [] as "identifying an object (a 'file') stored in a structured object naming and accessing environment on a host (a 'file system')." It is typically used to retrieve files from the local operating system. Using a file URL in an , which can be transferred among different hosts, represents a security risk and is also non-interoperable. As a consequence, MUST NOT use file URLs in EPUB publications. Any that is an XML-based media type []:
The above constraints apply regardless of whether the given publication resource is a or a . Note [] and [] are removing support for the XML 0 attribute []. EPUB creators should avoid using this feature. This section is non-normative. OCF is the required container technology for . OCF may play a role in the following workflows:
This section defines the rules for structuring the file collection in the abstract: the "abstract container". It also defines the rules for the representation of this abstract container within a ZIP archive: the "physical container". The rules for ZIP physical containers build upon the ZIP technologies used by []. OCF also defines a standard method for for those EPUB publications that require this functionality. This section is non-normative. The file system model uses a single common . All 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 7 that is a direct child of the root directory and stores the following special files: 9 05 Identifies one or more that define the . 0 07 Contains digital signatures for various assets. 5 07 Contains information about the encryption of . This file is mandatory when use . 8 07 Used to store metadata about the . 9 07 Used to store information about digital rights. 7 07 A manifest of container contents as allowed by Open Document Format []. Refer to for conformance requirements for the various files in the 7 directory. The virtual file system for the MUST have a single common for all the contents of the container. The OCF abstract container MUST include a directory for configuration files named 7 that is a direct child of the container's root directory. Refer to for the requirements for the contents of this directory. The file name 01 in the root directory is reserved for use by , as explained in . Files in the 7 directory and the 01 file are not so MUST NOT be listed in the . MAY locate all other files within the OCF abstract container in any location descendant from the root directory, provided they are not within the 7 directory. EPUB creators MUST NOT reference files in the 7 directory from an . In the context of the , and are [] (i.e., their values are case sensitive). In addition, the following restrictions are designed to allow file paths and file names to be used without modification on most operating systems:
Note If dynamically integrate resources (i.e., where the naming is beyond their control), they should be aware that automatic truncation of file names to keep them within the 255 bytes limit can lead to corruption. This is due to the difference between bytes and characters in multibyte encodings such as UTF-8; it is, therefore, important to avoid mid-character truncation. See the section on in [] for more information. Note EPUB creators should use an abundance of caution in their file naming when interoperability of content is key. The is intended to help avoid some known problem areas, but it does not ensure that all other Unicode characters are supported. Although Unicode support is much better now than in earlier iterations of EPUB, older tools and toolchains may still be encountered (e.g., ZIP tools that only support []). To derive the file path, given a file or directory file in the , apply the following steps (expressed using the terminology of []):
The is the [] of the . It is implementation-specific, but MUST assume it has the following properties:
The of a file or directory in the is the result of the file's with the container root URL as . Note The container root URL is the URL assigned by the to the root of the . It typically depends on how the reading system internally implements the container file system. However, a reading system cannot arbitrarily use any URL, but one that honors the constraints defined above. These constraints ensure that any relative URL string found in the EPUB will always be parsed to a URL of a resource within the container (which may or may not exist). The primary reason for these constraints is to avoid potential run-time security issues that would be caused by parsed URLs "leaking" outside the container files. For example, URLs like 59 or 60 honor these properties. But URLs like 61, 62, or 63 do not (parsing the URL string " 58" with these three examples as base would return 65, 66, and a parsing error, respectively). It is the responsibility of the reading system to assign a URL to the root directory that complies with the properties defined above. Note Parsing may replace some characters in the file path by their alternative. For example, 67 becomes 68. A string url is a valid-relative-ocf-URL-with-fragment string if it is a , optionally followed by 69 and a , and if the following steps return true:
In the OCF abstract container, any URL string MUST be an or a . In addition, all [] MUST, after , be equal to the content URL of an existing file in the OCF abstract container. Note These constraints on URL strings mean that:
Note that in any case, even the disallowed URL strings described above will not "leak" outside the container after parsing (as explained in the of this section). They are nevertheless disallowed for better interoperability with non-conforming or legacy reading systems and toolchains. All MUST include a directory called 7 in their . This directory is reserved for configuration files, specifically those defined in . To parse a URL string url used in files located in the 7 directory the MUST be applied to url, with the as . The REQUIRED 9 file in the 7 directory identifies the available in the . All [] elements defined in this section are in the 93 namespace [] unless specified otherwise. The contents of this file MUST be valid to the definition in this section after removing all elements and attributes from other namespaces (including all attributes and contents of such elements). Note An also informally defines the content of this file. The 0 element encapsulates all the information in the 9 file. Element Name: 0 Usage: REQUIRED [] of the 9 file. Attributes: 98 05 This attribute MUST have the value " 00". Content Model: In this order:
The 1 element contains a list of available in the . Element Name: 1 Usage: REQUIRED first child of Attributes: None Content Model:
Each 2 element identifies the location of one in the . Element Name: 2 Usage: As child of the Attributes: 10 05 Identifies the location of a package document. The value of the attribute MUST be a []. The path is relative to the . 5 05 Identifies the media type of the package document. The value of the attribute MUST be " 8". Content Model: Empty If an defines more than one 2 element, each MUST reference a package document that conforms to the same version of EPUB. Each package document represents one rendering of the . Note Although the EPUB container provides the ability to reference more than one package document, this specification does not define how to interpret, or select from, the available options. Refer to [] for more information on how to bundle more than one rendering of the content. The 3 element identifies resources necessary for the processing of the . Element Name: 3 Usage: OPTIONAL second child of Attributes: None Content Model:
Note This specification currently does not define uses for the 3 element. Refer to [] for an example of its use. Element Name: 4 Usage: As child of the Attributes: 3 05 Identifies the location of a resource. The value of the 4 element 3 attribute MUST be a []. The path is relative to the . 5 07 Identifies the type and format of the referenced resource. The value of the attribute MUST be a media type []. 29 05 Identifies the relationship of the resource. The value of the attribute MUST be a space-separated list of tokens. Content Model: Empty This section is non-normative. The OPTIONAL 5 file in the 7 directory holds all encryption information on the contents of the container. If an encrypts any resources within the container, they MUST include an 5 file to provide information about the encryption used. Element Name: 6 Namespace: 93 Usage: REQUIRED [] of the 5 file. Attributes: None Content Model: In any order: The 6 element contains child elements of type 37 and 38 as defined by []. An 37 element describes each encryption key used in the container, while an 38 element describes each encrypted file. Each 38 element refers to an 37 element, as described in XML Encryption. Note An also informally defines the content of the 5 file. 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 [] 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 may contain non-XML data, can use XML Encryption to encrypt all data in an . OCF encryption supports only the encryption of entire files within the container, not parts of files. EPUB creators MUST NOT encrypt the 5 file when present. Encrypted data replaces unencrypted data in an OCF abstract container. For example, if an EPUB creator encrypts an image named 48, they should replace the contents of the 48 resource with its encrypted contents. Within the ZIP directory, EPUB creators SHOULD store encrypted files rather than Deflate-compress them. Note that some situations require obfuscating the storage of embedded fonts referenced by an to make them more difficult to extract for unrestricted use. Although obfuscation is not encryption, reading systems use the 5 file in conjunction with the to identify fonts to deobfuscate. EPUB creators MUST NOT encrypt the following files:
EPUB creators MAY subsequently encrypt signed resources using the Decryption Transform for XML Signature []. This feature enables a to distinguish data encrypted before signing from data encrypted after signing. When stored in an , SHOULD compress streams of data with content types before encrypting them. EPUB creators MUST use Deflate compression. This practice ensures that file entries stored in the ZIP container have a smaller size. EPUB creators SHOULD NOT compress streams of data with content types before encrypting them. In such cases, additional compression introduces unnecessary processing overhead at production time (especially with large resource files) and impacts audio/video playback performance at consumption time. In some cases, the combination of compression with some encryption schemes might even compromise the ability of 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). When EPUB creators compress streams of data before encrypting, they SHOULD provide additional 59 metadata to specify the size of the initial resource (i.e., before compression and encryption), as per the 60 XML element defined below. When EPUB creators do not compress streams of data before encrypting, they MAY provide the additional 59 metadata to specify the size of the initial resource (i.e., before encryption). Element Name: 60 Namespace: 63 Usage: OPTIONAL child of 64. Attributes: Method 05 Identifies the compression method used. Value is either " 66" (no compression) or " 67" (Deflate algorithm). OriginalLength 05 Represents the size of the initial resource (number of bytes). Value is a positive integer. Content Model: Empty The OPTIONAL 7 file in the 7 directory provides a manifest of files in the container. The OCF specification does not mandate a format for the manifest. Note that specify the only manifests used for processing . Reading systems do not use this file. Note This feature exists only for compatibility with []. The OPTIONAL 8 file in the 7 directory is only for container-level metadata. If include a 8 file, they SHOULD use only namespace-qualified elements [] in it. The file SHOULD contain the [] 0 in the namespace 75, but this specification allows other root elements for backwards compatibility. This version of the specification does not define metadata for use in the 8 file. Future versions of this specification MAY define container-level metadata. This specification reserves the OPTIONAL 9 file in the 7 directory for the trusted exchange of among rights holders, intermediaries, and users. When do not include a 9 file, no part of the is rights governed at the container level. Rights expressions might exist within the EPUB publications. Note Adding a digital signature is not a guarantee that a malicious actor cannot tamper with an as do not have to check signatures. The OPTIONAL 0 file in the 7 directory holds digital signatures for the container and its contents. Element Name: 1 Namespace: 93 Usage: REQUIRED [] of the 84 file. Attributes: None Content Model: The 86 element contains child elements of type 85, as defined by []. can apply signatures 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). Note An also informally defines the content of the 0 file. When an EPUB creator does not include a 0 file, they are not signing any part of the at the container level. Digital signing might exist within the EPUB publication. When an EPUB creator creates a data signature for the OCF abstact container, they SHOULD add the signature as the last child 85 element of the 1 element. Note Each 85 in the 0 file identifies by URL [] the data to which the signature applies, using the [] 94 element and its 95 sub-elements. EPUB creator may sign individual container files separately or together. Separately signing each file creates a digest value for the resource that reading systems can validate independently. This approach might make a Signature element larger. If EPUB creators sign files together, they can list the set of signed files in a single XML Signature 94 element and reference them by one or more 85 elements. EPUB creators can sign any or all files in the OCF abstract container in their entirety, except for the 0 file since that file will contain the computed signature information. Whether and how EPUB creators sign the 0 file depends on their objective. If the EPUB creator wants to allow signatures to be added or removed from the OCF abstract container without invalidating their signature, they SHOULD NOT sign the 0 file. If the EPUB creator wants any addition or removal of a signature to invalidate their signature, they can use the Enveloped Signature transform defined in of [] to sign the entire pre-existing signature file excluding the 85 being created. This transform would sign all previous signatures, and it would become invalid if a subsequent signature were added to the package. Note If the EPUB creator wants the removal of an existing signature to invalidate their signature, but also wants to allow the addition of signatures, they could use an XPath transform to sign just the existing signatures. The details of such a transform are outside the scope of this specification, however. The [] 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 [] specification describes how additional information can be added to a signature, such as by use the 02 element. This section is non-normative. An is a physical single-file manifestation of an . The container allows:
An uses the ZIP format as specified by [], but with the following constraints and clarifications:
The following constraints apply to specific fields in the OCF ZIP container archive:
MUST include the 01 file as the first file in the . In addition:
Caution Better methods of protecting fonts exist. Both [] and [] fonts, for example, allow the embedding of licensing information and provide some protection through font table compression. The use of remotely hosted fonts also allows for font subsetting. are advised to use font obfuscation as defined in this section only when no other options are available to them. See also the . This section is non-normative. Since an 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 fonts is not a desired side-effect of not encrypting them. An 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 , 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 is insufficient to signify that the font cannot be reused in other contexts. This uncertainty can undermine the otherwise useful font embedding capability of EPUB publications. To discourage reuse of their fonts, some font vendors might only allow their use in EPUB publications if the 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 fonts. 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 fonts. This section is non-normative. This specification does not claim that obfuscation constitutes encryption, nor does it guarantee that the resource will be secure from copyright infringement. The hope is only that this algorithm will meet the requirements of vendors who require some assurance that their fonts cannot be extracted simply by unzipping the and copying the resource. Obfuscation, like any protection scheme, cannot fully protect fonts from being accessed in their deobfuscated state. The mechanism only provides an obstacle for those who are unaware of the license details. It will not prevent a determined user from gaining full access to the font through such alternative means as:
As a result, whether this method of obfuscation satisfies the requirements of individual font licenses remains a question for the licensor and licensee. are responsible for ensuring their use of obfuscation meets font licensing requirements. EPUB creators should also be aware that obfuscation may lead to interoperability issues in reading systems as reading systems are not required to deobfuscate fonts. As a result, the visual presentation of their publications may differ from reading system to reading system. Also note that the algorithm is restricted to obfuscating fonts. It is not intended as a general-purpose mechanism for obfuscating any resource in the EPUB container. MUST derive the key used in the obfuscation algorithm from the . All white space characters, as defined in [], MUST be removed from this identifier — specifically, the Unicode code points 19, 20, 21 and 22. EPUB creators MUST generate a SHA-1 digest of the UTF-8 representation of the resulting string as specified by the Secure Hash Standard []. They can then use this digest as the key for the algorithm. The algorithm employed to obfuscate fonts consists of modifying the first 1040 bytes (~1KB) of the font file. (In the unlikely event that the font file is less than 1040 bytes, this process will modify the entire file.) To obfuscate the original data, store, as the first byte of the embedded font, the result of performing a logical exclusive or (XOR) on the first byte of the raw font file and the first byte of the . Repeat this process with the next byte of source and key and continue for all bytes in the key. At this point, the process continues starting with the first byte of the key and 21st byte of the source. Once 1040 bytes are encoded in this way (or the end of the source is reached), directly copy any remaining data in the source to the destination. MUST obfuscate fonts before compressing and adding them to the . Note that as obfuscation is not encryption, this requirement is not a violation of the one in to compress fonts before encrypting them. The following pseudo-code exemplifies the obfuscation algorithm.
Although not technically encrypted data, all obfuscated fonts MUST have an entry in the 5 file accompanying the (see ). MUST specify an 38 element for each obfuscated font. Each 38 element MUST contain a child 28 element whose 29 attribute has the value 30. The presence of this attribute signals the use of the algorithm described in this specification. EPUB creators MUST list the path to the obfuscated font in the 31 child of the 32 element. As the obfuscation algorithm is restricted to fonts, the 33 attribute of the 31 element MUST reference a . To prevent trivial copying of the embedded font to other EPUB publications, EPUB creators MUST NOT provide the in the 5 file. All [] elements defined in this section are in the 36 namespace [] unless otherwise specified. This section is non-normative. The is an XML document that consists of a set of elements that each encapsulate information about a particular aspect of an . These elements serve to centralize metadata, detail the individual resources, and provide the reading order and other information necessary for its rendering. The following list summarizes the information found in the package document:
To parse a URL string url used in the , the [] MUST be applied to url, with the of the package document as base. This section provides definitions for shared attributes (i.e., attributes allowed on two or more elements). Note The 2 attribute is marked as often only support a single default directionality for text display. are still strongly encouraged to set the proper directionality of text values in the to ensure proper rendering once this situation improves. Specifies the [] of the textual content and attribute values of the carrying element and its descendants. Allowed values are:
Reading systems will assume the value 40 when EPUB creators omit the attribute or use an invalid value. Note The base direction specified in the 2 attribute does not affect the ordering of characters within directional runs, only the relative ordering of those runs and the placement of weak directional characters such as punctuation. Allowed on: A [] that references a resource. The URL string MUST NOT reference resources via elements in the package document (e.g., via a manifest Allowed on: The [] of the element, which MUST be unique within the document scope. Allowed on: A media type [] that specifies the type and format of the referenced resource. Allowed on: A space-separated list of values. Refer to each element's definition for the for the attribute. Allowed on: Establishes an association between the current expression and the element or resource identified by its value. MUST use as the value a , optionally followed by 69 and a that references the resource or element they are describing. The 7 attribute is OPTIONAL depending on the type of metadata expressed. When omitted, the element defines a . When creating expressions about a , the 7 attribute SHOULD specify a fragment identifier that references the [] of the resource's . Refinement chains MUST NOT contain circular references or self-references. Allowed on: Specifies the language of the textual content and attribute values of the carrying element and its descendants, as defined in section of []. The value of each 8 attribute MUST be a []. Allowed on: The 9 element encapsulates all the information expressed in the . Element Name: 9 Usage: REQUIRED [] of the package document. Attributes:
In this order:
The 98 attribute specifies the EPUB specification version to which the given conforms. The attribute MUST have the value " 32" to indicate conformance with EPUB 3. Note Updates to this specification do not represent new versions of EPUB 3 (i.e., each new 3.X specification is a continuation of the EPUB 3 format). The Working Group is committed to minimizing any changes that would invalidate existing content, allowing the 98 attribute value to remain unchanged. The 14 attribute takes an IDREF [] that identifies the The 0 attribute provides a declaration mechanism for prefixes not . Refer to for more information. The 0 element encapsulates meta information. Element Name: 0 Usage: REQUIRED first child of Attributes: None Content Model: In any order:
The 0 element has two primary functions:
The package document does not provide complex metadata encoding capabilities. If need to provide more detailed information, they can associate metadata records (e.g., that conform to an international standard such as [] or are created for custom purposes) using the In keeping with this philosophy, the package document only has the following minimal metadata requirements: it MUST contain the [] 60 property. All other metadata is OPTIONAL. The Note See [] for accessibility metadata recommendations. The Dublin Core elements [] and These elements MUST have non-empty values after [] is stripped (i.e., they must consist of at least one non-whitespace character). Whitespace within these element values is not significant. Sequences of one or more whitespace characters are [] during processing . The 1 element [] contains an identifier such as a UUID, DOI or ISBN. Element Name: 1 Namespace: 65 Usage: REQUIRED child of Attributes:
Text The MUST provide an identifier that is unique to one and only one — its — in an 1 element. This 1 element MUST specify an 4 attribute whose value is referenced from the Although not static, EPUB creators should make changes to the unique identifier for an EPUB publication as infrequently as possible. Unique Identifiers should have maximal persistence both for referencing and distribution purposes. EPUB creators should not issue new identifiers when making minor revisions such as updating metadata, fixing errata, or making similar minor changes. EPUB creators MAY specify additional identifiers. The identifiers should be fully qualified URIs. EPUB creators MAY use the to indicate that the value of a 1 element conforms to an established system or an issuing authority granted it. The 2 element [] represents an instance of a name for the . Element Name: 2 Namespace: 65 Usage: REQUIRED child of Attributes:
Text The first 2 element in document order is the main title of the EPUB publication (i.e., the primary one reading systems present to users). should use only a single 2 element to ensure consistent rendering of the title in . Note Although it is possible to include more than one 2 element for multipart titles, reading system support for additional 2 elements is inconsistent. Reading systems may ignore the additional segments or combine them in unexpected ways. For example, the following example shows a basic multipart title: The same title could instead be expressed using a single 2 element as follows: Previous versions of this specification recommended using the and properties to identify and format the segments of multipart titles (see the ). It is still possible to add these semantics, but they are also not well supported. The 3 element [] specifies the language of the content of the . Element Name: 3 Namespace: 65 Usage: REQUIRED child of Attributes: 07 Content Model: Text The of each 3 element MUST be a []. Although MAY specify additional 3 elements for multilingual Publications, will treat the first 3 element in document order as the primary language of the EPUB publication. Note do not inherit their language from the 3 element(s). EPUB creators must set the language of a resource using the intrinsic methods of the format. All [] elements except for Element Name: 4 | 45 | 5 | 6 | 47 | 65 | 48 | 49 | 50 | 71 | 7 | 8 Namespace: 65 Usage: OPTIONAL child of Attributes:
Text This specification does not modify the [] element definitions except as noted in the following sections. The 4 element [] is used to represent the name of a person, organization, etc. that played a secondary role in the creation of the content. The requirements for the 4 element are identical to those for the`` element in all other respects. The 5 element [] represents the name of a person, organization, etc. responsible for the creation of the content. MAY a with the element to indicate the function the creator played. The 5 element should contain the name of the creator as EPUB creators intend to display it to users. EPUB creators MAY use the a normalized form of the creator's name, and the to represent the creator's name in another language or script. If an has more than one creator, EPUB creators should specify each in a separate 5 element. The document order of 5 elements in the 0 section determines the display priority, where the first 5 element encountered is the primary creator. EPUB creators should represent secondary contributors using the The 6 element [] defines the publication date of the . The publication date is not the same as the (the last time the changed the EPUB publication). It is RECOMMENDED that the date string conform to [], particularly the subset expressed in W3C Date and Time Formats [], as such strings are both human and machine readable. EPUB creators should express additional dates using the specialized date properties available in the [] vocabulary, or similar. EPUB publications MUST NOT contain more than one 6 element. The 7 element [] identifies the subject of the . should set the of the element to the human-readable heading or label, but may use a code value if the subject taxonomy does not provide a separate descriptive label. EPUB creators MAY identify the system or scheme they drew the element's from using the . When a scheme is identified, EPUB creators MUST a subject code using the . The 59 property MUST NOT be that does not specify a scheme. The of the 7 element and 59 property are case sensitive only when the designated scheme requires. The 8 element [] is used to indicate that the is of a specialized type (e.g., annotations or a dictionary packaged in EPUB format). MAY use any text string as a . The 9 element provides a generic means of including package metadata. Element Name: 9 Usage: As child of the Attributes:
Text Each 9 element defines a metadata expression. The 72 attribute takes a that defines the statement made in the expression, and the text content of the element represents the assertion. (Refer to for more information.) This specification defines two types of metadata expressions that can define using the 9 element:
EPUB creators MAY use subexpressions to refine the meaning of other subexpressions, thereby creating chains of information. Note All the [] elements represent primary expressions, and permit refinement by meta element subexpressions. The is the for use with the 72 attribute. EPUB creators MAY add terms from other vocabularies as defined in . The 76 attribute identifies the system or scheme the EPUB creator obtained the element's from. The value of the attribute MUST be a that resolves to the resource that defines the scheme. The 76 attribute does not have a (i.e., all values require a ). The 0 section MUST contain exactly one 91 property [] containing the last modification date. The of this property MUST be an [] dateTime conformant date of the form: 92 MUST express the last modification date in Coordinated Universal Time (UTC) and MUST terminate it with the " 93" (Zulu) time zone indicator. EPUB creators should update the last modified date whenever they make changes to the . EPUB creators MAY specify additional modified properties in the metadata, but they MUST have a different subject (i.e., they require a 7 attribute that references an element or resource). Note The requirements for the last modification date are to ensure compatibility with earlier versions of EPUB 3 that defined a [] for EPUB publications. The 4 element associates resources with an , such as metadata records. Element Name: 4 Usage: As a child of Attributes:
Empty The 4 elements, each of which identifies the location of a or a in its REQUIRED 3 attribute. Resources referenced from the 4 element are only when they are:
In all other cases (e.g., when linking to standalone [] records), the resources referenced are not (i.e., are not subject to ) and MUST NOT list them in the . EPUB creators MAY locate linked resources within the or externally, but should consider that are not required to retrieve resources outside the EPUB container. The is OPTIONAL when a linked resource is located outside the EPUB container, as more than one media type could be served from the same URL []. EPUB creators MUST specify the attribute for all linked resources within the EPUB container. The OPTIONAL 00 attribute identifies the language of the linked resource. The value MUST be a []. The REQUIRED 29 attribute takes a space-separated list of values that establish the relationship the linked resource has with the EPUB publication. The value of the 5 attribute is not always sufficient to identify the type of linked resource (e.g., many XML-based record formats use the media type " 21"). To aid reading systems in the identification of such generic resources, EPUB creators MAY specify a semantic identifier in the 6 attribute. The is the for the 29 and 6 attributes. EPUB creators MAY add relationships and properties from other vocabularies as defined in . EPUB creators MAY provide one or more . Note Due to the variety of metadata record formats and serializations that an EPUB creator can link to an EPUB publication, and the complexity of comparing metadata properties between them, this specification does not require reading systems to process linked records. In addition to full records, EPUB creators MAY also use the 4 element to identify individual metadata properties available in an alternative format. The 1 element provides an exhaustive list of used in the rendering of the content. Element Name: 1 Usage: REQUIRED second child of Attributes: 07 Content Model:
42 With the exception of the , the 1 MUST list all publication resources regardless of whether they are or . As the package document is already identified by the , the 1 MUST NOT specify an 2 element for it (i.e., a self-reference serves no purpose). Note The manifest is only for listing publication resources. and (i.e., files in the 7 directory, and the 01 file) are restricted from inclusion. Failure to provide a complete manifest of publication resources may lead to rendering issues. might not unzip such resources or could prevent access to them for security reasons. The 2 element represents a . Element Name: 2 Usage: As a child of Attributes:
Empty Each 2 element identifies a publication resource by the URL [] in its . The value MUST be an or string []. MUST ensure each URL is unique within the 1 scope after . The publication resource identified by an 2 element MUST conform to the applicable specification(s) as inferred from the MIME media type [] provided in the . For , EPUB creators MUST use the media type designated in . The 23 attribute specifies the fallback for the referenced publication resource. The 23 attribute's [] value MUST resolve to another 2 in the 1. The fallback for one 2 MAY specify a fallback to another 2, and so on, creating a chain of fallback options. Refer to for additional requirements related to the use of fallback chains. The 49 attribute takes an IDREF [] that identifies the for the resource described by this 2. Refer to for more information. Note The order of 2 elements in the 1 is not significant. The`` element provides the presentation sequence of content documents. The provides information to about the content of a resource. This information enables discovery of key resources, such as the cover image and . It also allows reading systems to optimize rendering by indicating, for example, whether the resource contains embedded scripting, MathML, or SVG. The is the for the 6 attribute. MUST set the following properties whenever a resource referenced by an 2 element matches their respective definitions: These properties do not apply recursively to content included into a resource (e.g., via the [] 95 element). For example, if a non-scripted embeds a , only the embedded document's manifest 2 6 attribute will have the 77 value. EPUB creators MUST declare exactly one 2 as the EPUB navigation document using the . If an EPUB publication contains a cover image, it is recommended to set the , but setting this property is OPTIONAL. EPUB creators MAY add terms from other vocabularies as defined in . The 3 element defines a set of custom handlers for media types not supported by this specification. Use of the element is . Refer to the in [] for more information. The 4 element defines an ordered list of that represent the default reading order. Element Name: 4 Usage: REQUIRED third child of Attributes:
42 The 4 MUST specify at least one or . MUST list in the 4 all EPUB and foreign content documents that are hyperlinked to from publication resources in the 4, where hyperlinking encompasses any linking mechanism that requires the user to navigate away from the current resource. Common hyperlinking mechanisms include the 99 attribute of the [] 11 and 01 elements and scripted links (e.g., using DOM Events and/or form elements). The requirement to list hyperlinked resources applies recursively (i.e., EPUB creators must list all EPUB and foreign content documents hyperlinked to from hyperlinked documents, and so on.). EPUB creators also MUST list in the 4 all EPUB and foreign content documents hyperlinked to from the , regardless of whether EPUB creators include the EPUB navigation document in the 4. Note As hyperlinks to resources outside the EPUB container are not , they are not subject to the requirement to include in the spine (e.g., web pages and web-hosted resources). Publication resources used in the rendering of spine items (e.g., referenced from [] ) similarly do not have to be included in the spine. The 90 attribute sets the global direction in which the content flows. Allowed values are 38 (left-to-right), 39 (right-to-left) and 07. When EPUB creators specify the 07 value, they are expressing no preference and the can choose the rendering direction. Although the 90 attribute sets the global flow direction, individual EPUB content documents and parts of EPUB content documents MAY override this setting (e.g., via the 10 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). The 92 attribute takes an [] that identifies the manifest item that represents the . The 5 element identifies an or in the default reading order. Element Name: 5 Usage: As a child of Attributes:
Empty Each 5 element MUST reference the [] of an 17 attribute. 2 element IDs MUST NOT be referenced more than once. Each referenced manifest 2 MUST be either a) an or b) a that includes an EPUB content document in its . The 19 attribute indicates whether the referenced 2 contains content that contributes to the primary reading order and that must read sequentially (" 30"), or auxiliary content that enhances or augments the primary content that reading systems can access out of sequence (" 31"). Examples of auxiliary content include notes, descriptions, and answer keys. The 19 attribute allows reading systems to distinguish content that a user should access as part of the default reading order from supplementary content which a reading system might, for example, present in a popup window or omit from an aural rendering. Specifying that content is non-linear does not require reading systems to present it in a specific way, however; it is only a hint to the purpose. Reading systems may present non-linear content where it occurs in the spine, for example, or may skip it until users reach the end of the spine. Note should list non-linear content at the end of the spine except when it makes sense for users to encounter it between linear spine items. A linear 5 element is one whose 19 attribute value is explicitly set to " 30" or that omits the attribute — reading systems will assume the value " 30" for 5 elements without the attribute. The spine MUST contain at least one linear 5 element. EPUB creators MUST provide a means of accessing all non-linear content (e.g., hyperlinks in the content or from the ). The is the for the 6 attribute. EPUB creators MAY add terms from other vocabularies as defined in . The 6 element defines a related group of resources. Element Name: 6 Usage: OPTIONAL sixth element of 9. Repeatable. Attributes:
In this order: 0 26, ( 42 or ( 30, 4 42 )) The 6 element allows to assemble resources into logical groups for a variety of potential uses: enabling reassembly into a meaningful unit of content split across multiple (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 . EPUB creators MUST identify the role of each 6 element in its 46 attribute, whose value MUST be one or more NMTOKENs [] and/or []. The requirements for authoring specialized collections are defined by their respective specifications. The creation of new 6 element roles is now . Refer to the in [] for more information about the creation of specialized collections, including the requirements and restrictions on their use. The package document legacy features are retained from EPUB 2 only to allow to author content that can function, to some degree, in that only support EPUB 2 publications. These features were added primarily to address the overlap period as EPUB 3 reading systems were developed, as there was still a high probability at that time that users would be opening EPUB 3 publications on EPUB 2 reading systems. As reading systems that only handle EPUB 2 publications are now rare, EPUB creators should consider the likelihood of their publications still being opened on these types of older devices before making the effort to add these legacy features. MAY include the legacy features defined in this section for compatibility purposes with EPUB 2 reading systems. EPUB 3 reading systems will not use these features when presenting publications to users. Note should not alert EPUB creators about the presence of legacy features in an , as their inclusion is valid for backwards compatibility. EPUB conformance checkers must alert EPUB creators if a legacy feature does not conform to its definition or otherwise breaks a usage requirement. The [] provides a means of including generic metadata for EPUB 2 . Refer to the in [] for more information. Note The EPUB 3 The [] 9 element also allows to identify a cover image for EPUB 2 reading systems. In EPUB 3, the cover image must be identified using the on the manifest The [] provides machine-processable navigation to key structures in EPUB 2 . Refer to the in [] for more information. The [] provides a table of contents for EPUB 2 . Refer to the in [] for more information. This section is non-normative. This section defines a profile of [] for creating . An instance of an XML document that conforms to this profile is a and is referred to in this specification as an XHTML content document. An :
Unless specified otherwise, XHTML content documents inherit all definitions of semantics, structure, and processing behaviors from the [] specification. This section defines EPUB 3 extensions to the underlying [] document model. Note Although [] allows user agents to support , unless such extensions are listed in this section, they are not supported features of EPUB 3. MAY use the The attribute MUST NOT be used on the element or []. The [] specification defines a set of attributes that MAY use in to semantically enrich the content. The use of these attributes MUST conform to the requirements defined in []. The [] specification defines changes to the [] content model when authors use RDFa attributes. This modified content model is valid in XHTML content documents. Note The listing of RDFa does not express a preference on the part of the Working Group, only that these attributes represent an extension of the HTML grammar. EPUB creators can also specify [] and [] in XHTML content documents as both are natively supported. The 74 element provides a simple mechanism through which can tailor the content displayed to users, one that is not dependent on the scripting capabilities of the . Use of the element is . Refer to the in [] for more information. The 76 element enables the creation of markup-defined user interfaces for controlling multimedia objects, such as audio and video playback, in both scripted and non-scripted contexts. Use of the element is . Refer to the in [] for more information. MAY contain custom attributes, which are [] attributes whose namespace URL does not include either of the following strings in its []:
When using custom attributes, the content MUST remain consumable by a user without any information loss or other significant deterioration, regardless of the it is rendered on. Note Custom attributes are usually defined in a reading system-specific manner and are not intended for use by other reading systems. This specification should be extended to provide extensions that multiple independent reading systems can use. This section defines deviations from, and constraints on, the underlying [] document model applicable to EPUB 3 . support embedded []. Occurrences of MathML markup MUST conform to the constraints expressed in the MathML specification [], with the following additional restrictions: Presentation MathML The 80 element MUST contain only , except within the 81 element. Content MathML MAY include within MathML markup in XHTML content documents, and, when present, MUST include it within an 81 child element of a 83 element. When EPUB creators include Content MathML per the previous condition, they MUST set the given 81 element's 85 attribute to either of the functionally-equivalent values 86 or 87, and the 88 attribute to 89. This subset eases the implementation burden on and promotes accessibility, while retaining compatibility with [] user agents. Note The of the 2 element indicates that an XHTML content document contains embedded MathML. support the embedding of [] by reference (embedding via reference, for example, from an 5 or 93 element) and by inclusion (embedding via direct inclusion of the 94 element in the XHTML content document). The content conformance constraints for SVG embedded in XHTML content documents are the same as defined for in . This section is non-normative. The [] element can be used to specify the for the purposes of parsing URLs. When using it in an , the interpretation of the 0 element may inadvertently result in references to . It may also cause to misinterpret the location of hyperlinks (e.g., relative links to other documents in the publication might appear as links to a web site if the 0 element specifies an absolute URL). To avoid significant interoperability issues, should not use the 0 element. The [] 99 element is intended to provide a fallback for older that do not recognize ruby markup (i.e., a parenthesis display around 00 markup). As EPUB 3 reading systems are ruby-aware, and can provide fallbacks, should not use 1 elements. Since the [] element does not include intrinsic facilities to provide fallback content for that do not support scripting, are discouraged from using the element when the referenced resource includes scripting. The [] 03 element is a better alternative, as it includes intrinsic fallback capabilities. Caution may not support all the features of [] or support them across all platforms that reading systems run on. When utilizing such features, should consider the inherent risks on interoperability and document longevity. This section is non-normative. The Scalable Vector Graphics (SVG) specification [] defines a format for representing final-form vector graphics and text. Although typically use as the document type, the use of is also permitted. EPUB creators will typically only need SVGs for certain special cases, such as when final-form page images are the only suitable representation of the content (e.g., for cover art or in the context of manga or comic books). This section defines a profile for [] documents. An instance of an XML document that conforms to this profile is a and is referred to in this specification as an . Note This section defines conformance requirements for SVG content documents. Refer to for the conformance requirements for SVG embedded in XHTML content documents. An :
This specification restricts the content model of and as follows:
Note Although the [] 08 element allows markup elements, support for this feature is limited. are advised to use text-only titles for maximum interoperability. This section defines requirements for technologies usable in both and . This section is non-normative. CSS is an integral part of the Open Web Platform. Readers, publishers, and document authors expect CSS to "just work," as they expect HTML to just work. In the past, EPUB defined a profile of CSS that mandated support for certain properties and provided prefixed versions of numerous other properties. Although the CSS Working Group no longer recommends the use of prefixed properties, this specification maintains 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. Note Keep in mind that some will not support all desired features of CSS. The following are known to be particularly problematic:
A CSS style sheet:
Note This specification restricts the use of the 09 and 10 properties because might not implement, or might switch off, CSS processing. must use the following format-specific methods when they need control over these aspects of the rendering:
Earlier version of EPUB included prefixed CSS properties, as many CSS features related to world languages were not yet mature. To ensure backwards compatibility for content authored using these prefixes, they have been retained in this specification. Unless otherwise noted, prefixed properties and values behave exactly as their unprefixed equivalents as described in the appropriate CSS specification. The prefixed properties are documented in . Caution should use unprefixed properties and should support current CSS specifications. This specification retains the widely used prefixed properties from [] but removes support for the less-used ones. EPUB creators should use CSS-native solutions for the removed properties whenever available. The Working Group recommends that EPUB creators currently using these prefixed properties move to unprefixed versions as soon as support allows, as the Working Group does not anticipate supporting them in the next major version of EPUB. MAY contain scripting using the facilities defined for this in the respective underlying specifications ([] and []). When an EPUB content document contains scripting, this specification refers to it as a . This label also applies to that contain [] 12 elements. The of the 2 element is used to indicate that an EPUB content document is a scripted content document. When an [] 6 element contains a [], it does not represent scripted content. Note [] does not define data blocks as of publication, but the same exclusion would apply if a future update adds the concept. should note that are required to behave as though a unique [] has been assigned to each . In practice, this means that it is not possible for scripts to share data between EPUB publications. Which a script is used in also determines the rights and restrictions that a reading system places on it (refer to [] for more information). Note Reading systems may 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). EPUB 3 defines two contexts for script execution:
Whether embed the code directly in a 6 element or reference it via the element's 76 attribute makes no difference to its executing context. Which context EPUB creators use for their scripts affects both what actions the scripts can perform and the likelihood of support in reading systems, as described in the following subsections. A container-constrained script is either of the following:
A container-constrained script MUST NOT contain instructions for modifying the DOM of the that embeds it (i.e., the one that contains the 98 element). It also MUST NOT contain instructions for manipulating the size of its containing rectangle. should note that is only recommended in reflowable documents []. Furthermore, support in is optional. EPUB creators should ensure container-constrained scripts degrade gracefully in reading systems without scripting support (see ). Note EPUB creators 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). A spine-level script is an instance of the [] 84 or [] element contained in a . should note that support for spine-level scripting in is only recommended in and []. Furthermore, reading system support in all other contexts is optional. that include spine-level scripting SHOULD remain consumable by the user without any information loss or other significant deterioration when scripting is disabled or not available (e.g., by employing progressive enhancement techniques or ). Failing to account for non-scripted environments in top-level content documents can result in being unreadable. This section is non-normative. should consider the wide variety of possible implementations when adding scripting functionality to their (e.g., not all devices have physical keyboards, and in many cases a soft keyboard is activated only for text input elements). Consequently, EPUB creators should not rely on keyboard events alone; they should always provide alternative ways to trigger a desired action. that contain scripting SHOULD employ relevant [] accessibility techniques to ensure that the content remains consumable by all users. that contain scripting MAY provide fallbacks for such content, either by using intrinsic fallback mechanisms (such as those available for the [] 03 and 33 elements) or, when an intrinsic fallback is not applicable, by using a . MUST ensure that scripts only generate or fragments thereof. This section is non-normative. The is a of an . It allows to include a human- and machine-readable global navigation layer, thereby ensuring increased usability and accessibility for the user. The EPUB navigation document is a special type of that defines the for . It may also include other specialized navigation elements, such as a and a list of key . These navigation elements have on their content to facilitate their processing. The EPUB navigation document is not exclusively for machine processing, however. There are no restrictions on the structure or content of the EPUB navigation document outside of the specialized navigation elements (i.e., EPUB creators can mark the rest of the document up like any other XHTML content document). As a result, it can also be part of the linear reading order, avoiding the need for duplicate tables of contents. EPUB creators can hide navigation elements that are only for machine processing (e.g., the page list) with the . Note that reading systems may strip scripting, styling, and HTML formatting as they generate navigational interfaces from information found in the EPUB navigation document, and this may make the result difficult to read. If EPUB creators require such formatting and functionality, then they should also include the EPUB navigation document in the . The use of progressive enhancement techniques for scripting and styling of the navigation document will help ensure the content will retain its integrity when rendered in a non-browser context. A valid EPUB navigation document:
When a 3 element carries the Content Model: 41 In this order:
44 In this order:
47 In this order:
50 and 11 In any order:
Note that there are no restrictions on the attributes allowed on these elements. Refer the definition below for additional requirements. The following elaboration of the content model of the 3 element explains the purpose and restrictions of the various elements:
Caution Although the headings and links in 3 elements allow any [] , app-based reading systems often only support simple text labels. Because these apps create their own navigation widgets that are not based on HTML rendering, they often cannot retain embedded images and multimedia, MathML, inline styling and other element- and attribute-based rendering instructions. EPUB creators should avoid using these types of elements where their absence may lead to usability issues. As a conforming , EPUB creators MAY include the EPUB navigation document in the . In the context of this specification, the default display style of list items within 3 elements is equivalent to the []. EPUB creators MAY specify alternative list styling using CSS for rendering of the document in the spine. This section is non-normative. The 3 elements defined in an are distinguished semantically by the value of their This specification defines three types of navigation aid: Identifies the 3 element that contains the table of contents. The 5 is the only navigation aid that must include in the EPUB navigation document. Identifies the 3 element that contains a list of pages for a print or other statically paginated source. Identifies the 3 element that contains a list of points of interest. An EPUB navigation document may contain at most one navigation aid for each of these types. The EPUB navigation document may include additional navigation types. See for more information. The 5 element defines the primary navigational hierarchy. 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). SHOULD order the references in the 5 element such that they reflect both:
The 93 element provides navigation to static page boundaries in the content. These boundaries may correspond to a statically paginated source such as print or may be defined exclusively for the . The 6 element is OPTIONAL in and MUST NOT occur more than once. The 6 element SHOULD contain only a single 59 descendant (i.e., no nested sublists). MAY identify the destinations of the 93 references in their respective using the []. The 7 element identifies fundamental structural components in the content to enable to provide the user efficient access to them (e.g., through a dedicated button in the user interface). The 7 element is OPTIONAL in and MUST NOT occur more than once. The 7 element SHOULD contain only a single 59 descendant (i.e., no nested sublists). The 94 element descendants of the 7 element. The structural semantics of each link target within the 7 element is determined by the value of this attribute. The 7 MUST NOT include multiple entries with the same 9 value that reference the same resource, or fragment thereof. should limit the number of items they define in the 7 to only items that a reading system is likely to use in its user interface. The element is not meant to repeat the table of contents. The following landmarks are recommended to include when available:
Other possibilities for inclusion in the 7 are key reference sections such as indexes and glossaries. Although the 7 is intended for reading system use, EPUB creators should still ensure that the labels for the 7 are human readable. Reading systems may expose the links directly to users. MAY contain one or more 3 elements in addition to the 92, 93, and 7 elements defined in the preceding sections. If these 3 elements are intended for processing, they MUST have an This specification imposes no restrictions on the semantics of any additional 3 elements: they MAY represent navigational semantics for any information domain, and they MAY contain link targets with homogeneous or heterogeneous semantics. This section is non-normative. Although it is possible to reuse the in the , it is often the case that not all of the navigation structures, or branches within them, are needed. will often want to hide the and navigation elements or trim the branches of the table of contents for books that have many levels of subsections. While the [] controls the visual rendering of EPUB navigation documents in with , reading systems without viewports may not support CSS. To better ensure the proper rendering in these reading systems, EPUB creators should use the [] 031 attribute to indicate which (if any) portions of the navigation data are excluded from rendering in the content flow. The 34 attribute has no effect on how reading systems render the navigation data outside of the content flow (such as in dedicated navigation user interfaces provided by reading systems). Note The 34 attribute can be used together with the 030 property to maximize interoperability across all reading systems. This section is non-normative. Not all rendering information can be expressed through the underlying technologies that EPUB is built upon. For example, although HTML with CSS provides powerful layout capabilities, those capabilities are limited to the scope of the document being rendered. This section defines properties that allow to express package-level rendering intentions (i.e., functionality that can only be implemented by the ). If a reading system supports the desired rendering, these properties enable the user to be presented the content as the EPUB creator optimally designed it. This section is non-normative. , 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 "content presentation adapts to the user, rather than the user having to adapt to a particular presentation of content." [] But this principle does not work for all types of documents. Sometimes content and design are so intertwined it is not possible to separate them. Any change in appearance risks changing the meaning or losing all meaning. give greater control over presentation when a reflowable EPUB is not suitable for the content. EPUB creators define fixed layouts using a to control the rendering in . In addition, they set in its respective . Note EPUB 3 affords multiple mechanisms for representing fixed-layout content. When fixed-layout content is necessary, the EPUB creator'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 EPUB creator's choice of mechanism. The 035 property specifies whether the content is reflowable or pre-paginated. When the is specified on a 9 element, it indicates that the paginated or reflowable layout style applies globally (i.e., for all spine items). MUST use one of the following values with the 035 property: reflowable The content is not pre-paginated (i.e., apply dynamic pagination when rendering). Default value. pre-paginated The content is pre-paginated (i.e., reading systems produce exactly one page per`` when rendering). Note Reading systems typically restrict or deny the application of user or user agent style sheets to pre-paginated documents because dynamic style changes are likely to have unintended consequence on the intrinsic properties of such documents. EPUB creators should consider the negative impact on usability and accessibility that these restrictions have when choosing to use pre-paginated instead of reflowable content. Refer to [] for related information. When the property is set to 06 for a spine item, its content dimensions MUST be set as defined in . EPUB creators MUST NOT declare the 035 property more than once. They also MUST NOT declare the property using the . Refer to for setting the property for individual . MAY specify the following properties locally on rendition:layout-pre-paginated Specifies that the given spine item is pre-paginated. rendition:layout-reflowable Specifies that the given spine item is reflowable. EPUB creators MUST NOT use more than one of these overrides on any given spine item. The 044 property specifies which orientation the intends the content to be rendered in. When the is specified on a MUST use one of the following values with the 044 property: landscape should render the content in landscape orientation. portrait Reading systems should render the content in portrait orientation. auto The content is not orientation constrained. Default value. EPUB creators MUST NOT declare the 044 property more than once. They also MUST NOT declare the property using the . Refer to for setting the property for individual . MAY specify the following properties locally on rendition:orientation-auto Specifies that the determines the orientation to render the spine item in. rendition:orientation-landscape Specifies that reading systems should render the given spine item in landscape orientation. rendition:orientation-portrait Specifies that reading systems should render the given spine item in portrait orientation. EPUB creators MUST NOT use more than one of these overrides on any given spine item. The 051 property specifies the intended synthetic spread behavior. When the 051 property is specified on a 9 element, it indicates that the intended behavior applies globally (i.e., for all spine items). MUST use one of the following values with the 051 property: none Do not incorporate spine items in a synthetic spread. Reading systems should display the items in a single positioned at the center of the screen. landscape Render a synthetic spread for spine items only when the device is in landscape orientation. portrait (deprecated) The use of spreads only in portrait orientation is . EPUB creators should use the value " 055" instead, as spreads that are readable in portrait orientation are also readable in landscape. both Render a synthetic spread regardless of device orientation. auto The EPUB creator is not defining an explicit synthetic spread behavior. Default value. EPUB creators MUST NOT declare the 051 property more than once. They also MUST NOT declare the property using the . Refer to for setting the property for individual . Note Refer to the 90 attribute and that of local page-progression-direction within content documents. MAY specify the following properties locally on rendition:spread-auto Specifies the determines when to render a synthetic spread for the spine item. rendition:spread-both Specifies the reading system should render a synthetic spread for the spine item in both portrait and landscape orientations. rendition:spread-landscape Specifies the reading system should render a synthetic spread for the spine item only when in landscape orientation. rendition:spread-none Specifies the reading system should not render a synthetic spread for the spine item. rendition:spread-portrait The 061 property is . Refer to the in [] for more information. EPUB creators MUST NOT use more than one of these overrides on any given spine item. When a renders a , the default behavior is to populate the spread by rendering the next in the next available unpopulated , where the next available viewport is determined by the given or by local declarations within . An MAY override this automatic population behavior and force reading systems to place a document in a particular viewport by specifying one of the following properties on its spine 5 element: 064 The 064 property is an alias of the for centering a spine item. 067 The 067 property is an alias of the 069 property for placing a spine item in the left-hand slot of a two-page spread. 070 The 070 property is an alias of the 072 property for placing a spine item in the right-hand slot of a two-page spread. The 064, 067, and 070 properties apply to both pre-paginated and reflowable content. They only apply when the reading system is creating synthetic spreads. Although EPUB creators often indicate to use a spread in certain device orientations, the content itself does not represent true spreads (i.e., two consecutive pages that reading systems must render side-by-side for readability, such as a two-page map). To indicate that two consecutive pages represent a true spread, EPUB creators SHOULD use the 067 and 070 properties on the 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. EPUB creators MUST NOT declare more than one 078 property, and/or their unprefixed equivalents, on any given spine item (e.g., it is valid to specify both " 079" in case reading systems only support one of properties). Note The 067 and 070 properties were created to allow the use of a single vocabulary for all fixed-layout properties. EPUB creators can use either property set, but older reading systems might only recognize the unprefixed versions. The 064 was created to make it easier for EPUB creators to understand the process of switching between two-page spreads and single centered pages. EPUB creators can use either 064 or 066 to disable spread behavior in reading systems. The 085 property allows to express the CSS initial containing block (ICB) [] for and whose 035 property has been set to 06. Use of the property is . Refer to the in [] for more information. This section defines rules for the expression and interpretation of dimensional properties of . Fixed-layout documents specify their [] in the manner applicable to their format: Expressing in XHTML For XHTML , the [] is obtained from the REQUIRED 089 and 090 definitions in a , where:
The 095 and 093 values refer to the 100% of the width and height, respectively, of the reading system's . The 089 and 090 definitions MUST be specified in the first 4 tag in document order in the [] element. Reading systems will ignore subsequent 4 tags. EPUB creators MUST NOT specify more than one 089 or 090 definition within a 4 tag. Expressing in SVG For SVG , the initial containing block [] dimensions MUST be expressed using the []. Note The initial containing block definition affects only the document where it is defined. The dimensions of the containing blocks in the other content documents within the same publication may be different. Although control over the rendering of to create is an obvious need not handled by other technologies, there are also considerations for reflowable content that are unique to (e.g., how to handle the flow of content in the ). This section defines properties that allow to control presentation aspects of reflowable content. The 9 property specifies the preference for how should handle content overflow. When the is specified on a 9 element, it indicates the EPUB creator's global preference for overflow content handling (i.e., for all items). EPUB creators MAY indicate a preference for dynamic pagination or scrolling. For scrolled content, it is also possible to specify whether consecutive 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). EPUB creators MUST use one of the following values with the 9 property: paginated Dynamically paginate all overflow content. scrolled-continuous Render all EPUB content documents such that overflow content is scrollable, and the is presented as one continuous scroll from spine item to spine item (except where ). Note that EPUB creators SHOULD NOT create publications in which different resources have different block flow directions, as continuous scrolled rendition in EPUB reading systems would be problematic. scrolled-doc Render all EPUB content documents such that overflow content is scrollable, and each spine item is presented as a separate scrollable document. auto Render overflow content using the reading system default method or a user preference, whichever is applicable. Default value. Note that when two reflowable EPUB content documents occur sequentially in the spine, the default rendering for their [] elements is consistent with the [] having been set to 113. In addition to using the 9 property, EPUB creators MAY override this behavior through an appropriate style sheet declaration, if the reading system supports such overrides. EPUB creators MUST NOT declare the 9 property more than once. They also MUST NOT declare the property using the . Refer to for setting the property for individual EPUB content documents. Rendering of an EPUB publication with a single spine item, and with the 9 set to
Three column-like rectangles linked left-to-middle and middle-to-right with respective arrows, with a text flowing from one rectangle to the next one. The text is sectioned with headers figuring 'Chapter 1', '2', and '3'. The leftmost rectangle is enclosed in a schematic view of a tablet. Rendering of an EPUB publication with multiple spine items, and with the 9 set to
Three column-like rectangles linked left-to-middle and middle-to-right with respective arrows, with a text flowing from one rectangle to the next one. The text is sectioned with headers figuring 'Chapter 1', '2'. The section with 'Chapter 2' starts at the top of the rightmost rectangle, leaving an empty space at the bottom of the middle rectangle. The leftmost rectangle is enclosed in a schematic view of a tablet. Rendering of an EPUB publication with a single spine item, and with the 9 set to
A single, column-like strip (i.e., a rectangle without a bottom edge) with a text flowing down the strip. The text is sectioned with headers figuring 'Chapter 1', '2'. The top part of the strip is enclosed in a schematic view of a tablet. Rendering of an EPUB publication with multiple spine items, and with the 9 set to
Three column-like strips (i.e., a rectangles without bottom edges) linked left-to-middle and middle-to-right with respective arrows, each containing a text flowing down the strip. The text is sectioned with headers figuring 'Chapter 1', '2' and '3'. Each strip starts with a chapter header and flows down the strip. The top part of the leftmost strip is enclosed in a schematic view of a tablet. MAY specify the following properties locally on rendition:flow-auto Indicates no preference for overflow content handling by the EPUB creator. rendition:flow-paginated Indicates the EPUB creator preference is to dynamically paginate content overflow. rendition:flow-scrolled-continuous Indicates the EPUB creator preference is to provide a scrolled view for overflow content, and that consecutive spine items with this property are to be rendered as a continuous scroll. rendition:flow-scrolled-doc Indicates the EPUB creator preference is to provide a scrolled view for overflow content, and each spine item with this property is to be rendered as a separate scrollable document. EPUB creators MUST NOT use more than one of these overrides on any given spine item. The 0 property specifies that the given item should be centered horizontally in the or spread. The property MUST NOT be set globally for all (i.e., in a 6 attribute. 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. are encouraged to use CSS solutions when effective. This section is non-normative. Mainstream ebooks, educational tools and ebooks formatted for persons with print disabilities are some examples of works that contain synchronized audio narration. In EPUB 3, can create these types of books using media overlay documents to describe the timing for the pre-recorded audio narration and how it relates to the markup. The specification defines the file format for media overlays as a subset of [], a W3C recommendation for representing synchronized multimedia information in XML. The text and audio synchronization enabled by media overlays provides enhanced accessibility for any user who has difficulty following the text of a traditional book. Media overlays also provide a continuous listening experience for readers who are unable to read the text for any reason, something that traditional audio embedding techniques cannot offer. They are even useful for purposes not traditionally considered accessibility concerns (e.g., for language learning). The media overlays feature is transparent to that do not support the feature. The inclusion of media overlays in an 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. Media overlays in EPUB are not an equivalent to audiobooks, as audiobooks are primarily audio-based with text occasionally provided as an alternate format. The W3C [] recommendation is for building audio publications. Although future versions of this specification might incorporate support for video media (e.g., synchronized text/sign-language books), this version supports only synchronizing audio media with the EPUB content document. A :
All elements [] defined in this section are in the 131 namespace [] unless otherwise specified. The 1 element encapsulates all the information in an . Element Name: 1 Usage: REQUIRED [] of the media overlay document. Attributes: 98 05 Specifies the version number of the [] specification to which the media overlay document adheres. This attribute MUST have the value " 32". 4 07 The [] of the element, which MUST be unique within the document scope. 139 07 Declares additional metadata vocabulary prefixes. Refer to for more information. Content Model: In this order:
The 2 element is the container for metadata in the . Element Name: 2 Usage: The 2 element is the OPTIONAL first child of the Attributes: None Content Model:
26 As this specification does not define any metadata properties that must occur in the media overlay document, the 2 element is OPTIONAL. The 0 element represents metadata for the . The 0 element is an extension point that allows the inclusion of metadata from any metainformation structuring language. Element Name: 0 Usage: As a child of the Attributes: None Content Model: 30 elements from any namespace This specification does not require any metadata properties in the media overlay document; the 0 element is provided for custom metadata requirements. The 4 element is the starting point for the presentation contained in the . It contains the main sequence of Element Name: 4 Usage: The 4 element is a REQUIRED child of the Attributes: 9 07 An expression of the structural semantics of the corresponding element in the . The value is a white space separated list of types. Refer to for more information. 4 07 The [] of the element, which MUST be unique within the document scope. 169 07 Refers to the associated EPUB content document and, optionally, identifies a specific part of it. The value MUST be a , optionally followed by 69 and a . Content Model: In any order:
MUST include at least one 6 or 5. The 5 element is a sequential time container for media objects and/or child time containers. Element Name: 5 Usage: One or more 5 elements MAY occur as children of the Attributes: 9 07 An expression of the structural semantics of the corresponding element in the . The value is a white space separated list of types. Refer to for more information. 4 07 The [] of the element, which MUST be unique within the document scope. 169 05 Refers to the associated and, optionally, identifies a specific part of it. The value MUST be a , optionally followed by 69 and a . Refer to for more information. Content Model: In any order:
MUST include at least one 6 or 5. The 6 element is a parallel time container for media objects. Element Name: 6 Usage: One or more 6 elements MAY occur as children of the Attributes: 9 07 An expression of the structural semantics of the corresponding element in the . The value is a white space separated list of types. Refer to for more information. 4 07 The [] of the element, which MUST be unique within the document scope. Content Model: In any order:
The 7 element references an element in an . A 7 element typically refers to a textual element but can also refer to other media elements. In the absence of a sibling Element Name: 7 Usage: As a REQUIRED child of the Attributes: 76 05 Refers to the associated EPUB content document and, optionally, identifies a specific part of it. The value MUST be a , optionally followed by 69 and a . 4 07 The [] of the element, which MUST be unique within the document scope. Content Model: Empty Note [] no longer provides guidance for reading systems on the playback of timed media (i.e., the automatic starting of the referenced media). Although the 76 attribute of a 7 element may refer to embedded timed media (e.g., via an [] 52 element), referencing such media may have unpredictable results. The 3 element represents a clip of audio media. Element Name: 3 Usage: An OPTIONAL child of the Attributes: 4 07 The [] of the element, which MUST be unique within the document scope. 76 05 The or [] reference to an audio file. The audio file MUST be one of the audio formats listed in the table. 229 07 A clock value that specifies the offset into the physical media corresponding to the start point of an audio clip. MUST be a [] . See . 231 07 A clock value that specifies the offset into the physical media corresponding to the end point of an audio clip. MUST be a [] . See . The chronological offset of the terminating position MUST be after the starting offset specified in the 229 attribute. Content Model: Empty This section is non-normative. can represent a pre-recorded narration of a publication as a series of audio clips, each corresponding to part of an . 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 [] markup. Media overlays are, in fact, a simplified subset of SMIL 3.0 that define the playback sequence of these clips. The SMIL elements primarily used for structuring media overlays are The 6 element is the basic building block of a media 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 6 element uses two media element children to represent this information: an 6 elements' media object children are timed in parallel, reading systems render the audio clip and EPUB content document fragment at the same time, resulting in a synchronized presentation. The 7 element 76 attribute references the associated phrase, sentence, or other segment of the EPUB content document by its URL [] reference. The 3 element 76 attribute similarly references the location of the corresponding audio clip and adds the OPTIONAL and attributes to indicate a specific offset within the clip. EPUB creators place 6 elements together sequentially to form a series of phrases or sentences. Not every element of the EPUB content document will have a corresponding 6 element in a media overlay document, only those relevant to the audio narration. EPUB creators can also add 6 elements to 5 elements to define more complex structures such as parts and chapters (see ). Note In this section, the is assumed to be an . While may use media overlays with , playback behavior might not be consistent and therefore interoperability is not guaranteed. EPUB creators should also be aware that support for playback of both reflowable and fixed-layout EPUB content documents is not guaranteed. Differences in reading system pagination strategies mean that some reading systems will only support media overlays in one or the other layout format. The The 6 element represents a segment of content, such as a word, phrase, sentence, table cell, list item, image, or other identifiable piece of content in the markup. Each element identifies both the content to display (in the The 5 element represents sequences — sets of 5 and/or 6 elements that together represent a logical component of the content. can use it to represent nested containers such as sections, asides, headers, tables, lists, and footnotes. It allows EPUB creators to retain the structure inherent in these containers in the media overlay document. The 5 element MUST contain an . As 5 elements do not provide synchronization instructions, this attribute allows a to match the fragment to a location in the text. Note The reason for grouping structures like sections, figures, tables, and footnotes in a 5 element is so that reading systems can identify their start and end positions during playback. Reading systems can then offer playback options tailored to the layout of the content, such as jumping past a long figure, turning off rendering of page break announcements (see ), or customizing the reading mode to suit structures such as tables. Both the 169 attribute and the 76 attribute may contain a that references a specific part (e.g., an element via its ID) of the associated . For and , the URL-fragment string SHOULD be a reference to a specific element via its ID, or an [], respectively. EPUB creators MAY use other fragment identifier schemes, but may not support such identifiers. This section is non-normative. The granularity level of the media overlay depends on how mark up the and the type of fragment identifier they use in the 76 attributes and the 169 attrbutes. For example, when referencing [] elements, if the finest level of markup is at the paragraph level, then that is the finest possible level for media overlay synchronization. Likewise, if sub-paragraph markup is available, such as [] 50 element 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 . Fragment identifier schemes that do not rely on the presence of elements could provide even finer granularity, where supported. This specification allows the use of text-to-speech (TTS) — the rendering of the textual content of an as artificial human speech using a synthesized voice — in addition to pre-recorded audio clips. When a media overlay To express in , MAY specify the The 9 attribute facilitates behavior appropriate for the semantic type(s) indicated. Examples of these behaviors are and []. MAY use the applicable for the 9 attribute to define additional semantics. MAY express visual rendering information for the currently playing element in a CSS Style Sheet using author-defined classes. When used, EPUB creators MUST declare the class names in the using the and properties. EPUB creators MUST define exactly one CSS class name in each property they define. Each property MUST define a not including any selectors []. This specification does not reserve names for use with these properties. EPUB creators MAY define any CSS properties for the specified CSS classes but must ensure that each EPUB content document with an associated includes a CSS stylesheet (either embedded or linked) containing the class definitions. In the absence of such definitions might provide their own styling, or no styling at all. EPUB creators MUST NOT use the 282 and 283 properties in conjunction with a as they always apply to the entire . If an is wholly or partially referenced by a , then its 49 attribute. The attribute MUST reference the [] of the manifest 2 for the corresponding media overlay document. MUST only specify the 49 attribute on manifest 2 elements that reference EPUB content documents. Manifest items for media overlay documents MUST have the media type 48. MUST specify the duration of the entire in the using a In addition, EPUB creators MUST provide the duration of each . EPUB creators MUST use the to associate each duration declaration to the corresponding The sum of the durations for each media overlay document SHOULD equal the plus or minus one second. Note Although the sum of indivudal durations may not exactly match the total due to rounding the times to nearest fraction of a second, a difference of greater than one second indicates a mismatch arising from other issues. MAY also specify information in the package document, as well as to apply to the currently playing element. Note The 298 prefix is for inclusion of these properties in package metadata. While reading, users may 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. use the semantic information provided by media overlay elements' attribute to determine when to offer users the option of skippable features. MAY use the following semantics to enable skippability:
This list is non-exhaustive, however. It represents terms from the Structural Semantics Vocabulary [] for which reading systems are most likely to offer the option of skippability. 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). MAY use the following semantics to enable escapability:
This list is non-exhaustive list, however. It represents terms from the Structural Semantics Vocabulary [] for which are most likely to offer the option of escapability. Note Sometimes escapable structures may contain escapable structures. For example, tables are composed of many rows and cells that users may want to separately escape from. Reading system support for escaping from such structures is complex and not well supported at this time. EPUB creators should avoid identifying nested escapable structures until better support is available. This section is non-normative. As the is an , may associate a with it. Unlike traditional XHTML content documents, however, must present the EPUB navigation document to users even when it is not included in the (see []). As a result, the method in which an associated media overlay behaves can change depending on the context:
This section is non-normative. EPUB 3 builds upon the Open Web Platform expressly so that it can leverage the structure, semantics and, by extension, accessibility built into its underlying technologies. The requirements and practices for creating accessible web content have already been documented in the W3C's Web Content Accessibility Guidelines (WCAG) []. These guidelines also form the basis for defining accessibility in . As the current WCAG guidelines (version 2) are heavily focused on web pages, a separate specification, [], defines how to apply the standard to EPUB publications. It also adds EPUB-specific requirements and recommendations for metadata, pagination, and media overlays. This specification recommends that EPUB publications defined in []. A benefit of following this recommendation is that it helps to ensure that EPUB publications meet the accessibility requirements legislated in jurisdictions around the world. , however, should look beyond legal imperatives and treat accessibility as a requirement for all their content. The more accessible that EPUB publications are, the greater the potential audience for them. Note This specification does not integrate the accessibility requirements to allow them to adapt and evolve independent of the EPUB specification — accessibility practices often need more frequent updating. The accessibility specification is also intended for use with past, present, and future versions of EPUB. The approach of a separate specification ensures that the evolution of EPUB does not lock accessibility in time (i.e., it allows producers of older versions of EPUB to reference the latest accessibility requirements). This section is non-normative. The particularity of an is its structure. The EPUB format provides a means of representing, packaging, and encoding structured and semantically enhanced web content — including HTML, CSS, SVG, JavaScript, and other resources — for distribution in a single-file container. This means that EPUB 3's security and privacy issues are primarily linked to the features of those formats, and closely mirror the threats presented by web content. Although content risks are often equated with deliberately malicious authoring intent, need to be aware that many practices followed with the best of intentions may expose users to privacy and security issues. The rest of this section explores the risk model of EPUB 3 with the aim of helping EPUB creators recognize and mitigate these risks. This section is non-normative. pose a variety of privacy and security threats to unsuspecting users. Many of these threats intersect with web content, but EPUB also introduces its own unique methods of attack that can be used to trick users into accessing malicious content or into providing sensitive information. Some of the more important attack vectors that and users need to be aware of include: Embedding of remote resources EPUB 3 allows some to be , specifically resources whose sizes can negatively affect the downloading and opening of the EPUB publication (e.g., audio, video, and fonts). Although helpful for users when used as intended, these exemptions can also be used to inject malicious content into a publication. This threat is not limited to accessing content created by a bad actor. If EPUB creators embed content from untrustworthy sources (e.g., third party audio and video), there is always the possibility that users may receive compromised resources. Checking for malware and exploits at distribution time is not always reliable, either, as the malicious content can be swapped in any time after publication, unlike resources that come embedded in the . The of an EPUB is both unknown to the EPUB creator and specific to each reading system implementation. Consequently, if the EPUB creator hosts on a web server they control, the server effectively cannot use security features that require specifying allowable origins, such as headers for , , or 308. Linking to external resources Whether intentional or not, links to external web sites and resources expose users to potential exploits that can compromise their reading system or operating system. Although external links will typically open in a web browser, and be subject to the browser security model, this does not protect users from all exploits. Even if the intentions of the EPUB creator are not malicious, adding tracking information to external links is problematic for user privacy as it can allow a user's activity to be tracked without their consent. Broken-link hijacking — when a domain expires and is bought by another party to exploit the links to it — can also lead to users being taken to resources the EPUB creator did not intend. Including malicious content Resources embedded in the EPUB container are not immune to malicious actors, especially when EPUB publications are obtained from untrusted sources. Resources may contain exploits or forms that may submit sensitive information to unintended parties. Such actors may also try to gain access to using file indirection techniques, such as symbolic links or file aliases. The use of third-party content, such as games and quizzes, may also lead to security and privacy issues if the EPUB creator is not able to fully vet the content. Allowing scripts network access When scripts can access a device's network, it provides a variety channels to exploit the user:
Network access may allow third-party content to exploit the user even if it was not the EPUB creator's intent. Securing content with digital rights management The encryption and decryption of EPUB publications using digital rights management schemes may allow personally identifiable information about the user, what vendors they use, and their reading choices to be relayed to third parties. The effectiveness of these attacks also often depends on tricking users into believing that the publication they are interacting with is from a trustworthy source. These deceptions can take the following forms: Falsified publication information The EPUB publication may include false information about itself to trick users into believing that it comes from a legitimate source. A malicious EPUB creator might, for example, fake the title, authors, identifiers, and publisher for the work. Although this misinformation itself does not present an immediate harm, it could lead users to trust malicious forms, links, and other content within the EPUB publication believing it comes from a reliable source. Spoofed platforms Malicious EPUB creators may also design their content to imitate or replicate a platform's experience to trick users into trusting their content. EPUB 3 tries to avoid extending the underlying technologies it builds on, but it has introduced some new features. The restricted scope of these features limits the threats they might pose, however:
The one potential exception is the [] that allows to query information about the current . EPUB creators need to be mindful that they only use the information exposed by this object to improve the rendering of their content (i.e., avoid using the information to profile the user and their environment). Although cannot prevent every method of exploiting users, they are ultimately responsible for the secure construction of their content. That means that they need to take precautions to limit the exposure of their to the types of described in the previous section. Some practical steps include:
EPUB creators also need to consider the privacy rights of users and avoid situations where they are intentionally collecting data. Ideally, EPUB creators SHOULD NOT track their users, but this is not realistic for all types of publishing. When EPUB creators have to track users, they SHOULD obtain the approval of the user to collect information prior to opening the EPUB publication (e.g., in educational course work). If this is not possible, they SHOULD obtain permission when users access the EPUB publication for the first time. EPUB creators SHOULD also allow users to opt out of tracking, and provide users the ability to manage and delete any data that is collected about them. EPUB creators also need to consider the inadvertent collection of information about users. Linking to content on a publisher's web site, or remotely hosting resources on their servers, can lead to profiling users, especially if unique tracking identifiers are added to the URLs. When collecting and storing user information within an EPUB publication (e.g., through the use of and []), EPUB creators need to consider to potential for data theft by other EPUB publications on a . Although [] introduces a for EPUB publications, which limits the potential for attacks, there is still a risk that reading systems will allow EPUB publications access to shared persistent storage (e.g., older reading systems that have not been updated and non-conforming newer reading systems). Consequently, EPUB creators SHOULD NOT store sensitive user data in persistent storage. If EPUB creators must store sensitive data, they SHOULD encrypt the data to prevent trivial access to it in the case of an exploit. When publishers and vendors must use digital rights management schemes, they should prefer schemes that do not utilize or transmit information about the user or their content to external parties to perform encryption or decryption. To maximally reduce security and privacy risks, EPUB creators SHOULD produce their EPUB publications with the goal of long-term preservation. EPUB publications created this way are normally self-contained, not dependent on network access, and not encrypted with digital rights management, removing many of the possible attack vectors. [] is an example of such a preservation format for EPUB publications. While it is understood that not all EPUB creators can achieve these levels of self-containment, following as many of these practices as possible will still benefit overall user privacy and security. This specification contains certain features that are not yet fully supported in , that the Working Group no longer recommends for use, or that are only retained for interoperability with EPUB 2 reading systems. This section defines the meanings of the designations attached to these features and their support expectations. A under-implemented feature is a feature introduced prior to EPUB 3.3 for which the Working Group has not been able to establish enough . These features are considered important to retain despite this limitation because they are known to be implemented by (i.e., their deprecation would invalidate existing content) and/or they are integral to the content model on which EPUB is built. If this specification designates a feature as under-implemented, EPUB creators MAY use the features as described. Note should alert EPUB creators to the presence of under-implemented features when encountered in EPUB publications but must not treat their inclusion as a violation of the standard (i.e., not emit errors or warnings). Caution Whether under-implemented labels are removed or replaced by deprecation in a future version of the standard cannot be determined at this time. EPUB creators should strongly consider the interoperability problems that may arise both now and in the future when using these features. Note The marking of features as under-implemented is a one-time event to account for the different process under which EPUB was developed prior to being brought into W3C. This label will not be used for new features developed under W3C processes. A deprecated feature is one the Working Group no longer recommends for use in this version of the specification. Deprecated features typically have limited or no support in and/or usage in . If this specification designates a feature as deprecated, SHOULD NOT use the feature in their EPUB publications. Note should alert EPUB creators to the presence of deprecated features when encountered in EPUB publications. The following table lists the and [] allowed in . [] MAY use these external identifiers only in with the listed media types [] specified in their declarations. (Refer to for more information.) Media Type(s) Public Identifier System Identifier
313 314 47 316 317 29 319 320 This section is non-normative. Structural semantics add additional meaning about the specific structural purpose an element plays. The The applied semantics refine the meaning of their containing elements without changing their nature for assistive technologies, as happens when using the similar 322 attribute []. The attribute does not enhance the accessibility of the content, in other words; it only provides hints about the purpose. Semantic metadata enriches content for use in publishing workflows and for author-defined purposes. It also allows to learn more about the structure and content of a document (e.g., to enable in media overlays). This specification defines a method for adding structural semantics using the attribute axis: instead of adding new elements, can append the 9 attribute to existing elements to add the desired semantics. Attribute Name: 9 Namespace: 325 Usage: Refer to the requirements for , , and . Value: A white space-separated list of values, with restrictions as defined in . White space is the set of characters as defined in []. Caution Although the 9 attribute is similar in nature to the 322 attribute [], the attributes serve different purposes. The values of the 9 attribute do not enhance access through assistive technologies like screen readers as they do not map to the accessibility APIs used by these technologies. This means that adding 9 values to semantically neutral elements like [] 330 and 50 does not make them any more accessible to assistive technologies. Only ARIA roles influence how assistive technologies understand such elements. The 9 attribute is consequently only intended for publishing semantics and enhancements. Reading systems may use 9 values to provide accessibility enhancements like built-in read aloud or media overlays functionality where interaction with assistive technologies is not essential. Refer to Digital Publishing WAI-ARIA Module [] for more information about accessible publishing roles. The 9 attribute inflects semantics on the element on which it appears. Its value is one or more white space-separated terms stemming from external vocabularies associated with the document instance. The for the 9 attribute is the EPUB 3 Structural Semantics Vocabulary []. EPUB creators MAY include unprefixed terms that are not part of this vocabulary, but the preferred method for adding custom semantics is to use for them. Refer to for more information. This appendix defines a general set of mechanisms by which attributes in this specification can reference terms from vocabularies. It also defines EPUB-specific vocabularies for use with the attributes. This section is non-normative. EPUB defines a formal method of referencing terms and properties defined in metadata and semantic vocabularies using the . The 9 attribute uses this data type in and to add , for example, while the 72 and 29 attributes use the data type to define properties and relationships in the . A property value is like a CURIE [] — it represents a URL [] in compact form. The expression consists of a prefix and a reference, where the prefix — whether literal or implied — is a shorthand mapping of a URL that typically resolves to a term vocabulary. When a converts the prefix to its URL representation and combines with the reference, the resulting URL normally resolves to a fragment within that vocabulary that contains human- and/or machine-readable information about the term. To reduce the complexity for authoring, each attribute that takes a property data type also defines a . Terms and properties referenced from the default vocabularies do not include a prefix as the mapping reading systems use to map to a URL is predefined. The power of the property data type lies in its easy extensibility. To incorporate new terms and properties, only need to declare a . In another authoring convenience, this specification also for many commonly used publishing vocabularies (i.e., their declaration is optional). The following sections provide additional details on the property data type and vocabulary association mechanism. The property data type is a compact means of expressing a URL [] 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). 339 [ , ":" ] , ; 339 ? xsd:NCName ? ; 339 ? [] ? ; /* as defined in [] */ This specification derives the property data type from the CURIE data type defined in []. A property represents a subset of CURIEs. There are two key differences from CURIEs, however:
When an omits a prefix from a property value, the expressed reference represents a term from the for that attribute. A default vocabulary is one that do not have to declare a for in order to use its terms and properties where a is expected. EPUB creators MUST NOT add a prefix to terms and properties from a default vocabulary. EPUB creators MUST NOT assign a prefix to the URLs associated with these vocabularies using the attribute. Note Refer to the definition of each attribute that takes a for more information about its default vocabulary. The 0 attribute defines prefix mappings for use in . The value of the 0 attribute is a white space-separated list of one or more prefix-to-URL mappings of the form: (EBNF productions ISO/IEC 14977) All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F). 339 , { , { } , } ; 339 , ":" , , { } , ? xsd:anyURI ? ; 339 ? xsd:NCName ? ; 339 x20 ;339 ( x20 |x9 |xD |xA) ;With the exception of , MUST declare all prefixes used in a document. MUST only specify the 0 attribute on the [] of the respective format. The attribute is not namespaced when used in the . EPUB creators MUST declare the attribute in the namespace 325 in and . Note Although the 0 attribute is modeled on the identically named 0 attribute in [], EPUB creators cannot use the attributes interchangeably. The 0 attribute without a namespace in EPUB content documents is the RDFa attribute. It is common for both attributes to appear in EPUB content documents that also specify RDFa expressions. Note that for , prefixes MUST be declared on the [] root 355 element. To avoid conflicts, EPUB creators MUST NOT use the 0 attribute to declare a prefix that maps to a . EPUB creators MUST NOT declare the prefix '_' as this specification reserves this prefix for future compatibility with RDFa [] processing. For future compatibility with alternative serializations of the package document, EPUB creators MUST NOT declare a prefix for the Dublin Core /elements/1.1/ namespace []. MUST use only the [] elements . Caution Although reserved prefixes are an authoring convenience, should avoid relying on them as they may cause interoperability issues. will often reject new prefixes until their developers update the tools to the latest version of the specification, for example. EPUB creators should declare all prefixes they use to avoid such issues. MAY use reserved prefixes in attributes that expect a without declaring them in a . EPUB creators SHOULD NOT override reserved prefixes in the . The reserved prefixes an EPUB creators can use depends on the context: Package document EPUB creators MAY use the following prefixes in attributes without having to declare them. Prefix URL a11y http://www.idpf.org/epub/vocab/package/a11y/# dcterms http://purl.org/dc/terms/ marc http://id.loc.gov/vocabulary/ media http://www.idpf.org/epub/vocab/overlays/# onix http://www.editeur.org/ONIX/book/codelists/current.html# rendition http://www.idpf.org/vocab/rendition/# schema http://schema.org/ xsd http://www.w3.org/2001/XMLSchema# Structural Semantics EPUB creators MAY use the following reserved prefixes in the without having to declare them. Prefix URL msv http://www.idpf.org/epub/vocab/structure/magazine/# prism http://www.prismstandard.org/specifications/3.0/PRISM_CV_Spec_3.0.htm# The fields in the vocabulary definition tables have the following implicit requirements: Allowed Values Specifies the REQUIRED type of value using [] datatypes. Applies To Specifies which publication resource type(s) MAY specify the property on. This field appears for properties used in the . Cardinality Specifies the number of times EPUB creators MAY specify the property, whether globally or attached to another element or property. Properties with a minimum cardinality of one MUST be specified. Description Describes the purpose of the property and specifies any additional usage requirements that EPUB creators must follow. Example Provides non-normative usage examples. Extends Identifies what EPUB creators MAY associate the property with. This field appears for properties that define and . Name Specifies the name of the property as it MUST appear in the metadata. The properties in this vocabulary are usable in the 72 attribute. Unless indicated otherwise in its "Extends" field, the properties defined in this section are used to define : in other words, a 364 attribute referencing a resource or expression being augmented. The prefix URL for is 365. Name: 49 Description: The 49 property provides an alternate expression of the associated property value in a different language and/or script. The language tags of the alternate-script property and its associated property — as expressed by their respective in-scope xml:lang attributes — MUST NOT be the same. This property is typically attached to 368 and 08 properties for internationalization purposes. Allowed value(s): 370 Cardinality: 371 Extends: All properties. Name: 58 Description: The 58 property identifies the system or scheme the referenced element's value is drawn from. Allowed value(s): 370 Note The former IDPF EPUB 3 Working Group maintained a registry of subject authorities for use with this property. This Working Group no longer maintains the registry. Cardinality: 375 Extends: Name: 377 Description: The 377 property identifies the name of a collection to which the belongs. An EPUB publication MAY belong to one or more collections. It is also possible to chain these properties using the to indicate that one collection is itself a member of another collection. To allow to organize collections and avoid naming collisions (e.g., unrelated collections might share a similar name, or different editions of a collection could be released), SHOULD provide an identifier that uniquely identifies the instance of the collection. The 380 property must carry this identifier. The collection MAY more precisely define its nature by attaching a property. The position of the EPUB publication within the collection MAY be provided by attaching a . Allowed value(s): 370 Cardinality: 371 Extends: Applies to the EPUB publication and can refine other instances of itself. Name: 381 Description: The 381 property indicates the form or nature of a collection. When the 381 value is drawn from a code list or other formal enumeration, SHOULD attach a to identify its source. This specification also defines the following collection types when no scheme is specified: 389 A sequence of related works that are formally identified as a group, typically open-ended with works issued individually over time. 390 A finite collection of works that together constitute a single intellectual unit, typically issued together and able to be sold as a unit. Note Although are not required to support these values, specifying them provides the option to group related in more meaningful ways. Allowed value(s): 370 Cardinality: 375 Extends: Name: 92 Description: The 92 property indicates the numeric position in which to display the current property relative to identical metadata properties. This property only applies where precedence rules have not already been defined (e.g., precedence is given to based on their appearance in document order). Allowed value(s): 396 Cardinality: 375 Extends: All properties. Name: 48 Description: The 48 property provides the normalized form of the associated property for sorting. Allowed value(s): 370 Cardinality: 375 Extends: All properties. Name: 382 Description: The 382 property indicates the numeric position in which the is ordered relative to other works belonging to the same group (whether all EPUB publications or not). can attach the 382 property to any metadata property that establishes the group but it is typically associated with the . An EPUB publication can belong to more than one group. Allowed value(s): A single 396 or series of decimal-separated numbers (e.g., 407 or 408). Cardinality: 375 Extends: All properties. Name: 74 Description: The 74 property indicates the form or nature of an 412. When the 74 value is drawn from a code list or other formal enumeration, SHOULD attach a to identify its source. Allowed value(s): 370 Cardinality: 375 Extends: Use of this property is . Refer to the in [] for more information. Name: 46 Description: The 46 property describes the role of a 368, 423 or 424 in the creation of an EPUB publication. When the 46 value is drawn from a code list or other formal enumeration, SHOULD attach a to identify its source. When attaching multiple roles to an individual or organization, the importance of the roles should match the document order of their containing 9 elements (i.e., the first 9 element encountered should contain the most important role). Allowed value(s): 370 Cardinality: 371 Extends: Name: 434 Description: The 434 property indicates a unique aspect of an adapted source resource that has been retained in the . This specification defines the 436 value to indicate that the referenced 71 element is the source of the defined in the content. Allowed value(s): 436 Cardinality: 375 Extends: Note See [] for information on how to provide accessible page navigation. Name: 59 Description: The 59 property provides a subject code. Allowed value(s): 370 Cardinality: 375 Extends: Name: 91 Description: The 91 property indicates the form or nature of a 08. When the 91 value is drawn from a code list or other formal enumeration, SHOULD attach a to identify its source. When a scheme is not specified, SHOULD recognize the following title type values: 452, 453, 454, 6, 456 and 457. Allowed value(s): 370 Cardinality: 375 Extends: The properties in this vocabulary are usable in the metadata 29 and 6 attributes. The prefix URL for is 464. The following values can be used in the 4 element to establish the relationship of the resource referenced in the . Name: 468 Description: The 468 keyword is a subset of the for links. It differs as follows:
475 Extends: Only applies to the EPUB publication or collection. MUST NOT be used when the is present. Example: 477 Use of the 478 keyword is . It is replaced by the keyword with the value " 481". Refer to the in [] for more information. Use of the 483 keyword is . It is replaced by the keyword with the value " 486". Refer to the in [] for more information. Use of the 488 keyword is . It is replaced by the keyword with the value . Refer to the in [] for more information. Name: 479 Description: Indicates that the referenced resource is a metadata record. The media type of the record MUST be identified in the when this keyword is specified. For a list of commonly linked metadata record types, refer to the EPUB Linked Metadata Guide If the type of record cannot be identified from the media type, an can be assigned in the . Cardinality: 475 Extends: Only applies to the or collection. MUST NOT be used when the is present. Example: 497 Name: 498 Description: Indicates that the referenced audio file provides an aural representation of the expression or resource (typically, the title or creator) specified by the refines attribute. The media type of the audio file MUST be identified in the when this keyword is specified. Cardinality: 475 Extends: All properties. The MUST be present when this value is used. Example: 502 Use of the 503 keyword is . It is not replaced by another linking method. Refer to the in [] for more information. Use of the 505 keyword is . Refer to the in [] for more information. The following values can be used in the 6 attribute to establish the type of record a referenced resource represents. These values are provided for record formats that cannot be uniquely identified by their media type. Name: 490 Description: The 490 property indicates the referenced resource is an ONIX record []. Example: 511 The prefix URL for is 512. The " 513" prefix is with the package rendering properties and does not have to be declared in the . Note Unlike the other vocabularies in this appendix, the properties in the Package Rendering Vocabulary consist of a mix of properties (expressed in The usage requirements are also defined in not in this appendix. The following table provides a map to the properties, overrides, and where they are defined. Property Overrides Defined in 035
044
051
085 (Deprecated) — 9
developers may introduce functionality not defined in this specification to address reading system-specific issues rendering . To facilitate this experimentation, MAY include custom properties and overrides for use in the provided they do not use the 513 prefix. Note Custom properties should only address rendering issues specific to a particular reading system. This specification should be extended to provide extensions that multiple independent reading systems can use. The properties in this vocabulary are usable in the manifest The prefix URL for is 544. Name: 80 Description: The 80 property identifies the described as the cover image for the . Applies to: All Cardinality: 547 Name: 90 Description: The 90 property indicates that the described contains one or more instances of MathML markup. Applies to: Cardinality: 475 Name: 3 Description: The 3 property indicates that the described publication resource constitutes the of the . Applies to: The EPUB navigation document Cardinality: 553 Name: 554 Description: The 554 property indicates that the described contains one or more internal references to other publication resources that are located outside of the . Refer to for more information. Applies to: All publication resources with the capability of internal referencing (e.g., , , CSS style sheets and ). Cardinality: 475 Name: 77 Description: The 77 property indicates that the described is a (i.e., contains scripting and/or [] 12 elements). Applies to: Cardinality: 475 Name: 94 Description: The 94 property indicates that the described embeds one or more instances of SVG markup. This property MUST be set when SVG markup is included directly in the resource and MAY be set when the SVG is referenced from the resource (e.g., from an [] 5, 93 or 98 element). Applies to: ; the value is implied for . Cardinality: 475 Name: 74 Description: The 74 property indicates that the described contains one or more instances of the . Applies to: . Cardinality: 475 The properties in this vocabulary are usable in the spine The prefix URL for is 573. Name: 574 Description: The 574 property indicates that the first page of the associated 2 element's represents the left-hand side of a two-page spread. The is an alias for this property. Refer to for more information about their use. Name: 578 Description: The 578 property indicates that the first page of the associated 2 element's represents the right-hand side of a two-page spread. The is an alias for this property. Refer to for more information about their use. The properties in this vocabulary are usable in the 72 attribute. The prefix URL for is 584. The prefix " 298" is with properties in this vocabulary and does not have to be declared in the . Name: 282 Description: -defined CSS class name to apply to the currently playing element. Allowed value(s): 370 Cardinality: 547 Example: 589 Name: 294 Description: The duration of the entire presentation or of a specific . The specified durations account for the audio clips known at authoring time, and so exclude live streaming from external resources and speech synthesis. Allowed value(s): MUST be a [] . Cardinality: Exactly one for the and for each . Example: 591 Name: 297 Description: Name of the narrator. Allowed value(s): 370 Cardinality: 475 Example: 595 Name: 283 Description: Author-defined CSS class name to apply to the document element when playback is active. Allowed value(s): 370 Cardinality: 547 Example: 599 This appendix describes the prefixed CSS properties supported by EPUB. Note The prefix definitions are no longer being synchronized with their CSS counterparts. In some cases, the unprefixed versions of these properties now support additional values. may not support the new syntax with the prefixed properties, so are advised to use the unprefixed versions for newer features. This section describes the 600 prefixed properties for []. This property is a prefixed version of the []. Name: 1 Value: mixed | upright | sideways | sideways-right For compatibility with existing content, the 1 property also supports the deprecated 604, 605, and 606 keywords. The following table specifies the effect these have when specified. Deprecated value Value to be used 604 608 605 610 606 610 This property is a prefixed version of the [], with the same syntax and behavior. Name: 2 Value: horizontal-tb | vertical-rl | vertical-lr These properties are prefixed versions of the [], although 4 is deprecated. Name: 3 Value: none | all Name: 4 (deprecated) Value: none | horizontal | horizontal For compatibility with existing content, the 3 and 4 properties also support a number of deprecated keywords. The following table specifies the effect these have when specified. Prefixed version CSS equivalent 621 622 623 624 625 622 627 624 629 no equivalent This section describes the 600 prefixed properties (and one prefixed value) for []. This property is a prefixed version of the []. Name: 5 Value: none | manual | auto | all For compatibility with existing content, the 5 property also supports the deprecated 634 keyword. The value is no longer supported in CSS and there is no equivalent to use in its place. This property is a prefixed version of the []. Name: 6 Value: auto | loose | normal | strict This property is a prefixed version of the []. Name: 7 Value: auto | start | end | left | right | center | justify This property is a prefixed version of the []. Name: 8 Value: normal | keep-all | break-all This property is a prefixed value for the []. Name: 9 Value: -epub-fullwidth For compatibility with existing content, the 9 property also supports the deprecated 644 keyword. When specified, this has the same effect as 645. This section describes the 600 prefixed properties for []. This property is a prefixed version of the []. Name: 0 Value: This property is a prefixed version of the []. Name: 1 Value: [ over | under ] && [ right | left ] This property is a prefixed version of the []. Name: 2 Value: none | [ [ filled | open ] || [ dot | circle | double-circle | triangle | sesame ] ] | This property is a prefixed version of the []. Name: 3 Value: auto | [ under || [ left | right ] ] | alphabetic For compatibility with existing content, the value 3 property also supports the deprecated 656 keyword. When specified, this has the same effect as 657. This section is non-normative. As the of the 4 tag, that was used in earlier versions of EPUB 3, is not an officially recognized standard, this specification defines a basic syntax in order to allow to express for use rendering . The syntax of this grammar is also influenced by the parsing algorithm for the 659 tag, as defined in []. The syntax is intentionally left as generic as possible as it is not in this specification's scope to define all the possible properties and values. It only defines the basic requirements for defining a property and value pair as well as the possible separators between expressions. For , a 660 tag [] MUST have 88 and 663 attributes that conform to the following definition: name The value of the 664 attribute [] after [] MUST be 660. content The value of the 666 attribute [] after [] MUST be of the following form: (EBNF productions ISO/IEC 14977) All terminal symbols are in the Unicode Block 'Basic Latin' (U+0000 to U+007F). = , { , } ; = , [ , ] ; = ? character data ? ; = ? character data ? ; = , { } ; = ( ";" | "," | ) ; = [ ], "=", [ ] ; = x20 ;The only restriction on property and is that they MUST NOT contain or the . The authoring requirements in this section apply after [] (i.e., after a reading system strips leading and trailing whitespace and compacts all instances of multiple whitespace within the attribute to single spaces). EPUB creators MAY include any valid [] in the authored tag so long as the result is valid to this definition. There are no restrictions on any other attributes allowed on the element by the [] grammar. Note For more information about specifying the required 089 and 090 properties, and their required values, refer to . Although the 4 tag allows EPUB creators to use properties other than 089 and 090, and to not include values for these properties, such use is strongly discouraged. Setting other properties may have unintended consequences on the rendering of fixed-layout documents. This section is non-normative. A schema for is available at https://github.com/w3c/epubcheck/tree/master/src/main/resources/com/adobe/epubcheck/schema/30/package-30.nvdl. Validation using this schema requires a processor that supports [], [], [] and []. Note The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone. Note These schemas may be updated and corrected outside of formal revisions of this specification. As a result, they are subject to change at any time. A schema for is available at 674. Validation using this schema requires a processor that supports [] and []. The schema for is included in []. The schema for is included in []. A schema for is available at https://github.com/w3c/epubcheck/tree/main/src/master/resources/com/adobe/epubcheck/schema/30/media-overlay-30.nvdl. Validation using this schema requires a processor that supports [], [], [] and []. Note The NVDL schema layer can be substituted by a multi-pass validation using the embedded RELAX NG and ISO Schematron schemas alone. This section is non-normative. Consider the following extracts of a and an : The various resources in the can be categorized as follows. (Refer to for more information about these categories.) 677 The resource is a metadata record, stored in the . It is linked via a`` element in the package document metadata. It is therefore a on the (i.e., is not listed in the ). It is not part on any other planes. 679 The resource is a metadata record, stored remotely. It is linked via a 681 The resource is an XHTML document. It is listed in the [[EPUB spine | spine=]. It is a on the manifest plane, a , an on the , and is not present on the . No fallback is necessary. 682 The resource is the . It is not listed in the spine. It is a publication resource on the manifest plane, a container resource, and is not present on either the spine plane or the content plane. No fallback is necessary. 683 The resource is a CSS file. It is not listed in the spine but is referenced from an [] element. It is a publication resource on the manifest plane, a container resource, is not present on the spine plane, and is a on the content plane. No fallback is necessary. 685 The resource is a TrueType font file. It is not listed in the spine but is referenced from a CSS file. It is a publication resource on the manifest plane, is a container resource, is not present on the spine plane, and is a core media type resource on the content plane. No fallback is necessary. 686 The resource is a TrueType font file. It is not listed in the spine but is referenced from a CSS file. It is a publication resource on the manifest plane, is a , is not present on the spine plane, and is a core media type resource on the content plane. No fallback is necessary. 687 The resource is a font file in Compact Font Format. It is not listed in the spine but is referenced from a CSS file. Its media type is not listed as a . It is a publication resource on the manifest plane, a container resource, is not present on the spine plane, and is an on the content plane. No fallback is necessary. 688 The resource is a Pronunciation Lexicon file. It is not listed in the spine but is referenced from an [] element. It is a publication resource on the manifest plane, a container resource, not present on the spine plane, and is an exempt resource on the content plane. No fallback is necessary. 690 The resource is a PNG image file. It is not listed in the spine but is referenced from an [] 65 element. It is a publication resource on the manifest plane, a container resource, is not present on the spine plane, and is a core media type resource on the content plane. No fallback is necessary. 692 The resource is a PNG image file. It is referenced via an [] 11 element. Because it is referenced from a hyperlink, it must be listed in the spine. It is a publication resource on the manifest plane, a container resource, a on the spine plane, and a core media type resource on the content plane. As a foreign content document, a fallback is required, which is provided via a . 694 The resource is an XHTML document. It is the "target" of a manifest fallback so is not explicitly listed in the spine (but it "replaces" the existing spine item when needed). It is a publication resource on the manifest plane, a container resource, an EPUB content document on spine plane, and, because it is not "used" when rendering another EPUB content document, it is not present on the content plane. No fallback is necessary. 695 The resource is a High Efficiency (HEIC) image file. It is not listed in the spine but is referenced from an [] 53 element. Its media type is not listed as a . It is a publication resource on the manifest plane, a container resource, is not present on the spine plane, and is a foreign resource on the content plane. As a foreign resource, a fallback is required, which is provided via the sibling [] 65 element in an [] 24 element. 699 The resource is a PNG image file. It is not listed in the spine but is referenced from an [] 65 element that is used as an intrinsic fallback of the [] 24 element. It is a publication resource on the manifest plane, a container resource, is not present on the spine plane, and is a core media type resource on the content plane. No fallback is necessary. 702 The resource is an XHTML document. It is not listed in the spine but is referenced from an [] 95 element. It is a publication resource on the manifest plane, a container resource, is not present on spine plane, and, because it is "used" when rendering another EPUB content document, a core media type resource on the content plane. No fallback is necessary. 704 The resource is referenced via an [] 11 element and is not stored in the EPUB container. Reading systems will normally open this link via a separate browser instance. It is not on any planes defined by this specification. Additional examples on the usage of different types of resources can be found in . Consider the following example : and the following file 706: and the following file 707: From these examples, it is true that:
This example demonstrates the use of the OCF format to contain a signed and encrypted within an . Ordered list of files in the OCF ZIP container: The contents of the 01 file The contents of the 52 file The contents of the 57 file 0 The contents of the 53 file 1 The contents of the 719 file 2 The following are examples of allowed clock values:
This appendix registers the media type 8 for the EPUB package document. This registration supersedes RFC4839 (see https://www.rfc-editor.org/rfc/rfc4839). The package document is an XML file that describes an EPUB publication. It identifies the resources in the EPUB publication and provides metadata information. The package document and its related specifications are maintained and defined by the World Wide Web Consortium (W3C). MIME media type name: 732 MIME subtype name: 733 Required parameters: None. Optional parameters: None. Encoding considerations: 8bit if UTF-8; binary if UTF-16. Package documents are in XML, represented either in UTF-8 or UTF-16. When the package document is written in UTF-8, the file is 8bit compatible. When it is written in UTF-16, the binary content-transfer-encoding must be used. For further details, see []. 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 3 specification 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 3 specification located at https://www.w3.org/TR/epub-33/. The EPUB 3 specification supersedes the Open Packaging Format 2.0.1 specification, which is located at https://idpf.org/epub/20/spec/OPF_2.0.1_draft.htm and which also uses the 734 media type. Applications which use this media type: This media type is in wide use for the distribution of ebooks in the EPUB format. Additional information: Magic number(s): none File extension(s): 735 Macintosh File Type Code(s): TEXT Fragment identifiers: EPUB Canonical Fragment Identifiers are custom fragment identifiers defined for . They may be used to refer to an arbitrary content within any defined for the publication. These identifiers are defined at https://idpf.org/epub/linking/cfi/. Person & email address to contact for further information: EPUB 3 Working Group ([email protected]) Intended usage: COMMON Author/Change controller: World Wide Web Consortium (W3C) This appendix registers the media type 9 for the EPUB Open Container Format (OCF). An OCF ZIP container, or EPUB container, file is a container technology based on the zip archive format (see https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT). It is used to encapsulate the EPUB publication. OCF and its related standards are maintained and defined by the World Wide Web Consortium (W3C). MIME media type name: 732 MIME subtype name: 738 Required parameters: None. Optional parameters: None. Encoding considerations: OCF ZIP container files are binary files encoded in the 739 media type. Security considerations: All processors that read OCF ZIP container files should rigorously check the size and validity of data retrieved. In addition, because of the various content types that can be embedded in OCF ZIP container files, 9 may describe content that poses security implications beyond those noted here. However, only in cases where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. In such cases, matters of security would fall outside the domain of this registration document. Security considerations that apply to 739 also apply to OCF ZIP container files. Interoperability considerations: None. Published specification: This media type registration is for the EPUB Open Container Format (OCF), as described by the EPUB 3 specification located at 742. The EPUB 3 specification supersedes both RFC 4839 and the Open Container Format 2.0.1 specification, which is located at 743, and which also uses the 9 media type. Applications that use this media type: This media type is in wide use for the distribution of ebooks in the EPUB format. Additional information: Magic number(s): 0: 745, 30: 01, 38: 9 File extension(s): OCF ZIP container files are most often identified with the extension 00. Macintosh file type code(s): ZIP Fragment identifiers: EPUB Canonical Fragment Identifiers are custom fragment identifiers defined for . They may be used to refer to an arbitrary content within any defined for the publication. These identifiers are defined at https://idpf.org/epub/linking/cfi/. Person & email address to contact for further information: EPUB 3 Working Group ([email protected]) Intended usage: COMMON Author/change controller: World Wide Web Consortium (W3C)
This section is non-normative. Note that this change log only identifies substantive changes since EPUB 3.2 — those that affect the conformance of or are similarly noteworthy. For a list of all issues addressed during the revision, refer to the Working Group's issue tracker.
This section is non-normative. Specifications, like art, are human creations. No human has done more for EPUB than Garth Conboy, who has been there every step of the way, from the very first OEB 1.0 in 1999 to today's EPUB 3.3. None of this would have happened without Garth's vision, knowledge, and preternatural good nature. We dedicate EPUB 3.3 to his memory. We are forever in your debt, Garth. The following members of the EPUB 3 Working Group contributed to the development of this specification: |
