Kobo Reader Settings Tweaks

[jackie_w]

Originally Posted by EldRick

Now if someone would just locate the tables where the values are stored, and develop a patch program, I'd be Real Happy...

Yes, me too! Someone did exactly that for the Sony PRST1 and added a separate user config file to fill in the 8 font-size values you wanted to use - not as extensive as Kobo's 24 values, but at least they were your personal 8-values. Worked a treat.

[EldRick]

I find that 25 or 24 size and 1.2 line spacing works well, and gets a reasonable number of lines on a page.

I speed-read, so I like to minimize page turns.

[davidfor]

Originally Posted by jackie_w

For my own interest I decided to fill in the gaps in the Glo (fw 2.1.5) font-size details, so I may as well post them here to save anyone else the tedium (and rather a lot of crashes). The 24 values are:-
12, 14, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 28, 32, 36, 40, 44, 46, 48, 50, 52, 54, 56, 58

After reading that list, I rechecked it on my Touch. The first ten are the same as you have. I didn't go any higher. What I don't know is if I made a mistake before, or there has been a change for the Touch in the beta firmware I am running. I'll choose the latter

This has helped me understand why I'm struggling to get my 'perfect size' with some fonts, which go from 'a bit too small' to 'too large' in one step. It appears my ideal font-size is around 28-30, depending which font family is chosen. I find it odd that the granularity in the mid-range (28-44) is 4 (pts?) per click whilst it is only 2 at the top end.

I just tried an experiment. I put five copies on of the same book on my Touch, and created a content_settings record for each with the font sizes to 28, 29, 30, 31 and 32. When I looked at the books, it does seem to respect the in-between sizes. My measurement was crude, but, I the book with 30 was bigger than 28 and smaller than 32.

When I looked at line-height on the Glo I had a different minimum value to you, namely:
1.3, 1.35, 1.4, 1.6, 1.775, 1.9, 2.0, 2.2, 3.0
1.3 is a bit big for my tastes, for most fonts. I wonder how many people choose a line-height of 2+?

This time I definitely had a transposition error. I had copied the list somewhere and made a mistake. Looking back at the original notes, it is 1.3 not 1.

I have also tried setting it to 0.1, 1.0, 2.6 and 4. The 2.6 and 4 worked, but I need to redo the smaller test. I don't think they did, but my measurement was very crude. Plus I used different books which made it harder.

I agree, 15 does seem way too high, I'd prefer settings 0-5 with 1pt granularity or even 0-10 with 2pt granularity.

You might be happier in the future

Also, I will send you a PM related to this.

[EldRick]

I found this in the Developer section here - the issue being the large amount of wasted white space at the bottom of many pages, which is caused by foolish defaults for widow and orphan prevention.

In calibre, when converting a book, you can insert additional css which can override the existing settings in the book. In the Common Options/Look and Feel, Extra CSS panel, insert the following lines:

p, body{
widows: 0;
orphans: 0;
}

It seems to work well on epubs - for the first time, text uses all the usually-wasted white space at the bottom of the screen, and goes all the way down near the menu-bar area. You get several more lines/page and fewer page turns.

BIG thanks to textchimp for this one!

[bartveld]

Wow, EldRick, wonderful tip! Not only does it fill the space at the bottom, but the margins are much smaller (had mine at zero and still there was a considerable margin. Now 0 is really 0). Thanks!

[bob451]

I get, fairly consistently, 24 lines/page from epubs with "line-height: 1.2" for <p, <div, <td and <h\d, plus "widows: 0" & "orphans: 0", in the CSS.

Without those CSS entries for line-height, and with "readingLineHeight=1.2" in the .conf file, I get 23 lines/page. Explain that.

Where I don't consistently get 24 lines/page is for "long" paragraphs, that is, any paragraph of more than about 300 words. The html renderer on the Kobo Touch, presumably ADE, usually decides to throw a "page-break" before a "long" paragraph and, for a "longer" paragraph, throws further "page-breaks" in the middle of the paragraph. (The Kobo Original did something similar for paragraphs of more than about 500 words.)

The worst case is a "longer" paragraph at the start of a chapter: the successive screen "pages" display:
1. Chapter Title lines (2. 24 lines 3. 24 lines 4. 4 lines)...

It can look quite awful, especially where the first page of a chapter displays only the heading.

I get around the problem by inserting a "paragraph-break" (</p><p class="pb">) to the left-hand margin on the next line, at the end of a sentence after no more than about 250 words in the paragraph. That works for both indented- and line-spaced-paragraphs. While not looking ideal, it does at least show that it is a formatting break and not a real paragraph break.

Does anyone have a simpler solution? Don't say, "Use shorter paragraphs"; it's not my text. ADE seems to ignore all "page-break-...: avoid" directives in the CSS.

[EldRick]

Explain that.

Easy explanation - the Kobo software has significant bugs re. page and paragraph breaks. Best you can do is learn to live with it at this time.

[davidfor]

Originally Posted by bob451

I get, fairly consistently, 24 lines/page from epubs with "line-height: 1.2" for <p, <div, <td and <h\d, plus "widows: 0" & "orphans: 0", in the CSS.

Without those CSS entries for line-height, and with "readingLineHeight=1.2" in the .conf file, I get 23 lines/page. Explain that.

From some experiments, it looks like the minimum line height setting in the file or content_settings table is about 1.225. But, if the line height is set in the epub, it can be whatever you want.

I tested this by creating an epub with the following in it:

  <p>1<br />
  2<br />
  3<br />
  4<br /></p>

Except that it went to 40. I then made four copies and the numbers 1 to 5 in the titles. Then I put them on my Touch. After that I created the five entries in the content_settings table for the books. The font was set to Georgia, size 17 with margins of zero. I then played with different numbers in the line height setting. Then I disconnect the device and looked at each book and recorded the last number displayed. After a bit of playing, I got:

1.2	        32
1.225	32
1.25	        31
1.275	30

The first number is the line height, the second is the last number displayed on the page. Any number less than 1.225 gave 32 lines.

Then I edited a couple of the files and added line heights to the CSS. I tired 1.0 and 0.1. 1.0 put all 40 lines on the screen. 0.1 did as well, but they overlapped and covered less than a quarter of the screen.

Where I don't consistently get 24 lines/page is for "long" paragraphs, that is, any paragraph of more than about 300 words.

I haven't tried anything with very long paragraphs, so have no suggestions. But, reading this has mad me flashback to having to read "Washington Square" in high school. The book had the smallest font for a novel I have ever read and had a lot of paragraphs that were more than a page long. It was the most boring and hard to read book I have ever read. I'm not sure if I ever manage more than a page in one sitting.

[bob451]

Originally posted by EldRick
Easy explanation - the Kobo software has significant bugs re. page and paragraph breaks. Best you can do is learn to live with it at this time.

"At this time" has been going on for years, ever since the Kobo Original. Who has much hope that such problems (with ADE?) are ever going to be addressed, let alone fixed?

Originally posted by davidfor
From some experiments, it looks like the minimum line height setting in the file or content_settings table is about 1.225. But, if the line height is set in the epub, it can be whatever you want.

That's interesting. Why have such a high minimum of 1.225, instead of, say, 1.0?

The line-height: values in the CSS seem to have to be much lower for sideloaded and embedded fonts; for one (standard font, including yogh characters) that I tried, I had to get down to line-height: 1.04 for a reasonable number of lines/page (but then, such fonts are no longer rendered on the Kobo as well as they were previously).

I got to 24 lines/page with line-height: 1.2 in the CSS, a font size of 24, and all margins of 0, by trial and error for firmware 2.0.0 (also worked for 2.0.4).

Lo and behold, when I upgraded to 2.1.4/5, the display changed to 23 lines/page (the minimum bottom margin set by the Kobo seemed to increase slightly). Since hyphenation still has bugs in 2.1.4/5, and since the handling of dictionaries in 2.1.4/5 seemed miles worse than in 2.0.4, I went back to 2.0.4 (hyphenation is off).

I think I may stick with 2.0.4, since with various workarounds it more or less does what I want. Non-aggressive hyphenation that worked properly would be a bonus.

Upgrading to any firmware release after 2.1.4/5 would be the usual lottery. I think of the Kobo firmware, since it hails from North America, as NTSC: Never The Same Code (twice).

Originally posted by davidfor
"Washington Square" ... had a lot of paragraphs that were more than a page long.

Victor Hugo can do sentences of more than 300 words, never mind paragraphs.

[EldRick]

Who has much hope that such problems (with ADE?) are ever going to be addressed, let alone fixed?

I gave up on hoping that Kobo would address obvious bugs a long time ago, and have perforce learned to live with some them because the tradeoffs of the Kobo shortcomings vs. other alternatives falls on the Kobo side for me at this time.

However, it's not an ADE issue, as I have only non-DRM epubs on my Glo.

I will never buy books from Kobo or B&N as long as they use DRM.

[robko]

Originally Posted by EldRick

However, it's not an ADE issue, as I have only non-DRM epubs on my Glo.

I could be mistaken, but isn't the display driver for ALL epubs (as opposed to kepubs) ADE based even if it doesn't have DRM on it.

[davidfor]

Originally Posted by bob451

"At this time" has been going on for years, ever since the Kobo Original. Who has much hope that such problems (with ADE?) are ever going to be addressed, let alone fixed?

That could be one of the problems. A lot of what we are seeing when reading an epub is ADE. I assume that Kobo has to wait for fixes from Adobe.

That's interesting. Why have such a high minimum of 1.225, instead of, say, 1.0?

And then they chose 1.3 as the minimum that can be set through the font dialog. Playing with setting in the CSS a bit more and don't like 1.0. The text is to close. I have been happy with 1.3, but I might try 1.225 for a while.

The line-height: values in the CSS seem to have to be much lower for sideloaded and embedded fonts; for one (standard font, including yogh characters) that I tried, I had to get down to line-height: 1.04 for a reasonable number of lines/page (but then, such fonts are no longer rendered on the Kobo as well as they were previously).

For kepubs, all the settings seem to be treated as larger values than in epubs.

I got to 24 lines/page with line-height: 1.2 in the CSS, a font size of 24, and all margins of 0, by trial and error for firmware 2.0.0 (also worked for 2.0.4).

Lo and behold, when I upgraded to 2.1.4/5, the display changed to 23 lines/page (the minimum bottom margin set by the Kobo seemed to increase slightly). Since hyphenation still has bugs in 2.1.4/5, and since the handling of dictionaries in 2.1.4/5 seemed miles worse than in 2.0.4, I went back to 2.0.4 (hyphenation is off).

I think I may stick with 2.0.4, since with various workarounds it more or less does what I want. Non-aggressive hyphenation that worked properly would be a bonus.

Upgrading to any firmware release after 2.1.4/5 would be the usual lottery. I think of the Kobo firmware, since it hails from North America, as NTSC: Never The Same Code (twice).

Unfortunately, most development is like this, though a lot of times, fixing a bug reveals other bugs that just couldn't be reached before. For me, I am happy with the reading experience and the changes elsewhere (shelves and series info) are improvements I want. Hyphenation was bad at one point, but I haven't noticed a problem for a while.

[DNSB]

Originally Posted by EldRick

I gave up on hoping that Kobo would address obvious bugs a long time ago, and have perforce learned to live with some them because the tradeoffs of the Kobo shortcomings vs. other alternatives falls on the Kobo side for me at this time.

However, it's not an ADE issue, as I have only non-DRM epubs on my Glo.

I will never buy books from Kobo or B&N as long as they use DRM.

As far as I know, any epub file used the Adobe code whether it is DRMed or not. As the about file says, "contains Reader Mobile software under license from Adobe Systems Inc".

[bob451]

The way in which ADE on the KT is liable to throw a screen-break before a "long" paragraph, and to throw further screen-breaks within a "longer" paragraph, is quite noticeable for a font size of 24. (That corresponds roughly to "Medium" on the Kobo Original.)

For the next font size down on the KT, the effect is nowhere near as noticeable.

I suspect it is related to the way in which ADE determines what is a "page". In the Adobe document, "EPUB Best Practices", is the following section:

Synthetic page names

When page map is not available in the document, Adobe Digital Editions will synthesize a page-map based on the document content. The approach used is the following:

1. Determine a compressed byte length of each resource which is referenced in the spine, subtracting any known encryption overhead (IV size)

2. Assume that there is a page for each 1024 bytes in each resource, rounding up to the nearest whole number of pages for each resource

3. To map page breaks into a resource, use the number of pages for the resource as determined in step 2, count the number of Unicode characters in the resource; distribute synthetic page breaks in the resource evenly between the characters by dividing the number of characters by the number of pages; if the number of characters don't divide evenly among the pages, round the number of characters per page up and let the last 'page' contain less characters than the rest.

That typically means a bit more than 500 "words" per "page". For my setup with font size 24, that corresponds to perhaps 54 screen lines (over 2 screens with 24 lines/screen).

If text for a "resource" (chapter) were to flow continuously from screen to screen, each synthetic "page" may begin at any screen line; a synthetic "page" will usually not correspond to an integral number of screens. Thus, it would be ridiculous for ADE to have a new synthetic "page" start on a new screen, and it doesn't do that normally. The "page" number, whether for display or navigation purposes, simply need refer to the screen display containing the "page" break.

Why then is ADE liable to throw a screen-break before a "long" paragraph, and to throw screen-breaks within "longer" paragraphs? It seems to depend on the current position within the synthetic "page", the current position on the screen, and the length of the paragraph (or the remaining number of screen lines in a "longer" paragraph); different "long" paragraphs of identical numbers of screen lines may show different screen-breaks.

For some reason, ADE seems to confuse "screen-breaks" and "page-breaks". And I can't for the life of me see why it needs to do that. In practice, for a font size of 24, to keep "screen-break-before" occurrences down to an acceptable level and to eliminate "screen-break-within" occurrences, I have found it necessary to restrict "paragraphs" to about 250 words.

I did try epubs with a page-map file to tell ADE that the resource (chapter) has no pages (<page name="" .../>), so that each chapter appeared to be of 1 page (it was a useful way to get rid of the RHS page number displayed on the Kobo Original). No change: ADE still threw screen breaks in the same places, so it was still working on synthetic pages internally.

[Mrs_Often]

Anybody know whether you can set orphan and widow values in the Kobo eReader.conf ?