Feature/spread render customization

[lbeus]

EPUBNavigatorDelegate

Readium allows rendering EPUB spine elements in a custom way (e.g. PDF is rendered using PDFKit instead of being loaded in WKWebView).
Client can add custom overlay on top of WKWebView using

func navigator(_ navigator: EPUBNavigatorViewController, didExtractResources resources: Any, for spreadView: UIView)

delegate method.

In order for this method to be invoked for given EPUBSpreadView, loaded XHTML resource must have link tag element inside head block.

<link href="pages/sample-page.pdf" rel="preload" type="application/pdf" class="wrapped-resource" kind="pdf"/>

Link tag must have class set to wrapped-resource. href attribute is used to identify resource registered in EPUB which client can render in custom way, and kind is arbitrary type used by client to define how given resource should be rendered.

[svenmeyers89]

All in all, I think this solution is elegant and clear, which is most important. 👍

In my comments, I suggested a naming convention that I find more general.

I'd stick to the term resource, as it describes what we're trying to convey. More descriptive variants, such as externalResource, externalResourceParameters, resourceParameters would work as well. 👍

[Zellius]

Hey @lbeus! I’m definitely behind your level of knowledge about Readium 😄 but I’d like to add my two cents regarding an alternative solution.

The proposed solution works fine, but we still need to display a WebView and call JS to render a custom view on top of Readium’s view (as I understand it). Additionally, what if users of the library want to apply a custom UI while still using Readium?

Right now, we want something like an extended EPUB format, because our EPUBs already contain a few custom xml/json files. Extended format requires extended API. I think the most user friendly and flexible approach is to provide an API for parsing customization. In the end the Publication object could have different types of "pages" (default EPUB page, PDF page, etc.). We could also provide a way to supply a view provider based on the "page" type in the navigator pager adapter.

This approach allows us to display custom content without JavaScript and without using a WebView. At the same time, it requires more changes and a deeper understanding of how the project works.

It is just an idea, but I thought it was worth mentioning 😄

[lbeus]

@Zellius I thought of that approach as well, but didn't consider it more seriously as it would require more drastic changes both to the parser layer and navigator. I agree it would be most performant way of supporting extended EPUB, but not sure if we have resources for that approach. I will check in more detail how much effort it would be, but I think we should be cautious about this approach as in the end it might take more time to adjust Readium (and still it won't be sure they will accept our changes) than to write our solution from scratch. We will definitely need to discuss this approach a bit more.