Amazon’s Gonna Have My Legs Broken – A Few Tips on Not Getting Your Book Flagged

Amazon recently told the self-publishing world it was sick of their crap and they were gonna pay – and pay hard – for their insolence.

Okay, so it didn’t play out exactly like that, but that’s how a lot of people took it. Teeth were gnashed, curses were hurled to the Heavens, and at least one person vowed to move to Canada over the whole thing. Don’t worry, that’s normal. We writers are surly bunch and if you cross us you can not only expect to die in our next book, but you’d better believe your post or negative review is gonna get the glaring of a lifetime.

The general gist of the message was this: Amazon decided to start flagging books that were essentially unreadable and/or removing them until the flaws were fixed. Any number of things could cause this from excessive typos, to bad formatting, to bad cover images. Now, much as I hate to admit this, there are quite a few books out there that fall into one or more of the above categories. I know for a fact that one of mine definitely fell into one of the categories.

John Doppler is one of the very few people I know of who took the time to, you know, actually contact Amazon and get some hard information. Among other things, he found out that Amazon isn’t using bots to delete your book because you’ve got French words, and the odd typo isn’t going to call down the Amazon hammer. What they’re mostly concerned with is books that start getting an excessive amount of reader feedback about typos and formatting issues that render the final result unreadable. Amazon is employing actual humans to examine the bad books and will simply be asking authors to make their books readable. Once the errors are fixed, it’s all good in the hood.

Fancy that, it wasn’t as draconian as people were fearing.

Most of the issues are well beyond my purview to assist you with. If you’ve got a lot of typos, hire an editor or otherwise fix them. If your cover is really, really bad, hire a graphic designer to work with it. I’m actually available for that one, feel free to drop me a line. If your book has formatting issues that make it unreadable, hire someone to take a look at it. I can actually do that one, too. Drop me a line if you’re interested.

Earlier in this post I said I knew for certain that at least one of my books has serious formatting issues. That book was The Clock Man and it was one of those strange little things you wouldn’t expect would happen. When I took the Word doc and converted it to epub I did all my usual tweaks to clean it up and make it look all purty, but a quirk escaped my testing. One of my friends got hold of me and told me she was having problems reading the book. Apparently each new page would render in black on her older Kindle but immediately fade to a very faint gray.

Light gray on a light background is pretty hard to read.

It turns out some of the e-Ink Kindles have problems with named colors in CSS files. Instead of setting color: #000000 like I should have, I set it to color: black. That rendered beautifully on my tablet and my PC, but turned light gray on my old Kindle keyboard. The solution was simply to not use named colors and use hex codes instead. Or better yet, don’t use them at all, that way the Kindle just defaults to all black text.

So, there you go. One very important tip for you: test your final book on as many devices as possible before you upload it. No matter how good a simulator is, it’s not as good as trying something out on actual hardware.

A few more links (including John Doppler’s) on the whole thing.

Scrap That TOC Post From Earlier

Back in May I posted a quick and dirty primer for making a table of contents.  It was just my way of doing things and I wanted to share it in the hopes that it might help someone.  Last week I was putting together a final collection of short stories for distribution to Smashwords and had to follow their model of making a TOC.  It was much easier.

Don’t do it the way I posted about earlier; that’s old and busted.  The new hotness is actually easier to work with and produces better results.

The way to do it correctly is this:

1). Use whatever you want for your chapter headings.  I still use Word’s Heading 1 style because it throws the chapter title into the navigation pane and that makes editing easier.

Head 1 sample

2). Highlight the chapter heading in your manuscript and select Insert in the Word ribbon (that thing at the top that replaced easy to understand menus) and click Add Bookmark.

Insert Bookmark

Repeat this process for each chapter header.  Note: you can name the bookmarks whatever you feel like.  Make them something easy to remember.  I used the chapter name (or a variant) with no spaces in the name.  Spaces are bad, mmkay.  Don’t worry, no one will be able to see them but you.

3).  Type out your Table of Contents and style it however you please.  That’s one of the major drawbacks to using Word’s Table of Contents generator: it’s brutal to clean up the formatting.  This way is nice and easy and you can make it look however you want.  Once you’re done, highlight each chapter and go Insert on the ribbon bar and click hyperlink.  Make sure to select the Places in the Document button on the left.  Select the bookmark you created earlier and click okay.  Lather, rinse, repeat.

Create Hyperlink

4). Voila.  Note, Smashwords is still trying to get epub submissions (you still have to submit a Word 2003 or 2007 doc file) to work and a lot of your formatting will go out the window as soon your book hits a Kindle (or other tablet).


This example is from the Kindle preview tool that Amazon built and is showing how the mobi file will look on an e-Ink device.

Simpler, easier, faster.  I believe you can do the same thing with Libre Office and Open Office.  Ditch Word’s TOC generator and do it the easy way.


Go read my post on ebook formatting before you begin; this is a follow-on post that focuses on HTML and its good buddy CSS.  If you’re already up on formatting, you’re all good to go.  You definitely don’t have to format the same way I do.  Everyone has a process flow that works for them.  If you don’t have a process flow or want to see a bit more about formatting, check out the post.  If not, no worries.  Carry on.

Once you’ve finished writing your novel or story the journey is only partway over.  You’ve got edit it, format it, make the dreaded table of contentsmake a cover, and get the file ready for publication.  There are services and people out there who do most of this for you but for those of you who like to get your fingers covered with digital dirt the following links will at least get you started.

The post on formatting goes through a lot of the process of formatting and getting the file ready for publication, but there are a few more tricks that might come in handy.  If you’ve never designed a web site you might not be familiar with the twin heroes of web design: HTML and CSS.  The HyperText Markup Language and Cascading Style Sheets work together to define the look and feel a website.  Think of them as extremely lightweight programming languages even though neither of them technically fall into the realm of programming.

For instance, this is programming:

la.alertID = rdr.IsDBNull(9) ? Guid.Empty : new Guid(rdr[“AlertID”].ToString());

This is HTML:

<p>I’m a tag!</p>

This is CSS:

p{font-family: sans-serif;}


Don’t worry.  Things are only strange until you get to know them.  As the Skipper says, “An enemy is just a friend who hasn’t betrayed you yet.”  To get your head around HTML and CSS you don’t need to understand programming at all, especially since this post is focusing on HTML and CSS for eBooks.  Once you hit the realm of web sites the complexity increases dramatically, but an eBook is a pretty straightforward thing.

So, why worry about HTML and CSS in a post that’s supposed to be for authors?  The simple answer is this: an eBook is really nothing more than a very basic website and your eReader is really nothing more than a cut-down web browser.  In a lot of ways it makes an enormous amount of sense to use web technologies for eBook publishing.  They’re established technologies that most developers have already wrapped their heads around and it makes for portable data, which was what the Internet was going for all along.

The HTML code defines what’s in your book and gives it a basic breakdown of what’s a paragraph and what’s title and so on.  The CSS code takes that information and tells the browser how to render it into something that looks decent on a screen.  You don’t have to code out the whole thing from scratch.  If you’re using a modern-ish writing platform like Word, Scrivener, OpenOffice, LibreOffice, or any other number of tools, the program is creating the HTML and CSS for you as you type and format.  All you need to worry about is tweaking the occasional HTML tag or CSS instruction to make things perfect.

If you’re still worried about the idea of coding, don’t fret.  Here, have a kiss from a giraffe.


See! All better!

So, you’ve got everything written and formatted and converted to an epub file, but there are those nagging little things you want to change.  For me, it’s always the damned Table of Contents.  Others might see the epub rendered and want to change some things on the fly.  In order to do that, you need to have a basic understanding of HTML and CSS.  Since an eBook is just a website, I’m going to eschew the complicated stuff and just put together a simple site with some text and then do some basic formatting.

Here’s a simple HTML file with no CSS references in it.  Okay, so there’s one, but it’s commented out and I’m lazy.


and here’s a CSS file that I’ve already done some work on.


And this is what the page looks like in Chrome.

Yuck. Gross.

Yuck. Gross.

So, let’s link up the HTML and CSS files.  Conveniently, I’ve already done this.  If you look back in the HTML file up in the <head> section, you should see a line that looks like this:

<link href=”stylesheet.css” rel=”stylesheet” type=”text/css” />

This links the HTML file to the CSS file.  Now we can make changes to the CSS file and the changes will … cascade to the HTML file.  Meaning any time the browser sees a thing with a particular class name (or a particular type of thing, like an <a> tag), it looks back to the CSS file to figure out how to render it.  If there is no set of specified rules about how to render something, the browser just uses some default values.

So, the files are linked, but we haven’t told the individual elements of the HTML file what parts of the CSS file they’re associated with.  That’s why the screenshot of the site in Chrome looks like crap; those are the default ways of rendering HTML in Chrome.  So, we’ll start at the top with the title and work our way down.

To link the title element (Henchmen) to the correct class in the CSS file, I just have to tell the HTML file what class a title is.  Right now the code that generates the Henchmen line looks like this:


That just means its an HTML paragraph.  To make it all purdy and stuff, I’m going to associate that one thing with a part of the CSS file.  All I have to do is change <p>Henchmen</p> to this:

<p class=”BookTitle”>Henchmen</p> and I get this:

Better, but it still needs some work.

Better, but it still needs some work.

If I start hooking up the rest of the elements in the HTML file, like so:

Each tag now has a class associated with it.

Each p tag now has a class associated with it.

I get this:


Not perfect, but good enough for jazz and government work.

CSS and HTML can do an awful lot more than what I’m showing here.  For instance, check out the CSS Zen Garden sometime.  It’s a site that lets designers use their own CSS files to style the site and it’s an excellent example of what you can do with it.  Obviously, what the talented folks over at the Zen Garden are doing is far more in-depth than anything that will wind up in an eBook any time soon, but it does demonstrate what you can do with CSS.

The rule of thumb in eBook CSS and HTML is to keep it simple, but there are some common CSS settings that will come in handy.  For instance, here’s an example of CSS that Calibre defined for me based on Word formatting when I put Arise together.

.block_5 {

color: black;

display: block;

font-family: serif;

font-size: 0.83333em;

line-height: 1.2;

text-indent: 0;

margin: 0;

padding: 0


Most of it’s pretty obvious but there are a couple oddballs.  display:block, for instance.  Block just means start this element on a new line and take up as much screen real estate as possible before wrapping.   For a kind of decent example look at this page.  Each time there’s a paragraph break there’s an extra line added.  Each paragraph has about 1.2 to 1.5 line spacing, but between paragraphs there’s a 2.0 line space.  The paragraphs are likely defined as block elements with a specific line height.  Each time I hit enter, I get a new paragraph with a new block element, those are spaced around 2.0 or so.

A couple other tags that might come in handy are orphans and widows (Thanks to S.K. Holmesley for pointing this out to me).  An orphan is the first line of a paragraph that gets left on page 1 while the rest of the paragraph continues on page 2.  It looks wonky to see just the first line, so you can set orphans: 2; or however many lines need to be left.  A widow is exactly the opposite, it’s the number of lines that have to fall to the next page if a paragraph gets split.  widows: 2; would ensure at least two lines of the paragraph fall on the next page.  If you have a paragraph where you have to worry about both orphans and widows you either have very small pages or may want to break that paragraph up a bit more.

The CSS generated by programs like calibre is basically the same stuff you see here, there’s just more of it.  Every CSS/HTML interaction works exactly the same way.  If you open an epub in Sigil and something looks off, examine the HTML, find out what class it thinks it is and use that information to look up what the CSS is doing.  If you don’t like it, change it.

It’s pretty hard to seriously mess things up with CSS, but it can be done.  Follow the old standard of backing things up before you mess with them and you’ll be fine.

For more information on CSS, check out W3 Schools CSS reference.

Congrats.  You made it through.  Have a picture of a boxer.


eBook formatting

In addition to having trouble figuring out how to make my first cover, uploading Henchmen to Amazon proved to be a baffling ordeal.  Amazon’s instructions consisted of converting my Word to doc to filtered HTML and uploading it.  It worked but it lost some of my formatting and there was an image at the beginning of the book that disappeared.

I’m a little wiser and more experienced now, so let me give you a little primer on some formatting and getting things ready to go.  When your book is done and you’re ready to push the button the actual upload to Amazon is pretty straightforward.  Getting the ebook to that point can be a little more involved, but isn’t overly difficult.  Be ready to take some time, have backups of your book, and do some trial and error.

You’ll need some software, all of which is free (except the word processors, those range from free to a whole damn lot of money for MS Word).  Some of these links may be dead, but they all worked as of this writing.  I’m assuming you already have some sort of word processor, but there are some other tools that will come in handy.

  • Calibre: This is an ebook converter that can convert from and to almost any format on the planet.  I use it covert from .docx to .epub for upload.
  • Sigil: This will let you crack open an epub and edit the HTML inside of it.  It’s great for tweaking the little things that Word messes up.
  • Kindlegen: Convert .epub files to .mobi files.  This is basically the system Amazon uses on their server side to convert to their version of .mobi so it’s invaluable for seeing what the final product will look like.  Kindlegen is a command-line tool so make sure you’re comfortable with that.  If not, you can use Kindle Previewer to accomplish the same thing.
  • Kindle Previewer: Uses KindleGen in the background to compile to Amazon’s .mobi and let you see how it will look.  It’s great for fnding the little issues you weren’t expecting and you can even copy the created .mobi file to various devices to see how they’ll look.

On the off chance that you’re looking for a decent tool to actually write your book in, there are a whack of them out there.  I use Word 2010 but that’s just because I happen to have a copy of it.  OpenOffice is a great (and free!) alternative.  I’m not as familiar with the quirks of OpenOffice so I’ll write a story in it later and report back.  I know some people who swear by Scrivener, but I haven’t found as much use for it.  Again, I’ve got a copy so I’ll try to create something in it and report back.

So, to clean this mess up a bit, there’s a process that I follow that seems to work well for me.

  1. Write the story or book in Word.  I do my editing and most of my formatting in Word also.
  2. Load the book into Calibre and set some metadata.  Use Calibre to convert to epub.
  3. Use Sigil to edit the epub file
  4. Use the Kindle Previewer to see what it will look like and generate a mobi file
  5. Upload to Amazon KDP
  6. Kick back and wait for it to be processed

To make your writing life as easy as possible just write the story and don’t worry about formatting while you’re writing.  I referenced this in an earlier post, but let me reiterate it.  Don’t do any formatting until you’re done with editing.  Change the default font if Calibri isn’t your cup of tea, but other than that don’t do a thing but type.  The only bit of formatting I recommend is highlighting chapter headers and setting them to Word’s Heading 1 style.  The only reason I do this is because as soon as you set a block of text to Heading 1 or Heading 2 in Word it automatically gets added to the navigation pane.  That makes finding things in a long book much easier.


Word styles are basically CSS styles. Word docx files are zipped XML files with some formatting instructions dropped in.

After you’re done writing and editing you can start formatting.  This is where things start getting more and more nebulous.  There aren’t a whole lot of standards out there for formatting a book other than the end result must be readable.  I prefer a clean look personally, but others prefer more ornate looks.  For some background on formatting and some things that approach being a standard, look to Amazon’s formatting guidelines and Smashwords (PDF download) has a formatting guide of their own.  There are also a whole whack of good formatting guides out there.  Take some time to read up and see if you’re doing anything that’s an absolute no-no.

The general gist on all the formatting guides is to let styles take care of the formatting instead of using lots of hard breaks or tabs.  This is because an ebook is really nothing more than a zipped website and your ebook reader is just a fancy web browser.  All your styling should reflect this.  We’ll see a bit more when we hit the Sigil section.

One thing to definitely take a look at is the use of the magical Pilcrow.  This is the formal name for the paragraph symbol and something I work into casual conversation when I want to make myself look smarter than I really am.  The pilcrow will reveal all your formatting including hard returns, tabs, and whatnot.  If you’ve got a section that simply doesn’t work like it should, use the pilcrow and see what’s going on in the background.

So I told the President, "You really should consider using the picrow to track down that problem."

So I told the President, “You really should consider using the picrow to track down that problem.”

Once you’ve got it formatted and it’s looking good to you, make a bunch of passes through the entire text and see if you’re missing something.  One of the print versions of Arise came back without a page break between a couple of the chapters and the ebook version was missing the glyph on a couple chapters.  It’s easy to miss the little things like that.  But, it did get formatted and came out looking like this:


So … beautfiul …

My normal-style setup was 11pt Garamond, .3 indent from the left, no extra spacing before or after, and a 1.15 line space.  The Heading was set as 14pt Garamond, Bold, Centered, no paragraph indent, 24pt before, 0 after.  The glyph was set centered, no paragraph indent, 0 pt before, 50 pt after.

Don’t get too wedded to your font choice.  Remember, an ebook is a web site and the eReader is a web browser.  Files called .css (Cascading Style Sheets) determine the formatting and can be overridden by the browser.  Some things like centering, bolding, points before and after elements, and things like that will stick, but your font can be whisked away in the blink of an eye by a reader who prefers her headlines to be displayed in Comic Sans or his body text in Papyrus (there’s no accounting for taste).  As soon as you decide to do the print copy through CreateSpace you can really fret about fonts; until then find something that works and realize most people will be reading in Times New Roman or something like that.

Just as quick show, here’s the TOC from Henchmen formatted in Word.  Each line is selectable and will link to the appropriate chapter.  Looks good so far, right?  Hold onto that thought for a minute.


Not gonna lie, editing a TOC in Word is the stuff of nightmares. It tooks several iterations to get to this point and I swore I’d never touch it again.

That done, it’s time to load the sucker into Calibre and let Calibre perform its magic.  There are much better and more thorough guides out there on using Calibre than I could come up with here.  For our purposes, you need to add your document (straight from .docx, in my case), edit the metadata to set the title and author correctly, convert to .epub, and save to disk.  Don’t worry about adding a cover at this point.  I just added a cover to mine because I was sending it out to reviewers (none of whom were interested :(, oh, ah).  Recently I’ve heard some rumors that epub files created with Calibre won’t upload to Amazon, but I just did one to try it out and it worked fine so there may be other extenuating circumstances.

Had to clean up my Calibre list.

I appreciate software of this calibre.

Now, we’ve got the book written, edited, formatted, and coverted to epub.  It’s time to see what it will look like on a Kindle.  Fire up the Kindle Previewer and load up your epub file.  NOTE: Kindle Previewer is using Kindlegen in the background to convert your text.  When it’s done it will show you where it made the converted file.  For the most part it comes out okay until we hit this page:


Standard issue HTML tag rendering.

The TOC is a list of hyperlinks and <a> tags usually render like this.  It’s both a good and a bad thing.  It’s good because it’s a visual cue to the reader that they can click on a chapter title and go to the chapter.  By the way, this is how Henchmen actually looks on a Kindle.  I left it alone because of the visual cue thing.  It may not look as clean as it could, but this isn’t a print a book so some aspects of design have to be different.  It’s largely due to our good friend CSS acting up again.  Here’s where Sigil comes in handy.

Fire up Sigil and open the epub you created earlier.  You’ll get a mass of raw HTML.


One HTML file per chapter. I’ve also seen other programs create a single HMTL file for the whole book.

Note the highlighted text:

<p class=”block_6″><a class=”text_1″ href=”../Text/index_split_004.html#id_Toc403116700″>01 | It Doesn’t Stay In Vegas</a></p>

That class=”text_1″ links to the CSS file stylesheet.css down in the Styles folder.  If you scroll down you’ll find a section that looks like this:

.text_1 {

color: #00F;

text-decoration: underline


.text_1 is the class name.  Color (#00F) is the hex representation of the color and text-decoration: underline says underline the text.  If we tweak around a little and set the Color to black (#000) and comment out the text-decoration line we can change the way hyperlinks look.  So I’ll change to the following:

.text_1 {

color: #000;

/*text-decoration: underline*/


and get:



Two things to note here.  1: The links are still underlined.  This is because, like font, there are some expected things that just happen; in this case links are underlined.  2: Note the color for chapter 3 is still blue.  Go back to the big Sigil picture and you can see why.  Chapter 3’s css style is text_2, not text_1.  You can either modify the text_2 style in the stylesheet or reset the Chapter 3 line to use text_1.  Personally, I’d recommend fixing the HTML instead of modifying the css.  CSS styles apply to all elements that reference that style so a change in one place can have far reaching effects.  More than likely it’s fine to just change the text_2 css, but if anything else anywhere in your book was using that style, it will be refomatted.

Keep iterating through this process until you like what you’ve got.  Remember how I said Kindle Previewer will make a converted file for you?  Keep track of where it puts them.  When you’re satisfied, take the final mobi file and you can upload it directly into KDP.  Amazon will also accept HTML files, doc and docx files, and epub files.

I didn’t go into too much depth here on using some of these tools because there are other, better tutorials out there for them.  This post is just meant to give you an idea of what you can do and some of the tools that will help you do it.  There are also people out there who specialize in formatting eBook files so if it looks too arduous, check into a professional formatter.  If you have other questions or comments, drop ’em in the comments and I’ll see if I can help out.

Spend some time on your formatting.  You spent months writing the book, a few days of formatting is time well spent.