Open HadrienGardeur opened 4 months ago
Shouldn't we consider that the job is done (or well engaged) via https://github.com/readium/divina-player-js?
No, because we want a navigator aligned with what we have in Readium Mobile which isn't the case of https://github.com/readium/divina-player-js.
This means support for the Preferences API among other things.
Keep in mind that this is an Epic as well, which covers work across both toolkits.
Just to add, regarding being "build on top of <canvas>
", I would not recommend we go for an approach where the reading engine itself is in a <canvas>
. We can use a canvas to render individual pages, but things like transitions, scrolling etc. should be implemented using mostly CSS and the rest of the browser engine. We'll save a lot of time not reinventing the wheel and having to optimize for performance and memory usage. Comic readers I have observed that using a purely canvas-based engine are usually lacking many features due to the complexity involved. Not to mention accessibility will become more difficult
While Readium Web is already capable of handling comics/manga through its EPUB FXL navigator, we'd like to go further by providing a dedicated navigator optimized specifically for image-based navigation using the Divina profile of the Readium Web Publication Manifest.
This navigator would be built on top of
<canvas>
and need to be able to handle the following type of publicationsThis means that we'll need the ability to support:
On the server-side, the go-toolkit should be able to parse and serve as Divina:
In addition, we'll also need to support obfuscation over individual images of these publications to enable the distribution of some copyrighted content (this will need to be covered in a separate Epic).