Tuesday, June 29, 2010

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.

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.

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:

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.
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.

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

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:

Emboldened, I try a few more pages:

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.

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.

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.

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.

@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.

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.

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.

@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.

@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.

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.

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.