OverDrive is terrible and discriminatory

So I've got a sick kid, and he wanted to listen to Ender's Game, by Orson Scott Card. I pop over to the Boston Public Library which has an extensive collection of audio books, and ho! I'm in luck. They have it and it's available. I check it out, click the Download button, it downloads, and then I get this:



Yeah, I had seen that the file was a WMA file but since it said iPod as well, I thought I might be able to do it, oh my gosh, FROM MY MAC. But no. Turns out Overdrive discriminates against you if you have a Mac. I love libraries, but BPL: this is terrible.

Frustrated, but as yet undaunted, I fire up Parallels, so I can run Windows, download a brand new version of the Overdrive Media Console for Windows, which presumably supports said file type. Sign into BPL again, and download the book again. I struggle for a bit because it wants to open it up in the Mac version of the console, even though we have already seen that that won't work.

Finally, I get it to open up in the Windows version of the Overdrive Media Console, and I get this:



Yeah, I couldn't read it either. All I can think is, boy, it's a good thing I have a kind of wide screen monitor. Can you believe that?

With some trepidation, I click OK. I go back to the Overdrive Media Console on Windows and, as instructed, click Tools > Windows > Windows Media Player Security Upgrade. I get another big, wide error:



I say OK again, even though it's practically impossible to read.

Yet another window pops up and tells me that more DRM security files are going to be sent to who knows where to keep track of this audio file. For pity's sake.



I say OK again. In for an inch, in for a mile. And get this for my troubles:



Now, if you believe there's a server somewhere handling this that has ever been available, I've got a bridge to sell you. It's ridiculous. Ridiculous that Overdrive and the BPL treat me like a thief, ridiculous that I can't borrow books from the library as a Mac user, ridiculous that Overdrive makes me update a program I downloaded today, makes me jump through various incomprehensible hoops to do so, wastes an hour of my time, and at the very end says, "Oh, too bad, we don't care enough to make the process actually work."

Overdrive, you do a terrible disservice to libraries and book lovers. BPL, I love you, and I have continually advocated paying more taxes that should go to support what you do, but Overdrive does not serve me and it makes you look terrible.

Retina images in iBooks on iPad

I've been promising this post for several weeks and I think I finally have a definitive recommendation. But let me start at the beginning. The goal is to include beautiful high-res images in ebooks that take advantage of the Retina display, making sure to follow Apple's rules and not completely bloat the book, especially on lower-res displays.

So, I went to James Duncan Davidson who has done some pioneering work serving Retina images on websites. First, he found an issue with WebKit and Retina images. Then he showed it was possible, and what a difference it makes. Then, he speculated about need for progressive JPEG. And recently he figured out how to serve Retina images to Retina displays without bogging down slower screens. All very helpful.

At least for websites. Of course ebooks have different issues. First and foremost, since they are self-contained, it doesn't make sense to serve different images in different situations, unless you're creating completely different EPUB files, which is a hassle of its own.

Second, on the iPad 3, which has a resolution of 2048 x 1536, we have the added problem that iBooks doesn't allow images larger than 2 megapixels, and 2048 x 1536 is 3,145,728, precisely 1,145,728 pixels too many.

So how do we get Retina quality images in an ebook in iBooks?

First, following the guidelines in my last post on maximizing the iPad screen real estate, as well as providing lots of zoomability, I'm going to use a viewport that measures 2400 x 1860. And I'm going to create images at that size as well.

To get around the 2 megapixel limit, I worked out a technique based on an idea on Dan Amos' Book Creator website: “chop your 3.1 million pixel image into smaller images with each no larger than 2 million pixels. Then just line them up on the page.” First, I created an image that measured 2400 x 1860 (using the selection tool with a fixed ratio of 2400 x 1860 to select the desired area of my photo, then Save to Web at exactly 2400 x 1860).

I calculated that at 2400 pixels wide, a 2 megapixel image could have a maximum height of 833 pixels (2M÷2400). But that's an annoying number, so I opted for slices measuring 2400 x 800 pixels high. I set horizontal guides at 800px and 1600px and after activating the Slice tool (jumbled in with Crop), I clicked the Slides from Guides option in the toolbar. Then, I switched to the Slice Select Tool and double clicked each slice to name it. Finally, I chose Save for Web, Photoshop exported the three slices for me, with my chosen names (top, middle, and bottom).

In the HTML, I positioned each image right after the next with no spaces:

<div><a id="image" href="#pag001"><img id="item1" class="item" src="molt/top.jpg" alt="image" style="width: 2400px; height: 800px; z-index:-1" /><img id="item2" class="item" src="molt/middle.jpg" alt="image" style="width: 2400px; height: 800px;z-index:-1 " /><img id="item3" class="item" src="molt/bottom.jpg" alt="image" style="width: 2400px; height: 260px;z-index:-1 " /></a></div>

And in the CSS, I set the images to display as if they were block elements (one on top of the next):

img {display: block}

And the images display fine, and everything looks beautiful



And if I place a 900 x 698 pixel image on the right side page, flipped so that the same bits are next to each other, you can really see the difference:



Especially if you zoom in:



But here's the thing. If I place a 1600 x 1240 px image on the right hand page (again, flipped so I can compare the caterpillar heads with each other), I can't tell the difference. Maybe you can. And perhaps that makes sense, I'm not sure. A 1600 x 1240 image (which is less than 2 megapixels) is only 206ppi and not officiall Retina quality, compared with the 264ppi permitted by the iPad 3, but it's pretty darn good.



Even if you zoom in:



So, given that

1) Slicing high-res images is a pain (and sometimes reveals white dividing lines on iPhone and old iPad)
2) My high-res caterpillar takes up 2Mb, compared to the 1Mb for the 1600 x 1240px image.
3) The difference in quality is minimal.
4) The difference is even less noticeable on iPhones and older iPads.

I don't think going for extra high-resolution images that take full advantage of the new iPad's Retina screen is worth the trouble.

But I'd love to hear if you've found differently.

Finally, this is a fixed layout example, but I would say this goes double for flowing books, in which it would be even harder to position three images together reliably.

Want these posts emailed to your inbox? Would you like to see the example files that I used? Receive a discount on my books? And earn my eternal gratitude? Be sure and subscribe!

Maximizing zoom via the viewport in Fixed Layout ebooks in iBooks

I got an email from one of my readers the other day saying I was giving him a headache. Well, watch out, because I'm not done yet :) Bet you didn't know I used to be a math major...

Let's forge ahead. Although, as we've seen here and here, when you specify a viewport, you're actually specifying the proportions of the viewport, it turns out that you're also specifying the amount of zoom possible. Basically, if you use small numbers for the viewport, you'll have less zoom than if you use large numbers. Let's look at an example.

First, let's suppose, giving the calculations from Friday, that we want a viewport whose proportions take advantage of the iPad's screen with as little letterboxing as possible. We also want individual pages for each image. That means the viewport's proportions will be 1900 x 1470px.

You might be alarmed that 1900 x 1470, when multiplied together is larger than 2,000,000, which, if you had images that size, would cause your book to be rejected by Apple's iBookstore. But, just because your viewport is a certain size, does not mean that your images have to be that size, even if you want them to fill the page. They simply have to be displayed at that size.

But again, what numbers should we use for the viewport, if the proportions are 1900 x 1470, or a ratio of 1.29:1 (which is just 1900/1470)? A simple option would be to set the viewport to 1290px x 1000px (which of course, also has a ratio of 1.29:1).

<meta name="viewport" content="width=1290,height=1000" />

Now, what is the largest image that we can put in that viewport that will display full size? To get this number, multiply the ratio by 2 million (in our example 1.29 x 2,000,000 = 2,580,000), and then take the square root of the answer (1606). That number is the biggest width a 2 megapixel image of these proportions could have. If you like, round it off to make it easier to remember and type (1600). Divide the width by 1.29 to get the height (1240). And if you like, multiply them together to make sure you did it right. You should get a number that is less than 2,000,000 (1,984,000).

Next, save your images at 1600 x 1240px.

Add the images to your pages, and preview in iBooks. Here's the page at full size.



But with a book like this, your readers will want to zoom in. Here's the same page, zoomed in as far as it will go:



But what happens if we use a larger viewport? Let's try the full 1900 x 1470, which, as you remember has the same 1.29:1 ratio as 1290 x 1000px.

<meta name="viewport" content="width=1900,height=1470" />

I'm not going to change the images at all. It's the same 1600 x 1240 image I used in the previous example. (Though I did change the CSS to display the image at the same width as the viewport, 1900px wide.)

At full size, the page looks exactly the same. It's counterintuitive, but makes sense if you think about it. Just remember: the viewport determines the proportions, not the actual size.



But look what happens when you zoom in. Specifically, notice how much farther you can zoom in:



And what if we made it bigger still. Let's try. I'll pick 2400 pixels wide, just because it's relatively even number. If the width is 2400, I just have to divide by 1.29 to get the height (1860).

<meta name="viewport" content="width=2400,height=1860" />

At full size (it still fills the screen with no letterboxing), it still looks exactly the same as the other viewports with the same proportion. Note that I'm still using the same image that meaures 1600 x 1240px:



But now you can zoom in even further:



Now, I'm not sure what the limit is. Surely, it doesn't make any sense to be able to zoom in so far that the image is totally blurry or pixelated. However, in a book where zooming in is important, you want to make sure you don't use puny viewport numbers.

I also am not sure if there is an upper limit to the viewport that Apple or iBooks will allow. When I tried to create a viewport that measured 4800 x 3720px, it opened, but crashed when I zoomed in and out of a page. All of the sizes shown on this page work just fine.

Ah, and you might ask, what about the image size. How can we make the zoomed in images look their best. That's tomorrow :)

Note: This is a picture of a Monarch Butterfly egg. Notice the pin head in the upper-left corner of the picture for perspective on its size. This particular egg was just about to hatch (it's on the next page in the book!) They are truly amazing creatures.

Book Proofer, Caching, and iBooks

I just posted an update to my blog post about choosing a proportion for the viewport in Fixed Layout EPUB ebooks. I got some figures wrong originally because even though I had changed the EPUB and thought I was looking at the latest version, iBooks was holding out on me and showing me an older version.

I often use Book Proofer, especially when I'm working on Fixed Layout ebooks for the iPad. Book Proofer is a free tool that you can get if you have a full iTunes Connect account. (There are two kinds of iTunes Connect accounts, one for making books available for free and one that lets you sell ebooks through the iBookstore. Apple makes some tools available to holders of free ebook iTunes Connect accounts, but unfortunately, they only give Book Proofer to those who have signed on to sell ebooks through their store. What do you need to get the full account? One ISBN, a US Tax id, and your bank information. In my opinion, it's totally worth it, and you get the ability to sell ebooks as well.)

So what does Book Proofer do? When you drag an EPUB folder (you can drag a zipped EPUB, but why bother?) on top of the Book Proofer window, the book automatically syncs to iBooks on any connected iOS device that has iBooks open. Almost instantly.

And then, you can make changes to the XHTML and the CSS files and see the changes updated in the iPad on the fly. Book Proofer is really an invaluable tool for creating Fixed Layout for iBooks.



I found out on Tuesday, however, that not all changes are updated right away. I was playing around with the viewport size, trying to see if I could find a perfect horizontal page size that would fit perfectly and take maximum advantage of the iPad's screen. It turns out that Book Proofer won't update changes to the viewport. Let's see:



Now, anybody who has been working with iBooks for the last two years is probably familiar with its peculiar caching issues. I first discovered that iBooks wouldn't show you the latest version of an ebook unless you both deleted the iTunesMetadata.plist file from the EPUB and also changed the value in the dc:title value in the OPF file.

But, on Tuesday, I couldn't make that work. I think part of my problem was the order in which I was making the changes. Since I wanted to change the OPF file, the three XHTML files and the CSS file, I made the changes in whatever order I found the files on my desktop.

Not only that, sometimes I made the changes with the ebook open in iBooks, and sometimes I went back to the list.

I have found that the order matters, and sometimes you have to go back to the list.

So, if you want to change the viewport, first make and save the changes in the XHTML and CSS. Then, change the value of the dc:title element. When you save, iBooks should automatically close your document and display your list of EPUB books. It will replace the older ebook with the newer titled one. When you open that new document, you should find that the viewport has been properly updated.



Changing the dc:identifier element also works, as long as you do so while the book is closed. It also has the added benefit of creating an additional book instead of replacing the previous one, which can be helpful if you're trying out a series of changes and want to be able to go back and revisit earlier ones.

You can also change the dc:date element to track when the changes were made.

The important thing to remember is to make the changes to the XHTML and CSS files first, and only then change the dc:title, dc:identifier, and/or dc:date.

What I learned in Japan about EPUB 3, Rakuten, Kobo, Kodansha, and Japanese e-publishing in general

Here are some of my notes from the IDPF's first conference in Asia, specifically in Tokyo, Japan. The topic was EPUB 3, and it was co-sponsored by Voyager Japan. It was held as part of the larger 16th Tokyo Ebook Expo, in Tokyo Big Sight, a huge complex at the edge of the harbor.

NB: I don't speak Japanese, so not only are the quotes pretty rough, but they are quotations of how the interpreter translated what the speakers were saying. And it was all going by pretty quickly. Corrections welcome.

The opening presentation featured Hiroshi Mikitani, the head of Rakuten, the Japanese online retailing giant that just bought Kobo; Yoshinobu Noma, from Kodansha, one of Japan's largest publishers, and Bill McCoy, head of IDPF. with Takehiko Ogi, CEO Maruzen Chi Holdings, as the moderator.


Photo courtesy of Hagino-san, president of Voyager Japan

A few points stuck out for me. First and foremost, the Rakuten CEO stated that all their Japanese content would be in EPUB 3. He said they chose the open standard so they can compete not on format but on ease of use of their reade, that EPUB3 allows content to be viewed on all sorts of different devices. He talked about localized service on a globalized platform. Second, he stressed his desire to spread Japanese culture abroad, as well as to encourage reading in kids all over the world. Their initial target is to have 1,000,000 Japanese books in EPUB 3 format, and then add another half million, so you can get "any" book in Japanese as an ebook.

When asked how Rakuten was different from other players, and how the Japanese market was unique, Mikitani answered that they want to take advantage of the existing framework, including bookstores, of which there are 4x as many in Japan than in Europe or US.

The second panelist, Yoshinobu Noma, from Kodansha, said domination from one company was not good, and was encouraged by Rakuten's entry into the market. He mentioned that there are 70 million Rakuten club members with "points", and that the low price of the new Kobo Touch in Japan ($99) would help Rakuten and Kobo device gain foothold. He was concerned that fewer competitors keep books from coming to market. More publishers mean more freedom of expression, freedom to publish.

Then Bill McCoy (Executive Director of IDPF) added that the IDPF and open standards pave the way for the fusion of digital books: like manga is a fusion between comics and books, making a bigger world for all of us.

Mikitani then said "I am nationalist and as Japanese company, I want to make an impact in the global industry, and I want to export that overseas, not just manga, expand Japanese culture. Unless we have a device, [like Kobo], we cannot compete with overseas competitor: so there's a philosophical part plus a business part."

When asked if it was about books, he answered, "Kids are not reading, I'm not criticizing consoles, but this is a crisis because kids are not reading, and that affects the intellectual level. I think back to books I read in the past. In Brazil, there is no consumption tax on books, in EU, there is a lower tax. As a nation, we need to figure out how to expand book business.

The moderator immediately asked about Rakuten's servers, and it turns out they're all in Canada, which has some tax ramifications: Mikitani replied that "we must comply with the law, but we have servers in Canada for logistics… but that means no tax in Canada, 3% in EU and 0 in Japan."

[A quick internet search reveals that there is a 5% consumption tax in Japan, that will rise to 15% by the end of the year. It is not currently levied on electronic products purchased abroad, and thus by selling from Canada, Rakuten would not have to charge the tax.]

Mikitani played down color tablet ereaders because of weight and price [which I think are important points]. He said 70% of users in US have both tablet and e-ink. [Not sure where this number comes from.]

Then Noma-san spoke about government subsidized initiative to convert 60,000 books [to epub3 format??] but stressed idea that paper and digital is not zero-sum, that one can build on and benefit from the other.

He said that Japanese government has said that all textbooks must be electronic by 2020 and that that will be the tipping point for ebooks.

Question: EPUB 3 content is not widespread, how do you position it?

Bill: Japan has chance to leapfrog the splintering of EPUB 2. Mikitani: we have to have one Japanese standard and one global standard. Noma-san (Kodansha) is member of IDPF and also working on EPUB 3.

Noma-san continued on to explain concept of #GAFMA (or Google, Amazon, Facebook, Microsoft, and Apple), and said that they had to find a way to deal with that group. "As partner, we can work with them, but in US, there is competition. How can *we* compete with them? EU companies say Japanese companies exist that can compete, and they asked how we work with them, and we talked about how to compete healthily against each other. From EU perspective, they welcomed Rakuten's acquisition of Kobo. In short, GAFMA can be competitor or partner.

Question: Will Rakuten buy publishers? Bookstores? Mikitani: "I think we should let experts do what they do best, we have no plans to buy publishers or bookstores, but would like to strengthen alliance with bookstores [and indeed I saw Kobo being demo-ed in Bunkyo-do the next day.]

Question: What about writers? Are they thinking of ebooks?

Noma-san: Some are against, but gradually this will change. We are trying to do simultaneous paper, ebook, so get contract from author for both is way to go.

Question: Can Japanese culture be exported with ebooks?

Noma-san: "Already with manga, in Taiwan we have distribution company going to mainland China eventually, Japanese flavor needs to be added to Kobo in order to go global"

Mikitani: "I was amazed at how much manga was in FNAC in Paris, but in suburban stores, there's no shelfspace. So, selling ebooks online, where there is infinite shelfspace enables that possibility. This is great opportunity to export Japanese literature."

Question: Talk about how passionate you are about ebook industry.

Mikitani: This is going to be the initial year for ebooks themselves, this is an opportunity for ebook industry to expand overseas, with Kobo, and Kodansha, we'd like to support your business.

Noma-san: I make many speeches on big trends, but sometimes people misunderstand me. In Japanese market, unless we win in print, we won't win in digital. We have to win in print, now we will see a transformation, this is the chance to go digital. We have to create good content.

Bill: Digital books can be complimentary to print, but we don't yet know what digital books are, and can be. Publishers must become web publishers.

----------------

On the second day, after my and Markus Gylling's talks in the morning, Ren Ando gave another presentation on Kobo and Rakuten which I found interesting.

Here's a brief synopsis of what he said:

Rakuten is an online marketplace, travel, financial, banks, credit services, advertising, entertainment. They do 1 trillion yen of business per year (about 12 billion dollars). Kobo is 3 years old, with 9 million users in 190 countries, 17000 publishers, 2.4 million titles, sales partners in 7 countries. Joined Rakuten in 2012.

Partner model: authors and publishers => Kobo => distribute device through local partners

Kobo touch, to be available at the end of July. Make Japanese reading culture a part of the global culture. "Renaissance and revolution of the reading culture"

EPUB 3 for all Japanese books in the catalog

Why? A: An open ecosystems is better for global interoperability, publishers and authors can trust EPUB, rapid increase of number of titles, a reliable reading platform, fast circulation of EPUB based books, migration pain mitigation, other EPUB based services, authors, publishers

"We are at a tipping point in Japan"

Creators can create and there will be lots of channels for distributing content

Strategy:

1 EPUB migration assistance for publishers
Assistance on converstion process
EPUB 3 authoring guidelines

2 High fidelity to the Japanese publishers typography requirements
co-developed between Access and Kobo
Cross platform reading experience (Android, iOS, Mac OSX, Windows)

3 Rakuten viewer aligns with latest drafts of CSS writing modes and CSS text modules
Rakuten working with W3C and Unicode consortium on these drafts

"We don't want to compete on EPUB capabilities, but rather on ease of use"

4 For "renaissance of reading culture on global scale" Rakuten works with Access to share some part of our outcomes through Readium Initiative.

----------

Finally, this was my first trip to Japan. You can see my pictures here.

Creating pop-up footnotes in EPUB 3 (and thus in iBooks)

Apple sent around an email today announcing that EPUB 3 is now supported by iBooks and the iBookstore. It also tantalizingly suggested that EPUB 3 supports pop-up footnotes and said you could find information in the EPUB 3 spec on the IDPF website. The first part is true, and the second part is sort of true, but if you like, read on and I'll explain just how to do it.

The IDPF website explains the proper syntax for marking up footnotes semantically, that is, by labeling them as footnotes:

<p>In chapters 24, 89, and 90, we substituted a capital L for the symbol for the British pound, a unit of currency.<a epub:type="noteref" href="#n1">1</a></p>

This snippet is from an EPUB 3 version of Moby Dick, coded by Dave Cramer.

And then the EPUB 3 spec goes on to say that a Reading System may associate specialized behaviors with that syntax, and it looks like Apple has associated the pop-up functionality to the combination of epub:type="noteref" and epub:type="footnote" attribute/value pairs.

So, to make a pop-up footnote in EPUB 3 (which works in iBooks), you just have to create your footnote marker link as shown above, paying special care to include the epub:type="noteref" attribute/value pair. I'll repeat it here for good measure:

<a epub:type="noteref" href="#n1">1</a></p>

Next, create an aside element that contains the text that should appear in a pop-up display when the link is pressed.

The aside element must also have the epub:type="footnote" attribute/value pair to mark it as the footnote content as well as an id attribute that matches the value of the href attribute in your link.

<aside epub:type="footnote" id="n1">
<p>These have been corrected in this EPUB3 edition.</p>
</aside>

Note that the aside element, which is new to HTML5, is automatically hidden by iBooks. If you put your footnotes in, say, a div element, it would still pop-up when the link was pressed, but it would always be visible as a regular part of the text as well.

Another thing that I noticed is that you can enclose your a element in sup elements so that your footnote markers are raised with respect to the surrounding text, but make sure it's outside the a element or else it will break your pop-up footnote.

And that's it. Look! It works!

Here it is in a horizontally-oriented iBooks:



And here it is vertically:



Note that I completely disabled the CSS on this document, to be sure that the pop-up had nothing to do with any CSS effect.

And notice that the font in the pop-up changes to match the font chosen in the Font menu (here I've chosen Seravek):



Again, you can download this and other EPUB 3 examples from the EPUB 3 Samples site and view it in iBooks 2.1.1 (from April!). You can view this particular pop-up footnote on the third page of the Moby Dick book, called "Original Transcriber's Notes" in the table of contents (preface_001.xhtml). Thanks to Dave Cramer who coded the example (in January). And thanks to Apple for adding this functionality... and hinting that it existed so I could figure it out! I love, love, love that Apple totally followed the standard on this one: supporting symantically marked footnotes, and then "associating specialized behaviors" as the spec directs. No extra CSS or Javascript required. Well played, Apple.

OK, there are now two desktop EPUB 3 readers, and iBooks and the iBookstore have officially announced support as well. And there are pop-up footnotes. What are you waiting for to start creating EPUB 3 ebooks?

Customizing InDesign's EPUB files without cracking them open!

I'm working on my presentation about Enhanced EPUB for PePcon on Tuesday afternoon and I was playing with the newly released InDesign CS 6 to make sure that everything works as expected. But it didn't. For some reason, when you place an audio file, iBooks displays the controls so small that the only thing you can do is choose Airplay, but not the actual Play button (if you're on an Airplay network). It's pretty frustrating and would completely ruin InDesign's much improved multimedia function if not for one thing.

You can fix it without cracking the EPUB file open. One of InDesign CS 6's other new features is that you can choose additional CSS files to apply to your exported EPUB. All you have to do is create a CSS file that fixes the code that InDesign supplies, and voilà, the audio controls reappear. You don't have to unzip, or worse, rezip.

The key lies in the letter "C" of "CSS". It stands for Cascade. The Cascade means that when there are multiple sets of style rules for a given bit of text, there is a defined hierarchy for which rules will win out. I actually see it as a sort of waterfall in my head with the more “important” rules flowing over and covering the lesser ones.

To make the cascade work, you have to understand the slightly complicated topic of CSS inheritance: given two competing rules, which one wins? I talk about this in some detail in my HTML book. The very abbreviated answer is that you have to take into account specificity (that is #id overrules .class overrules p) and location (that is, inline overrides local overrides earlier, overrides imported), as well as taking into account the !important tag.

In our example, InDesign creates this code for audio elements. Note that this is the default size if you don't change the poster image for the audio element.

audio.frame-5 {
height:60px;
width:60px;
}

But when I open that document in iBooks on the iPad, this is what I see:



And when I click it, all I can select is which Airplay device I want. I can't actually play the audio.



So, I open a new text document. InDesign 6 lets me add additional CSS documents and will automatically load them after the CSS that it creates itself. That means that since my styles are later, as long as the specificity is the same, my styles will override InDesign's.

But if you look at the code above, notice that the selector that InDesign uses, audio.frame-5 has a class, and thus is more specific than a plain audio.

The answer lies in the HTML that InDesign creates. By default it generates an id element for each audio (and video) element that it creates, set to the filename. So, you can use that filename in the CSS to make your selector more specific, and thus override InDesign's CSS.

My audio file is called "bondia.mp3", and if you know CSS, you know there's a problem already. That period in the filename has special meaning in CSS (it means that what follows is a class name). Since we don't want that special meaning, we have to escape the period with a backslash:

audio#bondia\.mp3 {
height:26px;
width: 150px;
}

These values will now override the height and width values that InDesign generated. Save this text file as "extras.css"

How do I get them into my EPUB file? Go to Export in ID6, choose EPUB, click the Advanced panel, and then choose Add Style Sheet, then find your extras.css file. Export as usual.



If you looked inside your EPUB file (though you don't have to), you'll see this:



That's it! When you open your book in iBooks, you'll see that the audio controls are as you specified (and not as InDesign specified), even though you never had to deal with Terminal, never had to unzip or rezip or anything.



The best part about this is that you can use this technique to override any of the CSS that InDesign either creates in a way that you don't like or that it doesn't yet support. For example, suppose you want to add a border around a video. You can do that with an extras.css file. (Indeed, you can add borders to all of your videos just by using video as a selector instead of targeting just a single video.) Suppose you want to add media-queries so that your document will work as best as it can in different ereaders. Just put the media-queries in your extras.css file. The possibilities are really enormous.

Thanks to Adobe for incorporating this amazing new feature!!

Readium displays Fixed Layout EPUB on desktop (compatible with iBooks too)

We have been waiting to view Fixed Layout on a desktop screen for a long time and the IDPF with its Fixed Layout spec and support for Readium has now made it possible. Just look at this!



First, I adapted my Fixed Layout example (from my original miniguide on the subject, which desperately needs updating now) so that it conformed with the new IDPF spec. This required:

In the content.opf file:

• Add version="3.0" to the package element.
• Add prefix="rendition: http://www.idpf.org/vocab/rendition/# to the package element as well.
• Add <meta property="dcterms:modified">2012-05-08</meta> to the package element. This is a great, new required element that hopefully will help with caching problems, among other things, as it's supposed to contain the last date the content was modified.



Still in the content.opf file, we get to the stuff that determines how the fixed layout book is displayed, the so-called "rendition" options. (Thankfully, the CIA is not involved.)

There are three principal rendition variables: layout (with values of pre-paginated or reflowable, that is whether you want it fixed or flowing), orientation (with values of landscape, portrait, auto, that is, whether a certain orientation should be forced), and spread (with values of none, landscape, portrait, both, auto, that is, whether the ereader should use facing pages—aka a synthetic spread—in given orientations).

I promise to explain these in more detail in the upcoming new edition of the Fixed Layout miniguide!



Here I've chosen the most basic fixed layout options: that it be fixed layout, that it can be viewed in either a horizontal or vertical orientation, and that it always be displayed with facing pages.

In the content itself (the XHTML):

The code is not very different. As with all EPUB3 documents, I've eliminated the DOCTYPE, made sure the xml declaration is present, and used a simpler character set declaration:



Last but not least, add the meta tag for the viewport, as usual:

The new TOC

Finally, you have to create on extra file, the new HTML TOC, or nav element. It's not much more than an ordered list, with each of the TOC items in its own list item, along with the all important nav element:

<nav xmlns:epub="http://www.idpf.org/2007/ops" epub:type="toc" id="toc">

Here's what my toc.xhtml file looks like:



And, of course, don't forget to declare the toc.xhtml file in the content.opf file:

<manifest>
...
<item id="toc" href="nav.xhtml" properties="nav" media-type="application/xhtml+xml"/>

And you're done!

Now, zip it up as usual, and run it by EpubCheck3.0b5 to make sure you did it all right.

Then, in Google Chrome (it won't work in other browsers), download the very latest version of Readium (released this morning!), it's 0.2.4, kindly fixed and uploaded by Matthew Robertson, and add your book to the library.



And voilà, you can see a fixed layout book on your desktop!!!



What, you say, you don't see facing pages? Click the facing pages button in the Readium pop-up menu that appears when you hover over the bottom-right corner of the screen.



And where are the embedded fonts? I'm not sure yet if that's a problem with this very new software, or if I haven't embedded them properly. It's definitely true that only OTF and WOFF fonts are supported in EPUB3, but I use WOFF in my example, so they *should* be showing.

Ah, but I hear a bigger worry... why should you go to all this trouble to create a format that only works with a fledgling ereader that no-one uses yet? And I could try to convince you about the importance of standards, but hopefully the following screenshot is more powerful: because the IDPF's EPUB 3 Fixed Layout spec works in iBooks!!! Apple and Barnes & Noble (and others) were involved with the IDPF in creating the Fixed Layout standard and Apple already supports it as you can see the same file showed here in iBooks:



This is a great development, and the IDPF should be commended. Hopefully there will soon be a time when we can create a single fixed layout EPUB file and it will work properly in all ereaders—Barnes & Noble also worked closely with the IDPF to develop this spec—and on the desktop. Even in Kindle.

The best way to help make this happen is to start using the new EPUB3 Fixed Layout format right now: create lots of examples, view them in Readium and help contribute to making Readium a more powerful ereader.

You can download my new EPUB3 FXL example here. Feel free to open it up and play with it. I'd love to see any examples you create!


Don't forget: subscribers receive all my blog posts via email, as well as other perks, and help to keep me writing. Thanks to all of you!

Double tap zoom transforms fixed layout ebooks in iBooks

I'm supposed to be working on my presentations for PepCon, but I've been distracted with something that Rick Gordon brought to my attention last week: "Remember you can double-tap a text frame to zoom to screen size in iBooks FL".



As happens so often on Twitter, that message went into my brain and didn't come out until a few days later when Rick offered me a sneak preview of an amazing fixed layout ebook he's working on, Tiny Homes: Simple Shelter, by Lloyd Kahn.

Before I go any further, I have to tell you (if you haven't already heard my rants on the subject), that I generally hate it when publishers just replicate a print design as a fixed layout for the iPad (or whatever reader). One of the first examples I saw was a gorgeous collection of Ansel Adams prints with what I thought was the tiniest text you could never read. It was so frustrating. And although I understand the usefulness of Fixed Layout, and have written a fair bit of information about how to create FL ebooks, I've always shied away from recreating a text-heavy fixed layout ebook.

So, I was intrigued when, in the introductory note about Tiny Homes, Rick said that I could double-tap any of the text blocks or images to magnify them. I didn't remember being able to do that in other FL books, and wondered if Rick, an EPUB expert, had discovered or developed some new tricks. And while he has, and I'll get to that in a later post, what is almost more important is that he made me realize that we've had this capability all along.

At first, I couldn't believe we had. So I went back and looked. And though there are a few examples of what I'm calling double-tap-zoom (DTZ), I'm not surprised I didn't notice.



iBooks has always let you double-tap a book page to fill the screen with just that page along with a sliver of the facing page. This works in all fixed layout ebooks on iBooks.

What I didn't realize is that you can double-tap some text blocks and images to automatically zoom them as well. This makes reading a text-heavy (or text-and-image-heavy, as in Tiny Homes) a much more pleasant—and even feasible—project. I'm a bit embarrassed to admit that double-tap works great in the Ansel Adams book that I've used to use as an example of what not to do with fixed layout. No more.



But it's not consistent. Sometimes when you double-click an image, it zooms the page and sometimes it zooms the image. Sometimes the text zooms and sometimes it doesn't:



And the more I looked, the more I wondered what distinguished the text and images that zoom from those that remained static.

One of the most important characteristics of text and images that can be double-tap zoomed is so obvious, you might not have thought of it: they must start out smaller than the page itself. Otherwise, there's nothing to zoom to!

That means that if you have a text block that you want to have zoomed, the text has to be somewhat narrower than the page on which it is placed. (I have found that a width of 85% will zoom, while 86% won't. Actually, 86% zooms in landscape but not portrait.) The width property is very useful here:

div.text {width:85%}

What I found rather remarkable is that it doesn't matter if you position the text absolutely or some other way, it doesn't matter if the text has offsets or if it doesn't. And you don't have to invoke any crazy incantations. It just matters how wide the text block is with respect to the page width.

Of course, sometimes when you position an image, you change its width. For example, if you give a text block a left offset of 200 pixels on a page 1200 pixels wide, that leaves only 83% of the page (1000/1200) for the text block. It will zoom even though you haven't explicitly specified the width.

The same rule applies to images: as long as they're at least 85% smaller than the page width, they will zoom when double-tapped.

Why didn't we notice this before? Why didn't I notice this before (you probably did!)

There are three main reasons I've found. First, if you're using full bleed images and just placing text on top, there's no way to zoom the images. They're already as big as they can get. (The text on top should still zoom.)

Second, early fixed layout examples (mine included) often used an overly complicated system of displaying half of a layout on the left page and half on the right, hiding the bits that didn't fit. This required some strange sizing of even smaller images, rendering them unzoomable. What a shame. I feel a little guilty that I espoused that method of creating fixed layouts, and hope to remedy that more thoroughly soon. For now, I'll say that I recommend creating each page in a layout independently, dividing images into two pieces as necessary and keeping the sizing as simple as possible.

Third, if an image is beneath a transparent text block, particularly one that doesn't zoom, you won't be able to reach it with a double-tap. It's beyond your touch, and it won't zoom. Be careful with z-index!

If you're creating fixed layout ebooks with a lot of text and/or images, make sure they double tap zoom by following these caveats. It'll make you books a lot more pleasant to read.



You can download my example file shown in this last video. Feel free to unzip it and look at the code. The CSS is right in the XHTML just so you can see what is affecting what. I wouldn't create a real book this way. And I think the z-index is what is keeping the large 1200 x 1700 image (with the castle in the lower right corner) from zooming.

Oh, and sorry about all the reflection in the videos. I've got a ways to go before I can create videos as nice as my screenshots :)

Many thanks to EPUB coder extraordinaire Rick Gordon for getting me thinking about this and for sharing his lovely book with me. He also pointed me to a few interesting articles, one on double-tap zoom, another from the Safari HTML reference that describes the user-scalable variable and how it is on by default, and a third on a new zoom property. Rick's book, Tiny Homes, uses a few more double-tap to zoom tricks that I hope to talk about in a future post.

Using GREP to eliminate warnings—and reveal errors—in BBEdit

If you're making changes directly to your XHTML documents, it's a good idea to check their syntax before compiling and finishing your EPUB files. This helps weed out the most common and difficult-to-find errors: typos.

In BBEdit, choose Markup > Check > Document Syntax to see if your XHTML file is valid. BBEdit will quickly sift through and alert you to any problems.

If you export EPUB from InDesign, you may get a lot of warnings about spaces being recommended before trailing spaces.



They're quite right: if you have a all-in-one element like the img element or link element, you are allowed to write this:

<img src="image.jpg" alt="image description"/>

But it's recommended that you add a space before that trailing slash (after the last attribute and value):



The problem, and it's minor but annoying, is that all those warnings hide the real problems. (The errors are there, but you have to scroll down to find them. And you don't get that satisfying "No errors were found" message.) One temporary solution is to uncheck the Warnings box as shown in the above screenshot.

The other, more permanent, solution is to add the missing space so you don't get any warnings. I use GREP for this:

Search for (\S)/> (that is, any instance of a closing slash and closing bracket without a preceding space. Another way to interpret that GREP would be that you're finding anything that's NOT a space followed by a closing slash and closing bracket.)

And replace it with \1 /> (whatever came before the closing slash and bracket, a space, and the closing slash and bracket)

Now when you check syntax, you'll only see the real errors (here, a classic one for me: mismatched p's and div's):

---

I know this is a tiny and minor thing, but I hope it will be helpful to a few, and maybe even get folks who are interested in but scared of GREP to start with something small.

Word for Mac can't generate linked TOCs for Kindle

I've been trying to document the simplest way to create an ebook with a tool that most folks already own. The tool I've chosen, Microsoft Word, is a bloated, impossibly complicated piece of software that for some inexplicable reason, is used by a huge proportion of the populace. Feel free to enlighten me about its virtues in the comments.

Anyways, I want to call your attention to one particularly important failing of Microsoft Word for Macintosh: it will only create linked or active TOCs if the TOC contains page numbers. It's really important to include linked TOCS in ebooks, and particularly in Kindle books since most of Kindle devices don't have device-generated or navigational tables of contents, but it doesn't make sense to include page numbers (since they don't make any sense in a digital landscape).

Note that Microsoft Word for Windows is happy to automatically generate a useful TOC, sans page numbers, for an ebook.



Simply uncheck Show page numbers and then check Use hyperlinks instead of page numbers.

Now look at the corresponding dialog box in the latest version of Word for Macintosh:



You can hide the page numbers, but you can't convert them to hyperlinks, and I assure you, after much testing (and confirmation from @ljndawson), that without page numbers, no page links will be created. The TOC is there, but will take you nowhere in the converted ebook.



It makes Word for Mac a much less powerful tool for creating ebooks. Of course, there are solutions (like manually creating bookmarks for each TOC entry), but it's nothing like a one-button solution (!).

Why should anyone care about how Word creates TOCs? Because Word (.doc or .docx) is the one styled format that can be read and converted automatically into Kindle format (using KDP, Send to Kindle, and by emailing the document to a Kindle device). More on that soon.

Using Amazon's Send to Kindle to transfer ebooks and documents to Kindle

Amazon has just released the Send to Kindle app for Macintosh. It already exists for PCs. This is an app that facilitates getting documents in various formats—Word (.doc and .docx), text (.txt), RTF (.rtf), images (.jpeg, .gif, .png, .bmp) and PDF (.pdf)—to your Kindle.

Once you've downloaded and installed Send to Kindle, you can activate the app in several different ways. First, you can right-click a document in the Finder and choose the Send to Kindle option near the bottom of the menu.



You can choose Send to Kindle from the Printer menu in any program that has one (here's Word):



Finally, you can click the Send to Kindle icon on the dock or drag a document to the Send to Kindle icon directly.



Whichever method you choose, you'll see the Send to Kindle's window in which you can specify a new title for the document and choose which Kindle you want to send the document to. You will also specify whether you want to use free Wifi or incur extra charges by using Amazon's Whispernet service.



If you check "Archive document in your Kindle Library" (which is on by default), your document will be available in the Kindle cloud, and thus to all of your Kindle devices. You can even deselect a device and send your document only to the cloud.

Format

Notice at the bottom of the window that you'll be advised about which format your document will be converted to. If you right-click or drag and drop, Send to Kindle will convert Word, text, and RTF to Kindle format, and preliminary testing seems to indicate that it uses the same KindleGen algorithms that are used by Kindle Previewer and KDP. If you right-click or drag and drop a PDF file, you'll have the option (in the aptly named Options panel) to convert the PDF to Kindle format. I tested some simple documents, and it seemed to work quite well.



If you use the print option, it will always send the document as a PDF, and the PDF cannot be converted to Kindle format. Note that the PDF document will be much larger than the Kindle version.



All in all, the Send to Kindle app looks like a useful tool for getting documents into your Kindle. The Send to Kindle documentation has a few more details.

Unpacking a Kindle/Mobi file

Converting an ebook of whatever format to a Kindle/mobi file adds a level of abstraction that always leaves me with this gnawing uncertainty: did anything change under there? Is this what I really want? This may be due to general OCD, but I think it started with Microsoft Word's early attempts to guess what I wanted and automatically change my text for me, causing all manner of consternation and mistrust, as its guesses were often incorrect. Course it doesn't help that Kindle devices don't all display an ebook the same way.

As you might've guessed, I don't trust Kindle Previewer (or the KindleGen that it invokes) either... who knows what it does during conversion!? Indeed, when a feature in an ebook I'm creating doesn't come out right, knowing exactly what KindleGen is doing with my files can be very helpful for cross-platform development.

Thankfully, there are a bunch of folks over at MobileRead who have developed an open source tool for unpacking Mobi files and looking at their innards. It's called Mobi Unpack and the latest version (047) can be found there.

But what do you do with it once you've found it? Double-clicking didn't work at first for me:



And I had no idea what application I should associate it with. I used a rather convoluted system starting with Terminal, navigating to the MU folder, then typing python Mobi_Unpack_v047.pyw, which works, but it seemed like there should be a better way.

One of the Mobi Unpack developers told me I needed a thing called Python Launcher. You can find it in /System/Library/Frameworks/Python.framework/versions/2.5/Resources. It comes with your Mac. Who knew? :)

I dragged Mobi_Unpack_v047.pyw on top of the Python Launcher, and now it's permanently associated: when I double-click, it opens right up.



Once Mobi Unpack is open, use the top field and Browse button to choose the Mobi file that you want to unpack. Use the second field and Browse button to choose the folder you want to unpack the Mobi file into.

I don't check any of the other options.

Then click Start to unpack your Mobi file.

Mobi Unpack creates a mobi8 folder, which presumably is the KF8 version as well as a mobi7 folder which presumably is what old Kindles get. You can explore the files inside (XHTML, CSS, content.opf, etc.) to see how KindleGen (via Kindle Previewer or whatever) is creating your Mobi file.



The mobi8 folder even contains an EPUB file. I thought this might be useful if you were starting with a Mobi file and wanted to convert to EPUB, but unfortunately, at least in my testing (in which I did not generate the Mobi file from an EPUB file), the EPUB did not validate.