Print on Demand, Indie Publishing, and Europe

I've been writing about how to create ebooks for the past two years, but I am well aware that ebooks, even in the United States where they are most popular, only account for some 20% of the market, and in many places, much less. For a small publisher to get a foothold, it's really important to offer print versions as well.

The answer for many indie publishers has been print on demand. For the last ten years or so, Lightning Source, a subsidiary of Ingram (a major book distributor in the US and in Europe), has let publishers upload books to their system and then print them as orders come in. They used to distribute them equally well to Amazon, to Barnes & Noble, to Baker & Taylor, and indeed to any bookstore who wanted one.

Last year, thanks to the information gleaned from Aaron Shepard's POD for Profit, and the Publishing-Update email list that he hosts, I opened an account with Lightning Source and began publishing my first print books: Barcelona, Catalonia: A View from the Inside by Matthew Tree, What Catalans Want by Toni Strubell and Lluís Brunet, and then some books of my own, Read Aloud EPUB for iBooks and From InDesign CS 5.5 to EPUB and Kindle.

At first, everything went as promised. In my tests in March, I ordered Matthew's book from Amazon and it was printed and delivered with 48 hours.

But some time during the summer, Amazon changed the way it handled Lightning Source books, in favor of its own POD service, CreateSpace. Aaron and his community were the first to notice that Lightning Source books were suddenly not "in stock" on Amazon, but instead would ship in 1-3 weeks. This, of course, is a killer for any book. Part of Amazon's strength is its reliance on impulse buying, and 1-3 week delivery does not inspire anyone to buy a book right away. At the same time, CreateSpace books were always in stock.

Aaron developed a system called "Plan B" for dealing with this issue, which involved publishing books through both CreateSpace (to get the best availability on Amazon) and Lightning Source (so that books would also be available to Barnes & Noble, Baker & Taylor, and independent bookstores. I heartily recommend going through it carefully.

I have followed the Plan B system with my own books with success, but was still frustrated at the inavailability of Lightning Source books on Amazon outside the US. I sell a full 50% of my electronic versions of my books outside the US and I'm sure that print books would also sell abroad if I could only get them there. The deteriorating relationship between Lightning Source and Amazon meant that my books were available through Lightning Source's impressive list of distributors, but had 1-3 week shipping times from Amazon UK, Spain, France, Germany, and Italy.

It was really frustrating.

So, I was really excited to hear that Amazon's Print on Demand service, CreateSpace, is now available in Europe. If you already have your book available on Amazon CreateSpace in the US, you just have to go CreateSpace and activate your European markets. It's quite simple. And your book will be guaranteed in stock throughout Europe.

So, now you can buy Read Aloud EPUB and From InDesign CS 5.5 to EPUB and Kindle in print from Amazon all over Europe (in English and Spanish!), as well as my books about Catalonia.

Pepcon 2012

I'm writing this on the plane on my way home from Pepcon 2012. I'm tired and annoyed with the TSA, but even they cant take away my appreciation for having gone. As much as I love and value the connections and communication that happens online, there's something about meeting people in person that somehow makes it all real.

I wanted to write a little about what it was like so those who couldn't go could get a feel for it.

I didn't get to Pepcon until almost 3pm on Monday due to some prior commitments. But there were some sessions still going on when I got there, and I listened to part of Mike Rankin's top ten Long document tips and then a bit of Bob Levine and Keith Gilbert's presentation on DPS. One of the hardest parts of most conferences for me is wanting to listen to multiple presentations at once. My solution is to wander from one to the next, but it's imperfect at best.

Let me confess that I don't know a thing about DPS, but my first impressions aren't that great. It feels like a dead end to me, and I personally can't stand subscription programs; I don't want to be locked in month after month, I want to own. And it's all images, even the text?? No. I want standards so that my content doesn't get lost under proprietary formats. I don't want all my eggs in anyone else's basket.

After the sessions I took part in the first of two meetings with the senior InDesign engineers from Adobe. I've been on the InDesign beta team for a while so their names were familiar, but this was the first time I had met any of them in person. I was totally impressed. They asked us what we wanted (in terms of InDesign support for EPUB) and then carefully listened as we debated the merits of different solutions and the problems of various strategies. They didn't make any promises and they didn't make us sign any NDA forms, they mostly just listened and gave us feedback about our complaints.

One of my big complaints was that the CSS that InDesign generates has too many default values, and doesn't take advantage of CSS' power of inheritance (the cascade). It's tricky, because you can have an unending hierarchy of styles based on other styles in InDesign but the most obvious way to translate that to CSS involves using multiple classes, which are unfortunately not supported by all ereaders. There is limited cascade without multiple classes though there is the body, the p elements and then individual classes.

Throughout the course of the two meetings (almost four hours) we talked about a lot of issues. We didn't come to any firm conclusions and they made no promises but I think the important bit was helping them talk with people who actually use the tool to make EPUB files—probably Ron Bilodeau and Colleen Cunningham were more useful in this regard than I was.

And I don't mean that in a flippant way. In my own personal experience, it's a challenge to both write about how to create EPUB and actually create EPUB files. I imagine that it's even harder writing software that creates EPUB files and actually creating EPUB files. I'll come back to this point.

After the meeting with Adobe, I went to the Pepcon Ignite session. My favorites were the ones by MarisaKC and by Kelly Vaughn, whose presentation on creating crazy shapes with various weights and kinds of strokes reminded me a bit of my own exhaustive report on the possibilities of iPhoto.

You'll notice that I haven't mentioned food yet. I went up to my room and ate some of the lovely fruit that Anne Marie and David had left for me. but I didn't go out to dinner because I still wasn't done with my presentation despite my promises to myself not to leave it to the last minute. Having to stand up in front of people and say something relevant is a really good way of proving the difference between having an idea and actually having a presentation. I knew what I wanted to say, I knew where I wanted to put the emphasis, but when I started to practice out loud, I realized (yet again) how much work it is to put those ideas into a shape that makes sense to other people. Easy is hard, and all that.

I didn't get to sleep until 11:30pm local time, which was 2:30am in my head, and I had been up since 3am the night before because I had left on an early flight. Note to self: really, really finish your presentation before you go to your next speaking engagement.

I woke up at 5am, thanks to a call from my non-time-zone-aware-daughter, but then took advantage of the time to really finish my talks, and practice them all the way through.

During the morning session, while hearing the brilliant ID scripter Kris Coppieters, admit that he “isn't an InDesign user”, and then watch several more presenters describe features I've never used and sometimes never heard of, the difference of using a program and creating the program (or teaching others how to use it) became even more clear. It's really hard to do both.

I think of the morning sessions, it was Gabriel Powell's that was the most helpful in terms of EPUB stuff: “Preparing Images for ePub/eBook”.

At lunch, I had a nice chat with Ron Bilodeau and Felipe Santos, the former from O'Reilly in Cambridge, and the latter from Brazil. These are the moments that make a conference special: catching up with people face to face that you might know online (like Ron), and learning different perspectives and needs from people you're meeting for the first time (like Felipe).

At 1:30, I gave my first talk, on Enhanced Ebooks. I started by talking about what sorts of books are encompassed by that term, and then talked about how to embed audio and video in an EPUB file with InDesign, using the techniques shown in the blog post that I published that same day. I was pretty jazzed to be able to explain to these InDesign-centric and perhaps code-cautious listeners that they could create enhanced ebooks without cracking their EPUB files and looking at the dreaded HTML.

Then Matthew Diener joined me to explain what EPUB 3 has in store, wisely showing some nice examples on both Azardi and Readium. Then I gave a more nuts and bolts look at exactly what EPUB3 code looks like. It's not that different from EPUB2, you'll be happy to hear. There were many fewer listeners in the EPUB3 talk than the Enhanced Ebooks presentation. I think people are wary of future technologies that are not yet implemented. But as I mentioned yesterday, EPUB3 is now supported by the iBookstore, and Apple is using it in standard ways to provide a better user experience. It's time to make the move.

After my talks, we had another two hour meeting with the InDesign crew, in which we discussed indexes at some length. One of the issues we argued about was how to label references to content. That is, if you go look up EPUB3 in the back of a print book, you might see something like:

EPUB3 12, 45-67, 78, 92

In an ebook, of course, there are no discrete pages, and so at first glance, you might be inclined to do away with those references altogether and use something like:

EPUB3 1, 2, 3, 4

But I argued that even though the page numbers themselves might be an artificial construct, they still give us information about what we might find there, that is lost in the replacement solution. In the example above, I might expect a short introductory mention on "page 12", a more thorough treatment on "pages 46-78", and less introductory, but still short mentions on "78" and "92". How do we convey that information without the actual page numbers? The short answer is, we don't know yet.

Finally, it was time for dinner. I was looking forward to meeting EPUB coder extraordinaire Rick Gordon for the first time, and had put out a call on Twitter to see if anyone wanted to join us. It was a really interesting bunch in the end (about 10 of us) who made it to the Jazz Bistro Les Joulins, just down the street from the hotel. The food was good, and the conversation interesting, and heavy into code :)

Not quite done, in the morning, I spent an hour at the Meet the Author's table with Steve Werner, InDesign expert. I'm not sure people really knew we were there, but I got to talk to a few people who wandered over.

The last thing on my agenda was to talk to Kris Coppieters and see some of his amazing scripts in action. He kindly came out to give ma demo and I was totally enthralled. While I had originally talked to him about a script that converts blogs to InDesign documents, I was most interested in his CSS Geometry which spits out the coordinates of the text blocks in an InDesign document and might be very useful in generating Fixed Layout ebooks from InDesign.

And I did get to see a cablecar!



Many thanks to Anne Marie Concepcion and David Blatner for inviting me, and in general for organizing the conference and getting so many interesting people together! (And thanks to Matthew, whose nicest tweet ever is still making my day.)

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!!

Announcing and Denouncing Spanish Hate Speech towards Catalans

I came across a new Catalan website that has been documenting a very disturbing trend of Spanish hate speech towards Catalans. The site, Apuntem.cat (which means, We take note), retweets and records the hate speech so that people understand what Catalans have to deal with on a daily basis (and perhaps some of the reasons behind Catalonia's independence movement).

Honestly, I find Apuntem's Twitter stream really difficult to read. The people they retweet are really vile. But I agree with Apuntem's basic premise, that it's important to shine the light on them. Indeed, it seems that many of the posters have deleted their Tweets after Apuntem outed them, for shame or embarrassment, who can say.

Here's a sampling of commentaries from back in March about some kids in a school in a little town called Ripoll who sung the Portuguese song "Ai se eu te pego" in Catalan. You can find the original Spanish versions collected here.

"Infinite contempt upon hearing the kids singing Michel Teló's song... IN CATALAN #CastillianWhereAreYou"

"Disgusting kids... "renew, renew" over and over again, and on top of it all, in Catalan."

"Shameful those 6 year olds who were on channel 4, that at that young age, they're already speaking Catalan."

"They bring out some disgusting kids singing in Catalan... this is Spain for God's sake!"

"Catalans make me sick, children, parents, old people... all of them, hope they die."

"Those kids who came out to sing to Guardiola in Catalan should have been drowned upon birth. There would be less garbage."

"It's like a kick in the mouth hearing those kids sing in Catalan. That's what you get on sports channel 4."

"What a shame that they teach those kids to speak Catalan at such a young age. We're in Spain!"

---

That was about little kids. When they're talking about Pep Guardiola, FC Barcelona's coach for the last four years who just retired and who gave his farewell speech in Catalan, it gets worse. (Original Spanish hate tweets.)

"Pep, hope you get it in the ass, don't speak Catalan, you son of a bitch."

"What a fucking obsession with speaking Catalan, god damnit."

"Go ahead, speak in Catalan, but I'll shit and stomp on your ancestors Guardiola, die.

"Guardiola speaking in Catalan, he should be ashamed!!!! CLOWN! YOU'RE A CLOWN"

"Jail for Guardiola for speaking Catalan in stadium full of Spaniards."

"What a shithead disgusting Catalan!!! Speak in Spanish you fucker. #disgustingcatalans"

"Pep, speak in Spanish, you Catalan shithead."

"Son of a bitch Pep speaking in Catalan... Speak Spanish you asshole"

"What a lack of respect! Speaking in Catalan? And what about the people who don't understand it? That's his humbleness. Fucking Catalonia."

---

And it goes on and on. And I didn't even translate the ones that suggest bombing the Catalan football stadium. They should be ashamed. And everyone who lets such hate speech go by without reproach shares the blame.

Indeed, it seems that some are ashamed, and take down their tweets. They should never post them to begin with.

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.