what’s the benefit of this over Okular or Okular Mobile
More concretely, Okular has a number of issues with ePub:
It splits the content into paper-sized pages. Unlike an e-reader these pages have nothing to do with the screen, it still scrolls between them, just with an occasional page break. It has neither continuous pageless scrolling, nor screen-based discreet pages.
It doesn’t reflow when zooming. It’s clearly designed for fixed-layout content.
It lacks a lot of ePub features, such as a lot of CSS, inline SVG, and the hidden attribute.
It renders images in ePub at a low resolution and upscales them, resulting in even high-resolution images looking pixelated (presumably a bug in Okular).
It doesn’t support ePub 3 (it does handle some non-ePub 2 features, such as the video tag, but it notably doesn’t support ePub 3 TOC).
As for whether it’s simpler to make a separate application or add those features to Okular, I don’t know.
Some questions I have:
Does it support both continuous scrolling and discreet pagination modes?
Will it be available on Android?
Will it have full ePub support (most reader apps seem to lack a lot of CSS and inline SVG; Lithium is the only decent one I’ve been able to find)?
Will it support other reflowable publication formats, e.g. MobiPocket, FictionBook, Kindle and Markdown, or is it just for ePub?
Has anyone reported any of these (to the knowledge of any of the participants of this thread)? I ask because although I might not be the best bug owner for any of them, I can at least try to verify and report them if none of you have the time to.
Also, text selection in Okular by default highlights a rectangle, rather than highlighting content in a semantic order. But that can be switched, and it would make more sense to default to text highlighting for reflowable documents.
Wasn’t there KParts or something similar that would essentially just pop in a different renderer in the same GUI? (I’m grossly oversimplifying and forgot the right terms)
KParts still exists, but it’s not relevant here for a few reasons:
It’s the whole guts of the app, not just a front-end or backend. It’s used when you actually want to embed an app inside another one or write a thin wrapper around it with a slightly different UI (e.g. Yakuake is a wrapper with a slightly different UX around the Konsole core functionality).
Its QtWidgets-only and we want to be using QtQuick for our new apps.
So how is Peruse distinguished from Okular? At least Arianna distinguishes itself by focusing on reflowable documents, but Peruse and Okular both seem to be made for fixed-layout documents.