Beating iBooks Bugs

Yesterday and the day before I spent an inordinate amount of time doing trial-and-error testing with iBooks 1.1's latest bugs. Basically, if the default Full Justification is left ON in the Settings panel for iBooks, iBooks then overrides any left alignment setting specified by the book designer. Indeed, center alignment is often disregarded as well.

I posted my fruitless efforts to this blog and shared them on Twitter in the amazing #eprdctn group, and this morning found that others had worked on this problem and found a solution. I am in awe of the cooperation, generosity, and sticktoitiveness of this group. Thank you!

There are two parts to the problem. For some reason, iBooks ignores the text-align property when that Full Justification setting is ON. It is also known that iBooks ignores any font information set with the span tag.

The solution, discovered by Anthony Levings, is curious. Just by inserting empty span elements (no class necessary) within each and every p element, and without assigning a single CSS declaration to the span itself, iBooks suddenly pays attention to the text alignment settings in the CSS of the p element.


Rick Gordon, meanwhile, reminded us of The Span Bug: iBooks ignores font information applied through a span element. Rick suggests using some other element besides span, like the otherwise little-used cite, so that you also maintain a given font for the body of the ebook. And while it is true that using an element in this way is a hack, it is also true that the resulting ePub will validate, will have the font the designer intended, and will not break in other ereaders. It is also true that if Apple would follow the EPUB standard, these hacks would be unnecessary.


It's important to remember that (according to the official CSS spec) the text-align property only works with block-level elements, so it must be applied to the p selector. On the other hand, since iBooks doesn't support applying font information to a p, div, or span element, you must declare the font information with the cite element. In addition, many ereaders/browsers apply italics to cite by default, so you'll have to add font-style: normal to neutralize that effect.


It is my personal opinion that standards are an extremely important tool and that software manufacturers (read: ereader and web browser creators) should follow the published and specified standards so that those of us creating content can be confident that what we create will work in as many ereaders/browsers as possible and be compatible not only with current but also with future versions of the software. It is only when we all agree on the rules that this is possible.

When those software manufacturers don't follow the rules, I believe we content creators have the liberty to work around those deficiencies, but that we should do so in the most standards-compliant way possible.

So, in this case, Apple doesn't follow the EPUB spec that it says it supports and ignores a perfectly valid CSS property, text-align. Designers add in fairly harmless span elements that solve the problem. I call that an extremely reasonable compromise. 

Apple doesn't follow the EPUB spec in allowing span elements to convey font information. Designers use less common XHTML elements in a non-semantical way to resolve the issue. I am less comfortable with this solution, since using those elements in non-standard ways deprives them of their true meaning. Nevertheless, since those elements are rarely used anyway, I'm willing to go with this compromise as well.

You will have to make your own judgment.

And if you want to learn the latest in ePub creation techniques, or share some of your techniques with the rest of us, come visit us at #eprdctn!

iBooks is Buggy

Frustrated with iBooks refusal to play nice with text alignment and with fonts, I downloaded a new book from Gutenberg, Mark Twain's The Jumping Frog, and started fresh. I created the simplest of simple InDesign files, without adding any formatting at all, and then exported the whole thing to EPUB. It was pretty ugly.

One of the things that I haven't understood about the whole Apple-neglects-to-support-standards debacle is how their iPad User Guide (download it from the iBookstore) stays left-aligned even when I've got Full Justification set to its (absurd) default position of ON.



How do they do it?

There's no clue in the CSS. Not even so much as an !important: (And don't imagine that that text-align:left should have an effect; iBooks ignores it in favor of the Full Justification position in the iPad's general settings.)



Grasping at straws, I tried using Apple's style sheet with my (ok, Twain's) text, changing only the classes in my p elements to match the styles in Apple's CSS.



iBooks was clearly not fooled.

I took a step back. I changed only two paragraphs in my XHTML file, one header and one paragraph. And lo and behold iBook suddenly remembered how to style a paragraph with a different font:


How can that be? That's the exact same CSS and the exact same XHTML, except that instead of all the paragraphs being marked with the main body text class, only one of them is. There is nothing significantly different.

But look how not only the font is maintained, but also the left alignment. (In all of these examples, Full Justification is ON in Settings.)

Was it only Apple's lovely choice of Verdana? No, I could choose other fonts, like American Typewriter.

Was it the style names themselves that held some sort of magic? No, I could create my own style names with the same style definitions that Apple had used.


Was it the style definitions? No, I could use style definitions that I had used on other projects.


What then? I stopped fussing with the CSS and started fussing more with the XHTML. This time I tried formatting several more paragraphs. It still works:



Emboldened, I try a few more pages:


They still work. I push it just a little further. And I hit the wall. All I changed was the class of a few more paragraphs in the XHTML, and suddenly, all I get is Palatino, full justified, throughout the book, from the first page to the last.


There are some interesting things to note here. First of all, that same paragraph that now appears in Palatino was not altered at all between the penultimate test and this one. I only changed the classes in a few paragraphs at the end of the document, and that is what triggered the loss of all of the font and alignment formatting.

Further, note that the leading and font-size are maintained even as the font family and justification are lost.

I spent all day working on this, and didn't find a solution. I'm not sure there is one. I think its just a buggy program. I'm curious as to why Apple's iPad User Guide doesn't show up in the specified font, but still stays left-aligned. I haven't figured that out yet. In my tests, the font formatting is listened to at the same rate as the alignment.

For those who would say, "Apple recommends not choosing fonts" I would point out that they themselves choose fonts for their own publications, including the iPad User Guide.

And to those who marvel at this waste of time, I would caution that we must all speak up for standards, lest you soon join me in this fruitless exercise of trial and error.

Pigs, Gourds, and Wikis

I've been meaning to explain the name of my blog for some time now. It may seem like a very strange name, given the focus on all things EPUB lately. I mean to write about the other parts of the pigs, gourds, and wikis triad, really I do. You see, I live on a farm, and we raise chickens, sheep, cows, and an occasional pig, though there are no pigs this year since we're about to move to Barcelona for a spell. We have had as many as 75 chickens at once (50 for meat and 25 laying hens), and this year we got our first calf, Julieta.

That means we're milking once a day (and letting Julieta do the evening shift). Though “we” is a misnomer, since I've been holed up in my office tending to the “wikis” part of my life pretty steadily for the last four or five months.

The gourds piece is the part of me that loves to create things. When I started this blog, I was growing, drying, cleaning, carving, and painting gourds, not necessarily in that order. I had a short-lived run at selling them too, though that wasn't nearly as fun as making them. The problem is that now I have big boxes of beautiful, but neglected gourds. But on other days I've been known to sew, and to knit, to weave, to garden, to make crazy snowflakes out of origami paper, and to write web pages.

These days, however, all the focus seems to go to the wiki part of the trio. I'm busy writing a book on EPUB, or how to create electronic books that look especially good on the iPad and as good as possible on less graphic environments like the Barnes and Noble Nook, or even Adobe Digital Editions. Just for the record, “wikis” is more a metaphor than anything else, though I did create an exhaustive guide to iPhoto Book Themes using a wiki for structure.

Standards ≠ Control

To be clear: the argument over standards is not the same as the argument over who should have control over what an ebook looks like, whether it be ereader device manufacturers (Apple)? ebook designers (Penguin)? or human readers (you)?

The argument over standards asks whether we are willing to agree as a community—both ereader manufacturers and ebook publishers—to agree on the rules for creating and displaying ebooks so that the ebooks that we create and sell don't break after a week of use.

Apple Makes Full Justification Worse in iBooks 1.1

One of the big complaints about iBooks 1.0 was that books were automatically full-justified, that is, spacing was added between words—with no help from a hyphenation dictionary—so that the margins on both side would be even. Honestly, it looked pretty gross, with rivers of white space running down the center of text.

Thankfully, for all involved, it was pretty easy for a book designer to remedy the situation. eBooks are written in XHTML and CSS, and CSS is quite handy at specifying left-justification: text-align: left. Problem solved.

Enter iBooks 1.1 last Monday. Apple hid a switch deep in the bowels of the general Settings that lets readers turn off Full Justification, which is still on by default. Perhaps the idea was to give readers more control, but then why hide it? Who knows how many people will find that switch, my guess is about 14.

Meanwhile, the real damage is that with iBooks 1.1 Apple took away the book designer's power to choose left-justification for their books. Designers can choose centered text, and even right-aligned text, but left alignment is totally ignored (even with !important) It makes absolutely no sense at all. It's bad enough for a paragraph of text, but short lines (poetry or lists) look particularly awful.



And to all those who would trumpet the rights of readers, you should know that the upshot is that MORE readers and not less will have to contend with those rivers of white space running through their books. It's pretty ironic that a company so careful about its own design should have screwed this up so completely. It really does beg the question of whether any iBooks programmer has ever read a book on screen.

Here's what Apple should have done. First, they should make the defaults be anything they want, that's their prerogative. Second, they should let book designers override the defaults so that we can design beautiful books for those readers who are not inclined to design their own. Finally, if they want the reader to have more control, Apple should offer an easily accessible switch to human readers to override both Apple's and the book designer's style choices and, if desired, choose their own. While they're at it, maybe Apple could look into the hyphenation dictionary.

Apple damaging ePub standard with pseudo-support

I have been amazed by the number of people who have commented on yesterday's post, Apple kills fonts in iBooks, strikes blow to standards, with some variation of

"it's better for Apple to limit font choice because ebook designers will make unreadable, ugly designs we can't live with"

I'm just wondering if those folks think there should be fonts at all. Perhaps we should require a license before one is allowed to choose a font. And how did we miss the boat on print designers? They've been running wild!

Here's the thing. Fonts exist. They exist because we humans like variety, we like experimenting, we like design. And if you don't like it, you don't have to buy it. Printed materials have been going on this premise for hundreds of years, and no-one has had the temerity to suggest that Apple should decide what fonts they use!

But there's more. Apple says it supports the ePub standard. The ePub standard requires support of the font-family property. But Apple supports the font-family property only for some parts of a book, notably leaving out the ones that make it easy to style the body text. (And, it should be noted, iBooks does support adding all sorts of other kinds of formatting to the body text with no compunctions at all: color, size, bold and italic... don't tell those dastardly designers!)

But that doesn't mean you can't choose a font for the body text in iBooks 1.1. It just means you'll need an ugly, non-standards-supporting hack to do it. It would be one thing if Apple, like some other ePub readers, didn't support fonts at all, but it's quite another to support fonts in this completely non-standard, hack-inviting way.

This not only is annoying in a paternalistic, "I know better than you", sort of way, it will end up damaging the ePub standard, and costing extra time and money as designers, once again (have we really forgotten IE5 already???), create multiple designs to work in different ways on devices that supposedly should just work.

My bet is that there are a fair number of people who prefer a well-designed book to one in a generic font with full justification and no hyphenation. Just go to a bookstore and see for yourself.

Apple kills fonts in iBooks, strikes blow to standards

Oh Apple, what are you doing? So misguided. You add DRM to all your ebooks. And now, you have crippled iBooks 1.1 so that it won't recognize fonts applied with perfectly standard CSS to any body, p, div, or span element.

Your guidelines state that ebook designers should not choose fonts, stating that it "creates a bad user experience". You are wrong. Apple designers choose fonts for everything Apple does. Because fonts matter. Indeed, you have chosen the fonts for iBooks and for the iPad. And now you have chosen to keep ebook designers from choosing the body font for their ebooks. It is a very shortsighted decision.

The ePub specification requires that conforming ereaders, like yours purports to be, support font-family, among other CSS 2.0 properties. Indeed, you do support font-family for most inline elements, like b, em, code, and even some block level elements like dl and li. Why then not the biggies: p, div, and span?

Your desire for control will ultimately break these standards or it will break iBooks. It will break standards as it incites designers to use ugly hacks to overcome iBooks' broken support for standards. It will break iBooks as people design beautiful standards-compliant ebooks that look great in other readers that support standards.

Or should we just go back to Internet Explorer 5?

Here is a screenshot of a number of elements, all of which are styled with the following declaration: {font-family: sans-serif}. Here is the XHTML file and the perfectly standard CSS on which the ePub is based. Click on it to see, in a standards-compliant browser, what it should look like (hint: everything should display in a sans-serif font). Or download the ePub file itself to your own iPad.



[updated June 24, 9am] Just in case it wasn't clear, the example above is not meant to be an ebook design, for goodness sake! It is the simplest possible example that shows which elements can be modified with font-family in iBooks 1.1. The "Ew" in the screenshot means "iBooks is disregarding standard CSS" NOT "I don't like serif fonts".

More on Choosing Fonts for iBooks on iPad

[Update: With iBooks 1.1, Apple has changed much of the system for applying fonts. Please read Apple damaging ePub standards with pseudo-support and Apple kills fonts in iBooks, strikes blow to standards.]


Generally, a designer sets the font for an iBooks ebook by adding a font-family rule to a p or div selector in the CSS style sheet. In an earlier article, however, I noted that the reader can override such choices by choosing a new font in iBooks' font menu.

David Mundie found that not all the text is affected by choices the reader makes in the font menu. In fact, he found that if you specified the font in something other than a p or div, say, with em, strong, blockquote, or li, etc., the font persisted, even when the reader chose a different font.

David had also discovered that you could use the ancient font tag to make font choices persistent for a bit of text. And although I found that interesting, I couldn't quite get behind using that long deprecated tag.

At the same time, I found a different problem. First, iBooks completely ignores font choices applied via a span tag. Second, and somehow more disturbingly, if you apply a font to a particular paragraph via a p or div tag, and then try to use span to apply any characteristic (even color) to a bit of that text, iBooks applies the new characteristic, but loses the font choice, reverting back to the default font that the reader has chosen.



I combined David's findings with my own, and realized that the font tag discovery was a red herring. You can use any tag—except span, p, or div—to apply a persistent font, and it works whether or not a different font has been applied to the paragraph from an earlier rule. (OK, I confess I didn't test every single element in XHTML, so if you find one that doesn't work, I'd love to hear about it.)

That is, in my upcoming book on ePub production (ePub: Straight to the Point), I show a lot of code examples, much like the names of the XHTML elements in this article. I formatted them in InDesign with a special character style called "inlinecode". When I exported my files from InDesign to (begin to) create the ePub version of my book, it created a class called "inlinecode" and applied it to the code bits, by way of a span element:

<p class="body">Add a <span class="inlinecode">class</span> to the desired <span class="inlinecode">p</span> element in your XHTML document.<p>

Here is (some of) the style information for both the paragraph and the inlinecode class:

p {
font-family: "Optima";
font-size: .9em;
}

span.inlinecode {
font-family: "AmericanTypewriter";
color: #d90000;
}

However, because of iBooks' span bug, it not only doesn't use the American Typewriter font that I chose for the inlinecode class, but it also doesn't use the font chosen for the paragraph that contains it (Optima). Curiously, it does apply the red color. (Go back to illustration.)

But, if instead of applying the new font with a span element, I use the code element (which in this case, is also semantically appropriate), my font choices and the red color prevail. (Note that the class is no longer necessary.)

<p class="body">Add a <code>class</code> to the desired <code>p</code> element in your XHTML document.<p>

A side effect is that my font choices are persistent and can't be changed by the reader, but that's a topic for another post. (The number 1 in the illustration works the same way as the code elements, just with different formatting applied.)

In summary, you can apply font choices in iBooks by applying a font rule in the CSS to any element except the span tag. If you specify font choices with p or div, they can be overridden by the reader's font choice. Font choices specified with any other element are persistent, that is, not affected by what the reader chooses in the Font menu.


Related articles:

Palatino bug in iBooks on iPad
Text Size in ePubs-- Points? Pixels? or Ems? Oh my!
More fonts for eBooks on iBooks on the iPad
Choosing Fonts for iBooks on iPad

Goodbye Widows and Orphans, or yes you can force page breaks in ePub

[links to ePub samples now at end of article]

Working on a tip from a follower on Twitter, the other day I documented how to insert video into an iBook for iPad. Let's just say I got a lot of visits to my site for that, and continue to do so.

What I have to share with you today also originated from a follower on Twitter, Rick Gordon, and though it's not as sexy as video, it's much, much more significant. And it validates.

Rick tweeted the following yesterday afternoon:

Enclosing a ul or other block elements in a div set as inline-block causes whole block to shift page at once. Cool! #ipad #epub #ePrdctn

Having some control over page breaks is an ebook designer's number 1 concern right now. I'm thrilled to confirm that the battle has shifted to our favor.

Because it works. If you set the display property for a div to be inline-block, iBooks will display the contents of the entire div together on a single page, skipping to a new page if necessary, unless the entire div can't fit on a page by itself, in which case it will be divided across pages.

It's simple and very powerful: div {display: inline-block}

Here's a short document with no inline-block display. Notice how the header is separated from the paragraph that follows it, and even how a bit of the background bleeds through to the following page. Icks. The image and caption are likewise separated. Terrible!




Here's the exact same document with one div enclosing the header and paragraph and second div enclosing the image and caption. Both divs were set to display:inline-block. The result? Goodbye widows and orphans:



Where can you use this? As shown here, if you have a series of illustrations with captions, use inline-block to keep the caption right under the illustration.

If you want a header to never appear alone at the bottom of the page, but always be followed by at least one paragraph, just enclose the header and the paragraph in an inline-block div.

Perhaps you don't want any orphans or widows at all. You could conceivably set every p element to have inline-block display so that they will always (when possible) be displayed on a single page. (If the div can't fit on a single page, it will be divided across multiple pages. Which makes sense.)

Anywhere you might use InDesign's Keep functions, the display:inline-block rule will come in handy.

The possibilities are endless. And it works in iBooks, Adobe Digital Editions, and seems to work also on Barnes & Noble's nook. Perhaps everywhere, please let me know if you test it on other readers.

Addendum: Here's the ePub without inline-block. And here's the ePub with inline-block.

Page breaks with magic images in ePub for iPad

I've been having so much fun with Twitter these days. Learning so so much from all the folks posting with the #eprdctn tag. If you want to learn about ePub, that's the place to go. Be sure to follow @BookDesignGirl, @tinahender, @crych, @DigiBookWorld, @mundie1010, and even me: @lizcastro. Of course, there are many, many others! It's a wonderful community of folks sharing what they know.

Which is my typically long-winded way of saying that this post is a collaboration of sorts. David Mundie is working on an ePub of bird photographs and information and wanted to be able to control the pagination. He used a series of divs with width properties to force them to a single page. Unfortunately, he could only add text that was encrusted in JPEGs.

Today I was talking to a friend on the phone, who pointed me to Molto Gusto, a great looking cookbook now available on the iBookstore, as an example of a book that really takes advantage of the beautiful graphics of the iPad, with photographs that accompany recipes. At first it seemed that the photographs were generally accompanied by a recipe on the facing page, but it was not at all regular for me. Sometimes the caption got broken up, and then the whole pagination shifted uncomfortably. Look what happens when the second line of the Fava Bean explanation jumps above the Asparagus picture:

But it all got me thinking. Apple states in their documentation for iBook creators that since images are automatically resized to fit the screen, you shouldn't hard-code image size. I spent a lot of time figuring out just what size actually works. It turns out that if you use an image that is too big, iBooks will divide it between two pages. And if it's too small, you run the risk of labeling your asparagus as "ricotta salata".

But what if you used images that were the perfect size to take up the entire page? I found out that the magic size is 600 x 860 pixels. For simplicity's sake, I'll call pictures of that size magic images since iBooks will always fill an entire page with them—whether it's horizontal or vertical—and never divides them up (as it does with images that are too big).

And of course, implicit in filling an entire page with a magic image, is that by doing so, you create a page break, which up to now, you could only do by creating a new XHTML document in your ePub document. I will admit to you that I had fleeting thoughts of blank magic images (spacer gifs, anyone?) that I could use as page breaks, but the idea of blank pages in my resulting ePub didn't quite seem worth it.

But what about incorporating full size images into the layout so that they served as beautiful page breaks?

First, I created several magic images (using Photoshop's Image Size command). Remember it's not the proportion that's important but the actual pixel size: 600 x 860.

And then I created an ePub with a magic image cover of that size, followed by some explanatory text, another magic image, some more text, and so on. I think it looks pretty nice, especially in horizontal mode, but it's not bad in vertical either.




And here's the vertical:



There's nothing particularly special in the code... in fact I used InDesign CS5 to export it and then just fixed the fonts by hand. But you can download the ePub anyway if you're curious.

Clearly, this idea doesn't work for everything, but I think, until iBooks finally supports at least the page-break capabilities already standard in CSS2, it's a start. I'd love to see what people can do with it. (Send me screenshots and epubs!)

And I won't pretend its perfect. Once in awhile, seemingly out of the blue, iBooks likes to repaginate my book in horizontal mode, starting on the left page. That throws everything off. I don't have a workaround for that yet, though I think keeping the text before the image is more logical, and thus less confusing.

At the very least, it offers some interesting possibilities.

ePub Production links June 8 bis

And here are some more from today. Good thing too, because I spent the whole day debugging epubs that were perfectly fine, thanks to iBooks weirdness. I'll tell you about that another day.

• Better Screen, Same Typography on Subtraction by Khoi Vinh (posted: 8 June 2010 at 4:37:57 PM), thanks to @crych
• More thoughts about ebook indexes on Pigs, Gourds, and Wikis by Liz Castro at @lizcastro (posted: 8 June 2010 at 10:14:14 AM)
• eBook Indexes & User Interface Features on Joe Wikert’s Publishing 2020 Blog by Joe Wikert at @jwikert (posted: 8 June 2010 at 8:08 AM), thanks to @jafurtado
• 5 Reasons iBooks on iPhone Matters on elitzr.com by Mike (posted: 8 June 2010 at 7:21:39 AM)

More thoughts about ebook indexes

Joe Wikert has a great article about ebook indexes. I tried to add a comment, but it wouldn't let me so I thought I'd write it here:

Excellent article. Thanks! What I want to see is some way to differentiate index entries in an ebook. In print, I know that "125-138" indicates more in-depth treatment than say "125" and indeed, "125-126" indicates something different than "3-4", even though it's the same number of pages, just because we know that "3-4" is probably in an introduction.

And how are we going to label index entries at all? Of course, page numbers won't do it. So what's the alternative? Could size or color indicate depth? A bar that grows or shrinks according to depth?

I love the idea of pop-up summaries when you click an index entry. And what about if when you jumped to the referenced item, it was highlighted, at least temporarily, or you could choose to display indexed passages at will? How many times have you followed an index entry only to not be able to find the reference you're looking for?

The Back button is absolutely essential. The Nook's edition of Pride and Prejudice provides return links when you go to the glossary. I appreciated it even though it was kind of ugly.

I'd love to hear more thoughts on this topic.

[Was able to post comments on Joe's blog now.]

ePub Production links June 8

These are from the last few days. Clearly I don't seem to be able to make this a daily listing! Hope they're still helpful. Don't miss the one at the top on indexes.

• eBook Indexes & User Interface Features on Joe Wikert’s Publishing 2020 Blog by Joe Wikert at @jwikert (posted: 8 June 2010 at 8:08 AM), thanks to @jafurtado
• 5 Reasons iBooks on iPhone Matters on elitzr.com by Mike (posted: 8 June 2010 at 7:21:39 AM)
• Ebook growth charted in an annual format on TeleRead: Bring the E-Books Home by Paul Biba (posted: 7 June 2010 at 11:27:27 AM), thanks to @jafurtado
• iTunes Publisher inexplicably fails to publish an iBook. Now what? on ZDNet by David Gewirtz (posted: 7 June 2010 at 10:54:45 AM)
• Six tips for getting Apple’s iBooks to accept your ePub file on ZDNet by David Gewirtz (posted: 7 June 2010 at 10:13:58 AM), thanks to @adamwitwer
• Book formats and formatting books on Joho the blog by David Weinberger (posted: 6 June 2010 at 8:22:24 AM), thanks to @BookDesignGirl
• The font of uncertainty on Sydney Morning Herald by Elissa Blake (posted: 6 June 2010 at 7:34:26 AM), thanks to @MichelVrana
• Using Scrivener for epubs on Linden Log by David Mundie at @mundie1010 (posted: 5 June 2010 at 10:35:27 AM)
• epub code snippets (html/css) on MobileRead (posted: 3 June 2010 at 4:27:07 PM), thanks to @crych

Announcing “ePub: Straight to the Point” plus TOC!

I am proud to announce the imminent publication of my new book, ePub: Straight to the Point, which explains how to use a text editor, Word, and/or InDesign to convert a manuscript into an ePub document that looks gorgeous and is pleasing to read on the iPad and other ereaders.

For those curious about what the book will cover, I offer you the (current and tentative) Table of Contents, which is pretty close to final. However, since I tend to tweak things right up til the end, I can't guarantee that I won't add a few more things, especially to the "Advanced Formatting" chapter. It's also possible that page restraints will relegate the "Adapting plain text for ePub" section to my blog, though I had a great time putting GREP through its paces.

The print edition will be published and distributed by Peachpit Press, and is already available for pre-order on Amazon and Barnes & Noble.

There will also be an ePub edition, which will take full advantage of the very techniques discussed in the book itself, which will be available from all the aforementioned websites, as well as my own.

You can follow me on Twitter for all the latest news about my book, and about ePub production (#eprdctn) in general!

Table of Contents for ePub: Straight to the Point

Introduction

Print vs. ebook vs. website

Static vs. Dynamic

Appearance

How it’s read

The order of things

Formats, durability, and batteries

Searchability

Highlighting and sharing passages

Copy protection

Buying new books

What is an ePub document?

Navigating a sea of ereaders

Anatomy of an iPad page

Getting your eBook content

Using public domain content

Dealing with plain text

What about rights?

Using Word to write ePub

Styling your Word document

Setting up styles in Word

Applying styles

Saving Word files as HTML

Preparing HTML files for ePub

Using a text editor

Declaring the file to be XHTML, not HTML

Moving style data to its own file

Declaring the language used

Adding quotation marks around attributes

Using InDesign to create ePub

Creating an InDesign document

Creating a template for your InDesign files

Creating your styles

Loading existing styles

Cleaning up and saving the template

Organizing the InDesign files with an InDesign Book

Adapting plain text for ePub

Removing extra returns

Removing extra spaces

Converting plain text formatting to styles

Converting double dashes to em dashes

Applying styles to the book

Applying the main Body style

Applying headers, quotes, and other special styles

Replacing local formatting with styles

Drop Caps and Nested Styles

Adding images

Placing an image

Creating text wrap within the flow

Adding links

Creating a style for links

Hyperlinks

Cross-references

Creating a table of contents menu

Preparing your book in order to create the table of contents menu

Creating a Table of Contents Style

Adding Metadata to your ebook

Exporting ePub from InDesign

Exporting ePub from InDesign CS4

Exporting ePub from InDesign CS5

Inside an ePub file

Unzipping an ePub

The files that make up an ePub

The mimetype file

The META-INF folder

The OEPBS folder

XHTML and CSS files

The toc.ncx file for the table of contents

Writing the content.opf file

Creating the cover

Zipping and testing

Organizing files before rezipping

Rezipping after edits

Getting the new ePub file to the iPad

Further editing, rezipping, and testing

Validating your ePub file

Advanced ePub Formatting

Cleaning up InDesign ePub files

How InDesign writes XHTML

How InDesign writes CSS

Making sure ereaders use your CSS

Fonts in your ebook

The Palatino Bug

Specifying fonts by name

Specifying fonts by style

Specifying alternate fonts

Ornaments, dingbats, and symbols

Using non-English fonts

Embedding fonts

Drop caps and small caps

Having CSS mark the first letter and line

Tagging the first letter and first line explicitly

Controlling spacing

Controlling indents

Dealing with short lines

Borders and backgrounds

Creating a sidebar

Hyphenation

Adding soft hyphens

Using left-aligned text

Working with images

Size

Wrapping text around images

Wrapping text around sidebars

Creating links

Creating tables

Video in your ebook

Creating your video

Adding code for the video

ePub Production links June 3

Oops, missed a couple of days. Still trying to finish my ePub book!

But here are the links I've collected in the last few days:

• How to Paginate for iPad on Linden Log by David Mundie at @mundie1010 (posted: 3 June 2010 at 10:31:55 AM)
• iBooks 2.0 Wish List on Linden Log by David Mundie at @mundie1010 (posted: 3 June 2010 at 10:27:26 AM)
• A Speedepub Demo on Linden Log by David Mundie at @mundie1010 (posted: 3 June 2010 at 10:26:23 AM)
• Controlling Image Size in iBooks on the iPad on Pigs, Gourds, and Wikis by Liz Castro at @lizcastro (posted: 3 June 2010 at 10:20:18 AM)
• InDesign CS5 Creates Faulty Links in ePub on Pigs, Gourds, and Wikis by Liz Castro at @lizcastro (posted: 3 June 2010 at 10:19:57 AM)
• Update on InDesign CS5 Links Bug on Pigs, Gourds, and Wikis by Liz Castro at @lizcastro (posted: 3 June 2010 at 10:18:52 AM)
• Roundtable: Browser Wars 2.0, 6/3/10 on digitalbookworld by digitialbookworld at @@DigiBookWorld (posted: 3 June 2010 at 10:17:32 AM)
• Dealing with iBooks Caching on Linden Log by David Mundie at @@mundie1010 (posted: 3 June 2010 at 10:16:30 AM)
• ‘Vanity’ Press Goes Digital on Wall Street Journal by Geoffrey A. Fowerl and Jeffrey A. Trachtenberg (posted: 3 June 2010 at 10:15:42 AM), thanks to @KatMeyer
• Feedbooks versus Smashwords an ebook conundrum on Adam Maxwell’s Fiction Lounge by Adam Maxwell (posted: 3 June 2010 at 10:14:45 AM), thanks to @Hadrien
• Smart designer exports dumb pictures of text on fawny by Joe Clark (posted: 3 June 2010 at 10:13:59 AM)
• Textunes Moves Beyond “Classic E-Books,” Combines Crime Novels with Language Learning on Publishing Perspectives by Siobhan O’Leary (posted: 3 June 2010 at 10:13:13 AM), thanks to @BookDesignGirl
• 38% of iPads Outside of the US on AdMob (posted: 3 June 2010 at 10:12:12 AM), thanks to @albertcuesta
• An e-book pricing conspiracy tale on FUTUReBOOK by Philip Jones (posted: 3 June 2010 at 10:11:20 AM), thanks to @TheFutureBook

Update on InDesign CS5 links bug

<strong>Update (3/Oct/2011): CS5.5 exports links from multiple chapters correctly! </strong>

There was a great discussion about InDesign CS5's links bug this morning on the #eprdctn Tweet chat, hosted by Lindsey Martin (@crych). (Join in by following #eprdctn on TweetChat Wednesday mornings 11am EST.)

Here's the recap:

If you have a multiple document InDesign book with hyperlinks or cross-references that go from earlier chapters to later ones, and export this book to ePub, the links will be malformed, missing the file name portion of the link, and thus will not work.

These failed links generate validation errors from ePubCheck (whose approval is required for acceptance into the iBookstore).

Internal links (within the same document) or links to earlier chapters will continue to work (and are formed correctly, with both file name and fragment identifier).

Links in InDesign books also fail if exported to PDF as Interactive. (Exports to Print PDF work properly as long as Include hyperlinks is checked.)

InDesign CS4 and CS5 do not include the date upon export to ePub, nor have a way to manually enter the date, thus causing validation errors with epubcheck.

This is a major bug and pretty much incapacitates InDesign as a serious ePub generator until it is fixed.

Bug errors have been posted with Adobe, and several InDesign specialists have been notified. Hopefully, Adobe will post a fix soon.

InDesign CS5 Creates Faulty Links in ePub

<strong>Update (3/Oct/2100): CS5.5 exports links from multiple chapters correctly! </strong>

I'd heard last week or so that InDesign's super new feature—the ability to break a book into chapters automatically upon export to ePub (embodied in the "Use First Level Entries as Chapter Breaks" option)—would make hyperlinks break.

What I found yesterday is that even if you're the one that created the multiple chapters, InDesign still creates faulty links.

If you open up the generated ePub, you'll find that all of the links created are just URL fragments, that is, there is no reference to a particular book file, only the anchor reference to a particular place in the current file:

<p class="author" xml:lang='en-us'><span class="small-caps"><a href="#economy-anchor">Economy</a></span></p>

This is a little like sending a letter to someone on 456 Main Street without specifying which town they live in. It's not going to get there. The result is that only links within a single InDesign file will work.

I've heard there's a guy in the Netherlands who's developed a script to fix this problem, but really, shouldn't Adobe have done that?

In addition, I've found that InDesign doesn't export generated tables of contents to ePub at all. They simply disappear from the exported ePub (though they appear just fine in PDFs).

I am just amazed that this bug even exists, and that it hasn't been fixed immediately. InDesign is a great tool for creating ePubs but if it breaks all your links, that's pretty much a deal breaker.

Lindsey Martin reports that links in PDFs exported with Interactive also fail. I find this amazing.