1 | How To Make EPUB & MOBI Files That Don't Suck

his tutorial helps authors and producers make EPUB and MOBI (Kindle) files that don't suck. Using this method to format EPUB & MOBI yields a working GoTo table of contents and ncx navigation. Users can set a custom start page for their MOBI. Images, block quotes and text-styling are covered, too (among about a million other things).

Unlike other e-book formatting tutorials, this one gets users over the CSS roadblock by providing a pre-made CSS file that closely mimics standard print convention.

The tutorial spends a lot of time on troubleshooting content: what to avoid in EPUB and MOBI, and how to optimize 'safe' content for digital formats. The goal here is to produce lightweight, trouble-free EPUB and MOBI files that can display on any device or app an end-user might throw our way.

BETA Statement

BETA: September, 2015

September UPDATE:

• • Updated ebookstyle.css file to add a "safe" header class.

  • More about the Nook issues; applying "safe" class to all h1 elements.

  • Changed: use "padding" instead of "margin".

  • Many changes regarding cover images and cover pages.

  • Navigation clean-up.

August UPDATE: Lots of things in this round of updates, and more coming when I have a chance.

• • I have updated my Sigil version to 0.8.6. You should, too (but don't upgrade to 0.8.7 yet, please).

  • The CSS file included in this tutorial has been updated again to prevent an issue with Nook. If you have downloaded this file in the past, please overwrite with this version.

Technically, this tutorial is STILL in beta stage. 'Beta' means that the tutorial wording, images, layout, supplemental and reference material is still in flux. The EPUB/MOBI creation process works just fine.

• • Users might find ##Revise tags still in the text.

  • Many features (site map, navigation and master checklist) are still in the works.

Please report any problems, or direct any questions to Meg at mymegsilver AT gmail DOT com.

SPECIAL REQUEST: (ongoing) Any tutorial users who have used this production method and uploaded files to iTunes, please let me know how it went. Reports of issues and successes will be extremely helpful to your fellow producers.

INTRO: The Dull Bits

General Info:

• • The method outlined in this tutorial works best for straight-form fiction.

  • Much of what’s covered in this tutorial could apply to more complex productions, but this method is not recommended for poetry, non-fiction, graphic novels or technical writing.

  • This tutorial is Windows-biased. Mackers might need to tweak certain procedures for OSX.

  • This tutorial creates vendor-ready files suitable for upload at major retailers, including Amazon, Barnes & Noble, Kobo, Apple, D2D, All Romance eBooks, et al. (The EPUB will work at Smashwords, though uploading EPUB to Smashwords is not a recommended practice.)

General Specifics

For those who know just enough to be mildly dangerous (like myself), here's a list of stuff that might matter:

• 1. Media overlays are not addressed in this tutorial.

  2. Tutorial is EPUB2 friendly. EPUB3 tweaks will be made once those tweaks are more clear.

  3. This tutorial is intended for the DIY crowd on a tight budget. It's supposed to be simple and streamlined, using one source file to serve all masters. This is a tall order, so before emailing to man-splain the bee in your bonnet, please understand I'm working on happy mediums, here. I know that not everything is perfect, and that not everything will work for every platform. Some of what's here is the coding equivalent of duct-tape and WD40. Sorry, but there's a price to be paid for mass audience, multi-purpose info.

  4. No, this tutorial does not include Calibre. I love Calibre, and I personally feel that Kovid Goyal is one of the most wonderful, generous and gifted people in digital publishing. I just learned on different tools, so tutorial users will, too.

  5. No, this tutorial does not use Word™'s filtered HTML. While I do appreciate Microsoft's attempts at HTML export, the code is just too detailed and restrictive for our purposes.

General Overview:

Here's a bare-bones description of the process:

• 1. User content is prepared for digital production.

  2. User content is turned into raw HTML.

  3. The HTML file is then turned into a fully functioning EPUB file.

  4. The EPUB file is then converted to the MOBI format.

Why convert to MOBI from EPUB? Because this is the only method I have ever found that is successful 100% of the time (while still yielding all the professional-grade bells and whistles).

Benefits of this method over others?

• 1. Lightweight EPUBs cleaner than a surgical suite.

  2. EPUBs pass validation!

  3. Custom start page for the MOBI file. (This is currently impossible in EPUB format. Do not shoot the messenger in the face very hard.) UPDATE: This is becoming less and less possible for Kindle, too, thanks to some tweaks on their end. We can still define our start page, but please understand that KDP may ignore our Start/Beginning semantics to skip over all front matter.

  4. All MOBI bells and whistles work, including ncx navigation and the GoTo table of contents.

The file below was produced using this method, shown on a (poorly scanned) Kindle™ Keyboard.

How much computer stuff and HTML should users know beforehand?

Probably less than you’d think. The tutorial relies heavily on graphics to help users monkey-see-monkey-do their way through the process.

That said, the beta-process for this tutorial continues to delight and confound. To be fair (meaning completely unfair) EPUB production is not for everyone. There wouldn't be professional producers——or thirty thousand different e-book-making tutorials——out there if this stuff were intuitive and simple.

If you are an author who still uses the space bar or tabs to position content in word processors, this tutorial is probably not for you. The learning curve will be dauntingly steep for those moored in spatial type-setting principles. It's taken me fifteen years to get from there to here. I can't even imagine how frustrating this tutorial would seem, seen through those eyes.

And I have to say, indie or not, there is no shame in hiring a formatter. If nothing else, this tutorial might help users better prepare their content for a professional, and help figure out what to look for in a formatter.

What Can Possibly Go Wrong?

The top three reasons files might still suck after completing this method:

• 1. A content-based problem

  2. A platform-based problem

  3. A producer-based problem

Content-based problem: First-time users can expect a majority of their time to be taken up with revising e-book content. This will include removing or revising things that make the final product suck, like illegal characters or an entire laundry list of issues known to cause rendering problems.

These issues are extensively covered in the Editorial Concerns section. After producing hundreds of e-book files, I still refer to this section almost every time to make sure I have accounted for all the potential bugaboos.

Platform-based problem: I'm sure it's news to no one that all ebook-viewing devices and apps are not created equal. Though they all operate on similar ones and zeroes, different interpretations and "features" (BUGS) can cause some variance in output. BEFORE BLAMING ANYTHING ON A BUG, check your code. The problem is almost always in the code, not the platform. Sometimes this means stroking Google's fur backwards and straight-up moving into mobileread's forums. In fact, it almost always means moving into mobileread's forums.

Producer-based problem: Having worked with authors for 15+ years (and played an innocent bystander at the shotgun wedding between print production and HTML) I can tell you, beyond any doubt, the number one reason authors suck at e-book production: unrealistic expectations.

Those unrealistic expectations should begin to unravel when you read these next two sentences:

Print books are made of paper and ink. E-books are made of ones and zeroes.

Welcome, Dorothy. Mind the digital gap. We are somewhat limited by the constraints of the HTML coding language. Things are getting better, but there are still a lot of things that can be done in print that just plain cannot be faithfully reproduced in the HTML/EPUB/MOBI format.

Perhaps even more to the point, there are a lot of things authors expect to be able to control that they cannot control in the HTML/EPUB/MOBI version.

Here's a list of what we can control:

• • content (front-matter, story, back-matter)

  • page breaks

  • table-of-contents entries

  • image positioning (to an extent)

  • the page the MOBI version opens to the first time a user opens the file

  • indent depth

  • italic font

  • bold font

  • text justification

Here's a list of what we CAN'T control:

• • font face or font type (no, I'm not kidding)

  • font size (Yes, I'm serious)

  • color

  • line height/spacing

  • pages

  • margins

  • page headers and footers

Basically what it all comes down to is this question: Do I want to control everything, or do I want my EPUB and MOBI to function properly?

Abiding Philosophy

If you had trouble answering that question, remember these two things about this tutorial:

• 1. The reader is our god. Anything that could jeopardize their immersion is our mortal enemy.

  2. Base every decision upon what will produce clean, stable files that can render flawlessly on as many devices and apps as possible. (Simpler is ALWAYS the right choice)

Recommendations

When you click onto the next page, you'll find yourself diving straight into shallow end of the production pool. Before that happens and everyone's attention scatters, allow me to make a couple simple recommendations:

• • Read the entire tutorial through to the end (at least once) before attempting anything.

  • Don't be intimidated. This is sorta like learning to drive a stick-shift: it seems insanely complicated at first, but after a few days, you're shifting gears, talking on your phone and flipping off other drivers, all at the same time. (Yeah, don't actually use your phone while driving, mkay?)

  • Learn to rely on the key. The key is a simple reference file created in the next section. The key is literally the key to everything in this process, and while a lot of beta testers opted to skip it (for whatever stubborn reason) roughly 80% of the problems and frustrations they experienced would have been avoided if they had used a project key. So please don't skip it.

Next >> Save Your Sanity