Support for multiple renditions

[rkwright]

This issue is a Enhancement

• This is a discussion of the feasibility and approaches to supporting multiple renditions in Readium 1 and, potentially down the line, Readium 2. This issue is derived from an email thread here.

Related issue(s) and/or pull request(s)

None

Test file(s)

Only one MR book is known (though there may be others out in the wild we do not know of). It is here (??)

Product

Only an experimental readium-js-viewer demo is known. The branch is here. The demo itself is here.

Additional information

None at this time

[rkwright]

From @mutterback

We are exploring multiple renditions with UNICEF as a way to manage content inside 1 ebook for all learners. For deaf students there would be sign language videos, and for Intellectually Impaired students, simplified language.

I've seen a demo of Readium JS with a multiple rendition menu in the settings, so I know it's there somewhere. Saw the note http://idpf.org/forum/topic-3444 about very little content to test with. I agree - and our plans would include some content development.

Could you give me a quick pointer to the multiple renditions code in JS and any feedback on the roadmap for support in R2?

Very open to your feedback on how we could best contribute to make multiple renditions work well in R2.

[rkwright]

from @danielweck

Readium 1:

Link to the latest prototype build from the "Multiple Renditions" feature branch (slightly out of date, relative to the develop branch):

http://readium-multirendition.surge.sh/?epub=https%3A%2F%2Fcdn.rawgit.com%2Fsnaekobbi%2Fbraille-rendition-epub%2Fsamples%2Fedupub%2Fsamples%2FWCAG-ch1

This is the only EPUB3 Multiple Renditions demo book I know of (it includes the all-important Renditions Mapping Document too, to cross-reference positions within the publication, between the Braille and text renditions). Well, actually I am also aware of the Brazillian Dorina Foundation effort, but I do not know where to find the EPUB, or even whether it is publicly-available.

Readium 2:

No plans to include support for EPUB3 Multiple Renditions in the "webpub manifest" (internal JSON data format optimized for the client/server architecture of R2 reading systems). I think the concept is more likely to gain traction in R2 if the implementation design consists in some form of superstructure that binds together two or more individual publications, much like in EPUB3 but without the desire to include everything in a single publication package. Special handling would be needed on the reading system side to fetch + process more than one publication, but that is actually exactly how the Readium1 prototype anyway.

[rkwright]

from @mutterback

@danielweck: Thank you Dan, that's very helpful,

Let me ask a clarifying question re "Special handling would be needed on the reading system side to fetch + process more than one publication, but that is actually exactly how the Readium1 prototype anyway."

What you are saying is that you would pull content from book 1 (standard text) + book 2 (sign language video) into the reading system. For the user, it looks like 1 book.

Where would the "superstructure" live? ebook, streamer, navigator code if I have the main moving parts right in my head?

[rkwright]

from @HadrienGardeur

It would live in the model, which is shared by all the moving parts in R2.

Since a multiple renditions publication is almost like working with multiple publications, this could be represented as a special kind of OPDS 2.0 feed, one where we also provide a collection for mapping resources across publications together.

[danielweck]

For reference, the Pull Request is: https://github.com/readium/readium-js-viewer/pull/435#issuecomment-170640044

[danielweck]

A Multiple Renditions EPUB really consists in a publication container that includes 2+ separate publications (2+ individual OPF package files and their associated resources) and some additional metadata in META-INF/ to describe each of them (criteria for selection depending on user / reading system preferences) and the mapping document.

The Readium1 prototype implementation handles such multi-package publication in a mutually-exclusive way, by rendering one or the other(s) at any given time. Note that other implementations may decide to display the publications' documents side-by-side, I don't think the EPUB3 specification imposes any particular presentation mode.

In my opinion: in Readium2 "webpub manifest", instead of merging the resources (individual assets CSS, HTML etc.) into a single publication container, maintain the separation and serve additional metadata to logically bind them together. This metadata can live in a separate JSON document, or even be embedded in each of the renditions. The important point is that each distinct publication "package" defines what is within its scope (concise pub manifest).

I haven't spent much time brainstorming about this, but this where I stand at this moment in time. I may be convinced otherwise, if you insist :)

[HadrienGardeur]

In my opinion: in Readium2 "webpub manifest", instead of merging the resources (individual assets CSS, HTML etc.) into a single publication container, maintain the separation and serve additional metadata to logically bind them together. This metadata can live in a separate JSON document, or even be embedded in each of the renditions. The important point is that each distinct publication "package" defines what is within its scope (concise pub manifest).

There's not a lot of additional metadata in container.xml, we could easily add those to the metadata of each Readium Web Publication manifest.

If we re-use publications from OPDS 2.0, this could look something like the following example:

{
  "publications": [
    {
      "metadata": {
        "title": "Basic rendition"
      },
      "spine": [
        {"href": "text.html", "type": "text/html"}
      ]
    },
    {
      "metadata": {
        "title": "Braille rendition"
      },
      "spine": [
        {"href": "braille.html", "type": "text/html"}
      ]
    },
  ]
}

[danielweck]

To each of your comments: 1) yep, my point exactly. no merging of resources. just additional metadata. 2) that's what I was alluding to when using the term "superstructure"

[mutterback]

From @danielweck A Multiple Renditions EPUB really consists in a publication container that includes 2+ separate publications (2+ individual OPF package files and their associated resources) and some additional metadata in META-INF/ to describe each of them (criteria for selection depending on user / reading system preferences) and the mapping document. The Readium1 prototype implementation handles such multi-package publication in a mutually-exclusive way, by rendering one or the other(s) at any given time. Note that other implementations may decide to display the publications' documents side-by-side, I don't think the EPUB3 specification imposes any particular presentation mode. In my opinion: in Readium2 "webpub manifest", instead of merging the resources (individual assets CSS, HTML etc.) into a single publication container, maintain the separation and serve additional metadata to logically bind them together. This metadata can live in a separate JSON document, or even be embedded in each of the renditions. The important point is that each distinct publication "package" defines what is within its scope (concise pub manifest). I haven't spent much time brainstorming about this, but this where I stand at this moment in time. I may be convinced otherwise, if you insist :) Cheers, Dan