How To Create Fixed-Layout iBooks, Part 6

We now come to the final file we will need to make our fixed-layout iBook complete... at least in terms of functionality, that is. But once you build this file you can load your ebook onto the iOS device of your choice and see it in action. And that's when the real work begins. For now we'll focus on the final puzzle piece required, the content.opf.

As its name suggests, the content file is a descriptive listing of the ebook's physical contents, that is, the actual component parts included in the archive, not its literary or artistic content. OPF stands for open packaging format, which refers to the specification that defines the structure and semantics of the package. There are four essential elements that make up the content.opf file, each of which we'll take in turn.

First, however, you will notice that a new declaration element has replaced the previous !doctype and html namespace references:

<package xmlns="http://www.idpf.org/2007/opf"
       unique-identifier="book-id" version="2.0">

This provides a reference to the official opf spec at the International Digital Publishing Forum website. Those are the good folks who have been piecing this thing together over the years and working diligently to keep it up to date (not an easy task at the rate technology is changing).

The second element in this declaration is the unique-identifier which you should recall we made a reference to in the toc.ncx metadata section. The dtb:uid entry there will show up again in a moment, linking it with the reference here. The "book-id" element is sometimes written as "BookId" or some such instead. It's just a reference, so it can really be anything you like, so long as it matches what we enter below.

1. Metadata

The first section is where the metadata for your ebook content lives - and this time I do mean artistic and literary content. This section can be just a few short lines giving just the bare essentials of title, language, and identifier (the only ones technically required), or add a host of other information that can be useful for identifying and cataloging your title. In this, more is always better, as individual systems can ignore non-relevant portions, but cannot make them up if not provided.

Before we get to the metadata proper, however, we must declare our reference systems, of which we'll be using two:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
       xmlns:opf="http://www.idpf.org/2007/opf">

Dublin Core (dc) is the primary set of metadata elements in use in ebooks, but the opf spec add some specifics that are useful for fine-tuning our statements, so we declare both here, even though we've already referenced the opf spec above. The general practice is to state the <dc element followed by an opf specifier. So, for example, you might include this line of metadata:

<dc:identifier opf:scheme="ISBN">ISBN#</dc:identifier>

where the generic Dublin Core identifier is defined as an ISBN number via the opf:scheme. You would, of course, replace the temp ISBN# entry with your own actual data, given that you have one. An ISBN is required in order to upload directly to the iBookstore, but many aggregators will supply them for you for a fee.

<identifiers>

Other identifiers can be used instead of, or in addition to, an ISBN, and can be almost any unique string of data, such as a website URL or UUID. I've included the "book-id" identifier in the sample template, but here is where you would insert the UUID mentioned previously in the toc.ncx lesson. The idea is just to include some string of data which is unique to this specific incarnation of your work, and ideally includes some type of version number, since ebooks don't often have specific editions as print books do. Each time you update the ebook's content, however trivial, you should alter this data string, preferably in a logical and expressive way that will allow users (i.e. collectors of your awesome body of brilliant work) to identify the particular version they are holding. The UUID is particularly useful in that it can be decoded to discover the exactly moment and location of creation, but looks like utter gibberish otherwise.

<title> <creator> <publisher>

You are required to include a title, for obvious reasons, but not an author, as works can be anonymous. The dc:creator element has a wide range of specifiers, including such functions as author, illustrator, editor, etc., and there can be multiples of each. These can be added using either the id tag or an opf specifier, or both. There's also a publisher element for that entity, and you can add generic contributor elements as well for any others whose roles remain unspecified. I won't go into all the possibilities, as you can visit the referenced websites in the declaration above for complete listings of your options.

I will mention here, however, the opf:file-as tag, as this allows you to specify how you want your work to be listed in catalogs, which is generally last name first. If you leave this out your book will be listed under your first name in iBooks, which is totally lame and cries out amateur.

<date>

There are several opf events you can use for your date entry, including date of creation, copyright, and publication, of which you can include one, all, or none. Your choice. You can also just include the year and leave off the month and day if you like, but if you include the month and day you must use the year-mth-day format of ####-##-##.

<rights>

A statement of your rights is allowed, and just typically states All Rights Reserved (or creative commons, public domain, or whatnot). You can be as specific or general as you want here. In all of these entries, by the way, any of the id="en_whatever" tags can be included or removed. I have included these to show where you would add specific entries for different territories in which you plan to distribute your work, for example if you're doing translations into different languages or reserving/selling specific rights in different countries. In most cases, if you're getting this involved you'll want to consult a literary agent or legal representative who knows publishing law.

<language>

The third and final element you are required to include is a language tag, and this should employ the standard RFC 3066 Unicode language identifiers, using either the base two-letter code, or that plus a secondary string. So, for example, English can be either plain en, or en-us for United States dialects, or en-gb for Great Britain strains, or any of a host of others. Generally just the base language is all that anyone needs, but you never know. You can find the codes online.

<type> <subject>

Using the type element you can enter category data such as whether the work is fiction, non-fiction, poetry, etc., and/or a specific genre or classification, such as historical fiction or art history. Subject, on the other hand, is where you would add Library of Congress headings, or other subject info, such as those used by Amazon to categorize their entries. One reason you're adding all this extra information is precisely so that retailers can add it to their product pages. Adding it here facilitates the quick and accurate transfer of metadata concerning your work, and this is your chance to make sure it's right.

<description>

This is where you would place the back jacket blurb or other descriptive content that tells the reader what the book is about. Anything you might desire a potential customer to know could go here, including reviews, extracts, or a general description such as what you would read on any book page. Give it some thought as it will show up all over the Internet on every ebook retailer, and once it's there it's there for good.

<format>

One other tag you might include is format (iBooks in this case, but ePub or Kindle or whatever elsewhere). This might seem redundant since you've got the ebook right here in front of you, but not everyone reading this data will, and it's one more way this specific iteration of your work can be identified. For example, a library may be looking at a metadata listing in search of a particular format to include in their catalog, and other general ebook retailers will want to identify the format for their customers before selling it to them via whatever systems are put in place down the line as ebooks become more common.

2. Manifest

Just like a shipping invoice, the manifest lists all the items included in the package. Every file in the OEBPS folder must be listed here, with the exception of the content.opf itself. In addition, any files in the META-INF folder are excluded, since in order to get to the manifest the system will already have employed those files.

Each item gets its own entry, starting with item id that includes a descriptive name of your choice. This is followed by a media-type and an href which gives the file's location. Either can come first, but both must be included.

The media-type tells the system what kind of file the item is, and must be correct for the item to function (the file extension isn't enough in itself, apparently). I have provided the main media types you might use, although for images you can also have image/png or image/tif files. Note that all html files are listed as application/xhtml+xml, regardless of what extension you use for the actual file itself (.xhtml, .html, .xml, etc.). You can also use OpenType and SVG fonts in addition to TrueType.

3. Spine

The spine is a linear listing of the ebook contents in the order they will be presented, just as the pages in a print book are attached in specific order to the spine (hence, the name). Here you enter each html page you create using the item id you specified in the manifest above, as such:

<itemref idref="item1"/>

where the idref is equal to the item id in the manifest. Only the html pages themselves need be entered, and not their component parts (i.e. css, images, etc.). Just list them all in the order you want the reader to see them.

4. Guide

The iBooks asset guide states that this section is required, but I've seen iBooks work just fine without it. For fixed-layout ebooks it's altogether an irrelevant set of data. In standard ebooks this is where the drop down menu items are entered, but in fixed-layout iBooks that function is replaced by a set of thumbnails along the bottom and a drop down menu that leads you to a thumbnail grid. However, for the sake of completeness, I'll describe it anyway, as it might come into play in subsequent updates down the line (the Kindle KF8 format still employs it, for example).

Whereas the spine is a logical listing of every page in the ebook, the guide is a list of major waypoints along the way, such as chapters, appendices, table of contents, etc. As mentioned earlier, this is equivalent to the NavMap in the toc.ncx, and should essentially mirror it, although the NavMap can contain much greater detail since it allows page anchors. The guide, by contrast, can only handle major page divisions, and if included should have at minimum an entry for the cover (type="cover"), table of contents (type="toc"), and the first page of text (type="text"), as these three type tags have some built in functionality in ebooks: text, for example, shows up in the drop down menu in Kindle ebooks as "Go To Beginning" and the toc tag in either takes you to the html contents page. Additional entries for an index or appendices prove useful where this works, so if for some reason you decide to make a standard reflowable ebook, now you know what this section's for and how to use it. However, for fixed-layout you can just as easily leave it out.

TEST YOUR EBOOK!

You now have enough content and supporting files to load your ebook into iBooks via iTunes and give it a test run. If anything goes haywire you'll generally get an error message on the relevant page giving you a line and column reference to the offending element. Of course, if it doesn't load at all you'll have to backtrack and work out your error. I've tried to make this as easy as possible by providing a working template into which you can simply add your own content.

Of course, all you have so far is a book of pictures, which is fine if you're making a photo album, but you'll likely want to add some text even to that, so in the next installment I'll discuss embedding fonts and adding active text to your growing book.

How To Create Fixed-Layout iBooks, Part 5

Now that you have a page created for your iBook file you'll need to tell the reading application what to do with it. This requires three separate files to accomplish, but you'll only need to make them once, and then add in additional information for each new page that you create.

THE CSS FILE

The first of these is the css formatting data for the content on the page. In the sample template you'll actually find two style sheets, one named styles and the other page02. If each page in your fixed-layout ebook contains similar formatting for the text you can just create one css file and reuse it for every page. But chances are if you're doing a graphic novel or illustrated book with complex text layouts you'll need to make a different one for every page, as I have done in mine.

However, there will still be certain elements that will apply to every page, such as the page size and full page art positioning. If you open up the styles.css file here's what you'll find:

body {
width: 738px;
height: 985px;
margin: 0;
padding:0;
       }

img {
z-index: -1;
width: 738px;
height: 985px;
position: absolute;
padding: 0;
margin: 0;
top: 0;
left: 0;
       }

This is about a basic a css file as you'll ever see, and more often there will be a whole lot of other stuff in here, providing overall defaults for text styling and placement. For example, you will usually include your chapter header styles and a base paragraph style for the main body text, plus any special formatting you might use in your book, as well as embedded font information and the like. But I decided to save that discussion for the text section instead. For now we'll just set some general defaults for the document.

1. The "body" element

The "body" element defines the page size once again, so these need to match the pixel dimensions you enter in the page content html. This is a bit redundant, but required. The body element specifically defines the overall "container" that will hold your content.

It's also a good idea to set the default margins and padding to "0" just to give you a clean slate to work on. I'll talk about this more when we get to adding text, but in order to fill a page with an image edge to edge you need to remove any margins that might be set by the reading system. Since we're working with one specific program and a limited range of platforms here this isn't really an issue. But in a web based reader, for example, the browser will often add some default settings you don't want, such as base font size and spacing and whatnot. You can zero all that here, but the only one you really need to worry about right now is margin spacing. This way you can add your own margins later when we get to text without having to account for any additional defaults imposed upon your content by the reader.

2. The "img" element

One of the fundamental aspects of a fixed-layout ebook is the ability to precisely place images, and to overlay them with text, or even other artwork. Additionally, fixed-layout allows you to completely fill the page with art, with no white space surrounding it at all. This is called "full-bleed" in the print industry, due to the fact that the image is printed slightly larger than the final size, with some of it bleeding past the borders in order to ensure it reaches to the edge when cropped. Here, of course, your image will be exactly the size you make it.

The "z-index" is how you place your page elements in the vertical stack, with "0" being the default. Thus, in order to place your artwork behind the text, you simply drop it down one level by assigning a negative value to the img element. You could, of course, add a positive number to the text layer instead (or even in addition to it); however, since there will generally be only one background image, but a lot of text, it's easier just to change the overall img default to -1 and leave the text layers at the default setting of 0. You can then add other layers above these by adding them to the stack in the css for the relevant page.

Again, you need to enter your page dimensions here if you want to create full-bleed backgrounds, and zero out your margin and padding, as well as top and left positioning. You'll also see a "position" element set to "absolute" here, which allows us to place our images exactly using pixel references rather than placement relative to other elements. All your content can now be precisely positioned simply by giving the number of pixels vertically from the top or the bottom, and the number of pixels from either the left or right. Generally you'll use top and left, but sometimes it's easier to work out placement from the nearest edge.

In order to completely fill the page with art, you simply create an image with the same dimensions as the page (such as our cover art) and it will now be placed by default in the upper left corner at "0,0" and fill up the entire page.

You now have a completed cover page with both content and css. But we still have to tell the system how to find these files and when to display them, and this requires two additional pieces to our puzzle.

THE .NCX FILE

The toc.ncx file is a navigation control xml document which, as the name suggests, tells the reading system how to navigate the file. In this respect it functions as the table of contents for the file, and this is where the elements that make up the functional table of contents come from, that is, the one that shows up in the iBooks drop-down box in the upper menu bar and allows you to jump to another section of the book.

You can also include an actual table of contents as one of your html pages, complete with internal links, but these are generally less useful since you have to navigate to it first before going where you really want to. In addition, illustrated works such as graphic novels and children's books don't commonly employ tables of contents in the standard sense, although heavily formatted fixed-layout ebooks such as textbooks or travel guides will certainly want them.

But either way you will want to (and are in fact required to) include at least a few basic waypoints in the ncx, in particularly the cover and first page of actual story content. It's a good idea to at least put in chapter markers as well for every major section of the book.

If you open up the toc.ncx in the sample template you'll see the standard xml declaration/encoding data that we'll discussed before, followed by a new set of references:

<!DOCTYPE ncx PUBLIC "-//NISO//DTD ncx 2005-1//EN" "http://www.daisy.org/z3986/2005/ncx-2005-1.dtd">

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

The ePub format is actually an amalgamation of several earlier specifications that have been modified and developed through the years, with the .ncx being an artifact from the original accessibility functions inserted by the Daisy consortium to assist users with sensory or mobility impairments. Thus, the ncx doctype and namespace references point to the daisy.org site for their functionality. You don't need to know what any of this means, but just be aware of it and make sure to add it in.

1. The <head> element

The head element contains the document type definition (DTD), a name that is wholly unsuited to its function, as nowhere do you actually define the document type within it, or even within this file. There are four lines of meta data that do need to be included here, however, even though only the first two actually apply to ebooks at all.

<meta name="dtb:uid" content="0"/>

Every ebook requires a "unique identifier" (uid) to set it apart as a separate digital document, not just from all the other ebooks out there, but as a specific version of this document. You will need to replace the "0" content element here with your own identifier. This can be virtually anything, really, from a website url devoted to this book, to a version number string that includes enough data code (title, author, date, etc) to make it unique to any other ebook.

You can also generate a uid code using a web-based resource such as UUIDGEN, which will create a random string based on such factors as your IP address and the date and time. You will also enter this code in the content.opf we will create next, and the two must match.

<meta name="dtb:depth" content="1"/>

This is the only element that actually applies to the table of contents, and simply defines the number of levels in the toc hierarchy. For works of fiction this will almost always be "1" for simple chapter sections, but for non-fiction works there can be several levels of subsections within each chapter. Add one additional number for each subheading you'll be using.

<meta name="dtb:totalPageCount" content="0"/>
<meta name="dtb:maxPageNumber" content="0"/>

These last two are left over from physical print book metadata and are not relevant in ebooks generally, since the number of pages in reflowable ebooks varies greatly depending on the display screen and chosen font size. However, since fixed-layout ebooks do have a specific number of pages, you could enter that information here if you so choose. I'm not sure it will be used anywhere, but as this is metadata it might conceivably be included one day in the iBooks retail page listings for fixed-layout ebooks, so that potential purchasers can know how long the ebook is. This seems quite useful information to me, and since the metadata can be entered one would like to think it might be used.

The "totalPageCount" is the overall number of pages in the file, including front matter and appendices, whereas "maxPageNumber" would be the actual count of numbered pages, minus ancillary material.

2. The <docTitle> element

Here is one of the two places you'll enter the title of your magnum opus. The other is in the content.opf, and the two must match. Enter it as you want it to be listed.

3. The <navMap> element

The "navigation map" section is where you insert the entries in your table of contents, entering "navigation points" for each item you want to show up in the iBooks drop-down menu. Here we have just two, corresponding to the two main elements in our sample template, the cover and first page:

<navMap>

      <navPoint id="navPoint-1" playOrder="1">
            <navLabel><text>Cover</text></navLabel>
            <content src="cover.xhtml#cover"/>
      </navPoint>

      <navPoint id="navPoint-2" playOrder="2">
            <navLabel><text>Chapter 1</text></navLabel>
            <content src="page02.xhtml"/>
      </navPoint>

</navMap>

Each navPoint has an id which can be anything, but a simple numbered order is most practical. The playOrder element is what tells the device how to list the entries, although entering them here in any other order than the way you intend them to show up would be simply idiotic, not to mention confusing.

Within the <navLabel><text> element enter the text you want to appear in the table of contents list, exactly as you want it to show up (i.e. capitalized and spelled correctly for those of you who communicate by text these days).

Finally, the content src references the content file you create for that page. You can wait until all you content is created to make the .ncx file, or you can add them one by one, which you might want to do in order to test the file as you progress. It's also often easier to do it bit by bit to keep from getting thoroughly confused.

To create subheadings within the table of contents (as specified in the metadata depth element), you would simply add them below their parent entry, but before the parent entry's closing tag. So, for example, if you want a second level element beneath the Chapter 1 entry, start a new navPoint entry after the <content src="page02.xhtml"/> line, but before the following </navMap> closing tag. You can create as many nested levels as you like this way, so long as you specify the number of levels in the metadata section.

Lastly, you can create table of content entries for mid-page subheadings using fragment references which point to anchors in your document, by adding references after the name of the content source file, such as: ..."page02.xhtml#section2"/>. Of course, you'll need to be sure to add the proper anchor at the  specified location in the document, as in <a href="section2>Section Header Title</a>.

[By the way, you might notice an error in the template .ncx here where I used copy and paste to create the second navPoint entry rather than typing it out again, but neglected to delete the #cover anchor, which I had only added as an example, since you would never actually use one there]

And that completes your toc.ncx file. At least until you create more content, that is.

NEXT UP: The Content.opf File

How to Create Fixed-Layout iBooks, Part 4

So finally we get to put some content in our book! The first thing you must know is that in fixed-layout ebooks there must be a separate file for every single page. Because you'll be placing all your content precisely, you must define the area in which you will be working. This is why deciding on the size and shape of the page is so important, and here is where I'll show you how to do it. In addition, every page must be the same size and shape. Only their content will be different.

In this part we'll create the first page you'll likely want to make, which is the cover. Whereas in Kindle ebooks you are discouraged from including the actual cover image in the file, adding it instead during the upload process, in iBooks you must include it yourself.

Since the cover is generally a single full page image with the title text included it will make an ideal introduction into how to create a fixed-layout page. You can, of course, add the titles and any other text as a separate layer, but we'll save that for later and only focus on the artwork here.

I should mention that Apple frowns on using images that include text, requiring that any text within the ebook be created as an active layer. This is so that functions such as dictionary definitions, searches, highlighting, text-to-speech, or any other accessibility features be fully functional. Otherwise there would be no difference between the basic fixed-layout format and a standard pdf. However, this requirement does not apply to outer covers, or to title pages or other places where highly customized text is desired. Bear this in mind in your textual choices.

THE FIXED-LAYOUT PAGE

If you open up the template cover.xhtml file in your editor of choice, you'll see something like the following:

The first few lines provide our language declaration, and note that here we include an additional encoding statement which defines the document as using the "UTF-8" character set. There is also a DOCTYPE declaration which defines the file language as html, and provides the necessary referents.

Finally, there is an xml:lang statement defining the coding language as being written in English. This, of course, assumes you're an English speaker writing for an English audience, which I'll also assume since you're reading this. All of your html files should be encoded with this set as shown. Just copy and paste it as is.

THE HEAD ELEMENT

The next section is where you define the characteristics of the page, and link to the style sheet you'll use to format the page contents.

1. meta name="viewport"

Apple uses a feature called the "viewport" in iBooks to define the actual size of a page. This is not necessarily the size of the iPad display itself, although it can be. As I discussed at great length in the last part, your content is best created at a larger size than the actual iPad screen, for several reasons. Foremost this is so that users can zoom the image up to view more detail, such as reading smaller print. But also as I mentioned so the ebook doesn't become obsolete as soon as a higher resolution screen comes out.

That said, you are certainly free to make your book in any size and shape you wish. If you want to keep your file sizes small and have no need or wish for anyone to zoom your pages larger than the iPad screen, then create each page at the default resolution, as I discussed before, so that a single page will fill the screen in portrait orientation without being zoomed. Don't make each single page the size it will appear in a two-page spread in landscape orientation, because the iPad will zoom it up automatically to fill the screen when viewed as a single page in portrait orientation, and it will look like garbage. But the larger image will look just fine when shrunk to fit beside its opposing page in a two-page spread.

Whatever size you decide on, enter it on the first line here in the "width" and "height" attributes, where the numbers shown are the exact number of pixels that define the size of your page.

2. meta content="text/html"

This may seem a little bit redundant, since you've already given this information above, but here it refers to the actual content of the page and not the coding language of the document. Or so I've been told. Just put it in.

3. <title>

This is utterly pointless, since it doesn't show up anywhere. In fixed-layout ebooks there is no actual header in the upper margin (or footers for page numbers either, by the way, so you'll have to put those in yourself if you want them - see my Ring Saga sample chapter for an example). I imagine this is what that was meant to be, but as I said it won't appear anywhere, so you can put whatever you like there. Use it as a way to describe the page contents if you like, of put some jokes in for curious ebookworms. It really doesn't matter. I'm not even sure it needs to be there, but I haven't tested it.

4. link href=

This is the other line that really matters, as it tells the reading system where to find the formatting information for this page. That data is kept in a separate CSS file, and only the actual page content is located here. CSS (Cascading Style Sheet) is a "stylesheet" as the last element declares, which we'll get to shortly. You can create one and put all your formatting information in it, or make a separate one for every page, or even both, but any formatting that needs to be applied to this page must be referenced here.

The href= element is the only one you'll need to change, as it must specify the location of the specific style sheet you want to apply to the content of this page. Beat in mind that the css file location is relative to where this page is, so if you've put the html page file and its css file in the same folder all you have to do is list the file name. But if the css is in a separate folder, as in the example, then the relative path must be given. If they're in separate folders, start the line with ".../" which tells the OS to start looking at the root level (such as ".../css/styles.css" for example).

Obviously, we haven't created any css files yet, so just give it a name that makes sense and use that name when we get to that point. Or leave it as is and come back to change it later.

THE BODY ELEMENT

Now at last we get to the heart of the matter. The body container holds the actual content of the page, and it's written just like any standard website using html. You'll want to know at least the basics of html, but you don't need a lot. There are hundreds of thousands of quick reference guides out there on the web for free. You can open up ebooks and look at the code it's made of to learn how specific things are done. But for now we'll just keep things simple.

1. <div id="cover">

All we want on this cover page is a single image, so our body only has one element, contained within the <div> tags. Normally you'll just call up the divider using <div> all by itself, closing it with </div> after your content. But in order for your cover image to show up as a thumbnail on your iBookshelf you need to add the id="cover" element and attribute. We'll reference this elsewhere - in the content.opf file - and this is where that file reference will find what it's looking for.

2. <img ...

Since all that's on this page is the cover image, chances are you'll want that image to fill the entire page from edge to edge. To do so, all you need to do is create or resize that image to the exact dimensions of the viewport size you chose for your book.

To insert the image into the page, you call it up using the <img tag, followed by that file's location, or "source" (src), which you reference just as you did for your (currently nonexistent) css file. Technically, the image file is nonexistent as well, as I haven't told you to put it in the image folder yet. But you can do that now, or any time you like. The template already has folders for images, css, and fonts as well. You can just drag and drop yours into the appropriate one, and then delete the other.

Warning! If you delete the only file in a folder, it will delete the folder too, so put your image in there first before deleting the ones you don't want. Of course, you can recreate the folder, but I just thought I'd mention it to save you time.

3. alt=

The text you enter into the "alt" element is usually what you would see pop up if you were to hover a mouse over this image. Of course, the iPad has no mouse, and as you cannot hover your finger to make this happen, what you write here will never show up anywhere. However, it is used to vocally describe image content to visually impaired readers who are using verbal accessibility features. So give some thought to what you put here. Most people don't, and I imagine it's a great annoyance to those who would enjoy a bit more information than "front cover". It's unlikely very many visually impaired readers will be avid graphic novel fans, but you never know. I haven't done any research on those statistics, so it's probably best to hedge your bets and add a little something extra. That said, it is required to put something there, but what is left entirely up to you. At any rate, that's what "alt" is for.


You can now save your file and close it down. Be sure you've added the closing tags at the end or you'll get some nasty error messages upon loading the file into iBooks. Chances are you'll miss some of these (I always do), and it will be a pain to go back in and fix them, so just take a moment now to look the file over before moving on.

Congratulations! You have just created the cover for your book. Unfortunately, the file will not yet load successfully into iBooks, as you have no css, and you're still missing two other crucial files. We'll focus on those next so that you can start to get your work in progress functional enough to have a look at what you've got.

NEXT UP: The CSS File

How to Create Fixed-Layout iBooks, Part 3

Before we can continue building our fixed-layout ebook we'll need some content to put in there. This is, of course, the reason we're here undertaking this project, so I would presume you already have something you want to make an ebook out of, and as we're focusing on fixed-layout format you've likely got some heavy art to include. First, however, you must understand the nature of the medium that you'll be working in.

In standard ebooks the size and placing of elements onscreen can change, which makes everything relative to everything else. But in fixed-layout ebooks everything is...well... fixed, and consequently the size and position of every element is absolute. In order to place those elements accurately, therefore, you must know precisely where you want them to be and how to put them there. This will require a slightly technical explanation, so bear with me for a moment.

DISPLAY RESOLUTION

The current iPad screens contain 1024x768 pixels at a resolution of 132 pixels per inch. However, the pixel density of 132 is irrelevant since the total number of pixels is fixed. In print, a resolution of 100 pixels per inch would make a 1000x1000 pixel image print out at 10" x 10" square, whereas a resolution of 200 pixels per inch would make that exact same image print at only 5" x 5". But on a fixed digital screen both images will appear exactly the same, although a higher resolution image will generally look crisper since the original art will tend to have more detail.

The iPhone4S and iPod Touch have a screen resolution of 960x640 pixels at 326 pixels per inch. With nearly three times the density of pixels, the smaller screen has nearly as many total pixels (614,400) as the larger, but lower resolution iPad (786,432 total), even though the iPhone display is only 3.5" and the iPad nearly three times that at 9.7". This is why the smaller screen has the ability to display almost as much detailed content as the larger one.

To make matters worse, resolution will continue to increase until the larger tablet screens reach the pixel density of the smaller ones. Fortunately for us, 326 pixels per inch is pretty much the upper limit of the human eye's ability to discern individual details, so increasing pixel density further would be pointless. But when the iPad's 9.7" screen reaches the iPhone's level, its total pixel area will be 2529x1897 for a massive total of 4,797,513 pixels, every one of which you'll need to fill with content and color.

Now, some of those pixels can be duplicated, so that, for example, one pixel in a 1024x768 image created today will be displayed by a 4 pixel square in the 264-ppi 2048x1536 display rumored to be coming on the iPad 3 due out this April. Theoretically, the image should look pretty much the same, although in fact it will be zoomed and pixelated and somewhat fuzzy by comparison, since that 1024x768 image will only fill the middle of a screen with four times as many pixels (twice as many wide, and twice as many high), and it will be the display processor that calculates what color to make those extra pixels, not you. Crisp edges will become fuzzy where black meets white and the display logically selects three shades of gray as a compromise for the three new pixels it must fill in when zoomed to full screen resolution.

More importantly, these are all pixels that could contain more detail and present a clearer, crisper image. For this reason it is recommended that you always create artwork at the highest resolution possible to future-proof your hard work against the higher resolution screens that are surely coming. In the iBookstore Asset Guide Apple themselves recommend using images that are "at least twice their intended display size" for this reason, as well as enabling users to zoom in to see more detail.

FILE SIZE LIMITS

Complicating matters are two further issues we must take into consideration. First is Apple's two million pixel limit for each individual image. This is apparently not a hard and fast rule, but images larger than this may not display properly, or cause the iBooks app to crash. Given this restriction, the largest single image size legally allowable in the iPad's 4:3 aspect ratio would be 1224x1633, a total of 1,998,792 pixels. Of course, you can place more than one of these on a page, and two of them side by side makes up a full landscape spread. But this brings up our next consideration, which is total file size.

Since .epub files use .zip compression in their packaging, they must adhere to the zip archive's current 2 Gb limit, and this is a hard and fast rule which cannot be broken. Now, two gigs is a pretty enormous file, so there's really not a lot of concern here. But as files get bigger and enhanced ebooks include more content, it becomes increasingly possible this limit might be reached, particularly if a lot of video is embedded. The 28 images included in my Ring Saga sample chapter bring its total size to over 24 Mb - a long way off from two gigs, but it's only one chapter of a proposed 450-500 page project, each page of which is roughly 1 Mb at a quality setting of 10 in Photoshop. More compression can, of course, bring these file sizes down, and may be necessary for the final complete ebook. But where quality is concerned, the less compression the better. It's a compromise each ebook artist will have to make for themselves. And if screen resolution continues to increase, even these image sizes will be too small.

The bottom line is that when you're creating high quality artwork for a graphic novel or illustrated ebook with full-page images, you should ideally create them as close to the two million pixel limit as possible and work from there. I create my original artwork at upwards of 4000x3000 pixels or so and then shrink to fit. The iPad, by the way, automatically resizes larger images to fit the screen, in whichever orientation it's being viewed. You can double-tap to view full screen, or pinch and zoom to view the image at full size.

ACTUAL IPAD SCREEN SIZE

Although the iPad's total screen size is 1024x768, Apple's "recommended page size" in the Asset Guide is only 985x738, due to space taken up by the faux book pages and menus. Consequently, this is the size I've used in the template to give you the official example. Thus, the actual maximum image size you should use for a single full page layout using Apple's recommended layout would be 1630x1224, for a total of 1,995,120 pixels.

However, if you want your pages to fill the entire iPad screen with the upper and lower menu bars retracted, use the full iPad resolution for a single page (i.e. 1024 high by 738 wide). This will fill the screen with a single page in portrait, as well as a dual-page spread in landscape. Note that the auto-retracting menu bars will cover the upper and lower margins of the page when they are activated, obscuring what it underneath, which is presumably why Apple recommends the smaller page height. These menus disappear, however, when the page is tapped, removing them from view (all but the small status bar at the top, that is).

Recent updates have included the option to turn off the faux book borders in standard iBooks editions, via the font display menu, but since this menu is not available in fixed-layout iBooks, the faux book pages are there whether you want them or not. This may change at some point down the line, of course, particularly seeing that the new .ibooks format no longer has them (although they may just be turned off in the few textbooks I've looked at). But for the time being, you'll want to take them into consideration when creating your art layouts, as I have done above, since removing them will slightly alter the full page aspect ratio.

SPANNING IMAGES

Fixed-layout iBooks actually allow you to use a single image to fill a two-page spread by spanning the image across the pages. However, given all I've just said I highly recommend against this, since Apple's pixel limit only applies to each individual image. If you use one image to fill two pages, you have effectively cut the maximum size of your artwork in half, with only one million pixels per page. This is still enough to fill up the pages currently, but only just, and tomorrow it will look like crap. Additionally, it's a whole lot of extra effort and confusion to format for no real good reason. It is vastly easier to cut an image precisely in half in Photoshop than to span it across two pages. You have to create two separate page files either way, and the seams match up perfectly. This is what I've done in the Ring Saga sample, so have a look at that as an example.

However, in the interest of giving you a full range of options, I'll include the information anyway, as there may be occasions when it could be handy. For example, if a smaller image runs across two pages of, say, a magazine-style layout, or a travel guide or some such, particularly since this would allow you to adjust the image placement without having to go back in to Photoshop and crop it up again.

But I won't get into that just yet. First we'll build some single pages.

NEXT UP: Creating Your Cover

How to Create Fixed-Layout iBooks, Part 2

Today we'll be tearing apart an ePub file to look at what's inside, and then starting at the top and working our way down the list of contents one by one. If you haven't downloaded the free template file yet, then do so now, as I'll be using it to describe the contents of a standard iBooks file. You can also download my Ring Saga sample chapter and have a look inside if you want to see a somewhat more complex file. It's encryption-free, so you can open it up and look at all the content.

OPENING THE FILE

As I mentioned previously, an iBooks file is just a slightly modified .epub, which itself is just a .zip archive with the extension changed. Consequently, you can open an .epub the same way you open any .zip file. You can either change the .epub extension back to .zip if you want to, or you can just right-click on the .epub and select "Extract" or "Open with" whatever zip program you use. I recommend 7-Zip, which lets you modify the contents of an .epub without changing the extension or extracting the files. You can also just drag and drop new files into it, and delete ones that are in there. Other compression programs might do this too, but I haven't tried them, so you're on your own there.

The other program you'll want is Notepad++, or something similar which has numbered lines and search/replace functions. Don't use Windows Notepad as it doesn't have these features and will totally garble your files. You can use any webpage builder you might have, such as Dreamweaver or whatnot, but since you'll be opening and closing it a lot and often, you'll want something that loads and opens files quickly. Whichever editor you choose, be sure to add it as the default editor in 7-Zip (Tools / Options / Editor) so that you can right-click and select "edit" to open compressed files in the editor without extracting the files.

THE FILE STRUCTURE

When you look inside the template, what you'll see at the root level is one file and two folders (whose contents I'll also disclose here for a complete overview of where we're going:

     mimetype
     /META-INF/
            container.xml

            com.apple.ibooks.display-options.xml

     /OEBPS/

            /css/

                   page02.css

                   styles.css

            /fonts/

                   Storybook.ttf

            /images/

                   bookpage.jpg

                   cover.jpg

            content.opf
            cover.xhtml
            page01.xhtml
            page02.xhtml
            toc.ncx

This is the basic ePub file structure, all of which must be in an iBooks file (except for the custom font), although the names of the content files themselves can be unique to your book project, with the exception of the META-INF folder and its contents, which must be named exactly as shown. And of course there will likely be a whole lot of additional files in there before you're done, possibly including a few varieties not listed here. But more on that later. First things first...

THE MIMETYPE FILE

The mimetype file tells the reading system what type of file it's looking at. If you right-click and select "edit" to open this file you'll see a single line of text:

application/epub+zip

This tells the device's operating system that the file is an epub/zip archive, which tells it a lot about its structure and that the contents use zip compression. You can create this file from scratch in your editor, but you can also just use this one, as they're mostly all the same. The new .ibooks files have a new mimetype:

application/x-ibooks+zip

which I imagine tells the iBooks application to apply a whole new set of rules to the contents. This also technically makes it no longer an epub file, although the general structure is pretty much the same. As an experiment I changed my Ring Saga mimetype to this and loaded it into iBooks. The file opened with the super-cool new hardback cover animation, but there wasn't anything else inside, so I've got some work to do yet in figuring that out. I'll let you know when I work it out. But from this we can discern that one of those new rules is that .ibooks files get the nice new glossy hardback cover!

If you choose to create your own mimetype file there are three stipulations you must observe:

1. The mimetype file must not be compressed or encrypted
2. There must be nothing else in the file but the one line of text
3. It must be the first file in the zip archive

The best way to achieve these requirements is to create a zip archive with just the mimetype file in it, using no compression when you add it, and then to add in all the other files later, with compression. Encryption is an issue I won't even begin to get into here.

THE CONTAINER FILE

Like the mimetype file, the container.xml must be named exactly that. In addition, it must be in a folder named META-INF, so that the OS knows where to find it. The sole function of the container file is to tell the device where to find the .opf (which seems a somewhat redundant step if you ask me). Looking inside the container.xml file here is what you'll see:

This is the first of many files where we need to explain some things to the computer so it understands what we're saying and what to do with the information.

The first two lines are declarations, stating what language we're speaking and giving a namespace reference (xmlns), which is a specific set of operating rules, more or less:

<?xml version="1.0"?>
<container version=1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">

Within this is contained the rootfile path, which as I said tells the system where to look for the file that contains a listing of the ebook's contents, and what type of file that is:

<rootfile full-path="OEBPS/content.opf" media-type="application/oebps-package+xml"/>

Looking at our file structure above, you'll see that the content.opf is in the OEBPS folder, just like our path data says here. This file can actually be anywhere and named anything you like, so long as you say so here. The media-type, however, must read exactly as given, since it describes the target's file type, which is an Open eBook Publication Structure (OEBPS) package written in eXtensible Markup Language (XML). We'll talk about the .opf itself later. Be sure to include both the </rootfiles> and </container> closing tags as shown in the image.

THE COM.APPLE FILE

This is a file completely unique to Apple's iBooks, which consists of a set of display options that tell iOS devices how to present the content. I've included all of the triggers that I am aware of in the template file, along with some notes (in green) giving the allowable choices. However, the only ones required are these:

<display_options>
<platform name="*">
<option name="fixed-layout">true</option>
</platform>
</display_options>

The platform name "*" means all devices, with the only two other options being either "iphone" for handheld devices only (including the ipod touch) or "ipad" for tablet only content. This allows you to specify different display options for different platforms. I'll give an example using the remaining options:

<display_options>
     <platform name="*">
          <option name="fixed-layout">true</option>
          <option name="specified-fonts">true</option>
     </platform>
     <platform name="ipad">
          <option name="open-to-spread">true</option>
          <option name="orientation-lock">landscape-only"</option>
          <option name="interactive">true</option>
     </platform>
</display_options>

So here we have one set of options that apply to all platforms and three that apply only to the ipad. This would create an ebook with a fixed-layout and custom fonts on all devices, but which would only open as a spread on the ipad, and only in landscape mode, and which would have its interactive content disabled on handheld devices (since "true" is only chosen for the iPad and "false" is the default).

Most of these have "true/false" choices, with "false" as the default. Taking them one by one:

• "fixed-layout" [true/false] - this must be set to "true" for any of what we're about to do to work. This is the tag that tells iBooks to use fixed-layout properties, and so is required.
• "specified-fonts" [true/false] - you can embed your own fonts into your ebook if you want something beyond what's offered on the ipad, although you must have the appropriate rights to do so. More on this when we get into the fonts folder.
• "open-to-spread" [true/false] - this tells iBooks whether or not to open to a full two-page spread or zoom to a single page size, and is set to "false" by default. However, "false" does not mean you'll see only that single page, but that the starting page will be zoomed to its largest possible height or width, with the opposing page content flowing beyond the edges of the frame. Depending on the size of your book's pages you may see most, if not all, of a two page spread in non-spread mode, particularly in landscape orientation. And most unfortunately, for a cover image the left page will still appear, it will just be blank. This has been fixed in the new .ibooks format, but here there is no way to have just the cover itself appear, nor is there a way to place rear cover content on that blank left page. See my Ring Saga sample for my work around to that. With this option set to "true" you'll see the full two-page spread no matter which way you turn the device. Which brings us to...
• "orientation-lock" [portrait-only/landscape-only/none] - this allows you to choose just one orientation in which your ebook can be viewed, which can be beneficial if your book has odd sized pages (such as a photo album with pages wider than they are tall), or you're aiming for handheld-only devices only where you might want single pages viewed in portrait mode only.
• "interactive" [true/false] - this is an option which allows scripted content to be added and made active. Again, "false" is the default setting, so you must tell it if you're adding scripted content such as java or canvas. This does not apply to anything that's inherent in iBooks itself, such as pinch-and-zoom or tapping and swiping, but only to more complex content such as finger-painting or movable images that require scripted code.

As mentioned, aside from the "fixed-layout" option itself, you only need to add in others if they apply to your book. Just leave out the rest. But this gives you some leverage in how your work is presented to the world, which can make a lot of difference.

So that's it for the META-INF folder. There are other files that can find there way in here, but none you'll need to mess with, as they mainly involve encryption controls. Some ebooks will put in manifest and metadata files here, but those are best left in the .opf where they belong (and are required). These are all you'll need for now, and that's as far as we'll be going for the moment.

NEXT UP: Creating Your Content

Call for Beta Readers! Rhinegold, Chapter 1 - iBooks Edition

For anyone with an iPad who is interested, you can now download the opening chapter of my illustrated novel project The Curse of the Rhinegold in fixed layout format for iBooks. The file is available for free for a limited time, so get your copy now before it's gone.

The story is based on Richard Wagner's opera The Ring of the Nibelung, which is itself based on old Norse mythology, and was used by Tolkien as both source and inspiration for his Middle Earth stories. While I'm following Wagner's basic structure, I'm also bringing in a lot of the mythological material he left out, including ultimately the final apocalypse of the world known as Ragnarok.

The book is an experiment in creating a full color, fully illustrated novel for an older audience. I use the term graphic novel loosely, since this has come to denote a longer work in the comics medium. But I have never liked dialogue bubbles, and prefer considerably more narrative than standard graphic novels offer. So my intention here was to try and bridge the gap, to present a proper novel in a highly illustrated "graphic" format. I look forward to your feedback, as it will help me determine if the project has been successful, and to shape its future course.

Chapter 1 is 22 pages long, plus full jacket cover, title page, and an afterword addressed to beta readers. The file is 24.2 megabytes, optimized for the highest quality graphics, with images at 1788 x 1118 pixels (just under 2 million pixels each) to future proof them against increased screen resolution in the coming months. This project is an experiment in creating a full color, full bleed illustrated fantasy novel for a older audience (i.e. it is not a children's picture book, although young adults have read and enjoyed it so far). You can learn more about it on the Fantasy Castle Books website, or just download it and have a look. It won't cost you anything but time.

As with the initial PDF file, I'm extending the beta reader offer to this new iBooks edition. To anyone who sends in a review or critical comments on this chapter I will send a limited edition autographed chapbook of this section, as well as the next chapter in iBooks format as soon as it's complete. The second and subsequent chapters will not be made available online, and will only be free to those who have reviewed the earlier sections. For each chapter you critique you will receive the next one free. For those who send in comments or reviews on all five chapters of Book One, you will earn a signed print edition of the final published book, as well as the finished ebook in the format of your choice.

For more details see the final pages of the sample chapter download.

UPDATE 1/23/12:

For anyone who downloaded the file yesterday but only got a corrupted file, the sample chapter has now been moved to a new host, as Yahoo has doing something funky to zip/epub files. I'm in the process of moving my website to a new host, so I'll update the links as soon as possible. For now you'll have to use the external host's link. Sorry for the inconvenience.

UPDATE 3/2/12:

The newly updated "Version 1.1" sample chapter is now uploaded to my new web host. Some minor text corrections and a new Table of Contents are included. Beta test info pages have been removed, but the offer still stands.

How to Create Fixed-Layout iBooks, Part 1

With the new iBooks Author application only available for Mac users, the vast majority of us are left to fend for ourselves when it comes to making fixed-layout ebooks. This is probably just as well if you're at all like me and prefer to do things yourself and have complete control over the end result, although it's not all that difficult if you take it step by step and have a fair amount of patience (and good attention to details). While iBooks Author looks like it has some nice features, it requires a trade off in rights to the final product that I'm not willing to make just yet, particularly when there are other options available.

For the past few months I've been working out how to build fixed layout ebooks for the iBooks platform in order to replicate the layout I've created for my illustrated novel project, The Ring Saga. Since my intention is to produce the four-volume series as a full-color print edition in the standard 5.5" x 8.5" "perfect bound" format as well as in various digital editions, I needed to produce the art and page layouts in the print edition aspect ratio and reproduce them as ebooks from that. For a full color, heavily illustrated project such as this, the iBooks fixed layout format for the iPad was the obvious place to start when it came to creating the digital editions.

WHAT IS FIXED-LAYOUT?

The essence of a fixed-layout ebook, from a practical point of view, is that - as the name implies - it allows for the creation/replication of exact graphic design layout which the reader cannot alter, as opposed to the standard "reflowable" formats which allow the end user to change the font and text size, for example. This is incompatible with highly formatted layouts such as graphic novels and magazines, and simply unacceptable to many graphic design departments who've spent decades (if not centuries) refining the arts of composition, typography, and illustration.

Fixed-layout also allows for "full-bleed" (edge-to-edge) artwork and the layering of multiple elements on top of one another, placed precisely using XML, a relatively basic subset of HTML, and CSS for styling. You don't need to know very much of this code to make an ebook work, but of course the more you do know, the more complex and stylized your formatting can be. iBooks also allows both javascript and canvas for incorporating interactive elements, although this requires a far more extensive knowledge of those programming languages than the average author generally has. I'll include a few examples of scripting code that you can copy and customize for your own use as we go along.

Apple's fixed-layout iBooks format is an ePub file with a few additional options and requirements that make it only viewable on iOS devices, but also incorporates all the nice features inherent in the iBooks app, such as pinch and zoom, animated page turns, and automatic reorientation. Both Barnes & Noble's NookColor/Tablet and Amazon's Kindle Fire have fixed-layout formats, but B&N have thus far been very restrictive in allowing anyone but trade publishers to use their format, and Amazon have only just recently released the specs for their new KF8 format, which is still a work in progress, with the comics portion still forthcoming. And of course they both only have 7" screens, which is too small to adequately display more than a single book page at a time. This is not prohibitive, but it isn't ideal either, particularly if you want to reproduce the two-page layout of a print edition.

THE TEMPLATE

My intention here is to share enough of what I've learned to aid you in producing your own fixed layout iBooks from scratch, without the need of an app or conversion service to do the work for you. To make this easier, I've created a sample template file that you can download and use as the starting point for your own projects. In a series of subsequent posts I will break this file down into its component parts and explain them as plainly as possible, giving examples of the various code elements and describing the options available for each.

RESOURCES

There are some good resources available to assist in learning the fixed layout format, but none of them discuss in much detail the formatting options allowed or the reasons for them. I'll try to do that here. But I won't go into HTML or CSS beyond the necessary basics, and a few specifics that apply to iBooks, since the rest is common web code known to most, or easily learned elsewhere. In addition, I won't be discussing anything that applies solely to standard "reflowable" ebooks, or how to format your manuscript with headings and sections and the like. This tutorial is to help you create an illustrated ebook with "live" text, such as a children's book or graphic novel, for the iBooks platform. I plan to do subsequent tutorials for the Kindle Fire's KF8 format, and the Color Nook tablets, if interest warrants.

Before we begin, here are some useful ePub resources you might consult:

• International Digital Publishing Forum (IDPF) - complete ePub specs reference
• MobileRead ePub Wiki - discussion and examples of the ePub file structure
• ePub: The Language of eBooks - A Primer - guest post by Iris Febres explaining ePub
• Build a Digital Book With ePub - tutorial by Liza Daly of ThreePress
• HXA ePub Format Construction Guide - outdated and overly complicated, but informative
• JediSaber's ePub Tutorial - A bit antiquated, but filled with useful information

When it comes to fixed-layout iBooks specifically, the resources are more scarce:

• iBookstore Asset Guide (PDF) - Apple's own documentation, which includes a very sketchy section on creating fixed-layout ebooks
• How To Make An iPad Photo Book - the only online tutorial I've found on the subject, with just enough to get you started
• Liz Castro has a book out about making ePub files, with a fixed-layout supplement available for five bucks more. Also be sure to pick up her Read Aloud mini-guide, if only so you can take a look at her Aesop's Fables sample.

Other than that, there isn't much information available on how to produce high quality iBooks in this format. I'll cover the essentials, but knowing more about the underlying ePub format is recommended if you really plan to get your hands dirty. To that end, there's nowhere better to go than the IDPF site, where you can read through the entire code specification top to bottom. It's pretty dry reading and hard going at times, but quite enlightening nonetheless.

NEXT UP: The File Structure

iBooks Author Update

So my initial reaction to the release of iBooks Author yesterday was essentially one of frustration. What at first appeared to be a reasonably decent - even exciting - application for creating ebooks for the iBooks platform was quickly rendered mute by its virtual unavailability to the vast majority of computer users, including me. So utterly idiotic was Apple's decision to make this a Mac-only app that it completely overshadowed all other considerations at the time. It just seemed so plainly obvious to me when advance reports began to leak of Apple's intention to seriously compete in the ebook market that the only logical move that made any sense at all to me would be to open up the iBooks platform to a wider audience of content creators as Amazon have done so successfully.

But Apple's intention was, in fact, to make content creators come to them, and not the other way around at all. The astounding stupidity of this is just mind-boggling beyond belief. To think you have that kind of clout when you hold less than 5% of the market you're aiming at is one of the most misguided business notions I have ever heard (and there has certainly been plenty of stupidity in the business world of late). To create a product almost no one can use and expect it to somehow alter the fabric of reality is just complete insanity.

What I hadn't really given due consideration to was the fine print in the end user licensing agreement, which stipulates quite clearly that any content created using iBooks Author can only be sold via the iBookstore: that is, not on Smashwords, not on your own website, not anywhere else...ever. Like many (if not most) potential users I more or less blew this off. Since an iBook can only be read on an iOS device it didn't seem to make all that much difference, as the iBookstore is obviously the best place to sell that content. After all, you can purchase Kindle ebooks all over the place, but the place most readers purchase them is right on their Kindle. Why not the same for iBooks? The difference, of course, is that Amazon does not require you to sell Kindle ebooks on the Kindle, or even on Amazon at all, and aside from the exclusive Library Lending program, you're free to sell them anywhere.

But Apple are taking a different tack entirely, one that might be called totalitarian by some, and just plain dumb by any moderately educated business analyst. Perhaps they think that just because they've made the application free people will rush out and buy their relatively overpriced hardware in droves so that they can use it. And maybe they're right. But I highly doubt it.

The more real and serious implications of this move were pointed out quite clearly in a post by Dan Wineman over at Venomous Porridge yesterday, which boil down to the fact that Apple are in essence claiming sole rights to all output from its software, not just to the use of the software itself. This has vast legal implications for creative content beyond just this instance, which could set a precedent for digital content that might have lasting repercussions that are difficult to reverse. More importantly, it has immediate and practical implications for authors who want to retain full rights and control of their work. If you create content via iBooks Author then Apple gain sole and final distribution rights to that work. One can only imagine the lawsuits just waiting in the wings the first time an iBooks release becomes a million seller and that author wants to add the book to other platforms, or sign with a traditional publisher for worldwide publication rights.

As I mentioned yesterday, I had ordered a Mac Mini in order to upload my content to the iBookstore. Today I cancelled that order. Not only that, but I've started writing a tutorial on how to create your own fixed layout iBooks using a template I have uploaded to my website. I'll post the first part tomorrow, and continue so long as there is interest.

iBooks Author: Awesome & Disappointing

According to many news headlines, Apple "made their bid today" for a larger presence in the self-publishing space with the introduction of iBooks Author, a Mac app that lets content creators do just that: create rich, interactive ebooks with a simple drag-and-drop interface. The new tool was launched at a New York press conference this morning, along with iBooks 2 and an upgraded iTunes U, both of which now feature enhanced textbook sections, as Apple follow up on Steve Jobs' desire to reinvent the education space with digital content.

But while iBooks Author does indeed look promising, it leaves a great deal to be desired, both in terms of functionality and accessibility, and one must question whether it can ever hope to achieve what these latest headlines are touting. While the Author app will likely prove more than adequate for the majority of book content creators, it's essentially a dot-to-dot, fill-in-the-blanks production tool, with templates that are bound to make a lot of its output look alike. For textbooks and most standard fiction this is fine, but it eliminates much of the creativity involved in making content with complex layouts. Based on the promotional images and video released today, it appears to handle full-page images with overlaid text to some degree, and the image word wrap function is impressive. But the font selections are limited to those available on the iPad, and interactivity is little more than simple pinch and zoom and standard tap functions that trigger events like photo galleries and videos. Rotating 3D models are interesting, in a limited way, but I'm curious to see how the glossary feature works, and there's a lot that can be done with layered images and some scripting if you know how (java and html code are allowed, but not something many authors are familiar with). But of course, I can't really know how well it works, since I'm unable to use it. Which brings me to my main point, concerning accessibility.

Source: netmarketshare.com

The primary mark against iBooks Author as a useful tool for content creators in general, and self-published authors specifically, is its immensely restricted availability: it's only being released through the Mac app store, for OS X Lion only (not even Apple's own iOS), leaving 93.6% of the world's computer users out of luck. Had Apple at least made it available as an iPad app they could have targeted well over half of the tablet market, particularly given that their Pages word processing app is already on there, providing authors with all the tools they might need to create rich content for the iBookstore right on their iPads. But with only 6.4% of computer users (and thus, one must infer, authors) having access to a Mac, one can hardly call this a "bid to own publishing's future," as today's L.A. Times business section put it. The figures are even more skewed in the education field that Apple seems to be aiming for here, with less than 5% of schools and offices using Macs.

Still, it's a really sweet looking piece of software which is bound to lure in at least a few new Mac OS users. I can say that with some certainty because I bought my first Mac today, in the form of a Mac Mini, which is about the cheapest you can get into an OS X product. I had been contemplating this for some time, not as a jump to Mac, or even because of this new app, but simply as the only practical means of uploading my content to the iBookstore when it's ready, since iTunes Connect is also only available for the Mac. People complain about the proprietary nature of Amazon's Kindle format (with some justification), but Apple is truly even worse, since you can at least read Kindle ebooks on other hardware via apps, and Mac users can create and upload Kindle content. Not so with Apple. With them it's Mac or nothing. Which is why they have just 4% of the ebook market currently, and will never come close to competing with Amazon in terms of publishing. They may sell a lot of tablets, but they'll never sell very many ebooks until they open up the platform to all of the people who produce them.

You can learn more about this new app and view a promo video on the iBooks Author page.

Ebooks Take Over USA Today Top 50

This is part of a new graphic put out by USA Today this week, showing the rise of ebook sales up the bestseller charts. The full chart shows dates running back to July 2009 when Amazon's ebook sales were first added to the bestseller charts, but entries in the top fifty were essentially non-existent until last January, so I haven't included that portion of the chart here. However, you can click though on the image to view it over at USA Today.

The only important points missing from the truncated chart above are the inclusion of Barnes & Noble ebook sales in December of 2009, and Sony's in February 2010, plus the singular event when I, Sniper by Stephen Hunter became the first ebook to crack the top 50, coming in at #48 on January 1st, 2010.

Points noted on the chart above include:

1. First ebooks crack the Top 10 as post-holiday sales explode
2. Kobo ebook sales added (no significant impact in the U.S.)
3. Ebook sales begin to dip as holiday shoppers buy print books as gifts instead (and a whole lot of e-reading devices)
4. Ebooks outsell print editions for every title in the Top 10, including 42 of the top 50 best selling titles

As with this week last year, ebook sales have increased exponentially after a holiday season in which literally millions of new e-reading devices were received as gifts. Forrester Research estimates that Amazon has sold some five million Kindle Fires since its launch in mid November, with Barnes & Noble adding two million new Nook Tablets to the fray. Apple, meanwhile, sent out around forty million iPads last year, although it's difficult to determine how many will be used to read ebooks.

With digital editions overtaking print for the top spots on the bestseller charts, print is destined to decline even faster in the coming year, as print sales have largely been held up by the million-selling titles. Initial figures from the U.S. Census Bureau show that print sales fell by 9% in 2011, due in part to the demise of Borders, who sold their final book in September. But if post-holiday ebook sales remain as stable this year as they did throughout the past year, ebooks might well achieve market dominance this year.

Amazon Reveals Library Loan Royalties

In a somewhat unprecedented move, Amazon has publicly revealed some very specific financial figures in a press release today. These concern the Kindle Library Lending Program and its fledgling counterpart, Kindle Select, in which authors are given a share of a half million dollar pot each month for every ebook they have enrolled in the program that is borrowed, based on the total number of loans that month.

December was the inaugural launch of the Kindle Select program, and until today no one knew how much to expect each loan to earn, as there were too many unknown variables, such as how many total loans there would be, how many titles would be enrolled in the program, and how those loans would be distributed among the current offerings. Would the top ten ebooks get the lion's share? Would everybody get a little? And how would anybody really know if Amazon never offered up the numbers? I floated some estimates in a post last month, but made no predictions. Amazon used the figure of 100,000 ebooks borrowed for their example.

The actual figure was 295,000. Thus, dividing the $500,000 pot by 295,000 loans results in a payout of $1.70 per ebook borrowed. And thus ends the speculation.

Now let me put that in perspective a bit. On a $2.99 ebook with a 70% royalty, an author receives $2.09 for each book sold, minus the download fee, which is .10 cents per megabyte. My "Complete Edition" ebook is 2.31 Mb, so .35 cents is taken out, leaving me with $1.74 - only four cents more than I now make when the book is loaned instead of purchased. This effectively increases my revenue, and brings new readers to my work. It's a win-win situation.

Let me put it in even more perspective. On a .99 cent book with a 35% royalty (the only royalty allowed for that price point), the author receives .35 cents. Total. But for each time that same ebook was borrowed in December, they will receive... yep, $1.70. More than the cost of the ebook. Nearly five times the royalty paid out for a sale of that same ebook. Thus, rather than having to sell 100 books you can now loan out just 20 and make the same amount of money.

Now let me put this in another light. The average royalty for a traditionally published author is 10% on hardback sales up to 250,000 copies (12-15% for higher sales volume), and 6% for paperbacks. Minus 15% taken by the agent. Thus, for a $25 hardback the author receives $2.13 per copy sold ($2.50 minus 15%), but only when and if their advance has earned out (a $20,000 advance, for example, would require sales of over 9390 copies to start paying royalties; until then the author receives nothing beyond the advance). For a hardback book sold to a library to loan out innumerable times, that author receives... yep, $2.13. Total. Regardless of how many times that book is taped back together and checked out of that library. And that hardback is only available for sale for a short period of time, giving them a small window of opportunity to make that advance. After the paperback comes out our same author receives an average royalty of 6%, which on the average $6.50 title is just .39 cents... $1.31 less than our ebook author has just received for loaning out their title via Amazon.

For anyone that doesn't understand what Amazon is doing here, let me spell it out: they are buying authors. They are drawing authors in and stocking their shelves with exclusive content by paying out the best royalties in the business, giving them the best terms, the best tools, and the best distribution platform you could ever want: instant access, everywhere. Because of this, 75,000 titles are now enrolled in the Kindle Select program, up from 5000 available on launch. Exclusively. Meaning, you can't get those ebooks elsewhere. That is a requirement of the program.

And, just to make it more enticing, they have now just sweetened the deal: $200,000 more has been added to the pot for January, bringing the total to $700,000 that will go out to authors enrolled in the Kindle loan program this month. That would bring the royalty for those same 295,000 borrows to $2.38 instead of $1.70, more than the average traditionally published authors earns for selling hardbacks.

Of course, the more hardbacks an author sells, the more they earn. In this case, the more ebooks are loaned out the less each one earns. But for those that are loaned out in large numbers, the paycheck can be quite nice. Today's press release offered a few examples:

• The top ten borrowed authors earned a total of $70,000 in December
• Paranormal romance author Carolyn McCray received $8250
• Romance writer Amber Scott's paycheck will be $7650
• 16 year old children's book author Rachel Yu will get $6200
• Plus, sales for KDP Select authors have risen by an average of 26%

Other publishers and book distributors are going to have a really tough time competing with this kind of stuff. Complain all you like about the megalithic empire that is Amazon, I defy you to name a single other entity that has done so much to get so many books in front of so many readers, and pay those authors for it.

Oh, and by the way, my payday will come to just a little over twenty dollars.

KF8 & KindleGen2 Released

Amazon today finally released to the public the long awaited and much anticipated tools to produce ebooks in the new KF8 format, including a new Kindle Previewer, an upgrade to KindleGen 2, and a plug-in for InDesign that allows for KF8 export (minus a few of the enhanced features, such as Text Pop Ups and Panel Views). Links to each of these are provided below, as well as the associated documentation.

In addition, Amazon sent out a new survey to self-published authors today, which seeks to gather data on what they are looking for in a self-publishing service, what their past experiences have been, if any, with their own or other services, and asks for ratings of Amazon's offerings in this area if any have been used. So collectively it appears as if Amazon are poising themselves to actively champion the self-publishing cause, via a new enhanced format, new devices on which to distribute them, the tools with which to create them, and information on how best to serve the needs of content creators. I have, of course, completed the survey, with ample notes and commentary.

With the new format specs and tools having just come out today, it will take me a few days to sort through it all and test it out. I have nearly completed an iBooks fixed layout edition of my opening sample chapter, which I plan to upload early next week for your perusal, and as soon as I work out how to create an accurate KF8 version I'll upload that as well. Meanwhile, here are the links Amazon provided today, should you wish to go cavorting through some ebook code yourself...

• Kindle Format 8 Home Page - now includes links to the Previewer, KindleGen, and Guidelines
• KindleGen2 - Comand-line application for creating KF8/Mobi ebooks from X/HTML and EPUB
• Kindle Previewer - Graphic interface for the viewing, converting, and validation of KF8 ebooks
• Kindle Previewer documentation (PDF) - just in case you want to read it first
• Kindle Publishing Guidelines (PDF) - newly revised to include the KF8 format, with complete instructions on how to self-publish on Amazon
• Kindle InDesign Plugin (Beta) - includes KF8 support, minus enhanced features mentioned above, but with updates to be forthcoming
• Kindle Plugin for Adobe InDesign documentation (PDF) - again, for perusing first to see if it's what you need
• Simplified Format Guide - A step-by-step online reference for building KF8 ebooks from Word documents (the link to an HTML-based version isn't currently working)

More info will be posted as I have it.