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

[dpavlin]

Originally Posted by Oleksa

Main issue is normal pageturning in modes that differs from vertical one page mode (2-column). Now pageDn pressing leads to move to next page regardless to present mode. It's very uncomfortable in horizontal orientation and 2-column mode. Issue is that pageDn pressing leads to move to next text piece not to next page (like in Duokan)

If I understand you correctly, you would expect to be able to move through columns using previous and next page buttons instead of fiveway (I haven't used Duokan, so I might be wrong)

I though about it while implementing this feature, and somehow I decided that depending on human interaction seems more logical to me than having to specify number of columns. Current implementation works equally well for any number of columns if you zoom to first one manually since it depends on direction in which fiveway is pressed.

Then, when playing with a reader on real device, I somewhat liked using page previous/next to quickly browse through book, and though that it's somewhat more logical since keys behave same in each zoom mode.

I can be persuaded otherwise, but that would require code change and some way to specify number of columns so we can build matrix of all available position on page. Downside of that is that sometimes you have parts of page in which you are not interested (ads for example) which you can quickly skip using page buttons in current implementation.

[eLiNK]

Originally Posted by dave2008

Except for annotaion, which we are working on now ;-P

What about text search?

[dpavlin]

Originally Posted by eLiNK

What about text search?

I was hoping that somebody would suggest it :-)

We opened issue to track this request: https://github.com/hwhw/kindlepdfviewer/issues/75

[Oleksa]

Originally Posted by dpavlin

If I understand you correctly, you would expect to be able to move through columns using previous and next page buttons instead of fiveway (I haven't used Duokan, so I might be wrong)

I though about it while implementing this feature, and somehow I decided that depending on human interaction seems more logical to me than having to specify number of columns. Current implementation works equally well for any number of columns if you zoom to first one manually since it depends on direction in which fiveway is pressed.

Then, when playing with a reader on real device, I somewhat liked using page previous/next to quickly browse through book, and though that it's somewhat more logical since keys behave same in each zoom mode.

I can be persuaded otherwise, but that would require code change and some way to specify number of columns so we can build matrix of all available position on page. Downside of that is that sometimes you have parts of page in which you are not interested (ads for example) which you can quickly skip using page buttons in current implementation.

dpavlin, Thanks for your answer.
Yes, you uderstand me almost correctly (almost because pagetirning in one column horizontal (album) orientation differs from 2-column mode).

More people read books(or pieces of books) from begin to end page by page
How is pageturning (I mean actions for move to next piece of text) realized now:

- in one column vertical orientation to see next piece of text user must press PageDn. It's Ok

- in one column horizontal (album) orientation reader shown upper piece of page, and to see lower piece page user must hold pressing fiveway down some time (2-3s) for very slow scroll down

- in 2-column mode regardless to orientation to see next piece of text user must press fiveway down and when he go to end of page must press fiveway right. How it's look at reading: down(fiveway); down; down; Oh no, not response for pressing down must press right, down, down etc... It's not too comfortable as for me.

I wish that in al all this modes to see next text piece it will be enough to press PageDn only. The function that go to next page regardless to current mode (like PageDn now) is usefull too, but it's using rarely, and it's logical to correspond to this functions any 2 keys of keyboard. It's will be great if the user will be have opportunity to change functions of keys as he wish, for example in txt file.

Multicolumn mode is very usefull. It will be great if you mke it

Bugreport: if you change orientation in 90 degrees by ^J,k and after that goes to screensaver, it's orientate so screensaver picture too. If it was horizontal orientation screensaver picture becomes corrupt (blur and multiple). When you switch on, the home screen is corupt the same too.

It's important, how screensaver starts. If by swith off - it's enough to pageturn or joystick press to return to kpdfreader. If by timeout - hard reset helps only. Please debug it.

[dave2008]

Originally Posted by Oleksa

dpavlin, Thanks for your answer.

Bugreport: if you change orientation in 90 degrees by ^J,k and after that goes to screensaver, it's orientate so screensaver picture too. If it was horizontal orientation screensaver picture becomes corrupt (blur and multiple). When you switch on, the home screen is corupt the same too.

It's important, how screensaver starts. If by swith off - it's enough to pageturn or joystick press to return to kpdfreader. If by timeout - hard reset helps only. Please debug it.

Thanks for the report. I would say currently kindlepdfviewer does not support screensaver yet, i.e. when you go into screensaver for too long, it will exist. And if kindlepdfviewer does not exist normally the native system will not be able to update the screen correctly. (you may want to refer to my previous post: https://www.mobileread.com/forums/sho...&postcount=175).

Hope somebody can help fix this. I will give it a try if it is still not fixed after the djvu highlight is stablized and epub support is added. ;P It's quite annoying to manually exist kindlepdfviewer every time I want to go into screensaver.

[Oleksa]

Originally Posted by dpavlin

If I understand you correctly, you would expect to be able to move through columns using previous and next page buttons instead of fiveway (I haven't used Duokan, so I might be wrong)

I though about it while implementing this feature, and somehow I decided that depending on human interaction seems more logical to me than having to specify number of columns. Current implementation works equally well for any number of columns if you zoom to first one manually since it depends on direction in which fiveway is pressed.

Then, when playing with a reader on real device, I somewhat liked using page previous/next to quickly browse through book, and though that it's somewhat more logical since keys behave same in each zoom mode.

I can be persuaded otherwise, but that would require code change and some way to specify number of columns so we can build matrix of all available position on page. Downside of that is that sometimes you have parts of page in which you are not interested (ads for example) which you can quickly skip using page buttons in current implementation.

dpavlin, Thanks for your answer.
Yes, you uderstand me almost correctly (almost because pagetirning in one column horizontal (album) orientation differs from 2-column mode).

More people read books(or pieces of books) from begin to end page by page
How is pageturning (I mean actions for move to next piece of text) realized now:

- in one column vertical orientation to see next piece of text user must press PageDn. It's Ok

- in one column horizontal (album) orientation reader shown upper piece of page, and to see lower piece page user must hold pressing fiveway down some time (2-3s) for very slow scroll down

- in 2-column mode regardless to orientation to see next piece of text user must press fiveway down and when he go to end of page must press fiveway right. How it's look at reading: down(fiveway); down; down; Oh no, not response for pressing down must press right, down, down etc... It's not too comfortable as for me.

I wish that in al all this modes to see next text piece it will be enough to press PageDn only. The function that go to next page regardless to current mode (like PageDn now) is usefull too, but it's using rarely, and it's logical to correspond to this functions any 2 keys of keyboard. It's will be great if the user will be have opportunity to change functions of keys as he wish, for example in txt file.

Multicolumn mode is very usefull. It will be great if you mke it

Bugreport: if you change orientation in 90 degrees by ^J,k and after that goes to screensaver, it's orientate so screensaver picture too. If it was horizontal orientation screensaver picture becomes corrupt (blur and multiple). When you switch on, the home screen is corupt the same too.

It's important, how screensaver starts. If by swith off - it's enough to pageturn or joystick press to return to kpdfreader. If by timeout - hard reset helps only. Please debug it.

[hawhill]

I think you sent this twice by mistake. Would you edit it? And let me say thanks for your feedback, too. It's appreciated. I think dpavlin is just right, we ought to focus on interaction with the rest of the Kindle framework a bit to make it a smooth experience.

[Oleksa]

Originally Posted by hawhill

I think you sent this twice by mistake. Would you edit it? And let me say thanks for your feedback, too. It's appreciated. I think dpavlin is just right, we ought to focus on interaction with the rest of the Kindle framework a bit to make it a smooth experience.

Yes I was sent it by mistake. But I late to edit it. I have message about 15 minutes. Sorry, but I'm some days only as registered on this forum.

Thanks for your work. The project is developed very fast. That's great.

The epub support isn't critical for me. I use fbkindle for reading epub, fb2 and mobi files, and it works good.

The kpdfreader have some problems with pagenumber saving, when goes to screensaver (Maybe I'm not original in this bugreport). I'm surprised, but it depends from how screensaver mode starts: by switch-off slider manual or by timeout. In first case exist chance that reader saved pagenumber and after switch-on Kindle open kpdfreader at last readen page.

[vdp]

For me personally the biggest issue is that my DXG consistently reboots after browsing maybe 20 or 30 pages. I am running the "bleeding edge" from the repo now, but this still happens with both DJVU and PDF documents. I think there are memory leaks somewhere(caching?). Don't know if this is a known problem, but it's clearly visible with 'top'. The allocated memory steadily raises from about 20% to little above 50% at which time the kernel's OOM killer kicks in and the device restarts itself. Dave said something about limiting memory - do I have to set something somewhere in order to configure this?

[hawhill]

When you're running "bleeding edge": Did you adjust the value for muPDF's own store? You might want to set it to a much lower value. It's currently at 64MB, set in line 11 here: https://github.com/hwhw/kindlepdfvie...reader.lua#L11
That 64MB, then added about 10MB binary size (though cached), plus 5MB tile cache - I can see trouble for the DX with its 128MB... My suggestion is to set that muPDF cache down to 32MB.

[dave2008]

Originally Posted by vdp

For me personally the biggest issue is that my DXG consistently reboots after browsing maybe 20 or 30 pages. I am running the "bleeding edge" from the repo now, but this still happens with both DJVU and PDF documents. I think there are memory leaks somewhere(caching?). Don't know if this is a known problem, but it's clearly visible with 'top'. The allocated memory steadily raises from about 20% to little above 50% at which time the kernel's OOM killer kicks in and the device restarts itself. Dave said something about limiting memory - do I have to set something somewhere in order to configure this?

Oh, since I don't have a DXG for testing, when eLiNK told me kindlepdfviewer reboots his device, I thought it was caused by the amazon framework. If it is caused by OOM killer, stopping the framework with "killall -stop" won't help, too bad.

Currently, there is no memory control for DJVU, maybe you can bring down the memory usage by changing the cache size of kindlepdfviewer. It can be controlled by editing file ".reader.kpdfview.lua", refer to https://github.com/hwhw/kindlepdfviewer/wiki/Userguide. But I guess it won't help too much since the default cache is only 5MB.

As for PDF, we just found a way to decrease the memory usage of MuPDF, but no one add relevant code for this yet. If you want to give it a try, the cache size of MuPDF can be changed in the "pdfreader.lua", on line 11, the last arguemtn of pcall. This should be able to greatly decrease the memory usage of MuPDF. We will add a configurable entry for this in ".reader.kdpfview.lua" in next release.

[dave2008]

Originally Posted by hawhill

When you're running "bleeding edge": Did you adjust the value for muPDF's own store? You might want to set it to a much lower value. It's currently at 64MB, set in line 11 here: https://github.com/hwhw/kindlepdfvie...reader.lua#L11
That 64MB, then added about 10MB binary size (though cached), plus 5MB tile cache - I can see trouble for the DX with its 128MB... My suggestion is to set that muPDF cache down to 32MB.

Oops, hw beats me this time

[vdp]

Thanks to both of you!
These look like promising suggestions. I will try them and will let you know if they work for me.

[vdp]

Unfortunately, reducing the muPDF's cache to 32MB, doesn't seem to help - it just delays the reboot somewhat. Because the pattern is identical for DJVU and PDF I suspect that muPDF's caching is not the (only) reason. I wonder why you are not seeing the same on K3 however- that's strange... Did you try to open a PDF or DJVU and monitor the memory usage with 'top'. Also I tend to zoom in and use this special mode(FW down and then navigating using FW). It seems to me that while in this mode it takes even less page turns to reboot. I haven't tested it comprehensively though...

[dpavlin]

Originally Posted by vdp

Unfortunately, reducing the muPDF's cache to 32MB, doesn't seem to help - it just delays the reboot somewhat. Because the pattern is identical for DJVU and PDF I suspect that muPDF's caching is not the (only) reason. I wonder why you are not seeing the same on K3 however- that's strange... Did you try to open a PDF or DJVU and monitor the memory usage with 'top'. Also I tend to zoom in and use this special mode(FW down and then navigating using FW). It seems to me that while in this mode it takes even less page turns to reboot. I haven't tested it comprehensively though...

We have another mupdf memory knob which is by default 64M, and that might be the problem. I opened issue with possible solution for this problem: https://github.com/hwhw/kindlepdfviewer/issues/79