pReader (an eBook Reader for Palm-DOC files)

[benluo]

Why not issue the source code to google code(subversion), sf(subversion), bitbucket.org(mercurial), github(git) or other free public source version control service.

So some contributor can do more when you are not enough spare time.

[Jappus]

Originally Posted by benluo

Why not issue the source code to google code(subversion), sf(subversion), bitbucket.org(mercurial), github(git) or other free public source version control service.

So some contributor can do more when you are not enough spare time.

As I said in the original posting, that is indeed what I plan to do. I'll probably open up an SVN-repository & project on SourceForge.

Currently, I'm coding up the Rich Text Display code, and it's coming along rather well. I expect that it'll be finished within a week. As soon as that is done, I'll publish a version v0.6.0 here and open the repository at Sourceforge.

The simple reason for not opening it right now is that I've decided to do two steps at the same time: Implementing support for a book library, and implementing the rich text display. Unfortunately that means that roughly half the application code is undergoing more or less massive changes and cleanups.


As soon as that is done, everything will be modularized enough to really allow other programmers to add useful patches.

[retrobits]

Hey Jappus, great project, and thanks for making it open source and also for releasing early and often!

I've been an ereader customer for years... back to the peanut press days with a handspring visor.

I've been looking at the DRM support and have been doing some initial work on the user credential verification via SHA. Making some progress, hopefully I'll be able to at least validate the credentials in a few days. After that I plan to start looking at the DES decrypt.

No worries about a shared source repository at this point. I can keep the DRM routines isolated for now. If I get anything working, I'll just PM some code to you.

[bugduk]

I like this app a lot. I especially like the ability to choose a custom color for background. Cuts down on eye strain. I like black text, and, for example, this hex code for background: "#FCEEA7". Much better than bright yellow, or whatever. I like to read in the dark, and then shut off the Pre when I get sleepy. A custom background color is essential for this.

When and if this supports my old Mobipocket files, I'll be in clover.

Fortunately, most of my old files were saved in multiple formats, so I can always convert to text. And this app always remembers the place I left off.

Great job.

[Jappus]

Originally Posted by retrobits

I've been looking at the DRM support and have been doing some initial work on the user credential verification via SHA. Making some progress, hopefully I'll be able to at least validate the credentials in a few days. After that I plan to start looking at the DES decrypt.

No worries about a shared source repository at this point. I can keep the DRM routines isolated for now. If I get anything working, I'll just PM some code to you.

I'm glad that you want to help. As I said above, I've dabbled a bit in decrypting eReader files, but since I don't own files encoded in that DRM format, my progress was strictly theoretical.

But what I have found is that there are actually already pure Javascript DES and SHA-1 implementations, and they seem to work well and are, as far as I can tell, completely free. Those files are already in my private repository but currently wholly unused, since I currently concentrate on getting the Rich Text / Library thingy going.


But if you want to give the eReader DRM a spin, those two files will most certainly help you. I've zipped & attached them to this posting.

[retrobits2]

Thanks, I actually found those same implementations through google. We're on the same page. The SHA-1 plugs right in, performs fine, and I'm making use of it now. The DES needs to be converted to work with byte arrays rather than strings (shouldn't be too difficult - just switch charCodeAt to an indexer)... since pretty much all of your bytereader stuff uses arrays. I'm ignoring the DES for the moment, but hopefully will get there soon.

[retrobits]

I'm such an idiot. I ended up with two accounts and the two machines I use default to different ones. They are both the same retrobits. Sorry for the confusion. Gonna try to phase out retrobits2 from now on.

[Jappus]

Okay, I've pretty much implemented the Rich Text Display & Library support now.


Unfortunately, while it runs fine on the Emulator (SDK 1.2), it's not only unuseably slow on my Palm Pre (WebOS v1.1.3), but it is actually that --> <-- close to crashing it. Importing files into the library works, but as soon as I attempt to read a file, the Pre grinds almost to a halt.

I have the slight suspicion that it has to do with the WebOS version, which is still at v1.1.3 for my German Pre.

So, could someone of you who has a WebOS 1.2.1 / 1.3.1 Pre please install the preliminary version 0.6.0 of the pReader that is attached to this posting, and tell me if it runs and displays files?

Because if it does, the reason is that the Depot-API sucks only under v1.1.3. But if it runs just as bad as under v1.1.3, then it is because the Depot-API sucks in general on WebOS and I need to use a different approach to both Rich Text and the library.


P.S.:
Please try to test it with a small file (< 100 kByte), because currently the data that I store in the Depot on the media partition takes over 40 times as much space as the original file. So if you have a 35kByte file, the depot needs roughly 1.4 MByte...

[retrobits]

Similar behavior here on 1.2.1. Importing into the library works fine, but reading a file never seems to complete. Actually I did get the first page of a document to render once but it would not go to the next page. I tried a small plain txt file and it displayed an error popup.

[Jappus]

Originally Posted by retrobits

Similar behavior here on 1.2.1. Importing into the library works fine, but reading a file never seems to complete. Actually I did get the first page of a document to render once but it would not go to the next page. I tried a small plain txt file and it displayed an error popup.

Thanks for testing it. At least now I know that it's something device-specific, and not something version-specific.

I already have a slight suspicion what it could be. of course, debugging it will be quite non-trivial, given that the Emulator is at least an order of magnitude faster than the device and works fine. That the v1.1.3 device has no support for the palm-log reader also doesn't help...

[Jappus]

Good news everyone!


I've found the problem, and it was really, really, momentously trivial. Trivial in the "head-meets-desk" sense.

You see, when I implemented the landscape mode, I added a function that re-rendered the page whenever the device was turned. But I soon deactivated this method, because it caused random crashes. I simply attributed the crashes to my former screen-drawing implementation.

Now that I've changed that, I thought it could be worthwhile to reactivate that method. Now, you must remember that the Emulator has no direction of sense, and as such, that method was never called. But the device has a directional sensor.

I've found out that the method was to blame by noticing that the program drew the pages just fine if I held the Pre very, very, [b]very[/i] still and level. Basically, the method is called upon even the most minute change in direction of the palm, triggering a page-redraw.

Basically, I told the palm to redraw the page some 100 times per second. Of course that pretty much brought the Palm to its knees.


Now that the method is again commented out, everything runs just fine. That means, that tomorrow, I'll clean up the code, add the UI improvements that were given in this thread and open a public repository.


In other words:
Expect v0.6.0 tomorrow!

[tarirene]

Sweet! I had downloaded the file you posted above to test on 1.3.1 but sounds like that's no longer necessary. looking forward to the update!

[chortya]

can somebody please point me to any cyrillic font I can use with pReader?
what are the further development plans? Any other format support? FB2 or ePub for example?

[Jappus]

Originally Posted by chortya

can somebody please point me to any cyrillic font I can use with pReader?

The default font should work, since it contains cyrillic chars. As long as the file is encoded with UTF-8, and not KOI-8, all you should need to do is to change the encoding to UTF-8.

I appened a screenshot of a Russian Lorem-ipsum text that I generated with this tool. As such, the text is nonsensical, but it at least shows that rendering works.

what are the further development plans? Any other format support? FB2 or ePub for example?

Since I've finished implementing basic rich text, converters for the other formats will be added one after another. The order will be mostly dictated by how simple the formats are. It is the intended target of this tool to one day render pretty much every eBook format out there (except PDF and other very rich formats, like Word/OpenOffic DOC files).

The next plan on my personal to-do list is to implement bookmarks & links and the displaying of images. On the side, I'll also add more encodings like KOI-8 and ISO-8859-X.

But since this program is released under the GPL, and I'll open up a public repository on SourceForge today, I invite everyone who feels up to the task to implement the Readers for the other formats. The programming interface for those Readers is really simple and can be coded entirely independent of the "main" app.

Retrobits for example has already volunteered to examine the eReader DRM format, and I thank him greatly for it.

[chortya]

Thanks for this explanation. Could you please test the following book: http://fictionbook.ru/author/shetcin...ad.doc.prc.zip
I don't think it's in KOI, there is another widely used encoding: windows-1251 or CP1251

You can find more information about all cyrillic encodings here:
Cyrillic encodings (charsets). Small description

[Jappus]

Basically, I can quite easily add any UTF-8 compatible encoding to the pReader. All that I need is a table that tells me which code number matches which Unicode character.

For example, tables like on this website: Windows-1253 characters table to Unicode

With that, I can build a fast & clean encoding translator. All it takes is time, which is why I'll add more encodings on the side; step by step. I'll add at least CP-1251 to the v0.6.0.

If you want, you can help. Adding a new encoding to the pReader takes me 30 seconds if I have a file with the following format:

case 0xE0: code = 0x05D0; break; //HEBREW LETTER ALEF
case 0xE1: code = 0x05D1; break; //HEBREW LETTER BET
case 0xE2: code = 0x05D2; break; //HEBREW LETTER GIMEL
case 0xE3: code = 0x05D3; break; //HEBREW LETTER DALET
case 0xE4: code = 0x05D4; break; //HEBREW LETTER HE
[...]

The hexadecimal code after the "case" is the code number in the source encoding. Here, I use codes from CP-1255 (Hebrew). The hexadecimal code after "code = " is the UTF-8 char code for that symbol. Everything after the "//" is a comment and wholly optional.

If you can send me such files per PM, I can add the encoding in question directly to the next pReader version.


P.S:
The above file only needs to include lines where the source-codepoint is different from the UTF codepoint. A line of "case 0x14: code = 0x0014; break;" is not necessary, since such cases are handled by default.

[Jappus]

I've just released the pReader version 0.6.0

Please note that this version implements a new way of interacting with the eBooks: It adds a basic library. Of course, that means that your current progress in all files will be reset. It is also quite possible that the storage format will change in the future.


Since many changes occurred under the hood, it is quite possible that some errors will occur, especially on exotic files and encodings.
I also added the CP-1250 and CP-1251 encodings. The file Chortya provided above seems to render correctly now, since it's in CP-1251.



Please report if you find bugs, crashes or other errors.


Thanks, and: Happy reading!

[retrobits]

awesome release Jappus! This version loads ereader files faster than all previous versions I've tried. The navigation bugs that I noticed for ereader appear to have been fixed. Great work!

[plee3]

Question: For version 0.6.0, you said "Added basic rich text support". Does this mean support for .RTF files?

Thanks... plee3

[Jappus]

Originally Posted by plee3

Question: For version 0.6.0, you said "Added basic rich text support". Does this mean support for .RTF files?

No, sorry. I mean displaying HTML code and translating the proprietary rich-text format of the eReader files as HTML. And "basic", because not all HTML and eReader tags are supported, yet.

Basically, I understand Rich Text not in the Microsoft sense, but in the more general "Formatted Text" sense.


Sorry for the confusion.