Oh Apple, what are you doing? So misguided. You add DRM to all your ebooks. And now, you have crippled iBooks 1.1 so that it won't recognize fonts applied with perfectly standard CSS to any
body, p, div, or span element. Your guidelines state that ebook designers should not choose fonts, stating that it "creates a bad user experience". You are wrong. Apple designers choose fonts for everything Apple does. Because fonts matter. Indeed, you have chosen the fonts for iBooks and for the iPad. And now you have chosen to keep ebook designers from choosing the body font for their ebooks. It is a very shortsighted decision.
The ePub specification requires that conforming ereaders, like yours purports to be, support
font-family, among other CSS 2.0 properties. Indeed, you do support font-family for most inline elements, like b, em, code, and even some block level elements like dl and li. Why then not the biggies: p, div, and span? Your desire for control will ultimately break these standards or it will break iBooks. It will break standards as it incites designers to use ugly hacks to overcome iBooks' broken support for standards. It will break iBooks as people design beautiful standards-compliant ebooks that look great in other readers that support standards.
Or should we just go back to Internet Explorer 5?
Here is a screenshot of a number of elements, all of which are styled with the following declaration:
{font-family: sans-serif}. Here is the XHTML file and the perfectly standard CSS on which the ePub is based. Click on it to see, in a standards-compliant browser, what it should look like (hint: everything should display in a sans-serif font). Or download the ePub file itself to your own iPad.
[updated June 24, 9am] Just in case it wasn't clear, the example above is not meant to be an ebook design, for goodness sake! It is the simplest possible example that shows which elements can be modified with
font-family in iBooks 1.1. The "Ew" in the screenshot means "iBooks is disregarding standard CSS" NOT "I don't like serif fonts".
I don't like this. It reeks of Microsoft's "Embrace and Extend" strategy.
ReplyDeleteOne question: When you were able to specify fonts, were they appearing as sharply and clearly as the Apple-supplied fonts? I suspect Apple is using customized fonts and is also paving -- forcing -- the way for iPad Retina Display (or at least *Apple* ePub *compatibility* with iPhone RD).
All of the fonts are Apple supplied. Font-embedding has never been supported in ibooks. There is absolutely no reason, technical or political for them to customise fonts.
ReplyDeleteI suspect that this really is about not trusting the quality of the mass-auto-converted big publisher epubs by limited the amount of design that is possible.
@mikecane The issue still applies even if your only intent is to choose from among Apple-supplied fonts.
ReplyDeleteThis is about licensing...nothing else. Do you really expect Apple to pre-load every font?
ReplyDeleteNo, it has nothing at all to do with licensing. iBooks supports using any iPad pre-installed font perfectly well on *some* elements and not on others, particularly not on big, generic elements: p, div, body, html, and span.
ReplyDeleteDo any of the ebook apps do a better job? I see the Barnes & Noble reader uses sans-serif and Stanza incorporates art, but the font looks pretty bog standard serif.
ReplyDeleteThe FSF and others have been warning people about Apple's approach to platform freedom for years. As usual, XKCD says it best: http://xkcd.com/743/
ReplyDeleteMaybe Apple simply broke the XML parser in the 1.1 update?
ReplyDeleteLiz, about Apple adding DRM to all its ebooks: This is strictly a decision of individual publishers. Apple's uploading application for the iBookstore gives the choice of DRM or no DRM. But just as with music companies in the beginning, publishers are not ready to give up their DRM.
ReplyDeleteI stopped after you rant about DRM and blame Apple for this.
ReplyDeleteSorry but DRM is at the behest of book publishers. Complain to them.
And oh, I totally disagree. Just like the web I should not be beholden to designer conceit like 9px fonts.
@artbrut
ReplyDeleteI don't think you can absolve Apple in this. Apple does not allow you to publish DRM free books via iTunes even if you want to.
As for designers, i want to have cake and eat it too. I want designers to be able to make things look the way they want without resorting to tricks that ultimately make it impossible for the client to override, augment, enhance, index and all kinds of new things. Have we forgotten the horrible abuse of HTML tables?
Point size is most often chosen in relation to line length. A short measure calls for smaller text sizes. So it's not so much designer conceit as it is designers trying to pick type sizes that allow for a comfortable measure and therefore and more pleasant reading experience.
ReplyDeleteI think you're being a little harsh on iBooks. In my tests Stanza handles fonts almost exactly the same way. The designer's choice for body, div, and p are ignored. The only difference is spans, where Stanza respects the stylesheet. I think both readers are grappling with how to strike a balance between the designer's and the reader's choices, and I think it's important that the user be able to select the body font. I still like my solution — implementing the "!important" modifier.
ReplyDelete100% agree with @artbrut .
ReplyDeleteIt seems almost a bit ironic that you feel frustrated with Apple, as if your hands have been tied on this....but if you had your freedom on this, you'd turn around and restrict the book's purchasers....by forcing a font on them. (Just a different version of 'desire for control', no...?)
Font selection should be the reader's choice. People aren't buying epubs for the typography. They're buying them for the ease and flexibility. (And, sometimes, for people with eye issues, for control over fonts.)
Your prescribing fonts is as objectionable as DRM in some ways--an exercise of power and control over your customer. Your customers are grownups. They can pick their own fonts.
The sooner book designers quit worrying about fonts (and kerning and leading), and start focusing on flexibility--how to tell a tale in one variable-width column that'll work on every device the customer ends up using--the better epubs will become for readers. That's what it should be about, no?
I say: thank you, Apple, for removing a time-consuming, single-platform distraction and helping us keep our eyes on the prize.
I'd prefer that font override was at the user's behest. Some people will do a wonderful job of presenting poetry in weird and amusing fonts.
ReplyDeleteIn the meantime, font override at Apple's behest is the lesser of evils.
How much time do typography geeks spend critiquing fonts? MS Comic Sans, anyone? Trebucet? There's even a blog site dedicated to *ampersands*. The perfusion of fonts leads to ePubs that look like a bad Geocities page.
Now what happens when you get one typographer who is head-over-heels in love with Comic Sans, presenting an entire book in that font - to a world of people who loathe the font?
IMHO, Apple has been driven to this because they want to uphold the UX of their application, against a flood of people abusing webfont inclusion in ePubs.
On the other hand, this opens the door wide open for someone (anyone) to release a 100% standard compliant ePub reader for iOS which users can load their own books into. Stanza's not there, iBooks is not there either.
Then when it arrives, you'll find the first request that people will make will be, "can I please override the book's CSS with my own?"
An interesting thought: When the Mac first came out, a lot of people thought it was a toy because of the way people went overboard designing documents with loads of garish fonts. Maybe Apple is trying to avoid a replay.
ReplyDelete@manicdee: "one typographer who is head-over-heels in love with Comic Sans" is a contradiction.
ReplyDeleteever heard of a bug? relax man
ReplyDelete@artbrut isn't understanding the problem.
ReplyDeleteThe problem isn't about the font-size CSS property. It's about the font-family CSS property.
And no, this isn't a bug. It's a deliberate decision by Apple. More big-brotheresque nonsense.
I recently created an ePub that uses embedded fonts because the book in question uses some special characters and formatting that I cannot replicate by any other means. Unfortunately, there's nothing I can do to make it work with iBooks. They've broken my book.
Perhaps one of the central issues here is a disagreement on the boundaries of the author's artistic expression. Is it confined to the words, sentences, and paragraphs? Or, does it include more, such as page layout and font selection?
ReplyDeleteI have always concerned myself with more than the text and consider any alterations an encroachment on my creation. When purchasing a painting, for example, the buyer does not expect to be able to change the colors to better suit his taste. A buyer can find another painting or contract a special commission. Likewise, with print books, a purchaser can decide to forgo buying a certain text because the font is too small.
I imagine that many authors would readily yield control of all but their words if it means greater sales of books. However, other authors view their creation to include layout and font selection. Personally, I am in the later category. I am happy to lose sales at the cost of controlling the "experience" of my work. I don't think there is a "right" or "wrong" perspective here, but I do believe that this decision belongs to authors and not readers.
The problem I find with not having control over fonts is related to the type of publication I am working on doing. I am converting a magazine with articles that each have headlines and imagery. I have a specific set of fonts I use and at times, the start of an article has the headline intertwined with the image. It is a magazine. The article headline and look of it entices people to read further. I already have a serif and a sanserif font set for the pub. With the generic fonts the readers use or the option for users to select fonts, we now have a horrible mixture of fonts. I find this to be somewhat of a problem, where the look of the magazine is important.
ReplyDeleteHi Liz
ReplyDeleteI bought your book yesterday and skimmed through last night, it is excellent but a few questions arise. What page size do you use in InDesign given that it doesn't allow for px as a unit? Also your skill with writing code far exceeds mine so I intend to enlist Dreamweaver to help in the "post prod". Any thoughts on this?
Best
Graham
For all of you who say font is irrelevant. You are overlooking some very important points when font IS very relevant, and in an area that Apple and other eBook makers have been trying to court, Textbooks.
ReplyDeleteHave any of you really looked at a science, math, or programming textbook lately? They almost all use font selection to convey meaningful information.
Computer textbooks will often use a serif font for the body of the text and a monospaced font for the actual code text. This is not just some "typographer's choice", this is an element of the information being presented. Science and math books almost all use a different font for formulas and variables than they do for body text.
I agree that some people can go overboard with fonts, and I agree that users should be able to choose the body text font of their choice. However, it is incredibly stupid and irresponsible of Apple to break font selection on a serif, sans-serif, monospace level. Let the user choose the font for each style, but DON'T ignore this level of choice as often there is information conveyed in that level of font choice.
Many of the comments here seem to overlook that the first "C" in CSS stands for "cascading". CSS fully supports the author/designer making a set of design decisions, letting Apple provide a "recommended" (but optional) over-ride, and the user having the final say when it comes to font choice and formatting.
ReplyDeleteWhat Apple has done is take a situation where we all could have had our cake and eaten it too, and mandated that everyone eats Twinkies.
Sadly, Apple seems to be following Adobe and the rest of ePub community down the path of the browser wars of the 1990's. There's a standards based rendering engine under the iBooks hood, and Apple crippled it for no apparent reason.
I assume the four new fonts for OS1.5 are in addition to the old list? Or did we lose Verdana, Baskerville, and Cochin entirely?
ReplyDeleteFWIW, viewing this in Adobe Digital Editions makes all the paragraphs dishonor (heh) the sans-serif CSS.
ReplyDelete