4.2 EPUB Tour

Let’s have a quick poke around an EPUB to orient ourselves and look at all the parts. 

The META-INF folder is always top level and it includes two things inside of it: The container, which you must have or your ebook won’t work, and the encryption file. The container has one simple line of code that basically tells the reading system where to find the ebooks engine: the OPF. An EPUB must have this container file or it won’t work. 

The encryption file is related to the fonts and is optional. If you’ve opted to embed fonts upon export from InDesign, this encryption will pop-up automatically. But I’ll caution you that your fonts won’t work on Kindle if you leave the encryption in. So, you do what you want with that information, I’m just going to leave it in for now. But if this ebook was going to Amazon, then I would delete that encryption file.

Let’s look around a little more. The OEBPS folder holds all the bits and pieces of the ebook. InDesign organizes the EPUB in predictable ways: the cascading style sheets (CSS) are in a styles or css folder. The fonts, if you’ve embedded them, will be in a folder named font. Any JPEGs, PNGs, or SVGs in the ebook will be tucked into the image folder. 

There are a couple of other categories of things in here: the HTML files, the navigation files, and the content.opf file. 

The cover and the chapter HTML files are here. The cover.xhtml is obvious. The rest of the book will be in a series of HTML files that take the name of the InDesign file and iterate it. InDesign is a bit flat-footed about this. It just names these things with the name of the InDesign file and adds a number. 

The navigation files are the toc.ncx and the toc.xhtml. We don’t need the NCX file anymore in order for your ebook to validate but I always just leave it in because there is still the odd EPUB reading system in the world that are EPUB 2 driven and need an NCX navigation to fall back on. So I leave it in there, but I pay no attention to it and I don’t clean it up ’cause I resent it. There you go. That’s a little insight into how mean I am about EPUB. The toc.xhtml is the main navigation document in addition to being the source of landmarks, pagelist and any other navigational lists like a list of illustrations. I will spend a lot more time on the toc.xhtml in a bit.  

For now, let’s focus on the content.opf file first. This image is a screenshot of the OPF fresh out of InDesign. There’s a lot of code-ish things going on here that you don’t necessarily need to know all about. The main elements are the metadata, the manifest, and the spine and guide. 

Let’s go through this line by line. The line at the top is just there, never needs to be edited. Lines 2-4 are the package element. Version=”3.0” means that this is EPUB 3, not EPUB 2. Various pieces of these lines refer to Apple vocabularies, and the EPUB specification. The main thing to know about this line is that it is missing a language declaration which the ebook will need to pass an accessibility checker like Ace by DAISY. That line should be modified per the code snippet below:

<package version=”3.0″
unique-identifier=”bookid”
xml:lang=”en”
prefix=”ibooks: http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0/”
xmlns=”http://www.idpf.org/2007/opf”>

Note that this book is en English, so I have inserted xml:lang=”en”. Books in other languages should use the language of the content, i.e., “fr”, “sp”, etc.

Line 6 — <meta name=”generator” content=”Adobe InDesign 18.1″ /> — is a piece of code that InDesign inserts into every single EPUB that it exports. It is informational only so you can delete that if you want and nothing bad will happen. I do it just to annoy Adobe. I can’t imagine that they feel it, but I do it anyway. 

Line 7 — <meta name=”cover” content=”cover.jpg” /> —indicates the cover location. This piece of code ensures that your cover shows up properly on bookshelves and thumbnails. 

Line 8 — <meta property=”ibooks:specified-fonts”>true</meta> — indicates that there are embedded fonts and asks iBooks (Apple Books) to please be polite and play nicely. 

The rest of the metadata fields are fairly straightforward — title, author, publisher, rights declaration, etc. The dc:date field is the date on which the EPUB was created, not the pub date. You’ll notice that there are two language declarations here. This is a thing that InDesign does that is erroneous. The content of this ebook is English but, if you’ll recall, there is a snippet of French in chapter 1. InDesign thinks this is more than a snippet and says this is a bilingual publication. Watch out for extra language in the OPF metadata. Line 15 will have to be deleted. 

Line 16 indicates when this ebook was last edited. You don’t need to update it as you work but you may find it’s useful to do so. Some reading systems display cached versions of content; changing this line will force the RS to see the ebook as brand new. This is a handy trick when you are conducting quality assurance (QA). 

Line 17 is a funny one. In general, this would be the space for an ISBN. I don’t have an ISBN for this book because it’s just a test ebook. So, what is this long string here? Don’t ever delete this urn:uuid string. It is tied to the font encryption and if it is deleted, then the fonts won’t work at all. When InDesign exports embedded fonts, it subsets those fonts. So it creates new versions of those fonts that have just the glyphs that are present in the InDesign file in that content and makes new versions of them. And then it encrypts them using this piece of the puzzle up here and it’s all tied to this long string right here. So don’t delete that. If you want to add an ISBN, a proper ISBN, you can do that. I recommend you open an EPUB that you know works and has the correct metadata in it, and you copy it and paste it in here, and then paste your ISBN over top of the one that exists. I’m a big fan of cribbing successful code that works elsewhere.

A quick note: that urn:uuid string is tied to the NCX. If it is deleted or altered, you will get validation errors. This is a quirky thing that it’s good to be aware of. 

The next important part of the OPF file is the <manifest>. Just like a manifest on a ship lists every person on board, this manifest lists everything in the EPUB: the cover, the HTML files, the navigation files, the style sheet, the fonts right there, and then the images. If you add a font or take away a font, then you need to edit it here. If you add an HTML file or take away an HTML file, you need to edit it in this manifest. If this manifest doesn’t relate directly to what’s over here inside the ebook, you will get a validation error. 

Some things to note: lines 25 and 26 point to the navigation files, the NCX and the toc.xhtml. At the end of line 26, there is a unique declaration — properties=”nav” — that designates that file as the EPUB’s navigation. 

The spine is a unique thing in EPUB markup that just lists everything in the ebook and the order in which it appears. The cover has a linear=”no” because we don’t want the cover to display within the ebook, in general. If you do want it to display, you can change that to yes or you can just delete it altogether and it will display — just be cautious of duplicate covers when you send it to Amazon. If you delete an HTML file or add an HTML file in the maniest, then you need to edit it down here in the spine. 

And then finally, the guide is the last piece. This points to both the cover and the start of content, so it says text, and then here’s title=”Beginning” and that just means that’s where that file will open. The guide is a bit of an EPUB 2 holdover and is mostly replaced by landmarks everywhere except for on Amazon, I believe.