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