The World's Greatest Book
EPub3 eBooks offer a cornucopia of technological promises, but a recent study shows that eReader device manufacturers have been slow to embrace the possibilities. Granted, the statistics are not weighted to emphasize one feature over another. You may find support for “fixed layout” to be more important than support for “font embedding.” But the ePub3 eBook format was launched in October of 2012; publishers and device manufacturers are missing the ePub3 boat. This article suggests possible reasons for the format’s lack of support and suggests alternatives.
The Readium extension for Chrome (Google’s web browser) supports 72.5% of ePub3’s features—and it runs in a web browser, not in an eReader device. Popular dedicated eReader hardware scored lower with Kobo supporting only 46% of ePub3’s features, the Kindle Fire supporting 32.3%, and Barnes and Noble’s Nook supporting only 16.7%.
Notable is that the eReaders offering the best support for ePub3 are those that leverage the capabilities of a web browser. Over 50% of eBooks are consumed on devices other than dedicated eReaders—and most of these devices already include on-board web browsers. I proposed in an earlier post that the browser may well become the preferred eBook delivery channel. That was almost a year ago and only a few major publishers have even shown up at the ePub3 dock.
Why Support ePub3 Now that Web Browsers Learned the Secret Handshake?
EReaders were developed to offer what the web browser couldn’t—namely reflowable, paginated text.
Reflowable text is text that can be “reflowed” to fill its display area. In other words, less text will display on a smaller screen and more on a larger screen. Changing font sizes or line heights will “push” text farther down the page.
Paginated text is broken into discreet pages of information.
Web browsers have always offered reflowable text, but instead of paginating, HTML documents in a browser present a scrollbar once they got longer than the screen. Developers could guess where page breaks might occur and manually split content into multiple documents, but the problem of flowing dynamic text into discreet “pages” or screens gave rise to the development of dedicated eReader devices.
Paginated text has existed in PDF files for a long time, but these documents are not reflowable. (It’s interesting, though, that “fixed layout” is touted as one of ePub3’s advantages. If not for the reflowability requirement, PDF would likely have made an ideal eBook standard. EBook’s were designed, in part, to break away from the limitations of fixed layout.)
But recently, a lot of work has gone into advancing the state of the web browser. Javascript frameworks like Monocle.js and Treesaver.js use standard web technologies to render reflowable, paginated text in the web browser (gossip has been circulating that I’m at the advanced stages of developing my own solution but I don’t know who would start such a rumor). Certainly, Apple’s abandonment of Flash technology catalyzed massive efforts within the development community to upgrade the web browser’s native capabilities.
A book by Booki.sh based on the Monocle.js eBook Framework
While eReader devices sat at the bar and drank to their own success, the web browser stayed on the dance floor and learned to boogie.
EBooks: Be Careful What You Ask For
The good folks over at the IDPF developed the ePub3 standard to address the shortcomings of eBooks. And they didn’t undertake this massive project on their own. EPub3 was developed with the input and involvement of major publishing industry players. Features like fixed layout, embedded media, embedded fonts, scripting, and others were built into ePub3 at the request of publishers and eBooksellers.
IDPF delivered but there’s a lot of extra food on the buffet table. The honored guests who bothered to show up at all grabbed a few pigs-in-blankets and shuffled off. What’s the holdup? Why aren’t mainstream publishers leveraging the new format? Why are ePub2 books still standard?
The reasons can only be speculated on (disclaimer), but I suspect a major factor is the amount of work required to turn a manuscript into a viable ePub3 eBook. ePub2 was simple enough and basic enough so that publishers could likely “auto-convert” huge catalogs of books to electronic form. The aesthetic shortcomings of eBooks made mediocre eBook formatting an accepted standard. But once you introduce the capability for elegant typography (among many other features), eBook production requires a designer’s touch. I suspect that big publishers, after making a significant investment in ePub2, found themselves confronting the “Superman Dilemma”: With Great Power Comes Great Responsibility. Converting manuscripts to ePub2 is an altogether different matter than designing them to take advantage of the capabilities of ePub3. Multiply those costs and labor requirements by the size of a big publisher’s catalog and the problem is daunting. It’s not difficult to imagine that publishers returned to a “less is more” stance once the fog lifted.
It would be easy to blame eReader manufacturers for the failure to evolve. Perhaps publishers are clamoring for new feature support? But I doubt it. The conspiracy theorist in me suspects that the relationships between big publishers and big booksellers are too intertwined; if big publishers wanted ePub3 support, Amazon and Barnes and Noble would have made it happen.
EBook Technology: Where’s the Beef?
The one place where ePub3 technology is supported best is, ironically, in the web browser. I haven’t peeked under the hood to see what in-browser ePub3 reader developers have done, but it’s a safe bet they’re using the browser’s native capabilities to enable elegant typography, rich media, javascript support, CSS3, and other ePub3 features. The cold, hard fact of the matter is that with the problem of paginated, reflowable text solved, the humble web browser has evolved to become a far more capable eReader platform than the dedicated eReaders that were developed to replace its early shortcomings.
EBooks: Why bother With ePub3?
When the IDPF introduced ePub3, they described it as a “website in a book,” and they weren’t kidding. An ePub file—even an ePub2 file—is basically a zipped up bundle of HTML, CSS, and Javascript files packaged up with some additional data that tells an eReader how to display a linked table of contents. Ebook content in an ePub file is already formatted in a way that’s compatible with web browsers.
This begs the question: Why bother with ePub3? Ebooks and eReader devices are the domains of proprietary booksellers. If you can display and sell a consistently functional and aesthetically beautiful eBook in a web browser without having to pay sales commissions, why not dispense with the imaginary wall that separates books from websites? Why not put up www.TitleOfYourBook.com and sell access to your book the same way you would any other kind of web content? Given that countless solutions exist to make it easy and affordable to sell digital downloads or lock “premium” content behind a paywall, why would a publisher concerned with aesthetics or functionality release an ePub3 file that is likely to work inconsistently from one eReader to another?
EPub3 and the Role of the Bookseller
Answers to the above question are worth considering—or perhaps the question itself needs to be rethought? Has ePub3 become a solution looking for a problem? Maybe the important question has nothing to do with the ongoing relevancy of ePub3? If eBooks move to the web browser (and I see no compelling reason why they shouldn’t), what will be the ongoing role of the eBookstore? EBooks, as a medium, should serve the interests of readers. That the eBook publishing business is focused on licensing downloadable files, and that the standard upon which those files are based is weakly supported sound like problems the industry needs to address. Remember how the recording industry fought against digital downloads, fumbled the golden football, and inadvertently turned a computer company (Apple) into the world’s largest music retailer? The onus to evolve or fade away is clearly on the shoulders of publishers and booksellers—not on readers.
But whether or not you like the capabilities of a particular bookseller’s eReader device, finding books and reading reviews in an eBookstore is generally easier than and preferable to finding the author’s website and accessing a book there. As content collectors and aggregators of public opinion, bookstores offer a valuable service to publishers and readers.
Though I’m all for publishers being empowered to sell independently, I can envision a role for booksellers who want to manage access to and payment for HTML eBooks. If booksellers offered hosting services, provided tools for author promotion, and managed payment gateways, they could offer better eBooks and value-added services that would be worth paying a sales commission for. Quality hosting and merchant services (credit card processing) are hardly expensive but they aren’t free either—and elegant implementation requires the services of a web designer/developer (or at least someone slightly tech-savvy). Major booksellers dealing with quantities of HTML eBooks could offer services to publishers at an affordable price—or even on a commission basis. Booksellers will likely resist the idea of eBooks moving to the open web but if they’re creative, they should be able to leverage their offerings and their relationships with big publishers and readers to remain valuable and relevant.
EBooks in the Web Browser: Benefits and Liabilities
Browser books are not a panacea; ePub files do offer a few advantages:
EPub files are self-contained; the eReader software opens, manages, and executes the internal files in a way that’s invisible to the user. With web books, the user has to know to click index.html or how to load a file into a browser. It ain’t exactly rocket surgery, but idiot-proofing software is hard enough without challenging the universe to build a better idiot. As far as the consumer is concerned, an ePub document is one file. That’s a benefit.
EBooks also contain metadata—information about the author, genre, copyright, publication date, etc.—that eReader devices know how to extract and use. You can bundle this same data with a web-based book, but without some development work, web browsers won’t know how to sort your library by author or genre or release date.
EPub files don’t have security issues when displayed from your local drive. Though some browsers are forgiving of local files accessing online scripts, others refuse to display HTML books from your hard drive. Consistency between web browsers is less of a problem than consistency between eReaders, but it’s still a barrier—and it might mean that if your reader doesn’t have Firefox, your web book won’t display at all. Web-based eBooks are best suited to viewing over a live Internet connection. If you want to read on a plane or a cruise, your favorite web browser might not be up to the task.
Moreover, pagination is a tricky task. It works well enough in a web browser but zooming in or out plays havoc with it, largely due to some browsers’ tendencies to round the sizes of displayed elements to the nearest pixel. Web browsers are stuck in their own traditions; layering innovation on top of the way they’re used to working is not without caveats.
Choosing an eBook Publishing Path
If your book is all text, ePub3 may very well offer a practical solution. “Pretty good” text formatting with css is supported with reasonable consistency, and your book will display legibly (if not elegantly) on older eReader devices. A few eReaders even support embedded fonts.
But if your book contains rich media (maps, photo galleries, video, web fonts, interactivity, etc.), weak and inconsistent eReader support makes it difficult to predict how your book will appear to users of one platform versus another. It makes more sense to leverage the far less limited capabilities of the web browser to achieve eBook designs that deliver the experiences you intend them to.
The Ebook/ePub3 Boat: Who’s Navigating?
One thing seems clear: big publishers are not leading the charge when it comes to printed book design or eBook development; they have far too many books in their catalogs to focus time and energy on making individual eBooks remarkable. Innovation will likely come from its traditional source—the small, independent artist who’s obsessed with doing something better. The most enabling platform for this is the open web.
Being an early adopter or an innovator is always a risk. If your goal is to make books accessible to as many people as possible and distribute them through a proven sales channel, keep your book simple and upload an ePub2 file to a major bookseller. But if your strategy is to deliver works of elegance and functional brilliance that work consistently with minimal restrictions, ePub3 is not sufficiently supported to accomplish that task. Like self-publishers who offer printed works, you’ll have to think outside the bookstore, but that’s where the frontier lies. Big publishers may have missed the boat—but there’s nothing to stop you from building your own.
Publishers are Missing the ePub3 Boat