“Zorya” available now!

Zorya is now available on Amazon in Kindle, paperback, and hardcover (casebound). I’ll be getting it into more e-book formats soon. See the Zorya website for purchase links.

This book has been marinating for a long time and was sent to many agents and editors. I’m grateful that self-publishing has gotten to be so much easier and inexpensive for authors, although the real hurdles (as always) are in marketing the book after you publish it. Still, I remember when “self-publishing” meant paying a printer, stacking boxes of books in your garage, and trying to figure out how to get them to the readers and stores.

All it’s cost me (so far) was some time, a few skills, and my computer. That may change now that I’m in the advertising zone. I notice, for example, that book giveaways on Goodreads aren’t free anymore.

I used Kindle Direct Publishing for all three Amazon editions. Paperbacks used to be a separate process on Amazon’s Createspace, and they didn’t have a hardcover option at all until recently, but now all three options are integrated into KDP.

The Kindle version was composed on Microsoft Word, and crunched into Epub3 by Calibre. I used the simple “iPod” cover I had generated in Photoshop for my old Lulu editions. The paper editions were composed in Adobe InDesign CS6 and uploaded as PDF files.

Now, we’ll see.

EPUB progress

I had a number of kludge approaches to creating EPUB versions of my books (largely documented on my blog, particularly during 2012. Look under the “Self-Publishing” tag). Mostly, I was converting from Adobe InDesign to mobi with the Kindle InDesign plug-in converter, and from mobi to EPUB with the Calibre e-book management program.

The resulting files were good enough for many applications, but routinely failed the EPUB Validator check on a few issues.

After my Smashwords publishing experience, I began trying to perfect my technique for converting from Word files to EPUB. Unfortunately, outside of Smashwords, this still required an intermediate HTML step to make an EPUB file on Calibre, so I was still getting some bugs.

Now, Calibre has come up with an update that allows direct import of Word .docx files for conversion. When I combined this new tool with the techniques for building easy-to-convert Word documents that I learned from the Smashwords Style Guide, the result was a nice, clean EPUB file that passed validation with flying colors. And about frigging time, too.

This is all probably a big yawn for the HTML wizards out there who already do a great job by grinding through the actual code, but for code idiots like me, it was a godsend.

I’ve updated my buggy Nook file and sent it off to Nook Press.  Now I could probably do a direct upload for iBook too, and finally pass their strict checks, but I’m not sure it’s worth the trouble to chew through the whole Apple Author program and everything when I’ve already got iBook access through Smashwords.

As usual, a lot of the hassle for me was making sure the table of contents worked right, as well as the endnotes. Then there were annoying bugs like a missing blank line under one (and only one!) chapter heading, or two chapters that had no nice gap between the end of one chapter and the start of the next (chapter heading shows up in the middle of a page). This was all particularly bothersome since I had to submit the Word file to Smashwords and their “Meatgrinder” converter, and then make sure all the file types were readable. If all the formats worked except one (usually the mobi), I’d have to tweak the Word file and upload the whole thing again.

It’s much easier when I’m doing all the conversion work locally. I can debug before I send the final product out.

Kindle Direct Publishing launches beta of cover creation tool

Article at “The Digital Reader.”

One of the hardest parts of self-publishing is generating a good cover, either for paper books or digital ones. Places like Createspace and Lulu, among others, already have “cover wizards.”

You can certainly get a workable cover out of these “wizards,” but in my opinion it’s worth the effort to learn how to generate the artwork yourself, or at least hire it done. For one thing, there may be rights issues involved in reusing a cover created by a particular format’s “wizard” for another format. For another, you’re never going to get as much originality from a “wizard” as you can from real artwork.

Artwork for paper books, using the “one piece cover” art method, is hard to lay out. A one-piece cover is what you get by basically flattening the book out, or in the case of a book with a dust jacket, by removing the dust jacket and flattening it out. It’s easy to see that lining up the spine, end papers, and everything else can be tricky. Even changing the number of pages can affect this kind of cover design as the spine area gets larger or smaller.

Cover artwork for Kindle (or other e-books) is much simpler. It’s just a single JPG picture with art and title text. Last time I checked, preferred sizing for Kindle covers was 1563 pixels on the short side and 2500 pixels on the long side.

If you’re planning to do a lot of this kind of thing, it may be worth it to invest the time and money in learning Photoshop, InDesign, or other professional publication software. Adobe’s “Creative Suite” isn’t cheap, but it could be a good investment.

Embedding fonts on Kindle

I loaded a test version of my Zorya manuscript onto my old keyboard Kindle.  I used the same process I’d used before:  imported my basic Word file into Adobe Indesign, made the proper format changes, added a table of contents, and then used Amazon’s Kindle converter plugin for Indesign to create the .mobi file.  Then I just mailed it to my Amazon Kindle e-mail address, and in a short time it showed up on my Kindle.

When I opened the book, the font looked thin and spidery, and hard to read. I checked the Kindle’s display control panel, and noticed a line I’d never seen before: “Published Font: On/Off” I switched it off, and the text popped in nice and clear.

I checked a few purchased books, and none of them had that line in the control panel. Then I checked Castle Falcon, the one I’d published to Kindle before. The “published font” line was there, and it was switched off! I turned it on, and got the same spidery font. Yipes. That version is out there on sale.

I went back and made new Kindle files of both books using the plug-in, and this time switched off “embed fonts.” Tests of the results show they display nicely, and there’s no “published font” toggle confusing things.  I uploaded an update of Castle Falcon to Kindle Direct Publishing, and will try to get Amazon to tell purchasers the update is available.

So, if you’re making your own Kindle books, I recommend not embedding the fonts unless there’s some special reason they have to be in there. For most of us who are just writing regular normal-text books, the Kindle reader default font ought to work just fine.

Nook version done (finally)

The “formatting tweaks” took more tweaking than I thought (I won’t bore you with the messy details), but I fired off my EPUB version of Castle Falcon to Barnes and Noble this morning. I’m interested in how the book’s online web page will look.

As I said before, the hardest part of e-book publishing is coming up with a file that does what you want it to when it shows up on someone’s e-reader.

A quick summary of programs I found helpful:

Adobe InDesign is great for formatting real paper books but it’s expensive. If you’re a student, you can get it a lot cheaper. The Kindle Plugin turns out reliable Kindle files, but I found that InDesign’s EPUB save function had some bugs. Your mileage may vary.  Most people will get more use out of methods of converting Word files and the like, and unfortunately I didn’t do a lot of that so I don’t have much advice in that area.

Calibre is a great program for dealing with e-book files on multiple levels. I used it to create good EPUB files by simply converting my final Kindle files. It can do a lot more, but that one function was what saved my bacon.

Sigil is another editing program for working with e-books. Although I only used it for one minor formatting issue (losing my “coding virginity”) the program would be excellent for those familiar with HTML and working “under the hood” on e-books.

You can find book viewers (Kindle or EPUB) for any computer or almost anything that has a screen. If you don’t actually own an e-reader, this is critical for previewing your final files. All of the readers are free.

Kindle viewers can be found here.

Nook (EPUB) reading apps can be found here.

Now maybe I should get back to actually writing books…the one part of being an author that’s even harder than creating e-book files.

Footnote aggravations

Since the last entry, I found some serious problems with the footnotes in my EPUB version of Castle Falcon.

Unlike the Kindle conversion plugin for Adobe InDesign, InDesign’s built-in “save as EPUB” function has no mechanism for driving my Pratchett-style humorous footnotes to the very end of the book (essentially converting them to endnotes).  The only two choices I have are to have the footnotes right at the end of the paragraph they appear in (blech!) or have them show up at the end of each chapter (blech squared!)

What’s so bad about that?  Well, if you’re doing your job right as a writer (or at least trying to), the end of a good chapter should be a nice punch line that really makes your reader want to find out what happens next:

“Suddenly he turned around, and there was the creature he’d been hunting, right behind him.”

Now, imagine that snappy fadeout with a humorous footnote (from a completely different part of the chapter) tacked right after the last sentence on the page:

“Suddenly he turned around, and there was the creature he’d been hunting, right behind him.”
[12] Everyone else in the family believed that anchovies on pizza were a crime against nature.

On the smooth road of carefully-planned plot development, your reader has just tripped over a nice big cement block.

So if InDesign couldn’t get my notes back to the end of the book where I wanted them, what could?  (No doubt the EPUB wizards out there are smiling indulgently right now, going over the dozens of complex code modifications they’d use to fix this, but keep in mind I’m quite new at all of this.  Besides, I really don’t like working with code.)

The next thing I tried was starting from an original Word manuscript and importing that into the PubIt! converter online.  I spent a lot of time wandering around that particular dead end.  The footnote links in the resulting EPUB were at the end of the book all right, but they didn’t work properly.

In the converted Word file the footnote references in the text linked back to the notes at the end of the book, but they didn’t link in the other direction.  Only the last endnote, number 16, linked back to the original page when I previewed a download using Nook for PC.  In Adobe Digital Editions, it was even weirder.  All the endnotes linked backwards to the same obscure page in the book, and that page didn’t even have a note reference in the first place.

At this point, I was almost ready to chuck the whole thing.  I decided to pull up an EPUB file editor to see what was going on in the (gulp) code, and used a program called Calibre which I’d downloaded a while ago.

I noticed then that Calibre comes with a file converter function.  Well, whaddaya know. One of their recommended input formats is Mobi (Kindle), so just for kicks I used Calibre to convert my already-working Kindle file to create an EPUB file.

Wow!  The EPUB file came out with working endnotes at the end of the file, just like the Kindle version, and they linked back and forth properly.  As a bonus, Calibre had converted the Kindle file’s table of contents too (I never created one for the Word file).  The links on this also worked properly, linking each table of contents entry to the proper chapter beginning.

There are still one or two minor formatting tweaks I’d like to do before I’m ready to publish my Nook version at Barnes and Noble, but there’s definitely light at the end of the tunnel.

Kindle

Kindle e-publishing is almost fun to do, once you’ve gone to the hard work of creating your working file.

I had the advantage of doing all that work ahead of time for my Lulu gift books. All the formatting, spelling checks, beta-reader reviews, revisions, etc. I had the added advantage of starting with Adobe InDesign documents, which converted neatly with a plug-in (downloadable from Amazon for free) to get the final Kindle format (.mobi).

I made two changes. First, I wanted a table of contents. This isn’t essential for a Kindle book, but the classier ones have them. I had to construct a table of contents in InDesign that would then be converted automatically by the plug-in to hyperlinks in the Kindle document. This took a while, since I didn’t have any tables of contents in my Lulu documents at all.

As with a lot of word processors, the InDesign table of contents automatically fixes itself when you move pages around. The main technique is to assign a very specific paragraph style to your chapter headers (I very creatively labeled this style “Chapter Headers”). Then you just tell the table of contents creator to flag those for numbering.

When I was finally done, I liked the table of contents so much that I’m going back now and revising my old Lulu versions so they also have them (those, of course, will have page numbers, not hyperlinks).

The second thing I had to do was modify my Lulu book cover illustration for Kindle use. A hint: Always generate your cover graphics in a very high resolution (at least 300 dpi). You can always cook it down lower if you need it. Amazon likes Kindle cover images that are at least 2500 pixels high, with a 1.6 ratio of height to width. They’re selling books for some pretty high-res machines, now, and it doesn’t hurt to have your cover look great on an IPad Kindle app.

I dealt with footnotes in an earlier post.

Then you import your Kindle-ready file (.mobi in my case, but they do take others) and give Amazon a link to a properly-formatted cover image on your computer.

The rest is just going through the forms online and making some selections. There are decisions involved:

The “Kindle Select” option enrolls you in a program that gives you some benefits, but it prevents you from electronic publishing anywhere else for 90 days, automatically renewed unless you tell them. I went for this, since I wasn’t concerned about the other reader formats for now anyway. People can get a free Kindle reader app for almost any electronic device with a display screen.

DRM (Digital Rights Management) or not? I went for “not.”

Kindle does not assign you an ISBN. There’s a unique Amazon identifier number, though.

Pricing. There are restrictions (depending on other selections). The size of your file limits how cheap you can sell. Big files have higher minimum prices. There is a 30 percent and 70 percent royalty level (not bad), but that selection alters your price choices and some other things too. Pay close attention. I ended up with $2.99, which (in my completely unbiased opinion) is a good deal for a book of almost 500 pages.

Don’t overprice.

At the end of the process, Amazon will generate a final Kindle file and make it available to you for preview. Use that preview! As I said, you can get a Kindle app for any computing engine if you don’t own a Kindle, and they have an online previewer too. This is where you catch the bugs. I’d been previewing my plug-in output all along this way, so at this point I didn’t get any surprises.

When you finally hit the “publish” button, it takes time for things to mature on your new Amazon page. Features get added, bit by bit. Most of it is complete in a day or so, but some things like “Look Inside” take about a week to appear.

This is a very informal article, and Amazon has a lot more detailed help here. Make use of their forums, too.