iBooks Author vs. ePub Author
So, yesterday Apple launched the new iBooks Author application for the Mac. It looks great, produces fantastic dynamic content, and more than one person assumed that it was outputting ePub3 files. However, that was not the case, as is extensively documented by Daniel Glazman (co-chairman of the WC3 CSS working group) on his blog:
A wysiwyg EPUB3 editor will not be able to edit correctly an IBA document because of the different mimetype and the proprietary CSS extensions. iBooks Author is not able to reopen a iBook it exported in their pseudo-EPUB3 format because there is no Import mechanism! That means that on one hand EPUB3 readers cannot reuse a document created by iBooks Author because of its HTML/CSS/Namespaces extensions, and on the other iBooks Author cannot create an iBook from an existing EPUB3 document because it cannot import it.
In actuality, it even goes a little further than this.
HTML5? Or XHTML+XML?
Here’s the top section from an IBA I exported yesterday, reformatted for width:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<?xml-stylesheet href='assets/css/content2.css'
type='text/css'
media='all'?>
<?xml-stylesheet href='assets/css/content2-paginated.css'
type='text/css'
media='paginated and (orientation:landscape)'?>
<?xml-stylesheet href='assets/css/content2-nonpaginated.css'
type='text/css'
media='nonpaginated and (orientation:portrait)'?>
<html xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ibooks="http://www.apple.com/2011/iBooks"
xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en">
<head>
<meta http-equiv="Content-Type"
content="application/xhtml+xml; charset=utf-8"/>
<title>Untitled</title>
<link rel="stylesheet"
type="text/xml+svg"
href="assets/svg/content2.svg"/>
<link rel="alternate"
type="application/x-ibooks+linehints"
href="assets/hints/content2-landscape.plist"
media="paginated and (orientation:landscape)"/>
</head>
Note that the CSS stylesheets are declared using an <?xml-stylesheet ... ?> tag instead of a <link .../> tag in the HTML header. Also, the content-type <meta> tag defines the document as xhtml+xml, where the DOCTYPE clearly defines it as pure HTML5. Interestingly, the only HTML stylesheet link tag actually points to an (empty in my case) SVG file. Wait, what? Is that even legal? No, really, I don’t know— is it legal?
Everything’s Objective
Here’s how it specifies some of its text layout:
<object type="application/x-ibooks+shape" id="textShape-11">
<svg xmlns="http://www.w3.org/2000/svg" id="textShape-11-svg"
viewBox="0 0 666.788 277.788" preserveAspectRatio="none">
<title/>
<desc> </desc>
<rect class="s6" x="0" y="0" width="666.788" height="277.788"
rx="4.760" ry="4.760"/>
</svg>
<div class="s7" id="textShape-11-div">
<a id="textShape-11-hint" class="shape"/>
<p id="textShape-11-p0" class="s8">Lorem Ipsum</p>
<ol class="s9">
<li id="textShape-11-p1" class="s10">
<span class="c1">Lorem ipsum dolor sit amet</span>
</li>
<li id="textShape-11-p2" class="s10">
<span class="c1">Consectetur adipisicing elit,
sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua.
</span>
</li>
<li id="textShape-11-p3" class="s10">
<span class="c1">Ut enim ad minim veniam, quis
exercitation ullamco laboris nisi ut aliquip ex
commodo consequat.
</span>
</li>
<li id="textShape-11-p4" class="s10">
<span class="c1">Duis aute irure dolor in in voluptate
velit esse cillum dolore eu fugiat nulla pariatur.
</span>
</li>
</ol>
</div>
</object>
What’s that at the root there? Why yes, it’s an <object> tag. I may be missing something here, but ePub3 defines the epub:type attribute, and it’s entirely possible for them to render this using <div epub:type="x-ibooks+shape" id="textShape-11">, which is more browser-friendly than an <object> tag, which I believe a browser can choose to ignore if it doesn’t recognize the specified object tag. Yes, the browser, not the ePub Reader platform built on top of that browser.
Keynote
Where this goes further is when you look at the embedding of a Keynote file. First we see this:
<object type="application/x-ibooks+anchored"
data-anchor-ref="danchor-keynote-0">
<object type="application/x-ibooks+anchorednormal">
<object id="keynote-0" class="s13"
type="application/x-ibooks+widget"
title="Interactive 1.1 Blocks and Grand Central Dispatch"
data-widget-type="keynote"
data-geometry="affineGeometry(440,408,1,0,0,1,50,170)"
data-fullscreen-only="no"
data-content-layout="top-bottom"
data-background-enabled="yes"
data-corner-radius="3.000"
data-content-padding="10.000"
data-stage-geometry="affineGeometry(412,309,1,0,0,1,14,41)"
data-bundle-path="assets/widgets/assets.kpf"
data-show-transport-controls="no"
data-enable-user-interaction="no">
Within this chunk there’s a another set of <object> tags similar to those above, this time wrapping the header & footer for the container element, and an <img> tag for the image to show if the above object isn’t displayable.
The interesting part is the data-bundle-path up there. This points to a folder within the IBA container, which has the following structure:
assets.kpf/
480x268/
fallback/
images-1/
images-2/
kpf.json
player/
AnimationManager.js
[lots of .png files, a couple of .gifs for spinners]
[lots of .js files]
FilterDebugCode.bash
FilterDebugCode.sed
KeynoteDHTMLPlayer.css
KeynoteDHTMLPlayer.js
KeynoteDHTMLPlayer.html
So, nothing in there which looks too hairy for a browser, right? What happens if I unzip the container and open that html file I wonder?
That’s right– it works. Even all the animations. Perfectly. And it live-resizes perfectly, too.
So, in other words, they could have linked the ‘fallback’ image to this KeynoteDHTMLPlayer.html file to keep it at least broadly compatible with other readers. They could have followed the ePub3 spec and specified the content in such a way that inline-display-capable readers could render it inline, while others could just go to that page. As it stands, the source .xhtml file won’t render properly in Safari, and even then offers no way to access the Keynote file. That inaccessible file, though, is the only part of the document that works perfectly in Safari with no changes.
In fact, they could have specified the DHTML handler page for a custom mime-type using the bindings element of OPF3. The exported .ibooks archive appears setup to do all of this, with the exception of actually including this last crucial step.
Sigh…
So I’ve yet to see anything in here which couldn’t be output nicely using ePub3. Sure, there are CSS namespaces, that’s fine— CSS defines the @namespace keyword for a reason, after all. There’s SVG in there too, which is also fine. The placement of key layout attributes as proprietary attributes within <object> tags, though, is inexcusable when the ePub3 standard defines great things like the epub:switch element which would enable fallbacks for other readers to display the same content, and the epub:type attribute to specify content types for given tags. The latter could be used to denote things like 3D imagery, infer the encoding or purpose of a video/audio tag, and more– it’s extensible by the content author, and is an appropriate data point for reading systems to use when determining how or whether to render particular types.
So, in summary, it appears that {there is relatively little that iBooks Author can output which can’t be output as nicely standards-compliant ePub3. A few things to do with special gutter layouts and so on (which are still only proposed future CSS3 modules) but overall the general content being included could be output just fine.
The next question is, of course: who’s going to make an equivalent ‘ePub Author’ application?
ePub Author
I think there’s enough know-how in the industry outside of Apple to make a competitor to iBooks Author, by which desktop publishing in the eBook age can be as limitless in possibility as we can make it, yet not be restricted to a single target platform. I want to hear from experienced OS X software engineers who are interested in tackling such a project on a commercial (or possibly open-source, or both) scale, and from people companies who can contribute expertise or code to the effort.
You know who you are.