NickelTypeFix: a mod for better typography and typesetting (kepub only)

[rantanplan]

Originally Posted by JSWolf

Caecilla and Bookerly are ugly slabs. Why Amazon feels slabs are good I have no idea.

Maybe it's because you're in the minority?

[fogice]

Originally Posted by JSWolf

Caecilla and Bookerly are ugly slabs. Why Amazon feels slabs are good I have no idea.

I know you have Curmudgeon right under your username, but seriously, "in my opinion" goes a long way.

[DNSB]

Originally Posted by JSWolf

Caecilla and Bookerly are ugly slabs. Why Amazon feels slabs are good I have no idea.

Some people like them is likely the reason and describe them as bold, powerful, etc. Most of the people I know don't seem to notice any difference between serif and sans serif never mind what type of serif. You start talking about old style, transitional, didone or slab serifs and voila! An instant insomnia cure. My personal preferences are transitional then old style. I can live with slab but Didone is just too contrasty (thick verticals, thin horizontals) for my taste in most uses.

Of course, a lot of modern fonts are betwixt and between with the font designers incorporating parts from multiple styles. Once you know the rules, you can break them.

And Jon has always tended to post as if his opinions were carved into stone slabs carted down from a mountain top.

[ps67]

Originally Posted by JSWolf

Caecilla and Bookerly are ugly slabs. Why Amazon feels slabs are good I have no idea.

Stop trolling: it is only Your opinion: Bookerly is the best font for ebook. Yes, it is My opinion but I read with My eyes. So please don't say it anymore because You can't say that Your opinion is a truth, it is valid only for You.

PS: Your font is very bad, I know that it is My opinion and not a rule but You must understand that there are people that like slab font and particularly bookerly.

[jackie_w]

Originally Posted by Falkor

I accidentally posted this on the Nickelmenu thread, too:

The same would be nice to have for the user font. TENG overrides every single font, RMSDK only the one set in the body tag. I prefer the latter.

Kobopatch does also have a patch for this, namely Un-Force user font-family in KePubs where you can change the Nickel default override CSS for kepubs from

* { font-family: %1 !important; }

to whichever one of 3 alternatives you prefer. I choose option 3 myself but the Adobe RMSDK equivalent default for standard epubs is option 2.

1. div,p{font-family:%1!important; }
2. body,p{font-family:%1!important;}
3. body{font-family:%1 !important; }

Unfortunately Kobopatch currently only works for fw 4.x and I haven't heard (so far) that Patrick (@geek1011) has committed to updating it for fw 5.x.

[MrSilverstrike]

Originally Posted by jackie_w

Unfortunately Kobopatch currently only works for fw 4.x and I haven't heard (so far) that Patrick (@geek1011) has committed to updating it for fw 5.x.

I suspect it shouldn't be too hard to make it work with firmware 5.x. However, since the entire OS is different I suspect the majority of the patches (if not all) will require a rework.

Personally, I don't love the patch approach since any system updates undo the modifications and you are quite literally modifying the system software. I prefer more targeted mods with rollback/safety mechanisms in case something goes wrong. (They've never been easier to make in the age of agentic coding.)

It's part of why I made NickelTypeFix and the other mods, too, so I don't have to re-apply patches whenever a software update comes out every dang time to my various devices.

For 5.x, I'm working on something exciting (or, well, I'm having some agents work on some stuff that I'm reviewing) that hopefully makes it so I won't even need a NickelTypeFix for the new system software.

Hope to share more soon, but here's a hint: the built-in reader with the reliability and text rendering capabilities of KOReader

[rantanplan]

Do you think https://github.com/redphx/kobo-tweaks is better suited?

[MrSilverstrike]

For the 4.x firmware versions, kobo-tweaks is a great option if you like to tinker. It's not available for 5.x yet, I believe?

Though I can tell you: the "new" (Tolino) reader app is not good, compared to the Kobo one on firmware 4.x. It has issues with slow page turns and the way it does caching is... not how I would have done it.

[jackie_w]

Originally Posted by MrSilverstrike

For 5.x, I'm working on something exciting (or, well, I'm having some agents work on some stuff that I'm reviewing) that hopefully makes it so I won't even need a NickelTypeFix for the new system software.

Hope to share more soon, but here's a hint: the built-in reader with the reliability and text rendering capabilities of KOReader

I look forward to seeing it. I have a few questions...

1. Are your plans purely related to text rendering? I ask because quite a lot of current kobopatches are cosmetic changes to customise the look of the GUI. The latter are probably not as important but they are still nice to have.
   
2. I've been using eink readers and Android reading apps for many years now and the subject of "user override CSS" for font-family, text-align, line-height has been a constant problem which never seems to improve unless some kind community developer/hacker can create options to hand back control to the user. Is it possible to give complete control to the user by letting them maintain their own small override CSS file on the device which the reading app will use (if it exists) rather than using its own (usually bizarre) default decisions about how heavy-handed the overrides should be?
   
3. A very specific question. Do you think your new renderer will be able to deal with CSS pseudo selectors e.g. ::first-letter and ::first-line? Nickel kepubs handle them with no trouble but KOReader doesn't (unless something has changed recently).
   

[MrSilverstrike]

Originally Posted by jackie_w

I look forward to seeing it. I have a few questions...

1. Are your plans purely related to text rendering? I ask because quite a lot of current kobopatches are cosmetic changes to customise the look of the GUI. The latter are probably not as important but they are still nice to have.
   
2. I've been using eink readers and Android reading apps for many years now and the subject of "user override CSS" for font-family, text-align, line-height has been a constant problem which never seems to improve unless some kind community developer/hacker can create options to hand back control to the user. Is it possible to give complete control to the user by letting them maintain their own small override CSS file on the device which the reading app will use (if it exists) rather than using its own (usually bizarre) default decisions about how heavy-handed the overrides should be?
   
3. A very specific question. Do you think your new renderer will be able to deal with CSS pseudo selectors e.g. ::first-letter and ::first-line? Nickel kepubs handle them with no trouble but KOReader doesn't (unless something has changed recently).
   

Happy to answer them!

1. I'm currently working on a prototype that is a complete replacement for the current reader app exclusively on 5.x firmware. So it's not just text rendering, it's also providing a nicer user experience, while remaining familiar. Primary focus: speed, correct rendering, ease of use.

Some features that Kobo's built-in reader provides like text highlighting and drawing on text are not immediately planned. Currently, I'm using KOReader's engine (CREngine) for the prototype. The idea is simple: KOReader's engine letting you read your purchased books in a familiar (Kobo-like) UI.

Kobo's usual library handling does the rest: it provides the content that the engine loads, so this way I'm not bypassing DRM or something like that, which is illegal. The intention is to just provide an improved reading experience for books you legally purchased or sideloaded. Also, RMSDK still loads Adobe-compatible files. That's unchanged.

The reason I wanted to start from scratch was simple: I tried "fixing" the built-in reader. It's possible, but it's way too easy for it to become a mess to maintain. To truly make it fast, I'd need to almost entirely rework it. That would be way too brittle to do with how mods work today.

The custom reader, on the other hand, gives me much more control... and isn't that easily broken when installing updates with fewer hooks into the existing software. It could still break, but it'd be less of a pain to fix.

2. This one is tricky from a user experience point of view. I like the idea of being able to put a userstyle.css file that is always loaded and takes precedence over anything else.

3. CREngine does support both pseudo-elements, yes.

I'm not sure if I will ever release it, but I'm hopeful it might be doable based on what I've been able to build over the last week or so. If you have any feature requests or things you would love to see in a reimagined reader app/UI, do let me know. Suggestions are welcome, although I can't guarantee I will deliver everything, of course!

Edit: Here's some screenshots of the prototype to give you an idea of what it'd look like. The UI still needs a lot of polish but for a first version it is passable.

[rantanplan]

It looks nice. I pretty much now use KOReader because of the downsides of the new kobo reading engine.

I also prefer KOReaders highlighting in comparison to Nickel.

It took some time to have KOReader the way I want with all sync options and customisation but now I can just copy all relevant configuration to the next device plus reading stats sync.

[Falkor]

Originally Posted by MrSilverstrike

The reason I wanted to start from scratch was simple: I tried "fixing" the built-in reader. It's possible, but it's way too easy for it to become a mess to maintain. To truly make it fast, I'd need to almost entirely rework it. That would be way too brittle to do with how mods work today.

At one point I managed to break something (no idea how, I must have triggered some kind of bug) and TENG became quite fast. I bet there is a relatively simple way to speed it up considerably.

Btw, would it possible to enable CSS page breaks? break-before/after: column seems to be the most widely supported method for this.

[MrSilverstrike]

Originally Posted by Falkor

At one point I managed to break something (no idea how, I must have triggered some kind of bug) and TENG became quite fast. I bet there is a relatively simple way to speed it up considerably.

Btw, would it possible to enable CSS page breaks? break-before/after: column seems to be the most widely supported method for this.

TENG can be optimized, but it's likely a bunch of optimizations spread all across the reader app in a way that I can't easily fix. If TENG is fast, it's because the pages you visited were cached, and they're not always -- it's why page turns can feel very inconsistent.

I suspect most CSS you'd find in an ebook is going to work just fine, yes

[sherman]

Another option might be to try and adapt WPE Webkit if you want to use a fully featured browser engine.

[MrSilverstrike]

Originally Posted by sherman

Another option might be to try and adapt WPE Webkit if you want to use a fully featured browser engine.

Interesting! Thanks for linking. I'll check it out!