Keep Your Eye on the epub Ball (But Do Play Nice)
On Peter Brantley's Reading 2.0 email list, former IDPF director Nick Bogaty offered a great argument for dialing down some of the pressure aimed at device makers for not yet fully supporting the .epub ebook standard. Nick has kindly given permission to have his comments reprinted here:
While companies like the one I work for have broadly implemented .epub support in its eBook products (in Adobe's case in InDesign CS3 for making .epub and Digital Editions for consuming it), I think it is too early to question vendor support for the .epub format. The final piece of the .epub specification (which is really composed of three specs) was only approved in September 2007 and it takes time for big companies to digest the implications of .epub on their businesses, integrate it into their products etc.
When we were making the .epub format when I was at the IDPF, we envisioned that eBook hardware and software would handle .epub in one of two ways. The first way is to simply render (in the case of eBooks that means "read") .epub files natively. Personally this is what I think makes most sense and it is what Adobe thinks makes most sense. You get an .epub file, open it in a piece of software or on an ebook reading device, and you're reading an .epub book. This scenario uses .epub as a consumer format.
The second way is for software or a device to take an .epub file and automatically convert it to a proprietary format. A publisher creates an .epub file, sends it to a vendor or through a channel that they want to sell, and that vendor or channel builds some sort of automatic conversion of the .epub to a proprietary format. There are many reasons for doing this, and all reasons generally have to do with companies thinking the .epub format doesn't meet the requirements of their hardware or software. This scenario uses .epub as a distribution format.
Either way, the advantage for publishers is very clear. Until now publishers had to convert to X numbers of formats if they wanted to take advantage of X numbers of channels. This significantly raised costs for publishers and forced publishers to make a strategic decision on what parts of their inventory they wanted to convert to an eBook in order to recoup their investment in conversion. And this had depressing consequences for consumers. Imagine going into a Barnes & Noble store with only 10,000 titles available.
What .epub really gives publishers is leverage. They can say to their vendors and channels, "ok, I'm now only giving you .epub and you better either provide software that reads .epub or provides an automatic conversion from .epub to Y format." This tremendously lowers costs and aggravation for publishers and, I strongly suspect, will increase inventory through the channels quite dramatically. The decision to create an eBook is just so much easier to make. And, if a hot eBook startup (or existing non-compliant eBook device/software) comes along to a publisher and says, "I've got this great device or software, give me your books in my format," a publisher can say, "you get .epub if you want my books." I strongly suspect that in the coming months, this above scenario of ".epub only" will start to happen more and more as publishers begin to produce .epub and understand its tremendous benefits to their digital businesses. And, publishers can use this leverage to get their software and ebook device partners to implement .epub a little faster.
While people don't seem quite in the mood these days to do so, I'd give Amazon (and others) the benefit of the doubt and a little time on .epub. The format is clearly in everyone's best interest.
[Links and emphasis added]
Nick's comments are reasoned and rational (not unexpected from someone who's spent time on both the standards side and the vendor side). And while publishers need to be realistic in their expectations for adoption of such a new standard (here at O'Reilly we're still working ourselves to efficiently retrofit content for .epub), publishers still need to keep the .epub goal in sight, and make sure that our actions continue progress toward that endpoint. As Nick suggests, saying "ok, I'm now only giving you .epub and you better either provide software that reads .epub or provides an automatic conversion from .epub to Y format" is the right way to go, for publishers and consumers.
- Stay Connected
-

TOC RSS Feeds
Blog Feed
News Feed
Combined Feed
New to RSS?
Subscribe to the TOC newsletter. 
Follow TOC on Twitter. 
Join the TOC Facebook group. 
Get the TOC Headline Widget.
- Search
-
- Conference
-
Tools of Change for Publishing Conference
Save the Date! TOC 2009 will take place Feb. 9-11 2009 at the Marriott Marquis in New York City. Sign up for the conference newsletter to hear about important dates and developments as the show approaches.
- TOC DVDs
-
TOC 2008 Tutorial DVDs
Now available. These tutorials dive into the necessary skills and tools critical to the future of publishing.
- TOC Job Board
- Publishing News
-
- Latest from O'Reilly Radar
-

April 10, 2008 8:49 PM
I'm a little surprised to see .epub offered as a publisher's source format rather than the end product of a workflow. .epub's source markup is just XHTML, and XHTML is still largely based on loose semantics that could apply to any type of electronic document. I imagine most publishers would want a source format with a richer, more book-like vocabulary -- TEI or DocBook come to mind -- and only convert to something like .epub for distribution to an ebook reader.
Going from .epub to Y format -- where Y format is semantically richer than XHTML -- would be difficult to do automatically.
April 22, 2008 3:21 PM
> What .epub really gives publishers is leverage.
> They can say to their vendors and channels,
> "ok, I'm now only giving you .epub and you
> better either provide software that reads .epub
> or provides an automatic conversion
> from .epub to Y format."
of course, they could do that with _any_ format...
-bowerbird
April 22, 2008 4:17 PM
@bowerbird: Sure, but the point is that it's a "good enough" and transparent standard that publishers can agree on. If we all just assume ePub, then we can get on with more important things. When launching a new website, there's no discussion of what "format" to use -- HTML/CSS/JavaScript are assumed. ePub could be the same for book-style content.
April 27, 2008 3:28 PM
i strongly disagree that epub is "good enough" right now
-- would you like me to go through all its shortcomings,
one by one, to demonstrate you are wrong about that? --
but even if i did agree that epub is "good enough", then
there are many other formats that are "good enough" too.
so if we would all "just assume" any one of them, we could
"get on with more important things"...
but premature optimization is not a good thing.
where are the free and open-source epub reader-programs?
where are the free and open-source epub authoring-tools?
we don't have many good solid ideas about what the _library_
of the future will look like, so how can we even decide what
variables we need to use to evaluate a format's effectiveness?
anyway, i'm sure the publishing industry will indeed settle
on some "standard", and i'm sure that it will be a format that
requires expensive authoring apps with steep learning curves,
so as to raise the cost of entry for all those new small upstart
publishing companies that want to take advantage of the new
level playing field, so i'd say that epub likely has a good shot.
but if you think the people out here doing research on formats
that can maximize the possibilities while minimizing the costs
are gonna _stop_ doing our work, just because "the industry"
has decided on _their_ "standard", i will say that you're wrong.
the dinosaurs passed a law. but the mammals ignored it...
-bowerbird
April 28, 2008 10:39 AM
@bowerbird: Sure epub has shortcomings, but so does HTML and so does DocBook XML (or PDF for that matter), formats we use extensively here at O'Reilly. If the content producers don't push for adoption of an open standard, then I fear that a device will establish a de facto one, which is bad for publishers and in my opinion bad for readers. I disagree that we're headed for expensive authoring tools -- but I also don't see ePub as an authoring environment anymore than HTML. I see ePub as a delivery format. As for open source options, our engineers have (in collaboration with engineers at Adobe) developed new stylesheets for the DocBook XSL package to allow for ePub output from DocBook source.
As for open source options, our engineers have been collaborating with Adobe on new stylesheets for the DocBook XSL project to allow for ePub output from DocBook source. The initial work on that is complete and will be in the next release of the stylesheets, but you're welcome to check out the code from Subversion today.
April 28, 2008 10:50 AM
bowerbird wrote:
> where are the free and open-source epub reader
> programs?
As you know, Adobe Digital Editions is free but not open-source. The FBReader project is the most widely-known open-source .epub reader.
> where are the free and open-source epub
> authoring-tools?
The wonderful part about the .epub standard is how trivial it is to make .epub files without any expensive authoring tools. The best introduction to that topic is Bob DuCharme's Creating epub files with nothing but free tools.
> a format that requires expensive authoring apps
> with steep learning curves, so as to raise the
> cost of entry for all those new small upstart
> publishing companies that want to take
> advantage of the new level playing field, so
> i'd say that epub likely has a good shot.
Just the opposite. Building an .epub delivery channel will be much easier for upstart publishers than any print channel.
April 28, 2008 3:28 PM
docbook? oh boy, that gives me a good chuckle... :+)
adobe's digital-editions would be a respectable effort
if it had come from some hacker working by himself...
but one of the biggest software companies in the world?
well, it's kind of embarrassing...
fb-reader is quite an achievement, but it still hasn't
implemented the css part of xhtml/css, which means
it's about half-way to where it needs to be...
yeah, it's "trivial" to make .epub files with "nothing but
free tools" just as long as you're a whiz with xhtml/css,
which is exactly why i say the learning curve is too high.
i think the non-technoids will see things the way i do...
and i don't think you technoids will be able to sway them,
no matter how much you and i "debate" the situation here.
-bowerbird