WebVivant

Fixing Adobe InDesign CS3's ePub files (part 3)

The third part of our article of correcting InDesign CS3's ePub files looks at the toc.ncx file and CSS

« 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 

Savvy ShoppingThe 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:

Savvy Shopping ADE

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:

 

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

 

Fixing Adobe InDesign CS3's ePub files (part 2)

Correcting errors and adding new entries in the content.opf file to make e-books created with InDesign CS3 more compliant

« Part 1 - Introduction
» Part 3 - Fixing the toc.ncx file and CSS

In this second instalment, we look at editing the content.opf file - part of the ePub file package. Our examples are based on the files created for our recent free e-book, Make Do & Cook: Savvy Shopping.

Editing content.opf

TSavvy Shoppinghe content.opf file is the main metadata file describing the publication and its overall structure. It's an XML file, and if you don't know what that is, you may want to do some Googling on the subject first. The key thing to know is that XML uses tags inside angle brackets, much as HTML does. And like HTML, these tags come in pairs, with an opening tag and a closing one that includes a forward slash. Here's a typical line from the content.opf file:

<dc:identifier id="wvp-id" opf:scheme="ISBN">1441493379</dc:identifier>

This is the <identifier> tag. Its name is prefixed with 'dc:' (which stands for Dublin Core - a metadata standard). Such prefixes are known as namespaces, and if that term is new to you too, then it's time for more Googling. This tag also has attributes, additional bits of information that go inside the tag.

As content.opf is just a plain text file, you can open it with your favourite text editor. Make sure you use a text editor and not a word processor - you want something that can save ordinary text files. I use TextWrangler and Komodo Edit on the Mac. On Windows, you could use Notepad. Linux users are spoiled for choice (Kate was always my favourite).

Here are the highlights from the content.opf file as produced by InDesign (the bits in square brackets are my notes, not part of the file:

<?xml version="1.1"?>
<package xmlns="http://www.idpf.org/2007/opf" version="2.0">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:title>Make Do &amp; Cook: Savvy Shopping</dc:title>
    <dc:creator>Patricia Mansfield-Devine</dc:creator>
    <dc:subject>shopping</dc:subject>
    <dc:subject>cooking</dc:subject>
    [... ditto for several other subjects ...]
    <dc:description>Shop the smart way so you can enjoy delicious and nutritious meals on the smallest budget.</dc:description>
    <dc:rights>Copyright Patricia Mansfield-Devine. All rights reserved.</dc:rights>
  </metadata>
  <manifest>
    <item id="ncx" href="toc.ncx" media-type="text/xml"/>
    <item id="cover" href="Cover.html" media-type="application/xhtml+xml"/>
    <item id="mdc-cover-front-fmt-jpeg" href="images/MDC_Cover_Front_fmt.jpeg" media-type="image/jpeg"/>
    <item id="mdc-savvyshopping-cove-fmt-jpeg" href="images/MDC_SavvyShopping_cove_fmt.jpeg" media-type="image/jpeg"/>
    <item id="title-page" href="Title_Page.html" media-type="application/xhtml+xml"/>
    <item id="mdc-cover-front-fmt-jpeg-1" href="images/MDC_Cover_Front_fmt.jpeg" media-type="image/jpeg"/>
    <item id="mdc-savvyshopping-cove-fmt-jpeg-1" href="images/MDC_SavvyShopping_cove_fmt.jpeg" media-type="image/jpeg"/>
    <item id="copyright-page" href="Copyright_Page.html" media-type="application/xhtml+xml"/>
    <item id="mdc-cover-front-fmt-jpeg-2" href="images/MDC_Cover_Front_fmt.jpeg" media-type="image/jpeg"/>
    <item id="mdc-savvyshopping-cove-fmt-jpeg-2" href="images/MDC_SavvyShopping_cove_fmt.jpeg" media-type="image/jpeg"/>
    [... ditto for all the other chapters ...]
    <item id="css" href="template.css" media-type="text/css"/>
    <item id="pt" href="page-template.xpgt" media-type="application/vnd.adobe.page-template+xml"/>
  </manifest>
  <spine toc="ncx">
    <itemref idref="cover"/>
    <itemref idref="title-page"/>
    [... ditto for the other chapters ...]
  </spine>
</package>

The metadata section was created by InDesign based on the metabata we entered in the ID file itself. We also used ID's 'book' feature, where each chapter or section of the book is kept in a separate file. This creates a proper table of contents in the ePub file.

There are two problems with this file. First it's missing certain elements that are needed to make the file fully standards compliant. This is the source of that worrying message: 'The document appears to have minor errors that might cause it to be displayed incorrectly'. And second, there are additional elements we would like in there.

Compliance issues

We're going to be using some XML namespaces not already referred to in the document. So our first job is to edit the <metadata> tag on line 2. Here's how it ends up:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:opf="http://www.idpf.org/2007/opf">

The opening <package> tag should contain an element called 'unique-identifier'. This is actually a pointer to the <identifier> tag we met earlier. As you can see, that tag included the attribute id="wvp-id". So in this case, the <identifier> tag has an id of 'wvp-id'. You can choose whatever value you want for the id (ours is short for WebVivant Press ID), but it pays to be consistent. All of our books will use 'wvp-id'.

So, we edit the opening <package> tag to read:

<package unique-identifier="wvp-id">

And then we add the <identifier> tag to the metadata section. It can come anywhere in that section, so long as it's between the metadata opening and closing tags.

<dc:identifier id="wvp-id">{unique-id}</dc:identifier>

You need to replace the {unique-id} bit with something, well, unique. Unique, that is, to this book. If your book has an ISBN, you could use that, in which case you can also add the attribute, opf:scheme="ISBN". Here's what the tag looks like with an ISBN:

<dc:identifier id="wvp-id" opf:scheme="ISBN">1441493379</dc:identifier>

Because Savvy Shopping doesn't have an ISBN, we went with:

<dc:identifier id="wvp-id">WVP201002-Savvy-Shopping</dc:identifier>

Further down the file, in the <manifest> section, InDesign assigns the wrong mimetype to the 'ncx' table of contents entry. It says:

<item id="ncx" href="toc.ncx" media-type="text/xml"/>

In fact, it should be:

<item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml"/>

There's one final problem. In the manifest section, you'll see that each chapter file gets its own entry. The same goes for the images used in the book. Now, Savvy Shopping has only two images - one used as the cover and one used inside. But references are created to these images with every chapter. Here's what the lines look like for the first two 'chapters' - the cover and the title page:

<item id="cover" href="Cover.html" media-type="application/xhtml+xml"/>
<item id="mdc-cover-front-fmt-jpeg" href="images/MDC_Cover_Front_fmt.jpeg" media-type="image/jpeg"/>
<item id="mdc-savvyshopping-cove-fmt-jpeg" href="images/MDC_SavvyShopping_cove_fmt.jpeg" media-type="image/jpeg"/>
<item id="title-page" href="Title_Page.html" media-type="application/xhtml+xml"/>
<item id="mdc-cover-front-fmt-jpeg-1" href="images/MDC_Cover_Front_fmt.jpeg" media-type="image/jpeg"/>
<item id="mdc-savvyshopping-cove-fmt-jpeg-1" href="images/MDC_SavvyShopping_cove_fmt.jpeg" media-type="image/jpeg"/>

The second and third lines refer to the images. These lines are fine and need to be kept. But lines 5 and 6 are references to the same images (the 'href' parts are identical) even though the tags get new IDs (by having the -1 suffix added). Indesign did the same with all the other chapters. This is unnecessary and may make e-readers report an error. Certainly, epubcheck doesn't like it. So we deleted all the superfluous image references, keeping only the first reference to each image.

Adding lines

That's it for making the file compliant. Now to add some additional features.

The next step is to add lines to the <metadata> section. Like I said, InDesign has already created a number of entries there. We add:

<dc:publisher>WebVivant Press</dc:publisher>
<dc:language>en-GB</dc:language>
<dc:date xsi:type="dcterms:W3CDTF">{date}</dc:date>

Clearly, you'll want to use your own publisher name. The 'en-GB' entry is for British English. You could use en-US for American English or just en, assuming your book is in English.The contents of this tag need to comply with RFC 3066 (see http://www.ietf.org/rfc/rfc3066.txt).

You need to replace the {date} part with the publication date. For books, the most common formats are YYYY, YYYY-MM or YYYY-MM-DD. The acceptable date formats are defined by 'Date and Time Formats' at http://www.w3.org/TR/NOTE-datetime which is based on ISO 8601. We prefer to go with month and year, so the entry for Savvy Shopping looks like this:

<dc:date xsi:type="dcterms:W3CDTF">2010-02</dc:date>

The <creator> tag works as it is, but we add a little extra information - data that helps systems sort and store the document and what role the creator played in this case. So our tag looks like this:

<dc:creator opf:file-as="Mansfield-Devine, Patricia" opf:role="aut">Patricia Mansfield-Devine</dc:creator>

In the references below, you'll find lots more info about roles, and also the optional <contributor> tag.

Finally, in the <rights> tag we fix that copyright symbol problem by adding the &#169; entity, so it looks like this:

<dc:rights>Copyright &#169; Patricia Mansfield-Devine. All rights reserved.</dc:rights>

And that's it for the content.opf file. 

In the final part, we'll look at correcting the toc.ncx file and have a quick discussion about CSS.

 

Resources:

« Part 1 - Introduction
» Part 3 - Fixing the toc.ncx file and CSS

 

Fixing Adobe InDesign CS3's ePub files (part 1)

InDesign allows you to create ePub e-book files direct from your book's page layout. But it has its problems. Here's how to correct them

» Part 2 - Fixing the content.opf file
» Part 3 - Fixing the toc.ncx file and CSS

 

At WebVivant Press, we use Adobe InDesign CS3 for producing both print books and ePub format e-books. InDesign (ID) is a great piece of software for laying out magazines and books. And for creating e-books it's ... well, broken.

Savvy ShoppingWhen you use the 'Export to Digital Editions' option from InDesign the resulting ePub file (generally) opens fine in Adobe Digital Editions (ADE). However, if you look at the file info from within ADE, you'll probably see the message: 'The document appears to have minor errors that might cause it to be displayed incorrectly'. This is a message you come to fear greatly when creating e-books.

So this post is about how we dealt with these 'minor errors'.

Now, it's possible that CS4 does a much better job. But Adobe's prices are such that upgrading would soak up a lot of book profits. And I suspect we'd still end up tweaking the e-book files by hand. (If there are any InDesign CS4 users out there who can tell us how well it deals with the issues outlined below, we'd love to hear from you.)

Running into problems

I actually encountered these minor errors the first time I output an ePub file from InDesign. The book wouldn't load into ADE. It turned out that the 'minor' errors were, in fact, fatal. Then I discovered that removing a copyright symbol from the metadata of the ID file fixed the problem. This shouldn't be so: ePub files created with the normal, default utf-8 encoding are perfectly capable of including the copyright symbol, using the &#169; HTML entity. But removing it seemed to work and I got on with my life.

Then I noticed that, while the files would load, there was still a warning about 'minor errors'. Also, ADE showed the publisher as 'unknown'. ID has no metadata field where you can enter the publisher's name.

I think the problem is that CS3 is simply out of date and is producing files to an older, obsolete standard. Whatever the source of the problems, I decided to fix them by hand.

Opening the ePub file

These notes are based on the ePub file we created recently for a free e-book - Make Do & Cook: Savvy Shopping.

As I discussed in a previous post, an ePub file is just a zip file. You can unzip it and play with the contents. The tweaks I discuss here are those I used to fix ID CS3-produced files, but may also help with files produced by other means.

One way of testing corrected ePub files is simply to load them into ADE or some other e-book reader and see if there are any complaints.

A much better method is to use epubcheck, a free utility that tests your ePub file for compliance with the current standard. It's not without its own issues: epubcheck has a habit of issuing annoyingly vague error messages. For example, you might be told that a section of the file has 'missing elements' but are given no clue as to what these are (presumably, epubcheck knows because it's recognised that they're missing).

It is possible to run epubcheck as a web-based app, but the easiest method is to run it from the command line. It's Java-based, so should run on pretty much any platform. As discussed in Zipping ePub files, I've created a short shell script for zipping the various files back into an ePub package, so my workflow is:

  1. Unzip the ePub file created by InDesign.
  2. Edit the content.opf and toc.ncx files.
  3. Zip up the files into an ePub package again using a single command. This leaves the unzipped files still available if further editing is needed.
  4. Test using epubcheck. If this fails, go to 2. If it succeeds, you're done.

So, if you're ready to start playing, copy your ePub file into a new directory all by itself (easier to see what you're doing this way) and unzip it. Inside, you'll find a file called 'mimetype' and two sub-directories - META-INF and OEBPS. (If the ePub file was created by some method other than outputting from InDesign CS3, the file structure, and even some filenames, may be different, but the principles will be the same.)

Fixing ID CS3's ePub shortcomings involves editing two files in the OEBPS directory - content.opf and toc.ncx. In the next two parts, we'll look at editing those files and also take a quick look at the CSS file.


Resources:

» Part 2 - Fixing the content.opf file
» Part 3 - Fixing the toc.ncx file and CSS

 

Joining forces

A new group for authors in France's Grand Ouest region - Brittany, Normandy and the Pays de la Loire

Grand Ouest AuthorsWriting can be a lonely business. If you're lucky - which I am - you have a creative partner who can act as a sounding board and critic. Even so, there are times when you want to get away from the computer screen and seek the company of other writers.

And when you've produced your book, there's also the small business of selling it. Even if you have a contract with a mainstream publisher, unless you're an A-list writer, you're likely to find that you're largely on your own when it comes to promoting the book. That's why so many writers have decided they might as well self-publish.

Many writers tackle this problem by getting out of the house, visiting libraries, bookshops and anywhere that might take a few copies of their book to sell. They participate in literary and cultural events. They network.

This is tougher if the language in which you write isn't that of the country in which you live.

That's how Grand Ouest Authors was born. The group was inspired by an article in The Author, the house journal of the Society of Authors, which told of a group of local authors joining forces to create a presence that one alone couldn't muster. They organised group book signings, took joint stands at events and generally co-operated to make themselves more visible.

That's the aim with Grand Ouest Authors. It's for English-language writers living in the Brittany, Normandy and Pays de la Loire regions of France.

We've already created a web presence. Each author gets a profile page. And there's a page for each book the author has in print. Each book is also included in the GOA shop. We have a group blog and a forum, too.

It's all free. The idea is co-operation, communication and community. The aim is to move from a virtual presence to a real-world one, participating in local events and acting as a group to promote and sell our books. That's why we've made it regionally based.

We're also exploring ways in which WebVivant Press might act as an imprint for the group, but perhaps on a collective, rather than publisher-author, model.

If you're an English-language author in the Grand Ouest, do get in touch » 

 

Zipping ePub files

The ePub file format is just a zip file. But you have to be careful how you construct it

The ePub file format can be an intimidating beast. But in essence it's quite simple - a bunch of XHTML pages plus accompanying metadata in XML files all bundled up in an ordinary zip file.

That's good news because it means you can unzip the file, hack away at the contents (as we'll be seeing in the next post, about fixing Adobe InDesign CS3's ePub shortcomings) and then just zip it up again.

But there is a gotcha. The e-book readers that work with ePub files can be very picky about how the zip file is put together. And the ePub specification itself is highly specific. So here are a couple of quick tips on how to avoid problems.

I use OS X and Linux, but Windows users should be able to adapt these comments to their own environment.

Unzip the file

Clearly, your first step is to unzip the file. Linux users, being the geeks they are, will naturally head straight for the command line to do this, and quite rightly so. Mac users are accustomed to unzipping files by double-clicking on them, but this is unlikely to work with a file that has the .epub extension - you're more likely to end up opening the file in your favourite e-reader. Ditto for Windows users.

You could use a utility like StuffIt Expander. But given that much of the rest of what I'm discussing here will be done from the command line, you might as well go ahead and open a terminal window.

Let's assume your ePub file is called MyEbook.epub. For the sake of simplicity, you might want to have this sitting in a folder by itself.

From the command line, cd to the folder holding the file. Then simply:

unzip MyEbook.epub

The zip file will spew its contents into the folder. Hack away to your heart's content until you're ready to zip up the file again.

Zip the ePub file

Among the files you'll have found among the contents of the ePub document is one called mimetype. This is the critical one.

E-book readers require that the mimetype file is the first one in the zip document. What's more, to be fully compliant, this file should start at a very specific point - a 30-byte offset from the beginning of the zip file (so that the mimetype text itself starts at byte 38).

If this sounds intimidating, don't worry. It's actually quite easy to achieve if you're careful.

At this point, you might want to move the original MyEbook.epub file out of the way (or delete it, if you're working with a copy, which is a sensible thing to do). To start creating your ePub file, use the following:

zip -X MyNewEbook.epub mimetype

I've given the new ePub file a different name in case you ignored my advice about moving the original out of the way.

The key element here is that -X flag. It tells zip to ignore file 'extras' - metadata such as permissions, etc. If you don't use this flag, the contents of the mimetype file will be placed at the wrong position in the zip file. E-book readers may complain that the file contains formatting errors. And tools such as epubcheck (more of that in the next post) will tell you that the ePub file has the wrong mimetype - even when it has the correct mimetype, just in a slightly incorrect position. That can lead to all sorts of confusion.

You can then go ahead and add the rest of the files to the MyNewEbook.epub zip/epub file you've just created. Which files you need to add will depend on how the ePub file was put together in the first place.

I use InDesign CS3 for creating ePub files. These contain the mimetype file plus two directories - META-INF (containing one metadata file) and OEBPS (containing the book files themselves, images, more metadata etc).

So I use the commands:

zip -rg MyNewEbook.epub META-INF -x \*.DS_Store

zip -rg MyNewEbook.epub OEBPS -x \*.DS_Store

Some explanations necessary here. We start each line with two flags:

-r    (recursive)

This means move down through any directories/folders recursively, ensuring that everything in the folders specified gets included

-g    (grow file)

This means add to an existing zip file rather than creating a new one or overwriting an existing one. If you don't use this flag, the file you started with the mimetype file, above, will get overwritten.

-x \*.DS_Store    (exclude)

This is just for Mac users. It tells zip to ignore the .DS_Store hidden file that is found in most Mac OS X folders.

And that's it. To make things easier, I've put these commands into a shell script which is in my PATH for Bash sessions.

If you're uncomfortable with the command line, and still prefer to use GUI-based zip utilities, the above should give you enough information on which to make sensible choices about settings.

 

 

More e-book trouble for Amazon

Two more publishers are dictating higher e-book prices, deserting Amazon's $9.99 model

Let the tablet wars commence

Google has an ideal tablet operating system and a huge investment in e-books. It could give the Apple iPad a run for its money, at least in the publishing world

The iPad effect - loosening Amazon's grip

The book trade has long complained about Amazon's death-grip on prices and margins. Maybe the iPad has changed the balance of power

Tags:

Why the iPad may be good news for self-publishers

And, perhaps, the death knell of Amazon's Kindle

Creating e-books - part 2

In Part 1 we covered e-book formats, services and a production workflow. Now let's look at a few issues concerned with actually creating the files.

Creating e-books - part 1

The e-book is an important format - but how do you go about creating one?

E-books - the slow revolution

It's been fun dismissing the e-book as a gimmick. Now we must embrace it as the format of the future. For self-publishers, it's time to put the e-book first

What's a banker worth?

Is there anyone who really believes that bankers are brilliant people worth paying huge salaries?

Tags:

A short walk in the snow

A few photos of the local landscape

A guide to French drivers

Useful tips about driving in France for Brits and other ex-pats

Tags: