- 1 Requirements for a System to Render and Paginate Dynamic EBook Content
- 1.1 Introduction
- 1.2 Common Implementation Patterns
- 1.3 Implementation Requirements
- 1.3.1 Ability to turn pagination on and off
- 1.3.2 Ability to select page(s) for display
- 1.3.3 Ability to display multiple pages (2-up)
- 1.3.4 Determine the page(s) an element is on
- 1.3.5 Determine exactly where in text a page break happens
- 1.3.6 Map line-box content to source
- 1.3.7 Notification of font loading
- 1.3.8 Stable mechanism to convert between DOM and source
- 1.3.9 Ability to segment content
Requirements for a System to Render and Paginate Dynamic EBook Content
The display of ebook content has requirements beyond that of a traditional web browser. While browsers are designed to display dynamic web page content and most reflowable ebook content is built upon the same foundations (for example, HTML and CSS) as the web, the expectations of users can be quite different. Ebook content is typically paginated, and users of ebooks expect a different level of interaction with their books than they do with web pages. For instance, they may want to make highlights that persist across content loads and even over multiple devices. This document is intended to address the functionality a User Agent would need to provide to an ebook reading application built on web infrastructure, either as a web app or using a hybrid design (a native device application accessing a web component).
Since this document is targeted at reading applications built on top of web technologies, it will assume the underlying format for the content is HTML and CSS. While other formats exist for both reflowable and fixed layout content, addressing their needs is outside the scope these requirements.
Common Implementation Patterns
Ebook reading applications are not as rigorously defined as a browser User Agent. The most common web based format for such ebooks is the EPUB specification which relies heavily on both HTML and CSS specifications to define rendering and layout, and adds some additional levels of conformance for Reading Systems (defined in the epub spec, but essentially the thing an end user will use to read an epub-based ebook). However, it does not define exactly how such a Reading System should be written, nor does it cover the interaction between the Reading System and User Agent. This has left the actual implementation and interaction details up to developers which has led to a number of solutions. This section will briefly address some of the more common methods.
Web based reader
A hybrid reader is one where the actual reading application is written around an existing browser engine. There are several ways to accomplish this. For instance, this can be done by employing the system native embedded browser component (colloquially, a “webview”) or by separately porting and bundling an open source engine (for example, webkit or blink). In these cases, the browser engine may only be displaying the actual ebook content, with UI elements, annotations, downloads, user authentication, etc all happening in the native application. These applications may make use of extra APIs (for instance, for setting fonts) or even employ private/custom APIs to manipulate content.
Custom User Agents
It is also possible to implement an ebook reader from scratch, essentially implementing an entire User Agent targeted to ebook reading. This provides the ultimate level of integration, as ebook-specific features can be implemented at the core of the layout engine. This allows for better line breaking, actual page support, font replacement, etc without being limited by the APIs provided. This is also the most work, and a particularly daunting task that is becoming untenable due to the increasing complexity of browser engines.
This section will detail some specific requirements for the presentation and navigation of ebook content. While some of these requirements will also be useful to general web pages, they are called out here as being of particular interest to ebooks. No attempt is made to specify what these APIs should be, though in some cases existing interfaces may be mentioned..
Ability to turn pagination on and off
Ebook applications tend to support pagination, and it is a feature most ebook users expect from their reader. While some implementations may offer users a choice of paginated vs non-paginated modes (and some content may express a preference for one mode over the other), most reading systems will at least offer users the choice to paginate. Current mechanisms to paginate content range from use of CSS overflow to CSS multi-col, behind-the-scenes content scrolling to DOM alteration as well as CSS Regions on browsers that support it.
Ability to select page(s) for display
As a user reads a section of content, they will find the need to change pages or risk terminal boredom. This can be simple (“show the next/previous page”) to more complex (“Show heading 3 of chapter 6”).
Ability to display multiple pages (2-up)
Web page content is typically shown in a single, long scroll. Book content, however, is typically shown as two facing pages (in modern physical books). It is not uncommon for ebook reading systems to mimic the 2-up form of print, especially when the display is much wider than it is tall (for instance a tablet in landscape or a typical computer screen). Without a 2-up mode, text runs either become exceptionally long, or margins become excessively large. In addition to 2-up mode, where contiguous pages may be displayed side-by-side, reading systems may also want to have more than 2 pages in a row or column (for navigation purposes in a visual table of contents, or some type of thumbnail view), and it may want to display discontiguous pages from the same chapter without reloading all the chapter content. Some mechanism must be available to choose what pages are currently being displayed and where they should appear to fulfill this requirement.
Determine the page(s) an element is on
Given an arbitrary DOM node, reading systems must be able to determine what page or pages the node appears on. For instance, given an arbitrary highlight of text content, a reading system must be able to turn to the page that the highlight starts on. Since there is no guarantee of an element with an id existing at or near the location of the markup, there must be some mechanism to request that a particular location be displayed with at best access to a DOM node. Additionally, being able to determine the dynamically generated page number for such a selection may be required by a reading systems user interface (for instance, to display a page number next to every annotation or bookmark).
Determine exactly where in text a page break happens
Map line-box content to source
A mechanism for finding the source content in the DOM that is on a specific line may be used for setting highlights, breaking pages, handling window and orphans, etc. It is possible this would not be required in the cases that all other pagination use cases are fully addressed, but it is a common need for various implementations.
Notification of font loading
Font load events are already being worked on and implementations are appearing. Included here due to the importance of knowing when metrics will be accurate for pagination/display. Often the font resources are local, so deferring rendering and layout until they are loaded can reduce flashing and frequent changes to pagination results. Flashing is particularly problematic on device that do not support rapid refreshes (for example, eInk displays).
Stable mechanism to convert between DOM and source
In the world of dynamic web applications, being able to select a section of text and save that selection information (not just the text contents of the selection) for later use is rare. However, this is extremely common in ebooks. Often, these locations are synced across multiple devices and browser engines, and it can be difficult to remember their precise locations to restore them after dynamic pagination or on another device.
Ability to segment content
Due to memory limitations on some devices and a potential requirement to show pages from multiple chapters at the same time, the ability to segment content is important. That is, the ability to load only a portion the DOM for a given chapter, perhaps from certain previously calculated ranges.