eBook Formatting: Possibilities and Limitations

While we are well into the eBook revolution--far enough in so that it's pretty safe to say eBooks and eReaders are not a fad and have become a permanent disruption to print books--there are still significant limitations on how eBooks can be presented to the reader.

TL;DR

• You CANNOT duplicate sophisticated print typography in an eBook
• Readability is still the key, but your formatting choices are limited
• eReaders give most of the formatting/display control to the READER not the WRITER
• best practice involves formatting for the simplest common denominator (compatible with all devices)
• everything written here will change

e-Book Formats: MOBI and EPUB
At the very least, you will need to create two types of eBook formats to get your book in all the major marketplaces. Yes, eBooks are currently where Betamax and VHS tapes were in the late 1970's with two major formats that don't play well in one another's sandboxes. I'm referring to MOBI (Amazon's basic file) and EPUB (everyone else's). There are dozens of other eBook formats, but none of them have the market presence of these two.   

(If you want to see a rundown of all of them, this wikipedia article is a great overview.)

"But what about .azw and .kf8?" You ask. Those are Amazon's tweaked formats for their tablet devices. Currently, all amazon devices will render MOBI files and while you can do some fancier things with kf8 for the fire, those fancy things will not be shown on earlier devices. 

The good news is that both EPUB and MOBI are actually a limited subset of HTML with some fancy wrapping to make them displayable in eReaders, along with the cover and any metadata the author wants included. 

HTML? What's the Problem?

If you were displaying your book as a webpage, you could have it render just about any way you wanted. There's so much you can do with a good combination of HTML and CSS, even without resorting to other fancier programming. BUT, eReaders will not render all of that lovely code.

Understanding the limitations of what code eReaders will and won't display is key to creating clean eBooks. (An example of the HTML you can use for making Amazon compliant ebooks.)

Currently, there is no good way to render dropped caps, for example. It is possible to create an image file for the capital letter and have the rest of the word be text. However, when people increase the font size on their eReaders, your lovely image of a dropped cap will not change in size along with it. In addition, To the best of my knowledge, it is not possible to create a transparent image that will display properly on eReaders. A white background for a text image or a scene break glyph will be invisible if the user selects a white background for the eReader. But that is not a given and you need to consider how your images will look if the reader selects white letters on a black background, for example. (Your lovely image of a black dropped cap on a white background will potentially look quite odd.)

And because the exact subset of HTML that each reader is happy rendering is different, "KISS" is the rule that applies.

	This is an example of the print book format of the first page of THE BETWEEN. Notice the very simple formatting choices--Bold, large initial letter, first 5 words of the initial paragraph in small caps, leading paragraph flush with the left margin, subsequent paragraphs indented. The serif font was chosen for in print readability and the leading and kerning were also set. The text is fully justified, right and left. Notice the hyphenated world in line two "be-fore". That will be the same in each copy of the book.
	This is a screen shot of the EPUB version of the same book. Notice the chapter heading is indented, but not centered* and the font is one that the eReader defaults to. Bold formatting is understood and rendered, as is small caps for the opening words, but all paragraphs are indented* and there is no larger or bold font for the first letter of the first word. There are no hyphenated words on this page, but that would change depending on the font size chosen by the reader. The eReader wil automatically reflow the text. Text is only left-justified.
	This is a screen shot from the kindle paperwhite of the same page. Notice the different font chosen. It is a san-serif font. The text is fully justified, right and left. Regardless of the stylistic choices, be certain to select some typographic look that distinguishes the opening line of a chapter and/or scene.

*Note: Centered headings and no indents of initial paragraphs CAN be easily coded in current eBooks, but were not in this case.

Because I wanted the end experience to be similar across print and eBook platforms, I chose simple formatting that biased readability over all other style considerations.

Embedded Fonts
We are just beginning to see the ability to embed fonts in eBook files. However, this may not be best practice given that the fonts will not render on earlier and eInk devices. Again, I caution you to format thinking of backwards compatibility.

If you have a book whose design heavily relies on custom fonts and precise formatting and you feel the eBook must match it, then the only choice you have currently is to have a specific book app created in android and/or apple formats. The tablets will likely render it appropriately, but not a dedicated eReader (kindle, nook, etc) Therefore, your market will be smaller.

Tables and Images
Because of the way eReaders allow end users to control font and font size and because of the wide assortment of screen sizes of those readers, displaying tables and images can be problematic.

Consider your readers will be looking at your book on a smartphone screen and/or a large tablet. Images can be centered, but playing with sophisticated text flow around them won't be able to be rendered by most eReaders. Keeping the images reasonably small will keep the image and the text at least potentially on the same eReader page.

For tables, the problem is even worse. Large amounts of data in tables will be broken over multiple pages, especially in small screened devices. One way around this is to present your tables as image files. However, the text will not reflow if the user increases the font size and a large image may also break over a page.

You can also consider displaying table data as bulleted lists, if possible. It's potentially a better solution for device agnostic formatting in that it allows text size reflow. However, some tables may not be able to be converted in this way and still make sense. Another possible solution is to present the data as an image along with a link to the table on a webpage or as a downloadable pdf file for the user.

Best Practice, as of February 6, 2013
eBook formatting is still in its infancy. Most of what I have reviewed here will likely change in the next several  months to a year as technology marches on. But for today, at least, best practice includes:

• simple formatting for readability over other style considerations, and, 
• backwards compatibility to reach all eReader devices.

If you are a DIY type, you are welcome to download a free guide to using a combination of open office and calibre (both open source, free programs) to format and convert documents to eBooks. This will only do a good job on its own with relatively simple novels. More complex formatting requires hand coding in HTML, using CSS, and understanding what eReaders will and will not render.

I appreciate your thoughts on this post and if you have information and/or resources to add, please do leave a comment.