Lists in ePub generated from InDesign CS6

Recently, I wrote an article for InDesign Magazine titled “What’s New with ePub in CS6?” (Issue #48 – June/July 2012). In that article, I include a section called “Support for Custom Bullet and Numbering Marker Strings”. For the purposes of the article, I only included the part of this update that “works”, which is complicated numbered lists retaining their intended numbering when exported to ePub. Unfortunately, the solution that the Adobe engineers came up with to solve this problem ends up breaking (pretty much) everything else about numbered and bulleted lists.

For a great explanation of the actual problem, followed by some fantastic solutions, see Liz Castro’s post on the subject.

Since Liz’s explanation and solutions are (pretty much) exactly my thoughts, I will not bother to duplicate them here. Instead, I will use this space to elaborate on some of my other thoughts and suggestions for Adobe.

What was Adobe thinking?

Since the introduction of ePub export from InDesign (way back in CS3), one of my constant complaints was the fact that I could not get complicated numbered lists to export correctly to ePub. I have many books in my workflow that are loaded with complicated lists. (My current workaround for these lists is to select the option to “Convert Numbered Lists to Text”. However, I do not prefer this option, because I want my lists to be valid HTML lists, which these are not)

For clarification, here is an example of a simple list (through CS5.5, these lists export to ePub just fine):

  1. First list item
  2. Second list item
  3. Third list item
  4. Fourth list item
  5. Fifth list item

And here is an example of a complicated list:

  1. First list item
    Additional paragraph to extend the content for the first list item.
  2. Second list item
  3. Third list item
    Additional paragraph to extend the content for the third list item.
    A second paragraph to extend the content for the third list item.
  4. Fourth list item
    1. Sublisting under the Fourth list item
    2. Sublisting under the Fourth list item
    3. Sublisting under the Fourth list item
  5. Fifth list item

With CS6, the Adobe engineers attempted to come up with a creative solution to maintain proper numbering when dealing with these types of more complex numbered lists. As I mentioned before, this solution solves the problem of complicated list numbering, but creates a whole bunch of other problems, including bad code and double bullets (in bulleted lists).

Here is an example of the (above) complicated list, when exported to ePub via InDesign CS5.5 (or earlier):


The list, exported to ePub via InDesign CS5.5, and displayed using Adobe Digital Editions

And here is the html from that ePub file:


View of the HTML code contained in the CS5.5-generated ePub file

As you can see, when the list is viewed in your ePub reader, it is broken in a way that makes the numbering useless.
The code is pretty clean, except for one key issue (which I will explain in a minute).

Here is the same list, when exported to ePub via InDesign CS6:


The list, exported to ePub via InDesign CS6, and displayed using Adobe Digital Editions

And here is the xhtml from that ePub file:


View of the XHTML code contained in the CS6-generated ePub file

As you can see here, the list looks good when viewed in an ePub reader, but the code is awful and does not translate well.

Though I believe their hearts were in the right place, the direction that the Adobe engineers took (with CS6), was the wrong one.

Suggested Solution

I suggest that Adobe goes back to how Lists were exported to ePub in CS5.5 (and earlier), but with one minor change. If you look at the HTML code from the CS5.5 generated ePub again, you will notice that Ordered Lists (<ol></ol>) keep resetting, because InDesign does not know what to do with them:

Too Many ols

The “ol” tags (circled in red) are causing the list to constantly be reset

These need to be treated as “single” listings, and not broken up into smaller lists. This is the reason that the numbering does not continue correctly.

Here is what the code would look like with the unnecessary <ol>s removed:

Correct Code

The opening/closing “ol” tags should dictate the beginning and ending of the full numbered listing

And here is what the resulting list now looks like in your ePub reader:

Correct ADE

Properly formatted ePub listing, viewed in Adobe Digital Editions

As you can see here, the code is cleaner and the resulting complicated list is numbered correctly. In this example, the indents are not ideal, but that can be fixed by tweaking the stylesheet (CSS).

Challenge for Adobe

The challenge here is that, there is no good way for InDesign to know when a complicated list is intended to end. For simple lists, it is easy: when there are no more list items, the that list is ended.

For these more complicated lists, you may have unnumbered paragraphs, inline figures, or other elements included within the numbering. The engineers at Adobe will need to come up with a way to call this out.

I welcome any and all feedback regarding this issue.



Preparing your InDesign files for ePub export

A few years ago, I did a presentation on “Preparing your InDesign files for ePub export”.

At the time, CS4 was the most recent incarnation of InDesign. As we all know by now, the ePub export functionality in that version was pretty flawed, but significantly better than it was in CS3.

There was not very much improvement with the release of InDesign CS5, but version CS5.5 brought the whole thing to a new level.

The ePub-specific enhancements with the release of CS5.5 include:

  • The new Articles Panel
  • Style Export Tagging
  • Much improved ePub Export Dialog
  • etc.

With that said, I have gone ahead and updated my presentation to include these very helpful additions to Adobe InDesign CS5.5.

Click here to download the PDF. I also included an updated list of References and Resources at the end.

I hope you find this information helpful.



Kindle xRef link bug


When I first started generating Mobi files (for the Kindle) in addition to my ePub workflow, I came up with a list of annoying formatting issues that I just accepted and chalked up as “Kindle Formatting Limitations”. ie:

  • No embedded fonts
  • Extremely limited stylesheet options
  • Formatting being ignored when linking from one section to another
  • Page elements being pushed to previous page when linking from one section to another
  • And so on

However, the item highlighted in green (in the above list) bugged me the most because it just didn’t seem right.

After digging much deeper into the issue, I finally found the cause, followed by a solution.
(I use InDesign CS5.5 for the majority of my ePub/Mobi workflows, so that is what I will be referencing in the following examples.)

My workflow:

It seems that the Kindle will choke if an “Anchor” id is placed (inline) with the referenced line of text:

<h1 id="toc_marker-2"><a id="Anchor"/>CHAPTER 2</h1>

This example references the id in “Green” above:

Jumping to Chapter 2 from the TOC link causes no formatting issues on the Kindle

And this example references the id in “Red” above:

Jumping to Chapter 2 from an in-text cross-reference causes the Kindle to ignore formatting for the destination line

Why are there 2 different “id” locations?

InDesign CS5.5 creates ePub “id”s based on 2 types of sources:

  1. In the ePub Export Settings Dialog, you choose which InDesign TOC preset to use in order to create the .ncx file for the ePub

    When InDesign creates these links within the ePub files, it places the “id”s inside the opening html tag:

    <h1 id="toc_marker-2">

    When run through Kindlegen to create the Mobi file, these links work just fine on the Kindle.

  2. When you create internal Hyperlinks and Cross-references within InDesign, they export to ePub links as “id”s wrapped in <a> tags, and then placed in-between the corresponding HTML opening/closing tags:
    <h1 id="toc_marker-2"><a id="Anchor"/>CHAPTER 2</h1>

    When run through Kindlegen to create the Mobi file, these links cause the “loss of formatting” issue (illustrated above).

**It is worth noting that both of these examples of “id” locations are perfectly valid HTML and ePub. The Kindle is the only eBook reader/device (that I am aware of) that does not play nicely with both.

How to fix this on the Kindle?

After some testing, I found that simply moving the “bad id” outside of the HTML tag, solves the issue:

From this:

<h1 id="toc_marker-2"><a id="Anchor"/>CHAPTER 2</h1>

To this:

<a id="Anchor"/><h1 id="toc_marker-2">CHAPTER 2</h1>

How I accomplish this using GREP

I use either Oxygen or TextWrangler (on my Mac) to do my ePub/Mobi post-processing.

  • Oxygen is my preferred program because it does not require cracking open the ePub ahead of time. And it also has built-in ePub 2 validation. However, it is painfully slow when trying to apply batch fixes on large ePub files (hundreds or thousands of internal ePub HTML files), which I do a lot of.
  • I use TextWrangler to run my batch fixes on these larger projects. You need to crack the ePub file open to do so, but it is extremely fast and worth the extra step. And it is also free.

Here is the GREP pattern that I would use to fix the example in this post:


(<h\d/?[^\>]+class="/?[^\>]+">)(<a id="Anchor"/>)



The above pattern splits the search pattern into 2 slices and then flips them.

It can (and should) be re-written to account for other HTML tags (ie. <p>, <pre>, <div>, etc.) and multiple “Anchor id”s (ie. “Anchor-1”, “Anchor-12”, etc.).
Basically, it can be re-written to account for your specific situations.

I hope this is helpful to you all.


Indexes for eBooks (are they necessary?)

I have been banging my head about this issue for a while now.

  • If my printed book has an index, should my eBook?
  • If the book was written and indexed in InDesign, how do I convert the index to clickable hyperlinks for my eBook?
  • Does an eBook index add any more value than the ability to search the digital book?
  • Isn’t the ability to search an eBook much more convenient and intuitive than having an index?

I have converted many types of books to eBooks (ePub and Mobi). Some have included short indexes. Some have no indexes. I have even done one where I included the print book index, but called it “Index of suggested search terms for eBook”, and did not make them clickable.

I am now working on a GIANT cookbook conversion for a 900+ page cookbook that includes an 80+ page printed index. Translated to ePub or mobi, this index list will probably be close to 1000 pages when viewed on a Kindle, iPad, etc. device.

Does this really make any sense?

After thinking about this for a while this morning, I have come to some personal conclusions about indexing for eBooks:

  1. Long indexes have no place in an eBook. The ability to search the content covers any need for it.
  2. A very short index is ok, as long as it doestn’t span more than a few iPad, Kindle, etc. pages.
  3. Printed indexes are convenient because you can quickly flip through the pages with your fingers to find what you are looking for. And then you go to that particular page in your printed book.
  4. Long indexes also tend to break eBooks when reading on certain devices, because it is just too much information for the device to handle.

I am curious as to other people’s thoughts on this subject.


ePub Samples

Here is a small sampling of some books that I recently converted to ePub.

Note: All of these books were initially designed and laid-out (using Adobe InDesign CS4 or CS5.5) for the purpose of traditional printing. Using those same files, I exported to ePub, created custom stylesheets (CSS), and cleaned up the code using Oxygen.

The very nature of the ePub format is to allow enough flexibility so that the books can be read on any size/type of device/reader that can read ePubs. Because of this, the files may look slightly different when compared from one device to another. However, great care has been taken so that the content looks good and is legible on all ePub-compatible readers/devices.

With that said, these ePubs have been optimized for the iPad (since it is by far the most popular ePub reading device). So, the sample images that you are about to see are screen grabs from the iPad.


Art Space Tokyo

Ashley Rawlings & Craig Mod, Pre/Post
(Adobe InDesign CS5.5)

AST Table of Contents

Art Space Tokyo cover and TOC (Horizontal view)

AST chapter start

Sample chapter start with Title and Map (Vertical view)


Map zoomed in to fit the screen (Horizontal view). (You can double-tap images in iBooks in order to zoom in)

AST Interview

Start of Interview section with intros (Vertical view)

AST Interview

Sample Interview section (Horizontal view)


Google SketchUp Cookbook

Bonnie Roskes, O’Reilly Media
(Adobe InDesign CS4)

GSC Table of Contents

Google Sketchup Cookbook cover and TOC (Horizontal view)

GSC spread

Sample spread with images and Note (Horizontal view)

GSC spread

Sample spread with image (Horizontal view)

GSC sample page

Sample page with image and sidebar (Vertical view)


The Geek Atlas

John Graham-Cumming, O’Reilly Media
(Adobe InDesign CS4)

GA Table of Contents

Geek Atlas Table of Contents (Vertical view)

GA page

Section start with title and map (Vertical view)

GA spread

Sample spread with sidebar and image (Horizontal view)


Building the Perfect PC, 3e

Robert Bruce Thompson & Barbara Fritchman Thompson, O’Reilly Media
(Adobe InDesign CS4)

BPpc Table of Contents

Building the Perfect PC cover and TOC (Horizontal view)

BPpc sample spread

Chapter start (Horizontal view)

BPpc sample spread

Start of Hardware Design Criteria section (Horizontal view)

BPpc sample spread

Sample spread with Warning (Horizontal view)

BPpc sample spread

Sample spread with images (Horizontal view)

BPpc sample page

Sample page with table (Vertical view)