LATEST RESULTS OF A GIVEAWAY

Last week I put KINDLE CREATION FOR CONTROL FREAKS on the free pile for three days at Amazon. The results were a little different than I'm used to.

Generally, books in multiple-day giveaways see the most action on the first day. By far. Like 80 or 90%.

Maybe it's the time of year—the shopping season—but this time the downloads were a lot more evenly distributed.

First day: 43.75%

Second day: 31.25%

Third day: 25%

First two day combined: 75%

The three-day giveaway did not quite equal the first (one-day) session, back on November 15th. Again, probably the result of the hectic holiday season. (Be interesting to see if matters reset to "normal" after the first of the year.)

Even so, my advice concerning free promotions remains the same:
For maximum downloads, schedule no more than two days at a time.

And one day at a time would be best. It's just a lot of extra work, and you'll have to stagger your use of promotion sites, which like to see at least 30 days between promotions of the same title.

On the other hand, if you messed around and forgot to put up any promotions and the end of your 90 day Select period is approaching, there's no particular penalty for throwing all five days at the public at once. It's not optimum, but you'll still get some downloads on the last three days. And at least you didn't leave those days on the table.

FREE BOOK ALERT

KINDLE CREATION FOR CONTROL FREAKS will be free on Amazon for three days this week: Tuesday, Wednesday, and Thursday (December 10-12).

Starts at midnight tonight.

Snap one up!

MORE GIVEAWAY NUMBERS

During the latest one-day giveaway for KINDLE CREATION (unpromoted, like the last one), there were far fewer downloads: just 34.2% of the previous session.

I suspect that's a result of timing. Last time, it was the 15th of November. This time: the day after Black Friday.

Now, it may be folks WERE online at the Kindle store looking for gifts—but felt a bit squeamish sending someone a free book for the holidays.

Or maybe fiction is the better choice for gifts.

On the other hand, if you knew some budding writer who was curious about Kindle making, you might think of sending a copy of a Kindle manual his/her way. But still: a free book for a gift...

Just seems tacky, somehow.

By the way, the free session was supposed to end at midnight, Pacific Standard Time. But I noticed the book was still free an hour or so after midnight, prompting nearly 14% additional downloads from the American site. (I never check foreign sites for price, but there were no after-hours downloads from any of them.)

Is Amazon losing its grip?

KINDLE CREATION BOOK FREE

Just a brief reminder: KINDLE CREATION FOR CONTROL FREAKS will be be free on Saturday the 30th of November. That's tomorrow. Starts at midnight Pacific Standard Time.

Grab it up!

PROMOTION RESULTS

As I mentioned earlier, I had several book listed for free last week—the promotion running the full five days in a row.

My earlier experience with giveaways warned me I was going about this one in the most inefficient manner, but I had no choice. (I'd let the matter go too long before acting.)

This time, HOT STATUS was downloaded most on the first day: 67.6%. The combined first and second day was 82.8%. First three days: 91%. Limiting the free period to one or two days is indicated, once again—assuming the goal is to maximize the number of downloads. (And what else could it be, really?)

For THE EXPLODING WIZARD the total numbers were not quite one fourth the total of HOT STATUS. I think this indicates the relative percentage of interest between an adult thriller and a middle-grade chapter book.

Maybe. Another source of difference went uncollected. I sent both books to six promotion sites this time, but failed to check the sites to see which book made it to the Web. In the past, the adult book was posted more often than the kid's book.

For WIZARD, the percentages were: 41.7% for the first day, 61.1% for days one and two, and 72.2% for the first three days. Even if the book saw less promotion than the thriller, it appears folks are reluctant to select a free kid's book—not only in total numbers, but over time. For some reason it takes readers longer to give in and download the thing. Apparently.

The third book (KINDLE CREATION FOR CONTROL FREAKS) proved an interesting case. It was only free for one day, and I set up NO promotions for this one—a test of its stealth appeal.

In its one day it was downloaded 96% as much as HOT STATUS on its best day (Day One), despite the lack of promotion.

And I doubt restraint in promotion was the cause of this relative success.

It could be the nature of the book (non-fiction) put it more in demand than just another novel. I think, in general, non-fiction outsells fiction (at least, outside of the world of ebooks).

Might also be the price differential.

HOT STATUS has always only been sold at 99 cents (or for free). KINDLE CREATION was sitting at $2.99 before (and after) the freebie period. Perhaps folks perceived it as the superior bargain and went for it.

Even though it was not promoted.

(To be fair, I never checked to see if HOT STATUS was promoted at all—but it probably was.)

Maybe there was pent-up demand for KINDLE CREATION, folks visiting the details page repeatedly but unable to pull the trigger on the book because of its price. (Though I have had sales at the list price.) During its unannounced free period (well, it was announced HERE ) enough shoppers happened by (in hopes the price had fallen?) to grab the book for free. Their lucky day...

This brings up the haunting question: Is it possible to thwart sales for a book by pricing it too low?

Smashwords has released data showing their products make the most money in the three to four dollar range, with additional (lower) peaks in several (mostly ) higher zones. The lowest earning rate is in the one to two dollar range: less than 21% as lucrative as the highest rate. Since the royalty rate is fixed throughout (unlike Kindle), these numbers are not skewed by the royalty break point or delivery fees. In fact, books appear to sell twice as many copies at $3.50 as they do at $1.50.

Unfortunately, these data are for the complete range of books, not the same book sold at various prices. Perhaps the more desirable books are simply priced higher than lesser works. Or maybe better selling authors realize they can climb out of the pricing basement and still sell books; and in this case, even more books.

Author Dave Hendricks utilizes this pricing plan: All new books go up at 99 cents until they garner ten reviews. He then raises the price to the lowest available for a 70% royalty ($2.99). After that he bumps the price a dollar every two to four weeks, stopping only when the book's profits level off.

No freebies for him, apparently.

It will be interesting to see how the new Countdown promotion affects the number of freebies in the Kindle market.

AND ANOTHER PROMO

I forgot to add to the previous post there's another book on the freebie list.

KINDLE CREATION FOR CONTROL FREAKS will be free tomorrow (Friday, the 15th).

More stuff later.

NEW BOOK AND PROMOS

The script-to-novella project I mentioned a while back is complete and just went live on Amazon. Turns out it ran a bit under 24k words. (The script version was 20k.) I made no attempt to pump things up (or pad the text) in a quest for full-length status.

Click the cover image to the left (SALESMAN OF THE YEAR) to check out the details and maybe capture the free sample.

Also ongoing: HOT STATUS and THE EXPLODING WIZARD'S RIGHT-HAND BOY are both free through Sunday. I'm running all five days in a row (not the most efficient way to give away books) because I lost track of time and then ran out of it.

In the next Select period I plan to test-drive the new Countdown promotion. Maybe use HOT STATUS for free to juice-up MAD MINUTE (the sequel) in the countdown position. We'll see.

One detail I need to nail down. I understand you can run a Countdown for up to seven days, or for as short a period as one hour. If you only run for one day (or less), can you schedule the remaining time for other promos? Or do you get just one Countdown promo per 90-day period—no matter how short it runs?

Would be nice to be able to use all your allotted time. But consider their end: 168 one-hour promos per book per Select period. That's a lot of computing time for them. Would they really agree?

Till later...

EMBEDDED FONTS

It is technically possible to add custom fonts to your Kindle ebook, though Amazon will not be pleased. Not to mention: Embedding a font not only adds to your delivery fee, those spiffy new characters will only be available for kf8 applications (Kindle Fire and Paperwhite).

Furthermore, there may be legal implications. Using the image of a letter is probably safe, but inserting the actual code for a font into your mobi file is tantamount to the redistribution of that font – which may be expressly forbidden by the font’s creator. You may owe a licensing fee, at the very least. Or you might end up in court.

Finally, embedding a font could disrupt the reader’s ability to toggle the “Published fonts” switch on his or her device. In reality, this might be more of a problem if you attempt to switch out the font for the entire text of your book.

If you’re still determined to add a font to your book, I suggest you search for “open source” fonts on sites like Da Font and Font Squirrel. The listings on Font Squirrel contain icons representing the categories of permitted use available. That’s certainly helpful, but you still need to read the license agreement carefully. And don’t forget to acknowledge the font’s author on your copyright page.

That said, here’s how you embed a font. At the top of the <style> section add these lines:

@font-face
{font-family:"Name of Font", sans-serif;
src:url(Font-file-name.ttf);}
 
The name of the font is in quotes because it’s more than one word. The source of the file mentions no path because you’ve placed the font file in the same folder as the book’s HTML file. The second listing (following the comma) is a fall-back font – in case the new font is somehow unavailable. You can add a second fall-back font if you want. Some coders suggest you place this listing beneath a media call for kf8 (@media amzn-kf8). I haven’t found this to be necessary, but if you run into trouble, try it.

Now you need to add code for the actual application of the font. If, for instance, you want all your h2 headers to use the new font, add this code to the <style> section:

h2
{font-family:"Name of Font";}

If you’re using the new font for the big capital at the beginning of a chapter, add the font-family code to the span listing for initial capitals:

span.initial-cap
{font-family:"Name of Font";
font-weight:bold;
font-size:2em;}

And apply it in the usual way:

<p class="start"><span class="initial-cap">T</span><b>his is the first sentence</b> of the rest of [etc]</p>
 
You could add the font-family listing to your “dropcaps” or “bigcaps” span code. Kindle Fire and Paperwhite will sparkle; Mobi apps will revert to the machine’s default font.

SCRIPT TO BOOK CONVERSION

The project currently in the works is the conversion of a spec screenplay into a novella, to be published on KDP.

The screenplay ran 117 pages, which is a good length for a drama. It's about New Year's Eve 1999, and takes place in a police station. The two principals are detectives locked in a competition for Salesman of the Year, to be awarded to the one who can get the most confessions.

The conversion process began mechanically, by dumping the Final Draft version of the script (first saved as rtf) into Word. Macros from the original program were still active, apparently, so I had to save the document as text and reopen it. I then resaved it as rtf.

In the first pass through the manuscript I worked at changing the descriptions from present tense to past tense. I also stripped out character names, which in the script appeared in caps centered above lines of dialogue.

I wrangled the text into pre-Kindle mode: single-spaced block paragraphs with extra paragraph marks between them. I turned my dashes into two hyphens, with no spacing around them. Ellipses were changed to three periods, again with no spacing around (or between) them.

With all that done, I checked the length—about 20,000 words.

Long enough for my purposes, but I knew it would grow a bit, if only by fleshing out the descriptions of action. When I write in screenplay mode, I keep descriptions short and telegraphic, often using just one word in place of whole sentences. Fragments. Lots of 'em.

My second pass began the expansion process and corrected residual bits of present tense verbs. I find I have trouble making the transition. I was THINKING in present tense when I wrote it, and recasting a sentence into past tense is oddly difficult. I found chunks of present tense persisting into the third and forth proofing session.

Modern screenplays tend to have a lot of short scenes. And everything in the story stands right there out in the open. All actions are visual, and nearly every thought is expressed in dialogue. Character is revealed through action and dialogue alone, without interior monologue or anything like stream of consciousness. (Though sometimes there is voice-over narration—usually a hang-over from a well-known novel that's adapted to film.)

At least, this is true for most "Hollywood"-type productions.

Independent films tend to have longer, slower scenes, where character is more subtly hinted at. Maybe even some attempt is made to simulate interior landscapes.

Converting an "indy" script might call for a very free adaptation, a kind of re-imagining of the original concept. It would involve a process more like the conversion of a subjective, feelings-based novel to film, where the new writer would be more loyal to the spirit of the thing than to the original words.

SALESMAN OF THE YEAR is pretty Hollywood in concept. It's a mostly "surface" project. Action and dialogue. But there's still room to expand on character thoughts and attitudes, trading interior monologue for overt dialogue and bouts of physical twitching (sighs, shrugs, etc).

One of the biggest challenges is assigning point of view in the scenes. In a movie, POV is largely confined to camera tricks—literally having the camera track toward the object a particular character is approaching.

In suspense films, an action taking place inside a house might suddenly be seen from OUTSIDE the house, the camera in restless movement, ducking behind bushes, and whatnot. That's supposed to tell you someone is out there, watching. A lurker. Probably a bad guy.

Generally, though, an action taking place in a room is "covered" by various shots: singles and two shots and over the shoulder shots. Close ups might clue you to a particular character's mood, based on facial expression or body language. A grimace or a smile.

In a film, dramatic confrontation might well play out by jumping from one close up to another, featuring various major characters. With a large cast in play, a great many folks might get a moment of screen time in that one big scene. Plus, you have to be careful to document the everyone present, lest a sudden shot of some guy surprise the audience (where'd HE come from?).

But in narrative fiction, scenes are almost always "owned" by one particular character. That one person sees and hears everything that gets described, with perhaps a running mental commentary that tells the reader how the character feels about what he's experiencing.

If another character is in the same scene—and you want to get inside their head, too—you're supposed to skip a line and start a new scene.

In a movie, there is a lot more doubt over who exactly might be a viewpoint character. Multiple close-ups may imply multiple VPs. The exception is usually an experiment in POV (e.g., LADY IN THE LAKE, starring and directed by Robert Montgomery, which uses a "subjective" camera that "plays" the lead character).

Furthermore, a great many scenes might unspool with NONE of the main characters in evidence.

In a novel, this is handled by an adjustment of narrative distance. Main characters think a lot about the scenes they're in, while the interior furniture of minor characters is only hinted at.

When the novel calls for a lot of extraneous scenes, one thing you generally can't do is write the book in the first person.

In a strict first-person novel, the reader shouldn't be shown anything the main character doesn't personally witness. This can be frustratingly limited.

But there are exceptions and work-arounds. First person characters can NARRATE events that take place outside his or her presence, as long as it's plausible for the character to learn about those events from other sources or (less convincing) circumstantial evidence. It's distracting to wonder how the first person narrator could have found out what he's talking about.

Movies are relentlessly third person affairs. Narrative fiction designed to cover the same material will concentrate on certain main characters, using third-person interior monologue. Other necessary scenes, without main characters, will be kept short and operate as close to the surface as possible.

Fortunately, modern "Hollywood" movies tend to be about one character in trouble. Everything else is secondary. That simplifies the process of adaptation somewhat.

In this project, the very large number of short scenes (around 50), presents another challenge. Not POV, but formatting.

I decided to treat those scenes (which often jump around from place to place during a sustained action) in the simplest manner: automatically.

I had already added a # sign to separate scenes when I massaged the script into Word shape. Now (with the Mobipocket-created HTML safely in Notepad++) I just changed the style of each of the initial paragraphs to "start." That gave me a space between scenes (via the margin-top setting) and no indent (text-indent:0em). At the moment, I'm planning no further treatment.

It's different for the first paragraph of a chapter. (And that was another sub-project in the conversion, breaking the screenplay into chapters.) There I've gone with small caps for the first three or four words (type out in caps, surround the text with <small> and </small> tags).

The initial letter is set in what I call "bigcaps." These are 200% sized caps originally designed for drop caps, but raised by top and bottom margin specs to ride on (or just below) the first line. In other words, no "drop".

Here's the code I use in the <style> section of the HTML:

span.bigcaps
{font-weight:bold;
font-size:200%;
float:left;
padding-right:0.02em;
margin-top:-0.47em;
margin-bottom:-0.65em;}

These specs work perfectly in Firefox, but I'll probably have to make adjustments for Kindle Previewer.

Note that this code only works in kf8 apps: Kindle Fire, HD, and Paperwhite. I don't add additional code for Kindle Classic and DX, but the initial letter in those apps comes out as a 2 em capital, apparently the biggest you can get in a default font.

Using bigcaps gets me a dramatically large letter up front without having to worry about the spacing issue in Kindle Fire, where first letters larger than about 1.5 em cause the gap between lines one and two to be larger than the gaps between other lines in the paragraph.

Anyway, all this is mechanical. I still have a way to go in the adaptation, mostly slowing down some of the scenes and creating more material for internal character development.

As it stands, the thing has grown to 22,500 words, despite the fact I cut out a few short scenes.

A work in progress, then. I'll let you know when it goes on the air.

For the moment I turn my attention to matters external to my real life. Come Monday, I may be on my way to jury duty.

I can hardly wait....

HTML IN KDP BOOK DESCRIPTIONS

When you publish your book on KDP it's now permissible to use a little HTML to jazz up your Product Description.

I believe this works best for non-fiction books, where special items like bulleted lists make more sense. Still, in the case of a novel I don’t think it would be out of line to use italics or bold text to emphasize a plot point or two.

FYI, the approved tags are: b, br, em, font, h1 through h6, hr, i, li, ol, p, pre, s, strike, strong, sub, sup, u, and ul. You’re probably familiar with many of these guys, but here’s some info on some of them: ol and ul are ordered and unordered lists, respectively, where li identifies each list item. (Ordered lists get numbers, unordered lists get black bullets.)

Both s and strike run horizontal lines through text, while u underlines it. You get italics with either i or em. Similarly, b and strong both come out bold. If you find yourself using subscript (sub) or superscript (sup), you might be writing a book about water (H₂O) or the spicy world of Triple X (X³).

(This list of tags was adapted from KDP’s reply to an email query sent by author/publisher Tom Corson-Knowles and reproduced on his Webpage, TCK Publishing.)

Some words of advice about using HTML tags in the Product Description window: What you’re submitting is not a page of text, nor a page of HTML code—it’s a bastard hybrid that takes special handling. Send those guys no unintended line breaks. Make your book description one solid hunk of text, with the occasional set of HTML tags inserted where called for.

If, for instance, you have an unordered list, understand that the end tag for each item (</li>) contains within it a line break. If your description were to show each entry on a separate line, KDP will insert an additional line break at the end of every list item. On the sell page, that comes out as double-spaced text, which is probably not what you were going for.

Similarly, don’t add a line break (<br />) after header code end tags (e.g., </h2>). There’s a built-in break that varies in height depending on the size of header used. And by the way, because of pre-existing style code on their Web site, h2 headers come out in a custom-designed color called Amazon orange.

Always review your book description after your book goes live. Be prepared to come back to the page and make changes. I know it’s a hassle, but you’re in public now. Act accordingly.

If you have a lot of header code in your description, and a big fat typo in the first line, you have a decision to make.

Changing book items from the KDP window can take over twelve hours. And I believe the book will just sit there on the sell page, mistakes and all, the whole time.

Turns out you CAN fix the problem fast—in about ten minutes, in fact—but you have to go about it a different way.

If you have a bio up on Amazon's Author Central (and why don't you?), you can go there to fix your defective product description. Log onto your account, click Books at the top of the page, then select the book in question from the list.

The item will come up with the Editorial Reviews tab live, and that's where you want to be. (Note: You won't find this tab at Author Central UK; you have to use the American version.) If you have reviews on this page, scroll down to the last item: the Product Description. Click Edit.

You can now view your description in one of two windows, Compose or Edit HTML. You may notice your carefully sculpted headers are no longer so special. The thing is, the selection of HTML available on Author Central is rather limited. You can't use header code here, just italics, bold, line breaks, and lists (ordered or unordered).

But you CAN correct your typo, that's the good news.

The bad news? If you enter any changes on this page you will lose your ability to make changes on the KDP page forever. That means, in lieu of headers you'll have to type the text out in bold caps.

Since most descriptions of novels can do without header text, this is probably a good compromise.

By the way: After you preview your changes and click Save at the bottom of the page, you'll get a message saying the new stuff will be on the Web page in three to five business days. Not true, fortunately. Ten minutes or so will usually do the job.

Back in Editorial Reviews after the save, you'll notice the Compose window is now blank. But exit this book and return later, both windows will be populated again.

Tantalizingly, if you put header tags in the Edit HTML window, they show up in the Compose window. It's an illusion. Click Preview to see what's really headed to your sell page. The Preview window is accurate.

Keep in mind, the rules for HTML use are the same at Author Central as they are on the KDP page. The Edit HTML window shows you the text in one big block paragraph. If you break it up for easier viewing, the system will insert page break codes everywhere, converting your book description into erratic, double-spaced text. Next thing you know, you're back at Author Central going over the whole thing again. It can start to get tedious...

ANOTHER NEW BOOK

I've got a new book up on Kindle, but it's not a novel. It's my first non-fiction book:

KINDLE CREATION FOR CONTROL FREAKS.

If you've read the archives of this blog, you'll have a pretty good idea of what it's about.

There's just a lot more of it in the book.

Check it out, if you're so inclined. Get a free sample today.

EPUB STUFF - PART TWO

Continuing the saga of ePub creation. Here's the ePub version of toc.ncx:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ncx PUBLIC "-//NISO//DTD ncx 2005-1//EN"
"http://www.daisy.org/z3986/2005/ncx-2005-1.dtd">
   
<ncx version="2005-1" xml:lang="en" xmlns="http://www.daisy.org/z3986/2005/ncx/">
   
<head>
<meta name="dtb:uid" content="268a4670-ca8a-11e2-8b8b-0800200c9a66" />
<meta name="dtb:depth" content="1" />
<meta name="dtb:totalPageCount" content="0" />
<meta name="dtb:maxPageNumber" content="0" />
</head>

<docTitle>
<text>Your Title</text>
</docTitle>

<docAuthor>
<text>Lastname, Firstname</text>
</docAuthor>

<navMap>

<navPoint id="cp" playOrder="1">
<navLabel><text>Cover</text></navLabel>
<content src="cover_page.xhtml" />
</navPoint>

<navPoint id="tp" playOrder="2">
<navLabel><text>Title Page</text></navLabel>
<content src="title_page.xhtml" />
</navPoint>

<navPoint id="copy" playOrder="3">
<navLabel><text>Copyright Page</text></navLabel>
<content src="copyright.xhtml" />
</navPoint>

<navPoint id="c1" playOrder="4">
<navLabel><text>Chapter 1</text></navLabel>
<content src="chap_1.xhtml" />
</navPoint>

<navPoint id="c2" playOrder="5">
<navLabel><text>Chapter 2</text></navLabel>
<content src="chap_2.xhtml" />
</navPoint>

<navPoint id="c3" playOrder="6">
<navLabel><text>Chapter 3</text></navLabel>
<content src="chap_3.xhtml" />
</navPoint>

<navPoint id="c4" playOrder="7">
<navLabel><text>Chapter 4</text></navLabel>
<content src="chap_4.xhtml" />
</navPoint>

<navPoint id="about" playOrder="8">
<navLabel><text>About the Author</text></navLabel>
<content src="about.xhtml" />
</navPoint>

</navMap>

</ncx>

Copy and paste it into Notepad++. Save a copy in your ePub Making Kit folder before modifying it for the current book.

It would probably be a good idea to get a different identifier number for the ePub edition of your book. You can go back to www.famkruithof.net/uuid/uuidgen and get more than a hundred at a time. Keep a text file with UUID numbers in your book making kit folders; update the list by ticking off the numbers used (saying for what book, what edition, and so forth).

But here’s a tumbling block: Depending on your use of the ePub file, you might now have to get an ISBN from somebody. I believe some distributors (like Smashwords) supply a number for free. You need to look into it.

The first “playOrder” item is the book’s cover. That’s a change. The href is to cover_page.xhtml, the file that contains the tag for the cover image.

After that comes the title page, the copyright page, the chapters (listed one by one, just as in the Kindle ncx file), and ends with the About the Author page. What’s missing is the HTML Table of Contents. That file isn’t strictly necessary for ePub.

Add listings for all your chapters. Save the modified copy of the ncx file in the same folder you've been using to collect your other book parts. If you added navPoints for new chapters, you will probably want to save these changes before closing the template.

Next, the content.opf template:

<?xml version="1.0"?>
<package version="2.0" xmlns="http://www.idpf.org/2007/opf" unique-identifier="BookId">

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
<dc:title>Your Title</dc:title>
<dc:language>en</dc:language>
<dc:identifier id="BookId" opf:scheme="UUID">268a4670-ca8a-11e2-8b8b-0800200c9a66</dc:identifier>>
<dc:creator opf:file-as="Lastname, Firstname" opf:role="aut">Your Name</dc:creator>
<dc:publisher>Fake-out Publications</dc:publisher>
<dc:date>YYYY-MM-DD</dc:date>
<dc:subject>Type of book</dc:subject>
<dc:description>Say a few words about your book.</dc:description>
<meta name="cover" content="cover" />
</metadata>

<manifest>
<item id="cover_page" href="cover_page.xhtml" media-type="application/xhtml+xml" />
<item id="title_page" href="title_page.xhtml" media-type="application/xhtml+xml" />
<item id="copyright" href="copyright.xhtml" media-type="application/xhtml+xml" />
<item id="chap1" href="chap_1.xhtml" media-type="application/xhtml+xml" />
<item id="chap2" href="chap_2.xhtml" media-type="application/xhtml+xml" />
<item id="chap3" href="chap_3.xhtml" media-type="application/xhtml+xml" />
<item id="chap4" href="chap_4.xhtml" media-type="application/xhtml+xml" />
<item id="about" href="about.xhtml" media-type="application/xhtml+xml" />
<item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml" />
<item id="stylesheet" href="style.css" media-type="text/css" />
<item id="cover" href="cover.jpg" media-type="image/jpeg" />
<item id="title" href="title_page.jpg" media-type="image/jpeg" />
<item id="chap1_start" href="cs-1.jpg" media-type="image/jpeg" />
<item id="chap2_start" href="cs-2.jpg" media-type="image/jpeg" />
<item id="chap3_start" href="cs-3.jpg" media-type="image/jpeg" />
<item id="chap4_start" href="cs-4.jpg" media-type="image/jpeg" />
</manifest>

<spine toc="ncx">
<itemref idref="cover_page" />
<itemref idref="title_page" />
<itemref idref="copyright" />
<itemref idref="chap1" />
<itemref idref="chap2" />
<itemref idref="chap3" />
<itemref idref="chap4" />
<itemref idref="about" />
</spine>

</package>

You’ll find it’s a lot longer, but should be pretty familiar. Save a copy in your ePub Making Kit before making changes.

Modify the Dublin Core for the current book, including the new identifier number. If you’re now using an ISBN in that section, change the “opf:scheme” from UUID to ISBN.

You’ll see the cover listed at the end of the <meta> section, just like before:

<meta name="cover" content="cover" />

It’s also listed in the second half of the <manifest> section, but this time it’s heading up a list of other images: title page and chapter-starts. Delete mention of any images you’re not actually using.

In Kindle you could use jpg, pgn, gif, or bmp images inside the book; in ePub it’s jpg, png, gif, or svg (scalable vector graphics).

There are listings here for just four chapters (with chapter-start image support built in). The version in the Templates section goes to twenty. Add or subtract as needed.

But remember, everything in your book (except the mimetype file and the META-INF folder) needs to be listed in the <manifest>. Otherwise, it won’t pass the validator.

You don’t really need an XHTML TOC in your book, since most e-readers create one from your ncx file. But if you want to add one anyway, just in case, here’s how: Grab the core info from your HTML TOC—from the beginning of the Title header code to the end of the </div> tag—and drop it into one of your book chunk templates. Probably wouldn’t hurt to save this file as a template in your ePub Making Kit.

You’ll have to add this new item to the ncx file and the opf file, naturally. For the ePub’s opf file, it’s almost the same line as in your Kindle-ready version:

<item id="toc" href="toc.xhtml" media-type="application/xhtml+xml" />

Put it somewhere in the <manifest> section. Then add this to the bottom of the <spine>, after the “about” reference:

<itemref idref="toc" />

Put the appropriate listing in your ncx file, too. Again, I suggest you add it at the end. It’s easier. Plus, if a particular e-reader does create a TOC from the navigation map, it would be good to tuck the XHTML version out of the way. The listing is the same as it was in the Kindle ncx file—just add the x in front of the “html” extension.

Your cover image can remain the Kindle-preferred jpg version, but you could have other types mixed in here (for chapter starts or whatever). Just remember to change the media-type. Except for that rascal jpg, media-types copy the image file extension name, letter for letter.

If you followed my advice and let KindleGen resize your display cover when it built your mobi file, you should load the full-size image back into GIMP and make it smaller. Depending on the final destination for this ePub, there may be different specs to follow. I’ve seen 600 x 730 for nook, but also 750 x 1100.

Using the class="wide" notation inside the <img> tag will set your images at 98%, whatever their pixel size.

In the <spine> section you’ll find listed all the relevant stuff: cover page, title page, copyright, chapters, About the Author (and maybe TOC). This is the order they’ll be assembled and listed. Remove any items you’re not using.

If you want your book to open with the cover, you need do nothing. If you’d rather see your title page jump up first, you need to modify the listing:

<itemref idref="cover" linear="no" />

The start of your book will default to the next item on the list, though “Cover” remains the number one guy on your Table of Contents. You can also add the linear="no" spec on the listings for your title page and copyright page, so your book opens on the first page of Chapter One. Up to you.

As you can see, there is no <guide> to worry about in an ePub book’s opf file.

I’m going to break with tradition and suggest you just dump all your images in the OEBPS folder. Of course, if you don’t have chapter-start images, there’s only going to be one or two images to dump there. Some ePub creator programs like to segregate all your stuff into folders: one for the text files, one for images, one for style sheets. But who’s going to see it if you just let everything flop around in one big folder? Take a break—you don’t have to tidy up for anybody.

Also, this way you won’t have to go back and add an IMAGES folder to the path for your images, or a TEXT folder path for your XHTML files, etc.

Now, at last, you’re ready to assemble the package. Open Windows Explorer and navigate to the assembly folder for your book. It should have just three items in there: the mimetype file, a META-INF folder (with “container” inside), and a fully populated OEBPS folder. Right-click on an empty part of the window to open a menu. Maneuver down the list with the cursor to “New” and another list will open. Somewhere (possibly at the bottom) is the selection called “Compressed (zipped) Folder.” Left click there to create an empty zipped folder. Name it for your new book, but keep the zip extension (for now).

Normally I use xplorer2lite for file fiddling. If you have this program, follow the above instructions, but click "Shell new" at the bottom of the menu. Inside you’ll find the same Compressed Folder selection as in Windows Explorer.

Proceed in the following order (it’s important): First, drag the mimetype to the zipped folder. I like to use the right-click drag, selecting Copy from the menu; this way I keep a copy of the files outside the zipped archive—I’ll almost certainly need to fiddle with the HTML before getting the ePub file to validate. Next, tuck the META-INF folder inside. Finally, the OEBPS folder. Now right click the zipped folder, select Rename, and change the extension from zip to epub.

And there you go: an epub version of your book. Not that bad, right?

The official ePub validation Website is run by idpf.org (International Digital Publishing Forum).The site hosts ePubCheck 3.01. You can also download a copy and run this program from your computer, but you need to have Java installed. And you have to run it from the Command Prompt. That's annoying.

I found a program called ePubChecker that runs an older version of ePubCheck (1.0.5) in a Windows GUI environment. It’s a lot easier to use. Just browse to the file you want checked and set it loose. I’ve heard a rival program (Flightcrew) has error messages that are easier to understand. But if you followed my instructions exactly, you’re probably saying, “What error messages?”

After it passes the validation process, go online and run the file through the big guy, ePubCheck 3.01.

I want to thank Aaron Demott (Yoda47) and Liza Daly for their tutorials on ePub creation.

EPUB TEMPLATES

<!--here are the files and templates you need to convert your Kindle material to an ePub book-->

<!--the container, which goes inside the META-INF folder-->

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="OEBPS/content.opf" media-type="application/oebps-package+xml" />
</rootfiles>
</container>

<!--this is the contents of the mimetype file-->

application/epub+zip

<!--these are the three items inside an ePub file-->

META-INF
OEBPS
mimetype

<!--the css file template; leave out text-align for ragged right margin-->

body
    {margin-left:3%;
    margin-right:3%;
    margin-top:3%;
    margin-bottom:3%;
    text-align:justify;}

[Add your <style> units here, omit beginning and ending tags.]

=========================================================

<!--this is the template for your book chunk XHTML files; clone them and name them: title page, copyright page, chapter one through whatever, about-the-author page, cover page, and maybe XHTML Table of Contents-->

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>EPub Template</title>
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>

[New content goes here...]

</body>
</html>

=======================================================

<!--ncx file template-->

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ncx PUBLIC "-//NISO//DTD ncx 2005-1//EN"
"http://www.daisy.org/z3986/2005/ncx-2005-1.dtd">

<ncx version="2005-1" xml:lang="en" xmlns="http://www.daisy.org/z3986/2005/ncx/">

<head>
<meta name="dtb:uid" content="[large unique number which matches the one in the opf file - see www.framkruithof.net/uuid/uuidgen]" />
<meta name="dtb:depth" content="1" />
<meta name="dtb:totalPageCount" content="0" />
<meta name="dtb:maxPageNumber" content="0" />
</head>

<docTitle>
<text>Your Title</text>
</docTitle>

<docAuthor>
<text>Lastname, Firstname</text>
</docAuthor>

<navMap>

<navPoint id="cp" playOrder="1">
<navLabel><text>Cover</text></navLabel>
<content src="cover_page.xhtml" />
</navPoint>

<navPoint id="tp" playOrder="2">
<navLabel><text>Title Page</text></navLabel>
<content src="title_page.xhtml" />
</navPoint>

<navPoint id="copy" playOrder="3">
<navLabel><text>Copyright Page</text></navLabel>
<content src="copyright.xhtml" />
</navPoint>

<navPoint id="c1" playOrder="4">
<navLabel><text>Chapter 1</text></navLabel>
<content src="chap_1.xhtml" />
</navPoint>

<navPoint id="c2" playOrder="5">
<navLabel><text>Chapter 2</text></navLabel>
<content src="chap_2.xhtml" />
</navPoint>

<navPoint id="c3" playOrder="6">
<navLabel><text>Chapter 3</text></navLabel>
<content src="chap_3.xhtml" />
</navPoint>

<navPoint id="c4" playOrder="7">
<navLabel><text>Chapter 4</text></navLabel>
<content src="chap_4.xhtml" />
</navPoint>

<navPoint id="c5" playOrder="8">
<navLabel><text>Chapter 5</text></navLabel>
<content src="chap_5.xhtml" />
</navPoint>

<navPoint id="c6" playOrder="9">
<navLabel><text>Chapter 6</text></navLabel>
<content src="chap_6.xhtml" />
</navPoint>

<navPoint id="c7" playOrder="10">
<navLabel><text>Chapter 7</text></navLabel>
<content src="chap_7.xhtml" />
</navPoint>

<navPoint id="c8" playOrder="11">
<navLabel><text>Chapter 8</text></navLabel>
<content src="chap_8.xhtml" />
</navPoint>

<navPoint id="c9" playOrder="12">
<navLabel><text>Chapter 9</text></navLabel>
<content src="chap_9.xhtml" />
</navPoint>

<navPoint id="c10" playOrder="13">
<navLabel><text>Chapter 10</text></navLabel>
<content src="chap_10.xhtml" />
</navPoint>

<navPoint id="c11" playOrder="14">
<navLabel><text>Chapter 11</text></navLabel>
<content src="chap_11.xhtml" />
</navPoint>

<navPoint id="c12" playOrder="15">
<navLabel><text>Chapter 12</text></navLabel>
<content src="chap_12.xhtml" />
</navPoint>

<navPoint id="c13" playOrder="16">
<navLabel><text>Chapter 13</text></navLabel>
<content src="chap_13.xhtml" />
</navPoint>

<navPoint id="c14" playOrder="17">
<navLabel><text>Chapter 14</text></navLabel>
<content src="chap_14.xhtml" />
</navPoint>

<navPoint id="c15" playOrder="18">
<navLabel><text>Chapter 15</text></navLabel>
<content src="chap_15.xhtml" />
</navPoint>

<navPoint id="c16" playOrder="19">
<navLabel><text>Chapter 16</text></navLabel>
<content src="chap_16.xhtml" />
</navPoint>

<navPoint id="c17" playOrder="20">
<navLabel><text>Chapter 17</text></navLabel>
<content src="chap_17.xhtml" />
</navPoint>

<navPoint id="c18" playOrder="21">
<navLabel><text>Chapter 18</text></navLabel>
<content src="chap_18.xhtml" />
</navPoint>

<navPoint id="c19" playOrder="22">
<navLabel><text>Chapter 19</text></navLabel>
<content src="chap_19.xhtml" />
</navPoint>

<navPoint id="c20" playOrder="23">
<navLabel><text>Chapter 20</text></navLabel>
<content src="chap_20.xhtml" />
</navPoint>

<navPoint id="about" playOrder="24">
<navLabel><text>About the Author</text></navLabel>
<content src="about.xhtml" />
</navPoint>

</navMap>

</ncx>

==========================================================

<!--the opf file template-->

<?xml version="1.0"?>
<package version="2.0" xmlns="http://www.idpf.org/2007/opf" unique-identifier="BookId">

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
<dc:title>Your Title</dc:title>
<dc:language>en</dc:language>
<dc:identifier id="BookId" opf:scheme="uuid">[large unique number which matches the one in the ncx file - see www.framkruithof.net/uuid/uuidgen]</dc:identifier>
<dc:creator opf:file-as="Lastname, Firstname" opf:role="aut">Firstname Lastname</dc:creator>
<dc:publisher>Fake-out Publications</dc:publisher>
<dc:date>YYYY-MM-DD</dc:date>
<dc:subject>Type of book</dc:subject>
<dc:description>Say a few words about your book.</dc:description>
<meta name="cover" content="cover" />
</metadata>

<manifest>
<item id="cover_page" href="cover_page.xhtml" media-type="application/xhtml+xml" />
<item id="title_page" href="title_page.xhtml" media-type="application/xhtml+xml" />
<item id="copyright" href="copyright.xhtml" media-type="application/xhtml+xml" />
<item id="chap1" href="chap_1.xhtml" media-type="application/xhtml+xml" />
<item id="chap2" href="chap_2.xhtml" media-type="application/xhtml+xml" />
<item id="chap3" href="chap_3.xhtml" media-type="application/xhtml+xml" />
<item id="chap4" href="chap_4.xhtml" media-type="application/xhtml+xml" />
<item id="chap5" href="chap_5.xhtml" media-type="application/xhtml+xml" />
<item id="chap6" href="chap_6.xhtml" media-type="application/xhtml+xml" />
<item id="chap7" href="chap_7.xhtml" media-type="application/xhtml+xml" />
<item id="chap8" href="chap_8.xhtml" media-type="application/xhtml+xml" />
<item id="chap9" href="chap_9.xhtml" media-type="application/xhtml+xml" />
<item id="chap10" href="chap_10.xhtml" media-type="application/xhtml+xml" />
<item id="chap11" href="chap_11.xhtml" media-type="application/xhtml+xml" />
<item id="chap12" href="chap_12.xhtml" media-type="application/xhtml+xml" />
<item id="chap13" href="chap_13.xhtml" media-type="application/xhtml+xml" />
<item id="chap14" href="chap_14.xhtml" media-type="application/xhtml+xml" />
<item id="chap15" href="chap_15.xhtml" media-type="application/xhtml+xml" />
<item id="chap16" href="chap_16.xhtml" media-type="application/xhtml+xml" />
<item id="chap17" href="chap_17.xhtml" media-type="application/xhtml+xml" />
<item id="chap18" href="chap_18.xhtml" media-type="application/xhtml+xml" />
<item id="chap19" href="chap_19.xhtml" media-type="application/xhtml+xml" />
<item id="chap20" href="chap_20.xhtml" media-type="application/xhtml+xml" />
<item id="about" href="about.xhtml" media-type="application/xhtml+xml" />
<item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml"/>
<item id="stylesheet" href="style.css" media-type="text/css" />
<item id="cover" href="cover.jpg" media-type="image/jpeg" />
<item id="title" href="title_page.gif" media-type="image/gif" />
<item id="chap1_start" href="cs-1.gif" media-type="image/gif" />
<item id="chap2_start" href="cs-2.gif" media-type="image/gif" />
<item id="chap3_start" href="cs-3.gif" media-type="image/gif" />
<item id="chap4_start" href="cs-4.gif" media-type="image/gif" />
<item id="chap5_start" href="cs-5.gif" media-type="image/gif" />
<item id="chap6_start" href="cs-6.gif" media-type="image/gif" />
<item id="chap7_start" href="cs-7.gif" media-type="image/gif" />
<item id="chap8_start" href="cs-8.gif" media-type="image/gif" />
<item id="chap9_start" href="cs-9.gif" media-type="image/gif" />
<item id="chap10_start" href="cs-10.gif" media-type="image/gif" />
<item id="chap11_start" href="cs-11.gif" media-type="image/gif" />
<item id="chap12_start" href="cs-12.gif" media-type="image/gif" />
<item id="chap13_start" href="cs-13.gif" media-type="image/gif" />
<item id="chap14_start" href="cs-14.gif" media-type="image/gif" />
<item id="chap15_start" href="cs-15.gif" media-type="image/gif" />
<item id="chap16_start" href="cs-16.gif" media-type="image/gif" />
<item id="chap17_start" href="cs-17.gif" media-type="image/gif" />
<item id="chap18_start" href="cs-18.gif" media-type="image/gif" />
<item id="chap19_start" href="cs-19.gif" media-type="image/gif" />
<item id="chap20_start" href="cs-20.gif" media-type="image/gif" />
</manifest>

<spine toc="ncx">
<itemref idref="cover_page" />
<itemref idref="title_page" />
<itemref idref="copyright" />
<itemref idref="chap1" />
<itemref idref="chap2" />
<itemref idref="chap3" />
<itemref idref="chap4" />
<itemref idref="chap5" />
<itemref idref="chap6" />
<itemref idref="chap7" />
<itemref idref="chap8" />
<itemref idref="chap9" />
<itemref idref="chap10" />
<itemref idref="chap11" />
<itemref idref="chap12" />
<itemref idref="chap13" />
<itemref idref="chap14" />
<itemref idref="chap15" />
<itemref idref="chap16" />
<itemref idref="chap17" />
<itemref idref="chap18" />
<itemref idref="chap19" />
<itemref idref="chap20" />
<itemref idref="about" />
</spine>

</package>

======================

<!--if you add an XHTML TOC, add this to the <manifest> section-->

<item id="toc" href="toc.xhtml" media-type="application/xhtml+xml" />

<!--add this to the bottom of the <spine>-->

<itemref idref="toc" />

<!--to get your ePub to open after the cover page, modify the listing in the <spine> section-->

<itemref idref="cover" linear="no" />

=========================================================

<!--assembling the ePub file with zip.exe, use these lines at the command prompt-->

zip book.epub -DX0 mimetype

zip book.epub -rDX9 META-INF OEBPS

<!--end of ePub templates-->

EPUB STUFF - PART ONE

Here's one way to convert your Kindle book into an ePub. This is mostly just busy work, filling out templates, copying stuff from one place to another, and making the final assembly.

Start off by creating a new folder on your computer. It can run right alongside “Kindle Books” and could be called “ePub Books.” Inside that folder create another called “ePub Making Kit” or the equivalent.

In many ways, the ePub version resembles a Kindle book: HTML files of your text, an opf file to direct traffic, an ncx file to create your Table of Contents, a style sheet to boss folks around, tell ’em how to do their jobs. All of these guys are packed into a folder traditionally called OEBPS (Open EBook Publication Structure).

Sitting next to the OEBPS folder is another one called META-INF. Inside that folder is a single file, called the “container.” The container tells the ebook reader where to find the opf file—even though everybody expects to find the opf file in the same place: the folder called OEBPS.

Here’s the text of the container:

   <?xml version="1.0"?>
   <container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
   <rootfiles>
   <rootfile full-path="OEBPS/content.opf" media-type="application/oebps-package+xml" />
   </rootfiles>
   </container>

Once you’ve assembled your first META-INF folder, you can use it for every ePub book you make.

Sitting beside these two folders (OEBPS and META-INF) is a file called the “mimetype.” This file contains one short line of text:

   application/epub+zip
And it’s the same for every ePub book you’ll ever create.

As you approach the final assembly, you’ll have a folder dedicated to your new book with just those three items:

   META-INF
   OEBPS
   mimetype

You will then zip these items into a single file. I’ll get into the details in a future post.

The main work of putting together an ePub is tearing your HTML file apart, dropping the parts into separate XHTML templates, and lining everything up in the OEBPS folder.

Here's the template for the standard chunk:

   <?xml version="1.0" encoding="utf-8"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
   
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
   <title>EPub Template</title>
   <link rel="stylesheet" type="text/css" href="style.css" />
   </head>
   <body>
   
   [New content goes here...]
   
   </body>
   </html>
First, prepare your ePub Making Kit. Load copies of the mimetype. Create a META-INF folder and put the “container” file inside. Paste a copy of the “book chunk” template into Notepad++ and clone it repeatedly, naming the copies for: title page, copyright page, chapters one through whatever, the “about the author” page, and the cover page. Save the files like this in your ePub Making Kit folder:

    title_page.xhtml
    copyright.xhtml
    chap_1.xhtml
    chap_2.xhtml
    chap_3.xhtml    (etc.)
    about.xhtml
    cover_page.xhtml

Open your ePub Books folder and create the assembly folder named for this book. Working from your ePub Making Kit, put a copy of the mimetype file there, as well as a copy of the META-INF folder (with the “container” file inside). Finally, make a new folder for everything else called OEBPS.

Open the HTML file of your book in Notepad++. If you’re at all worried the file might be damaged, create a backup copy and open that instead.

Make sure it says “ANSI as UTF-8” in the bottom right of the screen. If it says something else, click “Encoding” and select “Convert to UTF-8 without BOM.” Save the file, then check Encoding again: It should be set to Encode in UTF-8 without BOM.

Open a new document in Notepad++. This is going to be your style sheet template. Start by adding this code (it's also found in the ePub Making Template on the right-hand sidebar):

   body
       {margin-left:3%;
       margin-right:3%;
       margin-top:3%;
       margin-bottom:3%;
       text-align:justify;}

This code begins by creating a border margin for everything. There's also a fascinating little item called “text-align.” Leave that guy set to “justify” and you’re going to have the same problems with your ePub book as you did with the Kindle edition.

Delete that line and you get a ragged right margin. You could even run your completed ePub file through KindleGen and create a mobi that would allow Kindle Fire apps to follow suit. (Mobi apps stay justified, however.)

Below this starting portion, add the contents of the <style> section of your HTML file. Leave off the top and bottom tags.

IMPORTANT: Don’t click the “save” icon, which may be your habit by now after making changes to a file.

Instead, click File and select “Save a Copy As”; drop the item in the OEBPS folder you just created for your new ePub book. Name it:

    style.css

Undo the latest changes to the template (but keep the first chunk) and save it in the ePub Making Kit folder, ready for use on your next book.

Open the title_page.xhtml template and copy either the title page image tag or the header code from your book. Don’t include the ID code unless you also plan to add an XHTML Table of Contents. It would probably be best to remove any width and height specs that call the size in pixels. Rely on your 98% spec for width, either by writing it into the tag or using the wide class. (You do have a wide class copied to your CSS style sheet, right?) Save a copy in the OEBPS folder; undo changes and close the template.

(Actually, if you use an image file for your title page—and you always call the image “title_page.jpg,” you could keep the changes to the completed template file. Saving it now will update the template for use in your next book.)

Open the copyright.xhtml template. Copy the copyright chunk out of your book into the template. Save a copy in the OEBPS folder; undo changes and close the template.

(Again, you could save the populated template; it would be good for the rest of the year, at least.)

Open up the chap_1.xhtml template. Highlight the contents of chapter one in your book—everything from the beginning of its chapter-start (image tag or header code) to just before the page-break code at the end—and drop it into the template. Save a copy in the OEBPS folder; undo changes in the template and close.

Repeat for the rest of your chapters. If you need more templates, copy one and name it appropriately. When you’re done saving the new chapter, empty out the template and save it for the next book.

Open the about.xhtml template and drop in your “About the Author” section. Save a copy in your OEBPS folder; undo the changes and close the template.

(Or keep the changes and update the file with every new book—especially if you end your profile with a list of available books.)

Open the cover_page.xhtml template. This is where you put the image tag that points to your cover. You’ll have to write one just for the ePub version of your book. Following the pattern, save a copy in the OEBPS folder; undo the changes and close the template. (Or save it just the way it is, as long as the names of all your cover images stay “cover.jpg.”)

Close the HTML file of your book, you’re done with it.

Next time, the special files—the ncx file, the opf file, an XHTML Table of Contents; plus: how to assemble and test your ePub book.

TWO FREE BOOKS - RESULTS

Two of my books were recently on the free list at Amazon.

The last two times I gave away books, the total for the first day alone equaled nearly 90% of the entire run. This time it was a little different.

First day for MAD MINUTE: 60% of the total.

First day for EXPLODING WIZARD: 40% of the total.

Sales of HOT STATUS: 67% of the total.

For the first four days, totals dropped every day for MAD MINUTE. WIZARD followed that trend, with the exception of the fourth day, which saw nearly a fifty percent rise over the third day.

The first TWO days business averaged 72% of the eventual total action.

The first four days ran in a row from Tuesday to Friday and the event was advertised on five book promotion sites. The fifth day came a few days later and was unadvertised. (I was running out of time to use up my Select promo days, so I dumped them all out there.)

The totals from the fifth day were better than the fourth day of the advertised session. That means folks were stumbling onto these books on their own, just by perusing Amazon's site.

Although the percent-of-total number was not nearly as dramatic as the first two giveaways, I still think it makes sense to limit these freebie sessions to one or two days at a time.

And definitely get some listings on the promotion sites.

Comparing the two thrillers, well more than twice as many copies of MAD MINUTE were given out on the first day as the first days for HOT STATUS. Probably a lot of folks who got the earlier book for free took the opportunity to grab the sequel for free, too.

But overall there were 50% more copies of the sequel given out than the prequel, so I think that represents progress.

Comparing the adult thriller to the kid's fantasy novel: MAD MINUTE accounted for two and a half times the downloads.

On the other hand, the thriller had THREE and a half times the words. And took one hell of a lot longer to write.

All in all, having three or four books in a children's fantasy series out there would probably make you more money than one thriller. More books means more exposure.

And if you had four books in a series, you could probably give the first one away for free every day. That couldn't hurt.

Speaking of four books, MY fourth book is due out any minute now, but it's not part of any series. It's not even fiction.

More about that later.

Sooner, than later...

TWO FREE BOOKS

Since I'm approaching the end of my first ninety day period of Kindle Select, I've decide to put my other two book out there for free.

Starting tonight at midnight and running through Friday, MAD MINUTE and THE EXPLODING WIZARD'S RIGHT-HAND BOY will be free on Amazon. Four free days.

MAD MINUTE is the sequel to HOT STATUS. They're both techno thrillers and action/adventure novels about air defense missile.

WIZARD is a middle-grade chapter book, a whimsical fantasy set in an alternate Los Angeles in the 1950s.

I'll let you know the results.

Last time, when I gave away HOT STATUS for two days, I had seventy-some downloads (90% in the first day)—and five sales of the other books (four of them the sequel, MAD MINUTE).

Inch by inch, right?

HOT STATUS REPORT

Earlier this week I gave away my techno thriller (HOT STATUS) for two days. I can now report the results:

Seventy-one downloads, mostly from Amazon.com (61), but also from UK, DE, and Japan (7, 2, 1).

Last time, in three days, I had 70 downloads. Last time, the vast majority came on the first day, with just a handful on the other two. I wondered if it was some sort of weekend pattern.

This time, giving the book away in the middle of the week, over 89% of the hits came on the first day.

Conclusion: Do your giveaways one day at a time to maximize the number of responses. I know, it's a lot more work to schedule the giveaway and submit time after time to the book promotion sites, but you'll get more hits this way.

Last time I wondered if giving away HOT STATUS would result in sales of the sequel (MAD MINUTE). It did not.

But back then, the sequel was on sale at $2.99.

This time I lowered the price on the sequel to 99 cents.

I had four downloads.

My next experiment is to give MAD MINUTE away and see if I can generate sales for the prequel—at 99 cents.

Should work.

In the meantime, I got my first review for HOT STATUS. (First review for any of my books, really.) It came in just a few days before the freebie period. It wasn't mentioned on the promo sites, but maybe some folks went to Amazon and saw it—and it had some beneficial effect.

Maybe if I give away enough copies of MAD MINUTE I can get a review for that guy, too. I hope so.

Not only is it hard to sell books that have no reviews, most of the promo sites won't even list your book when it goes free if it doesn't have a load of reviews. And mostly five-star reviews, at that.

Last time I submitted my book to fifteen sites, and five published the promotion.

This time, I only submitted to the five that published the first time—three of them went for it the second time.

Generally, they want you to rest your book for a month before going again. I was right on the bubble, timing wise. I don't know if that was a factor or not.

More stuff coming up: Stay tuned.

HOT STATUS FREE - AGAIN

The experiment continues...

Last month I mentioned in my report on the three-day period HOT STATUS went free that I needed to try again, this time during the week.

The first time—Friday, Saturday, Sunday—about two-thirds of the downloads occurred on Friday. I wondered if the tapering off was the result of a week-end pattern.

This Tuesday and Wednesday (23rd and 24th) the book will again be available for free download on Amazon. You can click the image of the book cover on the left-hand sidebar of the blog page. Make sure it says it's free before downloading it.

I submitted the book to the same five places that responded last time, plus I looked again into the one place that said the book needed to be free on Tuesday. But that site doesn't seem to be accepting new books at this time.

I'll let you know how it all turns out.

FINAL SLASH

When I first started messing with Kindle books I inserted images with this format:

    <img src="name.jpg" width=500 height=750>
 
Later, as I tried to get closer to the ePub syntax, I added:

    alt="subject of photo"

after the sizing specs.

Finally, I added the final slash before the end angle bracket.

In XHTML, which is used by ePub, so-called empty or void tags have to be closed. So I started using slashes like this:

    <a name="chap_1"/> for anchors

    <br/> for break tags

    <hr/> for horizontal rules
 
Now my image insertions looked like this:

    <img src="name.jpg" width=500 height=750 alt="subject of photo"/>

And I fell right into a problem I hadn't seen before.

In my novel MAD MINUTE I had ganged up three images for my chapter starts: a small image of a Nike Hercules missile and images of digits to form the chapter number.

Put one image right after the other inside one paragraph, they run side by side horizontally. You just have to make sure the combined width specs come in well under the width of a Kindle Classic (around 600 pixels).

And it worked, not just in Classic and DX and iOS apps, but in Fire and Paperwhite, too.

Until I added the final slash.

Before I go on with this saga, I need to back up a moment.

Not long ago I read a blog by an ebook formatter who was using a width spec of 98%. This way, images that go almost full screen in Kindle Classic (around 600 px) will not be shrunk to a tiny little thing covering less than half the width of a Kindle Fire HD 8.9". That boy's got a lot more pixels to fill up.

It made sense. I could size all my "full-page" at 98%, insuring that every app got the full-size image, across the board.

But when I tested it, I found Kindle Classic (and others) didn't know how to handle percentage specs for width. When in doubt, mobi-code apps force the image to go full size—the actual, GIMP-created size of the file.

Okay, I could live with that. It just meant that every title page or chapter-start image I generated in GIMP would need to have an actual size equal to the full width of a Kindle Classic page.

Set the width at 98%, and the other guys (Fire and Paperwhite) would benefit from going from one margin to the other (well, almost).

I had tried to revise my multiple image chapter start by using percentages: 10% for each image.

But as I said before, Kindle Classic balked at the percentage spec—the images all went full size.

So I went back to sizing the images in pixels.

But now even THAT wouldn't work: The images still went full size.

But wait, it USED to work, right? In my earlier version of MAD MINUTE it worked! Didn't it?

I checked the old file, just to be sure, using Kindle Previewer: And yes, it worked!

Why wasn't it working in my newest book?

You probably already guessed the answer, but it took me a while to compare the files and realize that the ending slash before the last bracket was ruining everything.

So I went on with my life. I worked AROUND the problem, resizing all my images in GIMP so they would work full size.

There was no problem with images designed to go full page—I'd already fixed that deal. It was when I created images of individual letters (as super-big capitals for the first words of chapters) that I got into more trouble. Some of these smaller images were right at the edge of pixelation.

I found I needed to select extra wide fonts, like Rockwell Ultra-bold and Broadway and Goudy Bold, or the images of individual letters looked too ragged.

I thought I was going to have to live with this annoyance.

Then I remembered something from my research into the origin of the final slash in XHTML. Older browsers went nuts when they ran into that thing. The solution, add a space before the slash.

I'd seen that space before, when I went hunting for working versions of the OPF file. End tags had slashes, and some of those slashes had spaces in front of them. But not all of them. It looked chaotic. I wondered how you decided when to use the space and when not to. Did it really make any difference.

One thing I noticed, Kindle didn't seem to care if there was a space there or not. I removed them all. And had no problems.

Now I wonder.

When I checked some test code at an HTML validator site, I got no argument when I put one or more spaces in front of the final slash. (But leave out the SLASH, you'll get a good talking to.)

I went back to my Kindle image tags and inserted a space before the final slash.

Bingo! It was like the end slash wasn't even there!

(Actually, there were some minor items: In Paperwhite, using the slash without the space made the images slightly smaller; in iPad, the images were taller [but not wider] with just the slash in place; only Fire seemed the same for all—slash, no slash, slash with space in front.)

Now I could go back to sizing in pixels in Kindle Classic. That was nice, but it didn't solve the other problem. With or without a space before the slash—or without the slash itself—Kindle Classic reverted to full-size images when the width was given in percentage.

And without using width=98%, how could I get my images to spread out full width on the HD models?

I thought the solution might come from my dalliance with drop caps.

Drop caps only work in Fire and Paperwhite (kf8), so if you want to use them there, you have to make arrangements for the older versions (mobi code guys like Classic, DX, and iOS). I thought the answer for the full-page image problem would be to split the code, giving different instructions to the kf8 apps and the mobi apps.

Turns out splitting the code wasn't necessary. You do need new code, though, a new image class, in fact, but it doesn't have to hide behind a kf8-only screen. Add this code to your style section:

   img.wide
    {width:98%;}

Now some of my image insertion codes look like this:

    <img class="wide" src="name.jpg" width=500 height=750 alt="subject of photo" />
 
Be aware there is some rather mysterious interaction between the kf8 percentage spec and the pixel specs in the tag. If the spec in pixels creates a bigger image than the percentage, kf8 apps go with the pixel specs, even if the image gets all disproportionate. You'll have to test these guys in actual use, in Previewer at least.

Recently, I actually had a chance to use this information.

I just put up a revised mobi of HOT STATUS. I set my full-width spec to 98%, but there were problems. In my Photo Gallery of full page images I had five or six that refused to show up in iPad. I needed to be able to lower the size specs of those images to get them to work.

After I put the new code in place (and added the space in front of the final slash), I could do just that without having to go back into GIMP and actually change the size of those images—which, if I had done so, would have affected all the other apps.

This new code also led to a fix for the use of large letter images at the start of new chapter paragraphs. What I wanted was a bigger actual image resized by code to a smaller one. To work the compromise between Kindle Classic font size one to font size six, you need a letter (boxed or not) around 30 or 32 pixels square.

Here's the new code:

    img.letter
   {width:12%;
   font-weight:bold;}

Now the code for a chapter start paragraph might look like this:

   <p class="start"><img class="letter" src="rockwell ultrabold T.gif" width=32 height=32 alt="rockwell T" /><b>his particular morning</b>, ten-year-old...
 
You can also add a float:left spec and use this technique for "drop" image letters:

   img.drop
   {float:left;
   width:12%;
   margin:10px 8px 0px 0px;}
   
Crank up your Kindle Previewer and get to work messing with this stuff.

Or don't: You COULD just stick with "font-size:large" or "font-size:x-large" for your big capitals and be done with it. Or set everybody to 2 em. At least the capital letter will size up and down with the font.

Remember: Images of letters never change size, though a shifting font size makes it look like the image is jumping up and down. If we could just figure out how to keep readers from messing with the font size...

One brave strategy (or do I mean reckless?) might be to pick a font size and stick with that. When you check out a book that just went up on Kindle, the online Previewer is set to Fire at font size 3. You could put your entire attention on that font, make it look perfect, then take a quick peek at the rest to be sure it doesn't look TOO outlandish at smaller and larger fonts.

Boy, would THAT be a relief!

Update: Part of what I said above was right, and part was wrong. I still think you should put the final slash in, and putting a space in front of it won't hurt anything. But my reasoning was wrong; it had nothing to do with older browsers learning to live with the final slash.

In fact, the first image insertion tag I displayed above, the one ending with the sizing in pixels, WOULD fail if I put a slash at the end (without a space to protect it). But the revised tag, using the alt image title at the end, would also work just fine with a slash at the end (with no space in front of it).

Turns out the problem was putting a slash right behind the pixel spec. It apparently contaminated the spec and made it invalid. Kindle Classic and DX need both specs to size properly, so they went full size. Kindle Fire (and also the iOS apps) only need one spec to size an image, so they were unaffected when the slash turned the final spec to junk.

Also a fix: put the pixel specs in quotes. Anything to keep that evil slash from rubbing up against the raw numbers. (It's also needed for ePub.)

And I now make some other changes:

     <a name="chap_1"/> for anchors -- becomes: <div id="chap_1"></div>

    <br/> for break tags -- becomes: <br />

    <hr/> for horizontal rules -- becomes: <hr />

All to make the book ready for ePub. More about that later.

AN EXPERIMENT WITH "DROP" IMAGES

We've seen the work of drop caps. It's also possible to treat IMAGES of letters like font-based letters. Sort of.

But only in Kindle Fire or Paperwhite.

One easy way is to create some image style code and put it in the style section at the top of your book's HTML. Like this:

   img.drop
   {float:left;
   margin:10px 8px 0px 0px;}

Then, when you want to apply it, call the "class" just inside the <img> tag. Like this:

   <img class="drop" src="rockwell ultrabold T.gif" width=12%/><b>his particular morning</b>, ten-year-old [etc.]

I've also added the so-called "illuminated" letter to the mix. In the following screen shots of Kindle Previewer, the width spec for the first illuminated T is 80 pixels. The second one is set for 20%.

Here's Kindle Fire at font size 1:



The images are floating, all right, but at this font size there's been no convincing tuck-in of the text—not enough words.

Okay, so let's go to font size 3:



Now we've got some tucking in. In all examples, the image is surrounded by text. It's starting to look real. And if the paragraph had been longer, the first view would have worked, also.

Now, font size 7:

Looking even better. That letter is buried at the beginning of the paragraph.

But look at what happens in 8:

The Rockwell Ultra-bold T has been dropped all right, dropped in status to a somewhat regular letter. Is a one-line drop even a drop anymore?

Well, we've seen this before. When you’re dealing with the images of letters, there's no difference in size from one font choice to another. The relative size of the letter shrinks or balloons as the selected font rises or falls.

Now here's iPad at font size 5:

You can pretty much always count on iOS to level out the drama. As a mobi-code app, the letters will never "drop"—iOS, as well as Kindle Classic and DX, can't understand the "float" command.

Here's Kindle Classic 1:

Since each image was sized in percent (which mobi can't handle), they all defaulted to the actual size of the image.

Now, Classic at size 6:

Again, full size images. No real difference from raised caps created by images.

Finally, Paperwhite at font size 6:

Very similar to Fire at 7. I think the 80 by 80 pixel version (first illuminated T) looks the most natural.

But look what happens at font size 1:

 
 
In the third line (image width=20%), the boxed-up letter T is so large it encroaches on the remaining letters of the word "the." No doubt some experimentation with sizing would deal with this sort of thing.

But the fact is, images of letters are fixed in size. Using true drop caps—which manipulates actual font—allows the initial cap to size up and down with the font selected.

On the other hand, image-based drop caps look a lot more dramatic in mobi-code versions of Kindle than plain old 2 em caps in the standard, default font. And no need to split the code between kf8 and mobi.

More compromise and decisions . . .

And speaking of more decisions, one can also put a border around the drop image.

Here's Fire size 3 with a double red border at a width of 8 pixels:

Now Fire at font size 7; ridge type border, 12 pixels wide, in yellow:

And finally, Fire at 5; inset border, 12 pixels wide, in orange:

There are other border styles: dotted, dashed, solid, groove, outset. Check out the w3schools tutorial on css to find out more.

The complete code for the yellow ridge drop image:

   img.drop
   {float:left;
   border:12px ridge yellow;
   margin:10px 8px 0px 0px;}

Margin specs go: top right bottom left.

As for when it makes sense to use drop images, see my discussion of the use of drop caps in a previous post. Drop caps of either variety are pretty fancy fare for most books.

Still, I like the "illuminated" letter, especially with the ridge border. It looks great in the dropped position, and pretty special in mobi, too (though, sadly, sans border).

I'm sure I could whip up a more interesting version than the one I've been testing here—and put my own dang border around it, too. I just need to write something that cries out for the use of the little darlings.