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.

Choosing a viewport's proportions in a Fixed Layout EPUB for iBooks

UPDATE: September 19, 2012. Well, unfortunately, the numbers given for the individual horizontal pages were not quite right. Which is strange, because the screenshots sure make it look like it was right. I'm still trying to track the problem, though I think the issue is caching, which I hope to get into in more detail in a separate blog post. For now, know that the faux pages take up 120px (because of the higher resolution of the Retina display!) and so the actual optimal size of full screen individual pages is 1900 x 1470.

---

Yesterday, I showed you how the specified Viewport size affects the size of text and images in a fixed layout ebook in iBooks. Today I want to go over in more detail how you should choose the viewport's proportions.

The first thing to remember is that even though you specify the viewport size in pixels, it's not really a fixed size, but rather a proportion. For example, if you specify a viewport of 1000px wide by 1000px wide, you'll get a square page, but on an iPad3, it will be displayed at some other number of pixels, but not necessarily 1000.

When viewing a two page spread, it will look like this:



And when you zoom into a single page, you get this:



Note that even though the viewport was defined as 1000px square, its actual measurement in pixels depends on its zoom factor. When zoomed into a single page, for example, it measures about 1470px square. When viewed in a spread, an individual page measures 997px square. That's awfully close to 1000, but it's just a coincidince.

A page whose viewport is set to 2000 x 2000px would also be displayed in a spread at almost 997px square. Actually, it measures 1010px square, because the faux pages are smaller and take up less room.



(If you're wondering why the image shrunk, go back and read yesterday's post.)

More importantly, when you have a square page viewed in a spread, there is a lot of letterboxing. And when you zoom in, you'll see as much of the facing page as fits in the space left over from the square:



Now what happens if you turn the iPad sideways? Viewing a spread of square pages makes them pretty small.



And when you zoom in, there's a fair bit of letterboxing above and below, and not so much room for the facing page.

So, how do you take advantage of the real estate?

Of course, if your book is designed to be square, there's not much to do about it, but if you're designing a new book, or have some leeway for adjusting an existing design, you can choose a viewport that better takes advantage of an iPad's screen.

There are two options in this vein. You can either choose to have a spread of facing pages fit on the screen, or you can have a single horizontal or vertical page fit on the screen. Let's look first at the facing pages option.

Suppose you want to create a book whose spread fits into landscape orientation view on the iPad. If the iPad measures 2048 x 1536, and you leave out 64 pixels for top and bottom real estate and 56 pixels for faux pages on the ends, you get 1984 x 1480px. If you have 1984px for the entire width, that means you'll need to set the width of one of the pages to exactly half that, or 992px. The height of each page will still be 1480px.

In this particular example—more Monarchs!—I filled the left page with the left half of an image and the right page with the right half of an image. So the spread looks like one large image, with only the telltale faux spine in the middle giving it away.



Now, I will admit that if you double click the spread, it moves the tiniest bit. I don't know if there is a perfect size that eliminates that. If there is, I couldn't find it. (This is different from the weird flicker that you get sometimes when flipping to a new page. That is a different problem altogether.)

You can't zoom in on that page because it already fills the screen.

If you turn the iPad sideways, you get letterboxing above and below, as you might expect,



but when you zoom in on a single page, it fills up practically the entire screen with no letter boxing and a minimal overlap of the facing page.



It's pretty good.

What happens if you change the viewport to 1984x2960? Note that that is precisely double the size we were using.

Once you change the width of each image to 1984px, it looks exactly the same:



There is one important difference, however, which I'm going to save for another post.

Until then, let's look at other options for the viewport. While you could create facing pages that would fit in a vertical screen, they'd be really skinny. There might be a reason to do that, but I'll leave it for you to figure out.

Instead, let's look at how to maximize the real estate of individual pages. There are a couple of reasons why you might favor individual pages instead of a spread that combines two pages into one. First of all, it's simply a different look to turn an entire page rather than turn a half of a page.

But secondly and more importantly, you can only apply Javascript within a single page. So if you want to activate something on the right side by doing something on the left side, you'll have to have both sides in the same XHTML document, that is, in an individual page.

Individual pages that maximize screen real estate

We've actually already seen how to maximize portrait orientation pages. Just use the same measurements as we did for the spread, but fill the right and left pages with distinct material.

Let's look instead at horizontal pages. Again, if we're starting with 2048 x 1536, then we have to subtract 64 for vertical real estate, 28 for the faux pages at one end, and 120 pixels for the minimum overlap of the facing page. That leaves us with 1900 x 1472px, which I'll round off to 1900 x 1470px so it's easier to remember.

Since each page is going to be independent, each image must occupy the full terrain, 1900 x 1470px.

If you view the book zoomed out, the pages are rather small:



But if you zoom into a single page, it takes up the full space available in horizontal orientation:

Other sizes

Of course, you can make a book any proportions you wish. You simply have to keep in mind that, as with the square example, there will either be a fair bit of letterboxing when the reader is zoomed out, or a lot of overlap from the adjacent page if they're zoomed in.

What about zoom?

I know, I keep hinting about zoom, and it's really important. But it's going to have to wait until Monday, independence or no.

The Viewport in Safari and Fixed Layout EPUB in iBooks

I owe you all a really good EPUB related post! I've been working on some interesting concepts in Fixed Layout books (as well as about twelve other projects) and I wanted to share some of what I've learned. That Fixed Layout Miniguide is getting really long in the tooth, and I hope this helps to update it. I will be publishing a new Fixed Layout miniguide in the near future, based on the articles you're about to read on this blog, starting with this one. If you want to support this project, I invite you to subscribe to my site.

First, let's talk about viewport, perhaps the most widely misunderstood concept in webpage and ebook design. I'm not even sure I've got it totally clear. Which is why I take lots of screenshots.

What is a viewport? Very loosely, it's the area that you have to work with, the area where a web page or ebook will be displayed, on a mobile device (not a desktop computer whose windows are always variable). The trick is how to figure out how it relates to a given device size. And what happens if you can (or can't) change that device size, like when you make a window bigger and smaller. Let's look.

To begin, I created a very simple page with a bit of text, an image whose width I set to 500px and a 1px border around the body:

...
<head>
<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />
<meta name="viewport" content="width=1000" />
<title>Test Viewport</title>
<style type="text/css">
body {margin:0;padding:0;border: 1px solid black; background:yellow}
p {margin:0;padding:0}
</style>
</head>
<body>
<p>Viewport measures 1000</p>
<p>And this image has width of 500px (actually 1100px wide)</p>
<p><img src="1100x1731.jpg" alt="1100x1731" width="500" /></p>
...

You can download it here.

And then I displayed it in Safari for iOS on my iPad 3:



The important bits to notice are that the image whose width is set to 500px takes up half of the 1000px viewport in Safari iOS. (OK, almost half, since I've got a border on the background that takes up 1 px on the right and 1px on the left.)

Now what happens if we change the viewport size to 750px or 500px?



With the viewport equal to 750px, the 500px image takes up about 2/3 of the page. It's as if you said "now the area the browser has to work with is just 750px".



If we set the viewport to 500px, something strange happens: the image is actually bigger than the so-called viewport (because of the 1px border).

Now look at what happens if we change the viewport to 250px:



The image still fills the screen, it's the exact same size it was when the viewport measured 500px, but now we see that the body with the border around it measures about half of that screen (250px).

There's also one more very important thing to notice. The size of the text was different in each instance:



(Note that it seems there's a minimum viewport size of 200px. Also, the text appears the same whether the viewport measures 500px or 250px. Not sure exactly what's going on there.)

What about the viewport in iBooks?

The idea is similar, but iBooks has its own quirks. Surprise!

You can download the 500px version of the Viewport test ebook here.

In iBooks, you not only have to specify the width of the viewport, but also the height. In these examples, I will change them proportionately so that we're not looking at too many changes at once.

First, here's an ebook, containing roughly the same page as above, with a viewport that measures 1000 pixels wide by 1574 pixels high. The width of the image is still set to 500px. (I've moved the text around in these examples so it's easier to read, but I didn't change its size from one book to the next.)



Notice how the image takes up half of the page size (500 is 1/2 of 1000).

Let's try with a viewport size of 750px wide:



There are three important things to notice here. First, the same 500px wide image now takes up 2/3 of the page. Second, the text is a bit bigger (since 4em depends on the viewport size), and third, and perhaps most surprising: the book itself didn't change size at all. There is exactly the same amount of letter boxing to the right and left and none above or below.

Let's look at a 500px viewport:



In contrast with the 500px viewport on Safari, now our 500px image exactly fills the 500px viewport. (I moved the text and changed its color (but not its size) so you could read it.) Again, the book itself has not changed size.

Finally, here's a 250px viewport:



Again, this is different than what happened in Safari iOS. In iBooks, with a 250px viewport, you'll only see half of a 500px image. It makes more sense, frankly.

There are a couple of things I want you to take away from all this.

1. In iBooks, the pixel dimensions of the viewport determine a book's proportions, not its absolute size. A book whose viewport measures 1000 x 1574px will look exactly the same at full size as a book whose viewport measures 250 x 394px. If the proportion of the viewport does not match the proportion of the screen itself, iBooks will letterbox the book.

2. The size of the objects on a page is determined with respect to the specified viewport. If the viewport is 1000 px wide and the image's width is 500px, the image will take up half of the page. If you have text that is 1em high, the em is determined in proportion to the viewport size. If you are positioning elements on the page, do it with the viewport dimensions in mind.

3. In Safari, an image that is larger than a viewport will still be displayed in its entirety. The viewport will still have the specified size, but there will be an intermediate, sort of extra viewport to hold the image at full size. It's almost philosophical. In iBooks, an image that is larger than a viewport will be cut off. (In earlier versions of iBooks, if you had more info than fit in your viewport you'd get that weird pile of boxes in the middle of the screen. That thankfully is no longer the case.)

4. Monarch butterflies are beautiful. When they hatch, their shriveled wings only take up about half of their regular size. It takes just a few minutes to pump them up and dry out, before they fly away.

Tomorrow, I'll talk about Viewports and Zoom. Unless Catalonia declares independence, in which case it might have to wait until Monday. Stay tuned.

Translating Twitter and Catalonia's March for Independence

Update: Twitter has reinstated my account, saying that translating tweets is not a violation of their TOS. Thanks to all who helped!

Today, hundreds of thousands, probably millions of people are marching on Barcelona to demand Independence from Spain and a new Independent State in Europe. And they're all tweeting about it, using #11s2012 and sometimes #FreedomForCatalonia.

The thing is, they're mostly tweeting in Catalan. And since this a huge issue that affects all of Europe and perhaps the world, I thought it would be helpful to translate as many of those tweets as I can into English.

Not wanting to bombard my kind and comprehensive loyal followers of my regular Twitter, who mostly are interested in my tweets about EPUB, I created a new account, @11s2012EN, and I carefully added my image and information so that it was not anonymous.

I then searched for the hashtag #11s2012 in tweets that did not contain #en. There are thousands! And I've been translating them as quickly, neutrally, and faithfully as I can. I change the RT to MT to indicate that I have "modified" the tweet (by translating it into English). Sometimes I have had to abbreviate, or remove extra hashtags in order to make everything fit, but I try to keep it as close to the original as possible.

So this:



became this (which I can't show on Twitter, because they've suspended the account):



In fact, many of the people whose tweets I've translated have then retweeted the translation, themselves.

But Twitter thinks I'm spamming by sending @ replies to people I don't know. They don't realize that I'm translating. And they've suspended my account.

So, Twitter, can you clarify? Is translating others' tweets really spam? What if they don't mind? What if they *want* me to do it? Is there another way you'd prefer I do it? Automated translation just doesn't cut it.

This is a multilingual world, and some of us who know more languages can help the rest of us who don't. You should be facilitating communication, not hindering it.

Please restore my account so that I can help people understand what is going on in Catalonia today. It is truly monumental.

And if you'd like info on today's march, try:

The Guardian: Barcelona braces for million-strong march for Catalan independence

Wikipedia: 2012 Catalan March for Independence

Help Catalonia

Or at http://www.11s2012.cat/global, where we're collecting all tweets with #11s2012 and #en in them. (I think this use of two hashtags is pretty revolutionary in itself!)

Or follow my regular account on Twitter, I try to keep the Catalan stuff to a minimum, but I'm not very good at it :)