Koreader running on Kobos (all of them, hopefully!)

[lohtse]

Originally Posted by tshering

My koreader folder is the same as in koreader-kobo-arm-linux-gnueabihf-v2013.03-631-g92ede68.zip; with the exception of the small change in input.lua. All other changes as producing history files and reading settings will be done by koreader itself.

what changes to the .lua files did you do?

[tshering]

Originally Posted by lohtse

what changes to the .lua files did you do?

I did these changes. But since you might not have a C/newer Touch model (cf. this post), these changes might not be applicable in your case, cf. this post.

[tshering]

Originally Posted by giorgio130

I see, so x and y are swapped on newer touch models. We should find out a way to distinguish between the two models...

From the rcS of FW 2.10.0 I learned that only if /usr/local/Kobo/pickel can-upgrade returns 1, the reader accepts an update file. So maybe this can distinguish between older an newer Touch models. On my Touch C the return value is 1.
Edit: This seems to check the charge of the battery rather than the model.

[Ken Maltby]

Establishing if something "works on a 'kobo touch'", is very much complicated by there being actually three different models, that are called kobo touch. Add to that the impact of different firmware, that effects most devices. As well as the different builds, and it can be hard to know for sure what may be needed to get a "Touch" working. That assumes that there is nothing wrong with that particular Touch.

No answer, but just an explanation for all the questions and the need to try so many different things, to isolate the problem(s).

Luck;
Ken

[Ken Maltby]

Originally Posted by jshzh

Thank you, Ken and Giorgio.

The Koreader seems to work properly now - mostly - except that the non-English book titles appear as question marks ????? in the "history" list. Under "FileManager" everything is displayed properly. Should I move or add "fonts" somewhere else?

It looks like that has been fixed https://github.com/koreader/koreader/pull/358 it will probably be in the next build.

I think this demonstrates the vast superiority of a development community supported project over the corporate controlled development. At least in regards to responding to the user's needs.

Luck;
Ken

[jshzh]

Originally Posted by Ken Maltby

It looks like that has been fixed https://github.com/koreader/koreader/pull/358 it will probably be in the next build.

I think this demonstrates the vast superiority of a development community supported project over the corporate controlled development. At least in regards to responding to the user's needs.

Luck;
Ken

Can't wait.

There is no doubt about it. Had I not discovered the Koreader project first, I wouldn't have bought the Aura HD.

[rehemiau]

I have a problem with defaults from default.lua.
Everything in pdfs is too light on my kobo mini, so I wanted to make it darker by default.
I changed "DKOPTREADER_CONFIG_CONTRAST = 1.0 " to 0.5, and when I open a fresh .pdf I do have "darker" option selected, but my contrast isn't "darker", it gets "darker" only if i click it.
Any ideas why is it happening?

[jshzh]

Based on my rudimentary experience with Koreader, I'd like to suggest three functions the developers may want to consider adding to pdf/djvu (not re-flowed) part of the project. I apologize if they are already available in the current release or others have brought these up before.

1)One extra line from the last screen page in pdf/djvu. Very often, an original page of a book is divided into three parts for landscape mode and the last line of the current screen (same as the first line of the next) may be split in the middle. The result is this line can't be easily read either on the current screen page nor the next screen page. It is necessary for the last split line to get displayed in full in the next screen page.

2)Demarcation that indicates where the last screen page ends in pdf/djvu files. This is very much needed for the last screen section of the original page because there are usually only a few lines remaining to be shown but since the last portion of the original page is so shorter that many lines from the previous screen page are shown on top of the new lines. One has to go through this last screen page and figure out where the few unread lines begin. It would to be of great help to have a dividing line that indicates where the last screen page ends.

3)It would be more convenient if the "fit the width" option become more "sensitive". Pdf and djvu files often contain pages in which the content doesn't lie in the middle. It makes things worse that the left and right margins are often not the same on odd and even pages. For instance, on odd pages the left margin is 1" and right 1.5" while on even pages left 1.5" and right 1", or vice versa. Using the manual cutting option will end up leaving blank space either on the left or right in order for every page to be complete. The auto and semi-auto margin cutting in Koreader - I might be wrong - couldn't fit the width to the maximum possible. That makes the slightly larger screen of Aura HD pointless and text on smaller screens less readable. I think the zoom (fit the width) /edge cutting functions can be optimized. The old Pocketbook software seems to be able to detect the difference in margins and always fit the real content width after the percentage of zoom or "fit width" is set.

Thank you again for the great work done in this project.

[louden]

I've been using koreader on my aurahd for a few days - and, although you may think it takes a bit of grooming - but I really like using skim (on mac os) to chop off white space and put documents in an aspect ratio perfect for koreader.

It makes reading technical pdf's pretty awesome.

[chrox]

Originally Posted by jshzh

Based on my rudimentary experience with Koreader, I'd like to suggest three functions the developers may want to consider adding to pdf/djvu (not re-flowed) part of the project. I apologize if they are already available in the current release or others have brought these up before.

1)One extra line from the last screen page in pdf/djvu. Very often, an original page of a book is divided into three parts for landscape mode and the last line of the current screen (same as the first line of the next) may be split in the middle. The result is this line can't be easily read either on the current screen page nor the next screen page. It is necessary for the last split line to get displayed in full in the next screen page.

2)Demarcation that indicates where the last screen page ends in pdf/djvu files. This is very much needed for the last screen section of the original page because there are usually only a few lines remaining to be shown but since the last portion of the original page is so shorter that many lines from the previous screen page are shown on top of the new lines. One has to go through this last screen page and figure out where the few unread lines begin. It would to be of great help to have a dividing line that indicates where the last screen page ends.

3)It would be more convenient if the "fit the width" option become more "sensitive". Pdf and djvu files often contain pages in which the content doesn't lie in the middle. It makes things worse that the left and right margins are often not the same on odd and even pages. For instance, on odd pages the left margin is 1" and right 1.5" while on even pages left 1.5" and right 1", or vice versa. Using the manual cutting option will end up leaving blank space either on the left or right in order for every page to be complete. The auto and semi-auto margin cutting in Koreader - I might be wrong - couldn't fit the width to the maximum possible. That makes the slightly larger screen of Aura HD pointless and text on smaller screens less readable. I think the zoom (fit the width) /edge cutting functions can be optimized. The old Pocketbook software seems to be able to detect the difference in margins and always fit the real content width after the percentage of zoom or "fit width" is set.

Thank you again for the great work done in this project.

Suggested solutions:
1) (no problem in scroll mode) In page mode you need to turn on the "DSHOWOVERLAP" option in defaults.lua by changing line 35 into

DSHOWOVERLAP = true

2) (no problem in scroll mode) Same as in 1).

3) Manual cropping will remember cropping box for odd page number and even page number so you only need to define page boxes for two pages(an odd page and an even page) if the content boxes are regular in all pages. If not, auto/semi-auto page cropping will be useful to automatically crop the white margins. In auto/semi-auto cropping mode additional page margins are added around calculated content area. Fortunately the additional margin sizes are totally customizable in koreader although its not accessible in the graphic user interface. You can edit the line 64 of "frontend/ui/data/koptoptions.lua" and change

values = {0.05, 0.10, 0.15},

into comfortable values. And you may also need to change the default page margin at around line 47 in defaults.lua. To make edited options take effect in previously opened books, you need to select corresponding options in the bottom configuration panel at least once.

[jshzh]

Originally Posted by chrox

Suggested solutions:
1) (no problem in scroll mode) In page mode you need to turn on the "DSHOWOVERLAP" option in defaults.lua by changing line 35 into

DSHOWOVERLAP = true

2) (no problem in scroll mode) Same as in 1).

3) Manual cropping will remember cropping box for odd page number and even page number so you only need to define page boxes for two pages(an odd page and an even page) if the content boxes are regular in all pages. If not, auto/semi-auto page cropping will be useful to automatically crop the white margins. In auto/semi-auto cropping mode additional page margins are added around calculated content area. Fortunately the additional margin sizes are totally customizable in koreader although its not accessible in the graphic user interface. You can edit the line 64 of "frontend/ui/data/koptoptions.lua" and change

values = {0.05, 0.10, 0.15},

into comfortable values. And you may also need to change the default page margin at around line 47 in defaults.lua. To make edited options take effect in previously opened books, you need to select corresponding options in the bottom configuration panel at least once.

Thank you, chrox.

I know nothing about Linux but I am using Editpad Lite 7 now to configure the values, following your suggestions. 1) and 2) work perfectly.Odd and even page manual cropping also works well.

As to auto/semi-auto cutting, since I have no idea how the calculation is done, I wonder what the default page margin means/is for. It is set to 0.10 currently in the range of 0-1. If I set it to 0.5, does it mean that the auto/semi-auto will cut off 0.5 and up (+0.05, 0.10, 0.15) based on its calculation? By the same token, I also wonder what [CODE]values = {0.05, 0.10, 0.15} means. The finer the difference between the values, the more accurate the cutting? Auto cutting will choose the closest of the following three (0.55, 0.60, 0.65) if the default is 0.5) in accordance with its calculation?

Edited: In my current experiment, I set the default to 0.5 and [CODE]values = {0.2, 0.3, 0.4} When I choose auto cutting, the margin seems not cut at all. When I choose semi-auto cutting, the adjustable frame is huge and I can only move the left and bottom sides together, the other two sides invisible - the result is nothing gets cut. Manual cutting stops working too.

If I don't change the [CODE]values = {0.05, 0.10, 0.15} and set default to 0.5, nothing gets cut. I haven't tried if with this configuration manual cutting works.

I actually read your old posts on this margin cutting issue and the conversation between you and talemix but still couldn't figure out how it is supposed to work. Maybe there is a tutorial somewhere online? This is the impression I got from reading old posts and my experiment:

For both scanned and text-based pdf files:
1) Auto cropping won't be auto. The margin to be cut in auto is determined in previous settings semi-auto and the margin is fixed with a lot of blank space. "Fit the width of contents" is not a snug fit.
2) Semi-auto setting that fits the content snugly won't stay after quitting the setting. If one switch to manual at this stage, the snug semi-auto setting is there, click ok, the setting will be kept through manual. However, this setting is not sensitive to the position of the content in each page. You mentioned that this sensitivity is the advantage of auto/semi-auto cropping. The position of the cropping frame is fixed like settings made directly via manual.

[chrox]

The values in page margin option are in inch for "small" "medium" and "large" margin respectively. So probably you may need to set the values to {0.0, 0.05, 0.1} and select "small" margin in the config panel so that no additional margins are added.

[jshzh]

Originally Posted by chrox

The values in page margin option are in inch for "small" "medium" and "large" margin respectively. So probably you may need to set the values to {0.0, 0.05, 0.1} and select "small" margin in the config panel so that no additional margins are added.

Done, best cropping ever in an e-reader!
Just one more question. I reset previously-opened books to auto (from manual). The 0/small added margin setting couldn't take effect - 0.1" margin was still added. In new books auto is default so they open with snug cropping on every page.

[chrox]

Originally Posted by jshzh

Done, best cropping ever in an e-reader!
Just one more question. I reset previously-opened books to auto (from manual). The 0/small added margin setting couldn't take effect - 0.1" margin was still added. In new books auto is default so they open with snug cropping on every page.

Although the config panel shows page margin as "small" which is set 0 in your case, the reader may use a previously stored value, probably 0.1 as its the default value, unless you re-select the "small" page margin option. It should be verified by the history file of the document which stores document specific parameters in the history directory in the main directory of koreader.

[jshzh]

Originally Posted by chrox

Although the config panel shows page margin as "small" which is set 0 in your case, the reader may use a previously stored value, probably 0.1 as its the default value, unless you re-select the "small" page margin option. It should be verified by the history file of the document which stores document specific parameters in the history directory in the main directory of koreader.

Got it. I thought by "config panel" you meant the defaults.lua. I changed the default margin to small (0) but didn't realize there was an option for margin size under the "column mode" icon in the bottom config bar. If fact, it was set the large after I changed the defaults.lua because the previous default - "medium" (0.05,0.10,0.15) is the current "large" (0.0, 0.05, 0.1).

Thank you again!