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

[hawhill]

I tend to agree :-) I just did not use kite myself for now. That's only due to "launchpad works for me" and a stupid small question that I better ask in the kite thread...

@lesen54321: Glad to hear it finally worked! Have great and relaxing holidays! And be assured that your english was quite well, I think. It's been easy to understand what you said. It was harder to think about what state your Kindle was in, but that's something different :-)

[lesen54321]

Hi hawhill,

thanks, that is nice to hear...

Bye

lesen54321

[mikeww]

Originally Posted by hawhill

it will probably be useless for now on the Kindle 4 (Non-Touch) version.

any plans for this to work on Kindle 4 NT?

[aliabbasjp]

Originally Posted by dave2008

@aliabbasjp, I have replied your issue in the project page

some one on github gave some more suggestions regarding cursor granularity too. Will it be implemented in future releases?

[reprep]

i downloaded kindlepdfviewer-eaaff0d.zip for shift + x functionality (thanks, it is a great help), though i guess NuPogodi's patches aren't involved, right? Because file type icons weren't there.

Also i think restart problems on kindle DXG have been totally solved. I tried various pdf files (some took more than 10 seconds to change pages in original firmware), with various zoom levels, but the kindle never restarted.

[dave2008]

Originally Posted by NuPogodi

The time wasted on discussing problems like the keypress time interval is a time wasted for nothing

Agree, I have added kite support to the issue tracker.

[dave2008]

Originally Posted by mikeww

any plans for this to work on Kindle 4 NT?

We have plans for K4 or even KTouch:
https://github.com/hwhw/kindlepdfviewer/issues/113

But none of the current developers have these two devices

I might be able to borrow a K4 from one of my friends next week and see if we can port it to K4. But even though we sucessfully port it to K4, we still need to finish the new UI framework first, current UI framework is too restricted to Keyboard input and is not flexible enough for future extensions. In all, it takes time...

Originally Posted by aliabbasjp

some one on github gave some more suggestions regarding cursor granularity too. Will it be implemented in future releases?

Yes of course, but not sure which release...

Originally Posted by reprep

i downloaded kindlepdfviewer-eaaff0d.zip for shift + x functionality (thanks, it is a great help), though i guess NuPogodi's patches aren't involved, right? Because file type icons weren't there.

A large part of NuPogodi's patches have already been merged to the latest code base, but that test build is released before the merge. We are working on the new patches NuPogodi sent to us.

[thomass]

Originally Posted by dave2008

We have plans for K4 or even KTouch:
https://github.com/hwhw/kindlepdfviewer/issues/113
But none of the current developers have these two devices

Then lets start to make donations...

[daksha]

Any chase to fix the landscape mode? I attached 3 pics, in the first one is the page I want to read in landscape, cos' in normal mode is too small. In landscape the page is supposed to be splitted in 2, as per pic 2 & 3. The top haft of page is displayed once the landscape mode is activated ( key F). Hence, to read the other half of the page, we need to use joypad 14 times just to fit the second part of the page. And it is staying there for the next page (another 14 moves for joypad to reach the top and another 14 to read the bottom of page). Can u make it easy to read, > to be not the next page but the other half?
Thanks for your time.

[dave2008]

Originally Posted by daksha

Any chase to fix the landscape mode? I attached 3 pics, in the first one is the page I want to read in landscape, cos' in normal mode is too small. In landscape the page is supposed to be splitted in 2, as per pic 2 & 3. The top haft of page is displayed once the landscape mode is activated ( key F). Hence, to read the other half of the page, we need to use joypad 14 times just to fit the second part of the page. And it is staying there for the next page (another 14 moves for joypad to reach the top and another 14 to read the bottom of page). Can u make it easy to read, > to be not the next page but the other half?
Thanks for your time.

I think what you need is "zoom to fit content width" mode. Here is what you need to do, press key "K" to switch to landscape mode, then press "Shift+S" to switch to "zoom to fit content width" mode. Now ">" should lead you to other half of the page.

[daksha]

Thanks, it is working. I tried only S or D command. But if I use joypad to pan, the landscape is screwed again, and I need to press again shift+S. It happen also if I zoom out a little bit. A scroll bar on the right side would be nice too, to have an idea how much from the page has left.

[NuPogodi]

In order to simplify a work for heroes (dpavlin, dave2008) who implement new updates in the main kpdf-branch, this time I've collected only those files I've modified since 19.05.2012. So, the users wanted to test new features should first download updates from 19.05.2012 & unpack the content over official kpdf-release (April, v2) and, only then, made the same procedure with current update (27.05.2012).

What's new?

1. kpdf no longer requires us to make double extentions for zipped cr-documents (like *.fb2.zip or *.txt.zip). Using the system command (unzip), kpdf (or, more exactly, crereader.lua) reads the content of zipped files, determines the right extention from the first fileentry and uses the correct style *.css. The same command is used to show the unzipped filesize (for zips only) in fileinfo.lua

2. The filechooser.lua was modified so that users are finally able to type 'H' and to see active hotkeys (i guess this feature has already been implemented in the main kpdf-code, but not yet released).

3. It was not the only change. I've added new & expanded already existing functions to manipulate files & folders. Folders: one can now make new folders (^N) or delete empty ones (by pressing the same button 'Del' as intended to delete documents). Files: i've have added a possibility to copy (^C) and/or to move (^X) documents into 'clipboard' and to paste (^V) the whole 'clipboard' content to any folder in your Kindle. Suggested usage is alike copy-paste procedure in Windows-based OSs [you have (i) to select some document, (ii) to copy or to move it into clipboard, to repeat this procedure for all files you're going to copy or to move, (iii) then goto to another folder and, finally, (iv) to paste the whole clipboard content there]. Actually, 'clipboard' has nothing to do with memory, it's just another folder (/mnt/us/kindlepdfviewer/clipboard/). The last, but not least... all operations with 'clipboard' and/or renaming should generally not damage the reading history.
Ohhh... I've forgotten: one can also rename selected document (^R).

4. "And now about something completely different" (C) Monty Python's Flying Circus
Some words about modifications i've introduced in inputbox.lua. This code was almost totally rewritten so that users could finally profit from UTF8-support in kpdf. ATM, when you call inputbox.lua (say, when making new folder or when selecting the pattern to search), you will see the virtual keyboard that prompts you the current layout - one of 8 possible layouts. ATM, you can select proper layout by "joypad up/down" or by keys 'Aa' (toggle the charcase: char <> CHAR), 'Sym' (toggle between chars and symbols) and 'Menu' (toggle between common characters [layouts 1-4] and language-specific chars [layouts 5-8]). By default, national layouts are cyrillic (see screenshot), but all you need to type your native characters (west- & ost-european, chinese, hebrew, etc) is
(i) to open attached file ./keyboard/mykeyboard.lua,
(ii) to edit the layouts (self-explanatory) and
(iii) to copy modified mykeyboard.lua to the main kpdf-folder (i.e. to /mnt/us/kindlepdfviewer/mykeyboard.lua).
Just after that, your own utf8-characters should be visible on virtual keyboad (the default font 'DroidSansMono' supports a lot of national glyphs) and available for searching (case-sensitive only - see screenshot), making new folders, renaming the filenames and so on. That's all, folks!

[reprep]

here is a bug report.

i previously mentioned an .epub file with built-in fonts rendered incorrectly (problem with non-latin characters)

At test version 78efdc7, i can choose a different font than the built-in one, and with some fonts those characters are rendered correctly.

but at bb5c54d (2012.04.2) even with both 2 patches of NuPogodi, i can't change fonts. The same font is displayed whatever i choose (of course that is if the .epub file has a built-in font).

Though i am pretty sure, the built-in font has these non-latin characters defined, and coolreader can display them well.

[dave2008]

Originally Posted by reprep

here is a bug report.

i previously mentioned an .epub file with built-in fonts rendered incorrectly (problem with non-latin characters)

At test version 78efdc7, i can choose a different font than the built-in one, and with some fonts those characters are rendered correctly.

but at bb5c54d (2012.04.2) even with both 2 patches of NuPogodi, i can't change fonts. The same font is displayed whatever i choose (of course that is if the .epub file has a built-in font).

Though i am pretty sure, the built-in font has these non-latin characters defined, and coolreader can display them well.

Thanks for the report. In fact, I have no idea why...

It is not caused by the lua codes but C codes. To verify that, copy the kpdfview file from the test build to release 2012.04.2, the characters should be able to rendered correctly. But we did not touch the c code too much after release 2012.04.2... I also tried to compile an other test version from latest code, and it also works. So it is likely to be fixed in the development code.

As a workaround, you might want to use the test build instead.

[reprep]

Originally Posted by dave2008

Thanks for the report. In fact, I have no idea why...

It is not caused by the lua codes but C codes. To verify that, copy the kpdfview file from the test build to release 2012.04.2, the characters should be able to rendered correctly. But we did not touch the c code too much after release 2012.04.2... I also tried to compile an other test version from latest code, and it also works. So it is likely to be fixed in the development code.

As a workaround, you might want to use the test build instead.

thanks for the reply. Yes, i am using the test build now, though the second patch of NuPogodi is great, so i will try to copy the kpdfview file to get the best of two worlds.