pReader (an eBook Reader for Palm-DOC files)

[Quintus]

Jappus,

Please don't get me wrong. I am extremely pleased with this app as I have stated in many of my posts thus far as I am an avid ebook reader. Your app has, in fact, replaced eReader via Classic. I was, however, REALLY looking forward to the "auto-scroll" function but I guess I assumed that it would "scroll" the text like it does in eReader by scrolling the text upwards based on certain speed choices. The auto-scroll you have implemented here doesn't really do that. It is a very different user experience than a true auto-scroll.

Is there any way that true auto-scrolling can be achieved in a future version?

[Quintus]

Originally Posted by prubin

Sorry, I don't see it.

Prubin,

Scroll down to the very bottom of the preferences. You will see a number on the left hand side with the words "AUTOSCROLL LINE/MIN". Hit that area and you can change the number.

[DangerousDan]

I can finally read my DRM protected eReader ebooks on my Palm Pre! Maybe one day eReader will get its *** in gear and release an eReader app for WebOS that will let me manage my bookshelf and allow OTA purchasing & downloading. They have an app for iPhone & Android but are happy to leave their core customer in the dust. Anyone else remember when eReader was PeanutPress and they only published for the Palm platform?

Anyway, thanks for reading my rant and THANK YOU developer for this app!

[conum]

I did it again, cleared .app-storage from all preader-mentions and installed newest version.
Three .pdb were read in, I could set metadata, read them.
Then I tried a mobipocket-formatted .prc-file.
It loaded very slow, the blue progress bar grew until about 70% - then I saw the palm logo - reset - starting preader over - library is gone, preader stucks, does nothing.
Now I will delete preader again and never ever install it again before it's version 0.9.9

[Jappus]

Originally Posted by Quintus

Prubin,

Scroll down to the very bottom of the preferences. You will see a number on the left hand side with the words "AUTOSCROLL LINE/MIN". Hit that area and you can change the number.

Additionally, when autoscroll is on, you can tap the two arrows in the belt bar to adjust the speed.


As for your question regarding autoscroll, well, I think that the autoscroll I implemented is actually quite superior compared to an autoscroll that scrolls the entire page. With the latter, you have the problem that the lines keep moving while you read them. If you look away for a moment, you have to find your position again. If you want to re-read the previous sentence again, you also can't skip back to where it was, since it already moved.

Additionally, when you read a real book, you don't read it while moving the page. You read it while moving your eyes. That's the reason why many people can't read books / newspapers while riding a car, a bus or (old) trains. It is virtually impossible to keep the book level. But your eyes can only compensate for so much movement. And even small compensations can quickly tire you.

There are a lot of reasons why many eBook readers implement autoscroll the way I've implemented it, if they implement it at all. ReadThemAll and Tibr for PalMOS did that, for example, despite the fact that "my" way is actually much more complex to implement. Of course it's unusual at first, but most readers quickly appreciate not having to constantly move their eyes. Just give it a spin.


Smooth scrolling is very nice for the web or images, but if you look at it closely, it's actually an inferior solution for books. Just ask yourself: When you read a column of text in a web page with the WebOS Browser, what do you do? Do you constantly scroll, or do you wait till you've finished a block of text till you scroll again?

I know that I do the latter.

[Jappus]

Originally Posted by conum

It loaded very slow, the blue progress bar grew until about 70% - then I saw the palm logo - reset - starting preader over - library is gone, preader stucks, does nothing.

Could you send me the MobiPocket file in question, or provide me with a link to where you've downloaded it from?

Because that would really help me debug that problem. After all, the MobiPocket importer is brand new; which explains both its slowness and that there still might be some bugs for some files.

[Quintus]

Originally Posted by Jappus

Smooth scrolling is very nice for the web or images, but if you look at it closely, it's actually an inferior solution for books. Just ask yourself: When you read a column of text in a web page with the WebOS Browser, what do you do? Do you constantly scroll, or do you wait till you've finished a block of text till you scroll again?

I know that I do the latter.

This is a very interesting debate. I can tell you that I first began reading ebooks via the eReader which scrolls the page upwards. This is what first sold me on ebooks and I've never looked back since. I've converted others who were book worms and swore they would never read an ebook and are now hooked. The scrolling feature was always the number 1 reason they converted to ebooks.

I wonder how many others feel the same way I do about the scroll feature? I'd love to hear others chime in.

Having said that, however, is it possible to implement a smooth scrolling feature in WebOS? You've done so much with this app that I feel bad asking you to implement yet another feature, but is this doable as an option?

[rboatright]

Originally Posted by Jappus

I think I've tracked down the reason for the reported slowness. I couldn't exactly reproduce it for page-changes, but I could reproduce it for opening the files. The main problem is, again the Mojo.Depot API. It appears that whenever you open a Depot-DB, WebOS reads the entire file. Which can take a while given that the Book-DB of the pReader can easily reach several tens of megabytes with even a modest number of books.

So to recapitulate: The Depot API needs somewhere between 5 and 50 times the amount of space to store anything. It never deletes anything; not even when you delete the app. You can't get a list of what you've stored in your DBs. It always loads the entire DB at once. And so on.

Ohh, and the best is: Those who developed this traffic accident of an API thought it's good enough to be the only way to store bulk data on WebOS. Who needs files, afterall. I mean, just because access to them is fast, flexible, resource conserving and simple, that doesn't mean anyone needs them, right?

But enough ranting. Afterall, it doesn't exactly help now, does it?

Well, it does, actually.

Depot sucks. Quit using it right away. Use sqllite instead. Sqlite actualy deletes records when you tell it to, does not massively inflate records, etc etc etc. It's JUST sql. No big deal. I strongly urge you to abandon depot and switch to sql instead. Tables just aren't THAT hard.

If you want help, just ask.

[Jappus]

Originally Posted by rboatright

Depot sucks. Quit using it right away. Use sqllite instead. Sqlite actualy deletes records when you tell it to, does not massively inflate records, etc etc etc. It's JUST sql. No big deal. I strongly urge you to abandon depot and switch to sql instead. Tables just aren't THAT hard.

I know, after all I studied Database Design as one of the main topics of my diploma courses.

But I assumed that Depot is just a fancy wrapper around JSON + HTML 5 databases anyway. Well, that's probably what you get for trusting the Palm API docs.

So well, I think I got the next big step for the pReader: Moving from the Depot backend to the SQL backend. Thanks!

[rboatright]

Have you looked at the gsunzip.js files in JSXgraph, a pure javascript implementation of unzip?

Again, I think you might be pleasently surprised.

Give it a shot!

JSXCompressor – zlib compressed JavaScript code « JSXGraph


Rick

[rboatright]

Originally Posted by Jappus

I know, after all I studied Database Design as one of the main topics of my diploma courses.

But I assumed that Depot is just a fancy wrapper around JSON + HTML 5 databases anyway. Well, that's probably what you get for trusting the Palm API docs.

So well, I think I got the next big step for the pReader: Moving from the Depot backend to the SQL backend. Thanks!

Depot IS a wrapper around sqlite, but it's a STUPID wrapper, not a FANCY wrapper. It has all the disadvantages you list, plus more.

Basically, it takes any javascript object you hand it, does a toJSON on it recursively, and stores it as a blob. it may be the silliest thing I've ever seen. The html5 calls to sqlite are _simple_ I don't understand why they built the depot at all.

[Jappus]

Originally Posted by Quintus

Having said that, however, is it possible to implement a smooth scrolling feature in WebOS? You've done so much with this app that I feel bad asking you to implement yet another feature, but is this doable as an option?

Sure. It complicates a few things, but it's possible. Afterall, the scrolling mode you're used to is actually vastly simpler than the one I implemented. (Which is, if you ask me, still the only thing that's actually better about it. )

I think I'll add it as an optional mode in the next version. But please understand that I'll first concentrate on getting rid of the Mojo.Depot and since this will most likely break the current library, I want to make sure that the next update's going to a big one.

So it's going to take a while.

[remmysmom]

I just downloaded the update and now when I go into preader all my books are gone. I tap on the add book to library and nothing happens. It is like the program is frozen. I have closed and re-opened several times and still nothing. It won't let me add, and it isn't loading my books. Anyone else having this issue?

[Jappus]

Originally Posted by rboatright

Have you looked at the gsunzip.js files in JSXgraph, a pure javascript implementation of unzip?

Again, I think you might be pleasently surprised.

Give it a shot!

I've stumbled upon it while I searched for a JS Zlib implementation. Unfortunately it's not exactly built in a way that makes it easy to extract only the decompressor parts of it (they compressed the JS source so that it calls functions with such beautiful names as a(), b() and c()). And I really, really, don't want to plonk it as-is into the pReader. That, and I had read reports on it not being exactly fast, something around the magnitude of < 5 kB/s decompression speed.

But well, I'll take a second look at it as soon as I'm done with the other issues.


Thanks again!

[conum]

Originally Posted by Jappus

Could you send me the MobiPocket file in question

i will attach it here ....
doesn't work with .prc-file, i will zip it ...

[conum]

now it works

[remmysmom]

I uninstalled and re-installed the program and now am adding to the library. Is there a max number of books you can have in the library? I had 6. I only added the book I was currently reading until I can validate what happened. Thanks

[Jappus]

I think it's clear now that pretty much all the problems can be reduced to the failings of the Depot-API.

The next version will use the SQLLite interface, as recommended by Rick. Until then, the only sane workaround is to limit the number of eReader and MobiPocket books you're using. Interestingly enough, since plain-text files like TXT files and PalmDOC files put less demand on the Depot, you can add a lot more of them.

[tamvegas]

Originally Posted by remmysmom

I just downloaded the update and now when I go into preader all my books are gone. I tap on the add book to library and nothing happens. It is like the program is frozen. I have closed and re-opened several times and still nothing. It won't let me add, and it isn't loading my books. Anyone else having this issue?

I had that at first too. I restarted Luna and it's been working fine (actually much better!). There was a quirk before where I had to open another program (a pod reader) and close it before Preader would load properly. That no longer happens on this update.
I've added several books to the library since the update without issue. There's about 30 in my Library right now.

[rboatright]

Originally Posted by Jappus

I've stumbled upon it while I searched for a JS Zlib implementation. Unfortunately it's not exactly built in a way that makes it easy to extract only the decompressor parts of it (they compressed the JS source so that it calls functions with such beautiful names as a(), b() and c()). And I really, really, don't want to plonk it as-is into the pReader. That, and I had read reports on it not being exactly fast, something around the magnitude of < 5 kB/s decompression speed.

But well, I'll take a second look at it as soon as I'm done with the other issues.


Thanks again!

I'll send you the uncompressed source.

I found it a couple of weeks ago.

and 5kb/s is not intolerable if it's a one-time thing. "This file is going to take about 3 minutes to import. Do it now? "

:-)

Rick