On eBook Reading Systems

Abstract

In this page I collect some notes about Reading Systems for eBooks, and their (current) lack of functions to properly support advanced usages of eBooks. The opinions contained in this page are personal. Feel free to disagree, to make them yours, even to exploit them in commercial products. In the latter case, I would like to be kept posted of your progress. Comments are welcome, especially if you point out mistakes or you have useful suggestions: just drop me an email or send me a tweet.

Important Update: on 2013-09-09, we published the project on GitHub: https://github.com/pettarin/epub3reader/, where you can find screenshots, a pre-compiled APK, and the source code.

Note: on 2013-05-08, I updated/clarified parts of this page, partially in response to comments and critiques I gathered. Original parts that I wanted to edit/delete have been striken out like this. A discussion takes place here.

Definitions

I wrote this page with the least possible technical language, so that it can be read by real-world people, not only software developers and ebook producers. (Kidding, of course.) To avoid misunderstandings, let me define the precise meaning I will give to some frequently occurring words:

My View on eBooks and Reading Systems

Let me start with a bold statement: reading eBooks, now, is a quite disappointing reading experience, with respect to their (abstract) potential.

Do not get me wrong: if you simply want to read novels or comics on your spare time, you might find decently formatted eBooks, and decent Reading Systems (RS) to enjoy them. (Even in this case, though, few RS allow the reader to apply really deep custom settings to the rendition of the eBook, and they almost all focus on typographical aspects, like changing font, its height, line density, margins, justification, and so on.)

But when you start using books for more complex activities, like studying, learning a foreign language, consulting professional manuals, and the like, current RS prove to be very poor tools. Have you ever experienced extremely different renditions of the same eBook, in two different RS? Have you ever tried taking annotations on an eBook and then expect them to be embedded into the eBook, while, at the same time, being able to use them outside the RS/ecosystem where you created them? Have you ever experienced the rather tiring, frustrating experience of using footnotes, dictionaries, translations, glossaries, on today RS? Have you tried referencing a text fragment of an eBook in another book (eBook or pBook)?

I think that the main reasons for all this mess are:

I do not have a magical recipe to improve the digital publishing ecosystem, especially in its financial dynamics: I leave this task to those who can pull the right triggers. But I can certainly contribute to the technical side of the discussion about eBooks and RS. The only prediction I have the gut to make is that the future belongs to open formats and tools, and that building walled gardens full of amazing proprietary tools will not pay off long term. Hence, in what follows, I will speak about open formats, RS and tools only.

Please, Give Us The Need for Intelligent RS

I think that one of worst pitfalls in the industry is that current RS are way dumber than they should be, given the level of sophistication that formats like EPUB3 allow. (As bowerbird noted, authoring tools are quite ineffective too. I agree with his view that even a 6 years old should be able to produce an eBook. This theme calls for another, deeper discussion.)

For example, no RS that I am aware of takes any advantage from the semantic vocabulary defined by EPUB3 (with the exception of footnotes in iBooks). But I do not want to enter the dangerous field of discussing a particular format. So, let's consider the generic theme of how links are handled in eBooks: how many RS allow the user to split the viewport to display the target (footnote, other chapter of the same text, an external Web page) concurrently with, say, the text fragment referencing it? (AFAIK, only ASTRI Bee can split the viewport, but it does not manage links automatically.) Along this line, the list of examples can be made arbitrarily long.

The effect is that actual eBook creators tend to spend insane amounts of time embedding in their eBooks code (CSS, Javascript) to make up for these missing functions. I say insane, because usually these attempts are not working well on all RS, and, more importantly, they are the digital publishing equivalent of the reinventing the wheel principle. Any programmer knows that she should avoid this as much as possible.

Besides support/standardization issues, I feel that eBooks are not fully recognized as different cognitive objects than the corresponding pBooks. For example, in principle, eBooks allow the reader to actively query the data contained in the eBook, unlike pBooks, where the reader was forced into a passive role regarding the book-to-brain transfer process, being unable to dynamically alter the content being displayed. Have you heard about any RS supporting XQuery lately? Of course, you do not.

To sum up, I think that making eBooks should be as simple as using any semantic-aware language, being sure that that eBook will be rendered uniformly by different RS and that special functions should be enabled by the RS, not requiring the eBook producer to code them from scratch every time! If someone wants to include her exotic JS stuff, that is fine with me, but, at least for common functions, there should be no need to code your own JS library and embed it into every single eBook. Finally, a good eBook should contain high-quality metadata and marked content, which are two necessary things to make complex usages possible.

Some Experiments with Android

So far, I just spew generic ideas (to borrow bowerbird's words), so let me go a little bit technically deeper on some coding experiments.

Currently, I am supervising a team of three students at my (former) Department of Information Engineering of the University of Padova, Padova, Italy. They are coding a demo Android app for reading EPUB2/EPUB3 eBooks, with focus on complex books.

The goal of this project is to show that, by putting some intelligence in the RS, the reading experience can be greatly enhanced. We focus on managing the following features:

A first focus of the project is about allowing the user to efficiently explore linked resources, by splitting the viewport to allow her simultaneous access to both linked and linking elements. For example, if you are reading full-screen an eBook and you click on a link, split the viewport in two panels, and render both the linking passage and the linked resource, which might be another part of the same eBook or an external Web page. Moreover, you can apply the same interaction to consulting a dictionary or a glossary.

A second focus of the project is about allowing a natural reading of parallel texts (for example, a book in its original language (say, EN) along with its translation in another language (say, IT)). It should not be that difficult to achive with eBooks, right? Wrong. So far, the only ways of doing it are:

Plus, the last two solutions require a lot of coding just to make the rendition work.

Our approach to the problem is different: first of all, the eBook should only contain the textual materials, marked up like any other EPUB book (so it is still compatible with other RS). But then, with the same split-the-viewport technique, we will offer the user the choice of whether she wants to read only the EN text, only the IT text, or both, simultaneously, in two half-screen panels. To keep things simple, we assume that the XHTML pages inside the EPUB container are named according to a naming convention that lets our app recognize the corrispondence between the original text and the translation (say, p001.en.xhtml and p001.it.xhtml), but also allows for shared, non-translated stuff (cover, introduction, etc.). The same mechanism might be achieved by other means (e.g., multi-OPF, etc.), but this is not the focus of the project.

(As bowerbird noted, a similar mechanism might be applied to TOC, search results, metadata, supplementary materials, etc.)

We will release this demo app by summer 2013, under a free software license. If the project will receive enough interest (and, possibly, funding) we will try to develop it further, including regular functions (typography management, bookshelf, etc.) and some other, more interesting features, including some of those listed below.

Extra Ideas

In what follows, I list, in no particular order, some ideas for functions that current RS lack, partially or entirely, and that I think I would like to see on RS.

Clearly this list is not exhaustive, feel free to email me your own suggestions.

Interesting Links

Few Comments on bowerbird's Notes

A few clarifications:

Now, a question: is ZML format (like this) the answer to all the questions raised so far? Or do you have "a bigger picture", hinged around it? I fear that overfocussing on formats is problematic too.