EPUB Reading Systems 3.4

This specification uses terminology defined in EPUB 3.4 [epub-34].

It also defines the following term:

content display area

The area within the viewport dedicated to the display of EPUB content documents. The content display area excludes any borders, margins, headers, footers, or other decoration a EPUB reading system might inject into the viewport.

In the case of synthetic spreads, the viewport contains two content display areas.

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, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

All algorithm explanations are non-normative.

Whether a reading system has to support a feature is mentioned at the beginning of its section. To be conformant with this specification, reading systems MUST support all required features as well as all applicable conditionally-required features (e.g., to support image rendering if the reading system has a viewport) as defined in their respective sections.

When supporting recommended and optional features, reading systems MUST meet all normative requirements as defined in their respective sections.

When reading system developers opt not to support a recommended or optional feature, it does not always mean none of the normative requirements of the section apply. In some cases, there might be alternative requirements when not implementing a feature (e.g., to process fallbacks when scripting is not supported). Reading systems MUST meet these alternative requirements when not supporting a feature.

Reading systems do not have to load EPUB publications, or resources within them, when they violate content authoring or processing requirements.

If a reading system has a viewport, it MUST support the image core media type resources [epub-34].

If it has the capability to render prerecorded audio, it MUST support the audio core media type resources [epub-34].

Reading systems MAY support an arbitrary set of foreign resource types, and if a foreign resource is not supported, MUST process fallbacks as defined in foreign resources [epub-34].

Reading systems SHOULD support remote resources, as defined in Resource locations [epub-34].

To limit the risk of network attacks, reading systems SHOULD only load remote resources referenced via the https URI scheme [rfc9110].

Reading systems MUST prevent data URLs [rfc2397] from opening in top-level browsing contexts [html], except when initiated through a reading system affordance such as a context menu. If a reading system does not use a top-level browsing context for top-level content documents, for example if the top-level content document is an SVG, it MUST also prevent data URLs from opening as though they are top-level content documents.

Reading Systems MUST prevent access to resources referenced via file URLs [rfc8089].

A reading system MUST use a non-validating XML processor [xml] that:

• does not read external DTD subsets [xml];
• conforms to [xml-names].

As part of processing publication resources, a reading system has to process the attributes to set the language and the base directions in XHTML content documents or SVG content documents, as well as the xml:lang attribute for all XML documents (e.g., the package document and media overlay documents).

Furthermore, a reading system MUST also process the dir attribute [epub-34] for the package document, where the base direction specified by dir applies to the element where it is specified, and to all elements in its content unless overridden with another instance of dir. (See also 5.1 Base direction for further details.)

In the absence of this information in a publication resource, reading systems MUST NOT assume either the language or the base direction of that resource from information expressed in the package document (i.e., in xml:lang and dir attributes, in hreflang attributes on link elements, or from dc:language elements [epub-34]). Refer to a resource's formal specification for more information about to handle the absence of explicit language or direction information.

Reading systems MAY support network access to retrieve remote resources and to allow scripted content documents to communicate with web-hosted APIs and retrieve resources.

Providing network access, however, increases both the security risks to the reading systems and the security and privacy risks to users. These risks are often unique to reading systems and the platforms they run on — the browser cores that most reading systems are built on do not offer the same security and privacy controls as web browsers themselves. Consequently, developers need to use extra caution when allowing network access, and more thoroughly test that their reading systems are not vulnerable to attacks. More information about these risks is provided in 15. Security and privacy.

If reading system developers allow network access, it is RECOMMENDED both that they:

• notify users when network activity occurs; and
• let users block access to the network (e.g., disable network access for the reading system globally or for a particular EPUB publication).

When a link has an http or https scheme [url], reading systems:

• SHOULD obtain the user's consent before opening the link.
• SHOULD open the link in a new browser instance to ensure that the browser's security and privacy controls are available to users.

For links that have schemes that require a helper application to load, reading systems SHOULD obtain the user's consent and follow platform guidance for opening the helper application.

A reading system:

• MUST treat any OCF ZIP container that splits the content into segments [zip] as in error.

• MUST treat any OCF ZIP container that uses compression techniques other than Deflate [rfc1951] as in error.

• MUST support the ZIP64 extensions defined as "Version 1" [zip].

• MUST treat an OCF ZIP container that uses [zip] encryption features as in error.

• MAY generate a physical directory for the root directory of the OCF abstract container if it unzips the contents.

• does not have to preserve information from an OCF ZIP container through load and save operations outside the context of the OCF abstract container. In particular, a reading system does not have to preserve CRC values, comment fields or fields that hold file system information corresponding to a particular operating system (e.g., External file attributes and Extra field).

With respect to specific fields in the OCF ZIP container archive, the reading system:

• MUST treat version needed to extract field values other than 10, 20 or 45 in the local file header table [zip] as being in error.

• MUST treat compression method field values other than 0 or 8 in the local file header table [zip] as being in error.

• MUST treat OCF ZIP containers with an Archive decryption header or an Archive extra data record [zip] as being in error.

Reading systems SHOULD support deobfuscation of fonts as defined in Font obfuscation [epub-34].

To restore the original data, reading systems can simply reverse the process: the source file becomes the obfuscated data, and the destination file contains the raw data.

If the dir attribute [epub-34] is set and indicates a base direction of ltr or rtl, reading systems MUST override the bidi algorithm per the higher-level protocols defined in [bidi], setting the paragraph embedding level to 0 if the base direction is ltr, or 1 if the base direction is rtl.

Otherwise the base direction is auto, in which case reading systems MUST determine the text's direction by applying the Unicode Bidi Algorithm, beginning with Rule P2 of [bidi].

Reading systems SHOULD NOT depend on the unique identifier being unique to one and only one EPUB publication. Determining whether two EPUB publications with the same unique identifier represent different versions of the same publication, or different publications, could require inspecting other metadata, such as their last modification dates, titles, and authors.

Whitespace

Reading systems MUST strip and collapse ASCII whitespace [infra] from Dublin Core [dcterms] and meta element values [epub-34] before processing.

The dc:identifier element

To determine whether the value of a dc:identifier element [epub-34] conforms to an established system or has been granted by an issuing authority, reading systems SHOULD check for an identifier-type property [epub-34].

The dc:title element

Reading systems MUST recognize the first dc:title element [epub-34] in document order as the main title of the EPUB publication and present it to users before other title elements.

This specification does not define how to process additional dc:title elements.

The dc:language element

The language(s) of the EPUB publication specified in dc:language elements are informational. Some uses of this information include:

• exposing it to the user through the reading system user interface
• using it to enhance functionality in a bookshelf (e.g., sorting by language)
• using it to optimize the reading interface (e.g., to preload text-to-speech languages)

See 3.7 Internationalization for more details on how to determine the language of a publication resource.

The dc:creator element

When determining display priority, reading systems MUST use the document order of dc:creator elements [epub-34] in the metadata section, where the first creator element encountered is the primary creator. If a reading system exposes creator metadata to the user, it SHOULD include all the creators listed in the metadata section whenever possible (e.g., when not constrained by display considerations).

The meta element

Reading systems SHOULD ignore all meta elements whose property attributes [epub-34] define expressions they do not recognize. A reading system MUST NOT fail when encountering unknown expressions.

If a reading system does not recognize the scheme attribute [epub-34] value, it SHOULD treat the value of the element as a string.

The link element

Retrieval and support of linked resources is OPTIONAL.

The language identified in an hreflang [EPUB-34] attribute is purely advisory. The language information expressed in the resource determines its language for processing and rendering purposes, as defined in the internationalization requirements.

Reading systems MUST ignore values of the properties attribute [epub-34] they do not recognize.

Reading systems SHOULD NOT use linked resources in the rendering of an EPUB publication due to the inherent limitations and risks involved (e.g., lack of information about the resource and how to process it, security risks from remotely-hosted sources, lack of fallbacks, etc.).

A reading system that does not support the MIME media type [rfc2046] of a given publication resource MUST traverse the manifest fallback chain [epub-34] until it identifies a supported publication resource to use in place of the unsupported resource. If the reading system supports multiple publication resources in the fallback chain, it MAY select the resource to use based on the resource's properties attribute [epub-34] values, otherwise it SHOULD honor the preferred fallback order [epub-34]. If a reading system does not support any resource in the fallback chain, it MUST alert the user that it could not display the content.

When manifest fallbacks [epub-34] are provided for top-level content documents, reading systems MAY choose from the available options to find the optimal version to render in a given context (e.g., by inspecting the properties attribute for each).

A reading system MUST terminate the fallback chain at the first reference to a manifest item it has already encountered.

Reading systems MUST provide a means of rendering an EPUB publication in the order defined in the spine element [epub-34], which includes:

• recognizing the first primary (linear) itemref [epub-34] as the beginning of the default reading order; and,
• rendering successive primary items in the order given in the spine.

When a user traverses the default reading order defined in the spine element, a reading system MAY automatically skip non-linear itemref elements [epub-34]. When a user activates a hyperlink to a non-linear resource, however, reading systems MUST render the referenced resource or a designated fallback. Reading systems MAY also provide the option for users to skip non-linear content by default or not.

If the page-progression-direction attribute [epub-34] is not set, the reading system MUST assume the value of default. When page-progression-direction value is default, the reading system can choose the rendering direction.

If the page-progression-direction attribute has a value other than default, the reading system MUST ignore any directionality computed from pre-paginated XHTML content documents.

Reading systems MUST ignore all values expressed in spine itemref properties attributes [EPUB-34] that they do not recognize.

Reading systems MUST NOT skip spine references to duplicate manifest items [EPUB-34] when rendering the linear reading order. The reading system MUST treat these as distinct items for user interface (UI) purposes (for example, each occurrence could be independently bookmarked or annotated). When a reading system follows a hyperlink to a resource referenced multiple times in the spine, the reading system MUST navigate to the first occurrence of the document in the linear reading order.

In the context of this specification, support for collections [epub-34] in reading systems is OPTIONAL. Reading systems MUST ignore collection elements that define unrecognized roles.

Reading systems MUST NOT support legacy features in content that conforms to this version of EPUB [epub-34].

Reading systems MUST process XHTML content documents [epub-34].

Unless explicitly defined in this section as overridden, reading systems MUST process XHTML content documents using semantics defined by the [html] specification and honor any applicable user agent conformance constraints expressed therein.

Reading systems MUST process SVG content documents [epub-34].

To process SVG content documents and SVG embedded in XHTML content documents, a reading system:

• MUST process SVG content documents using semantics defined by the [svg] specification, and honor any applicable user agent conformance constraints expressed therein, unless explicitly defined by this specification as overridden.

• MUST meet the conformance criteria defined in 6.4 Scripting.

• MUST, if it has a viewport, support the visual rendering of SVG using CSS as defined in Styling [svg] and it SHOULD support all properties defined in the Property Index [svg]. In the case of embedded SVG, a reading system MUST also conform to the constraints defined in 6.1.2.3.1 Embedded SVG and CSS.

If a reading system has a viewport, it MUST support the visual rendering of XHTML content documents via CSS [epub-34].

To support CSS, a reading system:

• MUST support the official definition of CSS as described in the [csssnapshot].

• SHOULD support all applicable modules in [csssnapshot] that have reached at least Candidate Recommendation status [w3cprocess] (and are widely implemented).

• MUST support [truetype], [opentype], [woff], and [woff2] font resources referenced from @font-face rules [css-fonts-4].

• SHOULD support all prefixed properties defined in CSS Style Sheets — Prefixed properties [epub-34].

• SHOULD apply style sheets referenced from EPUB content documents as written.

• SHOULD support the [html] suggested default rendering in their user agent style sheet(s).

Reading systems SHOULD support scripting [epub-34].

Reading system support for scripting depends on its usage context:

• Reading systems SHOULD support container-constrained scripting [epub-34] in reflowable EPUB content documents.

• Reading systems SHOULD support spine-level scripting [epub-34] in fixed-layout documents [epub-34].

• Reading systems SHOULD support spine-level scripting in reflowable EPUB content documents that use the "scrolled-doc" or "scrolled-continuous" [epub-34] presentation modes defined by the rendition:flow property. Similarly, if it supports spine-level scripting in reflowable EPUB content documents, it MUST implement the "scrolled-doc" presentation mode and SHOULD implement the "scrolled-continuous" presentation mode.

• Reading systems MAY support scripting in other contexts, but this specification does not address such scripting. As a result, the use of scripting in these contexts might not be consistent across reading systems.

If a reading system supports scripting:

• It MAY render scripted content documents as an interactive, scripted user agent according to [html].

• It MUST assign a unique origin [html], shared by all spine-level scripts of the EPUB publication. That origin [html] MUST be unique for each user-specific instance of an EPUB publication in a reading system.

• It MUST NOT allow a container-constrained script to modify the [dom] of the host EPUB content document or other contents in the EPUB publication and MUST NOT allow it to manipulate the size of its containing rectangle . (Note: Even if a script is not container-constrained, a reading system might impose restrictions on modifications. See the dom-manipulation feature.)

• It MAY place additional limitations on the capabilities provided to scripts during execution (e.g., limiting networking).

• It MUST extend the navigator object [html] with the epubReadingSystem interface defined in B. epubReadingSystem object. It also MUST support the dom-manipulation and layout-change features defined in B.3.1.2 Features in container-constrained scripting contexts.

If a reading system does not support scripting, it MUST process fallbacks for scripted content as defined in Fallbacks for scripted content documents [epub-34].

Reading systems MUST support the rendering of fixed-layout documents [epub-34].

Reading systems SHOULD process the reflowable layout properties [epub-34].

Except when obtaining the initial containing block dimensions for fixed-layout documents, reading systems MUST ignore rendering instructions in viewport meta declarations.

This restriction applies to both fixed-layout and reflowable documents.

Reading systems MAY support custom properties provided they do not introduce expressions that conflict behaviorally with the properties defined in the Package rendering vocabulary [epub-34].

When a reading system loads a package document, it MUST refer to the manifest item elements' [epub-34] media-overlay attributes to discover the corresponding media overlays for EPUB content documents.

Reading systems MUST support playback for XHTML content documents, and MAY support SVG content documents.

Playback MUST start at the media overlay element which corresponds to the desired EPUB content document starting point. Note that the start of an EPUB content document could correspond to an element at the start or in the middle of a media overlay. When the media overlay document finishes playing, the reading system SHOULD load the next EPUB content document (as specified in the package document spine) and also load its corresponding media overlay document, provided that one is given.

The strongest measure that reading system developers can take for privacy is to specify the data they intend to collect and use about the user and/or their reading behavior and seek the consent of users to obtain it. They SHOULD also allow personalization and control over this information.

If a reading system allows users to store persistent data, especially personally identifiable information, it SHOULD treat that data as sensitive and not allow access to it by third parties.

It is understood that the collection of some user data is often necessary for the sale, delivery, and operation of an EPUB publication, particularly on platforms where the sale of an EPUB publication and the method of reading it are connected. In these cases, the reading system SHOULD identify the data being collected, how it is used, and allow for user opt-outs (retailers could choose to inform users by other means, such as when a user creates an account on their web site). Anonymization of any collected data is RECOMMENDED for the privacy and the security of the user and reading system.

It is also understood that user data could be necessary or helpful for some reading system affordances. In these cases, anonymization is also RECOMMENDED. Reading systems SHOULD also inform users of what data is needed, what it is to be used for, and to provide methods to opt-out.

Content processors — defined as entities that handle the ingestion of EPUB content for distribution, display, or sale — also need to be aware of the potential risks in ingestion. It is advised that content processors check content for malicious content on ingestion, in addition to the validation steps that usually occur. This could include running virus scans, validating external links and remote resources, and other precautions.

Reading systems SHOULD treat content from any new source, including from an integrated bookstore, as insecure (e.g., prompt users to allow scripting and network access the first time the source is accessed). If a reading system allows users to load their own content (e.g., through the process of "sideloading"), each instance SHOULD be treated as insecure.

When processing XML documents, a reading system SHOULD NOT resolve external identifiers in DOCTYPE, ENTITY and NOTATION declarations [xml]. Reading systems SHOULD also consider security risks related to internal or external XML entities like, for example, DoS attacks also known as "Billion laughs attacks" or "XML external entity attacks".