Kindle -- KOReader: a document reader for PDF, DJVU, EPUB, FB2, HTML, ... (GPLv3)

[h1ro]

for the jump to page in file formats that have no hard breaks you could have some approximation based on total number of characters or lines.

There's no option for justification in html files. Even pdfs (which should be much more problematic because of the unflexible format) sometimes look better, even with reflowing

[knc1]

Originally Posted by h1ro

for the jump to page in file formats that have no hard breaks you could have some approximation based on total number of characters or lines.

There's no option for justification in html files. Even pdfs (which should be much more problematic because of the unflexible format) sometimes look better, even with reflowing

Nice thoughts, let us know when you get it implemented.

Would still like to hear the response of the person who made the "code this for me" request.

[Eithrial]

Originally Posted by knc1

And how can that target location be identified in the file?
Many of these formats do not have "hard" page breaks.

Originally Posted by knc1

Would still like to hear the response of the person who made the "code this for me" request.

First, maybe what I have written sound like some kind of "order" to make some feature specially for me, but it's not like that. I really appreciate all work made by KOReader developers, and many other people while creating other software to improve kindle. All I wanted to say, that it would be nice to see this feature and that I don't know any reason why it should be hard to do for somebody who knows more or less about programming. Of course I know very little and I may be mistaken.

Second, I was talking mainly about pdf's which I think has page breaks, hasn't they?

[twobob]

Sounds reasonable.

Perhaps this could be listed as a feature request on the github page?

[hawhill]

Yep, that would be a good place. Sometimes, it is a bit hard to distill ideas and suggestions out of a discussion. So, everybody feel welcome to file such things as issues on Github!

[daffy]

Originally Posted by knc1

And how can that target location be identified in the file?
Many of these formats do not have "hard" page breaks.

Without wishing to extend any support for this request, I might have an interpretation that would be workable with HTML:

Imagine a HTML file rendered to a virtual canvas featuring exactly the same width as the device's physical width. Then paginate the virtual canvas height by the device height. Voilá - paging

(The implementation would probably consume heaps of memory and CPU, not good).

Alternatively, allow for relative navigation in HTML, e.g. "plain" page down, "faster" page down (== 3x plain page down), "fastest" page down (== 9x plain page down) with exponential scrolling behaviour. This allows for faster navigation in what is inherently a single linear representation. For that to work, it wouldn't even be necessary to render to the output device. Rendering to a bitmap and blipping that in (in case the Kindle graphics stack supports that) would be sufficient, so this could be memory conservative.

Again, not supporting the feature request, just airing ideas

[daffy]

I am having a bit of a challenge to accurately crop PDF files on my Kindle Paperwhite.

My interpretation of the cropping feature user interaction setup is that touching will assign the top-left and/or(?) bottom-right positions.

Now, touching with any accuracy on that screen seems to be a bit of a challenge (for me). Perhaps the following addition would allow for better cropping:

Take the auto-detected frame as the baseline. Split the screen into the four quadrants, each corresponding to one corner of the crop area. Swipe up/down in the quadrant to adjust the crop rectangle up/down; make this relatively insensitive to user input ("decelerated" touch).

I suppose that the Kindle supports swipe and touch as independent actions?

[twobob]

Originally Posted by daffy

..

I suppose that the Kindle supports swipe and touch as independent actions?

It does.

[dave2008]

Originally Posted by daffy

Without wishing to extend any support for this request, I might have an interpretation that would be workable with HTML:

Imagine a HTML file rendered to a virtual canvas featuring exactly the same width as the device's physical width. Then paginate the virtual canvas height by the device height. Voilá - paging

(The implementation would probably consume heaps of memory and CPU, not good).

Alternatively, allow for relative navigation in HTML, e.g. "plain" page down, "faster" page down (== 3x plain page down), "fastest" page down (== 9x plain page down) with exponential scrolling behaviour. This allows for faster navigation in what is inherently a single linear representation. For that to work, it wouldn't even be necessary to render to the output device. Rendering to a bitmap and blipping that in (in case the Kindle graphics stack supports that) would be sufficient, so this could be memory conservative.

Again, not supporting the feature request, just airing ideas

Thanks for the brain strome

CREngine internally has the concept of virtual page. We can do navigation based
on virtual page of course. But the problem is virtual changes when you
retypeset the document(say zoom in). So it's a relative value and very tricky
to deal with.

What we did in kindlepdfviewer is we use percentage inside document for
navigation. So you will always jump to roughly the same location no matter how
you typeset the document. I think KOReader will also take this approach once
the goto feature is implemented.

[Aj74]

I thank all those who made the project.
Wishlist (if possible:
1. function searches the text (pdf, epub);
2. function "Go to page" (already asked ...)
3. link operation epub

Thank you.
PS: sorry for using the translator of "google"

[wisecrick]

Work very well! Good job!

One issue:
It's difficult to popup the home context menu on the file manager screen, so it's difficult to quit the application.

[twobob]

Originally Posted by wisecrick

Work very well! Good job!

One issue:
It's difficult to popup the home context menu on the file manager screen, so it's difficult to quit the application.

Is this the "Known Issue" as listed in post #2 ? or something else?

[wisecrick]

Originally Posted by twobob

Is this the "Known Issue" as listed in post #2 ? or something else?

Oh yes, it is.
I make a little modification to reader.lua to correct the issue (I almost know nothing about lua ^_^)

has_close_button = false 
->
has close_button = true

function FileManager:onClose(), insert
exitReader()
before
return true

[thomass]

Originally Posted by wisecrick

Oh yes, it is.
I make a little modification to reader.lua to correct the issue (I almost know nothing about lua ^_^)

redader.lua, line 151:
from

has_close_button = false

to

has close_button = true

redader.lua, line 173:
from:

	function FileManager:onClose()
		--UIManager:quit()
		return true
	end

to:

	function FileManager:onClose()
		--UIManager:quit()
		exitReader()
		return true
	end

Thanks for this tip.To have a bigger "close icon" I also changed 68th line of frontend\ui\widget\menu.lua to something like that:

		text = "-[ X ]-    ",

[PaulFreund]

Thank you very much, this wonderful software makes reading PDFs on the kindle bearable for me! (Duokan has similiar PDF capabilities, but its closed and has a few drawbacks such as loading time)

I would like to return the favour, but at the moment I don't have much time or money. I saw the source of koreader-base is well written and in c/c++. So if you need someone for testing or a debug session or even small implementations i'd be glad to devote a few hours.

I know this kind of offer is hard to evaluate but if you're interested just send me a task you'd like to get done.

Thanks again,

Paul