EPUB Navigation Peculiarities
In ebook technology, ease of navigation and reach for any piece of information is extremely important. The EPUB standard defines multiple ways to structure navigation of an ebook: sequentially, in a single path, or selectively, picking whatever to read from the Table of Contents.
But along with this structure, may come peculiarities that are rather confusing. Especially for an ebook authoring software company like us spending days inside the belly of the beast, it is important to give users friendly tools to set their chapter navigation preferences, with a clear bright picture of what they’re doing and expecting. Not knowing that behind the curtains, things are not very glamorous. Don’t get me started on what we’ve been through.
In this article I’d like to share the navigation possibilities in the EPUB standard, along with peculiar cases, both from an end-user’s perspective and from a technical perspective.
If you’re not very familiar with the EPUB format, or would like to freshen your memory, this is an excellent read: Alice in EPUB-Land: Understanding the EPUB format.
Navigation methods
With the current EPUB format, there are three existing methods to navigate an ebook:
Spine
The spine represents the series of chapters from start to end, that a normal user would pass through in order to complete reading the book. Spine navigation is controlled by Next and Previous buttons (or in case of mobile, swiping left and right). The spine is extremely important as it is the most basic method of navigation supported by the simplest ebook reader software or device.
In the EPUB format, the spine chapters are listed under the spine element in the package file. Any chapter existing inside the book must technically also exist inside the spine element. Among the peculiarities, is that even if this chapter is not part of the spine navigation sequence, it must still be included as an entry in the spine but marked in a special way to avoid displaying it. This case will be covered later.
Table of Contents
A restaurant will only list the dishes you want to see in their menu – it definitely does not mean that’s all they have in the kitchen. Same with books. The table of contents will list chapters, in a structured format, that you can refer to anytime for ease of access, and not necessarily all the chapters inside the book. In fact, some books may lack a table of contents entirely and solely rely on spine navigation.
In the EPUB format, the table of contents is stored in an HTML file all by itself, and linked to from the package file.
Hyperlinks
In some cases, you may want an invisible chapter – not in the spine nor the table of contents. Although it does sound peculiar, it’s actually quite common. The only way to access such a chapter, is through a hyperlink from another chapter. Think of it as a link for optional information, such as contact information, or a solution sheet for some questions. Or a better example, an adventure gamebook link where you are jumping from chapter to chapter. Ideally, it wouldn’t be a good idea to include those chapters in the spine navigation. Table of contents? Questionable.
In the EPUB format, invisible chapters are not included in the table of contents (obviously), but as mentioned previously should still be included in the spine. Their order in the spine doesn’t matter, as they are marked with a special attribute to make the reader jump right through it. More on that in the next section.
Peculiar cases
From our continuous exposure to different author requirements in ebook creation, we have a fair understanding of the common and uncommon use cases for book navigation. Firstly, let’s take a look at all the different combinations below, along with how common they are. These numbers are rough estimates, and based on our experience with Kotobee.
The most common case, is to include standard chapters in both the table of contents and the spine. That is what most authors would like to give: ease of access to their chapters.
Not in spine
When editing EPUB files manually, it is no doubt a peculiar case when a chapter is not to be in the spine. Because in the code, it still is inside the spine element. The chapter must be added, in any order, in the spine, along with the “linear” attribute set to “no”. This tells the reader that the chapter is not part of the spine navigation. The precise definition taken from IDPF’s website:
The
itemrefelementlinearattribute indicates whether referenced item is considered primary (yes) or auxiliary (no) in thespine. This attribute may be used to enable Reading Systems to distinguish presentation of body content from supplementary content which might be, for example, presented in a popup window or omitted from an aural rendition
Here is an example:
<spine> <itemref idref="chapter1"/> <itemref idref="hiddenchapter" linear="no"/> <itemref idref="chapter2"/> ..
As a reminder, all chapters, visible/invisible, must be included at all times under the manifest tag in the package file.
Fixed-layout books
Support for fixed-layout is a great addition to the EPUB standard. But with all due respect to the IDPF, that in itself is a problem. That it’s an addition. EPUB standard by design was meant solely for reflowable chapters. Support for fixed-layout was then added later on. To make the banana fit into the jar, the concept of fixed-layout chapters was tweaked to fit the anatomy of EPUBs. Bear with me now.
Each book chapter is a single HTML file. The EPUB standard is built around this core fact. Large or small, it is the ebook reader’s job to display the chapter appropriately – either using vertical scrolling, or dividing the chapter file into page views like Kindle does, etc. Of course, taking the user’s font preferences and screen dimensions into account. Whatever it is, at the end of the day, the chapter is represented by a single file.
This core fact is broken by fixed-layout books. With those types of books, a chapter is not represented by a single content block, but rather by a sequence of pages, each with a fixed width and height. The critical part, is that each page is represented by a single file. This means that a chapter can be represented by multiple files.
So although the EPUB standard indicates that each HTML file contains a single chapter, when it comes to fixed-layout books, an HTML file contains only part of a chapter. Multiple HTML files together can construct a chapter. So how do we fit all this into the EPUB format which treats files as chapters?
The way to do it is the following. Include all the page files into the spine, but only include the first page into the table of contents. This way the user can see the starting page in the table of contents, and by navigating there, can sequence his way forward through the spine. Remember, EPUB is treating each page as a chapter. But semantically, we are treating them as pages.
Applying this in Kotobee Author
A challenge of creating an ebook authoring tool is giving users a friendly way to set complex properties without necessarily having to understand the whole concept behind it. In Kotobee Author, we allow the user to set his chapter to any of the four different combinations of spine + table of content navigation.
The whole idea to avoid confusing the user, is to show his chapters in a single list and never more (just a table of contents, not a spine). When selecting any chapter, at the footer of the edit area, the user is given two properties: invisible, and Include in TOC. With clear help instructions, the user is able to distinguish what each checkbox will do.
With the suitable options checked, at the export stage, the chapter is shown/hidden from the table of contents and its linear attribute is set appropriately in the spine. If the user chooses not to include the chapter in the table of contents, exports his book, then opens it again, logically he should not find his chapter among the table of contents, since it’s not included anymore. But in our case, he will find it, along with an unchecked “Include in TOC” box. It was very important for us to preserve the structure and avoid the chapter being deleted entirely from the table of contents, because at anytime the user may change his mind. You don’t want him creating the chapter all over again, or fetching it from some other list. So how did we do that? When exporting, we hid the chapter from the table of contents using CSS. Once the book is opened again in Author, the CSS is ignored, and rather converted into the “Include in TOC” property. Quite a hack.
There is only one gotcha here, something which can’t be achieved currently with Kotobee Author. We are making the assumption that the order of chapters in the spine, is the same as the table of contents. It’s not necessarily that way, and for such a case, that would be one hell of a peculiarity!
If you are editing ebooks yourself, you will never get as much flexibility as extracting the EPUB content yourself and getting your hands dirty. Here is a more thorough article for editing EPUB files manually.
You may also like
Alice in EPUB-Land: Understanding the EPUB format
How to create an interactive ebook: A step-by-step guide
