Divina transitions between frames in a comic book.

[m-abs]

As mentioned in #74, at Nota (the Danish Library and Expertise Center for people with print disabilities) we are moving from DAISY 2.02 to EPUB and RWPM.

We use an in-house DAISY 2.02 format for comic books with narration, but if possible we'd like to use a format others can use when we migrate to EPUB and RWPM in 2021.

The Divina profile for RWPM looks promising but lacks a few features for our needs, the second issue is the transitions on a comic book page.

This drawing shows what we're correctly using and would like to keep when moving to RWPM with Divina.

Reading a narrated comic book page goes like this:

1. Zoom out to show entire page, e.g. frame 0
2. Zoom in to show frame 1.

• If the frame is wider than the viewport, pan from left to right while the frame is being narrated, (minus the zoom to frame time).

3. Pan and zoom to show frame 2

• If the frame is higher than the viewport, pan from top to bottom while the frame is being narrated, (minus the zoom to frame time).

4. Pan and zoom to show frame 3
5. Pan and zoom to show frame 4
6. Pan and zoom to show frame 5
7. Load next page and repeat from 1.

If possible slide left <-> right on page change would be nice-to-have.

[m-abs]

I hope to provide an working example of our current model over the next few days.

[HadrienGardeur]

I wonder if you really need explicit transitions for what you've describing. Based on your drawing, you could already handle what you want to do with guided, which seems to be a mix of:

• full page
• panel
• zoom on a specific area of a panel

In your description, you seem to be describing rules that a reading system could follow to reproduce your expected behavior:

If the frame is wider than the viewport, pan from left to right while the frame is being narrated, (minus the zoom to frame time).
If the frame is higher than the viewport, pan from top to bottom while the frame is being narrated, (minus the zoom to frame time).
If possible slide left <-> right on page change would be nice-to-have.

In addition to these two rules, you could also implement an auto zoom in and out based on the dimension of the fragment described in guided.

[m-abs]

It might be clearer with a demo of our correct renderer using own our format for DAISY 2.02 comic books demo.zip. It has two comic books and one book with text+images.

In addition to these two rules, you could also implement an auto zoom in and out based on the dimension of the fragment described in guided.

That is what we do with our own format. Since both the format and the renderer are made by us, we assume the client knows how to render the transitions and panning.

We can keep doing this if needed, I was just thinking having a more standardized way to do it might be better.

[anymus]

This kind of feature fueled much debate within the Divina working group :) We discussed at length the issue of structure vs. behavior: should the format specify precisely how a reading system is expected to render content or should it just describe its inner structure and leave it to the reading system to apply rendering rules?

In particular, guided navigation presented several challenges: should each page be presented in full before zooming in on certain regions? Should the different regions be presented one by one with a mask to cover the surrounding parts, or should the rest of the page still be visible? Should each region fit within the viewport or should the zoom level be kept constant? Should there be transitions to go from one region to the other, or at least some kind of "camera movement" giving the impression that we're hovering over the page (note: the user feedback we collected from systems who implemented such behaviors seems to be very negative)?

Faced with so many options, we eventually decided to stick to structure information only (and this general philosophy we followed is also why "presentation hints," for example, can only be called like that - "hints"). The Divina Player we're implementing answers all the above questions one way - regions only, with surroundings masked and no transitions - but other reading systems are free to make their own choices.

Transitions can be added if the author feels they are an integral part of the story - however the format itself cannot ensure that they will be rendered correctly by any reading system, since that depends on specific implementation... More complex behavior, liked timed panning across a region or page, could be made possible in future evolutions of the format, when keyframe animations is in place (please note that this is not something we consider in the short term).