Multiple reader engines

[shuvashish76]

Request to use multiple well known ebook reader engines
For example : Personally I think what makes KOReader great is it uses multiple engines for ebooks (just the app isn't user friendly for android users as it's targeted mostly for e-ink devices)

• https://github.com/koreader/crengine their own fork of CREngine
• https://mupdf.com/ (now with v1.24.0 supports MS Office type files, hence KOReader v2024.07 already support them as well)

Screenshot

[Acclorite]

Thanks for suggestion, but can you tell more details? From what you've said I can see two ways of what you mean:

1. Choosing which parser to use for parsing books. Cannot be done as it conflicts with the main app's idea - having "safe" zone. Firstly parse the book, then add it to the Library, where even if the book's file was deleted there will not be any difference, because the text was already saved for as long as book is added to the Library..
2. Changing visual appearance of Reader. This may be a good idea, but I want to stick to extending customizability.

[shuvashish76]

From what you've said I can see two ways of what you mean:

To some extent both.

Choosing which parser to use for parsing books. Cannot be done as it conflicts with the main app's idea - having "safe" zone. Firstly parse the book, then add it to the Library, where even if the book's file was deleted there will not be any difference, because the text was already saved for as long as book is added to the Library..

Is it too late to reconsider the philosophy of this project🙈? If I'm allowed to say...I really don't like 🙊 the current text only parser system as it's lacking many advanced features that those reader engines offer including images #30, charts, diagrams, tables #24 etc.

My proposal is to give the user freedom to choose from multiple engines (CREngine really good for epubs, mupdf for PDFs) for their ebooks similar to KOReader. And having an opt-in feature for text only parser. All options configurable from the settings page...like which file types would be used by which engines. The UI/UX needs a revamp for this.

I can understand why in the current situation you don't want such feature as it needs heavy modifications + brings chain of multiple feature requests with it.. but please keep the discussion open so that others can share their views/opinion on it. Thanks

[Acclorite]

Is it too late to reconsider the philosophy of this project🙈? If I'm allowed to say...I really don't like 🙊 the current text only parser system as it's lacking many advanced features that those reader engines offer including images #30, charts, diagrams, tables #24 etc.

As discribed in #24 I have an idea on how to implement text formatting. Images would look ugly in such customizable space (e.g. with changing colors). It is not about "philosophy" of the project. Browse screen will become useless as the files will be getting directly. This will directly affect current features and some I am planning to do (which a lot of people ask). For example, displaying PDF as is will also mean no such customizability as there is now and will be. It would probably be easier to create a new app from scratch than implementing this in current system.. It is not about philosophy, but more about the whole app concept, implementation and future.

I can understand why in the current situation you don't want such feature as it needs heavy modifications + brings chain of multiple feature requests with it.. but please keep the discussion open so that others can share their views/opinion on it. Thanks

I will let it be open, but really, don't hope on actual implementation.