pReader (an eBook Reader for Palm-DOC files)

[astracan]

Excellent work. Is there any possibility of scheduling autoscroll?. I'm used to Tibr application to read books, because it weighs very little and has a good autoscroll, but can not find anything similar to the pre palm.
Thank you very much for this application is very good.

[Veritas06]

Great so far, I love the library! I know this isn't a big issue at all (i'm a little OCD about stuff) but is there anyway to have the books imported without the %20, or a way to edit the info (title / author)?

Again, I know you have more important things to handle, more than asthetics. Thanks again for the great app!

[Jappus]

Originally Posted by astracan

Excellent work. Is there any possibility of scheduling autoscroll?. I'm used to Tibr application to read books, because it weighs very little and has a good autoscroll, but can not find anything similar to the pre palm.
Thank you very much for this application is very good.

I'm indeed currently implementing a number of different scroll modes based around tapping, flicking, key-presses and the accelerometer.

At the moment, they're all still based around "one-page-at-a-time" scrolling. But a good auto-scroll shouldn't scroll that way, because the change could happen when you're still in mid-sentence. A good auto-scroll also shouldn't scroll line-by-line where the entire document slowly moves upward. That simply causes too much eye-strain.

The ideal auto-scroll replaces the lines one after another. Imagine it as the current page lying on the table while the new page is slowly unfolded, line-by-line over the current page, starting with the top. If you can't imagine it, I could fabricate a Photoshop-Mock-Up. But basically, you should already know it from Tibr

In any case, that way, your eyes always see a stable page and only need to jump when you reach the end of the page and skip to the top of the page, where the new page is already waiting for you. You don't need to adjust mid-sentence, or wait for the whole page to reload to continue reading. All you need to adjust is the scrolling speed which only needs to equal your average reading speed over an entire page, so you're not overtaken by, nor overtake the scrolling page-break. And that speed is usually very stable and usually only needs to be slightly adjusted.


Unfortunately, WebOS / Javascript only allows you a very limited interaction with the screen. Basically all you can do is draw stuff on it, and then ask how high/broad it is and where the lower left corner of the entire block was placed. That's all. And even that has some caveats, I won't mention here.

Of course, that makes the above auto-scroll mechanism very hard to implement, because with it, you need to "nail" a line of text to a given position; irregardless of what happens above it. Combine that with rich-text and images and you can see that it's quite a non-trivial problem.



I've already thought long enough about it, that I indeed plan to implement that auto-scroll mechanism. It simply will take a while to do it, that's all.


Of course, if anyone of you has a brilliant idea, nobody stops you from checking out the sources from the SVN repository and start experimenting. I certainly won't be shy to accept such patches and properly attribute them. The more, the merrier!

[Jappus]

Originally Posted by Veritas06

Great so far, I love the library! I know this isn't a big issue at all (i'm a little OCD about stuff) but is there anyway to have the books imported without the %20, or a way to edit the info (title / author)?

I'm currently working on that. The basics for full metadata are already there, afterall, I have to store the name, percentage and category somewhere.

I contemplated withholding the release till I fully implemented editing of the metadata, but then decided against it, because as you said, testing if it works now is more important than waiting and withholding it till it's perfect. Release early, release often, as a certain wise man once said.

One of the next releases will contain the option to fully customize the metadata and the display. Additionally, some formats, like the eReader PPrs format, already contain metadata that I currently ignore, but plan to import & use in the future.


It's all in the works, but as I said in the first post, I'm currently working on a "spare-time" schedule, so it takes me a while to get there.

[barrylee]

Hi
Palm pre supports Korean and already has Korean font.
But pReader cannot display UTF-8 encoded Korean text file.
You can get the test UTF-8 file from this link

http://www.gncomputer.com/utf8Korean.7z

and the file should be displayed as follows
http://grab.by/Kg8

Thank you.

[Jappus]

Originally Posted by barrylee

Hi
Palm pre supports Korean and already has Korean font.
But pReader cannot display UTF-8 encoded Korean text file.

I'll look into that. If I can fix it, it'll be in the next version, along with a slew of other updates.

[Jappus]

Okay, I've examined the problem now, and unfortunately it's too fundamental to be fixed right in the next version. The reason is simply, that the problem has nothing to do with the pReader, but rather with the WebOS Javascript API.

As you know, the pReader is written exclusively in Javascript, and as such it is rather difficult to read files; especially binary files. What I do is to create an XMLHttpRequest for the file and force it to use an 8-Bit encoding.

And at that point the problem occurs. For most files this works fine and the JScript engine does what I want. But your file somehow trips it up -- it first removes half of the file and then completely butchers all non-ASCII characters in the file. That's why the "UTF-8" string in the file is pretty much all that survives.
It seems to me as if there's a certain byte sequence that totally confuses the XMLHttpRequest handler, and that that byte sequence is contained within the Korean UTF-8 block.


Since I can't influence that behaviour of the XMLHttpRequest (which is the same in IE, Safari and Opera -- only Firefox doesn't butcher the file), I can't currently fix that issue, since it happens before I can get even a single byte from the file.


I am afraid the problem has to persist till either Palm adds proper file access to the API, or till (if at all) I write my own Java-Backend for the pReader.

Sorry.

[barrylee]

Uhmm. It's strange. Korean web sites using UTF-8 encoding works well with XMLHttpRequest. If there is any problem, it can be the bug of the WebOS or some other reason. I haven't seen any problem with Korea UTF-8 sites and files.

Can you report it to palm or give me some information to ask them by myself?

[Jappus]

Originally Posted by barrylee

Uhmm. It's strange. Korean web sites using UTF-8 encoding works well with XMLHttpRequest.

Do you mean that you can open Korean websites with the Pre's browser and they work fine, or that you've used the Mojo-API's XMLHttpRequest implementation to fetch a Koren page/file and it rendered fine?

Because if it's the former, that it works there is simply because the browser itself is not limited by the XMLHttpRequest interface, because that's strictly for Javascript. The browser itself has a far better access to the web than it offers to JS through the XHR interface.

If there is any problem, it can be the bug of the WebOS or some other reason. I haven't seen any problem with Korea UTF-8 sites and files.

Well, the bug, if it is one, is pandemic in that case, because it applies to all browsers except Firefox. All of them truncate and butcher the file if I tell the XHR to get me the plain text of the file.

I've attached a minimalistic test program / script / html page that shows the problem on all browsers, including Safari which uses almost the same engine as the Pre (or rather, it's the other way around).

Extract the zip and then simply open the "test.html" file. It should display a hexadecimal representation of the content of the file. It works in Firefox but nowhere else. But only Korean makes such extreme problems. Opening a binary file like a PalmDOC pdb works [1], not in Opera and IE, but in Safari, and thus also on the Palm Pre.

[1] - But keep the file under 50k, since this implementation is not optimized and thus slow.

I tried to fiddle with the settings of the XHR Request, especially the mime-type/encoding, all to no avail. I simply could not convince it to not truncate the file. But well, extra eyes looking into it would be helpful.

Can you report it to palm or give me some information to ask them by myself?

The above test case, plus your Korean UTF-8 file (it's in the zip) should be enough. Ideally, opening the above HTML file in the same folder as the "UTF8Korean.txt" file should print out a hexadecimal encoding of the file.

It works under Firefox, but it croaks everywhere else.

[Jappus]

Good news everyone!

I just release the new version v0.6.1.

The changelog is:

• Fixed an error with the rich text display of eReader files.
• Implemented more ways to change the pages.
• Added an option to select the default file-encoding type
• Added support for CP-1252, it is now the default for new files
• Added option to select a fixed landscape mode
• Added a loading progress bar.
• Added experimental eReader DRM support

Please test the DRM support extensively. It should work with almost all DRM formats an eReader file can be in. We tested it both with very new, and very old files (> 6 years), but we can't be sure that there isn't an exotic problem somewhere.

Of course, since it's experimental, it's still rather slow. It can take minutes till the file is added, so I added a progress bar that should keep you informed.


Happy reading!

[Quintus]

Wow!!!! I can't believe we actually have a native ereader with support for DRM formats. Thank you....thank you....thank you!

[satoribomb]

Man! - I have been aching for a way to read my encrypted eReader files on the Pre that doesn't suck (read: eReader on classic). My only concern is that I have a huge library dating back almost 10 years, and pReader doesn't display the entire list of books, articles and short stories when I open the "Add an ebook" dialog. The file list just goes blank arter the first 200 or so files it finds. I've got about 450 ebook files on my Pre, and many of the titles I'm trying to add don't show up in the "Add an eBook" dialog.

Is this an imposed limit or an error with the code? Let me know so I can either wait for a fix or figure out a way to manage my ebooks, given the limitations.

Either way - fantastic job sir - you've made my Thanksgiving!

[satoribomb]

Oh yeah - tried the DRM import and it went flawlessly! Thank you again!

[Jappus]

Originally Posted by satoribomb

The file list just goes blank arter the first 200 or so files it finds. I've got about 450 ebook files on my Pre, and many of the titles I'm trying to add don't show up in the "Add an eBook" dialog.

Is this an imposed limit or an error with the code? Let me know so I can either wait for a fix or figure out a way to manage my ebooks, given the limitations.

The problem lies within the FilePicker widget that I have to use. It's part of the WebOS-API and the ONLY way to select files on WebOS ... at least without writing a custom Java Service as a backend (which are not supported by Palm's official AppStore).

The problem with it is that it's insanely limited. It has no support for folders - it just scans everything in /media/internal. It only allows filtering according to file extension [1] or a broad type category (audio, image, video, file). And I think that you have just discovered that it also limits the number of files that are displayed.


I'll see what I can do to fix your problem -- even if the fix will most likely be a workaround, since the only way to really fix the issue is to ditch the FilePicker for something better ... which currently doesn't exist.


[1] - I currently filter the extensions: TXT, PDB and PRC. There's no case-sensitivity, by the way.

[mbarashkov]

I'd like to add some features like FB2 format support and information bar on the bottom of the screen stating position in file, bookmarks in the future etc.
How can I get SVN access to commit? I don't want so much to fork off the project.

[conum]

I've installed the latest (0.6.1) version of preader. I imported some .pdb-files in library and tapped on a .prc-file, preader said, this format isn't supported. When I go back to add another file to library, tapping again on a .prc-file, preader gets stuck and does nothing more. If i try to leave the app, there's an empty screen on the card that I can swipe away, but my pre stucks, I have to reset.
If I remove preader within preware, it seems still to work in background and my battery goes down rather fast.
I tried this procedure twice to be sure.
Btw the library of preader seems to stay on my pre even if I removed the app. When installing it again, the library is still there.
Don't like it how this app let my pre get stucked.
And: How to get rid of the library?

[Jappus]

Originally Posted by conum

I've installed the latest (0.6.1) version of preader. I imported some .pdb-files in library and tapped on a .prc-file, preader said, this format isn't supported. When I go back to add another file to library, tapping again on a .prc-file, preader gets stuck and does nothing more.

Mhhhm, that indeed seems to be a bug. I'll try to reproduce it. If I can find it that way, I'll fix it. Of course, there's an off-chance that it has to do with the unsupported PRC file you used. If I can't replicate it, would you be willing to send me the unsupported eBook so I can test that case?

If i try to leave the app, there's an empty screen on the card that I can swipe away, but my pre stucks, I have to reset.

Yeah, that's a problem with Javascript. If the app crashes hard in a way that it uses 100% of the CPU and does not relinquish control to WebOS, but also doesn't trigger the hangcheck of WebOS (which shoots down Javascript threads that run too long without returning control), the app can't be closed. As in: At all.

The only solution is to either restart, or selectively kill the "LunaSysMgr" process, in which case only Luna (the WebOS GUI) starts again, without needing to restart the Pre completely. Of course, you need terminal access for the latter, but I digress.

Ideally, my program shouldn't crash that hard, but Javascript offers almost no error handling capabilities, so I have to weed out the hard crashes manually. Well, there's a reason why this program is still Beta-level software.

If I remove preader within preware, it seems still to work in background and my battery goes down rather fast.
I tried this procedure twice to be sure.

The reason for that is, that Preware only removes the program files and tells WebOS to shut down the app. But if WebOS can't shutdown the app, it keeps running. Reinstalls don't change that. If a JS application crashes that hard, a full restart is unfortunately the only viable (as in easy) option.

Btw the library of preader seems to stay on my pre even if I removed the app. When installing it again, the library is still there.
Don't like it how this app let my pre get stucked.
And: How to get rid of the library?

I'm sorry for your problems. I too have already noted that WebOS is very lazy as far as removing databases is concerned. Basically, if I delete an entry, it is not actually deleted. All the data remains and WebOS only marks them as deleted. Also, WebOS offers no way to delete a database. The best I can do is to replace it with an empty one or delete all the entries it contains. But either way, all it does is to mark all the current entries as deleted, without actually deleting them.

The only positive fact is that I observed that WebOS reuses the deleted space, but the file itself is never actually shrunken. If I add a book, delete it, and then add it again, the file size of the database does not increase. WebOS simply reuses the old space.


There is a way to delete the database, though. Manually, at least. Since it's stored on the media-partition, all you have to connect your Pre to a PC, and delete the "file_.var.usr.palm.application.com.mhwsoft.preader_0" folder in the hidden ".app-storage" folder.

If you've installed "Internalz" file browser, you can delete the folder from the device by going into "/media/internal/.app-storage", even without connecting the Pre/Pixi to a PC.


The problem I face is that I have no control at all over what WebOS does with its Depot-databases, and no control over what databases are removed when the app is removed. For example, I know that it removes all internal databases and the program files, but not the program folder and external databases. Additionally, WebOS does not inform my app when it's about to be deleted (the old PalmOS did!), so that I can't even clean up after myself.


So your best option is to manually remove the files. That's a problem all WebOS apps share, only that the pReader (and its counterpart the PalmReader) are pretty much the only ones that actually use the Depot to store large amounts of bulk-data.


As such, I'm of course deliberating what to do, but as of yet, no brilliant idea offered itself to me.

[Jappus]

Originally Posted by mbarashkov

I'd like to add some features like FB2 format support

Yay!

If you feel up to the task, pretty much all you have to do is to implement the "ByteReader" interface, and accept a File object (which itself already implements the ByteReader interface) in your constructor. The output can then be either plain-text or HTML, encoded as an array of bytes.

Writing a new format can thus be kept independent of every other aspect of the app. In the future, you'll probably also have to offer optional functions for things like metadata retrieval (Book name, author, etc.) and image-data support. But the specifics will be determined later. At the moment, the above is all you need to implement a new format.

As an example, simply look at how the DocReader and PPrsReader classes are currently built, and how the Library-assistant interacts with them.

and information bar on the bottom of the screen stating position in file, bookmarks in the future etc.

Adding an optional belt-bar is already planned for the next versions. I already have some very specific ideas of how to implement them.

How can I get SVN access to commit? I don't want so much to fork off the project.

Well, getting write access chiefly consists of asking me, and having a SourceForge account.

But at the moment, I would ask you to develop a patch-set instead of writing to the SVN, because we're currently experiencing problems with the SourceForge SVN servers. Namely, that they're utterly slow. I've already written a mail to SourceForge, and if they can't solve the issue, we'll probably migrate to another repository host.

In any case, developing a new format should also work if you don't have write access to the SVN, because, as I said, it's almost completely independent of the other parts of the application.

[davis.rob]

Originally Posted by Jappus

Please test the DRM support extensively. It should work with almost all DRM formats an eReader file can be in. We tested it both with very new, and very old files (> 6 years), but we can't be sure that there isn't an exotic problem somewhere.

Of course, since it's experimental, it's still rather slow. It can take minutes till the file is added, so I added a progress bar that should keep you informed.

Just tried it with the one eReader DRM book that I have and it seems to work well. As you say, a little slow to start with, but it works. Very impressive ... I didn't think that was really possible!! Thanks again.

[hankbuddy]

Hi,

Thanks for the great app. My one (hopefully) simple request would be to make the swipe gesture for turning pages reversible. It seems more intuitive to me to swipe from right to left to go forward in the book, as I would if turning the pages of a physical book. Although I must say I am liking the tap method of turning pages more than I thought I would.