KoboPatch WebUI: customization (NickelMenu, KOReader) and patching via your browser

[Phil_C]

Originally Posted by MrSilverstrike

@Phil_C: I've updated the preview. Let me know if it works as you'd expect!

This is all working great.

I restored stock firmware via the WebUI on a Clara 2E and a Clara BW. Patches were created and applied with some variation between models. Perfect on both devices.

Upon reconnecting to the WebUI after patching, all patch choices, fonts and other files were remembered and restored.

The UI is really nice and works well.

One note: In FW 4.45.23697 (for Clara BW N365), there is a patch name glitch. The original patch name "Remove line from bottom tab bar via CSS" is present in the Classic Grouping. However, in the newer grouping, the patch name appears as "Remove bottom tab-bar divider". So a search for the original name did not work. When I switched to Classic Grouping, the search function found the right name. I suggest the original name should be used to avoid confusion.

There have been previous attempts to automate Kobo patching, but none looked like they were worth getting involved with.

This one is the real deal. I look forward to using your WebUI from now on. Thanks again!

[ihazcat]

wow. such a cool tool. hope one day we will get updates for all patches.

[MrSilverstrike]

I'm actually looking into an experimental approach to have LLMs/agentic coding tools figure out a way to sort of automate the necessary patch updates, so that all of the blacklisted patches all work again. @geek1011 actually pointed me in this direction.

In order to properly validate that these new patches work correctly, I will need to do some tests! If anyone is interested in testing these new experimental patches, please let me know. Obviously, I can do some of my own testing, too.

I'll report back once I've got a more conclusive view on things. It's looking pretty promising, though. This way, we might be able to get all patches to work, even on newer devices.

@Phil_C: I've addressed the name of the patch. Should be better now!

[MrSilverstrike]

Originally Posted by ihazcat

wow. such a cool tool. hope one day we will get updates for all patches.

As I noted in the post above, I'm working on it and I've had some good results. I've opened an issue here with more information: https://github.com/nicoverbruggen/ko...ebui/issues/17

I've also got an experimental version of the website up and running which supports these previously-blacklisted-but-now-working patches. I can't verify ALL of them work correctly, but I've been able to apply some of them myself.

If you'd like, you can try those here: https://kp-dev-experimental-patches.nicoverbruggen.be. As always, PLEASE make a backup before doing this, in case a hard reset is required due to a botched patch.

I'd love to get some more confirmation on that some of these now work again, as I ran out of time to continue testing today.

[Phil_C]

OK, here us my report.

The only patch that was not working for me was "My 24 line spacing values". I used your latest experimental WebUI to enable that one and disable "My 10 line spacing values".

It works! No one has been able to figure out the changes needed for it to work on the Clara BW.

If I understand, you are using Claude AI to compare differences between older and newer firmware. And AI can analyze this to make adjustments to the patches. This is quite amazing.

Looks like AI might actually do us some good before it initiates an extinction event.

[MrSilverstrike]

Yup, that's right. I'm blown away how useful these tools are and how much better it's getting, at least for programming. For everything else, it can be pretty meh.

A little update on what's next: I'll also be adding a fix for font rendering that I've been tracking down for the last few months and FINALLY resolved.

It's can be quite subtle, but if anyone is curious what I'm talking about, I've linked it here: https://github.com/nicoverbruggen/ko...t-fix/issues/5

Basically, many fonts just render incorrectly, period. It's been bothering me for so long and I'm very happy that it's 1) fixable with a mod and 2) fixable with a special font

[rantanplan]

Question:
The improved font handling option is for sideloaded epubs, correct?

[MrSilverstrike]

Originally Posted by rantanplan

Question:
The improved font handling option is for sideloaded epubs, correct?

As far as I can tell, it will be for every book that uses the Kobo renderer, so any kepub file, purchased or sideloaded will benefit from this new system.

(You really should be converting to kepub via kepubify if you aren't doing so yet. Page turns and performance is significantly better with kepub books.)

[JSWolf]

Originally Posted by MrSilverstrike

As far as I can tell, it will be for every book that uses the Kobo renderer, so any kepub file, purchased or sideloaded will benefit from this new system.

(You really should be converting to kepub via kepubify if you aren't doing so yet. Page turns and performance is significantly better with kepub books.)

I'm going to disagree with you on both counts. calibre does a good job of converting to KePub. Also, the page turn speed is significantly better then ePub with RMSDK. If you turn on kerning, ligatures, and hyphenation, it's about the same.

The one thing RKMSDK does better then KePub is typesetting. KePub can occasionally have a typesetting mistake. But RMSDK does not have such.

[MrSilverstrike]

Originally Posted by JSWolf

I'm going to disagree with you on both counts. calibre does a good job of converting to KePub. Also, the page turn speed is significantly better then ePub with RMSDK. If you turn on kerning, ligatures, and hyphenation, it's about the same.

The one thing RKMSDK does better then KePub is typesetting. KePub can occasionally have a typesetting mistake. But RMSDK does not have such.

I'm confused. The kepub renderer (based on ~2014 WebKit) is faster, that's what I'm saying and you are saying as well, no? To use it, you need kepub versions of books. If you generate them, either with Calibre or kepubify (both are great), you force your Kobo to use the kepub renderer, which is generally faster, especially on older devices. Aren't we agreeing?

Anyway, my point is: if possible, I think most people just benefit from using kepub files. It's just a plain better experience. You get chapter forecasts, faster page turns, etc. and with my upcoming mod (or modified fonts) the somewhat broken text rendering is also improved, almost on-par with KOReader in terms of fidelity, given that the pure outlines are rendered without grid-snapping, which is what the KOReader renderer does, too.

[DNSB]

Originally Posted by MrSilverstrike

I'm confused. The kepub renderer (based on ~2014 WebKit) is faster, that's what I'm saying and you are saying as well, no? To use it, you need kepub versions of books. If you generate them, either with Calibre or kepubify (both are great), you force your Kobo to use the kepub renderer, which is generally faster, especially on older devices. Aren't we agreeing?

On my Kobo Sage, I find that page turns are not noticeably faster using kepub instead of epub. RMSDK still has better typesetting than the Kobo renderer.

I have also checked speed going back though my Kobo collection to my Kobo Touch and, for me, there is no real difference with newer firmware. Sadly my Kobo and Kobo WiFi do not support kepub so no chance of testing there.

Originally Posted by MrSilverstrike

Anyway, my point is: if possible, I think most people just benefit from using kepub files. It's just a plain better experience. You get chapter forecasts, faster page turns, etc. and with my upcoming mod (or modified fonts) the somewhat broken text rendering is also improved, almost on-par with KOReader in terms of fidelity, given that the pure outlines are rendered without grid-snapping, which is what the KOReader renderer does, too.

For me, the main benefit of using kepub is the support for much more of the ePub3 spec plus oddments such as being able to accept using margin: auto,auto; to center a block.

The reading statistics are of little interest to me, with the forecasts being a source of humour more than anything else. The current book I'm reading is ~148K words and I am about 67% finished. The time already spent reading is 1.6 hours (94 minutes from my calibre statistics) minutes and ~4 hours to finish the book. So I've read ⅔ of the book and it will take me ~2.5 times longer to finish the last ⅓.

[MrSilverstrike]

I've noticed that the "time to finish the book" indeed widely varies, and it isn't particularly accurate. However, being able to see e.g. relative chapter length with a visualization is something I do find helpful, and that's kepub only, too.

I'm curious: what in particular is making you all say RMSDK has better typesetting? To clarify: I happen to agree, but I'm curious if there are things that I haven't noticed myself.

I'm asking because I'm trying to tackle as many rendering issues/deficiencies as technically possible with the mod I'm working on. In particular, so far, I've found it's possible to address the following:

A. Hyphenation, ligature rendering. This is not new: you set the WebKit rendering mode to optimizeLegibility but it causes two annoying problems (that I know of):

(1) vertical text has issues w/ CJK text
(2) text justification is broken

As far as I can tell, these weren't really fixable before. It took me some time, but I was able to address those bugs with my mod. IMO, enabling optimizeLegibility fixes much of what I'd call the deficient text rendering Kobos ship out of the box with, i.e. in terms of tracking, kerning, ligatures, etc. (A type designer actually pointed out the horrible tracking to me when I provided them with a screenshot of their typeface on my device.)

B. Text outline quality (my personal pet peeve)

This is the one I mentioned earlier in the thread that I was working on. I did quite a bit of reverse engineering to track down what was causing what people have reported as "wobbly text" in the kepub renderer for certain fonts, especially at smaller text sizes, where the renderer appears to "snap" certain text to specific pixels.

What the renderer outputs in terms of text rendering (outlines) now is quite close to what KOReader outputs, from what I can tell. KOReader, too, ignores type hints and just renders the outlines as-is by default (you do have a setting).

Anyway, once the mod is properly finalized (likely over the next few days) the plan is to integrate it as an optional-but-on-by-default mod for KoboPatch Web UI.

If anyone wants to try the mod -- feedback is always welcome! (I've tested that it works on my Clara BW, Libra Colour and Libra 2.)

EDIT: Now available on the preview website!