InDesign TOCs to EPUB

I'm exporting an InDesign document to EPUB and for some reason the formatting that I've applied to the TOC title doesn't stick. I click in it and look in the Paragraph Styles box and it says TOC title,



but when I export, it says "No Paragraph Style". I go back again, check once again in the Paragraph Styles box, export, and once again, I get "No Paragraph Style".



What's going on?

And here's where going to trade shows really helps. I mentioned a while back that the engineers at Adobe are really open to suggestions and requests, and it happens that a couple of them came to my EPUB3 talk the other day in New York City. We talked for a bit afterward about my wish for a single file for both the navigational TOC and for the regular, in-the-body-of-the-document TOC (which I describe in some detail in my slides which you can find at the previous link). And the engineer told me, “but since we regenerate the ncx file upon export, we wouldn't know if the user had changed something in the text”.

Remembering that today helped me realize why my format wasn't making it through. InDesign doesn't pay attention to the document that's on your page upon exporting a TOC to EPUB, it only looks at the TOC Style, and what you have defined there. And here's what I had:



Since InDesign uses this definition and not what you see on the page to generate the TOC in your EPUB document, it was giving me "No Paragraph Style".

Once I updated the TOC style, I was able to get the TOC title to be exported with the proper style.





Unfortunately, InDesign CS 6 has a bug which keeps it from properly splitting an EPUB on a style that's part of a TOC. Argh. So, in the end, I had to add the TOC title separately in my InDesign document to ensure the break. (I also had to get rid of the title from my TOC style so that it wouldn't be repeated there.)

Still, I think it's important to keep in mind that when InDesign generates a TOC file, it gets the information from the TOC Style definition, and not from the content that you may have edited on the page.

Linking to external video (and audio)* in EPUB3

I forget when I first saw the option in the iBooks settings panel, but I know it was a long time ago. Enticingly, it said Online Content, and had an On/Off switch. And underneath was a short explanation: “Allow books to access publisher's content from the Internet.”

EPUB used to be a strictly closed affair; all of its content had to live within the EPUB package itself. But in EPUB3 an exception was made to allow remote access for audio and video elements only. These two things together could only mean one thing: that remote video was now possible in an ebook, at least on the iPad.

Why is it important to be able to access remote video and audio files? For starters, keeping your audio and video out of the EPUB can make your EPUB a lot smaller and much more agile. It will download much more quickly. On the other hand, in order to see that video, your reader is still going to have to download it at some point, and they might even do it multiple times, which can be a drag on your server.

Another reason to host video or audio remotely is to give access to multiple formats of the file. EPUB3 has the capability of looking through a series of links and only using the one that works best in a given ereader. Including multiple versions of a video file in an EPUB file would result in unnecessary bloat. (Of course, this is a bit of a moot point in a world in which video and audio in EPUB mostly works in iBooks, but that is changing with Readium, and surely with newer ereaders. The fact that there is no agreed upon codec for video is also an important factor.)

Finally, if the video is hosted remotely, that means you can update it at any time. Note, however, that you must be careful to maintain the same link that exists in the EPUB file.

The code

So how do you do it? I've tried a bunch of different techniques in the last few months, but couldn't make it work. Today, while reading Matt Garrish and Markus Gylling's EPUB 3 Best Practices, I discovered that they have figured it out. It's not complicated at all, I should have figured it out too :)

The code is very straightforward and not that much different from embedding video files right in an EPUB document.

1. First, in the HTML document (mine's called outvideo.xhtml), create the video element as usual, obviously using the proper URL for the src attribute:

<video controls="controls" poster="image/poster.jpg" width="384" height="276">
<source src="http://www.elizabethcastro.com/epub/examples/catbox.mp4" />
<source src="http://www.elizabethcastro.com/epub/examples/catbox.wvm" />
</video>

Although the controls attribute isn't required, I recommend it. Otherwise, your reader won't be able to start (or stop) your video. Also note that I was playing around with WebM video, but wasn't really able to get it to work. But I haven't given up yet.

2. In the content.opf file, you have to do two things: list your video in the manifest as if you'd included it in the EPUB document, and then declare that the HTML file that contains the video points to an external resource.

a. First, we'll manifest the video.

<item id="vid" href="http://www.elizabethcastro.com/epub/examples/catbox.mp4" media-type="video/quicktime" />

b. Next, in the manifest of the HTML file that contains the video, declare that you're using an external resource:

<item id="outvideo" href="outvideo.xhtml" media-type="application/xhtml+xml" properties="remote-resources" />

And that's all there is to it. What does it look like?

If your reader has the Online Content option in iBook preferences Off, all they'll see is the poster image:



If your reader has Online Content On, they'll be asked if they want to access your online content. It's good that they have a choice, since they may want to wait to download videos until they have wifi available.



Finally, once they click the Allow button, the video will download and become available.



Keep in mind again, that if they no longer have connection to the Internet, the video will stop being available (even if they never close the book or leave iBooks)



It works in Readium too:



You can download the example file here.

*Update: Yes, audio works too. Don't forget to use mime-type audio/mpeg when declaring audio file in content.opf file. And making sure your file paths match the actual file locations helps too :) Thanks to Alberto Pettarin for help troubleshooting.

Smashwords asks for EPUB files for testing

At the end of 2011, Mark Coker, Smashwords' founder, CEO, and Chief Author Advocate, promised that they would be accepting EPUB files by year's end. Yesterday, in the Site Updates section of the Smashwords' website (you have to be signed in to see it), there was an announcement:

December 28, 2012 - Smashwords Direct alpha testing underway. We're preparing to launch Smashwords Direct, our direct .epub upload option. One year ago in my 2011 annual year-in-review over at the Smashwords Blog, we made a commitment to launch SWD in the second half of 2012. We're working to fulfill that commitment. We're nearing completion of a beta version of SWD. The first iteration will enable those of you with professionally designed .epub files to replace your current Smashwords-generated .epub with another .epub. It'll also allow authors to upload .epub files instead of Word .doc files. We're inviting people with custom epubs to email them to us...

This is huge news. Although Smashwords is a major ebook vendor, especially for self-published books, many authors and publishers have been reluctant or unwilling to either create their books in Word, or submit them to the “Meatgrinder”, Smashwords' terrifyingly-named and woefully-limited EPUB conversion program. The new Smashwords Direct program will allow authors to upload professionally-designed EPUB files and thus give us absolute control over what the EPUB looks like.

So, let's email them some books and help them get this up and running!

Thanks, Smashwords!

Troubleshooting PNG vs JPEG in EPUB

So, I wrote two articles on versioning in iBooks (here and here), but I didn't tell you my main reason for wanting to update the book.

The truth is that in the first version of my Monarch Butterfly book, my favorite page didn't work on the iPad 1. That page has 10 images, each of which measures 1600 x 1100 px. As I was exploring the possibilities of interactivity, it was one of the first pages that I created in the book. And because I had a vague (erroneous) idea that Apple preferred PNG, I decided to experiment with them.

PNG affords some advantages, including allowing transparency, at least in the 24bit version. In the later pages of the book, I used this to advantage for the arrows, so that I didn't have to position them perfectly on top of the images. In addition, PNG doesn't suffer from the licensing issues that JPEG has. On the downside, its compression is not as good, so images are larger.

Here's what the page looks like. It's set up so that if you click the images across the bottom, they are expanded into the center area, so that the reader can view and control a stop-motion movie of the caterpillar emerging from its egg, and then having its first meal. If you click the center image, the animation goes backwards.



Unfortunately, when you open the original version of this page on the iPad 1, it crashes. And like I do so often when I'm troubleshooting—and this is the real lesson of this post—I assumed that the problem was that the iPad 1 was slow and didn't have enough memory, and that I had just pushed it too far by adding too many images. I decided to upload the book as is, and warn people that it simply didn't work well on the iPad 1.

The other day, someone asked me about PNG and the NOOK and I remembered an issue I had come across a year or so ago. I was helping some folks with a book with lots of images. Not particularly big images (it was a flowing book), but lots of them. The NOOK would refuse to let you navigate to the next chapter by turning pages, even though you could choose the chapter from the TOC and it displayed just fine. Very strange. One workaround was to change the images to PNG format.

And even though the problem was the JPEG in that problem, it made me think I should try to switch from PNG to JPEG. And the crazy thing is that it worked. I'm not sure if it's because the images are smaller (233Kb instead of 950Kb), or because of the format itself, but now the page works on iPad 1 beautifully and doesn't crash.

So, the moral of the story is first, don't assume you know what the problem is, and second, let those bits of information percolate in your head and spark new theories that might help—even if they're not directly related, and third, use JPEG images in EPUB for iBooks unless you need PNG's transparency!

P.S. I've just sent an email to everyone who bought the first version of the book so that they can download the new version for free. If you don't receive the email, let me know. If you bought the book through Apple, you'll be able to update the book through the iBookstore: go to Purchased Books, and then click Update next to The Monarch Butterfly Book.

And if you haven't bought the book yet, you can find the latest version on the iBookstore or on my own website.

Zen* and the Art of the Modular Ebook - #BiB12

I spoke at the amazing Books and Browsers 2012 conference, organized by Peter Brantley of the Internet Archive, at the end of last month in San Francisco. They've just made the video of my talk available so I wanted to share it.



In the video, I share the experiences with print publishing, Barcelona, and HTML that led me to where I am today—a bestselling computer book writer, turned publisher and Catalanist!

I should note that my blog is misspelled in the titles. If you're here, you know it's Pigs, Gourds, and Wikis.

And I'm particularly embarrassed that I misspoke about Matthew Tree. He is not "London-based" but rather he is originally from London, but has lived in Barcelona for the past 25 years or so. His book, Barcelona, Catalonia: A View from the Inside, has been described as “A must-read to understand Barcelona and Catalonia”.

And La Biblia del Macintosh, Tercera Edición, which was one of the first ever books about the Macintosh to be translated into Spanish actually had 1000 pages, not 500. It sold for 5000 pesetas, which was about $50, a monstrous sum at the time. I think we did an initial print run of about 3000 copies, which we financed by localizing the first ever translation of Adobe Photoshop into Spanish (version 3). We eventually sold all 3000 copies, taking advantage of the social marketing tools of the time: email, newsletters, and expensive advertisements in the Spanish edition of MacUser. I can only imagine where we could have gotten to if we had had Twitter.

They say you get less nervous the more that you speak in public. I'm still waiting!

New Contract needed for new iBookstores

I got an email from Aaron Shepard, POD expert, this morning, letting me know that it's not enough to add your books to the new 18 iBookstores (Latin America and New Zealand) that Apple made available last week. You also have to download and accept the new contract addendums! Argh. So glad he told me.

Quick overview:

First, add the new territories to your books. Start by going into iTunes Connect and clicking Manage Your Books.



Next, click the cover of the book to which you wish to add territories.



Notice that the book on the right just says "32 stores", but there are currently 50 total possible. That means I need to add the remaining 18 new territories.

You can also see, under the Read Aloud EPUB book on the left, that I had already added the new territories to this book, but the book has still not been accepted into the new territories.

Next, you'll see the summary page for the chosen book. click the Rights and Pricing button in the upper-right corner.



iTunes Connect will show you the current list of territories where your book has been added, along with the Sales Start Date, DRM, Price, and other data. Click the Add New Territories button in upper-left corner.



Choose a DRM option, Sales Start Date, Base Currency (sales in most Latin American countries in their own currencies is not available, with notable exception of Mexico), Publication Type, List Price (of print edition), and Suggested iBookstore Price (which must be less than List Price). Then check the boxes next to the territories you wish to add. Or click Select All. Then click Continue.



iTunes Connect now shows you a list of the new territories and the price for each one. You are not limited to this price. Go through the list and adjust as necessary. (The book shown here is free, so the price is 0 in each case.)



Click Confirm when you're ready. Now you'll be back at the Rights and Pricing list, with the new territories added. But notice that they're still Not On Store. (Aaron tells me that if you click on the Not On Store label, you can see what the problem is.)



Click Done three times (always at bottom right of window) to get back to the iTunes Connect main window.

Now click Contracts, Tax, and Banking on the left side of the main iTunes Connect window.



Click Request next to the new Contract amendment. I recommend downloading and reading the document. If you agree, click the appropriate box and then click Submit.

Two more Done buttons and you're, well, done.

Now when you go to Manage Your Books, you'll see that your books are available on all 50 stores.



And if you visit one of the new territories in iTunes (by clicking the flag button in the lower-right hand corner and then choosing the desired country), you'll see your books listed. It might take some time for the new iBookstores to properly index your book's search terms. At first, I was unable to find my books, even by searching on my name. Searching on ISBN does seem to work, and I'm hoping that that will get updated quickly.



Note that my book that sells for $5 in the US sells for 65 Mexican pesos which, according to Google, is indeed the going rate.

One more thing I learned last week: reviews are posted only in the iBookstore that belongs to the country of the person who wrote the review. So, there is a lovely review of the Monarch Butterfly book by Laura Brady which I can only see if I connect to the Canada iBookstore:



and folks who connect from countries besides the US cannot see the five five-star ratings that the book has in the US iBookstore.



I think it would be nice if Apple made those out-of-country reviews available (perhaps after reviews from one's own country?) If it's the same book, this is information that would be useful to all.

At any rate, keep in mind that if you want to see reviews of your books in other iBookstores, you'll have to go to each store individually. And if you've reviewed my book on a non-US iBookstore, please let me know. I'd love to see it. (And thanks!)

Presenting “The Monarch Butterfly: An Interactive Picture Book”

Over the weekend, I finally finished my first serious attempt at an interactive picture ebook. I've been working on it off and on for several years, first as I tried to take photographs that were worthy of being published, and second as I taught myself enough Javascript to create the effects that I thought were necessary to show the photographs and information in a fun and beautiful way.

Here's a short sampling of the book:



You can download a sample, or buy the whole book on the iBookstore. It works great on both iPad 2 and 3, as well as newer iPhones. I haven't tested it in other readers besides iBooks (yet).

I am writing a new miniguide that explains how to create interactive ebooks with Javascript and CSS and will announce that as soon as it's available.

If you would like a review copy, please contact me.

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.

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.