RenditionOptions: view: InlineView

[hrkazemi]

I want to replace iframe with InlineView but I have a problem when I do that.

import InlineView from 'epubjs/lib/managers/views/inline';

opt = {
   view: InlineView,
}

with this RenditionOptions There will be an error: view.offset is not a function

so I did create another class that prevents error, but the main problem is rendition.next not working at a certain point:

class AppInlineView extends InlineView {
    offset() {
        const _this = this as any;
        return {
            top: _this.element.offsetTop,
            left: _this.element.offsetLeft
        }
    }
    my_width() {
        const _this = this as any;
        return _this._width;
    }
    width = this.my_width;
}

[fchasen]

Apologizes that I don't have a better response for this but the inline view is half-backed for now and I wouldn't recommend using it. It should probably be removed as I ran into lots of style / html edge cases when running book content this way.

If you want to go this route, I'd recommend handling the content without using a rendition like in this example: https://github.com/futurepress/epub.js/blob/master/examples/renderless.html

[hrkazemi]

@fchasen thanks, I did try section.render but I couldn't figure out how to create pages of this rendered part.

[intity]

Hi, I am considering InlineView as an alternative. I found some issues with IframeView that have to do with blocking the text scaling function (ctrlkey + wheel event). If the focus of the mouse cursor is in the iframe, then the blocking does not work.

I understand there is a problem with inline book styles within the InlineView model. However, this option can be useful under certain conditions. For example, if you consider InlineView as an API extension function by registering with epubjs.

My tests with InlineView revealed some issues with epubcfi generation. Let me give you an example, for comparison:

• IframeView: #epubcfi(/6/10[pref01]!/4/2[pref01]/2[page_v]/2/1:0)
• InlineView: #epubcfi(/6/10[pref01]!/4/2[toolbar]/4[metadata]/2[book-title]/1:0)

As far as I understand, this problem is related to the algorithm for determining the root element of the document structure. That is, within the InlineView model, the root element of the book is the div container. But the function for defining epubcfi is based on the document structure, in which the root element is body.

If we still consider InlineView in the context of an API extension, then a little more options are needed to achieve the desired result at the level of the InlineView class.

[intity]

Hi I have created two branches for testing InlineView. I solved the problem with generating epubcfi. Perhaps this is not the best implementation option. However, it works.

Inline styles are also supported, although a lot of testing needs to be done.

• epubjs-reader
  • epub.js

[noe]

@intity your branches contain a lot of changes, can you point to the changes that solve the problem with the generation of epubcfi?

[intity]

@noe key changes for correct evaluation of epubcfi:

1. Retrieving the root element from the content property ( mapping.js#L40 )
2. Definition the parent element, relative to the #viewer container ( epubcfi.js#L889 ), if the target document is the main document.

The other of the changes are related to InlineView.