Publishers are Missing the ePub3 Boat

eBookSupportEPub3 eBooks offer a cor­nu­copia of tech­no­log­i­cal promises, but a recent study shows that eReader device man­u­fac­tur­ers have been slow to embrace the pos­si­bil­i­ties. Granted, the sta­tis­tics are not weighted to empha­size one fea­ture over another. You may find sup­port for “fixed lay­out” to be more impor­tant than sup­port for “font embed­ding.” But the ePub3 eBook for­mat was launched in October of 2012; pub­lish­ers and device man­u­fac­tur­ers are miss­ing the ePub3 boat. This arti­cle sug­gests pos­si­ble rea­sons for the format’s lack of sup­port and sug­gests alternatives.

The Readium exten­sion for Chrome (Google’s web browser) sup­ports 72.5% of ePub3’s features—and it runs in a web browser, not in an eReader device. Popular ded­i­cated eReader hard­ware scored lower with Kobo sup­port­ing only 46% of ePub3’s fea­tures, the Kindle Fire sup­port­ing 32.3%, and Barnes and Noble’s Nook sup­port­ing only 16.7%.

Notable is that the eRead­ers offer­ing the best sup­port for ePub3 are those that lever­age the capa­bil­i­ties of a web browser. Over 50% of eBooks are con­sumed on devices other than ded­i­cated eReaders—and most of these devices already include on-board web browsers. I pro­posed in an ear­lier post that the browser may well become the pre­ferred eBook deliv­ery chan­nel. That was almost a year ago and only a few major pub­lish­ers have even shown up at the ePub3 dock.

Why Support ePub3 Now that Web Browsers Learned the Secret Handshake?

EReaders were devel­oped to offer what the web browser couldn’t—namely reflow­able, pag­i­nated text.

  • Reflowable text is text that can be “reflowed” to fill its dis­play area. In other words, less text will dis­play on a smaller screen and more on a larger screen. Changing font sizes or line heights will “push” text far­ther down the page.
  • Paginated text is bro­ken into dis­crete pages of information.

Web browsers have always offered reflow­able text, but instead of pag­i­nat­ing, HTML doc­u­ments in a browser present a scroll­bar once they got longer than the screen. Developers could guess where page breaks might occur and man­u­ally split con­tent into mul­ti­ple doc­u­ments, but the prob­lem of flow­ing dynamic text into dis­creet “pages” or screens gave rise to the devel­op­ment of ded­i­cated eReader devices.

Paginated text has existed in PDF files for a long time, but these doc­u­ments are not reflow­able. (It’s inter­est­ing, though, that “fixed lay­out” is touted as one of ePub3’s advan­tages. If not for the reflowa­bil­ity require­ment, PDF would likely have made an ideal eBook stan­dard. EBook’s were designed, in part, to break away from the lim­i­ta­tions of fixed layout.)

But recently, a lot of work has gone into advanc­ing the state of the web browser. Javascript frame­works like Monocle.js and Treesaver.js use stan­dard web tech­nolo­gies to ren­der reflow­able, pag­i­nated text in the web browser (gos­sip has been cir­cu­lat­ing that I’m at the advanced stages of devel­op­ing my own solu­tion but I don’t know who would start such a rumor). Certainly, Apple’s aban­don­ment of Flash tech­nol­ogy cat­alyzed mas­sive efforts within the devel­op­ment com­mu­nity to upgrade the web browser’s native capabilities.

A book by based on the Monocle.js eBook Framework

While eReader devices sat at the bar and drank to their own suc­cess, 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 devel­oped the ePub3 stan­dard to address the short­com­ings of eBooks. And they didn’t under­take this mas­sive project on their own. EPub3 was devel­oped with the input and involve­ment of major pub­lish­ing indus­try play­ers. Features like fixed lay­out, embed­ded media, embed­ded fonts, script­ing, and oth­ers were built into ePub3 at the request of pub­lish­ers and eBooksellers.

IDPF deliv­ered but there’s a lot of extra food on the buf­fet table. The hon­ored guests who both­ered to show up at all grabbed a few pigs-in-blankets and shuf­fled off. What’s the holdup? Why aren’t main­stream pub­lish­ers lever­ag­ing the new for­mat? Why are ePub2 books still standard?

The rea­sons can only be spec­u­lated on (dis­claimer), but I sus­pect a major fac­tor is the amount of work required to turn a man­u­script into a viable ePub3 eBook. ePub2 was sim­ple enough and basic enough so that pub­lish­ers could likely “auto-convert” huge cat­a­logs of books to elec­tronic form. The aes­thetic short­com­ings of eBooks made mediocre eBook for­mat­ting an accepted stan­dard. But once you intro­duce the capa­bil­ity for ele­gant typog­ra­phy (among many other fea­tures), eBook pro­duc­tion requires a designer’s touch. I sus­pect that big pub­lish­ers, after mak­ing a sig­nif­i­cant invest­ment in ePub2, found them­selves con­fronting the “Superman Dilemma”: With Great Power Comes Great Responsibility. Converting man­u­scripts to ePub2 is an alto­gether dif­fer­ent mat­ter than design­ing them to take advan­tage of the capa­bil­i­ties of ePub3. Multiply those costs and labor require­ments by the size of a big publisher’s cat­a­log and the prob­lem is daunt­ing. It’s not dif­fi­cult to imag­ine that pub­lish­ers returned to a “less is more” stance once the fog lifted.

It would be easy to blame eReader man­u­fac­tur­ers for the fail­ure to evolve. Perhaps pub­lish­ers are clam­or­ing for new fea­ture sup­port? But I doubt it. The con­spir­acy the­o­rist in me sus­pects that the rela­tion­ships between big pub­lish­ers and big book­sellers are too inter­twined; if big pub­lish­ers wanted ePub3 sup­port, Amazon and Barnes and Noble would have made it happen.

EBook Technology: Where’s the Beef?

The one place where ePub3 tech­nol­ogy is sup­ported best is, iron­i­cally, in the web browser. I haven’t peeked under the hood to see what in-browser ePub3 reader devel­op­ers have done, but it’s a safe bet they’re using the browser’s native capa­bil­i­ties to enable ele­gant typog­ra­phy, rich media, javascript sup­port, CSS3, and other ePub3 fea­tures. The cold, hard fact of the mat­ter is that with the prob­lem of pag­i­nated, reflow­able text solved, the hum­ble web browser has evolved to become a far more capa­ble eReader plat­form than the ded­i­cated eRead­ers that were devel­oped to replace its early shortcomings.

And with all that browser func­tion­al­ity still wait­ing to be imple­mented in ded­i­cated eReader devices, eReader devel­op­ers, them­selves, appear to have cho­sen the open web as their plat­form for innovation.

EBooks: Why bother With ePub3?

When the IDPF intro­duced ePub3, they described it as a “web­site in a book,” and they weren’t kid­ding. An ePub file—even an ePub2 file—is basi­cally a zipped up bun­dle of HTML, CSS, and Javascript files pack­aged up with some addi­tional data that tells an eReader how to dis­play a linked table of con­tents. Ebook con­tent in an ePub file is already for­mat­ted in a way that’s com­pat­i­ble with web browsers.

This begs the ques­tion: Why bother with ePub3? Ebooks and eReader devices are the domains of pro­pri­etary book­sellers. If you can dis­play and sell a con­sis­tently func­tional and aes­thet­i­cally beau­ti­ful eBook in a web browser with­out hav­ing to pay sales com­mis­sions, why not dis­pense with the imag­i­nary wall that sep­a­rates books from web­sites? Why not put up and sell access to your book the same way you would any other kind of web con­tent? Given that count­less solu­tions exist to make it easy and afford­able to sell dig­i­tal down­loads or lock “pre­mium” con­tent behind a pay­wall, why would a pub­lisher con­cerned with aes­thet­ics or func­tion­al­ity release an ePub3 file that is likely to work incon­sis­tently from one eReader to another?

EPub3 and the Role of the Bookseller

Answers to the above ques­tion are worth considering—or per­haps the ques­tion itself needs to be rethought? Has ePub3 become a solu­tion look­ing for a prob­lem? Maybe the impor­tant ques­tion has noth­ing to do with the ongo­ing rel­e­vancy of ePub3? If eBooks move to the web browser (and I see no com­pelling rea­son why they shouldn’t), what will be the ongo­ing role of the eBook­store? EBooks, as a medium, should serve the inter­ests of read­ers. That the eBook pub­lish­ing busi­ness is focused on licens­ing down­load­able files, and that the stan­dard upon which those files are based is weakly sup­ported sound like prob­lems the indus­try needs to address. Remember how the record­ing indus­try fought against dig­i­tal down­loads, fum­bled the golden foot­ball, and inad­ver­tently turned a com­puter com­pany (Apple) into the world’s largest music retailer? The onus to evolve or fade away is clearly on the shoul­ders of pub­lish­ers and booksellers—not on readers.

But whether or not you like the capa­bil­i­ties of a par­tic­u­lar bookseller’s eReader device, find­ing books and read­ing reviews in an eBook­store is gen­er­ally eas­ier than and prefer­able to find­ing the author’s web­site and access­ing a book there. As con­tent col­lec­tors and aggre­ga­tors of pub­lic opin­ion, book­stores offer a valu­able ser­vice to pub­lish­ers and readers.

Though I’m all for pub­lish­ers being empow­ered to sell inde­pen­dently, I can envi­sion a role for book­sellers who want to man­age access to and pay­ment for HTML eBooks. If book­sellers offered host­ing ser­vices, pro­vided tools for author pro­mo­tion, and man­aged pay­ment gate­ways, they could offer bet­ter eBooks and value-added ser­vices that would be worth pay­ing a sales com­mis­sion for. Quality host­ing and mer­chant ser­vices (credit card pro­cess­ing) are hardly expen­sive but they aren’t free either—and ele­gant imple­men­ta­tion requires the ser­vices of a web designer/developer (or at least some­one slightly tech-savvy). Major book­sellers deal­ing with quan­ti­ties of HTML eBooks could offer ser­vices to pub­lish­ers at an afford­able price—or even on a com­mis­sion basis. Booksellers will likely resist the idea of eBooks mov­ing to the open web but if they’re cre­ative, they should be able to lever­age their offer­ings and their rela­tion­ships with big pub­lish­ers and read­ers to remain valu­able 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 soft­ware opens, man­ages, and exe­cutes the inter­nal files in a way that’s invis­i­ble 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 soft­ware is hard enough with­out chal­leng­ing the uni­verse to build a bet­ter idiot. As far as the con­sumer is con­cerned, an ePub doc­u­ment is one file. That’s a benefit.

EBooks also con­tain metadata—information about the author, genre, copy­right, pub­li­ca­tion date, etc.—that eReader devices know how to extract and use. You can bun­dle this same data with a web-based book, but with­out some devel­op­ment work, web browsers won’t know how to sort your library by author or genre or release date.

EPub files don’t have secu­rity issues when dis­played from your local drive. Though some browsers are for­giv­ing of local files access­ing online scripts, oth­ers refuse to dis­play HTML books from your hard drive. Consistency between web browsers is less of a prob­lem than con­sis­tency between eRead­ers, but it’s still a barrier—and it might mean that if your reader doesn’t have Firefox, your web book won’t dis­play at all. Web-based eBooks are best suited to view­ing over a live Internet con­nec­tion. If you want to read on a plane or a cruise, your favorite web browser might not be up to the task.

Moreover, pag­i­na­tion is a tricky task. It works well enough in a web browser but zoom­ing in or out plays havoc with it, largely due to some browsers’ ten­den­cies to round the sizes of dis­played ele­ments to the near­est pixel. Web browsers are stuck in their own tra­di­tions; lay­er­ing inno­va­tion on top of the way they’re used to work­ing is not with­out caveats.

Choosing an eBook Publishing Path

If your book is all text, ePub3 may very well offer a prac­ti­cal solu­tion. “Pretty good” text for­mat­ting with css is sup­ported with rea­son­able con­sis­tency, and your book will dis­play leg­i­bly (if not ele­gantly) on older eReader devices. A few eRead­ers even sup­port embed­ded fonts.

But if your book con­tains rich media (maps, photo gal­leries, video, web fonts, inter­ac­tiv­ity, etc.), weak and incon­sis­tent eReader sup­port makes it dif­fi­cult to pre­dict how your book will appear to users of one plat­form ver­sus another. It makes more sense to lever­age the far less lim­ited capa­bil­i­ties of the web browser to achieve eBook designs that deliver the expe­ri­ences you intend them to.

The Ebook/ePub3 Boat: Who’s Navigating?

One thing seems clear: big pub­lish­ers are not lead­ing the charge when it comes to printed book design or eBook devel­op­ment; they have far too many books in their cat­a­logs to focus time and energy on mak­ing indi­vid­ual eBooks remark­able. Innovation will likely come from its tra­di­tional source—the small, inde­pen­dent artist who’s obsessed with doing some­thing bet­ter. The most enabling plat­form for this is the open web.

Being an early adopter or an inno­va­tor is always a risk. If your goal is to make books acces­si­ble to as many peo­ple as pos­si­ble and dis­trib­ute them through a proven sales chan­nel, keep your book sim­ple and upload an ePub2 file to a major book­seller. But if your strat­egy is to deliver works of ele­gance and func­tional bril­liance that work con­sis­tently with min­i­mal restric­tions, ePub3 is not suf­fi­ciently sup­ported to accom­plish that task. Like self-publishers who offer printed works, you’ll have to think out­side the book­store, but that’s where the fron­tier lies. Big pub­lish­ers may have missed the boat—but there’s noth­ing to stop you from build­ing your own.



Publishers are Missing the ePub3 Boat — 2 Comments

Leave a Reply