Instructions for patching firmware 4.32.19501

[JSWolf]

There was a trick to allow you to reference fonts from the fonts directory as though they were embedded fonts. I don't know if it still works in 4.32.

@font-face {
font-family: monospace;
font-style: normal;
font-weight: normal;
src: url("res:///fonts/normal/Dark Courier");
}
@font-face {
font-family: monospace;
font-style: normal;
font-weight: bold;
src: url("res:///fonts/bold/Dark Courier");
}
@font-face {
font-family: monospace;
font-style: italic;
font-weight: normal;
src: url("res:///fonts/italic/Dark Courier");
}
@font-face {
font-family: monospace;
font-style: italic;
font-weight: bold;
src: url("res:///fonts/bolditalic/Dark Courier");
}

[Acopdegarrotix]

It worked until 4.31, not anymore. Epubs are still fine, though.

[jackie_w]

Originally Posted by JSWolf

There was a trick to allow you to reference fonts from the fonts directory as though they were embedded fonts. I don't know if it still works in 4.32.

That still works for epub, although kobopatch Default ePub monospace font was equally good. Neither ever worked for kepub.

Using your "Dark Courier" example, pre-4.32 all that would have been required for kepub was

1. coding font-family:"Dark Courier";, rather than font-family:monospace; in the various CSS styles.
2. making sure you had already sideloaded the Dark Courier*.ttf files.

As it stands in 4.32, for kepubs you also need to embed the "Dark Courier" ttfs and add @font-faces to CSS, instead of step 2. Not difficult for one book but incredibly tedious and a diskspace hogger if a lot of books are affected.

I think I'll solve my own problems by automating the embedding (when required) on-the-fly during calibre's send-to-device.

Trying to develop something generic which would work for all users, all abilities, any font(s) using KoboTouchExtended or Kepubify would be more of a challenge, I think.

[JSWolf]

Originally Posted by jackie_w

That still works for epub, although kobopatch Default ePub monospace font was equally good. Neither ever worked for kepub.

Using your "Dark Courier" example, pre-4.32 all that would have been required for kepub was

1. coding font-family:"Dark Courier";, rather than font-family:monospace; in the various CSS styles.
2. making sure you had already sideloaded the Dark Courier*.ttf files.

As it stands in 4.32, for kepubs you also need to embed the "Dark Courier" ttfs and add @font-faces to CSS, instead of step 2. Not difficult for one book but incredibly tedious and a diskspace hogger if a lot of books are affected.

I think I'll solve my own problems by automating the embedding (when required) on-the-fly during calibre's send-to-device.

Trying to develop something generic which would work for all users, all abilities, any font(s) using KoboTouchExtended or Kepubify would be more of a challenge, I think.

Thank you for all of this.

I do have Courier Prime as my monospace font for ePub. I'm going to have to test out if the added weight will work for Courier Prime if used as font-family: monospace; in ePub.

[jesson345]

Originally Posted by jackie_w

Firstly, in fw 4.32.19501 patch Un-Force user font-family in KePubs, with the option 3 you've selected, is working the same as it always has done. I know this because I use it myself.

I believe the font problems you are seeing in your screenshots are due to the major changes Kobo have made to font handling. This has particularly affected certain kepubs where some convenient undocumented "font tricks", which used to work pre-4.32, no longer do. I know this because ~50% of the kepubs loaded on my own Kobos are affected by this change.

If you understand HTML/CSS the following info may be of interest.

-------------------------------------------

Some general background pre-4.32 ...
The official standard way to make your book display fonts referenced by name (e.g. font-family: "My Special Fontname") in the epub/kepub's internal CSS is to embed all those named fonts into the book and include matching @font-face statements in the CSS to link the font to the relevant embedded .ttf or .otf file. As long as you've done it correctly it will work in Kobo epubs and kepubs with a caveat for kepubs:

• on an unpatched Kobo you must also select "Publisher Default" from the [Aa] font menu.
• if you apply kobopatch Un-Force user font-family in KePubs you can select any font you like from the [Aa] font menu.

Publishers don't have a choice, they have to follow the standards. But for your own books ... no-one really wants to spend time embedding fonts if there's an easier way.

Fortunately, for kepub users, there *was* an easier way pre-4.32. I've never seen it documented as a supported feature, so maybe it was just a "happy accident". You didn't need to embed any font files or add any @font-face statements to CSS. If the kepub internal CSS contained any style

font-family: "My Special Fontname";

then the kepub reading app could "find" the font to display if it was present in your Kobo's sideloaded /fonts directory with the correct "My Special Fontname" internal name and external filename(s).

Fw 4.32 onwards ...
Unfortunately this kepub undocumented feature no longer works. I have no idea whether it is due to collateral damage from all the font-related changes in fw 4.32 or a deliberate removal of some old code.

Selecting a sideloaded font from the [Aa] font menu should still work in the same way it always has done for the main body text in kepubs.

-------------------------------------------

What can you do about it? I don't think there is a painless answer unless Kobo see the current situation as a bug (unlikely, but you never know) and "fix" it in a future fw. Special named fonts (e.g. for fancy headings, dropcaps, monospace, true small-caps, ...) will need to be embedded to be visible in kepubs.

THX,a lot of information。

I will study the information here carefully。

[jesson345]

Originally Posted by Acopdegarrotix

I can confirm jesson345's findings. But the issue affects only kepubs. Up until 4.31, both were OK even without applying the patch.

Thx,I will try the sample epub.

[konstantinus]

Originally Posted by jackie_w

I think I'll solve my own problems by automating the embedding (when required) on-the-fly during calibre's send-to-device.

I've done this before (not in Calibre), it's not a problem. The problem is that advanced settings (Publisher Default) do not affect the embedded font, but which is simply specified in CSS - they do. I had to go back to the previous firmware.

[jackie_w]

Originally Posted by konstantinus

I've done this before (not in Calibre), it's not a problem. The problem is that advanced settings (Publisher Default) do not affect the embedded font, but which is simply specified in CSS - they do. I had to go back to the previous firmware.

I don't understand exactly what you're trying to say. Can you rephrase with more details, please?

FWIW the sentence you quoted from my previous post is what I've actually put in place since I posted it. I don't like it at all as a "solution" but it does work OK for my limited needs. However, I did need to make significant code changes to my customised KoboTouchextended calibre driver to do it. It's not going to be a realistic option for most users.

[MGlitch]

I asked over in the 4.32 firmware thread but I suspect it got buried and really it’s more of a patch question anyway.

With the whole WebKit rendering option in the config file do we need to use the patches that do something similar to them? Are they both getting to the same goal in different ways, or would they work together? And if they do work together could they be combined with a non matching option, e.g legibility and precision one from the configuration file the other from the patches?

For those who don’t know it was discovered you can add the following to the config file:

[Reading]
webkitTextRendering=*

Where the value is one of the following
optimizelegibility
geometricPrecision
optimizeSpeed
auto

[jackie_w]

Originally Posted by MGlitch

I asked over in the 4.32 firmware thread but I suspect it got buried and really it’s more of a patch question anyway.

With the whole WebKit rendering option in the config file do we need to use the patches that do something similar to them? Are they both getting to the same goal in different ways, or would they work together? And if they do work together could they be combined with a non matching option, e.g legibility and precision one from the configuration file the other from the patches?

For those who don’t know it was discovered you can add the following to the config file:

[Reading]
webkitTextRendering=*

Where the value is one of the following
optimizelegibility
geometricPrecision
optimizeSpeed
auto

Sorry, I must have missed your question in the other thread. This is my current understanding of the state of play...

The 2 existing kobopatches,

1. KePub stylesheet additions - optimizeLegibility
2. KePub stylesheet additions - optimizeSpeed

are no longer required because, in fw 4.32, Kobo have provided an alternative (unannounced) way of achieving the same result by adding an extra line to your Kobo's config file (.kobo/Kobo/Kobo eReader.conf)

1. If you usually enable kobopatch KePub stylesheet additions - optimizeLegibility (in libnickel.so.1.0.0.yaml) to enable kepub ligatures/kerning then you can now disable it.
   
   Instead, manually edit the Kobo config file with your text editor to add this line to all the other lines under the existing [Reading] section header
   

   webkitTextRendering=optimizelegibility

2. If you usually enable kobopatch KePub stylesheet additions - optimizeSpeed (in libnickel.so.1.0.0.yaml) for whatever kepub benefits you feel it gives you (which doesn't include ligatures/kerning) then you can now disable it.
   
   Instead manually edit the Kobo config file with your text editor to add this line to all the other lines under the existing [Reading] section header

   webkitTextRendering=optimizespeed

I don't believe there's any actual harm leaving the patches enabled after editing the Kobo config - but it's pointless. In addition, the contents of the Kobo config file will survive a firmware upgrade whereas kobopatches won't. Besides, you need to convince yourself that the new "Kobo config method" adequately replaces the old "kobopatch method" on your own Kobos

Assuming nothing unexpected crawls out of the woodwork, I'll be retiring both of the above kobopatches at the next firmware upgrade.

P.S. Before anyone asks, I've no idea what you should expect to see on your Kobo if you set the config file to either of the following options:

webkitTextRendering=auto
webkitTextRendering=geometricprecision

I'll leave that as an exercise for another curious mind.

[rtiangha]

Originally Posted by jackie_w

P.S. Before anyone asks, I've no idea what you should expect to see if you set the config file to either of the following options:

webkitTextRendering=auto
webkitTextRendering=geometricprecision

I'll leave that as an exercise for another curious mind.

According to spec, with auto, fonts under 20pt are rendered with optimizeLegibility, while fonts larger than 20pt are render with optimizeSpeed. But that's assuming the renderer Kobo is using works like other webkit-based renderers. Ditto for geometricPrecision; heck, Firefox-based renderers ignore it and treat it as optimizeLegibility.

[MGlitch]

Thanks Jackie, the other thread got pretty busy with cross chatter about another users Kobo issues and the new word count etc changes, so easy to miss things.

Another user had posted this for what each should do:

https://developer.mozilla.org/en-US/...text-rendering

Though I’d bet you’re already familiar with that, hopefully it’ll give others an idea.

I’ve only just started using the legibility patch this firmware (I did disable it when I edited the config file) and in my limited use thus far they seem comparable. At some point I might sit down with the two Formas I have get their settings to be the same and aside from the patch vs config file and see if there’s a difference that can be spotted. But that’s going to wait until next weekend at least.

[codychan]

Originally Posted by jackie_w

Firstly, in fw 4.32.19501 patch Un-Force user font-family in KePubs, with the option 3 you've selected, is working the same as it always has done. I know this because I use it myself.

I believe the font problems you are seeing in your screenshots are due to the major changes Kobo have made to font handling. This has particularly affected certain kepubs where some convenient undocumented "font tricks", which used to work pre-4.32, no longer do. I know this because ~50% of the kepubs loaded on my own Kobos are affected by this change.

If you understand HTML/CSS the following info may be of interest.

-------------------------------------------

Some general background pre-4.32 ...
The official standard way to make your book display fonts referenced by name (e.g. font-family: "My Special Fontname") in the epub/kepub's internal CSS is to embed all those named fonts into the book and include matching @font-face statements in the CSS to link the font to the relevant embedded .ttf or .otf file. As long as you've done it correctly it will work in Kobo epubs and kepubs with a caveat for kepubs:

• on an unpatched Kobo you must also select "Publisher Default" from the [Aa] font menu.
• if you apply kobopatch Un-Force user font-family in KePubs you can select any font you like from the [Aa] font menu.

Publishers don't have a choice, they have to follow the standards. But for your own books ... no-one really wants to spend time embedding fonts if there's an easier way.

Fortunately, for kepub users, there *was* an easier way pre-4.32. I've never seen it documented as a supported feature, so maybe it was just a "happy accident". You didn't need to embed any font files or add any @font-face statements to CSS. If the kepub internal CSS contained any style

font-family: "My Special Fontname";

then the kepub reading app could "find" the font to display if it was present in your Kobo's sideloaded /fonts directory with the correct "My Special Fontname" internal name and external filename(s).

Fw 4.32 onwards ...
Unfortunately this kepub undocumented feature no longer works. I have no idea whether it is due to collateral damage from all the font-related changes in fw 4.32 or a deliberate removal of some old code.

Selecting a sideloaded font from the [Aa] font menu should still work in the same way it always has done for the main body text in kepubs.

-------------------------------------------

What can you do about it? I don't think there is a painless answer unless Kobo see the current situation as a bug (unlikely, but you never know) and "fix" it in a future fw. Special named fonts (e.g. for fancy headings, dropcaps, monospace, true small-caps, ...) will need to be embedded to be visible in kepubs.

I'm using Un-Force user font-family in KePubs patch, and I enable Alternative 3 instead of Alternative 1 to make the multiple-font work. It has been working for a long time, I can confirm that it doesn't work for current firmware/patch v4.32.19501. It doesn't work, I mean, I use a font specific for some parts in my book's css, but Kobo won't use it, it fallbacks to the default font instead, I can change the font in Kobo's Aa for those parts in my book that I haven't set font, so technically the multiple-font feature can still be working but I cannot choose the font I need in css's file.

[jackie_w]

Originally Posted by rtiangha

According to spec, with auto, fonts under 20pt are rendered with optimizeLegibility, while fonts larger than 20pt are render with optimizeSpeed. But that's assuming the renderer Kobo is using works like other webkit-based renderers. Ditto for geometricPrecision; heck, Firefox-based renderers ignore it and treat it as optimizeLegibility.

Yes, I read the spec and what I should have said is

... I've no idea what you should expect to see on your Kobo if you set the config file to either of the following options ...

I've updated my post accordingly.

[codychan]

Originally Posted by codychan

I'm using Un-Force user font-family in KePubs patch, and I enable Alternative 3 instead of Alternative 1 to make the multiple-font work. It has been working for a long time, I can confirm that it doesn't work for current firmware/patch.

Originally Posted by jackie_w

To add a bit more detail to @geek1011's comment ...

Kobo seems to have completely re-worked the way fonts are handled by the GUI. The outcome is that trying to customise font-family in the following 4 patches is now very limited:

1. Dictionary text font-family/font-size/line-height (libnickel.so.1.0.0.yaml)
2. Custom header/footer captions (nickel.yaml)
3. Custom page navigation scrubber (nickel.yaml)
4. Customise Header back button (nickel.yaml)

If you have been using any of the above patches to customise things other than font-family (e.g. font-size, line-height, ...) then those customisations should continue to work the same as they ever did.

Based on my limited testing, if your font-family customisation in patches 2,3 or 4 was to change Georgia --> Avenir or
Avenir --> Georgia
then there is a fair chance that will still work as it did before v4.32.19501.

In patch 1, the only font-family customisation I could make work at all was to changeGeorgia --> sans-serif
which I suspect is not particularly useful to most users.

Unrelated to the above 4 patches, a font-family GUI customisation which *does* still work (at least for now) is to completely replace the default system GUI fonts, Georgia and/or Avenir, with "better" fonts for your language. If you have the technical skills to already be doing this then everything should continue to work the same as it did before v4.32.19501.

I'll update this post if I discover anything new, related to font-family, that might be useful to others.

ETA: If you try to patch to a font-family other than Georgia/Avenir you won't get your chosen font after installation. Instead you'll get a fallback font (Kakugo, I think) which is one of the built-in CJK system fonts.

I'm using Dictionary text font-family/font-size/line-height (libnickel.so.1.0.0.yaml), I only need to enable it, and the font in my popup sideloaded dictionary works in in prev-v4.32.19501, but it doesn't work for v4.32.19501, and I tried to uncomment
```
# - ReplaceString: {Offset: 54, Find: "Georgia ", Replace: "sans-serif", MustMatchLength: yes}
```

Or replace sans-serif with my sideloaded font, it doesn't work either, some characters won't be displayed in it.