Is Readium a Rendering Engine or Reading System?

6 posts / 0 new
Last post

I am new to this forum and I came here because I discovered Readium appears to be the only publicly known effort to manifest an EPUB3 rendering engine and/or reading system. I am however confused as to what Readium really is. Is it a rendering engine, meaning, is it software that transforms EPUB documents into a set of pages and associated metadata or is it intended to be a complete reading system? If it is a complete reading system in its own right, can I customise the look and feel for my own app? Are templates built-in to make it possible for me to "re-skin" the application to my taste?

I would be very grateful if someone well acquainted with the Readium codebase could point me in the right direction with regards to a Developer Guide or some kind of API user manual that allows me to either use Readium as a rendering engine or as a reading system that I can customise.

Many thanks.

The short answer is that Readium is both.  There are two major variants of Readium:

1. ReadiumJS, which is a pure JS implementation of an EPUB3 Reading System.  There are two variants of this: the CloudReader, which is a cross-browser implementation (see http://development.readium.divshot.io/) and the Readium Chrome Extension (see https://chrome.google.com/webstore/detail/readium/fepbnnnkkadjhjahcafoag...).  Both ReadiumJS RS (which share 90% of their code) are full Reading Systems (albeit not as complete as we would like, but improving) which support almost all EPUB 3 features.

2. The Readium SDK which is a C++ Core plus the same shared-js layer used in ReadiumJS.  The SDK supports iOS, Android, OSX and Windows (limited). Each platform has a "Launcher" which is a deliberately primitive RS app whose sole purpose is to facilitate testing. A number of different firms have built apps on top of the SDK.  

For more information, see  http://readium.github.io/

re Documentation, it is regrettably one of our weak points, which we are working on, but the above link should get you started.  Please feel free to continue this conversation either here in the forum, or contact me directly at rkwright@readium.org.

Ric Wright, Dir. Eng. Readium Foundation

Right. What you're saying is that 'the Readium SDK is the Rendering Engine', a core C++ library that does the things one would imagine a Rendering Engine should do (albeit incomplete). There is a JavaScript layer atop the SDK which has been used in the two JS-based Reading System apps (Cloud reader and Chrome extension) supplied by the Readium Foundation. You also have Launcher apps (JavaScript apps?) on the various platforms (iOS, Android etc) that use this shared-js facade for the C++ SDK.

For my purpose, I have no interest in the shared-js library since I am working on native apps for iOS and Android. I would like to know how I can plug into the C++ SDK directly. If you would be so kind, could you please point me to the C++ classes or subroutines that perform the functions of the rendering engine? I would like to gain a clear understanding of the relevant interfaces that return structures like pages and metadata. Obviously, an understanding of the design of the rendering engine (in terms of relationships between classes and functions) would be the most useful thing. It's unfortunate that the design for use isn't actually documented. If you could show me the relevant code as I've asked I could contribute to the project at my leisure by documenting this most important aspect of the codebase to make it easy for developers interested in making Reading Systems to plug and play into the Readium SDK.

Thanks for your support Ric Wright.

OK ignoring all the JavaScript stuff as I'm only interested in the Rendering Engine, I've found the code here:
https://github.com/readium/readium-sdk

When you say the Rendering Engine is built using the MVC pattern (a design pattern appropriate for GUI systems), is that a cryptic way of saying that the Rendering Engine's OUTPUTS are a set of "view" objects which are returned when a client invokes functions on the "controllers"? The "model" being, of course, where the actual parsing job is done.

So from a Reading System maker's viewpoint, I only need to know about the Controllers, which are the interfaces for working with the Rendering Engine and the Views, which are the things I'm really looking for I.e. the PAGES and METADATA objects that give me the data to populate my Reading System UI.

Ric, could you please confirm for me that my understanding of the Rendering Engine design is correct?

Finally, could you please tell me the names of the Controllers I need to invoke? Are they in a package somewhere in the source tree? Do they have a naming pattern?

Many thanks.

Well, the design of Readium is such that you can in theory do this but it would require a lot of work.  Basically, there has to be a layer that allows the C++ to talk to the browser engine (which may be WebKit, UIWebView, Edge, Trident, etc.) in a cross-platform way.  We have chosen, in Readium, to do this via the shared-js layer.  I.e. the SDK constructs JSON "messages" which are sent to the shared-js layer which dispatches them appropriately and uses the browser and OS for the heavy lifting.

Bear in mind that there multiple platforms here (iOS/Objective C, OSX/Objective C, Windows/C++, Android/Java/JNI, etc.).  So the decision to "wrap" the SDK in a JS layer was done to try and mitigate all these cross-platform issues.  In addition, the ReadiumJS side also used the shared-js layer, so there is a code saving there as well.

So using the SDK without the shared-js layer would require that you re-implement all the work that the shared-js layer does (for every platform/browser).  That is feasible but a LOT of work.

Re:
"Basically, there has to be a layer that allows the C++ to talk to the browser engine (which may be WebKit, UIWebView, Edge, Trident, etc.) in a cross-platform way. "

The browser engines are written in C/C++. Likewise we are trying to (I believe) write an EPUB engine that "transcends" the browser. Why would you need a layer of JavaScript to get C++ to talk to C++?

All the platforms you've mentioned run C++ so there is no reason to "wrap" the C++ SDK in a JS layer except for the exclusive purpose of writing a "browser based" Reading System.

The next logical question then: is there a spill-over of the functions of the Rendering Engine into the JS layer, and if so, why? Surely this is bad design and breaks the model of the C++ SDK being the Rendering Engine. I should (in theory) be able to just grab the C++ code and plug it in into my Android app using JNI and invoke methods on the rendering engine. This is by far simpler than having to use a "JavaScript layer".

Secondary menu