pReader (an eBook Reader for Palm-DOC files)

[Jappus]

Originally Posted by PapaNoHair

I am drawing from memory so I might be wrong but wasn't the date for us to be able to open files larger then 10 mb going to be available this month?

Yeah, that was the plan. Unfortunately, three things conspired against us:

1. Both Retrobits and I are swamped with pReader unrelated work. Currently, my Thesis eats far too much time.
2. The PDK is still in Beta and the support for mixed Javascript/Native apps is horrible, to put it lightly.
3. You can't upload PDK-enabled apps to the App Catalog yet. So even if we'd be ready by now, Palm would still say: "Nyuck, nyuck, please try again later."

Basically, I currently work on fixing the last few formatting issues, adding translations to the pReader (Spanish and German are already done!) and implementing a few other minor, but nifty features. Hopefully, I'll be done with that in the next few days.

After that, I'll concentrate on the transition to the PDK. Of course, since there's still my thesis, I can't say how long that will take. But well, even a journey of a thousand lines of code starts with a single instruction.

[Jappus]

Originally Posted by jmesseder

Back to the "Reading file" error. It was working great until I installed the 800MHz overclock. Now all my apps work EXCEPT pReader. The pdb I was reading - first of the Mossy Creek series, still showed 4% into the book, but will no longer display the book. I uninstalled pReader, power-off reset the Pre, reinstalled pReader, deleted my books and re-copied them from my PC. I added Omnivore's Dilemna and was asked for the credit card name and number, which pReader accepted, but displays the same Reading file screen when I try to load the book. I have webOS 1.4 installed.

Well, the pReader makes extensive use of timed and untimed callbacks. Basically, it means that it relinquishes control to the WebOS, but tells it to execute a certain function immediately afterwards (or after a delay). A function that is instructed to notify another part of the app as soon as it's done.

All this just to prevent WebOS from killing the app because it consecutively ran for more than 2.5 seconds.

And here's the rub: It's distinctly possible that the 800MHz overclocking patch throws a big spanner into these intricately interlocking gears, causing everything to violently explode. Maybe it eats the timed callbacks because time now moves faster for WebOS, or maybe the CPU can't reliable work at 800MHz or maybe it simply causes the hangcheck to trigger after 1.5 instead of 2.5 seconds. Afterall, almost no other Javascript app on WebOS needs THAT much processing time and is therefore so highly dependent on tricking WebOS into not shooting it down.


In other words: I can't guarantee that the pReader will work on an overclocked device. All I can test for is whether it works in the WebOS Emulator and on a non-overclocked device. Sorry.

[Jappus]

Originally Posted by Pr3Lov3r

I did, however, notice an interesting occurrence. Once I loaded all three of them along with my eReader info to "activiate" them, I opened them to make sure they were really there...then closed the app. I then reopened preader and all my books were gone. I had to individually add them to library all over again, along with my my eReader activation information for each one. This time, I decided to open each book, scroll several pages into each and bookmark a point in the three books. When I closed and opened the app the next time, each book was still listed in the library. Anyone else ever experience this?

Mhhhm, early versions of the pReader had issues with the library not being stable and books vanishing into the ether, but I haven't heard such a report for several revisions now. Can you please check if you have the most recent pReader version installed?

If you have, then could you please watch this issue and tell me if it happens again, and if, under what circumstances? After all, maybe there's still a certain sequence of actions that triggers the lossage. Thanks.

[Jappus]

Originally Posted by beans

Feature Request - An option I'd really like to see is the ability to control how many linebreaks are generated on the screen when there is a linebreak in the document. For example, I have many PDB files that have a single linebreak after a paragraph, but I find it much easier to read on the Palm if there are two linebreaks after a paragraph. Being able to modify this in the reader would be much easier than modifying the PDBs. At least one, if not more, of the text readers I used on my Palm Tungsten had this feature.

Mhhhm, yes, such a feature should be possible. It should even be comparatively easy to add such an option, since all we have to do is to remove or add a given number of line breaks to every consecutive run of them.

I've just added it to my ToDo list, and if it turns out to be more or less trivial to implement, it'll appear in the next version.

Thanks!

[Pr3Lov3r]

Originally Posted by Jappus

Mhhhm, early versions of the pReader had issues with the library not being stable and books vanishing into the ether, but I haven't heard such a report for several revisions now. Can you please check if you have the most recent pReader version installed?

If you have, then could you please watch this issue and tell me if it happens again, and if, under what circumstances? After all, maybe there's still a certain sequence of actions that triggers the lossage. Thanks.

Hello there!
Thank you for your quickness in responding to my situation. I only downloaded PReader yesterday (last night actually) from the app catalog. When I check in device info, it tells me that I have version 0.8.3. I will certainly keep a watchful eye and let you know if this happens with the next book(s) I add to my library.

Thanks again! I really appreciate your promptness in responding to my concern. Great app and great customer service, I'm very happy.

[hooliganhjp]

Love preader. but some of the mobipocket files have character problems. the files get like foreign language fonts

an a with ^ above it
a E that is curved with multiple horizontal lines.

not on all prc files but many

[zdar01]

while using this wonderful app (0.8.3) I have run into several things which are annoying...
- the file selection dialog shows too small part filename, either smaller font or landscape mode would help
- file conversion:
- once file selected for import there is no way to cancel process. this is highly unfortunate as import takes long time and "time is money"
- there should be a way to "disable" html/plaintext question for conversion. something like text/html/auto in preferences would be welcome (autodetection should be easy / just look for <> at first part of text)
- backswipe during text/html selection dialog does not go back to file selection but startes conversion
- import on background would be nice
- charset of book title is still wrong...
- book with no title in library could not be read nor deleted

[Jappus]

Originally Posted by zdar01

- the file selection dialog shows too small part filename, either smaller font or landscape mode would help

That's a limitation in the Palm SDK that can't be circumvented. The only option we have is to switch to the Palm PDK, something which we indeed plan to do soon. Unfortunately, as I've outlined above, there are certain hurdles in that path.

- file conversion:
- once file selected for import there is no way to cancel process. this is highly unfortunate as import takes long time and "time is money"

Just close the pReader. That aborts the import process and as long as you eventually import the file, it doesn't cause any waste of disk space.

But I'll think about whether it's feasible to add a separate cancel button.

- there should be a way to "disable" html/plaintext question for conversion. something like text/html/auto in preferences would be welcome (autodetection should be easy / just look for <> at first part of text)

Yeah, an option to disable it is a good idea. As for the whole autodetection, well, that's not really easy to do, because not all of those files start with "<html>", some simply sprinkle in their tags without any root elements. Furthermore, some of those files even start with a plain-text block of metadata and only later begin with actual rich-text.

All in all, autodetection would only be mostly reliable, and that's the quality of hacks, not of actual solutions.

But the option to disable it will be in the next version.

- backswipe during text/html selection dialog does not go back to file selection but startes conversion

Yeah, a cancel is treated as if you selected the Plain-Text mode. Back when I implemented it, I thought it was a good idea. But well, perhaps it's really better to treat it as an actual canceling.

But do note that even then, a backswipe will not take you back to the file selection, it will take you back to the library. That's because the file selection dialogue is actually an external app that is called, and as soon as that's goen away, you can't return to it, you can only re-open it.

- import on background would be nice

Yeah, but that's big version of Pandora's box. On the surface it's really nice, but it leads to several extreme problems. For one, real background tasks are even more restricted than foreground tasks as far as processing time is concerned. Furthermore, since import tasks eat so much processing power, you really wouldn't like the UI response with a backgrounded task. It would be like watching a dia-show. For example, a tap would take several seconds to actually do anything. And amazingly enough, there's a paragraph in Palm's User Interface guidelines about that. It basically says that whenever you start a time-consuming task that shoots down the UI performance, you should offer a progress bar and lock the UI, instead of subjecting the user to an atrociously stuttering user interface.

On top of that, there's a whole heap of issues that comes with the inherent parallelism. For example, at the end of the import process, the importer refreshes the Library screen for you. But what happens when you've already left the library screen? What if you've opened the File Selection dialogue that's, as I've stated above, pretty much an independent app? Not to mention the icky details of what happens to parallel writes...


All in all, while it would be nice, it would also be an enormous headache and a horror to implement in JavaScript. JS simply is not meant for parallel processing, it's both too slow and to simple for that.

- charset of book title is still wrong...

I'll take a look at that. But you could greatly help me if you could send me a file with a title that's stored in a different charset. After all, I can only "fake" this by manually creating such files.

- book with no title in library could not be read nor deleted

Mhhhm, can you tell me what you did to create a book with no title? Because I really tried hard to plug all the holes that allowed this to happen, but obviously I've overlooked a few.


Thanks!

[Jappus]

Originally Posted by hooliganhjp

Love preader. but some of the mobipocket files have character problems. the files get like foreign language fonts

an a with ^ above it
a E that is curved with multiple horizontal lines.

not on all prc files but many

Can you send me such a file, or provide a link to one? That would really help me to debug the issue.

Apart from that, have you tried changing the character encoding to UTF-8, or CP-1252? Because MobiPocket books can be stored in either encoding. That would neatly explain why only some of your files exhibit that problem.

[Jappus]

Hello everyone.

I just wanted to point out that I've just fixed a really nasty error with the eReader import code. I don't know who it was who pointed it out for me (and I can't find it anymore in this thread) but much kudos go to him or her for doing it.

Basically, he (or she) told me that you couldn't unlock a DRMed eReader document if you once typed in a wrong username / password combination. At least, not until dismissing the dialog and trying it again, or by deleting the username and password.

This led me to look closer at what might produce such a weird error, and I found out that it had nothing at all to do with the dialog itself, but with the decryption algorithm that we use! Because whenever you entered a new username/password combo, it appended parts of the old decryption key to the newly generated one, which of course led to total mayhem!


This is most likely the reason why so many people had problems with their eReader codes. Basically, even if they entered the correct key, the pReader would say that their key doesn't work, and it would only work again once they completely dismissed the dialog and started from scratch. A thousand thanks again to the user who pointed out that error, for I'd have never found it myself!


Anyway, the bug will be fixed in the next 0.8.4 version and I plan to release it very soon.

Sooooo, any last minute feature requests anyone?

[goldyman]

while you're at it...the ereader indent-import bug???

[Funsh]

Very soon sounds great
I am waiting for the fixes regarding the ePub import.

But then i don't have any excuses anymore to not read the books i have currently on my hard drive.

[Jappus]

Originally Posted by goldyman

while you're at it...the ereader indent-import bug???

I'm on it. It's one of the last four ToDos on my current list. It's such a simple, but at the same time nasty bug, because I've found out that the pReader simply eats the relevant tags. One moment they're there, the next moment they're gone. I'm more and more convinced that the pReader has reached a level of sophistication where it has gained the "washing machine" perk. You know: Eat 1d4 socks once per day.

Originally Posted by Funsh

But then i don't have any excuses anymore to not read the books i have currently on my hard drive.

Heh, I'm afraid that it's not just TVTropes that will ruin your life...

[Jappus]

Good news, everyone!

I've just submitted the new v0.8.4 revision of the pReader to the App Catalog. Those who can't wait can, as always, download the ipk file from the first posting in this thread.

Here are the changes in this version:

• Added ability to go back to the last position after you clicked a link.
• Fixed several ePub and eReader import problems.
• Added internationalization support. pReader now comes in English, German and Spanish.
• Fixed the indentation bugs that plagued the eReader format.
• Added a Password Database
• Fixed a very nasty DES error that prevented eReader files from being opened after the first invalid try, even if you entered the correct credentials. You had to abort & retry the import for it to register the correct credentials.
• Added option to default to plain-text for PalmDOC files.

The most requested, and most important new feature is colored in red. Unfortunately, it might also be the one that will most delay the v0.8.4 release. Why? Because it makes uses of Palm's internal encryption system ... a system that falls under one of the most momentously stupid US-American legal insanity ever devised: The Cold War relic called the Export Administration Regulations part 772.1. Basically, you have to beg them to allow you to "export" anything that contains an encryption system above a certain strength; no matter if that system is publicly known everywhere.

Unfortunately, while this is only a mildly grueling task for US-American citizens, it is an utter nightmare for everyone else -- including poor old German me.

Anyway, it's a distinct possibility that Palm will complain about this release and delay it. In that case, I'll probably have to burden Retrobits with obtaining the necessary magic 6-digit code that's wanted by Palm and given out by the US-Government.



Anyway, in unrelated news, this will be the last Javascript-only version of the pReader, except if there are some serious errors. The next version will be half-native, half-Javascript and will get rid of a lot of drawbacks of the JS-API.

Of course, this also means that the gap between v0.8.4 and v0.9.0 will be ... rather large. But well, every journey starts with a single step.


P.S.:
Do note that I also have delayed to implement the following features that were on my ToDo list for v0.8.4, but didn't make it since they all connect to areas that will be redone in native code anyway:

• Clean up / fix HTML tags
• Import Metadata fields from formats other than ePub
• Add option to add/remove n linebreaks from every consecutive run.
• charset of international book titles is still wrong.

[zdar01]

Originally Posted by Jappus

Just close the pReader. That aborts the import process and as long as you eventually import the file, it doesn't cause any waste of disk space.

Yes I use this way

There is however one issue connected to file dialog and import. Until file is imported I can't be sure if I'm importing right book. It would be nice if book TITLE could be displayed at import time so I could cancel import if wrong bookis choosen...

Originally Posted by Jappus

Yeah, an option to disable it is a good idea. As for the whole autodetection, well, that's not really easy to do, because not all of those files start with "<html>", some simply sprinkle in their tags without any root elements. Furthermore, some of those files even start with a plain-text block of metadata and only later begin with actual rich-text.

All in all, autodetection would only be mostly reliable, and that's the quality of hacks, not of actual solutions.

But the option to disable it will be in the next version.

I think "auto" does not need to be totaly reliable. It just needs to be working most of the time. If it fails then user just disables "auto" in preferences before importing that specific book.

Originally Posted by Jappus

But do note that even then, a backswipe will not take you back to the file selection, it will take you back to the library. That's because the file selection dialogue is actually an external app that is called, and as soon as that's goen away, you can't return to it, you can only re-open it.

Hmm. It is just matter of personal preference... (it should follow by default UI guidelines)

Originally Posted by Jappus

Yeah, but that's big version of Pandora's box. On the surface it's really nice, but it leads to several extreme problems. For one, real background tasks are even more restricted than foreground tasks as far as processing time is concerned. Furthermore, since import tasks eat so much processing power, you really wouldn't like the UI response with a backgrounded task. It would be like watching a dia-show. For example, a tap would take several seconds to actually do anything. And amazingly enough, there's a paragraph in Palm's User Interface guidelines about that. It basically says that whenever you start a time-consuming task that shoots down the UI performance, you should offer a progress bar and lock the UI, instead of subjecting the user to an atrociously stuttering user interface.

On top of that, there's a whole heap of issues that comes with the inherent parallelism. For example, at the end of the import process, the importer refreshes the Library screen for you. But what happens when you've already left the library screen? What if you've opened the File Selection dialogue that's, as I've stated above, pretty much an independent app? Not to mention the icky details of what happens to parallel writes...


All in all, while it would be nice, it would also be an enormous headache and a horror to implement in JavaScript. JS simply is not meant for parallel processing, it's both too slow and to simple for that.

I undertand. Nice - but not feasible due to the technical things...

Originally Posted by Jappus

Mhhhm, can you tell me what you did to create a book with no title? Because I really tried hard to plug all the holes that allowed this to happen, but obviously I've overlooked a few.

By importing in the older version of pReader. So the problems is to get rid of it...


Thanks for your effort to develop this app

[goldyman]

Uh oh. No indents in my eReader books under 0.8.4, either. Have rebooted Pre, deleted database and reimported several books to no avail. Each book looks good in both Classic and in the desktop eReader.

On a brighter note: Keyring database works awesomely!

[Jappus]

Originally Posted by goldyman

Uh oh. No indents in my eReader books under 0.8.4, either. Have rebooted Pre, deleted database and reimported several books to no avail. Each book looks good in both Classic and in the desktop eReader.

In that case, could you send us a test-file where no indentation is inserted? We've tested it with several eReader books and everything but the very smallest files (where the eReader creator does very weird stuff) worked okay.

I've sent you a PM with my E-Mail address. After all, as long as Palm hasn't approved the release, we can still squeeze in a last-minute fix.


[EDIT]
Oh yeah, before I forget it. There's also a certain (if small) chance that we won't be able to properly support the indentation, at least any time soon. The reason is that the "official" eReader apps use a certain set of heuristics to determine when to insert indentations all on their own, even if the file does not specify any indentations. For example, it seems that it always adds an extra indentation after a single-line of centered and bolded text, or when there are two consecutive newlines (an empty line between two blocks of text, in other words).

So basically, to render a file like the official apps, we'd have to guess / reverse engineer those heuristics. There are quick fixes, regular fixes, time consuming fixes, tedious fixes and then there are those fixes that need reverse engineering. Guess which of those take the longest time.

[Jappus]

Originally Posted by zdar01

There is however one issue connected to file dialog and import. Until file is imported I can't be sure if I'm importing right book. It would be nice if book TITLE could be displayed at import time so I could cancel import if wrong bookis choosen...

Yeah, it was one of the more idiotic design decisions by Palm to truncate the name of the listed files in the only dialog that allows access to files from Javascript.

But indeed, a simple "Importing <name> now..." message is pretty trivial to add. The next version (or v0.8.4 itself if Palm decides to be uppity about it) will contain that text.

I think "auto" does not need to be totaly reliable. It just needs to be working most of the time. If it fails then user just disables "auto" in preferences before importing that specific book.

I'll think about it a bit more. Especially since I need to re-do the whole import code for the transition to "native code" anyway.

By importing in the older version of pReader. So the problems is to get rid of it...

Ahh yeah, ensuring cross-version compatibility is not exactly a strong suit of Javascript. And with "not a" I mean "physically impossible for a mortal being". ^_^

[dowish]

Originally Posted by Jappus

Anyway, the bug will be fixed in the next 0.8.4 version and I plan to release it very soon.

Sooooo, any last minute feature requests anyone?

Despite being late to the party, I do have a feature request. Could you add a meta-data field that would contain the series the book belonged to and what number in the series it was? For example, I have the Hitchhiker's Guide to the Galaxy series on my phone. To get the books to display in the proper order I am currently putting HHG (book number) as part of the title. While that works, it doesn't seem like an elegant way to do that. It would be nice if I could just use different display options like are currently available for author/title.

Thanks for you hard work and I can't wait to see what you can do with the 'native' PDK.

[Jappus]

Originally Posted by dowish

Despite being late to the party, I do have a feature request. Could you add a meta-data field that would contain the series the book belonged to and what number in the series it was? For example, I have the Hitchhiker's Guide to the Galaxy series on my phone. To get the books to display in the proper order I am currently putting HHG (book number) as part of the title. While that works, it doesn't seem like an elegant way to do that. It would be nice if I could just use different display options like are currently available for author/title.

Mhhhm, adding a "Series" field indeed sounds reasonable. You see, the problem is for me "how much is too much". If it were an app for a PC, I would simply add a configuration option that allows you to add as many custom fields as you like. But with Javascript, that's an ugly task, and on the device, screen space is always at a premium.

Anyway, to solve your problem at hand, yes there's a slightly more subtle way: You can enter any text you like in the "displayed name" field. While the default is just "%t", which stands for: "Display the title"; and the preset alternatives are "%a - %t" and "%t - %a" for the title separated from the author with a dash as the displayed name; you can enter any string you like.

If you want, you can type in: "%a - HHTG - %t" which would would result (for example) in:
"Douglas Adams - HHTG - So long and thanks for all the fish"
or
"Douglas Adams - HHTG - Mostly Harmless"

And if you want to give them a number without writing several different formatting strings; well, if one of the fields is free, you can simply abuse one (because the pReader quite frankly hardly cares ). For example, if the "Publisher" field is free, simply put a number in it and use:
"%a - HHTG %p - %t" as the code. That would yield you:
"Douglas Adams - HHTG 4 - So long and thanks for all the fish"
"Douglas Adams - HHTG 5 - Mostly Harmless"


It's crude and more or less a "Russian" solution, but it works.