Open Grunthos opened 11 years ago
Thanks for considering my request. In fact I am not in favor of a standard reader API, as it reduces the flexibility and is restrictive. I have used and tested many readers on Android and I feel that depending on one's needs and preferences, one would rather chose the reader suited for the task instead of being stuck with a stock reader. For example, I prefer the reading experience on dedicated eBook readers, but despite that I would rather use Android devices which give me the flexibility to use the reader of my choice. If I want to read books in complex script like Arabic, not all the readers can display these properly. Sometimes, I prefer the embedded fonts and some readers support it while others don't.
Now as to the problems:
Kindle does not support ePUB but the MOBI format, and these files do have garbled names. If the user can't identify the file, he would even otherwise have problem accessing the file except through Kindle app.
Some readers do store epubs in their own directory, but user can still keep them in the directory of his choice nonetheless.
I have never liked the blanket scanning for ePubs. If a user wants to have a catalogue of eBooks on the device, per se, he/she can always use one of the many reader apps to do it. Book Catalog is basically for cataloging physical library, and let it stay that way. But where one has the digital eBook also available, let the user have the ability to hyperlink it, so to say, and access it too.
If you could add this functionality of hyperlink, user can even put all these eBooks (PDF, ePUBs, MOBI, Doc, HTML, TEXT etc.) in a local or cloud directory and access these easily. This functionality needs to be seen as an wxtension to the catalog of one's collection of books in hard print.
Thanks.
From a user:
In the absence of a standard reader API, this might be a good first step.
The key problem with this is: