The group that created the ePub eBook standard now admits that the format really, really sucks and is totally inappropriate for formatting tomorrow's book, a fact that many of us have known for years. But we're not sure the folks who created the ePub standard in the first place are the best ones to figure out how to fix it -- and maybe the best solution is to let the marketplace come up with some solutions.
It was a startling admission from a working group of the International Digital Publishing Forum charged with establishing the parameters of ePub 2.1.
Now, on a very, very basic level ePub is a success: it's supported by every eBook vendor and content-creation system, albeit on a spotty level by Adobe in CS4. (We are so hoping for more in CS5.)
But it's a baseline standard. And when you start examining lowest-common-denominator standards, you can find a lot wrong with them. They're basic. They lack flash.
Anyone spending any time playing with the iPad knows the potential of the marriage of books and apps: we're drooling over the potential of coming out with some existing titles in an app format. But these enhanced books will be impossible to create with ePub, and we're not sure there's a workable solution. Here's the IDPF working group analysis of the 13 ways ePub sucks:
- Need for rich media and interactivity support. EPUB 2.0.1 has an extension mechanism, with provision for fallbacks, but does not intrinsically standardize support for rich media (such as video) and interactivity (programmatic content, such as would be needed to implement a quiz or crossword puzzle). These capabilities are necessary for interactive digital textbooks and digital magazines, and more generally to enable eBooks to evolve into a new medium, rather than simply be digital equivalents of paper books.
- Need for enhanced global language support. There is substantial interest in using EPUB in China, Japan, Korea , and other geographies, however it is recognized that at a minimum, requirements for support for the character sets, Ruby markup, and typographic rules needed for reading systems in these geographies (including but not limited to special line-breaking rules and vertical writing direction) are not adequately specified in EPUB 2.0.1.
Published Minimal Requirements on EPUB for Japanese Text Layout (English) - Need for enhanced article support. The fundamental atomic unit of magazines and newspapers is the article, an entity which is not specifically defined in EBUB 2.0.1.The magazine industry has adopted the PRISM standard for interchange and archival of digital content and it is desirable to support a workflow where PRISM content can be delivered as EPUB.
- Need for enhanced metadata support. EPUB 2.0.1 provides basic support for expressing embedded publication metadata. However, native support for standards such as ONIX and RDFa is not yet provided, which has a negative impact on the fidelity of metadata provision. Likewise, PRISM has article-level and inline metadata support that could integrate into EPUB.
- Need for a means to convey page-level layouts and target multiple display surface sizes in a single publication. EPUB 2.0.1 lacks any way to specify page-level layouts or dynamically select different layouts based on considerations such as available display area and user-preferred font size. This is a barrier to supporting books with more complex information designs, as well as digital magazines, and even for trade books makes it harder to convey a “house style” (addressing this requirement was requested by the AAP in conjunction with its endorsement of EPUB in May 2008).
- Need for enhanced navigation support. There is currently no ability to represent preferred instantiations of navigational elements; as well, presently any rendering of page-to-page navigation as well as Table of Contents and other navigation elements is optional and entirely Reading System-dependent. Version 2.0.1 makes “end user” presentation of the NCX TOC a “should” with statement that the next version will likely transform to a “must” and that other NCX sections may receive similar “upgraded” treatment.
- Incomplete alignment with broadly-adopted Web standards. EPUB 2.0.1 is built on numerous horizontal industry standards. However, these building-block standards, and the Web browsers that implement them, are rapidly evolving and the versions of these standards utilized in 2006 when EPUB 2.0 was formulated are no longer current. Since most distributed Reading Systems utilize Web browsers to present content to end users, and many standalone Reading Systems utilize Web browser rendering technologies in their implementations, it is desirable to improve alignment with Web standards as implemented by modern browsers.
- Lack of annotation support. There is presently no standard mechanism by which user-generated (aka “post publication”) information such as reading-position, bookmarks, and annotations may be stored and exchanged, which reduces interoperability across Reading Systems. It unclear if annotations should be a separate specification which could “overlay” the other EPUB specs. Note that annotations may wish to be stored and/or transported separately from publication content, and there exist at least two annotation specifications that can work with EPUB as well as other formats (DAISY and Adobe’s).
- No native support for mathematics. The lack of a native schema to represent mathematical equations (MathML) limits applicability and interoperability of eBook in the textbook and academic publishing segments.
- No native support for book-specific semantics. For academic publishing in particular, the absence of native support for book-specific structures such as glossaries, note reference systems and advanced cross-reference systems pose a limitation that negatively impacts the behavioral repertoire of reading systems.
- Insufficient accessibility support. EPUB is well-aligned with the DAISY standard but does not presently incorporate all DAISY features; in particular, there is not explicit support for full synchronization of multiple media types, such as audio and text. The proposed EPUB 2.1 revision will coincide in time with the revision of DAISY (ANSI/NISO Z39.86); the option to further the harmonization of the two standards should be considered.
- Insufficient mechanism for adding industry specific extensions. Vertical markets have defined schemas that communicate specific semantics important to their market segment, which presently cannot be handled in an interoperable manner within EPUB.
- No clear relationship to approved national and international standards. While EPUB has enjoyed broad adoption, the relationship to national and international standards has not been clearly articulated. In addition, no roadmap has been provided to address these questions in the industry.
Can't really argue with any of these. And really, #1 pretty much sums up the biggest problem facing eBook publishers. Logically, it's possible to add these features to a text file and then distribute as an app: it's then a matter of programming. And it costs more to program a solution than to merely lay it out in the likes of CS.
We'll be watching development of the ePub standard closely; most publishers are already invested in the standard and will wait to see what happens with it. But we're not so sure the smart business play isn't to look at next-gen solutions that merge programming and book production.
| Next > |
|---|
