More on Choosing Fonts for iBooks on iPad

[Update: With iBooks 1.1, Apple has changed much of the system for applying fonts. Please read Apple damaging ePub standards with pseudo-support and Apple kills fonts in iBooks, strikes blow to standards.]


Generally, a designer sets the font for an iBooks ebook by adding a font-family rule to a p or div selector in the CSS style sheet. In an earlier article, however, I noted that the reader can override such choices by choosing a new font in iBooks' font menu.

David Mundie found that not all the text is affected by choices the reader makes in the font menu. In fact, he found that if you specified the font in something other than a p or div, say, with em, strong, blockquote, or li, etc., the font persisted, even when the reader chose a different font.

David had also discovered that you could use the ancient font tag to make font choices persistent for a bit of text. And although I found that interesting, I couldn't quite get behind using that long deprecated tag.

At the same time, I found a different problem. First, iBooks completely ignores font choices applied via a span tag. Second, and somehow more disturbingly, if you apply a font to a particular paragraph via a p or div tag, and then try to use span to apply any characteristic (even color) to a bit of that text, iBooks applies the new characteristic, but loses the font choice, reverting back to the default font that the reader has chosen.



I combined David's findings with my own, and realized that the font tag discovery was a red herring. You can use any tag—except span, p, or div—to apply a persistent font, and it works whether or not a different font has been applied to the paragraph from an earlier rule. (OK, I confess I didn't test every single element in XHTML, so if you find one that doesn't work, I'd love to hear about it.)

That is, in my upcoming book on ePub production (ePub: Straight to the Point), I show a lot of code examples, much like the names of the XHTML elements in this article. I formatted them in InDesign with a special character style called "inlinecode". When I exported my files from InDesign to (begin to) create the ePub version of my book, it created a class called "inlinecode" and applied it to the code bits, by way of a span element:

<p class="body">Add a <span class="inlinecode">class</span> to the desired <span class="inlinecode">p</span> element in your XHTML document.<p>

Here is (some of) the style information for both the paragraph and the inlinecode class:

p {
font-family: "Optima";
font-size: .9em;
}

span.inlinecode {
font-family: "AmericanTypewriter";
color: #d90000;
}

However, because of iBooks' span bug, it not only doesn't use the American Typewriter font that I chose for the inlinecode class, but it also doesn't use the font chosen for the paragraph that contains it (Optima). Curiously, it does apply the red color. (Go back to illustration.)

But, if instead of applying the new font with a span element, I use the code element (which in this case, is also semantically appropriate), my font choices and the red color prevail. (Note that the class is no longer necessary.)

<p class="body">Add a <code>class</code> to the desired <code>p</code> element in your XHTML document.<p>

A side effect is that my font choices are persistent and can't be changed by the reader, but that's a topic for another post. (The number 1 in the illustration works the same way as the code elements, just with different formatting applied.)

In summary, you can apply font choices in iBooks by applying a font rule in the CSS to any element except the span tag. If you specify font choices with p or div, they can be overridden by the reader's font choice. Font choices specified with any other element are persistent, that is, not affected by what the reader chooses in the Font menu.


Related articles:

Palatino bug in iBooks on iPad
Text Size in ePubs-- Points? Pixels? or Ems? Oh my!
More fonts for eBooks on iBooks on the iPad
Choosing Fonts for iBooks on iPad