Book reader

There are many ways to read texts on a laptop; using the browser, using a document editor (abiword), or with a read activity (pdf/djvu) or browser (html/js/crossmark).

The IA and Open Library are currently working on an XO customization of the gnubook reader, including an evince plugin. For discussions of readers, book lists, and use cases, see the bookreader mailing list : bookreader@lists. For meeting minutes, see Book reader meetings.

Book reader features

This page serves as a forum for discussing the features required to make the device a useable eBook reader. Access to a diverse library of reading and reference materials will be a prime selling point of the olpc project. The devices are being cost-justified to interested nations based on the idea that money currently budgeted to purchase textbooks for students could be used to purchase a $100 laptop for each child and that the textbooks would be available in eBook format on the laptop itself.

Before diving into the discussion, designers have chosen to include Evince along with the basic HTML/XML capability of the browser. One would hope that this includes both DJVU and PDF capabilities of Evince, however DJVU probably provides the most value-add.

Features

Reader

The number one required feature for an ebook reader HAS to be the clearest, most easily readable text display possible on the hardware. Anti-aliasing or font-smoothing can be a great asset if implemented well or a horribly "smudgy" mess if implemented poorly...

In addition, there are two fundamentally different kinds of ebooks that must be supported. The first one is repurposed paper books. The DJVU compression format is designed specifically to make this feasible. The target countries for the OLPC do not have very much digital content available, however they have several generations worth of printed books that could be quickly repurposed. The second format is the computerised text that most people think of as E-Books, available in a bewildering array of proprietary and open text formats supported by dozens of ebook reader programs.

Useful features might include

• User definable "style sheets" to control font size and type face, etc.
• Display graphics in various formats; both vector and bitmap formats
• Display complex formulae
• Link in multimedia elements such as sound or video files (this is not an e-book. Ebooks should be limited to text and still images in order to get maximum use of electricity. People can still choose other apps to view multimedia content)
• Bookmarking, preferably sharable via network
• Annotations, preferably sharable via network
• Link to external programs for coursework such as worksheets, labs, etc. which can be forwarded BY the teacher to the students, and sent back to the teacher once the homework is done.
• Human readable, yet efficient markup language (should use an existing e-book markup language since many e-books will be available as well as tools. Existing e-book formats are often based on a simplified HTML markup)
• Compressed files (easily decompressed to access original files) (this needs to be carefully balanced against the built-in compression of the JFFS2 file system. Since JFFS2 can handle alternate compression formats it may be better to influence the JFFS2 development. Ideally, ebooks will be tightly compressed on modern desktops, and the OLPC will be able to quickly decompress them without using too much CPU/electricity)
• Simple, intuitive interface
• Localizable
• Supports complex-text language rendering (for example, Arabic and Thai)(bidirectional is where the real complexity is)
• A way to scroll, or "turn pages" of ebooks with the following properties: simple, natural, low-learning curve.
• Easily usable in book mode with the gamepad controller on the screen.
• Users should be able to encrypt and view documents. Special care should be taken to treat the contents in a highly sensitive manner to make wide-scale analysis of such documents infeasible.
• A text to speech option can help kids learn to read.
• A text to speech option might help kids that do not like to read a lesson but would not mind listening to it at a speed they could understand it. (Note that TTS voices must be produced for each language, and creating new voices is a huge amount of work (on the order of $10,000 production work per voice), so we need a low-tech short-term solition, like:)
• Voice recording and playback, to easily record your own voice reading the page in your own language, and create personalized spoken translations.
• Linking to a dictionary/glossary/thesaurus to define and gain understanding of words. Students unsure about a word can select it and tell the app define it and the definition of it could either pop up within the application or display it in a secondary program.
• Support for a book that comes in multiple formats - resolutions - mediatypes: understanding of the notion of ´switching between versions´ preserving location or bookmarks as best as possible.

Library

The laptop has the storage capacity for many hundreds of books, articles, stories, essays, etc., so cataloging, organizing and searching will be crucial.

Useful features might include:

• A standardized schema of metadata for categorizing work. The library.info information described in Creating a collection is a start
• Sorting on any of the fields in the schema, plus system generated data like last page read, etc.
• Full-text search capability across all titles - MUST be speedy so indexing will be necessary
• Highlighting the words that are searched.
• Network access to larger library to allow downloads of additional titles
• Synchronizing the page and selection between all readers in a shared activity.

An open source product, called Greenstone has a number of these features, and is already used to distribute collections of books to developing countries.

Formats

Several formats will need to be supported; Ebooks discusses this in more detail. Probably-useful formats include HTML, PDF, DJVU, and OpenDocument. Some people are working on a common wiki markup language called WikiCreole, and adding support for Crossmark would be a good idea (mstone has worked on parsing it in the past). A wiki engine using a superset of WikiCreole is being built by the OLPC team.

The Read Activity should support plug-in book format types, whose code is dynamically loaded on demand, but not loaded before it's required. Currently it is hard-wired to use evince, which supports several file types, but is not easily extensible. We need to define a higher level eBook rendering interface that is not specific to evince, but can also support other rendering modules. For example, the "poppler" module can efficiently rendering PDF directly into a Cairo context. Some work needs to be done to implement evince's paging, caching, scaling and scrolling features, but that can be easily written in Python with Cairo.

Other formats which would be useful to support : Word and abw, which are already supported elsewhere among core laptop activities. (note interest from MEXICO, AGS by Dagoflores)

Support for zipped file formats, such as those used in wikibrowse, to allow many more books to be kept in the library.

Lightweight footprint

Low memory usage for the program as a whole. Low memory usage for multiple instances running at once. Small footprint on disk for storing books - see ´support for zipped file formats´ above.

This is one of the standing problems with making the Browser a main bookreading platform.

Interface

First and foremost, the OLPC has a user interface that is not quite like most existing PC operating systems. The Ebook interface should fit into that context. Look here for interface examples.

The XO's screen can be flipped around and folded into "book mode", hiding the keyboard and trackpad, and exposing the two game pad controllers on the screen. Since this is the most natural way to read books, it's important that the eBook reader be easy to use and fully functional in "book mode", with the gamepad controllers.

There are two different game pad controllers on the screen that you can use in book mode: on the left is a directional joystick with four directional sensors that can be pressed horizontally, vertically, or diagonally. On the right is a set of four buttons in a diamond, currently labeled "X" (down), "O" (right), "Triangle" (up) and "Square" (left). (The labels on those buttons (familiar to Playstation owners) may change in the final release, but not their diamond layout and position.)

The directional controller on the left should be used for directionally oriented tasks like paging, panning, zooming, navigating toolbars and pie menus, etc. The four button controller on the right should be used selecting commands, entering and escaping modes, controlling widgets, following links, and invoking important functions.

The buttons available in "book mode" also include a "rotate" button that rotates the screen, by using the X11 RandR extension. The activity's window gets rotated and resized so its aspect ratio is different, and the user interface has to adapt to the different width and height of the screen as it's rotated. This may require re-mapping the directional arrows, because the display is rotated differently with respect to the directional gamepad orientation. (But I wouldn't recommend mapping the labeled gamepad buttons on the right, because they're symbolically labled, and not as directionally oriented as the unlabled joystick gamepad on the left!)

There are also some hardware switches that detect what mode the screen is in, but I don't think they're hooked up yet in the current B2 system. Since the activity will be able to detect if the screen is in book mode or laptop mode, the user interface should adapt to the screen configuration accordingly. How should the Read activity behave differently in book mode? Disable commands that require the keyboard, etc. Better than disabling important commands like search, it should provide a virtual keyboard for searching in book mode. When it's in book mode, it would know to pop the virtual keyboard up automatically when you navigated to the search field.

Post eBook interface ideas here.

• Should the eBook interface look like Adobe Reader[1]? (The UI can be completely hidden, the page can be rotated to be read like an open book, and pages can be turned with the right-arrow key, conveniently located on the bottom corner of the keyboard near where your left thumb would hold it.)
• Should it look like Evince? (Most UI stuff can be hidden)
• Should it have a status bar? (If so the it's not an ebook reader. All UI elements, including status bars, should be hideable).

Jog Reading Wheel

A few years for a ridiculous sum of money, considering the fact that the units are no longer supported or sold, I bought a stony clie' PDA T625 C ( I still have it on my desk if someone wants to make me an offer:) Anyway one of the most salable features and indeed usable things about this PDA is the thumb wheel on the side of the case. It allows me to read PDF or whatever documents and scroll up or down the pages of the document using this little plastic wheel, if you push the wheel in you can also reset to the start of the document. Don't take my word for it here is what many other people say about this neat feature;

http://www.the-gadgeteer.com/review/sony_clie_peg_n760c_review "On the left side of the Clie are the jog-wheel, back button and hold. The jog-wheel? "What a dumb idea," I thought when I started using the unit. "What is the point when you can just touch the screen to select objects and items?"

Well In less than a week I found this little addition to be an absolutely wonderful feature. I can fly though addresses or to-do's with a flick of my thumb while driving, on the phone, etc."

The Sharp Zaurus models that look like little laptops also had this feature.

Maybe we should bring back the old OLPC generator crank, but as an jog-dial-like input device for paging and scrolling, instead of producing electricity!

Down Arrow: I do the same thing reading e-books on my laptop web browser by holding down the down-arrow key.

PGUP/PGDN Buttons: The Gemstar/Rocket/RCA/eBookwise Ebooks (Picture Here) has PGUP/PGDN buttons near the grip (which was also very nice and was designed to be held like the spine of a book). I've been using one of these for two years, but I'm very interested in upgrading to something more flexible. I think that the design of the unit was very well thought out and should be experienced by anyone designing hardware that is meant to be suited for reading ebooks.

Blackberry-style Controls

The Blackberry has one thing that is really right in that both the enter/fwd key and the esc/bck key are easily available. The OLPC/Sugar interface should have use the 4-way pad an Enter and an Esc. This way, you can follow links in your PDF and HTML ebooks. If a user can't jump back to the place where they were reading easily, they will not be as willing to look up terms in the glossary (for example). eBooks will be made assuming that the user can jump back -- authors should not have to re-format their works for the OLPC.

The 4-way pad is already in the hardware specification as is the enter/fwd; an esc/bck should be added now. It will come in handy for many applications.

Reading experience

All readers should support setting zoom and flow, paging and scrolling, text selection, linking, basic search.

Long pages

We want to be able to parse long pages and render subsets of them without waiting to render everything. Gecko is pretty good at this; Evince isn't quite perfect at guessing how to focus on rendering only the page being looked at. Some subsets of reading/display/commentary we want to handle:

• Display collections of images and text quickly, before the whole page has loaded

Other

• Nuanced use of keystrokes in handheld mode to allow a few dozen interpretations
• Offer interactive options to the reader when loading plaintext, long, or complex documents
• Early rendering of images or media before the entire thing has loaded

Interface specification

This can be done somewhat independently of implementation.

• /usr/share/activities : the webview toolbar and embedded browser could use some updates to reflect interface ideas
• mechanisms for moving about the page, chaning font type and size, and loading or turning off images and other media, need general hooks