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

[eLiNK]

Originally Posted by Germanc

Well, I gave it a shot to add djvu outlines support. ...

I do hope you reserved some place for your name on that poster of yours

It's nice to see the djvu format being taken seriously.

Anyway, as far as scanned books are concerned the djvu format should be the first choice as it does not levy such a high 'performance tax' like the pdf.

I've been experiencing constant reboots on my KDXG with the image heavy pdfs but no problem at all with the original djvu files (except for when I once tried to open a djvu file and the kindle got rebooted.)

The only thing I would miss in this case are annotations, which should be doable according to the last djvu specification.

I also hear that Onyx devices support annotations in djvu books.

Thank you all for your great work.

P.S.: BTW, there's a pdf and djvu reader being developed for the nook devices. It is based on mupdf and DjVuLibre libraries as well.
-> https://www.mobileread.com/forums/sho...d.php?t=165609

It is for the Android system but maybe you could find some useful ideas nonetheless.

[hawhill]

Yeah, I really was busy on the weekend. I hope and plan to fix the caching this evening (Central European Time).

[dave2008]

Originally Posted by eLiNK

I do hope you reserved some place for your name on that poster of yours

Strongly agree with this

Originally Posted by eLiNK

It's nice to see the djvu format being taken seriously.

Anyway, as far as scanned books are concerned the djvu format should be the first choice as it does not levy such a high 'performance tax' like the pdf.

I've been experiencing constant reboots on my KDXG with the image heavy pdfs but no problem at all with the original djvu files (except for when I once tried to open a djvu file and the kindle got rebooted.)

The only thing I would miss in this case are annotations, which should be doable according to the last djvu specification.

I also hear that Onyx devices support annotations in djvu books.

Thank you all for your great work.

P.S.: BTW, there's a pdf and djvu reader being developed for the nook devices. It is based on mupdf and DjVuLibre libraries as well.
-> https://www.mobileread.com/forums/sho...d.php?t=165609

It is for the Android system but maybe you could find some useful ideas nonetheless.

A temporary solution to reboot when viewing image heavy pdf is to stop the framework before kpdfview starts. But if doukan can beat that high memory usage, I think we can too.

Yes, I miss annotations too If we managed to add the annotations, we can backup our annotations easily or have them converted to any format we want, that will be really handy.

[Germanc]

Originally Posted by dave2008

A temporary solution to reboot when viewing image heavy pdf is to stop the framework before kpdfview starts. But if doukan can beat that high memory usage, I think we can too.

Duokan stops the framework, and also last versions don't support DXG, so it's possible they were encountering the same issue. Anyway, since previous versions did work on DXG there should be some way to limit memory usage.

Btw, thanks for goto input box ! Only annotations and caching and I'll be completely happy

[eLiNK]

Originally Posted by dave2008

I have added the goto input box that can be invoked with G key...

It is becoming increasingly better.

I wonder if it is also possible to get it working in the TOC as well.
I have some books with at least 10 page long TOCs.

The only thing is the G key is reserved for the Duokan style shortcuts in the TOC.

[dave2008]

Originally Posted by eLiNK

It is becoming increasingly better.

I wonder if it is also possible to get it working in the TOC as well.
I have some books with at least 10 page long TOCs.

The only thing is the G key is reserved for the Duokan style shortcuts in the TOC.

It can

We can use Alt+G or Shift+G combo. You mean a goto input box for jumping inside TOC menu pages?

EDIT: But I guess a percent jump in TOC menu might be enough

[eLiNK]

Originally Posted by dave2008

It can

We can use Alt+G or Shift+G combo. You mean a goto input box for jumping inside TOC menu pages?

EDIT: But I guess a percent jump in TOC menu might be enough

Whatever so that a more efficient selection of entries within the TOC would be possible.

Except that somehow I would like 'a goto page input box' more. But that would probably depend on the implementation.

Are there other opinions?

[dave2008]

Originally Posted by eLiNK

Whatever so that a more efficient selection of entries within the TOC would be possible.

Except that somehow I would like 'a goto page input box' more. But that would probably depend on the implementation.

Are there other opinions?

Or we can have both since little changes will be needed.

[eLiNK]

Originally Posted by dave2008

We can use Alt+G or Shift+G combo....

I mean the user would have to remember if you want to go to a page within the book, press 'G'.
If you want to go to some page within the TOC, press Alt+G.

No problem as long as there are only a couple of shortcuts but I expect we would see much more.

This is why I liked the Duokan way of pressing ALT + some number (or rather letter, which gets interpreted as number in combination with pressing the ALT).

It works the same both within the book, within the TOC, and (if I'm not mistaken) within the Duokan bookshelf.

[dave2008]

Originally Posted by eLiNK

I mean the user would have to remember if you want to go to a page within the book, press 'G'.
If you want to go to some page within the TOC, press Alt+G.

No problem as long as there are only a couple of shortcuts but I expect we would see much more.

This is why I liked the Duokan way of pressing ALT + some number (or rather letter, which gets interpreted as number in combination with pressing the ALT).

It works the same both within the book, within the TOC, and (if I'm not mistaken) within the Duokan bookshelf.

Oh, I see. Agree that the inconsistent leads to confusion. I think the changes will need to wait and be added to next next release, in which the input system will be rewritten.

[eLiNK]

Originally Posted by dave2008

Oh, I see. Agree that the inconsistent leads to confusion. I think the changes will need to wait and be added to next next release, in which the input system will be rewritten.

the fine-tuning can certainly wait.
Have you sorted the things out with the cache system?

[dave2008]

Originally Posted by eLiNK

the fine-tuning can certainly wait.
Have you sorted the things out with the cache system?

The cache system is too complicate for me to play with ;P

Hawill made a first try and so far works great on my K3. I guess the new release can be out soon (hopefully in this week)

[Germanc]

I finally ditched duokan and saved 1gb thanks to djvu support, and now I have a question: would it be possible to implement continuous pages ? Duokan did this by default while using Fit to width and it's useful when reading. I guess next page caching should be implemented first, but after that maybe ?

[hawhill]

Yes, continuous page rendering would certainly be nice. The bits and pieces are in the backend, however, it would require a different caching policy plus the UI logic.

However, I've just tagged the status quo as "Release 2012.03" and built a package.
You can download it from the download page: https://github.com/hwhw/kindlepdfviewer/wiki/Download

News since latest release:

- DJVU support
- Human readable and editable settings files
- New key binds Home, used to exit program directly while reading
- One bug fix in fit-to-content mode
- Two bug fixes in two column mode
- Compile with optimization options enabled, much faster
- Jump history can be restored when you open the book next time
- Notes support for jump history. notes are auto generated according to the TOC section - where the page is in. you can change it by editing the book setting file (the one that generated in the same directory with your book).
- New two column mode without margins, invoked by Shift+F
- Improved file browser:
- Navigate throughout entire filesystem
- Manage unreadable dirs
- Show current path on last line;
- Add "single file mode": if kpdfview called without any file/folder param, open last viewed file;
- Bug fixes in reading Table of Content
- Duokan style menu item shortcuts
- Fast jump by percent, refer to the move section in Short Cut Guide.
- The behavior for page turn is now consistent with kindle native reader in fit_to_content_width mode. (i.e. do a real page turn until hit page bottom)
- You can now change default settings for your reader in .reader.kpdfview.lua. Refer to settings section of user guide.
- Manual page crop, refer to Short Cut Guide.
- 90 degree rotation support. Shift+K and Shift+J.
- Reading progress bar with Key Menu.
- Goto input box in reading mode.
- Rewrite caching strategy.

A special thanks goes to all the other contributors who made this possible. I hope it's fun for you guys too, but I really enjoy how this software evolved. I learned a lot of interesting stuff on the way.

[dave2008]

Great! Finally the release it out ;P

Many thanks to all the developers and users who help with testing. You guys liberate my kindle :-)

Originally Posted by Germanc

I finally ditched duokan and saved 1gb thanks to djvu support, and now I have a question: would it be possible to implement continuous pages ? Duokan did this by default while using Fit to width and it's useful when reading. I guess next page caching should be implemented first, but after that maybe ?

OH, continuous pages will be nice I am almost certain that it will be added in next release.