Browser Engine vs EPUB Rendering Engine

12 posts / 0 new
Last post

I find the readium project to be haphazard. As a developer, looking at the source code it looks like bits of code put together by somewhat disinterested developers. It seems to lack direction as far as the ultimate reusable end product. Since this is a rather serious software engineering project (I.e. reusable rendering engine component for EPUB3) I wonder why this is so. Why is there no upfront design for functionality that has clear requirements specified in the EPUB3 specs?

Why can I not just grab a binary that gives me an interface with a small set of methods that do exactly what it is intended to do?

When I use a rendering engine component for EPUB3, I expect it to ask me for an EPUB3 zip file, open it and return me a set of pages, at the very least. Additionally it should return metadata and resources like video and its position on a page/screen bitmap. I expect it to deal with HTML5, SVG, CSS, MP3, MP4 and any other formatting technology that is required by the spec. I, as a developer, can then by having a high level understanding of the EPUB3 spec, know exactly what to do with the pages.

Finally, and most importantly, why is readium based on WebKit? By my understanding the requirements for an EPUB3 rendering engine is not an extension nor is it a subset of the requirements for an HTML based browser engine. The EPUB reader is not a descendant of the browser, it is somewhat of a cousin. EPUB borrows heavily from the technologies required to render web pages, but an EPUB page is NOT a webpage so isn't it somewhat unpragmatic to have the one reference implementation for EPUB3 based on an engine that arguably is not designed to implement the same set of functionalities? Apart from the bloat and unnecessary functionality, you will also have situations where a developer tries to hack a similar functionality to an EPUB3 functionality causing all sorts of software problems and creating future bugs and headaches.

It is somewhat worrying that the entire publishing industry is waiting on this Readium project as the catalyst for doing good business with ebooks. I think it's a disaster in that sense. A tragedy even since everyone is waiting on this one project that is bound to fail.

The point, the purpose of a project like readium is to remove the need for developers to write boilerplate code - i.e. the difficult, tedious code that is common to all ereaders using EPUB. If the work is done correctly, I should be able to write an ereader app without any knowledge of how to manipulate in code the underlying formats (HTML, SVG, CSS etc).

It's like trying to create airplanes but the engine is unavailable, this is the current state of EPUB3. Nobody is flying. The end product cannot be a loose set of flimsy code in .so and .js files that require the developer(s) to understand how they've been written. The end result must be a black box, with inputs and outputs. A publisher launching an ereader app wants to focus on the app and not the intricate details of parsing HTML. Conversely , the ereader maker doesn't want things like UI and navigation built into the rendering engine. The ereader maker wants to be free to make the decisions about how his/her app looks and feels.

So, to reiterate, the rendering engine product needs to be a black box, with inputs (e.g. a content document, an epub zip or a set of epub zip files) and outputs (pages for the platform, e.g. Android/iOS and metadata objects). App developers don't want to know how it works inside. App developers DO need some design documents that show them how to use the OUTPUTS of the rendering engine to make their paginated ereader applications.

EPUB 3 supports all of HTML5, SVG, JavaScript and CSS3 (there is a CSS3 profile but that is only a minimum required level). So it is as a practical matter unreasonable to build an EPUB 3 reading system other than by building on top of a browser engine. The consensus decision to align EPUB 3 so tightly with the Open Web Platform was not taken lightly (back in 2010 it wasn't even 100% clear whether HTML5 was going to gel). But that's the way we went and as EPUB's use expands into learning content and other areas that go beyond straight text I still believe it was the right decision. The direction of evolution in EPUB 3.1 and beyond will further strengthen this alignment.

As a result EPUB 3 reading systems, even if they are native apps, necessarily utilize browser engines. And these engines differ on a platform-by-platform basis so Readium in fact is not "WebKit" based (life would be a lot simpler if that could be true!). For native apps, on iOS Readium SDK uses UIWebView, on Android WebView, etc. We have Readium Chrome App which of course uses Chrome, And Readium Cloud is for browser deployment of EPUB conent that needs to work on all browsers. 

Readium SDK/JS can thus be thought of as a set of "polyfills" that add to a browser (/ browser engine for native apps) everything needed to do EPUB that a browser doesn't already do: resource extraction from a ZIP archive, metadata parsing, pagination, media overlays. As such these "polyfills" necessarily vary depending on the platform/browser they are layering on.

That does make things quite a bit more complicated and messy than if EPUB 3 was able to be delivered via a single cross-platform binary application.  But again that is a consequence of our decision to align with the Open Web Platform. Using Readium software is certainly much less work for a developer than to write all these features yourself. And if you want to help us make it even beter, we welcome new contributors!

Bill, Android Webview is WebKit , but, I digress.

In the EPUB 3 specification overview, it states:

"EPUB Content Documents may optionally reference EPUB Style Sheets, allowing Authors to define the desired rendering properties. EPUB 3 defines a profile of CSS based on CSS 2.1 [CSS2.1] for this purpose, together with capabilities defined by various CSS3 Modules and several additional properties specific to EPUB.”

Just wanted to be clear, does that mean CSS support is optional like JavaScript? Or is there a basic set of CSS that all Reading systems must support to be conformant?


Thank you for your insightful feedback. After three years of volunteer work on this open source project, I had no idea it was haphazard. I'm glad you cleared up the purpose of the project too, as we who started it clearly had no idaea. Obviously you have done your homework. It is developers like you that, having contributed no code, but who have brilliant insights, that get me up in the morning.

Thank you for your insightful feedback. After three years of volunteer work on this open source project, I had no idea it was haphazard. I'm glad you cleared up the purpose of the project too, as we who started it clearly had no idaea. Obviously you have done your homework. It is developers like you that, having contributed no code, but who have brilliant insights, that get me up in the morning.

Micah, you're that Bluefire Reader guy I suspect? I'm glad I get you up in the morning, but, my insight wasn't intended to slight the developers. Instead you could see it as me suspecting something could be wrong with the development process if there isn't any documentation or a developer guide for a project that is presumably very important to the publishing industry.

I also have an eReader app (Djenne) and I'm hoping to use Readium as my rendering engine since my app is native and not browser-based, I was a little concerned about the direction of the project. Hopefully by contributing our insights both our businesses can reap benefits from this project. Bottoms up!

@odeyemi How on earth could they have created a cross-platform solution without depending on a browser engine?

That being said, I do think the Readium-JS codebase is bloated with unnecessary dependencies (eq. jQuery) and the coding consistency across files differs. It's hard to contribute to such a project.

@odeyemi Sorry for being so grumpy in my comment, I was having a bad day. The "haphazard" and "disinterested developers" comments kind of set me off. In any case, apologies are in order on my part. Regarding "browser based". The native code versions of the project (e.g. for iOS, Android, etc) do rely on web views. A browser engine of one kind or another is necessary to support HTML5, as otherwise one would be writing their own browser engine in native code, which would be a significant undertaking and require significant maintenance. And in the case of Apple, it does not appear they would allow that under their app store policies. The Readium projects are community based (e.g. volunteer contributions) and there are weekly meetings for the various projects. It is a work in process, and we welcome contributions. There is three years of work under the hood, and there have been weekly meetings throughout, and I assure you that the developers are anything but disinterested. It is true that documentation could be better for sure. It is one of those things that is hard to find volunteers to do. If you are interested in using the SDK, I highly recommend attending the weekly meetings, as from my standpoint, I can't imagine a developer succeeding in implementing without doing so, as it is evolving quickly and is rather complex.

I wear many hats Micah. I am the developer of Djenne and I am also the owner. My concerns go beyond development matters and I think about the long term impact of my choices. Thus far, I don't think Readium is a good product to adopt. I've been in the technology business long enough to know from a distance when a project smells bad.

Same here in terms of multiple hats, e.g. I'm CEO, but in terms of other hats, not actually a developer in my case, I'm a UX guy.

Given your comments, I would agree that it is probably not the right fit for you. If you take a different path to implementing EPUB3 rendering, and it works out well, it would be great if you could post back here what path you took.

I have been searching for webkinz unused codes and I found for generating it through powerful webkinz codes generator.

Secondary menu