Instructions for patching firmware 3.18.0

[StillReading]

GeoffR, you were referring to an unhinted font in a previous post in this thread. May I ask why you've explicitly stated that the font is unhinted? I've been playing around with fonts on the Kobo lately, and can't find in-depth information on the web about whether it makes sense or not to remove the hinting info from fonts for use on eBook readers, specifically the Kobo H2O. I'd be thankful for any info on the subject.

[GeoffR]

Originally Posted by StillReading

GeoffR, you were referring to an unhinted font in a previous post in this thread. May I ask why you've explicitly stated that the font is unhinted? I've been playing around with fonts on the Kobo lately, and can't find in-depth information on the web about whether it makes sense or not to remove the hinting info from fonts for use on eBook readers, specifically the Kobo H2O. I'd be thankful for any info on the subject.

It is just that the Gentium Basic fonts are ones that benefit greatly from removing the hinting, so someone with the unmodified font installed might wonder why it looked so different to my screenshot.

Here is a post with screenshots comparing the hinted and unhinted Gentium Book Basic.

If the font looks good to you then I wouldn't bother removing the hinting, but if you notice that some glyphs look darker than others, or are of uneven thickness, or are just very thin; especially if the effect goes away when you increase the font size, then it might be caused by the hinting.

[StillReading]

Thanks, that was exactly the type of information I was looking for!

[Nick_1964]

In this case I am a complete newbie, but did some research, hinting would be done to make the font better visible at a low resolution (that is what I understand) but in the examples,the unhinted looks much better to me.
So the question rise, can you prevent the hinting by the device or do you have to manually adjust the fonts ?

[NiLuJe]

You can also 'fix' the broken Gentium byte code hinting by using ttfautohint, which will rebuild them using FT's autohinter .

[Diruuo]

I think this is the first time I see mention of this Reagl refresh. What is it, why is it Aura specific (I use the Aura) and what makes it different from the other refreshes.

Also in regards to the Advanced font controls... I grabbed the Literata .OTF files a while ago from somewhere on the internet and I had the impression that those should work just fine with kepubs (including the advanced font control). The font seems to be applied just fine but the Advanced font controls are not present. Do I still need to apply the patch unlocking the advanced font control or have I simply misunderstood how the kepubs interact with .OTF fonts?

[mietek81]

Would it be possible to make a patch that would center the covers and captions on home screen tiles? And it also would be great if tiles were vertically justified (and not aligned to top like now)
I know it's just pure aesthetics so I'm not expecting you to even start looking for a solution just for me but maybe some day..

And one more thing..
Is it possible to make Kobo display some parts of kobofied epub with publisher font and other with font selected from font face menu? Both fonts are on the device.

[GeoffR]

Originally Posted by Diruuo

I think this is the first time I see mention of this Reagl refresh. What is it, why is it Aura specific (I use the Aura) and what makes it different from the other refreshes.

I don't really know about Reagl, someone else can probably answer it better, but it is some sort of technique for doing a partial refresh that doesn't require a full refresh as often, but it requires some hardware support so it can't be done on devices without that hardware. The Aura is supposed to do a Reagl refresh every page and a full refresh just once per chapter, instead of an ordinary partial refresh every page and a full refresh every n-th page.

Also in regards to the Advanced font controls... I grabbed the Literata .OTF files a while ago from somewhere on the internet and I had the impression that those should work just fine with kepubs (including the advanced font control). The font seems to be applied just fine but the Advanced font controls are not present. Do I still need to apply the patch unlocking the advanced font control or have I simply misunderstood how the kepubs interact with .OTF fonts?

You still need the patch to enable advanced font controls for sideloaded fonts, unless you rename the font to 'Delima', 'Felbridge', 'Rockwell', or 'Times New Roman' (which were built-in fonts in earlier firmware versions, but have since been removed.) The only difference between ePub and KePub in this regard is that the advanced controls only work for TTF fonts in ePubs, but for both TTF and OTF fonts in KePubs.

However kerning only works with TTF fonts (if the also have 'old-style' kern tables) in Kepubs, but it with both OTF and TTF fonts (without the need for 'old style' kern tables') in ePubs. So in practice TTF is the preferred format for Kobos because it allows kerning and advanced font controls in both ePubs and KePubs.

[GeoffR]

Originally Posted by mietek81

Would it be possible to make a patch that would center the covers and captions on home screen tiles?

Possibly, ...

And it also would be great if tiles were vertically justified (and not aligned to top like now)

Not sure, but I would guess probably not, ...

And one more thing..
Is it possible to make Kobo display some parts of kobofied epub with publisher font and other with font selected from font face menu? Both fonts are on the device.

I think the patch in the following post will do what you want.

[GeoffR]

The KePub reader is very heavy-handed when a font-family other than 'Publisher Default' is selected from the font menu. This patch makes the KePub reader use a lighter-handed approach similar to the ePub reader, letting the user select a font, but allowing the publisher to overide it.

The first alternative just uses the user-selected font at <body> level, the publisher can override anything else. The second alternative forces the user-selected font to be used at <body> and <p> level, which is similar to how the unpatched ePub reader does it.

I haven't tested this patch much, it seems to work but let me know if you see any unexpected side effects.

Paste into libnickel.so.1.0.0.patch:

Spoiler:

<Patch>
patch_name = `Un-Force user font-family in KePubs`
patch_enable = `yes`
# Multi-version patch: 3.3.0 - 3.18.0+
#
# This patch allows the font-family set by the publisher in the kepub
# stylesheet to override the font-family selected by the reader from the device.
#
find_base_address = `*\0 \0{\0 \0f\0o\0n\0t\0-\0f\0a\0m\0i\0l\0y\0:\0 \0%\01\0 \0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0 \0}\0\n\0`
#
# Alternative 1: (similar to ePub with `Un-force font-family override p tags`)
#
#     * { font-family: %1 !important; }\n
# --> body{font-family:%1 !important; }\n
#
replace_string = 0000, `*\0 \0{\0 \0f\0o\0n\0t\0-\0f\0a\0m\0i\0l\0y\0:\0 \0%\01\0 \0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0 \0}\0\n\0`, `b\0o\0d\0y\0{\0f\0o\0n\0t\0-\0f\0a\0m\0i\0l\0y\0:\0%\01\0 \0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0 \0}\0\n\0`
#
# Alternatve 2: (Similar to ePub default)
#
#     * { font-family: %1 !important; }\n
# --> body,p{font-family:%1!important;}\n
#
#replace_string = 0000, `*\0 \0{\0 \0f\0o\0n\0t\0-\0f\0a\0m\0i\0l\0y\0:\0 \0%\01\0 \0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0 \0}\0\n\0`, `b\0o\0d\0y\0,\0p\0{\0f\0o\0n\0t\0-\0f\0a\0m\0i\0l\0y\0:\0%\01\0!\0i\0m\0p\0o\0r\0t\0a\0n\0t\0;\0}\0\n\0`
</Patch>

[mietek81]

So if I have an ebook about programming and program code is in something like <pre class="programs"> tag and rest of text in <p class="noindent"> tag than with patch altrnative 2 all code will be in publisher font and rest in font of my choice? Am I right?

[GeoffR]

Originally Posted by mietek81

So if I have an ebook about programming and program code is in something like <pre class="programs"> tag and rest of text in <p class="noindent"> tag than with patch altrnative 2 all code will be in publisher font and rest in font of my choice? Am I right?

It would depend on how the publisher had styled p and pre in the stylesheet. If they had something like

p {font-family: serif;}
pre {font-family: sans-serif;}

then with alternative 2, <p> should be in the user-selected font and <pre> should be in sans-serif (Avenir), while anything without a font-family style specified directly or inherited from somewhere else should inherit the user-selected font from <body>

The only difference with alternative 1 is that <p> would be in serif (Georgia).

There are lots of ways for the publisher to mess this up though, such as using <div> instead of <p> for paragraphs, using <p> for things which are not paragraphs, etc.

Edit: A simpler way to look at it is: if MyFont is the font you have selected from the font menu, then alternative 1 is like adding this to the end of the stylesheet:

body {font-family: MyFont !important;}

while alternative 2 is like adding this instead:

body, p {font-family: MyFont !important;}

(if Publisher Default is selected then nothing extra is added to the stylesheet.)

[Nick_1964]

Originally Posted by GeoffR

There are lots of ways for the publisher to mess this up though, such as using <div> instead of <p> for paragraphs, using <p> for things which are not paragraphs, etc.

That is why I always manually edit a book,I can add so many things with an extra.css but there is always one rule that make it "worthless".. 9 out of 10 the publisher tries to make the epub look exactly the same as the book,including grayscales at fonts.. almost every e-reader is capable of selecting a good font,set the margins by hand,justify txt or not,stretch the txt so it will fill the whole line,but publishers want to let it be hard coded..it is almost impossible to make a patch for this because they don't use a standard,they just try their own rules to do it and i think 90% of them doesn't even try how it looks on a e-reader... and sometimes they make you crazy the way they make the lay-out.. we try with patches to get as much as possible on a page, they use line heights of 1.6 or bigger and upper,lower,left and right margins...

[mietek81]

Ok, so I guess that it will be the same if instead of font family I have specific font (e.g for <pre> DejaVuSansMono)?

[GeoffR]

Originally Posted by mietek81

Ok, so I guess that it will be the same if instead of font family I have specific font (e.g for <pre> DejaVuSansMono)?

I'm not sure what you mean, but whatever font you select from the font menu on your device will be used for the font-family style on <body> (or <body> and <p>for alternative 2.) It doesn't matter what the name of the font is.

Edit: I have a feeling I might have misunderstood what you wanted when I said this patch would do what you want. There isn't any way to select more than one font from the device, the user can just select one font and all the others have to be specified in the book. This patch just prevents the user-selected font from overriding all the fonts specified in the book, making the KePub reader behave more like the ePub reader.