Using Readium Web for Zotero's EPUB support

[HadrienGardeur]

Hello,

While looking up for projects that reference Readium, I discovered that Zotero's Reader relies on Readium CSS v1 with a heavily forked version of EPUB.js.

Over the last three years, we've been working on a Readium project for the Web, which directly ports our work on Readium Mobile (Swift/Kotlin for native iOS/Android apps) with two different toolkits:

• a Go toolkit, primarily meant to run on a server: https://github.com/readium/go-toolkit
• and a TypeScript toolkit, primarily meant to power an EPUB reader: https://github.com/readium/ts-toolkit

More recently (in September 2024), we started working on a fully open-sourced (BSD-3) Web Reader built on top of these toolkits and using TypeScript/React to provide all the features that one would expect from a full-fledged reader.
We're expecting to reach 1.0 status in late March, but in the meantime you can check the following resources:

• Repo: https://github.com/readium/playground
• Build: https://playground.readium.org/

Our roadmap for this project in 2025 includes support for a read aloud feature (using TTS or pre-recorded), audiobooks and many accessibility features.

This is also the first project built on top of Readium CSS v2, which introduces a new take on how we handle pagination and user settings.

I'd love to chat with developers or project managers working on Zotero to provide more details, feel free to send me an email at hadrien.gardeur@edrlab.org

cc @mrtcode and @AbeJellinek

[AbeJellinek]

Hi Hadrien, thanks for getting in touch. The new web reader implementation looks slick! From my little bit of testing, it seems to work really well, and it's a definite improvement over the old https://readium.firebaseapp.com/. But I don't think I'd be interested in doing a full rewrite on top of the new toolkit right now for several reasons:

• The client/server split isn't compatible with Zotero's model - people primary use Zotero and its reader through a desktop app written in JavaScript (think Electron app with Firefox as the base instead of Chromium), and the reader needs to work fully offline.
• We use a single reader UI and theming system in all three of our reader types (PDF, EPUB, and snapshot), so we wouldn't want to switch to Readium's, as nice as it is.
• We've worked hard on getting accessibility right with our current EPUB implementation, and we've met WCAG 2.2 Level AA.
• Our current reader is fairly mature and we've ironed out many of the quirks and incompatibilities reported by users. EPUB.js is not modern, but we don't use its renderer at all, and the data model is fine for our purposes.

That said, I'm certainly open to selectively integrating some of these improvements into our reader. I think that the work you and the project are doing is very valuable, and we'll definitely always look into the components that Readium offers when working on new features.

[HadrienGardeur]

Hello @AbeJellinek,

From my little bit of testing, it seems to work really well, and it's a definite improvement over the old https://readium.firebaseapp.com/.

Glad that you like it!

Readium JS (which powers the old https://readium.firebaseapp.com that you're pointing to) hasn't been maintained for many years now, we switched to a very different architecture around 2016/2017 and have been slowly building toolkits and open-source apps for all platforms since then.

The client/server split isn't compatible with Zotero's model - people primary use Zotero and its reader through a desktop app written in JavaScript (think Electron app with Firefox as the base instead of Chromium), and the reader needs to work fully offline.

The client/server split can be entirely handled in the app in this case.

We've had to deal with something similar in Readium Mobile (our native Swift/Kotlin toolkits for iOS/Android) and also in Thorium Desktop (an open-source desktop app built with Electron).

On the Web it's a little bit harder, but would be doable using a Service Worker. We don't really support that use case right now though.

Based on our experience dealing with EPUB files, we prefer keeping the bits in charge of interacting with ZIP separate from the reader itself as much as possible.

We use a single reader UI and theming system in all three of our reader types (PDF, EPUB, and snapshot), so we wouldn't want to switch to Readium's, as nice as it is.

A few other organizations are in the same situation, and in this case, they usually build on top of the toolkit (Readium Web) rather than on top of the app (Thorium Web).

We also have lower-level building blocks that can be leveraged as well, such as Readium CSS (which you're already using) and Readium Speech (for read-aloud support).
With Readium Speech for example, we plan on building a fully standalone library that could be used with EPUB, PDF or any text-based format.

Finally, Readium LCP support might also be useful for Zotero, as it would allow your app to open DRM protected EPUB, PDF and audiobooks that your users would either buy from a retailer or borrow from a public/academic/specialized library.

In any case, if you're interested in how any of this could be leveraged or what our roadmap looks like for each of these projects, feel free to reach out whenever you want.