KPV: a PDF reader for Kindle, based on muPDF, GPLv3

[eLiNK]

does Kindle create a crash log?
I had my KDXG restarted while testing one of the previous versions.

a bit off topic
stating the obvious, the file searcher just written by dave2008 (along with the corresponding lines from mupdf to make it a stand-alone solution) represents a file search system hack, which can be improved
1) by showing the complete name (just like kindle does, if the file name is long) -> also relevant for mupdf
2) by associating files with certain applications (e.g. to open a pdf file with the mupdf or the native pdf viewer)
3) by enabling searching in all files through indexing (in case of pdf files, it may also be relevant for mupdf)

[dave2008]

Originally Posted by eLiNK

does Kindle create a crash log?
I had my KDXG restarted while testing one of the previous versions.

a bit off topic
stating the obvious, the file searcher just written by dave2008 (along with the corresponding lines from mupdf to make it a stand-alone solution) represents a file search system hack, which can be improved
1) by showing the complete name (just like kindle does, if the file name is long) -> also relevant for mupdf
2) by associating files with certain applications (e.g. to open a pdf file with the mupdf or the native pdf viewer)
3) by enabling searching in all files through indexing (in case of pdf files, it may also be relevant for mupdf)

Do you remember which version? Can you reproduce the bug? Well, I do not know where kindle puts the crash log :-(

1) um... What do you mean by complete name? Currently it shows the complete file name. But there is no code to handle long names, so long names are simply displayed out of the display. Do you mean truncate long file names and append with dots?


2) That's a good suggestion! The kindlepdfviewer can then support all the
formats the native system supports. But two problems must be solved before
implement this feature:

1. When kindlepdfviewer runs, it take full control of the device, i.e. the eink display and key press events. So if we want to use the native viewer, we have to exit kindlepdfviewer first to release the control.

2. I know little about the native system as well as JAVA, thus I have no idea of how to call the native viewer.

Maybe we can solve the first problem by temporally release the eink display and input device in kindlepdfviewer before calling the native viewer. But I haven't tested this approach yet, not sure it will work or not.

For the second problem, I have no idea. :-( Maybe more experienced hackers know how to achieve it.


3) This can be done, but I need to get familiar with mupdf's API first. I just started reading their source code yesterday. ;-P

[dave2008]

I added a table of content menu to the reader, so now we can jump between chapters by pressing "t" key when viewing pdfs.

download link for the new version:
https://github.com/hwhw/kindlepdfviewer/wiki/Download

As always, bugs reports are welcome. :-)

[vmonkey]

Originally Posted by dave2008

I added a table of content menu to the reader, so now we can jump between chapters by pressing "t" key when viewing pdfs.

download link for the new version:
https://github.com/downloads/houqp/k...er-606ef84.zip

As always, bugs reports are welcome. :-)

Thanks for the TOC menu support!

I have maybe one little thing - when I exit the kindlepdfviewer the home screen of my Kindle is not visible (even though I can browse it) and there is still kpdfviewer, not navigable though - that means that after quiting kpdfviewer it would be great to implement "refresh page" (or I am not sure how to call it properly - I mean when the screen goes black and everything on the screen is redrawn again).

[dpavlin]

Originally Posted by dave2008

As for the 10° rotation, I agree with dpavlin that it may be useful for viewing comics (as he pointed out in the pull request). So I think would be better to leave Shift+K and Shift+J shortcut to these two motions.

I will try to write a menu for the rotation feature you mentioned if I have time. I am now working on the search feature. It is half done and should be finished tomorrow if I am lucky enough. :-)

In all honesty, I think that rotation by 90° might be better default value than 10°, so I suggest to move 10° rotation to SHIFT+J/K and leave 90° at J/K.

Rotation code is half-baked: you shouldn't really be able to rotate page out of view (as it is right now). We would need to calculate new bounding boxes for page which takes in account rotation.

Unfortunately, I don't have DXG right now (I asked friend to make me serial port so I can update kernel) so I can't really test rotation sensor in DXG.

[eLiNK]

Originally Posted by dave2008

Do you remember which version? Can you reproduce the bug? Well, I do not know where kindle puts the crash log :-(

it could be 015c27d but I'm not 100% sure.
I was just moving "the cursor" around in the mupdf's file manager and then all of a sudden the Kindle restarted itself.
Interestingly, nothing happened to the mupdf.
I have not been able to reproduce the bug with the latest version ('83fa148').

Originally Posted by dave2008

1) um... What do you mean by complete name? Currently it shows the complete file name. But there is no code to handle long names, so long names are simply displayed out of the display. Do you mean truncate long file names and append with dots?

I have many articles/papers in pdf format, so they all have pretty long names (Author_CompleteNameOfTheArticle(JournalAbbreviati on)_year.
In the mupdf, the long names are cut off.
So are they in the kindle bookshelf. But if you move the cursor to the article, the file's name is shown on two lines. If the name is still too long to fit on two lines, then some part of the file name is replaced by dots, but the last 8 characters are still shown, which I consider to be very important.
Because sometimes the name is the same but the year could be different (as papers may have several revisions)

Originally Posted by dave2008

2) That's a good suggestion! The kindlepdfviewer can then support all the
formats the native system supports. But two problems must be solved before
implement this feature:

1. When kindlepdfviewer runs, it take full control of the device, i.e. the eink display and key press events. So if we want to use the native viewer, we have to exit kindlepdfviewer first to release the control.

2. I know little about the native system as well as JAVA, thus I have no idea of how to call the native viewer.

3) This can be done, but I need to get familiar with mupdf's API first. I just started reading their source code yesterday. ;-P

It should not necessarily be you.
I just made some suggestions, how a work flow could be improved.

Thanks for the new version

[eLiNK]

Originally Posted by dave2008

I added a table of content menu to the reader, so now we can jump between chapters by pressing "t" key when viewing pdfs.

download link for the new version:
https://github.com/downloads/houqp/k...er-606ef84.zip

As always, bugs reports are welcome. :-)

Tested some of my very complicated files.
Everything works well, not a glitch.

two suggestions/wishes on how to improve reading experience
1) it would be great if the mupdf would get "memory".
Specifically related to the table of contents. If I'm say on page 10, I call the table of contents up, go to another chapter, read a couple of pages.
By pressing the backspace, I should return to page 10 (on which I called the TOC up).
Likewise, if a function to go to a certain page (by number or bookmark) would be implemented later, pressing the backspace should bring you to the page on which this function has been called.

2) I find it rather appealing how the shortcut system is well thought out in Doukan.
Every line both in the file manager and in the TOC overview is 'numbered' by letters, so that pressing a certain letter you can directly start a file or go to some chapter from the TOC without the need to first select that line by joystick.
Obviously, it is of great value for non-touch kindles.

[hawhill]

Just wanted to add a short note that I'm soooo happy you guys are working on this :-) I'm somewhat buried in other work, and it's a great pleasure to see the "release early" paradigm work out really great in my "absence". You guys rock :-)

[dave2008]

Originally Posted by vmonkey

I have maybe one little thing - when I exit the kindlepdfviewer the home screen of my Kindle is not visible (even though I can browse it) and there is still kpdfviewer, not navigable though - that means that after quiting kpdfviewer it would be great to implement "refresh page" (or I am not sure how to call it properly - I mean when the screen goes black and everything on the screen is redrawn again).

Thanks for your suggestion. I have fixed this in my repo, waiting for hawhill to merge the change. I haven't packed a new version for this fix yet, because I am working on some other features ;-P Currently, you will have to manually press "HOME" key every time you exit the kindlepdfviewer to do a refresh.

Originally Posted by dpavlin

In all honesty, I think that rotation by 90° might be better default value than 10°, so I suggest to move 10° rotation to SHIFT+J/K and leave 90° at J/K.

second that.

Originally Posted by dpavlin

Rotation code is half-baked: you shouldn't really be able to rotate page out of view (as it is right now). We would need to calculate new bounding boxes for page which takes in account rotation.

How about using the native dbus interface to do the major degree rotate? like:

lipc-send-event -r 3 com.lab126.hal orientationRight &

So we can not only rotate in mupdf, but also in filechooser and other menus. Also, when user quit kindlepdfviwer, the rotation state is kept in native system.

Originally Posted by dpavlin

Unfortunately, I don't have DXG right now (I asked friend to make me serial port so I can update kernel) so I can't really test rotation sensor in DXG.

Cool, hardware hacker. :-)

Originally Posted by eLiNK

I have many articles/papers in pdf format, so they all have pretty long names (Author_CompleteNameOfTheArticle(JournalAbbreviati on)_year.
In the mupdf, the long names are cut off.
So are they in the kindle bookshelf. But if you move the cursor to the article, the file's name is shown on two lines. If the name is still too long to fit on two lines, then some part of the file name is replaced by dots, but the last 8 characters are still shown, which I consider to be very important.
Because sometimes the name is the same but the year could be different (as papers may have several revisions)

OK, I know what you mean. I haven't noticed that the native bookshelf has this feature. ;-P

Originally Posted by eLiNK

Tested some of my very complicated files.
Everything works well, not a glitch.

Many thanks for your testing work!

Originally Posted by eLiNK

two suggestions/wishes on how to improve reading experience
1) it would be great if the mupdf would get "memory".
Specifically related to the table of contents.

Wow, I have just started working on some thing similar! What I want to add is a "jump stack", which records your every jump motions, so you can fireup a "jump stack" menu and choose which page you want to jump back (maybe we can even adds notes to these jump points).

Originally Posted by eLiNK

2) I find it rather appealing how the shortcut system is well thought out in Doukan.
Every line both in the file manager and in the TOC overview is 'numbered' by letters, so that pressing a certain letter you can directly start a file or go to some chapter from the TOC without the need to first select that line by joystick.
Obviously, it is of great value for non-touch kindles.

Yes, Duokan has done a great job, except closing their sources.

OK, this feature is not difficult to add. Now we have a long TODO list:
https://github.com/houqp/kindlepdfviewer/issues

Originally Posted by hawhill

Just wanted to add a short note that I'm soooo happy you guys are working on this :-) I'm somewhat buried in other work, and it's a great pleasure to see the "release early" paradigm work out really great in my "absence". You guys rock :-)

Good luck to your work then, looking forward to your return.

[eLiNK]

Originally Posted by eLiNK

Tested some of my very complicated files.
Everything works well, not a glitch.

Just noticed one thing.
German umlauts (ä,ö) are not shown in the TOC.
Is it an intention or an oversight?

[eLiNK]

Originally Posted by dave2008

Wow, I have just started working on some thing similar! What I want to add is a "jump stack", which records your every jump motions, so you can fireup a "jump stack" menu and choose which page you want to jump back (maybe we can even adds notes to these jump points).

Sounds even better.

Originally Posted by dave2008

Many thanks for your testing work!

You're welcome.
That's the very least I could give you back for all your efforts.
Keep on

[dave2008]

Originally Posted by eLiNK

Just noticed one thing.
German umlauts (ä,ö) are not shown in the TOC.
Is it an intention or an oversight?

Oops, my bad. I was testing with Chinese Characters and forgot to set the font back. ;-p

I have fix this in the new version. This version includes the fix for screen refresh after exit. Also the font configuration is unified among all menus and configuration is now automatically saved after exit.

download link:
https://github.com/hwhw/kindlepdfviewer/wiki/Download

Now I can concentrate on the "jump stack" feature. :-)

[dave2008]

Hey guys,

When I am working on the jump stack feature, I found it not so easy to save the stack into book specific configuration files with current settings module. I think the "jump stack" information is best represented as a nested table, but the setting module only support (key, value) bindings. Thus I cannot find an elegant way to save nested table with the settings module. (I only came up with a some how dirty hack)

So I tried the table Serialization approach and did a benchmark between it and the settings module, which uses sqlite3.

As first, I thought since the settings module uses sqlite3, it should be faster. But the result turned out that it is not true:

  $ ./benchmark_pickle.lua                                              git:master [cb982f5] modified untracked
Time for sqlite3 approach: 2.05
Time for pickle approach: 0.19

The Serialization approach, using pickle module, is about 10 times faster though it handles more data than the sqlite3 approach. You can check out the benchmark code from following link:
https://github.com/houqp/kindlepdfvi...ark_pickle.lua

So I suggest using Serialization approach in the settings module instead of sqlite3 for four reasons:

1. Serialization approach is faster, as my test shows
2. Serialization approach generates human readable text stream instead of binary data, which is easier to maintain and modify by humans if needed.
3. Serialization approach make the code cleaner, you can dump the whole table with one function call.
4. For small data, Serialization approach dumps smaller setting file (395 bytes vs 3.0K in my test case). Haven't tested with large data tough.

I only tested the pickle module, but there are many other implementations which might be even faster:
http://lua-users.org/wiki/TableSerialization

So, any suggestions or feedbacks for this?

[knc1]

The longer you use Lua, the more you will like it (a rare thing these days).
Written by a: Lua lover

[knc1]

Originally Posted by knc1

The longer you use Lua, the more you will like it (a rare thing these days).
Written by a: Lua lover

You can also register the Lua engine with the kernel and the kernel will then execute your Lua script (if chmod'd +x).

Some notes (and magic numbers) on how to do that:
http://hg.minimodding.com/repos/aufs/auroot.hg/

Also a "known working" copy of luaposix as used in Alpine Linux:
http://hg.minimodding.com/repos/lua/luaposix.hg/