Proposed Specification 8 July 2015
Updated to address issues raised during review.
Please refer to the errata for this document, which may include some normative corrections.
Copyright © 2012-2015 International Digital Publishing Forum™
All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).
EPUB is a registered trademark of the International Digital Publishing Forum.
This document is in proposed recommendation status and is made available for final IDPF membership review.
This section is informative
This specification, EPUB Previews, describes how preview content can be included in EPUB® Publications. This document outlines two key models for defining such content:
Best practices for metadata and links related to previews (e.g., to acquire the full Publication) are also covered.
Refer to the EPUB Specifications for definitions of EPUB-specific terminology used in this document.
A preview derived from a subset of resources of its containing EPUB Publication.
An EPUB Publication whose content represents a preview of another Publication.
The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].
All sections of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendices applies to all child content and subsections they may contain.
All examples in this specification are informative.
This section is informative
There are many reasons why a preview might be distributed as a separate EPUB file: to begin marketing a book before the full manuscript is complete, to limit the content available when not using DRM schemes, to minimize download sizes for media-rich works, and so on.
When distributing such a preview, it is necessary both to identify to the User that they do not have the complete publication, and also provide the means for them to obtain that work.
This section details how to create standalone Preview Publications, including the required labelling in the Package Document metadata, how to create an identifier for the preview, and how to link the preview to its parent work (how to acquire the parent work is outlined in 4. Acquiring Publications).
In addition to being a valid EPUB Publication, a Preview Publication must meet all of the following criteria:
In addition to processing the Preview Publication according to the version of the EPUB specification it conforms to, an EPUB Reading System must meet all of the following additional criteria:
In order to indicate that a Publication represents a preview, its Package Document metadata section [Publications301] must include a dc:type
element with the value "preview
".
The following example shows how a Preview Publication is defined in the Package Document metadata.
<package …> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:type>preview</dc:type> … </metadata> </package>
A Preview Publication must not use the same package identifier as its source Publication.
Since a Preview Publication is rarely a product, this specification recommends using something else than an ISBN as the package identifier.
A Preview Publication should link back to its source Publication using a dc:source
element, with the source Publication's package identifier as the value.
The following example shows how a Preview Publication links back to its source publication.
<package … unique-identifier="pub-id"> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:type>preview</dc:type> <dc:identifier id="pub-id">urn:uuid:13b92c40-3f6b-11e3-aa6e-0800200c9a66</dc:identifier> <meta property="dcterms:modified">2013-08-01T12:00:00Z</meta> <dc:source>urn:isbn:9782367932095</dc:source> … </metadata> </package>
The following example shows a minimally complete metadata section, where the Publication is identified as a preview, metadata links back to the source publication and a link to acquire it has also been included.
<package … unique-identifier="pub-id"> … <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:title>Norwegian Wood</dc:title> <dc:language>en</dc:language> <dc:type>preview</dc:type> <dc:identifier id="pub-id">urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier> <meta property="dcterms:modified">2011-01-01T12:00:00Z</meta> <dc:source>urn:isbn:9781448103706</dc:source> <link href="http://example.org/book/9781448103706" rel="acquire" media-type="text/html" /> <link href="http://example.org/book/9781448103706.atom" rel="acquire" media-type="application/atom+xml;type=entry;profile=opds-catalog" /> </metadata> … </package>
This section is informative
Preview content does not have to be packaged as a separate Publication. In many cases, the subset of resources that constitute the preview can be identified within the context of the complete Publication, and directly extracted to present a preview for the User.
These Embedded Previews provide Authors control over how preview content is generated from the source Publication, instead of third-party vendors selecting which part(s) of the Publication to extract. Embedded Previews also provide an advantage over Preview Publications in that a new Publication does not have to be downloaded, and the Preview Publication replaced, when the User purchases the full version ‒ the full content simply has to be unlocked.
This section explains how to use the Package Document collection
element to create such previews: from defining the necessary role to the requirements for a manifest of resources, as well as which (parts of) Content Documents can be viewed.
An Embedded Preview must meet all of the following criteria:
An EPUB Reading System must meet all of the following criteria for processing Embedded Previews:
An embedded Preview is defined in a Package Document collection
element [Publications301] with the role
attribute value "preview
".
The preview
collection must include a child manifest
collection [ManifestRole] that identifies all of the EPUB Content Documents in the preview, as well as all the associated resources required to render them.
Each link
element’s href
attribute must point to an EPUB Content Document. The IRI expressed in the href
attribute may include a fragment identifier but must not include EPUB canonical fragment identifiers [EPUBCFI].
The order of child link
elements in a preview
collection represents the order in which the documents are to be rendered.
The following example shows how a publication can provide a collection that indicates which EPUB Content Documents are included in a preview (including only part of chapter 3), as well as a manifest of the resources necessary for this preview.
<collection role="preview"> <collection role="manifest"> <link href="chapter1.xhtml" media-type="application/xhtml+xml" /> <link href="chapter2.xhtml" media-type="application/xhtml+xml" /> <link href="chapter3.xhtml" media-type="application/xhtml+xml" /> <link href="stylesheet.css" media-type="text/css" /> <link href="image1.jpg" media-type="image/jpeg" /> </collection> <link href="chapter1.xhtml"/> <link href="chapter2.xhtml"/> <link href="chapter3.xhtml#preview"/> </collection>
While fragment identifiers usually reference a specific location in a document, in the context of a Preview Collection, such fragment identifiers actually reference a range:
Instead of creating a separate Preview Publication, an EPUB Publication containing an Embedded Preview can be used to generate the Preview Publication automatically.
Software that generates a Preview Publication from an Embedded Preview must respect the following processing rules:
This specification does not mandate how to adapt content for rendering in a preview. Reading Systems might direct links outside the preview content to a generic placeholder page that indicates the content is not available in the preview, might make such links inactive by removing their href
attributes, or might employ other mechanisms to handle references to non-preview content.
It is strongly encouraged, however, that all link labels be retained when adapting the preview ‒ including in the table of contents ‒ to give a complete picture of the content available in the full EPUB Publication.
See also [DistributableObjects] for additional guidance on how to translate a collection to a packaged EPUB Publication. The translation steps for previews are not identical (e.g., metadata is taken from the package not the collection), but many of the requirements to produce a valid EPUB Publication are the same.
Both Preview Publications and Publications containing Embedded Previews may provide a link to allow a User to acquire the full source Publication. To do so, one or more acquire link
elements [Publications301] should be included in the Package Document metadata section.
The following example shows links to an HTML vendor page and an OPDS catalog entry for acquiring the full Publication.
<package …> … <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:type>preview</dc:type> … <link href="http://example.org/book/9781448103706" rel="acquire" media-type="text/html" /> <link href="http://example.org/book/9781448103706.atom" rel="acquire" media-type="application/atom+xml;type=entry;profile=opds-catalog" /> </metadata> … </package>
This specification does not define how Reading Systems and vendors are to negotiate access to the acquired Publication.
While this relationship value may be used with any potential media type, this specification recommends using either "text/html
" for publications that can be acquired in a browser, or "application/atom+xml;type=entry;profile=opds-catalog
" for an [OPDS] entry.
This appendix is informative
EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.
The EPUB Previews 1.0 specification was prepared by the International Digital Publishing Forum's Advanced/Hybrid Layouts working group, operating under a charter approved by the membership in November 2012, under the leadership of:
Active members of the working group included:
IDPF Members
Invited Experts/Observers