Generally, a designer sets the font for an iBooks ebook by adding a
font-familyrule to a
divselector 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
div, say, with
li, etc., the font persisted, even when the reader chose a different font.
David had also discovered that you could use the ancient
fonttag 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
spantag. Second, and somehow more disturbingly, if you apply a font to a particular paragraph via a
divtag, and then try to use
spanto 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
fonttag discovery was a red herring. You can use any tag—except
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
classcalled "inlinecode" and applied it to the code bits, by way of a
Here is (some of) the style information for both the paragraph and the inlinecode class:
<p class="body">Add a <span class="inlinecode">class</span> to the desired <span class="inlinecode">p</span> element in your XHTML document.<p>
However, because of iBooks'
spanbug, 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
spanelement, I use the
codeelement (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
spantag. If you specify font choices with
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.
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