Separate non-paginated modal viewport for ancillary EPUB documents / non-linear HTML spine items

[ClementHard]

Hi,
I'm trying to open non linear items into a popup webview on android but the InternalLinksSupport does not seems to support links to those items properly.

Is it possible to check the linear nature of the item and add a target on those links ?
Is there another way to do it ?
Thanks

[danielweck]

Assuming you are working from the "develop" branch, or at least from release 0.14, then support for linear="no" is provided but is indeed minimal: primary reading flow is handled correctly (ancillary content is excluded appropriately), but target linking to linear="no" content documents occurs within the same viewport (no dedicated popup window). Note that depending on the type of Readium app (i.e. Chrome app/extension, pure web browser, Android / iOS / OSX / Win native WebView launchers), the concept of a "popup viewport" is likely to vary. Therefore, if you have some ideas / suggestions about a "cross-platform" solution, please let us know.

For those who have access to the Readium developer documentation, here's the shared Google Doc where design / functional requirements are tentatively described:

https://docs.google.com/document/d/1XY4SL0hwcr4b6XvCw8yf9tKQMnDXDnjKs_MDEzPKTHc

Regards, Daniel

[danielweck]

http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-spine-elem

Email discussion:
https://groups.google.com/forum/#!topic/readium-dev/5ik4Kgvt2rc

[danielweck]

Bugzilla:
https://app.devzing.com/Readium/bugzilla/show_bug.cgi?id=46

[danielweck]

The navigation concept of "escaping" the ancillary reading context (non-linear spine items) ; i.e. branching off-and-back into the primary reading flow ; was discussed recently with the accessibility folks that are going to contribute in the implementation of external descriptions (DIAGRAMMAR model). The "modal dialog" solution used by iBooks is practical because of the obvious "dismiss" semantics (conventional UI affordance "cross" button), but the document is only scrolled, not paginated or fixed-layout as any HTML file could potentially be. Consequently, a more generic approach would seem to consist in re-using the regular Readium rendering viewport, but making sure that the previous/next page commands respect the begin/end document boundaries (instead of navigating to the sibling spine item), and by adding a new "escape" command equivalent to the "dismiss" button of a modal dialog. Must do: careful examination of the implications in terms of bookmarking (+ preserving current reading location), and "inner" navigation history (see #149).

A shared Google doc will be written to provide detailed descriptions of the expected behaviours. A feature branch will be created in readium-shared-js (core model) and readium-js-viewer (UI controls).

[danielweck]

Note that @mohit-agarwal has started working on this.

[danielweck]

Google shared doc: https://docs.google.com/document/d/1XY4SL0hwcr4b6XvCw8yf9tKQMnDXDnjKs_MDEzPKTHc/

Related issue (history navigation): readium/readium-js-viewer#127

[danielweck]

Addressed in PR: #211