Viewport-based comic book view support
Open, Needs TriagePublic


where metadata defines a viewport to show, rather than a full page, research required on formats and methods

leinir created this task.Jan 21 2016, 11:01 AM
leinir updated the task description. (Show Details)
leinir raised the priority of this task from to Needs Triage.
leinir claimed this task.
leinir added a project: Peruse.
leinir moved this task to Future Features on the Peruse board.
leinir added a subscriber: leinir.
leinir updated the task description. (Show Details)Mar 3 2016, 3:01 PM
leinir moved this task from Ready for Testing to Future Features on the Peruse board.

Okay, so I've read through the code, my idea for UX for this is splitting between two/three navigation modes.

Mode 1: Image is set to fit page height, user can switching between pages.
Mode 2: (Double) Clicking on an frame area will switch to frame navigation mode. Controls for switching between pages becomes controls for switching between modes. Clicked on frame will become the current frame. Performing the same action will make it return to mode 1.
Mode 3: Pinch zoom will enter the same panning mode that is used right now. If there are no frame definitions, double clicking will also do this, like it does right now.

Now, ACBF uses text-areas for holding textdata, but EPUB's region navigation instead uses them as a refinement on frames, specifying

From this hierarchical navigation sequence, the basic Reading System behavior would be to first show each parent Region in full and then navigate to the child Regions in sequence. Since there is no extra information about these child Regions (i.e., no epub:type attribute specified), the Reading System will simply go in sequence from one to the other.

While epub support is still kinda far away (Okular uses EPUB tools, which implemented page spread handling but not viewport or region navigation before it stopped being maintained), we should contemplate whether we want add the epub method.

woltherav added a comment.EditedSep 8 2018, 11:11 AM

My investigations in this were stopped dead in it's track due to trouble accessing the pages and thus frame data.

My first goal was to get Shape objects drawn over the main image in the image browser, just to get the data accessed.

I first tried to make body into a property of the acbf document, which allowed me to access it from qml, but then trying to access the pages was a whole different story. I did find Object and List Property Types Example, and QQmlListProperty Class, but the problem is that those expect a non-const QObject and 'this' is const.

QQmlListProperty<Page> Body::pages() const
    return QQmlListProperty<Page>(this, 0, &AdvancedComicBookFormat::Body::pageCount, &AdvancedComicBookFormat::Body::page);

(Note, pageCount needs to be made as well, but it is a trivial function.)

Anyway, I am not sure how to resolve this, so I'll poke at something else instead.

EDIT: This is, btw, blocking like 90% of ACBF data access.

Hmm... this is const because the getter is const... going by what the example suggest, implementing a QQmlListProperty requires the getter not to be const, which of course seems weird for a READ function, but that is what it expects, so... yeah, try that?

Yes, I've got it sort of working. But I am wondering whether the method used for 'author' isn't easier(count of objects, count notified, add/remove entries, getentry). It is what I've used for the other metadata.

woltherav closed this task as Resolved.Sep 18 2019, 3:41 PM
woltherav reopened this task as Open.
woltherav moved this task from Future Features to Ready for Testing on the Peruse board.