Showing posts with label kindle formatting. Show all posts
Showing posts with label kindle formatting. Show all posts

Tuesday, July 16, 2013

New Adventures in Mobi Creation

No, not the whale, but the program that creates the digital book for Amazon’s Kindle (though at the moment I’m ready to put the great white whale’s last name to the whole evolution and refer to it by the crude vernacular). Since readers have their accounts set up and click a button to download their Kindle Book to their Kindle device all in a matter of seconds, an author needs her book in the Kindle Store. To get it there, she must create her masterpiece in .mobi format.

Getting my latest novel, Camellia Creek, a gothic mystery/suspense set against the backdrop of  Presidential Reconstruction at the end of the War for Southern Independence, into mobipocket, .azw format, took days, untold hours I wish I’d actually recorded so you could more clearly understand how absolutely anal I am. For those of you who have looked at my blog for “technical” advice, no matter how unintentionally spurious, you know that over a year ago I blogged extensively about my creation of the files required by MobiPocket Creator to build a mobi book. With those files—sitting in the folder for each individual book in the “My Publications” folder associated with MobiPocket Creator—I managed in 2011-2012 to upload my first four books and get them in the Amazon Kindle Store. Camellia Creek, thought I, will be a piece of cake.

Wrong. Oh, I created the files easily enough based on templates I’d created from my first four books—the .html version of my book, the .ncx file, a proper version of the .opf (MobiPocket Creator creates an .opf file automatically from whatever data one feeds it—if one feeds it no extra data, it creates it from the .html file itself and it always overrides whatever .opf file you place in the folder so you have to keep checking and cutting and pasting your good one over the one it makes. Suffice it to say, that evolution is time consuming and frustrating.). Then I added my only two graphics—the cover and my logo.

For four days I tried to get MobiPocket Creator to build my book. Now, I didn’t sit in front of my computer uploading and re-uploading the same files over and over during that time with the expectation of one time getting a winning result. That folks, is the definition of stupid. I’m just sorta stupid for sticking with it all that time. I’d make changes to the .opf and tried different renditions; I checked and rechecked all my files, my headers, my content, my “#$!%” html. I even removed MobiPocket Creator and reinstalled it—on both the computers I own with access to the internet. One thing I did discover was that every time I took the “failed” build and removed the .ncx from the mix, the book built. I knew the problem was with the .ncx or the .opf (which references the .ncx). I went to the online forums and studied and tried to replicate individual methods of inserting files into MobiPocket Creator and overcoming the Creator’s frustrating habit of messing up my .opf. At one point I created a .zip file of Camellia Creek’s files and attempted to insert that into the My Publications folder. That didn’t work either—works for epub, but not mobi. I kept the .zip file anyway.

Finally, on the fifth day, I removed the publisher version of  MobiPocket Creator and downloaded the “Home/Family” version. The MobiPocket Creator website said it was simpler to use. Personally, I didn’t see much difference from the “use” angle, but one thing that simple little sucker did when it, too, failed to build on my first try was point out one tiny error in the spelling in the “content src” for chapter seventy-four in my .ncx. I’d spelled “seventy” “seveenty”. I fixed it and Camellia Creek build on the next try, .opf, .ncx and all.

I don’t know that the misspelling caused all those wasted hours, not to mention stress, but the results rendered after its fixing indicates that was the problem. So why didn’t the “publisher” version point it out to me when the “simpleton’s” version was so quick to do so? Maybe the publisher’s version thinks publishers should know how to spell or are such thorough proof readers there is no way they’d let a screwball thing like three “e”s in seventy get by—this in a work of 79 chapters and an epilogue (Camellia Creek is twice the length of my previous books).

Oh, and now comes the really, really good part. I start uploading to Amazon—I get to Part 5 at the “Upload Your Book” window. The little pinwheel is purring, there’s a window there that says “uploading your book, this may take a few minutes” and wahlah—the KDP (Kindle Direct Publishing) platform rejects it. The window says, simply, that I used software other than that approved by Amazon. I’m confused—I sent them the .prc. KDP didn’t need to build my .prc. I SENT it one already done, darn it! And fifteen months earlier the KDP platform had accepted four of my .prc books built the same way—ok, this one was built with the “simpleton’s” Creator, but what the heck.

I go to the “formatting guide” offered in the rejection window. Sure enough, .prc’s aren’t listed. I go to the Amazon “techies”. “Yes they are,” the “techies” say. Two day’s later the “techies” have it figured out—I needed to use KindleGen to build my .prc, not MobiPocket Creator.

During that two-day interim, I went back to that “zipped” file I’d fortuitously saved during my nightmare of working with the publishers version of MobiPocket Creator and uploaded it at Part 5 of the Upload Your Book window. It uploaded fine. Camellia Creek is at the Kindle Store.

Next, my pathetic adventures using KindleGen.

Friday, January 27, 2012

The Guide

The guide, and I know this from personal experience, plays an important role in a mobipocket book. Not so, for an EPUB book. In EPUB Straight to the Point Elizabeth Castro says the guide is optional, its purpose to identify the role of the different files making up the book.

Not so in its mobipocket manifestation. Here, it serves as another table of contents, only this time for the "book" menu in the Kindle (or other mobipocket reading device) by turning the anchors created in the .html-formatted novel into selectable links. The Mobipocket Developer Center (see sidebar) describes guide items as content for the book’s "Go to" menu in the eReader.

For the Kindle, the "guide" requires only two anchors. Indeed, if I interpret Joshua Tallent's guidance correctly, only two are used by Kindle, the novel's "#toc" (the book’s table of contents) and "#start" (in the case of my book, River's Bend, the "start" is Chapter 1).

Other mobipocket devices use additional anchors and you can expand the guide if you like. River's Bend uses only the #toc and #start, since I figure if I can get the reader (by this I mean the human reader) to the toc, he/she can get anywhere else in the book.

If the guide is not formatted correctly, the reader can't get anywhere short of clicking the device's forward and reverse buttons. I know, because the "guide" was the last thing I had to unravel to get River's Bend to work correctly in mobipocket format.

I had trouble with River's Bend's "guide" section from the moment Mobipocket Creator produced the first .opf, but it was not until a month had passed following my first warning- and error-filled "build" and I had uploaded my hand-made files into the Creator's Publishing window and created a seemingly flawless "build" that I realized something was still wrong. In the Kindle Previewer, when I clicked on the Table of Contents in Kindle's menu on the top bar, I went to the cover. I couldn't get to any of the chapters, including chapter one the designated "beginning" (#start) of my book. Always, I went to the cover.

It took a little while longer and another review of the Joshua Tallent book to zero in on the "guide", which, in the section of his book of the same name (chapter 7), he states quite clearly that if the reference in the guide is incorrect, "Kindle will not contain active links to the Table of Contents and the Beginning of the book." Well, the "toc" and "start" reference types were both there, but my error proved to be in the href. My guide read thus:

<guide>
<reference type="toc" title="Table of Contents" href="Riversbend.html"></reference>
<reference type="start" title="Start" href="Riversbend.html"></reference>
</guide>

What it should have read (and now does) is this:

<guide>
<reference type="toc" title="Table of Contents" href="Riversbend.html#toc"></reference>
<reference type="start" title="Start" href="Riversbend.html#start"></reference>
</guide>

I fixed, I rebuilt, and I uploaded to the DTP. Amazon blessed it and put it in the Kindle Store. I downloaded it to my Kindle. It looked nice. I'd worked long and hard on it. I was so proud of the thing. That's when I noticed that when filling out my data on my DTP dashboard I spelled my name with three "s"s--Charlsie Russsell. No one would find me by that name. Could I have been any dumber? I was sick, afraid it would never upload right again.

Well, I guess I just answered my last question, didn't I? Amazon corrected it. Piece of cake, but it did elicit a final gasp and one last curse from silly me.

Hope some of you will find my struggle with creating a mobipocket book of use. Thanks so much for reading, and once again, comments are appreciated--especially if you can contribute ideas to improve my efforts at mobi production.

Charlsie

Friday, January 20, 2012

Manifest, Spine, and Tours

I decided to combine what I've learned about the manifest, spine, and tours sections of a mobipocket book's .opf document into one post. The first two are linked in that the "item id" in the manifest must match exactly the "itemref idref" in the spine. There’s not much to say about tours, but what I know, I share below.

First, I want to show you how River's Bend's final manifest, spine and tours sections turned out:

<manifest>
<item id="toc" media-type="application/x-dtbncx+xml" href="toc.ncx"></item>
<item id="item1" media-type="text/x-oeb1-document" href="Riversbend.html"></item>
<item id="item2" media-type="image/jpg" href="Riversbendcover.jpg" ></item>
<item id="item3" media-type="image/jpg" href="Riversbendlogo.jpg"></item>
</manifest>

<spine toc="toc">
<itemref idref="item1"/>
<itemref idref="item2"/>
<itemref idref="item3"/>
</spine>

<tours></tours>

The manifest lists the files that make up the mobipocket book, and the spine arranges the documents in a linear reading order. The manifest begins with a <manifest> element and contains an "itemid" for each "item" making up the book. Each item is annotated by its "media type," a declaration of what kind of item it is. Choices include "text" (the .html book), "image" (cover and/or logo and any other pictures in the book), "application," I assume that means how it's applied or used within the book (i.e. the navigational table of contents--.ncx file), and "font." That would be an embedded font, and I’m pretty certain embedded fonts are not applicable to a mobi book.

The section closes with the corresponding </manifest> tag. In the case of River's Bend, the manifest includes the toc.ncx file; the novel formatted in .html; and two graphics, one being the cover and the second, Loblolly Writer's House's logo, which appears on the book's title page. Four items, that's all.

The Spine section, as you’d expect, opens with a <spine> tag and closes with </spine>. In between, it tells the e-Reader (the machine not the person) the order in which to read the files. You can see the relationship between the item id in the manifest and the itemref idref noted in the opening paragraph of this post. Except for...

Okay, I admit it, the spine has caused me some confusion. In River's Bend's file, I called it, not "<spine>," but "<spine toc="toc">." My guidance came from Joshua Tallent in his example of the .opf file in Chapter 7 of Kindle Formatting (see sidebar).

Now, look at the manifest. The first item id in the manifest="toc" and its href is the "toc.ncx" file. Yes, that's right; it should be the toc.ncx element, but why isn't there a spine itemref idref like this

<spine>
<itemref idref="toc"/>

to make the spine parallel with the manifest?

First off, Elizabeth Castro states in Chapter 3 of EPUB Straight to the Point (see sidebar) that the spine element "must have a toc attribute whose value matches the value of the id in the item that referenced the toc.ncx file in the manifest." Now, I've noticed that what's right for epub more often than not is right for mobi. The two are kissing cousins, so that explains that. And although the "toc" attribute in the spine header is present (<spine="toc">) in Joshua Tallent's example, the itemref idref="toc" in the spine's body is not. His spine is very simple:

<spinetoc="toc">
<itemref idref="item1"/>
</spine>

"Item 1" in his example references the .html book itself, the reference to the table of contents being covered in the spine's opening tag.

Now, let's keep going. In April L. Hamilton's example of the spine in her Indie Author Guide To Publishing for The Kindle (see sidebar), there is an itemref idref="toc" in the body of the spine, but if you look at Liz Castro's example of the spine in Chapter 3 of EPUB Straight..., she does not place the itemref idref="toc" [or maybe it should read "ncx" ?] within the spine either.

I conclude that the digital book works either way. Which way is the correct way is a different matter. Certainly mine, without the itemref idref="toc" within the spine, works fine, and I'd be willing to bet everything April Hamilton formats works, too. By my own assessment (I've already told y'all I can be anal), I think the itemref idref="toc" should be in the body of the spine section. If so, River's Bend's spine should actually look like this:

<spine toc="toc">
<itemref idref="toc">
<itemref idref="item1"/>
<itemref idref="item2"/>
<itemref idref="item3"/>
</spine>

Anal or not, I'm not about to tempt fate. My River's Bend Kindle book works as is, and I "ain't" messin' with it. I will change the template, though, and see how Epico Bayou works with the itemref idref="toc" within the spine.

<tours></tours>

Here's how the International Digital Publishing Forum defines the <tours></tours> element: "A set of alternate reading sequences through the publication, such as selective views for various reading purposes, reader expertise levels, etc."

Got that? Neither did I.

River's Bend's "tours" section is empty. In truth, the tours section is deprecated. I do wonder what would happen if I deleted it from my .opf document altogether. I'd be willing to bet if my itemref idref="toc" missing from the body of my spine slips by unnoticed, the same would be true of a non-existing tours, but then I think if I ever understand its purpose, I might use it someday. It can be used and probably is by somebody somewhere. I’m just gonna leave it. Everyone else does.

Want to study more? My resources are in the sidebar.

Thanks for reading. Next week I plan to finish up the .opf file with the "guide" section.

Charlsie