Just like a shipping invoice, the manifest lists all the items included in the final package. Every file in the ebook archive must be listed here, with the sole exception of the OPF itself. Additionally, in Kindle ebooks converted using Kindlegen, any images or CSS files that are referenced directly in an HTML page do not technically need to be listed in the manifest. However, it is generally the best practice to include all files in the manifest nonetheless, both for reference and for future compatibility.
Each item gets its own line entry containing three required attributes, the first of which is an id that includes a descriptive name of your own choice. This can be anything you like, the only stipulation being that no two id values in the manifest can be the same, for obvious reasons. Some of these id’s will be linked to elsewhere, and the reference must be clear.
This is followed by a reference to the file’s location, in the form of an href url that is relative to the OPF. Thus, if the file is in a subfolder, such as is the case for the images in the templates, then the folder name must be provided, such as:
If the file is at the same level as the OPF - such as the NCX in the templates - then just the file name is sufficient.
Finally, there is a media-type attribute that defines what kind of file the item is. These are grouped in the templates according to their type, with header labels provided for ease of reference. The common media-types and their values are as follows:
HTML files = “application/xhtml+xml”
CSS files = “text/css”
NCX file = “application/x-dtbncx+xml”
Image files = “image/jpeg”
Fonts = “application/x-font-ttf”
These are the main media types that you will likely use, although for images the Kindle format also supports non-transparent PNG, BMP, and GIF files, as well as Scaleable Vector Graphics (SVG), the latter of which can be used for text as well as graphics.
You can also use OpenType fonts (x-font-otf) in addition to TrueType, but it is not recommended that you use Type1 Postscript fonts, as these will not render clearly when scaled. Kindlegen will give you a warning if you include them.
Note that all HTML files are listed as “application/xhtml+xml”, regardless of what coding iteration you use for the actual file itself (.xhtml, .html, .xml, etc.).
These three item attributes can come in any order, but each must be included for every item.
As mentioned, there must be one HTML file for each page in a fixed layout ebook, and consequently, one line item for each page as well. Since images and CSS files can be referenced from within the HTML page file, these are optional, but as mentioned, best practice is to include them.
There are two other items that must be present in every manifest. These are an NCX or NAV file (or both) and the cover image. Each of these include new ePub3 code attributes included in the version 2.8 update, which requires a little further explanation.
The ePub3 spec adds a navigation file that supersedes the NCX, and you will see that file referenced in this section of the Advanced Template along with the NCX. Again, both navigation files can be included, with the ePub3 version being preferred over the older NCX. We will discuss these files when we reach the Navigation section, but just be sure to reference the one (or ones) you’re using here.
Also note that an additional properties attribute is given here for the new nav.xhtml file, whose value is “nav”, which is required for proper identification of the navigation file. The cover image entry also gets a new properties value as well, as we will shortly see.
The manifest entry for the cover image is where we need to match our content value from the metadata name=“cover” entry up above, and this is entered as the item id value for the cover image file. Whatever name you chose to enter as the value of the content attribute must be entered here as well:
This tells the reading system which file you are using as the cover - and this must be an image file, not an HTML page containing the cover image.
Finally, with regard to the cover image entry in the manifest, the ePub3 code adds a new properties attribute, the value of which is "cover-image", as seen at the end of the line in the Advanced Template. The manifest entry is otherwise unchanged from the standard Kindle format. However, if the properties value is included here, the otherwise required name=“cover” entity can be excluded from the metadata section. That said, for the sake of backwards compatibility, at the present time it is best to include both.
The Spine is a linear listing of the ebook contents, in the order you want them to be presented to the reader, just as the pages in a print book are attached in specific order to the spine of the bound book (hence, the name). Here you enter each of the HTML pages you create using the item id you specified for them in the manifest above, like so:
where the value of the idref is equal to the item id in the manifest for that page. Only the HTML pages need be entered, and not their component parts (i.e. CSS, images, etc.). Just list them all exactly in the order that you want the reader to see them.
Two elements found here require further explanation. The first of these is the toc attribute attached to the spine tag itself:
This is a required attribute if you are using an NCX for navigation, the value of which can be any name you like, but which must match the item id for the NCX file in the manifest. This is how the reading system identifies the NCX as the source for its menu contents.
The Spine itself functions as something of an internal “table of contents” for the reading system, listing the pages in their proper order. However, the actual page links that appear in the Kindle pop-up menu are created either in the NCX/NAV file, or the Guide section of the OPF below (which we will get to in a minute). It is the NCX file that must be referenced here if it is being used, while the NAV document is referenced in the manifest above. Both can be present without conflict, as they are in the Advanced Template. If using only the ePub3 NAV file, the toc=“ncx” attribute can be removed from its location here, as it is not relevant to the Navigation document.
You can, of course, also create an active Table of Contents page within the ebook itself, if you so choose, as a standard HTML page with internal links; but that is another matter unrelated to this. Here we are only concerned with the links that appear in the Kindle menu and the reading order of the pages. We will cover this in more detail in the Navigation section, but we need to specify the NCX file here.
NOTE: For a discussion of the "page-id" property and its effect on two-page spreads, please see the published guidebook.
In order to provide a means of navigation from the Kindle menu (as opposed to an internal Table of Contents page), one or more additional items are necessary; these are a section of the OPF file called the Guide, or one or both of two additional external files, these being the NCX or the NAV doc. Your ebook will work just fine without them, but there will be no way to navigate beyond moving forward and backwards through the pages. But this is fine for shorter illustrated works like children's books and comics, and is, in fact, the general practice for these types of content.
Unlike the previous three sections of the OPF, which are all required, the Guide section is optional. That is to say, your ebook will work just fine without it (in most cases), although there are reasons why you may want to include at least some parts of it. However, because it is not necessary for a Kindle ebook to function, this tutorial does not address the somewhat convoluted and confusing subject of including the Guide, which has, in fact, been deprecated in the EPUB3 specification.
Until recently all menu navigation in Kindle devices and apps was handled by the Guide and a file called the NCX (Navigation Control XML file), but these have both been superseded by a single HTML navigation file, which for ease of reference is generally called the NAV doc - even though it’s really just another HTML file with some unique code included.
But since this is a new addition, many older reading systems do not yet recognize it, leaving the Kindle format in something of a transitional state. It is therefore wise to include both an NCX and a NAV file in your Kindle books at present, as well as the Guide section of the OPF (if you include any of them at all, that is).
The use of all three navigation elements, and how they interact with one another, is explained in great detail in the published manual, How To Make Kindle Comics & Children's Books, but is not addressed here. For those wanting to know what the Guide section does and how to add one, or how to create an NCX or NAV doc, there are extensive lessons in the published guidebook.