Getting iBooks to respect image width

So, I wrote a long time ago about how iBooks doesn't apply the CSS width property to images properly. Despite the fact that the spec says that width applies to all elements except non-replaced inline elements, and that images are replaced inline elements, up til now, iBooks wouldn't apply width to img. There is a workaround: applying the width to the image's parent, and setting the width of the image itself to 100%, as I describe in that article.

What's more frustrating is that since InDesign follows the rules, dutifully applying the pixel or percentage dimensions in the CSS directly to the image—which again, should work but doesn't in iBooks—those images are not displayed properly in iBooks.

So here's a document in InDesign: (I'm showing you the example in InDesign, but I would have the same issue if I created the code myself from scratch.)



Here's the code that InDesign generates when I choose "Preserve appearance" and "Relative to page"



And here's how iBooks displays that page:



I wrote Douglas Waterfall, Engineering Architect on InDesign, about the problem and he pointed me to the solution, right there in the iBooks Asset Guide (which you can download if you have an iBookstore account).

The solution consists of creating a super-charged or magic CSS class that you can then use to properly apply the width property to img elements in iBooks. And it won't confuse ereaders that already do.

First, in the content.opf file, you have to make sure you have declared the iBooks namespace in the package element. You need this namespace if you use iBooks versioning as well. And it's completely harmless for non iBooks ereaders. (Note that I'm doing this in EPUB 3. I don't know and haven't tested it in EPUB 2.)

<package xmlns="http://www.idpf.org/2007/opf"
prefix="ibooks: http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0/" version="3.0" unique-identifier="bookid">

Next, in the meta section of the content.opf file, define which class should be able to apply the width property properly.

<meta property="ibooks:respect-image-size-class">respect</meta>

I called my class respect, but you can call it whatever you like.

Next, in the HTML, apply the respect class to your images.

<p class="Basic-Paragraph"><span><img class="respect" src="image/imagefolder-2_fmt.png" alt="imagefolder-2.jpg" /></span></p>

You can actually create multiple classes, as long as they are equal to, or prefaced with the name you declared in the meta element. So I could use respect, respect-wide, respect-small, or whatever.

Finally, create a rule in your CSS that references the respect class and applies the width property:

img.respect {
width:51%;
}

(Of course, if you're using InDesign, you can simply create a style called respect and let InDesign create your HTML and CSS.)

And then, miracle of miracles, iBooks applies the width property, just as it should.



Seems crazy that we have to help iBooks follow the spec properly, but at least we can.

If you like this post, please consider subscribing!

InDesign CC - Embedding Fonts

One of the most appreciated improvements to InDesign with the new Creative Cloud edition is that it finally embeds fonts in a way that iBooks understands. Let's take a look.

In InDesign, there is always some font chosen for text. You can't have "none". When you export a book to EPUB, the default is for InDesign to "Include Embeddable Fonts"



The problem is that InDesign CS 6 doesn't do it right. Whether it's Adobe's fault or Apple's or the IDPF's, I've never been quite sure, but the truth is that there were two major problems: the font didn't get obfuscated properly and InDesign didn't account for iBooks' idiosyncracies (read: non-standard font requirements).

So, given this InDesign document:



InDesign CS 6 exports a file to EPUB that looks like this in iBooks:



My design surely lacks penache (it was designed to take advantage of the fonts that were available on the iPad in 2010), but if that's what I want, that's what I want InDesign to give me.

Now InDesign CC does. Notice both the Bradley Script for the headers and the Optima for the body text.



I heard that it finally got the obfuscation right (or in accordance with Apple), but the coding news is that it also caters to Apple's requirement of including the com file in the META-INF folder.



And here's what it looks like on the inside:



Apple's com file is totally non-standard (that is, not part of the EPUB3 spec), but regardless, if you want fonts to work in iBooks with an EPUB 2 file, that's what you need, and I think Adobe made a great decision by including that file automatically so we don't have to crack open the EPUB to add it ourselves. Since the com file doesn't affect other ereaders or validation, there's nothing to be lost in adding it, and everything to be gained.

Note that I said EPUB 2, but InDesign CC actually includes the com file in EPUB 3 exports as well. That's not perfect—since Apple now follows the spec for declaring font usage in a meta element in EPUB 3—but it still works and better yet doesn't break anything. And given Adobe's dedicated support for EPUB lately, I'm confident that they'll roll the new behavior into InDesign CC soon.

One small caveat: remember that if you have Preserve Local Overrides unchecked and you've applied fonts with an override, then you shouldn't be surprised if the fonts don't make it to the EPUB file.

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.