Kobo stock reader vs KOReader rendering

[jospalau]

I get most of my books from Amazon and convert them to epub.

This time I tried with an epub I downloaded from Standard Ebooks (I found this site in this forum).

They render the chapter header differently. I checked Calibre and it renders it the same way than KOReader:

Does the stock kernel ignores font-variant: small-caps;?
Why I is cursive? It should be bold according to the styles
It also ignores some other margin stuff.


I know you always clean the epubs to make them look like you want, so you can tell me what is going here.

[JSWolf]

Originally Posted by jospalau

I get most of my books from Amazon and convert them to epub.

This time I tried with an epub I downloaded from Standard Ebooks (I found this site in this forum).

They render the chapter header differently. I checked Calibre and it renders it the same way than KOReader:

Does the stock kernel ignores font-variant: small-caps;?
Why I is cursive? It should be bold according to the styles
It also ignores some other margin stuff.


I know you always clean the epubs to make them look like you want, so you can tell me what is going here.

Attachment 207945

The ePub reading software is an older version of RMSDK that doesn't do ePub 3 all that well. small-caps is not supported.

Please get an ePub from the MR library. ePub from StandardEbooks do not always work well with RMSDK on a Kobo. So the results can be different from ePub via RMSDK and ePub via KOReader.

Try this one as I did the formatting and I know it will work well on both RMSDK and KOReader. https://www.mobileread.com/forums/sh...d.php?t=177182

[jospalau]

Understood.

There you are.

[JSWolf]

Originally Posted by jospalau

Understood.

There you are.
Attachment 207948

This is very interesting. I don't think I'd know any difference looking at one or the other. But together, you do see that KOReader can use a smaller space and/or some tighter kerning.

[jospalau]

Originally Posted by JSWolf

This is very interesting. I don't think I'd know any difference looking at one or the other. But together, you do see that KOReader can use a smaller space and/or some tighter kerning.

I agree

Sent from my 22081212UG using Tapatalk

[NiLuJe]

As was mentioned earlier, KOReader implements a tiny subset of micro-typography magic to contract/expand inter-word ("Word Spacing" in the settings) and inter-letter ("Word Expansion") whitespace.

That's in addition to using a modern harfbuzz, which should yield proper (or at least, "as intended by the font foundry") kerning. Where you might see larger divergences in terms of kerning are outside of LGC, for complex scripts that only fairly recently got better support in harfbuzz.

That's not to say I wouldn't expect *any* kerning differences even on LGC, simply because text rendering is *hard*, and everyone kind of does its own thing, so unless you *know* the stack is *also* FT + HB, you're kind of comparing apples to oranges (which is not always uninteresting in this context, mind you ). (spoiler alert: I'm not sure anything actually uses FT + HB outside of the Qt UI on Nickel, RMSDK does its own thing, and Access is using Monotype's iType font engine)

On that front, Adobe tends to do its own thing (and to do it rather well, I might add. It's been a while, but I distinctly remember Acrobat Reader being something that rendered text exceedingly well, even on low DPI screens (i.e., an LCD monitor), even on systems with *very* opinionated native font rendering (i.e., macOS and Windows).

I also vaguely remember that you had to be very persistent to get one or both of these to handle kerning properly, at the expense of possible rendering bugs (the whole prefer-speed or prefer-legibility css property or something. Might be only for Access, though).

[JSWolf]

Originally Posted by NiLuJe

As was mentioned earlier, KOReader implements a tiny subset of micro-typography magic to contract/expand inter-word ("Word Spacing" in the settings) and inter-letter ("Word Expansion") whitespace.

That's in addition to using a modern harfbuzz, which should yield proper (or at least, "as intended by the font foundry") kerning. Where you might see larger divergences in terms of kerning are outside of LGC, for complex scripts that only fairly recently got better support in harfbuzz.

That's not to say I wouldn't expect *any* kerning differences even on LGC, simply because text rendering is *hard*, and everyone kind of does its own thing, so unless you *know* the stack is *also* FT + HB, you're kind of comparing apples to oranges (which is not always uninteresting in this context, mind you ). (spoiler alert: I'm not sure anything actually uses FT + HB outside of the Qt UI on Nickel, RMSDK does its own thing, and Access is using Monotype's iType font engine)

On that front, Adobe tends to do its own thing (and to do it rather well, I might add. It's been a while, but I distinctly remember Acrobat Reader being something that rendered text exceedingly well, even on low DPI screens (i.e., an LCD monitor), even on systems with *very* opinionated native font rendering (i.e., macOS and Windows).

I also vaguely remember that you had to be very persistent to get one or both of these to handle kerning properly, at the expense of possible rendering bugs (the whole prefer-speed or prefer-legibility css property or something. Might be only for Access, though).

Yes, that is only for Access.