Friday, February 15, 2013
When you’re satisfied with the state of your HTML file, it’s time to submit it to Amazon’s Kindle Direct Publishing. Again, that’s at
If you have pictures in your book, you’ll have both an HTML file and a separate folder with an associated name. Before sending all this to Amazon KDP, you need to combine it into a single Zip archive. Do not move your picture files out of the folder or rename it. If you do, Word’s HTML links to them won’t work, and the Kindle converter won’t know where to find them! Instead, include the entire folder.
On Windows, select both the file and the folder, then right-click and choose “Send to compressed (zipped) folder.” Or you can zip just the HTML file and then add the other folder to the archive. On the Mac, select file and folder, then Control-click and use the Compress command; or find that command on the File menu.
Also at this time, you’ll need a book cover, a book description, and a selection of book categories. Besides using the cover image for your Amazon book page, Amazon will insert it at the beginning of your Kindle book. Do not try to add the cover ahead of time. I’ll say more about all this later.
Your submission has probably not been lost but is instead stuck in a queue. If you return to your Dashboard five or ten minutes later, you will probably see that the title is in Draft status. Return then to the submission page and again click “Save and Publish,” and you should see an acceptance message within seconds. Of course, you’re less likely to have any problem if you submit at less busy times.
Posted by Aaron Shepard at 9:33 AM
Thursday, February 14, 2013
In this step, you’ll do test conversions of your HTML to Kindle book format and check the results. You may also want to disassemble the Kindle book file for study or troubleshooting.
Let’s get one thing straight right now: If you do not test your book, it is not likely to come out as you want. You cannot count on anything—Word, Amazon KDP, this book, or even a designer you hire—to produce a flawless book. Serious Kindle publishing requires at least a reasonable amount of testing.
Better to find the problems yourself than to read about them in one-star customer reviews!
Originally, the chief difficulty of formatting for the Kindle came from its substandard, deficient ebook format. Nowadays, the chief problem is that there is no one Kindle. There are several families of Kindle, both hardware and software, with a variety of members in each family, and more than one basic format spread across them. So, formatting for the Kindle is much like designing Web pages in the 1990s, when designers had to deal with multiple Web browsers and their generations, each one interpreting HTML a bit differently. In other words, it’s a mess.
Here are the families of Kindle.
Kindle. The original Kindle, with its e-ink screen, has evolved through several generations and has now split into two models, with and without a keyboard. Kindle DX was an earlier, larger model.
Kindle Touch and Kindle Paperwhite. The Kindle Touch, with its touch screen, has evolved into the Paperwhite, adding backlighting and high resolution. It is the most advanced of the e-ink Kindles, and the one most likely to cause formatting problems.
Kindle Fire. This is Amazon’s tablet, with a customized Android operating system. The Fire comes in different sizes, while HD models have high-resolution displays. Unfortunately, the Fire has been optimized for movies, with its screen much taller and narrower than that of any other Kindle.
Mobile Kindles. These include Kindle apps for tablets like iPad, Android, and Windows 8, and for smartphones like iPhone, Android, Windows Phone, and Blackberry. They tend to lag in capability.
Desktop Kindles. For reading on your computer. Includes Kindle for PC and and Kindle for Mac. They’re available for free here:
Kindle Cloud Reader. For reading in a Web browser. Supported browsers include Firefox, Chrome, and Safari. Access it for free at
Besides producing all these varieties of Kindle, Amazon has adopted two completely different ebook formats to be read on them. The original Kindle format was called Mobipocket, or MOBI, after the company that created it and that was then acquired by Amazon. This is a rudimentary, outdated format designed for older cell phones. It is still the basic format for many Kindles.
Starting in 2011, Amazon began a move to Kindle Format 8, or KF8. This is a more modern format, similar to EPUB in many ways, but still proprietary. It’s currently used mostly on the Kindle Fire and the Paperwhite. Amazon has said it would migrate other Kindles to KF8 but has been slow in doing so.
When the Kindle converter processes your book, it converts it to both MOBI and KF8 formats and packs both into a single file. One or the other format is then chosen according to the Kindle being used, and sometimes even according to whether the book has flowing text or fixed format. And of course, the interpretation of either MOBI or KF8 varies from one type of Kindle to the other.
Can you see now why it’s so important to test for a variety of Kindles?
Amazon provides more than one option both for converting your files to a Kindle book and for previewing it before final submission. At various times, you might want to choose different methods. Let’s look at the options.
Online. The simplest and most direct methods of converting and previewing your book are provided on the Amazon KDP site itself. That site, again, is at
Once you’ve signed up for an account there, you can also start the setup for your book title. That lets you upload and convert your files any number of times for testing before you’re ready to publish.
You can even set up a book title you never intend to publish, and use it to test any book or to just experiment. At this writing, for example, the titles on my KDP Bookshelf include Test and Test 2. They allow me to test new versions of a book already published—such as this one—without disturbing the finished files I’ve submitted earlier or taking the chance I’ll release a draft by mistake.
Upload and conversion normally take only a minute or two. And since this is also the method you’ll use for final submission, you know you’re getting the most reliable result possible. (For more on procedure, see the upcoming section on “Submitting.”)
When your book is ready, you can click “Preview book” to see it in KDP’s online previewer, which allows you to choose among several different Kindle models for emulation. But though this is the easiest way to preview, even Amazon warns it is not that accurate, especially for pictures. Personally, I almost never use it, and I recommend you ignore it, too.
Desktop. After conversion, Amazon KDP will also offer the option of downloading both your book and a previewer to run on either Windows or Mac. Though not perfect, this Kindle Previewer provides the best possible look at your book without seeing it on actual Kindles. The Previewer can also be downloaded here:
When you launch the Previewer, it opens a window with option settings, helpful links, and Amazon announcements—including notice of Previewer updates. You can open your book through the File menu, but you can also just drag and drop it on this window. To get multiple preview windows for comparisons, just launch the Previewer more than once.
As with the online previewer, you can choose among several Kindle models to emulate, selecting from the Devices menu for Kindle families, then from the top tabs for individual models. You can test both external links and internal navigation, and change settings where applicable for screen orientation, font size, font face, and color mode—Normal, Night, and Sepia. To spot problems, you should test as many combinations of device and settings as practical.
Though the Previewer allows you to change font size, the default Size 3 will give you a sense of what will fit a single Kindle screen by default. This size will no doubt look too big to you, but remember that the Previewer is displaying a magnified view. Of course, you’ll need to change font size for the iPhone!
As valuable as the Kindle Previewer is for previewing, it has another, less-known capability worth almost as much: It can be used to convert your HTML file to a Kindle book! Amazon’s Kindle converter is built right into the Previewer. All you need do is open or drag in your HTML file, and the Previewer will handle the rest.
The conversion provided by the Previewer is not quite as good as the one you get at Amazon KDP. Specifically, your cover will be missing, and you may also get error messages for navigation—like telling you that your Kindle book lacks a table of contents. Still, joint converting and previewing in the Previewer lets you run quick and mostly accurate tests of formatting without the need to visit Amazon KDP and wait for processing. Most of my experiments for this book have relied on the Kindle Previewer for both previewing and conversion.
Another advantage of converting in the Previewer is that you get access to a log of what Amazon calls “Compilation Details,” including warnings and error messages. These can be valuable in pinpointing errors in your files or in just studying how the converter operates.
Instead of running directly on Windows or Mac OS, the Kindle Previewer relies on a cross-platform system add-in called Java; and on the Mac, also on another add-in called X11. These dependencies sometimes cause problems in running the program. If your Previewer isn’t working properly, see the section in the Appendix on “Previewer Problems.”
The Kindle converter—formally called KindleGen—is also available on its own, for use on Windows, Mac, and Linux. Direct use of KindleGen is too geeky and marginal to discuss in this book, but if you like, you can find the program here:
On Kindles. If your Kindle book works well on the Kindle Previewer, it’s more than likely to work well on actual Kindles. Still, it should be obvious that the ultimate test is to try it on the Kindles themselves. Of course, no one expects you to have access to every single Kindle model. But almost anyone can get their book on one or more.
You can start with one of the free desktop Kindles for Windows or Mac. Again, they’re available here:
Once installed, these apps will open your book automatically when you just double-click it.
The tricky part, though, is that the app will also add the book to your desktop Kindle Library, which you access through the app. The next time you double-click that book on your desktop, or even just a book with the same file name, it’s the copy already in your Library that you’ll see. To make a newer version open instead, you’ll have to either make sure the new file has a different name or else delete the old version from the Library. (If you convert with the Kindle Previewer, it automatically gives your book file a unique name.)
If you own a major type of tablet or smartphone—Apple, Android, Windows, or Blackberry—then Amazon has a Kindle app for you. So, you have another Kindle for testing.
You may already have one or more of Amazon’s hardware Kindles for your own reading. On the other hand, I’m often surprised to find people wanting to publish on Kindle who don’t own or use one themselves and may never even have held one.
Kindles are now cheap enough that, if you’re serious about Kindle publishing, there’s seldom a reason you can’t own one or more just for testing. For my own tests, I have one Kindle from each major family—a latest-generation basic Kindle, a Kindle Paperwhite, and a 7-inch Kindle Fire HD. All together, they cost no more than a single Adobe publishing app!
To get your Kindle book onto most hardware Kindles, all you need do is connect the Kindle to your computer with the USB cable you use for charging, or one like it—one with a micro USB plug, for all but the oldest Kindles. In the Kindle’s directory, you should see a “documents” folder where you can drop your book. The Kindle Fire, though, is more complicated and varies from model to model, so refer to your user’s guide or search online for instructions.
A simple alternate method that works for all Kindles is to use one of Amazon’s Send to Kindle desktop applications, available for Windows or Mac. Find them here:
These apps upload the file to Amazon, which turns around and sends it back to any one or more selected Kindles via Wi-Fi or Whispernet. In most cases, you’ll want to tell the app not to archive the document in your online Kindle library. Along with that, make sure your Kindle is set to show what’s on your device, not in the Cloud. Also note that, for a Kindle Fire, your book will wind up in the Docs section rather than under Books.
Reportedly, sending a Kindle book to your Kindle by email can strip out advanced features—so, if you try that, do so cautiously.
Inspecting your Kindle book is an optional procedure that involves taking apart the book package and looking at its component files. It’s particularly useful for checking on how the Kindle converter has processed your pictures. It can also be used in troubleshooting your book’s formatting and navigation, if you’re familiar enough with HTML.
If you know much about the EPUB format, you probably know that it’s actually a collection of files in a Zip archive. That makes it easy to take apart and put back together. A Kindle book too is a collection of files, but packaged in a less common format—a Python database. To take it apart, you need a utility called KindleUnpack (formerly MobiUnpack). It can be downloaded from the first post in this forum thread:
KindleUnpack requires some version of the Python software language to be installed on your computer. Macs already have it. For Windows, you can download free versions from either of these locations, among others:
What you’ll see after unpacking includes files and folders for two different versions of your Kindle book—the Kindle’s old MOBI format (here called “mobi7”) and the newer KF8 (here called “mobi8”). Each version will have its own HTML file for the book contents, and its own set of image files.
If previewing shows that you need to make changes, do not make them in the HTML file—or at least not just in there. Go back to your Word document and make them in that. You want to maintain that document as a source file you can easily change at any time and then convert again quickly.
You may have trouble starting the Previewer if you are on an older, 32-bit computer running Windows 7 or Vista. In that case, Amazon advises you to set the Previewer’s compatibility mode to “Windows XP (Service Pack 3).” To do this, right-click on the Previewer shortcut in your Start menu, click on “Properties,” and go to the Compatibility tab.
On both Windows and Mac, the Kindle Previewer relies on Java, a cross-platform system add-on. This means that problems with the Previewer may stem from incompatibility with the version of Java on your computer, possibly resulting from Java updates. At one point, for instance, the Previewer worked on the Mac only with Java 6—the last version issued by Apple itself—while failing with Java 7—a version more up-to-date but issued by another source.
By default, the newest versions of OS X don’t include Java at all. But they should prompt you to download and install it when needed.
On the Mac, the Kindle Previewer’s Paperwhite emulation relies on an archaic system add-on called X11, which any commercial software developer would be ashamed to use. If you don’t already have this on your computer, the Previewer is supposed to prompt you to install it. You can then download and install XQuartz, the X11 version that comes from an independent source but is supported by Apple. Find it at
To make it work after installaton, you’ll have to log out or restart and also consent to allow “webreader” to accept incoming network connections.
The problem is, you may not get a prompt if X11 is already in your system but in an older, incomplete, or incompatible version. The Previewer may then open but go into an endless round of error messages when you try to view your Kindle book on Paperwhite. And it doesn’t help that Paperwhite is the Previewer’s default for initial display of your book.
If you run into such trouble, your first step is to uninstall each of the following two folders that may be in your usr folder.
Don’t know where the usr folder is? It’s at the root of your primary hard drive or partition, along with Applications and System—but, of course, it’s invisible. So, to get to the folders inside usr, you must have a utility that makes all your hidden files and folders visible, or else use this command in your Terminal utility:
sudo rm -rf /usr/X11/ /usr/X11R6/
Note that Terminal won’t show your password when you type it and won’t tell you the folders are deleted. You’ll just see a new prompt. You can then install XQuartz.
If you get really desperate, you might consider running the Windows version of the Previewer in a Windows emulator like VMWare Fusion.
Posted by Aaron Shepard at 1:59 PM
Wednesday, February 13, 2013
Once you have Word’s HTML, you can modify it to better suit the Kindle. Some code you’ll change to handle older Kindles with quirky and deficient HTML support. Some you’ll change to take advantage of advanced capabilities in newer Kindles. Some you’ll change to conform to Amazon’s recommendations and guidelines. And some you’ll change to prevent the Kindle converter from overriding your preferred formatting with its own.
My suggested code tweaks are distributed throughout this book so I can discuss them in the context of the formatting they adjust. They’re labeled, though, and on newer Kindles, you’ll see them distinguished by shaded boxes. This will help you pick them out quickly when you get to that stage of processing.
Can you ignore the tweaks entirely? Earlier versions of this book said yes, and that’s still true to some extent. In fact, that’s pretty much what Amazon tells you, as one of its allowed options is to submit a Word document itself without even bothering to export the HTML.
The question is, are you as tolerant of quirks and flaws and poor formatting as Kindle users generally have shown themselves? If not, you’ll have to tweak code.
Though it’s possible to modify HTML in Word or Notepad (Windows) or TextEdit (Mac), that can be tricky or else not very efficient. I suggest you instead use a dedicated code editor.
On Windows, the most popular code editor is the free Notepad++. Find it at
On the Mac, I recommend BBEdit from Bare Bones Software. (BBEdit has been my own HTML editor since around 1996.) Find it at
Bare Bones also offers a free but much less capable editor called TextWrangler.
Don’t confuse a code editor with a consumer program for building Web sites. Most of those programs take control of your code instead of letting you do what you want. That’s not likely to work.
If you do wind up using Word to modify your code, you’ll need to open and edit the file as “Plain Text” or “Text Only.” This requires turning on “Confirm file format conversion at Open” in Word’s General or Advanced General options or preferences. Otherwise, Word will automatically convert your HTML back to Word format on opening. Once you have the file opened correctly, it will automatically save in the same format.
Also, to protect straight quotes—single and double—in your code, make sure “Smart Quotes” are turned off beforehand in “AutoFormat As You Type.” And then make sure they’re restored afterwards! (More on “Smart Quotes” later.)
One nice but hidden feature of Word’s find-and-replace is that it offers the use of a large number of wildcards—many more than you’ll see in the Find and Replace dialog box. To learn what’s available, search on “wildcards” in Word Help.
To edit your code in the Mac’s TextEdit, you must first go the “Open and Save” tab in Preferences. Under “When Opening a File,” make sure “Ignore rich text commands in HTML files” is selected. This will tell TextEdit to open the file as plain text instead of formatted.
When tweaking code, you’re going to want to make sure you don’t introduce errors. If you’re working in a code editor, it may include a built-in syntax checker for this. If not, you can check your code by uploading it all to a site like the W3C’s Markup Validation Service.
Of course, before you can check your HTML for errors you add, you’ll have to get rid of the ones Word has already made. Luckily, they are few, but one is a doozy. I’ll point out less common errors of Word as we go along—especially in its <img> tags—but here are the two most basic ones, along with their fixes. Remember that all quotes must be straight.
• The HTML exported by Word is a version called HTML 4.01 Transitional. This is supposed to be identified in the HTML document by a statement called a doctype, so that browsers and syntax checkers know what they’re dealing with—but Word leaves it out. Ironically, this can make a syntax checker spew out hundreds or thousands of false alarms, because it checks by the wrong set of rules!
So, start by adding the doctype to the beginning of your code, before anything else in the document. If you’re using a text editor like BBEdit, you may find a command that will insert it for you. If not, you can type it yourself:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Or if typing it is too intimidating, you can copy it from many places online, including here:
• Next, fix Word’s <style> tag, near the top of the document.
Replace: <style type="text/css">
Replace: <style type="text/css">
For books with text only, those two errors may be the only ones a syntax checker would complain about!
Most of the code tweaks I’ll suggest are simple find-and-replace operations. If you use a number of them, though, you may find it simplest to combine them in a single macro—a custom command that combines multiple steps.
Macro features are offered by Word; by code editors like Notepad++ and BBEdit; by standalone macro recorders for controlling other programs; and by the Automator and AppleScript features of Mac OS. You should carefully read instructions for this feature in any program you choose.
In Word for the Mac, access macro functions from the Tools menu. In Word for Windows, you need to add the Developer tab to the Ribbon. For Word 2010, for example, go to File > Options > Customize Ribbon; then under “Customize the Ribbon,” check the box for “Developer.”
The kind of macro I’m suggesting may take a while to set up, but it takes next to no time to apply to later books. For example, I currently have a “Fix Kindle” Text Factory in BBEdit that runs over fifty find-and-replace operations, processing the HTML of a medium-size novel in about a second. That leaves me only a few more seconds of code processing that I have to finish up with an AppleScript—and the script takes that long only because I don’t yet know how to make it loop on its own.
In other words, starting with the HTML exported from Word, I can wind up with fairly clean and Kindle-optimized code in about ten seconds! With that kind of speed, there’s nothing to discourage me from making any text corrections back in the original Word document and just running off a new HTML file. (Sorry, I can’t share my macro with you, because it’s customized for my own work!)
In some programs—like BBedit—you assemble macros in a special editor. In others—like Notepad++ and Word—you simply “record” the steps as you perform them and then replay them later. (BBEdit allows that too, but I have not found that feature to work usefully.)
Now, obviously, it might be a challenge to flawlessly record a macro with over fifty steps. Luckily, you don’t need to. Once you record a macro with a single find-and-replace operation, you can usually then edit the macro to add others.
For example, the following line of code from a Word macro is for a find-and-replace operation that replaces “Shepherd” with “Shepard” throughout a document.
WordBasic.EditReplace Find:="Shepherd", Replace:="Shepard", Direction:=0, MatchCase:=0, WholeWord:=0, PatternMatch:=0, SoundsLike:=0, ReplaceAll:=1, Format:=0, Wrap:=1
Once you see that line, you can simply copy and paste it as many times as you want, just plugging in new Find and Replace terms each time, as long as your other settings don’t need to change. In fact, the code you copy and paste doesn’t even have to come from the same macro. You can create a number of them independently and then merge them.
When devising your macro, there are several potential gotchas.
• For safety, avoid writing your replacements in a way that causes errors if you run the macro on a file more than once. For instance, if you replace “1” with “11,” running the macro twice will give you “1111”! To prevent this, you might set up the find to “Match whole words only” or to include unique text that you know comes before or after. Or you could add a follow-up operation to replace “1111” with “11.”
• Make sure the text you’re trying to find hasn’t already been changed by an earlier operation. For example, if you’ve already changed all exclamation points to question marks, you’ll get zero results on a search for “Error!”
• Don’t replace terms that are also found in text. For example, don’t replace the font name “Georgia” with “Arial” if you’re writing about the Peach State. Here, too, try to include unique text before or after, even if it’s just a punctuation mark. (I admit, I committed this kind of error in an earlier edition of this book, with my code samples!)
• As I said before, you have to protect straight quotes in code, which means you can’t replace them with Word unless Smart Quotes are turned off. The best way to do that is in the macro itself. Start by turning Smart Quotes off, and end by restoring them.
Besides the actual errors I’ve pointed out in Word’s HTML export, it does have annoying quirks that can cause glitches in find-and-replace operations. The worst is Word’s habit of sometimes breaking a line right in the middle of an HTML tag, replacing a space with a paragraph mark. Though this works fine as HTML, it can cause you to miss a tag in a search.
Luckily, Word is likely to do this with only a few kinds of tags, so you can fix them before such operations. The tags are <a>, <span>, and <img>. For example, you would find “<a” followed by a paragraph mark and replace it with “<a” followed by a space. Check how the program you’re using wants you to represent a paragraph mark. (For Word, it’s “^p”, selectable from the “Special” menu. For BBEdit, it’s “\r”.)
Another quirk is in Word’s CSS code—the formatting instructions that piggyback on HTML. Strictly speaking, each CSS declaration is supposed to end in a semicolon, but Word leaves out the final one when the declaration is contained in an HTML tag. So, depending on where it appears, a declaration like “font-family:Georgia” might or might not include that ending semicolon.
There’s probably no simple way to correct this one, so you’ll just need to be aware of it and deal with both possibilities.
Posted by Aaron Shepard at 9:41 PM
Tuesday, February 12, 2013
In this step, you’ll tell Word to save your finished text as HTML, the basic language of Web pages and ebooks, including Kindle books.
You will hear over and over how bloated and corrupt Word’s exported HTML is, and how long it takes to alter and clean up before submission. One wonders whether the people who claim this are ignorant of HTML, or Word, or Kindle conversion, or all three. Yes, there’s some excess in Word’s HTML—especially if you don’t choose the correct export option—but it’s not really significant and gives the Kindle converter no problem at all. In fact, the converter has apparently been optimized for Word’s HTML!
And, yes, you can spend a fair amount of time adjusting the code, if you don’t automate the process as I’ll recommend. But that’s to overcome problems with the Kindle, not problems with the HTML. Word’s code itself—again, when exported with the right option—is nearly error-free and quickly corrected if you care to. If you don’t, the few existing errors are ignored by the Kindle converter—which then introduces masses of HTML errors of its own!
In Word’s exported file, most of the formatting info is actually in a language called CSS, which stands for “Cascading Style Sheets.” As this is a companion language to HTML and intermingles with it in the file, it’s common to refer to them together as HTML. So, I’ll only refer to CSS separately when that’s all I’m talking about.
Before exporting to HTML, make sure your document is saved. If you do not save your changes, they’ll be in the exported HTML but not in your original document. And Mac users beware: If your only change has been to a style definition, you must change something else besides, or else the Save command won’t work!
The procedure for exporting to HTML will vary according to your version of Word, but you’ll be saving as “HTML” or “Web Page” or the like. In the dialog box you get, you then want to specify the variety that includes the least code. This may be designated as “Web Page, Filtered” or by an option like “Save only display info into HTML.” In either case, you’ll be choosing to omit code that isn’t proper HTML and that could be used only by Word in reimporting the document.
If in doubt about which option to choose, save in alternate ways, then choose the one that creates the smallest file. Also, when saving the best way, you should not see any auxiliary files with the .xml extension. As still another way to tell, open the file in a text editor. At the very beginning, you should see a plain <html> tag followed by a <head> tag. If you see additional code within and following the <html> tag, you’ve chosen the wrong option.
When saving as HTML, Word may give you a warning about the document losing some formatting if you proceed. Just go ahead with it.
After saving, Word will normally show you the new HTML document, now open and converted to Word format for screen display. I suggest you immediately close this to avoid confusing it with your original document. No changes you make to this version will be saved to the original!
Word offers a number of “Web Options” related to HTML export, but you can almost always leave them as is. Most of the defaults are fine—and when they aren’t, changing them seems to have no effect anyway!
If you’d like to know, though, the default text encoding for HTML from Word for Windows is “Western European (Windows),” also known as Windows-1252—an encoding very close to “Latin-1,” officially known as ISO 8859-1. For the Mac, the default is “Unicode (UTF‑8)”—which also happens to be the basic encoding of the Kindle. Either of these encodings are handled just fine by the Kindle converter. (By the way, checking the option “Always save Web pages in the default encoding” will mean that Word ignores any encoding choice you’ve made.)
Posted by Aaron Shepard at 3:00 PM
Your goal in this step is to format your text and pictures in ways that will control and take advantage of the Kindle’s features while minimizing its drawbacks and avoiding its pitfalls. You’ll also install navigation features that will carry over to the Kindle. Most of the chapters to come are dedicated to explaining these tasks.
On Windows, any version of Word should work for you, starting with at least Word 2003. On the Mac, some versions have lacked maturity as Microsoft has had to adjust radically to changes in Apple’s operating system. Your best bets are Word 2004—my primary version for this book—and Word 2011.
Whether other word processors might work as well as Word, I can’t say. But I will say I tried half a dozen other Mac word processors to find one that exported HTML better suited to Kindle conversion, and I finally gave up. I’ll also say that you won’t be able to follow my instructions with other word processors, because their commands and their exported HTML will differ. And even starting a document in another word processor and then importing into Word is known as a primary source of problems.
Word, though, is an extremely complex and sophisticated program that has gone through major changes in interface over the years. You are bound to run into situations that I have not or cannot cover in this book. So, do yourself a favor and buy yourself a good manual for your particular version of the program. It can save you a whole lot of grief and frustration.
Since 2007, Microsoft has been pushing the Ribbon as a tool for easier formatting. It may or may not be such, but to harness the full power and flexibility of Word, you need to work with dialog boxes. On Windows, you can usually access these through the small icons at the lower right corners of the Ribbon’s command groups; on the Mac, you still reach them through the menus. Most of the time in this book, I’ll be referring to commands in these dialogs. (They are generally pretty much alike on Windows and Mac.)
Because of the variations, quirks, and deficiencies among the different versions and models of Kindle, it is not the optimum platform for presenting pictures—and Word is not the best tool for handling them. Still, if your expectations aren’t too high, they can do an acceptable job.
To work with pictures, you’ll probably need a photo editor like Photoshop, Photoshop Elements, Corel PaintShop Pro, or Gimp. Personally, I use Photoshop, but for beginners, I recommend Photoshop Elements. It has everything you’re likely to need for Kindle graphics, maintains the legendary quality of Photoshop, is far less intimidating, and is very reasonably priced. You can also find lots of help for it.
I’ll devote a separate chapter to working with pictures. But picture editing is a huge topic in itself, and the discussion here is mostly on how to bring your picture into your book for maximum effect and least damage—that’s after you’ve made it look good on its own. If you’re new to this, I suggest you get Photoshop Elements and a good book that tells you how to use it.
Accidental errors can occur anytime, and you may not notice them till it’s too late to correct them. Save a backup of your text before you start work on it, and save additional backups regularly as you go on. Also save different versions of your pictures as you go through the steps of processing, so you can redo steps without starting from the very beginning.
Posted by Aaron Shepard at 2:52 PM
There is more than one way to produce a Kindle book with Word. Here, though, is the procedure I believe will give the best results, and the one we’ll follow in this book.
The rest of this chapter will go over each of the basic steps. While it may seem odd to detail some of them so soon, this will give you an idea where you’re headed, and it will also give you the chance to test various parts of your book’s formatting before completing the whole thing.
1. Create a properly formatted Word document, including any needed pictures.
2. Export from Word to HTML, the language of the Web.
3. Optimize the HTML code for Kindle.
4. Convert to, preview, and inspect the Kindle book.
5. Submit the book, cover image, and marketing data to Amazon KDP—Kindle Direct Publishing—at
Posted by Aaron Shepard at 2:46 PM
Monday, January 28, 2013
About This Book
Part 1—Basic Steps
Converting and Previewing
Part 2—Creating Your Document
Settings and Views
Styles and Formatting
Front and Back Matter
Part 3—Character FormattingTypeface
Symbols and Special Characters
Part 4—Paragraph Formatting
Justification and Hyphenation
Indents, Margins, Space Between
Part 5—Page Layout
Picture File Formats
Picture Export and Preview
Web and Email Links
Table of Contents and Index
Kindle Menu Items
Part 8—Marketing Materials
Part 9—Marketing Decisions
Digital Rights Management
Pricing and Royalties
Kindle Book Lending
Anchor Fix Macro
Sales Rank Express
Posted by Aaron Shepard at 2:58 PM