Edited 3:15pm: Though the current epubcheck considers the sample below to be valid, the approach described in this post is likely not strictly valid according to EPUB 2.0.1. The XHTML TOC is not necessarily meant to be part of the EPUB publication as it is for Kindle consumption only, but it is included in the manifest. Proceed with caution.
Many publishers prefer to create only a single EPUB file that can be distributed both into EPUB reading system channels like iBooks and B&N, but can also be distributed in the Kindle ecosystem after conversion by kindlegen, Calibre or Amazon’s internal systems.
There are a few problems with this. One is that Mobipocket’s primitive HTML support conflicts with the requirement that commercial EPUBs be valid XHTML 1.1. There are some design elements that are difficult to do “right” in Mobipocket while still maintaining compliance with EPUB. Our best recommendation in this case is to optimize the design for EPUB reading systems that are based on browser engines; that is clearly where the next generation of EPUB readers are going, and ebooks should be designed as much for future readers as for the state of the art today. Designers who need fine control over the look of Kindle books should first buy Kindle Formatting by Joshua Tallent, and then be prepared to produce two separate EPUB files: a Mobi-specific one and a valid one for distribution in the other channels.
If exact formatting isn’t critical, then the single-source approach can work, but there’s one other layout issue: Kindle requires both the EPUB NCX Table of Contents as well as a table of contents marked up in XHTML. This requirement is silly — an XHTML TOC should only be included if the creator really wanted custom layout — but there it is.
This leads to content creators including an XHTML TOC in their EPUB, which is unnecessary in EPUB readers, takes up valuable front-matter space, and impedes the flow of reading.
Here’s a quick trick to bundling an XHTML TOC and “hiding” it from an EPUB reader: omit the XHTML TOC from the spine.
<?xml version="1.0"?> <package xmlns="http://www.idpf.org/2007/opf" xmlns:dc="http://purl.org/dc/elements/1.1/" unique-identifier="bookid" version="2.0"> <metadata> <dc:title>Test demonstrating mobi TOC that does not appear in an EPUB</dc:title> <dc:creator>Threepress Consulting Inc.</dc:creator> <dc:description>A demonstration of including a Mobi-friendly XHTML TOC in an EPUB</dc:description> <dc:date>2010</dc:date> <dc:rights>Public domain</dc:rights> <dc:identifier id="bookid">urn:uuid:AB7456FF-DDC7-4DB1-AEFB-153DDDBA9F9B</dc:identifier> <dc:language>en</dc:language> </metadata> <manifest> <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml"/> <item id="untitled-5" href="Untitled-5.xhtml" media-type="application/xhtml+xml"/> <item id="toc" href="toc.xhtml" media-type="application/xhtml+xml"/> <item id="css" href="template.css" media-type="text/css"/> </manifest> <spine toc="ncx"> <itemref idref="untitled-5"/> </spine> <guide> <reference href="toc.xhtml" type="toc" title="Table of Contents"/> </guide> </package>
In this case, the
guide entry tells Kindle where to find the XHTML TOC, but omitting it from the
spine means that it is not added to the “linear reading order” of the book. It’s simply not accessible to any EPUB reader.
Thus you have a Kindle-friendly EPUB file that does not burden its EPUB reader cousins with unnecessary cruft.