Embedding fonts in iBooks without bugs

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

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

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

Use this code in your CSS:

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

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

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

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

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

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



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

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

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

h1 {
     font-family: NixieOne;
     }

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



The solution is to first remove the bold:

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

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

Here's 1px stroke:

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



and with 2px stroke:

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



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

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



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

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