The reason I gave in and bought a third-generation Kindle was simple: price. With the wifi + 3G version now only $189, it finally falls into that price bracket of 'worth a try'. If I decide in the end that it's not working out, I won't have blown too much money — assuming that I haven't invested a great deal in books (but more of that later).

The improvements with the third-generation Kindle (or Kindle 3 as it's inevitably, but unofficially being called) don't end with the price drop. Amazon has reduced the size and weight and adopted the latest screen technology — the Pearl e-ink display.

And then there's the small matter of not having any other e-reader. At WebVivant Press we're publishing e-books, but my only experience so far of reading them has been on the laptop. That's just not right. I wanted to find out what the e-reader experience is like.

I could have bought a Nook, or a Sony e-reader. But, frankly, of the dedicated e-readers on the market, the Kindle strikes me as the only long-term prospect. Besides which, we publish on the Kindle through Amazon DTP, so it seemed like the right move.

The other option was the Apple iPad, but there were two very good reasons for not going that route: 1) it starts at 499 euros; and 2) it's still version 1 and I never buy v.1 of anything, especially when it's from Apple (and I'm a fan of their products).

First impressions

I opened the box (entirely made of recyclable card, BTW), lifted out the Kindle, peeled off a couple of transparent plastic protective sheets and was about to peel off a sticker covering the whole screen when I realised there was no sticker. What appeared to be a printed sheet was, in fact, the display itself. That's a good first impression.

E-ink displays are the opposite of laptop screens — the brighter the ambient light the easier they are to read. Sitting in the garden on a dazzling sunny August day, the Kindle's screen was a joy to use — very easy on the eyes. As light levels drop, that's when you start squinting. Now, you could say the same is true for those archaic, last-century reading devices … what are they called? … oh yes, books. And that's true except that, even with the latest Pearl screen, the Kindle still doesn't achieve the contrast (and therefore readability) of the printed page. It's not far off, mind, but there's enough of a difference that, as the sunlight fades, you'll be hunting for the light switch sooner with a Kindle than you would with a book.

The Kindle comes with a pre-loaded manual, but I've been a tech journalist for nearly 30 years and I'm damned if I'm going to start reading manuals now. Fortunately, navigation is reasonably intuitive. I showed the Kindle to a bunch of friends at a writer's group meeting. None of the group members is what you'd call in the first flush of youth, and among the people I know these are the least likely to be impressed by a gimmick or 'cool' bit of technology. But all were, in fact, impressed. One person (who, admittedly, is at least reasonably tech-savvy and certainly far above average intelligence) was quickly moving between books, checking out the text-to-speech feature and generally finding her way around with no prompting from me.

Connectivity

Where the Kindle scores above many other e-readers is the tight integration with Amazon. That sounds obvious, but an important part of the Kindle experience is not having to switch to a computer to find and download books. Immediate access to the Amazon store from the Kindle itself makes it a competely stand-alone product.

For example, during lunch, the subject of conversation alighted on Jack London and I had to admit I'd never read White Fang. A few moments later I had a free copy of the book on the Kindle (even with a slow Edge connection — no 3G around here). One of our group, a 70 year-old with, as far as I know, no special love of technological toys, was soon buried in the book, having adjusted the font size to compensate for not having his reading glasses with him. He said he found he was changing pages without any conscious action, just as one might flip the pages of a printed book.

Indeed, what I've found with the Kindle is that one can easily ignore it. When I read an e-book on the screen of my laptop, I'm always aware of the machine somehow. I have to try to see through it. It's an effort. With the Kindle, just as with a book, I soon lose any awareness of the physical object and am quickly inside the world of the story. I think the e-ink technology has a lot to do with this — its easiness on the eye erases the barrier between you and the text.

The Kindle also copes well with my pathological compulsion to make notes. Highlighting sections of text is easy, and you can add your own notes. Or you can simply mark a page with a bookmark. You don’t need to do this to remember where you are — the Kindle automatically keeps your place, even as you flip back and forth between books. And there’s an option to synchronise your place between the Kindle and the Kindle apps on your computer, smartphone or iPad.

When reading magazines or newspapers, there's an option to 'clip' the article you're reading. This adds the text of the article to a file (just one file for all your clippings) which you can download on to a computer. No doubt this will prove a huge boon for students who need to plagiarise when writing papers.
The search facilities are not bad, too. The search results pages show chunks of text with your keywords highlighted, so it's easy to see the context and know which results are relevant.

Other features

The Amazon store access is provided by dedicated software. But you can also browse the web on this machine. The web browser is surprisingly good, though slow. It wouldn't be my first choice of platform for mobile web use, but it'll do in a pinch.

Amazon still classifies the browser as one of the Kindle's 'experimental' features. Another is the text-to-speech feature, which is mostly ghastly. The voice pauses in all the wrong places. It's like being read to by Stephen Hawkins' idiot brother. I can't think of a single use for it. If you're sight-impaired, go for real audiobooks instead. It's bad enough being blind without having to put up with this.

As someone who doesn't text (in fact, I don't even have a mobile phone anymore), using the keyboard with its tiny buttons is a challenge. Given that you can increase the size of the display font, I was going to recommend the Kindle to a friend with eyesight issues. But this barely visible keyboard ruled that out.

I've invested quite a lot of time working out how to hold the damn thing. The new Kindle is lighter and smaller than its predecessors. In fact, as far as weight goes, it's not dissimilar to a lot of paperback books. It's just that I've found it tricky to hold comfortably without hitting the back/forth paging buttons or the keyboard. I'm starting to think that a leather case would actually make it easier and more comfortable to hold.

Mixed blessings

So far, finding books for the Kindle has been slightly frustrating. Bestselling novels are generally not hard to find. But my tastes tend to run a little more eclectic, and so far I've found that only about one in three is available in Kindle format.

And in spite of Amazon's much publicised battles with publishers to get them to bring down prices, some Kindle editions can run rather more expensive than I'd like.

Against that is the availability of so many classic texts as free editions. These editions have largely been created by enthusiasts and volunteers (like Project Gutenberg) so the quality is variable. You get rogue carriage returns. There are rarely clickable tables of contents. But it's surprising how little any of that matters when the price is so right. Within minutes of starting to use the Kindle I had works by Austen, Dickens, Kipling, Swift, Chekhov, Wharton and Dostoyevsky, plus On the Origin of Species.

And in spite of my complaint above, there are inexpensive editions. I spent something like $3.75 for a good version of the King James Version of the Bible, with clickable contents and navigation links. (As an atheist, I've filed this under 'classic fiction'.)

A few reservations

The Kindle is not perfect. In fact, I still have a few reservations about the entire concept. I'm very conscious of the fact that any books I buy will be available to me only so long as I have a Kindle reading device. Now, that could include, say, an iPad with the Kindle app. Indeed, around 20% of the people buying and reading Kindle editions are doing so on something other than a Kindle. But all the same, the relative lock-in to the Kindle ecosystem does give me pause. I will probably limit my Kindle purchases to free books, and those I am likely to read only once or twice.

It also annoys the crap out of me that I can't load our ePub e-books on to this machine. (I tried, just in case Amazon had made the Kindle ePub compatible without telling anyone. They hadn't.)

You can get books on to the Kindle other than by buying them from the store. You can plug the Kindle into your computer, which will view it as an external disk drive. You then just copy readable files (plain text and PDF, for example) to the device.

Amazon also gives you a special email account: <YourUserName>@kindle.com. You can email various types of file (eg, Word documents) to this email address at which point Amazon converts the file to Kindle format and downloads it to your device. There's a small charge for this — $0.15/MB — presumably to cover the wireless costs. Alternatively, you can email the file to <YourUserName>@free.kindle.com. Amazon then converts the file and makes it available for you to download, via the web browser on your computer. You can then copy it across to the Kindle.

The future

In spite of the browser and a few other gimmicks, the Kindle is still a one-trick pony. But it does that trick — being an e-book reader — superbly well. It offers an excellent reading experience.

We all know that the predominant trend in technology is convergence. The Apple iPad scores so much better in this regard. It's a multi-purpose machine. It's capable of far more than reading books, and it’s larger size and colour screen make it superior for magazines. As an e-book reader it’s let down by being an LCD screen, which is immeasurably less crisp that e-ink and far more tiring on the eyes. When display technology improves, the Kindle's one advantage — ease of reading text — will diminish, perhaps even vanish. But I think we're still a few years from that point. And who knows? Maybe Amazon will expand the capabilities of future versions of the Kindle, making it more into a fully-fledged tablet device.

For the time being, though, for long-form reading, nothing beats the Kindle. And in the end, that's why I decided to buy one. The Kindle concept, as currently conceived, has no future. But that's fine, because I'm using it to read books now, and enjoying the experience immensely.

• The Kindle is available at Amazon.com and Amazon.co.uk. 

Apple is often admired — and not just by fanbois — for the beauty of its products. But what is often overlooked is the cleverness with which it creates ecosystems in which everything works together. Your MacBook Pro works effortlessly with your iPhone, iPod and iPad. And Apple's services — such as Mobile Me — make it easy to share data across devices, put images on the web … and so it goes on.

This integration is a great selling point. It's the basis of the so-called 'halo effect' in which people who are not habitual Apple users become seduced by one device — the iPhone or iPad perhaps — and find themselves longing for other Apple products because they work together so well.

A small, largely unheralded update to iWork has given us another example.

The iWork suite is Apple's cut-price office package. It contains Pages word processor and page layout software, the Numbers spreadsheet and the Keynote presentation package. This isn't a guide to using Pages: if you want to know how to wring every last bit of capability out of this package, I suggest you pay regular visits to I Work in Pages where Alexander Anichkin demonstrates the full versatility of this software.

Export to ePub

Apple recently issued a minor update which mostly affected Pages. Version 9.0.4 of iWork included a number of bug fixes — plus (and you'd be forgiven for not having noticed this) the ability to export a document directly to the ePub e-book format. And it just so happens that ePub is the format Apple has adopted for iBooks — so if you want to get your publications into the iBookstore, they'll have to be in ePub format.

As ePub is fast becoming the de facto standard for e-books, and is the focus of the work we're doing at WebVivant Press (not least because we publish via the iBookstore among other channels) I decided to check out how good a job Pages does when creating ePub files.

Best practice

Apple has produced a short document, 'ePub best practices for Pages' (ZIP file) that contains a number of predefined paragraph styles, such as Title, Subtitle, Author, Chapter Title etc. There are about 15 that will be of interest to e-book producers. That's a little skimpy, but you can always define your own.

As we’ve discussed before, working with paragraph styles is the key to creating successful e-book files.

As suggested in the Apple guide, I deleted the text in its sample document and saved the file as a template. I then opened a new document using this template and pasted in the text from my novel, Lady Caine. I reformatted the text using just a few of these basic styles. The bulk of the book used just Chapter Title and Body styles. I named the file 'Lady Caine - basic styles', then exported it as an ePub document.

Here's how it looked in Adobe Digital Editions:

The first thing to notice is that the e-book has a table of contents. That tells me that Pages has cleverly split the text into separate files, one per chapter. It does this based on the table of contents set-up in your Pages document. This is very smart and makes for more standards-compliant ePub files.

The ePub unzipped

I unzipped the .epub file and checked the file hierarchy (right), which confirmed my suspicions about the separate chapter files.

Here's the OPF file (named epb.opf in this case):

<?xml version="1.0" encoding="UTF-8"?>
<package unique-identifier="BookId" version="2.0" xmlns="http://www.idpf.org/2007/opf">
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
        <dc:title>Lady Caine - basic styles</dc:title>
        <dc:creator opf:role="aut">Steve Mansfield-Devine</dc:creator>
        <dc:contributor opf:role="bkp">Pages v4.0.4</dc:contributor>
        <dc:date>2010-08-28</dc:date>
        <dc:subject>Fiction &amp; Literature</dc:subject>
        <dc:identifier id="BookId">07CBB607-5854-4D85-9905-9303471CA34E</dc:identifier>
        <dc:language>en</dc:language>
    </metadata>
    <manifest>
        <item id="cover" href="cover.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-1" href="chapter-1.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-2" href="chapter-2.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-3" href="chapter-3.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-4" href="chapter-4.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-5" href="chapter-5.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-6" href="chapter-6.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-7" href="chapter-7.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-8" href="chapter-8.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-9" href="chapter-9.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-10" href="chapter-10.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-11" href="chapter-11.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-12" href="chapter-12.xhtml" media-type="application/xhtml+xml"/>
        <item id="chapter-13" href="chapter-13.xhtml" media-type="application/xhtml+xml"/>
        <item id="stylesheet" href="css/book.css" media-type="text/css"/>
        <item id="ncx" href="epb.ncx" media-type="application/x-dtbncx+xml"/>
    </manifest>
    <spine toc="ncx">
        <itemref idref="cover" linear="yes"/>
        <itemref idref="chapter-1" linear="yes"/>
        <itemref idref="chapter-2" linear="yes"/>
        <itemref idref="chapter-3" linear="yes"/>
        <itemref idref="chapter-4" linear="yes"/>
        <itemref idref="chapter-5" linear="yes"/>
        <itemref idref="chapter-6" linear="yes"/>
        <itemref idref="chapter-7" linear="yes"/>
        <itemref idref="chapter-8" linear="yes"/>
        <itemref idref="chapter-9" linear="yes"/>
        <itemref idref="chapter-10" linear="yes"/>
        <itemref idref="chapter-11" linear="yes"/>
        <itemref idref="chapter-12" linear="yes"/>
        <itemref idref="chapter-13" linear="yes"/>
    </spine>
    <guide>
        <reference type="text" title="Title Page" href="cover.xhtml"/>
    </guide>
</package>

A few observations.

First, it has created an appropriate 'creator' entry, presumably because I used the Author paragraph style for my name.

Pages has also created a unique identifier, which is important, although I would want to hack this to use the ISBN instead. The date given is the date the file was created and I'd want to change this to the official publication date. And I'd want to add publisher details.

In fact, I'd probably want to make a number of changes to this file, just to ensure it matches our standard approach to ePub packages. For example, even though I entered a number of keywords into Pages' 'info' panel, the software didn't create any keyword entries in the metadata section.

So I'd end up unzipping the ePub file, making the changes and zipping it up again, as described in this earlier post. But that's only because I'm being picky.

The acid test

Now for the real test. I ran the ePub file through epubcheck 1.0.3. It passed with no errors reported.

I had less success adding a cover image to the start of the file. There is an option, when exporting, to use the first page as the cover image. Inserting a JPEG or PNG file on to the first page led to the creation of a relevant entry in the epb.opf file — but it was empty. Even exporting the sample file from Apple failed to produce a cover image when viewed in Adobe Digital Editions. I'll need to investigate this further, but it's not a big deal for us. We send cover images separately when supplying to the iBookstore and other e-book channels.

Quick and easy

To sum up, creating a standards-compliant ePub file from Pages is now very simple. While I might be picky about metadata, the ePub files output by Pages are well-formed and will be accepted without quibbling by the Apple iBookstore — which is rather the point.

Adding Pages to the publishing ecosystem created by the iBooks app, the iBookstore, the iPad and the iPhone means that Apple now has the entire process covered, from writing the book, through digital file creation, distribution and sales to reading on a mobile device. And the whole thing is relatively effortless.

Defining appropriate styles in your word processor or DTP software not only makes the production process faster, it helps avoid problems later, whatever technology you’re using to produce the final document (print or e-book). Although our workflow is largely centred around InDesign, what we’re about to discuss is highly relevant if you’re, for example, preparing a Word document to upload to Smashwords or plan to output an ePub file from iWork’s Pages.

There’s an important point here: you may be lucky and, depending on the software or service you’re using to create your ePub files, maybe be able to achieve the formatting you want without defining lots of styles. But by using a workflow based around defined styles, with no formal formatting, you not only give yourself the best possible chance of success, you also improve compatibility between various publishing media and channels. What this means is that from a single file, you can publish print versions via a Print On Demand (POD) service such as Lulu or CreateSpace, e-books via Smashwords, the iBookstore and the Amazon Kindle … in fact, your choice is pretty much unlimited and you don’t have to keep messing with the document to tweak it for each channel.

What’s a style?

First, let’s make sure we’re on the same page. What is a paragraph style? (We’ll also touch on character styles, but they’re a little less critical.)

A style is a named configuration that controls the format of a paragraph of text. By defining a style, you can set the font, type size, margins, indents, line spacing, space above and below the paragraph and a large number of other characteristics. It’s useful because you can apply all these formatting characteristics in a single action simply by selecting the style — either by selecting it from a menu or (if you’re smart) by assigning a hot-key to it.

As part of your workflow, you should create a document template containing all the paragraph styles you’re likely to need. You insert your manuscript text into the template and go through it selecting the appropriate paragraph style for each section of text.
So, for example, we have a Word template in which hitting Shift-Alt-B selects the style ‘TextBody’. Hitting Shift-Alt-J selects ‘TextBodyJustified’ — which happens to be the same as TextBody except that the first line is not indented.

Here’s Word 2008 open with the manuscript of my novel Lady Caine. The current paragraph is using TextBody style as you can see from the Styles section of the palette.

And while this isn’t going to be a tutorial on how to use Word’s styles per se, here’s a screengrab of the style editing dialogue box.

Defining paragraph styles is useful for all kinds of wordprocessing tasks. You can format an entire document with just a few keystrokes.
For e-books, however, it’s essential. The reason for this is that, during the conversion process to the ePub format, the information in the paragraph style definitions is used to create the CSS style sheet for the book (remembering that ePub largely consists of web-like HTML pages, plus a style sheet and some other meta-information files).

As a general rule, only information contained in defined styles is transferred to the ePub. Manual styling is ignored. Let’s assume your TextBody style is ranged left. If you manually centre a section of text that is designated as TextBody, you’re likely to find that it comes out ranged left in the e-book. To be safe, every bit of formatting you do should be achieved with defined styles — don’t format anything manually.

Space is important

In addition to formatting the text within a paragraph, you also need to pay attention to the space around it. For example, it’s common to leave a linespace between sections of text within a chapter, such as when a major scene change occurs in a novel. Unfortunately, e-book readers generally ignore blank lines. If you want to space out text, you need to do it with paragraph styles. For this reason, we’ve defined a paragraph style called TextBreak which is defined with generous space above and below the paragraph. We then apply this to a line that contains only an asterisk.

Let’s take another example — the title page. Here’s the text from the title page of Lady Caine as it appears on the InDesign layout:

Now, if you were preparing this only for print, you might type that text as:

The Outside Lomcovak Club presents:
<blank line>
Lady Caine
<blank line>
by
<blank line>
Steve Mansfield-Devine
<etc…>

You can’t do that with an e-book. If you did, the lines would run together as:

The Outside Lomcovak Club presents:
Lady Caine
by
Steve Mansfield-Devine

The way to sort this problem is to use several paragraph styles. Here’s the text again with the paragraph styles used in brackets:

The Outside Lomcovak Club presents: [TitlePageSeriesTitle]
Lady Caine [TitlePageBookTitle]
by [TitlePageSubTitle]
Steve Mansfield-Devine [TitlePageAuthor]
WebVivant Press[TitlePageText]
www.webvivantpress.com[TitlePageText]

The way this achieves the necessary spacing is that these styles are set to having a certain amount of space above and below the paragraph. The TitlePageBookTitle style, for example, is defined with 0.4233cm above and below the paragraph.

When we output from InDesign to ePub, the defined styles are written to the template.css file that is part of the ePub package. Here’s how the TitlePageBookTitle format looks in the template.css file:

p.titlepagebooktitle {
    font-family: serif;
    line-height: 1.25em;
    font-size: 1.33em;
    margin-bottom: 0.75em;
    margin-top: 0.75em;
    text-indent: 0.00em;
    margin-right: 0.00em;
    margin-left: 0.00em;
    text-align: center;
    font-weight: bold;
    font-style: italic;
    color: rgb(0,0,0);
}

It has a defined a class ‘titlepagebooktitle’. You’ll notice that the space above and below the paragraph is converted to margin-top and margin-bottom settings. (You’ll also notice that there’s no specific font defined for this style other than the generic ‘serif’ — more about that in a future blog.)

Here’s the entire HTML file for the title page — note how the paragraph styles are applied as classes.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Title_page</title>
        <link href="template.css" rel="stylesheet" type="text/css" />
        <link href="page-template.xpgt" rel="stylesheet" type="application/vnd.adobe-page-template+xml" />
    </head>
    <body>
        <div id="title-page">
            <div class="story">
                <p class="titlepageseriestitle">The Outside Lomcovak Club presents:</p>
                <p class="titlepagebooktitle">Lady Caine</p>
                <p class="titlepagesubtitle">by</p>
                <p class="titlepageauthor">Steve Mansfield-Devine</p>
                <p class="titlepagetext">WebVivant Press</p>
                <p class="titlepagetext"><a href="http://www.webvivantpress.com">www.webvivantpress.com</a></p>
            </div>
        </div>
    </body>
</html>

This isn’t specific to InDesign. If you’re using a service like Smashwords, which converts from Word (.doc) files, a similar thing happens.

In all probability, you’ll end up defining a lot of styles, so don’t do this on the fly — sit down and map out carefully how many different styles you need. We currently have around 50, which include three levels of headings for parts, sections and chapters, chapter subtitle, three types of crosshead, four styles for the copyright page, and so on.

The same principles apply to character styles. You use these when you want specific formatting to a word or a section of text but not the entire paragraph. Let’s say you want a few words in italics or bold, or in a different font (sans-serif instead of serif). You might be tempted just to hit Ctrl-B or the ‘bold’ button. And it might work. But to be safe, you should define character styles for all the formatting variants you want. We have character styles em, strong, url and others.

We’ve defined these styles in Word, because most of the proofreading and preparation is done in that package (we had issues with OpenOffice’s not-quite-perfect rendering of .doc files). We also use the Word file to create the Kindle version of the book. In effect, the book is designed, formatted and finalised in Word.

But because we use InDesign for creating ePub and press-ready PDF files, we’ve replicated all of the styles (using the same names) in InDesign. After flowing the text from the Word file into the InDesign, there’s not much work to do. With one Word file and its corresponding InDesign file we can output every edition of the book — print, ePub (mainly for the iBookstore but also sometimes Lulu), Kindle and, of required, PDF — with no changes at all to the formatting.

There is an extra trick. our e-book does not have to conform to the layout of your print edition (it won’t anyway because of the fluid nature of e-book files). You can alter the look of the e-book significantly simply by having a separate CSS file which you use to replace the one created by, say, InDesign. In fact, it’s a good idea to create a standard CSS file for all your books, to give them a consistent look and feel. We’ll come to that in another post.

In a future post, I’ll also look at how the latest version of Pages — part of Apple iWork — exports to ePub format, and the role that paragraph styles play in that process.

My first thought when I saw the Apple iPad and its iBooks app was, 'how do I get on it?'. That question has now been answered: Apple has opened up the iBookstore to everyone. But to take advantage of the opportunity, you need to be prepared.

First, sign up with Apple iTunes Connect. I get the impression that the sign-up process has been designed deliberately to put off casual wannabes. It's fairly detailed and demanding. For example, if you're not a US resident, you'll need an IRS ITIN - I explain here how we got ours.

Next, you'll need your book in ePub format. And you have to make sure it passes epubcheck with flying colours. I covered a lot of this in my three-part post about fixing InDesign CS3's ePub issues.

Apple wants a separate cover image, not one embedded in the ePub file, so have a hi-res version ready.

Your book also needs an ISBN. For Make Do & Cook and Lady Caine, we decided to create iBookstore editions with their own ISBNs.

You'll be asked to enter various metadata, including a book description. You'll also be asked about the print version of the book (price, number of pages). If you don't have a print version, you need to guess at what it would be like. Strange.

The iTunes Connect website provides forms for uploading the files. But Mac users have a better option. You can download the iTunes Producer software which holds your hand as you go through the various stages of providing information for your book (metadata, pricing, territories, etc) and ensures that all the ducks are in a row before you upload. I highly recommend using this as it helps you understand what information you'll need to have at hand.

Once uploaded, the book needs to be approved. This took about 48 hours for our titles. We then sold our first e-book within a few hours, before we'd even had time to announce that the iPad editions were available.

« Part 1 - Introduction
« Part 2 - Fixing the content.opf file 

In this final instalment, we look at editing the table of contents file, toc.ncx, part of the ePub file package, as well as taking a quick look at CSS. Our examples are based on the files created for our recent free e-book, Make Do & Cook: Savvy Shopping.  

Editing toc.ncx 

The toc.ncx file is the publication's table of contents. Like the content.opf file we dealt with in the previous post, it too is an XML file which you can edit with any plain-text editor (such as Notepad).

And also like the content.opf file, we've got two jobs to do here - fix InDesign CS3's errors and improve slightly on its output. The file produced by InDesign fails to meet the requirements laid out here.

Here's what the toc.ncx file for Savvy Shopping, produced by InDesign CS3, looks like (as before, the bits in square brackets are my comments, not part of the file):

<ns:ncx xmlns:ns="http://www.daisy.org/z3986/2005/ncx/">
  <ns:navMap>
    <ns:navPoint>
      <ns:navLabel>
        <ns:text xmlns:ns="http://www.daisy.org/z3986/2005/ncx/">Cover</ns:text>
      </ns:navLabel>
      <ns:content src="Cover.html"/>
    </ns:navPoint>
    <ns:navPoint>
      <ns:navLabel>
        <ns:text xmlns:ns="http://www.daisy.org/z3986/2005/ncx/">Title_Page</ns:text>
      </ns:navLabel>
      <ns:content src="Title_Page.html"/>
    </ns:navPoint>
    [... repeated navPoint tags for subsequent chapters ...]
  </ns:navMap>
</ns:ncx>

All entries use the ns: namespace. There is an all-encompassing <ncx> tag. Inside that is a <navMap> tag. And inside that are repeated <navPoint> tags - one per chapter.

Inside each <navPoint> tag there's a label tag which provides text for contents table or 'spine' features in e-readers. For example, this text provides the links in the left-hand column in this example, using Adobe Digital Editions:

InDesign produces this table of contents if you use its 'book' feature, where each section is created as a separate file. You then output the ePub document from the book window.

Actually, if you look closely, you'll see that the contents of the <navLabel> tags don't quite match the chapter names in the screenshot above (which is of the amended e-book). InDesign replaces spaces with underscores. So the one bit of tidying up we do with the toc.ncx file is to put the spaces back. However, don't do this with the names in the <content> tags, such as:

<ns:content src="Title_Page.html"/>

(These are self-terminating tags, in that there is no separate closing tag, but there is a forward slash at the end). The contents of these tags are filenames and have to remain unaltered.

Compliance issues

The remaining tasks are to make the toc.ncx file standards compliant.

First, we edit the opening <ncx> tag. This needs the attribute version="2005-1", and you can also take the opportunity to add the appropriate language setting (see the previous post for more info). So our version looks like this:

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

Next, we add two new sections, immediately after the <ncx> tag and before the opening <navMap>.

<ns:head>
    <ns:meta name="dtb:uid" content="{unique-ID}"/>
    <ns:meta name="dtb:depth" content="1"/>
    <ns:meta name="dtb:totalPageCount" content="0"/>
    <ns:meta name="dtb:maxPageNumber" content="0"/>
</ns:head>
<ns:docTitle>
    <ns:text>{book-title}</ns:text>
</ns:docTitle>

Within the <head> section, the first two items are mandatory. The content of the unique ID part should match the string you used in the content.opf file - eg, an ISBN.

The depth setting reflects how many branches there are on the tree structure of the table of contents. If you have a simple list of chapters, then you use 1. If you have sub-sections nested inside chapters, you'd use 2. If there are sub-sections of sub-sections, then it's 3, and so on.

The totalPageCount and maxPageNumber apply only to documents in which rigid pagination is enforced. This doesn't apply to the vast majority of e-books, where text is designed to be fluid. So you could leave out these entries or set them to 0, as we have here.

Obviously, you'll need to put your own book's title in place of {book-title}.

The remaining step is more tedious and time-consuming. Every opening <navPoint> tag should have two attributes, id and playOrder.

The id attribute is a unique identifier for the specific <navPoint> tag. It should be simple, with no spaces or punctuation. A version of the chapter title would do fine. So, if this is the <navPoint> tag for Chapter 1 of your book, an id of chapter1 would work fine.

The playOrder attribute simply specifies the order of the chapters. So, in our example above, we would have:

<ns:navPoint id="cover" playOrder="1">
   <ns:navLabel>
      <ns:text xmlns:ns="http://www.daisy.org/z3986/2005/ncx/">Cover</ns:text>
   </ns:navLabel>
   <ns:content src="Cover.html"/>
</ns:navPoint>
<ns:navPoint id="titlePage" playOrder="2">
   <ns:navLabel>
      <ns:text xmlns:ns="http://www.daisy.org/z3986/2005/ncx/">Title Page</ns:text>
   </ns:navLabel>
   <ns:content src="Title_Page.html"/>
</ns:navPoint>

With these changes, your ePub e-book should sail through epubcheck with flying colours.

The CSS file

There's also a CSS file in the ePub package, called template.css. This provides the styling for the book, including setting fonts. This is a whole subject in itself, but there are just a couple of observations to be made here.

InDesign CS3 doesn't generally embed the fonts in the ePub package. It creates a CSS file that assumes the fonts specified in the InDesign paragraph and character styles will be found on the user's machine. That ain't necessarily so.

Unfortunately, it doesn't specify 'fallback' fonts should the user not have the fonts you wanted. It's worth fixing that.

One way is to edit the template.css file for each book. Open it in a text editor. Ignore the opening sections which start, @font-face. But in the main section, where the styles are defined for each paragraph style, add a fallback font wherever you see 'font-family' used.

For example, InDesign produced the following for Savvy Shopping:

p.headings-titlepagebooktitle {
    font-family: "Adobe Garamond Pro";
    [... other stuff ...]
}

There's no fallback should users not have Adobe Garamond Pro on their machines. So we change this to:

    font-family: "Adobe Garamond Pro", serif;

In that case, the user's machine will use its default serif font, whatever that may be. Don't be tempted into entering long lists of your favourite fonts. Just use serif, sans-serif, cursive or monospace as appropriate. (You could use 'fantasy' too, but that could produce some nasty effects.)

We've eased this burden by creating an all-purpose CSS file for all our books. We created an InDesign document that uses all the paragraph and character styles we've defined for our print books. Then we modified these styles, selecting very common fonts (Times New Roman for serif, Arial for sans-serif), output an ePub package and then edited the template.css file, making slight adjustments and adding the generic fallback fonts.

Now, whenever we output an e-book from InDesign, we simply replace the template.css file with our standard one. That means we can have any fonts and font sizes in the InDesign layout we want, giving us great flexibility in the design for the print version. These are all replaced with settings more appropriate to e-books simply by replacing the template.css file.

Resources:

• Open Packaging Format (OPF) 2.0 v1.0: Recommended Specification September 11, 2007 - essential reading if you want to understand the format. 
• Epub Format Construction Guide by Harrison Ainsworth - a good overview of the file formats.
• Specifications for the Digital Talking Book - in spite of the title, has some excellent general information, especially on things like the toc.ncx file.
• epubcheck - invaluable Java-based tool for checking your ePub files, even if its error messages can be infuriatingly ambiguous or misleading at times.

« Part 1 - Introduction
« Part 2 - Fixing the content.opf file