Tuesday, June 29, 2010

iBooks is Buggy

Frustrated with iBooks refusal to play nice with text alignment and with fonts, I downloaded a new book from Gutenberg, Mark Twain's The Jumping Frog, and started fresh. I created the simplest of simple InDesign files, without adding any formatting at all, and then exported the whole thing to EPUB. It was pretty ugly.

One of the things that I haven't understood about the whole Apple-neglects-to-support-standards debacle is how their iPad User Guide (download it from the iBookstore) stays left-aligned even when I've got Full Justification set to its (absurd) default position of ON.

Apple ragged right

How do they do it?

There's no clue in the CSS. Not even so much as an !important: (And don't imagine that that text-align:left should have an effect; iBooks ignores it in favor of the Full Justification position in the iPad's general settings.)


Grasping at straws, I tried using Apple's style sheet with my (ok, Twain's) text, changing only the classes in my p elements to match the styles in Apple's CSS.

My text, Apple's CSS

iBooks was clearly not fooled.

I took a step back. I changed only two paragraphs in my XHTML file, one header and one paragraph. And lo and behold iBook suddenly remembered how to style a paragraph with a different font:
Apple's CSS, my text, only 2 paragraphs

How can that be? That's the exact same CSS and the exact same XHTML, except that instead of all the paragraphs being marked with the main body text class, only one of them is. There is nothing significantly different.

But look how not only the font is maintained, but also the left alignment. (In all of these examples, Full Justification is ON in Settings.)

Was it only Apple's lovely choice of Verdana? No, I could choose other fonts, like American Typewriter.
American Typewriter
Was it the style names themselves that held some sort of magic? No, I could create my own style names with the same style definitions that Apple had used.
New style name

Was it the style definitions? No, I could use style definitions that I had used on other projects.
New style declarations

What then? I stopped fussing with the CSS and started fussing more with the XHTML. This time I tried formatting several more paragraphs. It still works:

more xhtml with new styles

Emboldened, I try a few more pages:
page 29 and counting

They still work. I push it just a little further. And I hit the wall. All I changed was the class of a few more paragraphs in the XHTML, and suddenly, all I get is Palatino, full justified, throughout the book, from the first page to the last.
Palatino, full justified

There are some interesting things to note here. First of all, that same paragraph that now appears in Palatino was not altered at all between the penultimate test and this one. I only changed the classes in a few paragraphs at the end of the document, and that is what triggered the loss of all of the font and alignment formatting.

Further, note that the leading and font-size are maintained even as the font family and justification are lost.

I spent all day working on this, and didn't find a solution. I'm not sure there is one. I think its just a buggy program. I'm curious as to why Apple's iPad User Guide doesn't show up in the specified font, but still stays left-aligned. I haven't figured that out yet. In my tests, the font formatting is listened to at the same rate as the alignment.

For those who would say, "Apple recommends not choosing fonts" I would point out that they themselves choose fonts for their own publications, including the iPad User Guide.

And to those who marvel at this waste of time, I would caution that we must all speak up for standards, lest you soon join me in this fruitless exercise of trial and error.


  1. iBooks are useless for poetry. It's like Apple forgot poetry exists or thought noone would want to read it.

  2. Anscheinend erkennt iBooks die am häufigsten verwendete Klasse für den Inhalt und formatiert diese wie in den Einstellungen festgelegt. Klassen welche seltener im Buch verwendet werden, lassen sich frei formatieren.
    Es wäre ein versuch wert für jedes Kapitel eine eigene Klasse für den Inhalt zu verwenden, in der Hoffnung das diese dadurch ihre Formatierungen erhalten.

  3. Apparently iBook recognizes the most commonly used class of content and formats them as specified in the settings. Classes which are used less frequently in the book, can be free format.
    It would be worth an experiment to use for each chapter a separate class for the content, in the hope that those obtained by their formatting.

  4. Text is align:left in iPad User Guide because of the 〈span〉 tags.

    Remove these and the text is justified. It is enough to place 〈span〉 after every 〈p〉 and 〈/span〉 before every 〈/p〉 to reactivate the text-align:left and this can be done on a paragraph by paragraph basis.

  5. By substituting all instances of span with cite, and defining cite as…

    cite {
    font-family: "Verdana";

    … all the Verdana is held, and so is the left justification.

    Maybe InDesign's can be a blessing in disguise.

  6. The code in my comment got deleted> I meant:

    "Maybe InDesign's span='generated-style' can be a blessing in disguise."

  7. …And it wouldn't realy HAVE to be "cite". It could probably be any other inline tag that you are willing to dispose of for some other purpose, such as acronym, abbr, or whatever.

  8. @Rick Gordon Is there a benefit to this? If empty &9001;span&9002; is used then iBooks respects styles applied to &9001;p&9002; classes, which means that none of the standard mark-up needs altering and other readers such as Adobe Digital Editions and Sony Reader Library simply ignore the presence of the &9001;span&9002; tags.

  9. Whoops, messed up the entity codes in that last post, but you know what I mean

  10. It’s not in dispute that iBooks is screwing up, but your code sucks. Do not put a classname on every or even more than a couple of P elements. This isn’t how HTML works. If you want e.g. the first graf after a heading to look different than other grafs, use h2 + p.

    You can’t replace a SPAN with a CITE, so ignore that suggestion. (SPAN has no semantics; CITE does. You can’t throw darts at the board with markup.)

    To reiterate: iBooks has display bugs, but your code, and the code of your commenters, suck.

  11. Thanks, you guys, can't wait to test this out.

    Dear Joe: that's InDesign's sucky code. The rest of us are just trying to figure out how to deal with it. In a perfect world, ID would spit out perfect code and we'd just marvel at it. Alas, reality is somewhat different.

  12. @joeclark & @anthonylevings: No doubt it's ugly, unsemantic, and unsavory. It just happens to work with iBooks. I HATE having to do this kind of stuff, but this article is about finding out how to wrestle these bugs to the ground. As Liz said, the code (apparently generated by InDesign, and let us not forget, used in an Apple-distributed document) puts a span in every paragraph. The reason that simply leaving it a span is not enough (though it appearently solves the justification issue), is that a nasty bug in iBooks causes spans (even spans with font definitions) to revert to the user font. So by choosing another inline tag to replace the InDesign-generated spans (or removing the InDesign-generated spans, as I was previously recommending), there is the possibility of holding a designer-chosen font, even with p tags. I don't like it; I'm just trying to explore some way to make things work.

  13. @Rick Gordon thanks for the clarification, I had in my mind there was some span problem with iBooks, but didn't have it pinned down since I'd forgotten what I'd read.

    I think we have to think of the future as well as the present. When iBooks auto-hyphenates then the left align won't be such a big issue, and it might frustrate the reader to not be able to choose their own justification. I'm also not adverse to letting the reader choose an unattractive full-justify as long as I get my indents and the capability to fully control the appearance of displayed text.

  14. Liz, your results seem entirely consistent with the suggestions in Apple's publisher guide: Specific fonts should be used only sparingly, for local effect. So, they may intentionally be ignoring any font specifying that goes beyond that.

  15. No, Aaron, I disagree. Apple does not get to modify the EPUB spec in this way. It is harmful for Apple to allow specifying a font with h1, em, and code, but not with p, div, and span (as the official EPUB spec demands). That is as far from consistent as you can get.

    What you decide about using fonts is your decision. What an ereader/browser is supposed to do with fonts is determined by the spec.

  16. @Aaron Shepard: Where can Apple's publisher guide be found?

  17. Liz, I wasn't arguing that Apple was right in doing that. I was only pointing out that it might be a "feature" rather than a "bug."

    David, the publisher guide is available for download after you sign up at iTunes Connect, itunesconnect.apple.com.


More of my books