A while back I wrote how Adobe's InDesign CS3 software could directly ouput ePub e-book files, but how they needed a little work. Now I've had a chance to play with the current version of the software - CS5 - and have had a chance to evaluate its handling of ePub exports.

The good news is that it's much better. The bad news is that you're still going to have to do a little work on the final files if you want your ePub documents to be fully standards compliant.

For this test, I decided to create a test ePub e-book for one of our forthcoming releases. Twisting Tales is a stunning collection of short stories by Clare Le May, which WebVivant Press will be publishing in print, Kindle and iBooks editions.

As it consists of short stories, it's important that the story titles show up in the table of contents. As usual, then, we created the InDesign document using the software's 'book' feature. Each chapter, and sections such as title page, copyright page and so on, is created as a separate document, managed via the book. To create an ePub file, all you need do is select the 'save as ePub' option:

Now, if you're eagle-eyed, you'll have noticed that the menu above is in French. That's because I was using a French friend's Mac to run this test. But even a basic grasp of the language should be enough for you to see that there's an 'Export book in ePUB format...' option.

This brings up a dialogue box with three tabs. I won't go through all the options - I dealt with many of them in the previous series of articles. However, it's worth pointing out a couple of options that have appeared since CS3.

There are now two fields that allow you to input important information. In my previous articles, I detailed how you need to have a unique ID (which appears in two places) and how it's desirable to be able to add metadata to the ePub files identifying the publsher. With the CS3 export, you had to hack the resulting files by hand. With CS5 that's no longer needed. The 'Ajouter une entrée pour l'éditeur' and 'Identificateur unique' fields allow you to enter a publisher (not 'editor' as you might think) and ID information. Here, we've used the ISBN number as the ID.

Running the latest version of epubcheck (v1.1) on the resulting ePub file produced just one error:

ERROR: Twisting Tales.epub/OEBPS/content.opf(2): date value '' is not valid. The date must be in the form YYYY, YYYY-MM or YYYY-MM-DD (e.g., "1993", "1993-05", or "1993-05-01"). See http://www.w3.org/TR/NOTE-datetime.

That's not bad, but it still needs fixing. There's always a chance that the Apple iBookstore - which insists on files passing epubcheck - might reject the file. It's possible that, somewhere, there's a metadata setting in the InDesign file that I've overlooked and which would fix this problem. If you know of one, please let me know.

In spite of this error, the file opens just fine in Adobe Digital Editions (ADE):

Note how the chapter headings have rendered fine in the contents listing on the left. These have been lifted from the filenames of the individual chapter files.

Also, note the image. Twisting Tales is enlivened by some beautiful illustrations by Angela Rozelaar - on the cover and one illustration starting each story. I placed these in the InDesign pages by creating a new paragraph style where the text was centred and there's a little space above and below the par. I then cut and pasted the images into these paragraphs. As you can see, the images exported fine and are suitably centred.

Now to the nitty-gritty of how well InDesign CS5 did, compared to CS3. In the previous series of articles I detailed how I would unzip the .epub document and tweak the content.opf and toc.ncx files, before zipping up the package again. How much of that work still needs to be done?

Content file - content.opf

The 'unique-identifer' attribute in the <package> tag is now properly inserted, thanks to that new field in the dialogue box. Certain schema information, which we've been entering as attributes in the <metadata> tag haven't been inserted by InDesign, but as epubcheck doesn't complain about its absence, maybe that's not a problem.

The publisher and identifier tags are there, again thanks to that extra field in the dialogue box. However, I would prefer it if the identifier tag also contained the attribute opf:scheme="ISBN", given that we're using the ISBN as the ID. This would need to be added by hand, but it's not the end of the world if it's not there.

There's a language tag - in this case it was:

<dc:language>en</dc:language>

I might have preferred en-GB for the value, but maybe that's splitting hairs.

The creator tag is similarly basic:

<dc:creator>Clare Le May</dc:creator>

A more complete and compliant version would be:

<dc:creator opf:file-as="Le May, Clare" opf:role="aut">Clare Le May</dc:creator>

The <manifest> section has the correct media-type attribute and didn't suffer the duplicate image references that CS3 insisted on inserting.

The one actual problem was the date tag. This was empty, thus: <dc:date/>

Once modified to show the publication date - <dc:date>2011-03</dc:date> - the ePub file validates fine. And given that the content.opf file needs to be opened and hacked in this way, you might as well go ahead and add the other stuff I've mentioned above.

Table of contents file- noc.ncx

Given that the toc.ncx file validates fine with epubcheck, you could always leave it alone. Indeed, CS5 has addressed nearly all the issues I mentioned with regard to the CS3 files. The only thing it does a little strangely is that, with the <navPoint> tags, it uses id="navpoint-1", id="navpoint-2" etc, rather than using the chapter titles for the navPoint ID. You'd probably need to be a purist to worry about this, though.

Conclusions

In summary, InDesign CS5 does a fine job of exporting to ePub - providing you set up some of the metadata information in the InDesign files themselves. If there's a way of fixing that date problem with ID CS5 metadata, then only a purist would feel the need to go in a hack the ePub files.

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.

All self-publishing authors should consider producing e-book versions of their work. In fact, there's a good argument to say that you should regard the e-book as the primary format these days. But how do you go about creating the e-book? Here's how we do it at WebVivant Press.

Which format?

The first question to ask yourself is, which e-book formats are you going to target? For my money, the main contenders are:

• ePub: This is emerging as a standard. The format is open source. In fact, it's basically a bunch of HTML files with XML wrappers neatly gathered in a zip file. Sony has now adopted this as the main format for its e-book readers, and most other e-readers can handle ePub. It's possible to wrap DRM around the file or leave it DRM-free. We've adopted this as the main format for WebVivant Press.
• Kindle: Amazon's e-reader doesn't support ePub. It uses Amazon's AZW format, which is essentially the Mobipocket .mobi format with DRM added. The current generations of the Kindle can also read PRC, plain-text and (in a still somewhat limited fashion) PDF files. Not making your book available for the Kindle would be somewhat short-sighted, whatever impact Apple's tablet computer, and its inevitable emulators, might have on the Kindle's future.
• PDF: Most e-readers can handle PDFs, as can all desktop and laptops PCs. However, PDFs are so easy to create, it's not worth considering PDF as a primary format - target one of the others and then crank out a PDF too.

There are other formats, including plain text, Word and RTF, but these are the most important.

How to publish

Next, let's consider how you publish your e-book. There are two aspects to this: 1) Creating the e-book file itself; and 2) Making it available to the buying public, handling orders etc.

You can create your own e-book file and make it available for download from your site. We're investigating this for WebVivant Press, using Google Checkout for handling orders. In the meantime, we've decided to use three services.

• Lulu: Our print books are produced via Lulu, so it makes sense to use the company for e-books too.
• Smashwords: This service creates e-book files in a variety of formats, including ePub, .mobi, PDF and others. The service is free but the company takes a cut of sales. It is setting up deals with all kinds of outlets and distribution channels, provides easy ways of creating coupons, allowing you to make special offers on your books, and generally seems like a vibrant company.
• Amazon Digital Text Platform (DTP): This is the service that allows you to create e-books for the Kindle. The downside of this service is that it's very US-oriented. If you live outside the US, the only payment option is cheque (or check, if you're American). Quite why Amazon can't pay we Europeans by bank transfer, the way Google does, is beyond me.

Designing the workflow

All of these services allow you to upload your book as a Word or RTF file. So, problem sorted. Except that that doesn't quite fit with our workflow.

With our first book, Lady Caine, we used a Word file to upload to Lulu. (My experiences with RTF over the years haven't been entirely happy. So RTF plays no part in this post. If you have experiences using RTF files, I'd be happy to hear about them.) But there were problems.

Although I used Lulu's own template for the page size we'd chosen, the text reflowed slightly, causing widows and orphans. It may have been a font issue, or the fact that the Word file was created from OpenOffice (more of which later). Either way, it was annoying. Besides which, word processor software isn't ideal for laying out books.

Our preference, then, and the method we use now, is to layout the print version using Adobe InDesign. This gives us much finer control over the appearance of the book. And from InDesign, we can easily create PDF and ePub versions. In fact, the ePub versions produced this way are superior to those we get from Word files, as we'll see in Part 2. Lulu accepts ePub files for its e-book service, so we can use the same InDesign file for the print version, the Lulu e-book and PDF.

But this doesn't get around the fact that we'll still need the book as a Word file for Smashwords and Amazon DTP. Maintaining two versions is a pain - late changes have to be made to both copies. But so far I haven't found a better solution. We've alleviated that issue to some degree by adopting the following workflow:

1. We flow the copy into a Word template which has a large number of paragraph and character styles for all sections of the book.
2. We edit the copy, add hyperlinks, add special copy including: title page; copyright page; author bio; WebVivant Press page. In other words, the copy is absolutely complete except for a contents page.
3. We carefully proofread the book, at least twice. When we're happy with it, we save the file with '_FINAL' added to the filename. This is the text that will appear in the book. Only essential changes are made after this point.
4. We make a final check to ensure the file is technically compatible with the various e-book services.
5. This Word file is used to create e-book versions at Smashwords and Amazon DTP.
6. We flow the text from the Word file into an InDesign template. This template has paragraph and character styles that match those in the Word template.
7. We add a contents page (for non-fiction books) to the InDesign version. We may make some minor design tweaks, but generally the design is taken care of by the template's style settings.
8. We output from the InDesign file as PDF for the print and PDF versions and as ePub for the Lulu e-book version.

In Part 2, we'll look at some of the issues you might encounter when creating your e-book.

We all like to use great photography on our websites. Photographs add impact, draw visitors and increase the overall quality of the site.

In other words, photographs add value.

And that's why photographers like to get paid for their work. Alas, as we all know, image theft is rampant on the web. It's seen, by the more clueless members of the web community, as a harmless activity. They fail to understand that they are taking money directly from the pockets of photographers. Copyright is perceived as an oppressive tool of huge, venal corporations: yet most image theft actually impacts hard-working, underpaid, self-employed freelances.

The problem is that several myths have taken root, leading people to think that they can use whatever images they find without compensating the rights holder. Add some laziness into the mix and you have an environment in which image theft is endemic.

But it's not without its risks, as one UK firm has recently discovered. Its unauthorised use of a postage stamp-size image ended up costing the firm something in the region of £26,000, mostly in legal fees.

So let's deal with a few myths.

If it's on the web, it's public domain

Flat wrong. Major news agencies and photo libraries have images on the web. Do you really think they're public domain? Finding an image on the web is no different to finding it in a book or magazine. The web is just another publication medium. The public availability (and ease of copying) of the image does not make it freely exploitable. Publication on the web has no effect whatsoever on an image's copyright status.

My use of the image falls under 'fair use' provisions

This is almost certainly untrue. This excuse is frequently trotted out by people who have dangerously little knowledge of copyright laws. They've heard of 'fair use' and assume - for whatever specious reason - that it applies to them. (Often the excuse is that their site is 'non-commercial' - see below.) Fair use provisions were included in copyright laws for very specific applications. You need to be very, very sure that your use of the image falls within these extremely narrow provisions. In the vast majority of cases, it won't.

If it's on the web, it's Creative Commons

Nope, sorry, wrong again. Whether an image is made available under a Creative Commons licence is a decision for the photographer, not you. Unless the image carries information specifically identifying it as being available under CC provisions, you have to assume it's not. Most images produced by professional photographs are not Creative Commons, because that hippy-dippy licensing scheme makes no commercial sense and is really just for amateurs and dillettantes.

I'm only using it small

That didn't save the UK company mentioned above. Size doesn't matter.

My site is non-commercial

So what? You may have just a personal blog with no advertising or products for sale, but you are still using someone else's property to add value to your site. Whether you make money out of your site is entirely irrelevant. And it's unlikely the courts will take this into account when deciding damages.

I've credited the photographer

Oh, good for you. I'm sure that's given the photographer a warm glow of satisfaction. Unfortunately, photographers can't use credits and warm glows for paying for things like food. In the professional world, a credit is assumed as a right. But a photographer's business relies on getting paid. Providing a credit does not satisfy the requirements of copyright law. You're still stealing.

This excuse is often accompanied by...

I've linked to the photographer's site

Another big whoop. See I've credited the photographer above for why this is irrelevant. I mean, seriously, how much business do you think a photographer is going to get as a result of a link from your site?

It's not watermarked, so I can use it

I think the reasoning here is something along the lines of, "If the photographer hasn't marked it as his/her property, then it's okay to use it". This is just as wrong as the if it's on the web it's public domain argument. There is no requirement to watermark images in order to protect copyright.

There's no metadata, so I can use it

This is a variation of the watermark myth. Many image formats, such as JPEG, allow you to store 'metadata' - information about the photo - in the image file itself. Professional photographers store data such as their names and web addresses, caption details and keywords in IPTC metadata. And digital cameras automatically store technical info about the image in EXIF metadata. Alas, many image hosting sites automatically strip out IPTC and even EXIF data. And just as with watermarks, the lack of metadata does not alter an image's copyright status.

There's nothing to say it's copyrighted

Another variation on the two above - in fact, a sort of general version of those. The fact is that in most places in the world, an image is automatically copyrighted the moment it is created. There is no requirement to go through any kind of 'copyrighting' process in order for the image to have copyright protection. (Even is the US, the process of registering images with the Copyright Office simply changes the nature of the damages one can recover when copyright is infringed. Such registration isn't needed to confer copyright on an image.) In short, you have to assume that the image is copyrighted. The lack of any indication about an image's copyright status is irrelevant and doesn't give you a legal excuse to use it.

I couldn't find out who it belonged to

Well, that's your failing. Just because you haven't been able to identify the owner doesn't mean you can use it. Try this experiment: go to a parking lot. If you're lucky enough to find an unlocked car with the keys in the ignition, drive it away. When stopped by the police, explain that you couldn't work out who the owner was so you thought it was okay to take the car. See how they laugh, pat you on the back and wish you a safe journey.

Other sites are using the image

This will help you in one way, and one way only. You and the other site owners could band together and hire the same lawyer to defend yourselves. That way, you might get a bulk discount which means slightly lower costs. You might only lose your house, but not your car. And have you considered that the other sites might have paid for their use of the image?

So what do I do?

It's a minefield, isn't it? With all kinds of image licensing schemes, varying copyright laws across the world, and a flood of images with no identifying details, how do you know whether you can safely use that image?

Here are some very simple rules that will keep you out of trouble - and out of court:

» Assume the image is copyrighted. As described above, most photos are copyrighted automatically.

» Assume you have to pay for it. This follows on from the above point. If it's copyrighted, it's someone's property. If you want to use other people's property, it's reasonable to assume you'll have to pay for that, no?

» Assume you need permission to use it. Even if you're happy to pay for the image, you can't just use it and think "I'll pay when the rights owner gets in touch". Copyright infringements are not about not paying for images - you infringe copyright when you use an image without permission. Even if you could prove that you intended to pay, you could still find yourself paying damages for not getting permission first.

» If you can't work out who it belongs to, don't use it. How can you get permission if you don't know who to ask?

In fact, that last point brings us to our most important guiding principle:

» Assume you can't use it.

Yes, I know, you might really, really want to use that image. But if you don't know if it's okay to use it (which it probably isn't) then it's safer and more honest not to do so. After all, what overriding need do you have to use it? Why is it so important that you use that image? And why is this more important than photographers' rights to be compensated for their work and skill?

Following on from my post about how to set up InDesign and Photoshop when creating your book cover, I thought I'd add a few more tips and observations.

Think small

Many of the book covers I like use subtle details and small type. That's not going to work in this web age.

A very large proportion of the people who come into contact with your book are going to do so via the web. If you're adopting a web-based business model, that proportion becomes 100%. And, most often, they're going to see a thumbnail version of the cover. So your design has to work on a small scale.

A cover that seems elegant, classy and understated on the bookshelf may look drab, fuzzy and unexciting when it's only 100-ish pixels wide. To see what I mean, I chose a book from Amazon.co.uk: I didn't spend a lot of time searching, so you'll find much worse examples, but this gives some idea of what I'm talking about. (And to show there's no malice, I selected a book and an author that I admire. In spite of what I say here, I strongly recommend that you buy this book - click on the cover images to visit Amazon.co.uk.)

Here (left) is the main thumbnail of Daniel Dennett's Freedom Evolves. It's a tasteful cover, befitting a leading philosopher. But at 125 pixels wide, the background image (of tree branches) is already starting to become somewhat murky and indistinct. There's no impact to the image at all. It would be hard to pick this book out of a line-up.

Amazon also makes extensive use of 40px-wide thumbnails - eg, for the 'People who bought this also bought...' feature. Here (right) is the 40px version.

The author's name is still readable - just. That's important because Dennett is a well-known writer and that name recognition is important. But the book title has broken up, so you'd be hard-pressed to know which of his books this is. This hasn't been helped by the use of a serif font reversed out of a dark background. Serif faces can suffer when being reversed out at the best of times, and don't stand up to this kind of scaling down treatment at all well.

The background image has become entirely abstract and, well, messy. The book has lost its unique identity. There's no recognition factor.

Key elements

That doesn't mean that everything has to be bold and brash. It does mean that the design needs to retain some impact when it's viewed small. Critically, it has to remain recognisable, and not become a jumble of random pixels.

As a general rule, then, this means using:

• Simple, bold colours - and not too many of them
• Large, simple type for the title - avoid fancy fonts
• A simple graphic element that scales well, retaining its recognisable shape as it gets smaller.

I'll use my own book as an example. That's not because I think the design is perfect - far from it. It's just that I have access to all the design elements.

Here's the cover of my novel, Lady Caine, at 200 pixels wide.

I used Gill Sans for the title. It's a very open, simple typeface. As you can see, it's in black against a white background.

There are several elements to the illustration, but the key one is the aeroplane (a DC-3 I photographed at an airshow back in the early 1990s). This is used large and has been treated to make the image more graphic, including the use of a bold colour. The effect is to make the whole thing simpler while retaining the recognisable form of an aircraft. To see what I mean, here's the original image:

So what happens to these elements when they're scaled down?

Here's a 120px-wide version (right). The title and author name are both still readable. And the graphic is barely affected. The cover remains instantly recognisable.

And much of the same applies when the cover is further reduced, to 40px wide. Okay, the author name has gone, but for a first novel, author recognition is less important - it's the book title that's important.

Don't be so clever

Browsing the Lulu website, you'll soon find examples of classic mistakes. People cram lots of images on the cover, presumably in the hope that people will find something they like. They use fussy designs with no strong graphic elements. They use muddy or dull colours. Or they use complex background images that turn into a frenzy of random pixels as soon as the image gets reduced to web resolution. There are lots of examples of fancy fonts, too - for example, script faces that, I assume, the authors believe are classy or sophisticated or quirky but which, alas, fast become unreadable.

So, you can take away at least one lesson from their examples: KISS.

Your cover is your most effective marketing and sales collateral for your book. People do judge books by the cover, so it's important to get it right.

What follows are some tips on the mechanics of laying out your cover. But it's not a course in graphic design: you're still going to need some visual flair to put together a great cover. If you don't think you have the necessary visual abilities, find someone who has. Design is a skill - it's not something you can pick up overnight.

This article uses Photoshop and InDesign as the file creation tools - because they're the best tools for the job and because that's what I use. But the steps outlined here will transfer equally well to other DTP or image editing software.

For the sake of this article, let's assume you're producing a 6x9in perfect-bound trade paperback. We'll also assume that you're designing a one-piece cover that incorporates front and back covers plus spine - although much of what you read here will be just as useful if you're creating separate images for front and back.

Before you can start, you need to know the width of the spine. This depends on the number of pages in your book and the type of paper you're using. Your printer or POD service will advise you. Lulu, for example, has a calculator for this (look under 'Creator tools' in the sidebar when you're logged in to your dashboard). Although you can always tweak your design later, should the number of pages or paper stock change, it's a lot easier if those elements are fixed before you start. So lay out, proofread and finalise the book contents before starting on the cover.

Image size and bleed area

If you're book is 6x9in you might assume you need a 6x9in image for the cover. Not so.

Printers require a 'bleed' area around the cover image. In effect, this allows a margin of error when the printer trims the book. Any image or text that extends all the way to the edge of the cover should continue into and right to the edge of this bleed area. If you end the image at the edge of the main page, you risk having a white border appear when the cut doesn't quite match the edge of the image.

Lulu specificies a bleed area that extends 0.125in (0.36cm) beyond each edge. This is a typical figure used by many printers. For example, with a book height of 9in, the height of the image needs to be 9.25in, and you should assume that the top 0.125in and bottom 0.125in will get trimmed off.

For a one-piece cover, the image width needs to be twice the width of the book, plus the width of the spine, plus a bleed area each side. Let's say your 6x9in trade paperback has a 1in spine: the width of the image will need to be:

0.125in (bleed) + 6in (back cover) + 1in (spine) + 6in (front cover) + 0.125in (bleed) = 13.25in

So, for this example book, the full image size is 13.25in wide x 9.25in high.

Don't make the bleed area any bigger, "just to be on the safe side". Lulu, for example, assumes that the bleed area will be a fixed 0.125in: if you make it bigger, Lulu will rescale the whole image.

Lulu also suggests using safety margins inside the main (6x9in) page area of 0.25in all round. You should keep any text or images that you don't want to bleed within these margins to avoid any danger of them getting trimmed. (That margin width is just for covers - Lulu suggests 0.5in for inside pages).

Let's look at setting up the image in two separate programs - Photoshop and InDesign.

Using InDesign

I prefer InDesign because it's a page layout program and what we're doing is laying out pages. Well, duh.

Start a new document. Select 'Custom' in the 'Page Size' option, number of pages 1 and make sure 'Facing Pages' and 'Master Text Frame' are unticked. Now we need to enter various dimensions.

The width you enter should be twice the page width plus the spine - don't include the bleed area. In our example, this width is: 6in + 1in + 6in = 13in. Similarly, the page height should be 9in (ie, without the bleed). Why? Because, being a proper page layout program, InDesign knows about bleed and allows you to specify that separately. We'll come to that in a moment.

Being old school, I like to work in picas, so that's how I have InDesign configured. Fortunately, InDesign allows you to enter measurements in any unit you like and automatically converts. So I typed '13in' into the width and '9in' into the height, which ID converted to 78p0 and 54p0 respectively.

I set columns to 1 and ignored the gutter setting as it's irrelevant.

I then set the margins to 1p6 - which is the same as 0.25in - our safety margin. And I set the bleed area to 0p9, which is 0.125in. We're all set.

Once the blank page comes up, I set vertical guides at the 6in and 7in points, marking the spine. This gives me a blank page that looks like this:

The outer, red frame marks the bleed area. Any image that needs to bleed off the edge of the page should extend right up to this line.

The black rectangle marks the actual page size. The inner magenta line marks our 'safe margin' - we're going to keep all important elements inside this line.

The two vertical cyan lines mark the spine. For the sake of symmetry, you'd probably also want to add two further vertical guides, 0.25in either side of the spine guides, matching the margin on the opposite sides of the pages. These two guides would be at 5.75in and 7.25in.

Let's put an image in there. I have a cover image I created (in Photoshop) for my novel Lady Caine. Here's what the layout looks like with the front cover done.

There are several things to note here.

First, see how the text for the title etc is nicely inside the magenta safety margin. It's well away from the page edge so there's no danger of it getting trimmed or even looking crowded.

At the bottom of the page, the black area needs to bleed off the page, so it extends all the way beyond the page limit (the black line) to the full extent of the bleed area. (In this image, the blue frame of the image is covering the red line denoting the bleed area).

The aircraft's wingtip is coming quite close to the edge of the page, but I was happy with that because it doesn't really matter if it gets trimmed a little.

So you can see more easily what's happening here, let's look at it in close up. Note how the black area crosses the black line of the page boundary and extends out.

The left-hand edge of the image ends abruptly at the spine. This is a little dangerous. Slight variations in trimming can mean that the spine might 'bleed' slightly on to the front cover, or vice versa. Having such abrupt changes at the spine boundary is, therefore, not generally recommended. In the case of this book, I did this because, in fact, the cover design was not done as a one-piece. If I had designed it as a one-piece, I'd have extended the graphic over the spine and even on to the back cover.

Lulu asks that you supply one-piece covers as PDFs - indeed, that's typical of many POD services. I'll be blogging separately about PDF settings and options, but there's one thing we need to cover here.

When outputting to PDF, make sure you include the bleed area in the PDF file. When you come to export as Adobe PDF, the (somewhat complicated) PDF options dialogue includes a page for 'Marks and Bleeds'. Make sure the 'Use Document Bleed Settings' is ticked. (However, under 'Marks', do not tick 'Bleed marks' - most POD publishers do not want these included).

Using Photoshop

Things are slightly trickier when using Photoshop (or another image editing tool) just because it doesn't offer bleed and margin settings, so you need to do a little more work with guides.

So, here we are creating the new file:

A key thing to note here is the image size. This time, because Photoshop doesn't have a separate setting for the bleed area, we're creating an image with the bleed area included - 13.25in x 9.25in. I've gone for 300dpi. You may also notice that I've opted for sRGB as the colour space, rather than Adobe RGB. The latter may work with some POD services, but the more limited colour space of sRGB is probably safer.

This creates a blank image. Now we need to add guides. The edge of the image denotes the bleed area. We want both vertical and horizontal guides 0.125in inside the outer edges to mark the limits of the pages. And we want other guides 0.25in inside those to mark the 'safe margins'. In addition, we need two vertical guides to mark the spine - and another two vertical guides either side of the spine guides, and 0.25in away from them, to complete our safe margin guides.

Let's start with the vertical guides. The first is at 0.125in, marking the edge of the page inside the bleed area. The next is at 0.375in - that's 0.125in for the bleed + 0.25in for the safe margin.

Next, we'll mark the spine, because it's easy to calculate. The left side of the spine comes 6in from the page edge. The guide that marked the page edge was set at 0.125in. Therefore the spine starts at 0.125in + 6in = 6.125in. Our spine is 1in wide, so the other guide needs to be at 7.125in.

Now we want to add the guides to mark the safe margin either side of the spine. The one for the left side (the back cover) needs to be 0.25in inside the spine guide - ie, 6.125in - 0.25in = 5.875in. The guide the other side (for the front cover) needs to be at 7.125in + 0.25in = 7.375in.

Remember that the right-hand page (the front cover) started at 7.125in, which means the right-hand edge of the page must be at 7.125in + 6in = 13.125in. (Or, you could have calculated this from the width of our whole image, 13.25in minus the bleed area width of 0.125in.) And we need a safe margin guide inside that: 13.125in - 0.25in = 12.875in.

Now you need the horizontal guides. There are only four of them, marking the page edges and safe margins at 0.125in, 0.375in, 8.875in and 9.125in.

Here's what the image looks like. To highlight the different areas, I've tinted the bleed and safe margins. The grey area around the cover is Photoshop's pasteboard and doesn't form part of the image, but it does show you where the guides are. The red areas are the bleed, and will get trimmed. The beige areas are the safety margins. They will form part of the cover image. The white rectangles are where it's safe to put text etc.

You wouldn't want to actually have these red and beige tints in your image - I've put them in purely for demo purposes.

Once you've done all your design work, you're going to want to output as PDF. Select 'Save as...' and choose the Photoshop PDF format.

At first sight, the new logo for the UK Government's Office of Government Commerce (OGC) seems unremarkable. In fact, one might reasonably complain about them having spent money on it. After all, any one of us could have come up with such a dull, text-based design. Here it is:

But wait! As The Register pointed out, the logo is worth another look. Specifically, it's worth a look with your head tilted to the left. Oh hell, we'll save you the trouble. Here it is rotated:

Now what do you see?

According to The Register's story, an OGC spokesthing has claimed that the logo "is not inappropriate to an organisation that's looking to have a firm grip on government spend".