Instructions for patching firmware 3.16.0

[GeoffR]

Originally Posted by forster01

But i cant make on change that i would like to: I cant chande inital font size from 12 to 18. I could really use some help:

# Start with this font size: (GloHD, Others)
replace_int = 87B38E, 14, 14
replace_int = 87B392, 12, 18

Is this the line that should look like this? or i'm doing something wrong?

Yes that is the correct change to make for devices other than the GloHD. It should result in the font size slider starting at size 18 instead of 12, so there will be 6 fewer options to choose from on the slider. I just tested it and it works on my Glo.

Edit: Also check that you have set patch_enabled = `yes`. This patch is not enabled by default, since the font size choices in the unpatched firmware are now much better than they used to be.

[forster01]

Thanks mate!

[GeoffR]

Could someone with a Mac help me with this?

In Linux I can set the permissions of NEWFILE to be the same as the permissions of OLDFILE with the command:

chmod --reference=OLDFILE NEWFILE

Does this work on the Mac, or is there another way to do it?

[NiLuJe]

@GeoffR:

OS X's chmod version doesn't seem to support the reference flag, so I'd go with a stat+chmod combo, something like:

chmod $(stat -f %Lp OLDFILE) NEWFILE

(And, yes, stat is also wildly different from the Linux version, where that would look like stat -c %a OLDFILE)

[GeoffR]

Originally Posted by NiLuJe

chmod $(stat -f %Lp OLDFILE) NEWFILE

Thanks, I'll use that.

[Gabriel.Voyager]

Thanks to all who help me upgrading my Aura H2O
I've installed the 3.16 Mark4 and then patched it
Work perfectly!

But now is off, i use always the Glo HD... is so perfect for me

[forster01]

Originally Posted by GeoffR

Yes that is the correct change to make for devices other than the GloHD. It should result in the font size slider starting at size 18 instead of 12, so there will be 6 fewer options to choose from on the slider. I just tested it and it works on my Glo.

Edit: Also check that you have set patch_enabled = `yes`. This patch is not enabled by default, since the font size choices in the unpatched firmware are now much better than they used to be.

I'm doing something wrong obviously, cuse nothing happens... i.e. initial epub size starts at 12... I still have to press + 5 times

[GeoffR]

Originally Posted by forster01

I'm doing something wrong obviously, cuse nothing happens... i.e. initial epub size starts at 12... I still have to press + 5 times

The initial size when you open the book should be whatever size you last set. If you had it set to 12 before applying the patch it will still be set at 12 after the patch has been applied, until you change it.

But if that is not what you mean then I don't know what is happening, it works on my Glo and from what I can tell in the code the AuraHD should start at the same size as the Glo, but I have no way to test on any device other than a Glo.

To test if the patch is active you can try counting the number of positions on the slider, i.e. start at the smallest size and press + until you reach the end. If the patch has been applied with the size starting at 18 then there should be 44 positions on the AuraHD, or 50 if the patch hasn't been applied.

Edit: Another possibility is that the The AuraHD and H2O are using the GloHD settings, if that was the case then the slider would have 48 positions, starting at size 14.

Edit2: Also the best way to check for sure what font size has been set by the slider is to look at the value of readingFontSize that gets saved in the device's configuration file, as the publisher can change the base font size for the book.

Edit3: After looking at what you wrote again, it might just be that the patch doesn't do what you think it does. All this patch does is change the font sizes that can be selected from the slider. The font size you select from the slider is not necessarily the size that appears on the screen, as that depends on the book's stylesheet. So if you select a font size of 18px, one book might display it as 18px, another might display it as 24px, another as 15px, depending on what base size the publisher has used for the book. If you are trying to get the fonts to be the same size in all your books then you can't do that with a patch, you would need to edit each book and make the base font size to the same value.

[GeoffR]

I've updated the attachment to post #1 to include the `Enforce user line spacing in ePubs` patch, however this patch can no longer be used together with the `ePub fixed/adjustable top/bottom margins` patch, because I couldn't fit both patches in the available space for the EPUB stylesheet.

I've attached a copy of the patch here for those who want to paste it into their existing libnickel.so.1.0.0.patch file instead of downloading the zip attached to post #1:

Spoiler:

<Patch>
patch_name = `Enforce user line spacing in ePubs`
patch_enable = `no`
#
# This patch cannot be enabled if the `ePub fixed/adjustable top/bottom margins`
# patch is enabled.
#
# This patch causes the line spacing setting selected from the reading settings
# (Aa) menu to be applied at body and paragraph level, instead of just at body
# level. This will result in the user-selected line spacing setting taking
# effect in some books where it wouldn't before, but there will still be some
# books where it won't take effect (such as those where the publisher has used
# <div> instead of <p> for paragraphs), and some books where it does take
# effect when it shouldn't (such as those where the publisher has used <p>
# instead of <h1>, <h2>, etc. for headings). The only way to get perfect
# results is to edit the epub and fix the problems at source.
#
replace_string = B2FBE8, `\x20\0l\0i\0n\0e\0-\0h\0e\0i\0g\0h\0t\0:\0 \0%\01\0 \0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0\n\0`, `}\0b\0o\0d\0y\0,\0p\0{\0l\0i\0n\0e\0-\0h\0e\0i\0g\0h\0t\0:\0%\01\0!\0i\0m\0p\0o\0r\0t\0`
replace_string = B2FC34, `\x20\0p\0a\0d\0d\0i\0n\0g\0-\0b\0o\0t\0t\0o\0m\0:\0 \0%\01\0e\0m\0 \0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0\n\0`, `a\0n\0t\0}\0 \0b\0o\0d\0y\0 \0{\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0\n\0`
</Patch>

(I don't know if this patch is really very useful, because the way the stylesheet cascade works in the EPUB reader means the line spacing set in th book's stylesheet by the publisher will still have priority in most cases. The way that Calibre 'flattens' the stylesheet during conversion can also result in the line spacing becoming fixed so that this patch can't override it, even if the original book didn't have the problem.)

[GeoffR]

The Dutch hyphenation dictionary hyph_nl.dic that comes with the firmware contains two faults:

1. Although marked as UTF-8, hyph_nl.dic is actually encoded as ISO8859-1. I am not sure if this creates an actual problem in practice, but my guess is it could cause problems for words which contain non-ascii characters. The hyphenation dictionaries for all other languages are correctly encoded as UTF-8.

2. The LEFTHYPHENMIN and RIGHTHYPHENMIN settings are missing from hyph_nl.dic. This probably means that these settings default to 2, which results in extremely aggressive hyphenation, and is more likely to expose any faults in the dictionary or hyphenation algorithms. Most other languages have them set to 5.

AFAIK these faults have been present in the hyph_nl.dic in all firmware versions, but with the changes to the KEPUB hyphenation in firmware 3.16.0 they may have become more noticable.

I've attached a copy of a patched hyph_nl.dic which fixes these two problems. Because the hyph_nl.dic that comes with the Kobo firmware is identical (apart from being incorrectly marked as UTF-8) to the one available from OpenTaal.org I think it is okay to distribute a modified version from OpenTaal.org here. I have included the licence in Dutch and English. The only modifications I have made to hyph_nl.dic are to encode it as UTF-8 using iconv, and to add LEFTHYPHENMIN 5 and RIGHTHYPHENMIN 5 lines.

All you need to do to replace the hyph_nl.dic on your device with the patched one is to extract the attached ZIP file and copy the KoboRoot.tgz it contains into the.kobo directiory of your device and safely eject. It is safe to use this file on older firmware versions too.

Edit: Note that updating the firmware replaces this dictionary with the original faulty one, so if you want to continue using this dictionary then you'll need to re-install it after each firmware update.

[JSWolf]

Originally Posted by GeoffR

2. The LEFTHYPHENMIN and RIGHTHYPHENMIN settings are missing from hyph_nl.dic. This probably means that these settings default to 2, which results in extremely aggressive hyphenation, and is more likely to expose any faults in the dictionary or hyphenation algorithms. Most other languages have them set to 5.

I find that left and right set to 5 is too large. I think both values should be set to 3. That reduces the gaps more and give more hyphens.

[Nick_1964]

Something strange, in kepub, font Amasis, when I put the linehight to low or to high, the latest line of txt is not displayed well, it looks like the footer is shifting over it.
I do use the showPageHeader=false line in the conf. file.
Is it because I made the page xx of xx a little bit larger ?
When I set the linehight a bit by the slider you can see -------- at the bottom line, these are the top of the letters of the next line that is displayed on the next page, when I set the slider totally to the left, about 75% of the last line is visible, like a half s, a half e.
The new page shows the first line, and what is partially displayed on the end of the previous page,is cut off the first line.
If don't place the lineheight exact right,this is on every book.
I use all the default values in the patch for footer height, only the line for the txt height is changed, that code is:
# Replacement caption font size value for GloHD:
replace_string = 00C5, `font-size: 30px;`, `font-size: 33px;`

picture 1 shows part of the txt of the next page at the bottom, picture 2 shows the cut of first line.

[GeoffR]

Originally Posted by Nick_1964

Something strange, in kepub, font Amasis, when I put the linehight to low or to high, the latest line of txt is not displayed well, it looks like the footer is shifting over it.

This looks to me like the KEPUB page break bug that happens when the line spacing is too narrow. I think the only solution is to increase the line spacing, or use a different font, or use the EPUB reader instead.

[Nick_1964]

Originally Posted by GeoffR

This looks to me like the KEPUB page break bug that happens when the line spacing is too narrow. I think the only solution is to increase the line spacing, or use a different font, or use the EPUB reader instead.

I think I indeed must switch to EPUB, some books have forced linehight and I can't edit them all..or I have to add somehow a 5 point bottom margin ??
The fact is that the epub reader is so much slower then kepub.
I try if I can find options in the KoboTouchExtended driver to add it ( if that helps)
There is no way of fixing this bug ??
I can also look it up in the config file to see what linehight is the best.
Because when I change font, to lets say Malabar, the linehight used with amasis isn't correct to.

So switching fonts does not much, I only have to adapt the lineheight again,it seems not font related.

[booklover6]

Originally Posted by GeoffR

This looks to me like the KEPUB page break bug that happens when the line spacing is too narrow. I think the only solution is to increase the line spacing, or use a different font, or use the EPUB reader instead.

I get this problem too, if I start fiddling with line spacing or font size. I am using side loaded kepubs with Charlis SIL modified larger. (With header and footer intact). If I lessen the line spacing I normally use, the bottom cut off happens. So I generally just leave it alone.