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

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

Metadata

A Mobipocket publication is an Open Publication Format (.opf) file composed of one master eXtensible Markup Language (.xml) file and multiple .html and graphic files. The master file, bearing the suffix .opf, is a text (.txt) document and contains data that points to the content files (i.e. the book and cover graphic) and includes the book's manifest, spine, and guide sections. But before those, the .opf file contains the book’s metadata.

The metadata section includes information about the book: author, publisher, description, identifier, etc., which allows the buyer to find the book. This section also has a subset, which includes the output encoding, the embedded cover graphic, and the price of the book.

The metadata section begins with two metadata namespace attributes: Dublin Core metadata specifications (dc-metadata) and “open ebook” specifications (oebps), which keeps the .xml document valid. The dc-metadata elements, oebps elements, and x-metadata were deprecated with the launch of the ePub format in 2007, but the Mobipocket format continues to use them.

Here’s what those statements look like:

<metadata>
<dc-metadata xmlns:dc="http://purl.org/metadata/dublin_core" xmlns:oebpackage="http://openebook.org/namespaces/oeb-package/1.0/">

And here’s the rest of River’s Bend’s metadata section:

<dc:Title>River's Bend</dc:Title>
<dc:Language>en-us</dc:Language>
<dc:Identifier id="uid">978-09769824-8-7</dc:Identifier>
<dc:Creator>Russell, Charlsie</dc:Creator>
<dc:Publisher>Loblolly Writer’s House</dc:Publisher>
<dc:SubjectBASICCode="FIC014000">Historical Fiction</dc:Subject>
<dc:Description>Thirty years following the War Between the States a handsome stranger comes to Mississippi and marries a cast-away beauty in exchange for a now decrepit antebellum home steeped in dark history and rumored to hold the secret to a fortune in missing Yankee gold. Mystery, suspense, and romance that will keep the lights on and the pages turning until the final mystery is solved.</dc:Description>
<dc:Date>12/21/2011</dc:Date>
</dc-metadata>

<x-metadata>
<output encoding="utf-8" content-type="text/x-oeb1-document" </output>
<Embeddedcover>RBcvrkindle.jpg</Embeddedcover>
<SRP currency="USD">2.99</SRP>
</x-metadata>
</metadata>

For those of you who want to delve further into the “why’s” of a mobipocket book, here are the sources I used: Joshua Tallent’s Kindle Formatting, April I. Hamilton’s Indie Author Guide To Publishing For the Kindle..., the Mobipocket Development Center website, the International Digital Publishing Forum website, the Dublin Core website, and good ole Wikipedia.

I love it when this stuff starts making sense, even if just “sorta.” Next week I'll discuss the “manifest, spine, and tours.”

And if anyone is interested in how my baby looks on Kindle I'd love for you to go over and take a look at the Kindle Store.

Thanks for reading,

Charlsie

Mobipocket's OPF File Part 1

Of the three .txt files making up the mobipocket version of my first Kindle book, River's Bend, I found the .opf file the hardest “to get right.” The .opf or open (ebook) package format has a number of sections, all different, but related, making its structure confusing. Accuracy, however, is critical.

Mobipocket Creator produced River’s Bend's original .opf file in a subfolder on my hard drive way back in November when I first hit “build” in the Creator’s publishing window. The book built with 56 warnings and three errors and it continued to produce a significant number of warnings and errors “build” after “build”. The warnings I soon associated with my chapter heads and pages containing front and back matter. Mobipocket Creator identified the errors as a missing cover and missing table of contents (the latter, no doubt, the cause of those 56 warnings). The problem (and solution) was the .opf file. Simply put, the .opf file is the glue that holds the digital book together--it’s what makes the e-reader (Kindle, Nook, ipad, whatever) work. It’s the “brain” of the digital book, and if its circuitry isn’t right, the book is screwy.

The .opf file is an .xml (eXtensible markup language) file, which, as I understand it, is a container file within which .html and .xhtml/.css (used for EPUB) languages are placed. I have no idea what else .xml files are used for, but certainly they contain .txt documents belonging to digital books, because that’s what the mobi and epub .opf files are--.txt files. Regardless, .xml is equal to, but different than the formatted text that goes into them. Think of the combo as “language within a container”--assuming you want to think about it at all. For our purpose here, you really don’t have to. Suffice it to say, the format for this file is rigid, if simple. All you have to do is get the letters, numbers, and goofy-looking characters in the right place and you can create your own .opf file from scratch.

BUT, Mobipocket Creator can create one for you based on the data you feed its publication window.  River’s Bend’s first .opf file I liken to a shell. The Creator produced a perfectly formatted header for me as well as all the sections, but a lot of needed information was missing. Further, the file was not well structured. The solution was to edit it. Given the .opf file is a .txt document, the ideal editor is Notepad++. If you don’t already have that particular software, go here for a free download.

I edited River’s Bend's .opf file from the dc:identifier down. I also broke down the sections so I could "see" them. My Mobipocket Creator-produced file ran from the left to the right side of the screen, then disappeared from view. It’s hard to work with that, and even scrolling doesn’t organize the sections so I can tell where one section/subsection ends and the next one begins. Clearly, carriage returns were needed.

The mobi .opf file consists of five sections wrapped up within a package.

The sections are:

(1) Metadata

(2) Manifest

(3) Spine

(4) Tours (unused)

(5) Guide

Over the next several weeks I intend to detail the .opf file section by section. I’ll start next week with metadata. My goal to produce a mobi book evolved into a plan to create a template whereby I could produce from scratch the files required to build a mobi book. By this, I mean, not using Mobipocket Creator to create the “files.” I think I’ve accomplished that--I'm happy to announce that River's Bend is now for sale at the Kindle Store.

Using the Creator to produce the .prc book for upload to the DTP is a different matter and will be the subject of a later post. Thanks for reading.

Charlsie

Table(s) of Contents and Kindle Books

Simply put, there are two of them, one embedded in the book and one, the Navigable Table of Contents (toc.ncx) housed in its own file.

At one point during the creation of my first Mobipocket book, I had three Tables of Contents associated with my book. One was the Table of Contents (TOC) I embedded near the beginning of my .html book. This embedded TOC is the standard, run-of-the-mill contents page which links to front matter, back matter, and chapters by way of simple anchors; Mobipocket Creator spat out the second TOC during the build stage; and the third TOC was the “navigable” (toc.ncx) file, which I created from scratch.

For creating/formatting the embedded Table of Contents (TOC) and the toc.ncx, I again refer the reader to April L. Hamilton and Joshua Tallent.

I looked for a good definition for the toc.ncx file and came up with Table of Contents Navigation Center eXtended, courtesy of the International Digital Publishing Forum (IDPF). No, this doesn’t define the .ncx file, merely breaks out the acronym. As best I’ve been able to figure, an .ncx file allows reading systems (by that I think the powers that be are referring to devices such as Nook, Kindle, iPhone, etc.) that recognize “auxiliary” content to navigate to that auxiliary content. Otherwise, the reader (the human holding the device) couldn’t get to it. In other words, the .ncx file “extends” the content that the device can access/show/read. Kindle 2, I assume, fits that category of devices; hence, Amazon requires an .ncx file for its Kindle books.

In the case of a simple fiction novel such as my River’s Bend, the toc.ncx doesn’t extend accessible content by much. For example, the .ncx file will take my readers two additional places that the regular TOC does not: River’s Bend’s cover and its (embedded) Table of Contents.

The cover is not present in the book’s embedded TOC because it’s not part of the book’s content, and the second item...well, I don’t really need to explain that, do I? In other words, the embedded TOC provides links to the book’s content and the .ncx file provides links to “auxiliary” content--it gets the reader to the book’s cover if he wishes to see it (and what reader doesn’t?) and to the Table of Contents, which gets the reader everywhere else in the book. Of course, the toc.ncx also gets the reader “everywhere else,” which begs the question, is the embedded TOC really needed? Probably not, but it is part of the book’s content right?

Actually, in my print version of River’s Bend, there is no Table of Contents and that’s true of the majority of fiction books these days. Nevertheless, the reader cannot “fan” through the pages of an eBook--an alternative method is needed.

I inadvertently created that aforementioned Mobipocket Creator-produced TOC (identified by the suffix .mbp) early on, when first getting acquainted with the Mobipocket Creator Publication Files window. I’ll admit, I struggled with what to do with the thing for hours. It was one line--said “Table of Contents”--then the page was blank. Of course, it was blank from lack of data that only I could provide. In point of fact, I now understand that the Table of Contents tab in the Publications Files window is for the publisher’s convenience to automatically create the book’s TOC, which I’d already done from scratch and embedded in my book. I know now that just because a tab appears in the Publications File window that doesn’t mean I have to use it.

Oh, duh!

Next week I’ll talk about River’s Bend’s OPF (open publishing format) file. The “glue” that holds the digital book together.

Thanks again for reading,
Charlsie

Creating Mobi Files for the Mobipocket Creator

I didn’t make my Friday, 23 December 2011 deadline and bring my blog back on schedule, and I didn’t upload River’s Bend to Amazon’s DTP. Oh, but I do have a nice .prc book sitting in My Publications folder on my hard drive.

Mobipocket Creator compiled the book from five files: my book in .html format, River’s Bend's open package format file, the toc.ncx file, and the cover and logo graphics. The Creator didn’t create any of those files. I created them, then uploaded the finished document into Mobipocket Creator’s Publication Files window.

Okay, I’ve misspoken. In point of fact, way back in November, the Creator did make the first .opf file, which I subsequently annotated. Mobipocket Creator created the original .opf file automatically when I hit “Build” the first time. That file was compiled from the data I gave the Creator using my input to the “Book settings,” “Metadata,” and “Guide” sections in the Publications Files window. Without that step, I would have had to find an example of another .opf file for mobi, then modified it to fit my book. In the beginning, I wouldn’t have even known I needed an .opf file, much less thought to create my own from scratch. I know now.

As it was, I spent a significant amount of time changing (which mandated, by default, studying) that most critical “.opf file”. Good Lord willing and the creek don’t rise, I’ll not have to use the Creator to conjure up another generic .opf file. I now have, in my humble opinion, a beautiful .opf file. But I digress. A detailed description of my trials and tribulations with that .opf file will be the subject of a later blog. The file might be beautiful now, but it took a lot of work getting it to that point, and I want to share.

I intend to use the files I created for River’s Bend as a template for my other three published (and all future) books. I will, at that point, as I’ve done with River’s Bend, upload the completed files into the Creator’s Publication Files window. No more inputting data, then having the Creator crunch out files, which I subsequently have to modify.

In a nutshell, here’s the process I’ve come up with using the Mobipocket Creator to create a .prc version of my book for subsequent upload to the Amazon DTP:

1) I took the Word (.doc) document I created for Smashwords and saved it as a filtered web page (that converted it to .html.). [see my earlier blogs regarding the Smashwords Style Guide.]

2) Per April L. Hamilton's Indie Author Guide To Publishing For The Kindle With Amazon’s Digital Text Platform, Mobipocket Creator & MS Word 2003 Or Higher I went back into my graphics program (I use Paint Shop Pro 8) and reformatted my two graphics (cover and logo) to meet Mobipocket requirements. [Changed image size and dpi]

3) I opened my .html document in Notepad++, added anchors, and cleaned up the document.

Preparing the .html document for upload to the Creator (and subsequently to the DTP at Amazon) takes work, no question about it. But if you know the basics of .html, doing so isn’t hard. “Tedious,’ in my opinion, best describes the effort.

4) I annotated the .opf file as explained above.

5) I manually created the navigable table of contents (toc.ncx) required for Kindle 2.

Joshua Tallent and April Hamilton both provide guidance on creation of the toc.ncx. I, fortunately, had already created an .xhtml toc.ncx for another of my books I put in ePub format, so I was familiar with the structure of the .ncx file. I even used that previously created “xml” file as a template for the toc.ncx file associated with my .html document.

6) I uploaded the .html document and graphics into the Creator’s Publication Files window along with my now “beautiful” .opf file and my toc.ncx files.

You will not see the .ncx and .opf files in the Creator’s “Publication Files” window, but you will see them in your My Publications folder. Make sure you click on “all files” when you start your search.

7. I hit “Build,” which took me to the “Build Publication” window where I opted for standard suppression and no encryption, then hit “Build” again.

And it built. No errors and no warnings.

I reiterate that the 7 steps I outlined above are what I’ve boiled the process down to. You see, when, at point 7 I said my book “built” perfectly, I left out the first 50 times I’d come to point 7 and it did not. Failure after failure to the point I just wanted to sit down and squall. That or take a hammer to the poor ole computer, which really couldn’t be blamed at all.

I did neither. I went to bed and woke up the next day and started again. I’m pretty sure “I got it” now. Look in next week, and I’ll tell you what I understand about the Tables of Contents.

Thanks for reading.

Charlsie

Those Elusive Files Required For a Mobipocket PRC

I may be a day late with this blog post, but I’m not a dollar short. In a week spent finishing up Christmas decorating, power shopping, wrapping, getting gifts and orders in the mail, and completing my Christmas cards, I still managed to figure out what files the Mobipocket Creator requires to produce a mobipocket.prc book for uploading to Amazon’s Digital Text Platform (DTP) and subsesquent creation of a Kindle book. PRC is a container format for the Palm OS PDA. PRC files are used by mobipocket eBook readers. I tell you this not because I understand it, but to let you know there is a connection between .prc and mobipocket, and what the Mobipocket Creator produces during the “build” process is a .prc file. The DTP uses that .prc file to create the Amazon.azw--a DRM or digital rights management-restricted format of the book. This is the Kindle book, exclusive to Amazon.

I love having all that straight in my head. I didn’t before. Here’s what happened this past week:

First, I discovered April L. Hamilton, author of Indie Author Guide To Publishing For The Kindle With Amazon’s Digital Text Platform, Mobipocket Creator & MS Word 2003 Or Higher. Joshua Tallent has a link to her book at his eBook Architects website. Ms. Hamilton’s focus (and here I allude to my last post) is the creation of a mobipocket.prc file for uploading to the DTP. From my point of view, Ms. Hamilton is to mobipocket what Elizabeth Castro is to ePub.

I downloaded Ms. Hamilton’s Indie Guide... and read it twice. I conclude that only four files are required to build a mobipocket.prc book in the Mobipocket Creator. Those files are:

1) The cover (embedded in the book’s .html file, but as is the case with a web page, for example, the graphic must be included in the folder or the system can’t display it)

Any other graphics in your book must also be included. In my case, I have a logo

2) The book in .html format

3) The Open Packaging Format (.opf) file, an .xml file that the Mobipocket Creator generates automatically with information provided by the author/publisher on the publishing page (Guide, Book settings, Metadata)

The .opf file consists of the book’s metadata, manifest, spine, and guide

4) The Navigable Table of Contents (toc.ncx) file, which the author/publisher creates manually, then uploads to Mobipocket Creator

Ms. Hamilton starts with making a clean, properly formatted Word document (.doc). This is what she prompts the publisher to upload to the Creator. From the Word document, the Creator formats the book into an .html document.

The conversion of a Word document into .html produces, in my opinion, messy .html. I create my own .html version of the book from the Word document before uploading to the Creator. BUT, I learned .html when I built my own website. Far from being an expert, I still know enough .html to be comfortable using it, and Kindle’s .html formatting is not complicated. Hence, I redirect interested readers back to Joshua Tallent’s book, Kindle Formatting. Mr. Tallent goes into great detail on formatting with .html, but abbreviates the creation process. Ms. Hamilton carefully walks the publisher through the creation process in her Indie Author Guide..., but scarcely broaches .html formatting for the book. By combining their guidance, I think any determined self-publisher can create a nice Kindle book on his own.

Note the qualifier, “I think.” I’ll let you know for sure next week. By then, I hope to have cleaned up River’s Bend in the Mobipocket Creator, produced the .prc version of the book, reviewed it in my recently downloaded Amazon Kindle Previewer, and uploaded it to the Amazon DTP.

My ultimate goal is to use the files I’ve created for River’s Bend as templates for my other three books and future books, allowing me to bypass the Mobipocket Creator automation of the .html and .opf files, uploading instead, clean, “build-ready” versions of the files to create the .prc file. The .opf generated by the Creator always will require manual changes/corrections and those corrections for my books will always be the same. Why redo the guide, book settings, and metadata, step by tedious step, every time I create a .prc version of my book?

Thanks for reading this week. Comments are appreciated.

Charlsie