A dynamic book reading system for computers


Since the invention of the printing press we have seen little progress in the reading habits of humans. A physical book once published on paper or imitated on a computer, would not allow for its content to interact with the reader. No book, for example, would let the reader to turn any of its tables into an interactive chart despite the fact that it is quite difficult for humans to interpret large bodies of numbers. This immutable nature of paper curbs mental development of humans, but the situation is being changed by the arrival of computers. Humans(and other animals) learn by interacting with their environment and an environment rich in live elements would definitely boost the intellectual abilities of its reader. A computer is a medium that provides necessary tools needed to build a dynamic environment for any situation and there is an urgent need for lush, rich, and dynamic learning environments.
readaratus is a tiny proof of concept and computerized experiment to introduce some dynamism into the realm of books. Ultimately, readaratus aims to be a "self-decoding", "dynamic", and "machine-friendly" protocol for learning.
The following list demonstrates the current features of readaratus:

In future versions we intend to introduce the following features(mainly for PDF documents):

Our misson is to remind people that computers could be used in better ways.

Preemptive Frequently Asked Questions

What formats do you support?
As of version 1.0 we only support the PDF format.

What is PDF?
PDF is an ISO standard for document storage and stands for "Portable Document Format". PDF has a page description scheme(borrowed from Ghostscript) that treats the page as a 2-D coordinate system where the bottom-left corner is assumed as the origin and objects(text, figure, ...) are geographically positioned across the page in this addressing manner. For more information please take a look at the PDF standard specification.

Is readaratus a software for reading books or a protocol?
Both. Ultimately, readaratus would be a protocol for learning. This means that it stores the content and the decoder for that content in the same unit of storage. Think of it as a content ready virtual computer that can run on any machine and eliminates the need for an external reading tool.
It is a reading program since we have already a lot of books in the PDF format that need to be dealt with.

What do you mean by "machine-friendly"?
Current content storage systems are not designed to be retrieved by computerized routines. The PDF standard, for example, provides no directions for retrieving figures of a page, there is no way of distinguishing between header, body, and footer of a page, there is no way of extracting drawn charts, tables are difficult to extract and ... . To fully grasp he tyranny of the PDF standard just look how many projects are out there trying to extract information buried in PDFs. Word processors and type setting systems which are in turn used to produce PDFs burn all these useful meta-data about objects simply because the PDF scheme does not provide any means for storing them.
A protocol that provides the content is obliged to aid potential readers in decoding the content.

What do you mean by "self-decoding"?
A readaratus unit of storage is divided into several parts. One of the important parts contains the instructions used to prepare a decoding tool. This decoding tool is similar to the mainstream book reading softwares and is in turn used to display the book contained in the package.

What common features of mainstream PDF readers are missing in readaratus?
Annotations, form filling, password protection of files, and object(text, figure, ...) selection/copying are not incorporated in readaratus. We need to discuss these issues with people before incorporating them in our protocol.

How can I switch to continuous reading mode?
As of version 1.0, we do not support this feature. But we are working on it. This is also causing some headaches when there are more than one TOC item in a single page.

Isn't the reading screen a bit crowded?
Agreed, but it is temporary.
For the moment, we have created the crudest user interface possible. We think that keyboards are not human-friendly in that they completely ignore the tactile awareness of our minds by replacing delicate commanding culture of our hands with uniformly mechanized strokes of keys. We are specially interested in a keyboard-averse gesture commanding input system where functions of readaratus is accessible through a rich set of gestures similar to how the Rand's GRAIL system functioned.

Memory usage is unusually high, why?
This is an issue that we have with Poppler's Page object class. We preload all Page objects at once and each Page object occupies about 750KB of memory which is unusually high and for a 100-page book the memory usage would exceed 75 MB. We are working to fix this.

What languages are supported?
As of version 1.0, we support books written in English.

What is the license?
GNU General Public License V3 or later.

How do I run the downloaded program?
In Linux: unzip the file you've downloaded, make it executable, and run. You also need to install poppler-glib and Gtk3 runtime libraries.

What is your technology stack?
Currently we program in C and we depend on Poppler-glib, GLib, Gtk, Cairo, and Pango. Finally, all dependencies would be removed and a bare-metal ready version of readaratus hopefully written in more humane language like Squeak or Erlang would remain.



Source code


Linux 64-bit(x86_64) - version 1.0


Mac OS X 64-bit(x86_64) - version 1.0

in progress


Windows 64-bit(x86_64) - version 1.0

in progress

readaratus is a free and opensource effort. Please consider supporting us.
Bitcoin: 157e8W6thG4XH9AmSWuB62jeCZfn62jXtz