Flexibility helps keep us healthy. We can better enjoy physical activity which, in turn, motivates us to exercise. Keep on stretchin’!
Likewise, a flexible digital publication format is much better for the industry—and for readers—than a rigid, limited one.
To be more precise, a flexible format is more likely to be embraced, due to business pressures.
The IDPF’s new open standard e-book format, ePUB, is rapidly proving its flexibility. And ePUB’s flexibility is, of course, intentional by design.
A little history of ePUB’s predecessor as a consumer standard
Five years, two months and eight days ago, I published the reviewed eBookWeb article: “OEBPS: The Universal Consumer eBook Format?” My article delved into some of the requirements an e-book format must meet to be potentially embraced by the digital publishing industry as the consumer standard. From the requirements analysis, I concluded that IDPF’s OEBPS specification met these requirements and could become, when the time is ripe, the industry standard.
And indeed we are now seeing a groundswell of interest in ePUB by publishers and application developers. The primary reason is its flexibility in a number of areas, some of which are only now being recognized. I’ll delve into a couple of them in this article. [Note 1]
Flexibility #1: End-use
Obviously, a publisher is not going to spend money formatting its content into ePUB just for the heck of it. Pubishers do so only if the ePUB-formatted content will be useful in their business—that there will be a positive return on their investment. That’s Business 101. Of course, they prefer that ePUB be re-usable in the future, and not be just another “format of the moment.” Using the jargon of digital publishing professionals, they want their content to be “repurposeable”.
There is a misconception still floating around that ePUB is limited for use as an intermediary format. That is, ePUB is optimized only for format conversion by publishers and distributors/retailers.
In actuality, ePUB was designed from the ground-up to be optimal as both an intermediate format, and for direct rendering by consumers—full repurposeability. This explains the particular design of its XML-based framework, and the publication feature set it supports. [Note 2]
And, logically-speaking, one cannot really differentiate between the two. Even “direct rendering” requires internal conversion (in this case at the user-end) to present the content to the reader.
What we must not do is limit our thinking of ePUB conversion only to publishers and distributors/retailers (thus the end-user will never see or own an ePUB), but understand that ePUB allows end-users to also participate in conversion as their particular needs require, now and into the distant future.
For example, if I were a developer building an automated ePUB to “HappyBook” format converter so that the content could be viewed on “HappyBook” reading systems, then who mandates that only publishers or distributors/retailers can use my converter? The converter could also be incorporated into the “HappyBook” reading system to allow the consumer, who owns ePUB e-books, to natively read them on their “HappyBook.” Or, I could make my converter directly available to end-users, who will be able to manually convert their ePUB to the “HappyBook” format. [Note 3]
As reported here in TeleRead, a great demonstration of ePUB’s flexibility in empowering the end-user is bookworm, by Liza Daly at threepress. bookworm allows the user to read their ePUB e-books on their web browser. Simple, yet powerful.
And Opera, who I’m advising on ePUB (I plan to write more about this in the future), has made significant progress on a widget to natively render ePUB in their browser. (Hopefully native ePUB rendering will be included in their browser for mobile devices.)
Flexibility #2: Specialized applications (“verticals”) and accessibility
ePUB is not only designed as a general “trade” e-book format (which I define to be a format for simple, rigidly narrative/linear books like novels), but to also be used for other types of books and publications which have greater complexity and non-linearity. For example, ePUB supports graphics, including SVG, embedded fonts, and may include specialized markup such as MathML. Full hypertext support, plus the feature called auxiliary content, allows supporting more non-linear texts and documents. (I hope that future versions of ePUB will support fully non-linear content, such as web site structures—it could easily do so since ePUB is based on XHTML and CSS.)
With regards to accessibility, ePUB was designed from the ground-up to be accessible. Accessibility experts, such as George Kerscher, participated from the very beginning in 1999, and they have been a constant presence in the working group, making sure the rest of us understand their needs. Interestingly, the more accessible the format, the better the format is for the sighted (a topic I hope to write about in the future.)
For OPS 2.0 and OPF 2.0 (which underlie ePUB), the accessibility community played an even greater role, and as a result I am happy to report that OPS now supports DAISY’s Digital Talking Book document format (which has ties to NIMAS), and requires (because of my efforts) inclusion of the DAISY NCX (navigation control file) in all OPS 2.0 Publications (i.e., ePUB).
To make it clear that I don’t speak for IDPF and DAISY in any official capacity, I see it a distinct possibility that IDPF and DAISY will formally merge their efforts—it came pretty close to a de facto merger for authoring OPS 2.0 and in developing epubcheck. I hope this happens since, as noted above, the more accessible-friendly the format, the better the format is for everyone.
Publishers are now finally seeing the advantage to them of using high-quality, structural and semantic markup in their publications.
Jon Noring’s digital publishing bio
Note 1: The various versions of IDPF’s e-book specifications, published since 1999, and the name/acronym changes, can be a tad confusing to those who weren’t involved with IDPF standards development from the beginning. First, understand that ePUB is essentially an OPS 2.0 Publication wrapped inside a zip file per the OCF 1.0 spec. In turn, OPS is the successor of, and is very similar to, the OEBPS 1.x specifications. So ePUB is the natural successor to OEBPS, at least when it comes to the theme of my 2003 eBookWeb article just described.
Note 2: I’ve been contributing to the OEBPS/OPS specifications since 1999, participating in nearly all working group meetings, and holding various leadership positions in the Working Group. I’m not saying this to brag, but rather to say that I’ve been there the whole time and understand first-hand all the internal dynamics and politics. And I can unequivocally say the reason why, for a few years, OeBF/IDPF publicly described OEBPS as an "exchange format" was primarily political since there were OeBF members who did not want OEBPS to be promoted as a consumer format. So it was a compromise of sorts to keep OeBF together among competing business interests. However, in the working group we always held, as a kind of “Prime Directive”, that OEBPS may be used for both conversion to other formats and for direct rendering. In fact, logically-speaking, one cannot separate the two since conversion of some kind will take place somewhere in the chain between the publisher and the end-user.
Note 3: The term “HappyBook” has been used since the earliest days of the OEBPS working group to describe any OEBPS/OPS Reading System—sort of like how “Acme” was used in the Road Runner cartoons. I”m not sure who first coined the term, but it may have been Garth Conboy (co-founder of eBook Technologies) who was then with SoftBook, one of the original founders of OeBF (now called IDPF—got all that, folks?)