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.

iBooks 1.5 increases page size by about 15%

Apple released version 1.5 of their iBooks ereader app last night. The biggest improvement to iBooks 1.5 is undoubtedly the new Full Screen mode. To access it, click the Font menu, and then click Theme in the pop-up menu. Then turn on Full Screen at the bottom of the extended menu.



Full Screen mode hides the faux pages, the faux spine, the space between those faux pages and the edge of the screen, etc. and increases the size of the page about 15%.

Here's what my upcoming book on InDesign CS 5.5 to EPUB and Kindle looks like with and without the chrome in vertical orientation:



Notice that there's hardly any difference vertically. Though you can see the line endings change ever so slightly, I couldn't measure any difference. The old page measured 560px wide by 760px, and the new page measures 560px by 850px high.

And here's what the horizontal two-page view looks like now, with chrome:



and without:



Of course, the pages reflow when you go from Full Screen to Normal view, and so it's hard to compare two pages that are exactly the same. In my test, my book takes up 205 pages in normal view and only 178 in Full Screen, a difference of about 15%.

With chrome, a small page (in horizontal view) measures 400px by 540px high. In Full Screen mode, the page now measures 410px by 600px.

iBooks also removed three existing fonts—Baskerville, Cochin, and Verdana—and replaced them with new ones with curious, or at least lesser known names: Athelas, Charter, Iowan, and Seravek. I wonder if this is a licensing thing? Here's what they look like:

Athelas:



Charter:



Iowan:



Seravek:



They've also changed the highlighting system slightly, and added a Night-reading theme which darkens the background so it's easier on your eyes and your sleeping companions. Indeed, it not only darkens the background, it eliminates it completely. Watch out if you have any images with white backgrounds, the white will stand out:



That will have to be fixed! (I'm hoping to get From InDesign CS 5.5 to EPUB and Kindle out the door today or tomorrow... more details soon.)

Embedding fonts in iBooks without bugs

Pablo Defendini posted an error to the #eprdctn group on Twitter this morning and Susan Neuhaus quickly concurred. Both posted screenshots and code. Chris Casey quickly googled a bug report and solution on StackOverflow. Amazing collaborative group!

I found the bug report a little hard to understand and tried to recreate the problem. But I couldn't. I tweeted back to Pablo who recommended I experiment with Google Web Fonts, which is what he had used. And lo and behold, I discover a whole treasure of open source fonts available for commercial use and embeddable in EPUB books. I send a heads-up to Eric Hellman who is doing a similar project with funding ebooks up front so that they too can be free. The Zen of Ebook Production.

I had looked at Google Web Fonts ages ago when it was still just on the web. You had to link to them and there was the worry that if Google went down, so would your fonts. This also made them unavailable for EPUB use. No longer. Now you can download Google Web Fonts (and there are some really nice ones) and embed them in your own books. Of course, you don't have to use Google Fonts, all the info here is valid for any embedded TrueType or Opentype font. Here's what you do:

Use this code in your CSS:

@font-face {
    font-family : NixieOne;
    font-weight: normal;
    font-style: normal;
    src : url("fonts/NixieOne.ttf");
}

NixieOne is the name of the font I used. The name you use for font-family shouldn't matter, but I have found that sometimes it does. To be safe, double-click the downloaded .ttf or .otf file, and use the name that's listed in the menu. You don't need to install it to use it for EPUB.

The font-weight and font-style items are required. It seems, though I find this unclear in the CSS3 spec (info welcome), that these should not be necessary as they are the default values. However, Webkit (on which Safari and iBooks are based), does not default to them, and without them, will not allow you to apply bold or italic formatting at all. So, use them!

Then in your CSS, when you want to use the font for a given selector, use font-family, as shown here:

h1 {
     font-family: NixieOne;
     ...
     }

And now back to the bug in iBooks. It turns out that if you embed a font—seems that it happens with both TrueType and OpenType fonts—and that font is formatted in bold, then iBooks will render it incorrectly, most noticeably with thinner fonts and at larger sizes. (This is a simple, single stroke font and should not look this blurry.)



Note that it doesn't matter if you set the font-weight: bold yourself as in:

p {
     font-family: NixieOne;
     font-weight: bold;
}

or if it's in the default stylesheet for the selector as in:

h1 {
     font-family: NixieOne;
     }

Since h1 (h2, h3, etc.) are all bold by default, this text will also be rendered incorrectly:



The solution is to first remove the bold:

h1   {
      font-family: NixieOne;
      font-weight: normal;
}

and then, if desired, create the bold with something other than font-weight. The folks at StackOverflow recommended -webkit-text-stroke and text-shadow.

Here's 1px stroke:

h1   {
      font-family: NixieOne;
      font-weight: normal;
      -webkit-text-stroke: 1px black;
}



and with 2px stroke:

h1   {
      font-family: NixieOne;
      font-weight: normal;
      -webkit-text-stroke: 2px black;
}



and here's text-shadow with a value of 1px:

h1   {
      font-family: NixieOne;
      font-weight: normal;
      text-shadow: 1px 1px #000;
}



I think all three are reasonable options and the choice depends on aesthetics more than anything else.

More thanks for helping figure this all out. Paul Irish for his @font-face gotchas page. Webkit for explaining -webkit-text-stroke. And finally to Sandra Williams, who sent me this page just as I was finishing this post. Someone else will have to follow through with that code—especially given the caveat about Safari at the end. Still, it looked interesting.