iBooks 3.0
So, it was with some anticipation that I waited for the update to hit my iPad. Armed with a host of test files (mostly from the epub-samples repository, but with a couple of my own) I took a break from my otherwise busy day to discover the truth about iBooks’ EPUB3 support.
And ended up being quite disappointed.
But first…
I feel very sad that I have to make the following disclaimer, but history has taught me that it’s necessary:
Note: Testing a feature or format does not constitute an endorsement of said feature or format. Don’t be a goddamn idiot and criticise me for recommending X or Y just because I checked to see if it’s possible and report on what can be done. Reporting on facts does not mean I like those facts or that I wouldn’t like them change. Similarly, not testing something or reporting on something doesn’t mean I disapprove of them.
If I think something is crap, I’ll probably say so, and even if I say that support for some feature is good news, that doesn’t mean that I think using it is a good idea. The good news here is entirely in the context of comprehensive standards and features support, not in terms of what is practical or sensible to use in book design.
Anyway…
User features
In my mind, the best features of iBooks 3.0 have nothing to do with its format support or design features, but are all those small improvements and features designed to improve the user experience of the app.
Sharing and exporting
iBooks has always been more of a silo than most other ereader apps. The various bits and pieces of the Kindle platform have had twitter and some form of social sharing for ages, and even though most of them don’t offer any easy way of exporting your notes, they do aggregate them at the kindle.amazon.com website, which is better than nothing.
This update brings note sharing and exporting to iBooks, albeit only if you’ve upgrade to iOS6. It works as you’d expect. Twitter sharing is limited by twitter’s character limit. Email sharing works on both single notes and on a collection of notes in a feature that looks a bit like the email sharing feature of Bluefirereader. Sharing preserves some metadata context (title, author, etc) but not all, and it loses all formatting.
So, yeah, there’s lots of room for improvement. The ideal solution for sharing and working with ebook notes and highlights would be a combo of a full, open, API, like Readmill’s and a true archival export format.
Scrolling
iBooks now lets you choose a scrolling view of the ebook instead of a paginated one. This has been on my wish-list for a quite a while and is a feature that used to be an ereader mainstay.
It’s hardly the revolutionary feature some people are painting it as (so, so many other ereaders used to support this) but it is useful if you tend to write a lot of notes and make a lot of highlights, or if the books you read tend to have a lot of illustrations.
Switching between paginated and scrolling views seems fairly easy and reliable, so you don’t have to worry too much if you like to read fiction paginated and non-fiction scrolling.
However, the scrolling view tends to become jittery in long books on my iPad (third gen, iOS6) compounding iBooks’ overall slightly unresponsive feel.
iBooks Author
In tandem with the iBooks 3.0 release, we got an updated iBooks Author.
This isn’t what I’d call a major update. Some minor niggles have been addressed. Two spiffy new widgets were added. Some new nice-looking templates. MathML support. All good, to be sure.
Oh, and an almost automagical implementation of font embedding. Select some text, change its font, export the file, and the font will be embedded and obfuscated in the export file.
Of course, since font licensing rules for many foundries require extra licensing fees for ebook embedding, you need to take some care in choosing the font, but that’s a headache for another day.
The widgets aren’t game changers but are nice. One of them is a pop-over widget, which, as I have written about previously, is an interaction primitive. The other is a scrolling sidebar. Both are useful, but in a subtle way. Not demo widgets done for show.
Which is a good thing.
I still have mixed feelings about iBooks Author ebooks, given how they are only compatible with a single ereader app on a single class of devices (iPads), but if your choice is between making just an iOS book app or an iBooks Author ebook, most would be better served by the iBooks Author ebook. If not just for the cost savings.
Not that there is any alternative to speak of. The only ereader that has substantial and testable EPUB3 javascript support is iBooks and, as far as I know, the only ebook store that accepts interactive EPUB3s for sale is the iBookstore.
If you want to make an interactive ebook your only choices are apps, the web, or the iBookstore, as always.
If you really want to make a cross-platform interactive EPUB3, you pretty much have to roll your own ereader app platform to distribute it on.
(Readium is an option for that. Except that it’s almost entirely web-based, which, given the extensive feature set that Readium aims to support, means that you are almost certainly going to run into performance issues on most mobile phones and tablets.)
EPUB3
The testing process was very simple: load the EPUBs into iBooks and see if the features worked. Most of them didn’t.
EPUB3 FXL support
The EPUB3 FXL specification is supported as long as the rendition metadata applies to the entire book. Setting different rendition metadata on individual pages does not seem to work.
This means that mixed-mode fixed layout books aren’t possible in iBooks. The spec in theory allows for fixed layout ‘plates’ to be inserted in an otherwise reflowable ebook.
The problem, as I see it, is that it isn’t clear how this is supposed to work. In every print book that has inserts, the individual plates match the size and aspect ratio of the rest of the book, barring the occasional foldout. Now, even though ebooks are not bound by the limitations of print, it was my assumption, originally, that there would be a way of accomplishing something similar in FXL EPUB3s, a way for the fixed layout chapters to match the size of the rest of the ebook.
There isn’t. There’s no way to let the reading system know that you want this page to be fixed layout but that it should match the size of the rest of the book, whatever it is. This nicely scuttles the idea of using fixed layout pages as inserts in an otherwise reflowable ebook.
The ability in FXL EPUB3s to mix fixed layout pages with reflowable chapters seems a bit half-baked and badly thought out.
In fact, in my testing (not comprehensive, I’m sure) I couldn’t get anything to work that involved separate settings for just a single FXL page. I couldn’t set a single page to a different size and get it to render in a different aspect ratio, no matter what I set the rendition:spread or viewport properties to. Whatever rendition property I set on individual chapters on the itemref element seemed to be ignored.
Rendition:orientation does work and locks the ebook to whichever orientation you specify.
Setting the rendition:spread metadata property to ‘none’ turns off iBooks’ annoying skeuomorphism in fixed layout books, so that’s at least some good news.
All in all iBooks’ support for the EPUB3 FXL specification is still only partial. It’s enough for people to stop using Apple’s older proprietary fixed layout format, but it only represents a fraction of what the spec allows.
Other features
iBooks doesn’t seem to support bitmaps or SVGs in spine, either. They have to be embedded in HTML. Which is a pity as that would have made life easier for comics and manga publishers.
One concern I have is the differences in rendering that exist between the paginated and the scrolling views. For example, setting a full-bleed background colour works in scrolling view if you set it on the HTML element (which is actually how it should work in the paginated view according to my reading of the specs) but it doesn’t work in the paginated view; the colour is cropped at the margins. I’m worried that more differences will surface in further testing.
Absolute positioning now seems to work reliably in reflowable EPUB3s, which should be a boon for interactive ebooks.
Crap that’s a part of the EPUB3 spec for some unfathomable reason
The EPUB3 specification is full of crap and nonsense that was invented out of whole cloth without any public implementation whatsoever.
In any other standards organisation EPUB3 would not have been ratified until those features were either dropped or until there were several independent implementations in the wild.
(This is the reason why the W3C has published so few Recommendations and Candidate Recommendations and the reason why they frequently drop or spin out features from standards so as to not let a single recalcitrant feature hold back an entire standard.)
None of the following crap seems to be supported by any commercial EPUB reading system:
- Bindings
- oeb-page-head and oeb-page-foot
- epub:switch
- Media overlays in regular (not FXL) ebooks
It’d all be very useful, I’m sure, if they were ever implemented, which doesn’t seem likely at this point.
Basic epub:trigger does seem to work in iBooks (play and pause, show and hide, not mute and unmute). Yay.
MathML
The good news is that iBooks 3.0 supports MathML both in iBooks Author books and in EPUB3.
The bad news is that it is buggy as hell (like everything in iBooks, I guess, ::sigh::). Loading a sample maths textbook, full of MathML, takes ages and iBooks is fairly unresponsive while it’s loading. Once loaded, the book remains much less responsive than normal ebooks.
I’ve also heard several reports from reliable parties (like Nate over on The Digital Reader) that MathML isn’t working for all readers. My suspicion is that iBooks tries to render all of the equations in the background, runs out of memory, and bails. If I’m correct, you can’t rely on MathML working correctly on the iPad2 or the iPad Mini and it may even flake out on the iPad3 if it has got too much going on.
It looks like MathML is only safe to use in moderation.
The FXL theory
By now, a lot of you are familiar with what I believe to be the reason why ereader platform vendors refuse to implement the full range of EPUB3’s CSS features (or that of any other format for that matter):
A few weeks ago I got into a massive argument with several ereader app developers about CSS overrides. (And, yes, I was loud and obnoxious, as I’m wont to do in Twitter debates.) I maintained that their insistence on CSS overrides was the single biggest issue that ebook developers are facing. It increases costs, complicates development, makes testing next to impossible. It is a nightmare.
But, as it happens, one of the biggest issues ereader app developers are facing are ebook developers.
To be specific: a large proportion of the ebooks they get are so utter rubbish that to load ebook files without CSS overrides would have a dramatic negative effect on their business, support costs would skyrocket, returns spike, reputations would crater, etc..
In short: vendors can’t fully support open and non-proprietary ebook formats because a prolific minority of publishers can’t make ebooks that don’t suck.
However, fixed layout ebooks have access to a much wider range of CSS features than reflowable books, making them almost acceptable when it comes to CSS support.
My theory is that the prolific publishers of crap ebooks aren’t interested in fixed layout books because of their expense, complexity, and teeny-tiny revenue so platform vendors don’t have the same problems with FXL books as they do reflowable. No publishers of crap; no need for overrides.
If that theory is correct, we will never see support for fixed layout capabilities, media overlays, or the like added to regular EPUB3 files. Vendors like Apple and Kobo will keep the two segregated, leaving reflowable ebooks in a ghetto of our own creation.
Before you rah-rah optimists castigate me for being pessimistic, let me remind you that you cannot solve systemic problems without addressing the fundamentals that cause said problems. Not a single one of you optimists I’ve encountered so far (more than a few) has shown any sort of willingness to do so. Most of you don’t even acknowledge the idea that problems can have hidden root causes, let alone try and address those root issues. Any suggestion I’ve made that you need to look into the root causes before you charge on has fallen on deaf ears.
Until I see organisations and major publishers actively working to discover what issues cause vendors to implement CSS overrides or limit javascript APIs or whatever other insane limitation they’ve implemented lately, and try and work with them, in public, with full transparency, to mitigate those root issues, I see no reason to change my pessimistic assessment of future EPUB3 support.
Some people talk as if my pessimism is the reason why the situation is bad.
No.
I’m pessimistic because the situation is bad and the so-called optimists are wasting their time castigating me for insufficient boosterism instead of trying to discover the actual reasons why everything regarding ebooks sucks.
Anyway, this segregation would be a pity since a large portion of the publishing industry’s backlist consists of books that require the design capabilities only available to fixed layout books, but are nonetheless very text-heavy.
This segregation, the subpar design of the fixed layout formats available, combined with the desperation of publishers, is likely to lead to books that are astronomically expensive to make where hundreds of pages of text are laid out in a fixed layout format, as if HTML were some sort of mutant offspring of PDF.
This thought does not make me happy.