Summary of Modified Fonts

[MGlitch]

Literata works quite well, I did end up mucking about with fontforge, and enabled kerning and removed hints. I added some weight with font control, because it was a small change. For now it's replaced Minion Pro for me.

[GeoffR]

Originally Posted by sherman

I was getting fustrated, because the newer version just wasn't being displayed by Nickel or ACCESS properly, compared to the previous version. RMSDK didn't care.

Today, I found out what the problem seems to be. It seems that Nickel and ACCESS do not like having the PANOSE information set in the font file. I set all values to 0 (any), and now there is no wackiness in either the interface (Nickel) or when reading KEPUB's.


So, it seems fonts destined for Kobo Readers should not have any PANOSE information set.

Thank you! This was the piece of the puzzle I needed to get all my sideloaded fonts to work properly with KePubs.

In each case the fonts I had that didn't work properly with KePubs had the PANOSE weight set incorrectly, I didn't need to remove the PANOSE info altogether, I just corrected the weight so it matched the actual font weights (book/bold.)

The only font that still has problems is the built-in OpenDyslexic font, so perhaps someone could tell Kobo that they need to look at the PANOSE weight for that font?

[sherman]

Originally Posted by GeoffR

Thank you! This was the piece of the puzzle I needed to get all my sideloaded fonts to work properly with KePubs.

In each case the fonts I had that didn't work properly with KePubs had the PANOSE weight set incorrectly, I didn't need to remove the PANOSE info altogether, I just corrected the weight so it matched the actual font weights (book/bold.)

The only font that still has problems is the built-in OpenDyslexic font, so perhaps someone could tell Kobo that they need to look at the PANOSE weight for that font?

It's more than just that, the original Alegreya fonts had all but weight set to 0 in the PANOSE info and it worked fine. The updated font has a lot more information included that is - as far as I can tell - correct for the font, and the Kobo did not like it at all (in fact, in both cases, the font weight was the same.).

This may require some more investigation from interested parties as to exactly what has a detrimental effect and what does not.

The only reason I thought to change the PANOSE information at all (considering I know bugger all about fonts...) is that was the only major difference I could see between the two font versions (that wasn't kerning or ligatures), so I thought aha! maybe this needs to be investigated...

[JSWolf]

Originally Posted by MGlitch

Literata works quite well, I did end up mucking about with fontforge, and enabled kerning and removed hints. I added some weight with font control, because it was a small change. For now it's replaced Minion Pro for me.

Bad idea to remove hinting. Bad idea to add weight in FontForge before trying the advanced font controls.

[sherman]

Originally Posted by JSWolf

Bad idea to remove hinting. Bad idea to add weight in FontForge before trying the advanced font controls.

Depends on the hinting.

If a font has been "hand hinted" (usually for LCD screens), then chances are, they will look awful on the eink screen.

Case in point, The font designer of Alegreya uploaded a hand hinted True Type version of the font. I tried it on my Kobo. I removed it immediately because it looked terrible.

[doubleshuffle]

Originally Posted by sherman

Case in point, The font designer of Alegreya uploaded a hand hinted True Type version of the font. I tried it on my Kobo. I removed it immediately because it looked terrible on my Kobo.

Looks great with the hinting removed, but with the hinting it was horribly irregular.

[davidfor]

Could this be a Qt issue? I know Kobo is using this for other font related functions, so this could be a shortcoming there.

[GERGE]

Originally Posted by JSWolf

Bad idea to remove hinting. Bad idea to add weight in FontForge before trying the advanced font controls.

Look, I will explain this for the last time and stop repeating myself from now on.

Hinting, by its very nature, is for the screens. It does interpolation of the pixels so that glyphs would seem more natural, more like print. Hinting instructions tells the renderer which pixels are to be interpolated. But the screens the hinting is designed for are all geometrically aligned and that is why analysis works and interpolation happens so beautifully.

On the other hand, eInk capsules aren't geometrically aligned, they are like this: https://upload.wikimedia.org/wikiped...rocapsules.png (this is from a Kindle)

There absolutely no way hinting that depends on any kind of a geometrical premise would work and there is no system of hinting I know of that doesn't depend on it. For that to happen the system needs to analysis the eInk capsules and the placement of the glyphs on the page, create hinting instructions for every glyph, and do the hinting. All of them on the fly and page-to-page basis. Our eReaders don't have this kind of resources to use effectively yet.

I have no idea why you keep telling that hinting works, that is a mathematical impossibility; anything that works, works by accident.

And about the advanced font controls, it is just a hack. Adding weight to glyphs by automation requires advanced algorithms and analysis. While Kobo's hack works, it messes up the balance. Sometimes a leg becomes thicker, sometimes height becomes uneven, sometimes we lose sharpness... I mean, it is just a fast hack. But adding weight by using algorithms of FontForge (or Glyphs, the one I use) offers much better end results. It might be destructive but no one is forcing you to erase the source.

[kacir]

Originally Posted by GERGE

Hinting, by its very nature, is for the screens. It does interpolation of the pixels so that glyphs would seem more natural, more like print. Hinting instructions tells the renderer which pixels are to be interpolated.

No.
Once upon a time, when looked at text, fonts looked extremely ugly. They were stair-stepped. Each pixel was either 100% foreground color or 100% background color.
Then somebody invented anti-aliasing. Anti-aliasing works this way: Pixel doesn't have to be either black or white, it can have 256 shades of grey, depending on how much of the pixel would be white and how much would be black if the font border line went through the pixel.
This works nice for letters like "S" that are all curves, but not with horizontal and vertical lines. If the letter 'I', for example, was rendered big enough, so that the stem was wide several pixels it didn't matter that the border pixels were grey. But if it was about 1 pixel wide you had to force the borders of the stem so they are located on the borders of the pixels, so instead of two pixels with 50% grey you get 1 pixel with 100% black and surrounding pixels are white. To get this, you have to round the dimensions of letters so that the borders of letters fall exactly between pixel borders.
BUT, when you start rounding you might get capital "I" where left serif is 2 pixels wide and right serif is 1 pixel wide. This is why Microsoft started using hinting. Hinting is set of rules saying how the dimensions are supposed to be rounded - so that, for example, you do not get letter "T" with one arm shorter than the other.

Hinting information is basically a set of instructions, similar to assembly code that tells computer how to round the dimensions, so that all stems of letters are same width, all serifs are same dimensions, ...

Nowadays, there are lots of clever algorithms baked into the [font] rendering libraries, and the computers have enough processing capacity so even without hinting info contained within the font you get nice looking letters on the screen. Plus, most of the hinting info in the font is automatically generated. Still, hand-tweaked hinting info inside the font provides even better results. This is A LOT of work and this is the reason why one good font costs lots of money.

Originally Posted by GERGE

On the other hand, eInk capsules aren't geometrically aligned, they are like this: https://upload.wikimedia.org/wikiped...rocapsules.png (this is from a Kindle)

There absolutely no way hinting that depends on any kind of a geometrical premise would work and there is no system of hinting I know of that doesn't depend on it.

Yes, you are right, capsules do not fall into the grid, but the underlying electronics that manipulates the capsules clearly does. I can see that on the linked picture.

[John F]

Originally Posted by GERGE

Look, I will explain this for the last time and stop repeating myself from now on.

Hinting, by its very nature, is for the screens. It does interpolation of the pixels so that glyphs would seem more natural, more like print. Hinting instructions tells the renderer which pixels are to be interpolated. But the screens the hinting is designed for are all geometrically aligned and that is why analysis works and interpolation happens so beautifully.

On the other hand, eInk capsules aren't geometrically aligned, they are like this: https://upload.wikimedia.org/wikiped...rocapsules.png (this is from a Kindle)

There absolutely no way hinting that depends on any kind of a geometrical premise would work and there is no system of hinting I know of that doesn't depend on it. For that to happen the system needs to analysis the eInk capsules and the placement of the glyphs on the page, create hinting instructions for every glyph, and do the hinting. All of them on the fly and page-to-page basis. Our eReaders don't have this kind of resources to use effectively yet.

I have no idea why you keep telling that hinting works, that is a mathematical impossibility; anything that works, works by accident.

And about the advanced font controls, it is just a hack. Adding weight to glyphs by automation requires advanced algorithms and analysis. While Kobo's hack works, it messes up the balance. Sometimes a leg becomes thicker, sometimes height becomes uneven, sometimes we lose sharpness... I mean, it is just a fast hack. But adding weight by using algorithms of FontForge (or Glyphs, the one I use) offers much better end results. It might be destructive but no one is forcing you to erase the source.

Excuse the ignorant question, but for eink aren't the cells geometrically aligned? At 300 dpi, isn't that good enough for hinting to be helpful?

[kacir]

Originally Posted by John F

Excuse the ignorant question, but for eink aren't the cells geometrically aligned?

Yes, they are aligned.
I am talking about cells of electronics that "flip the bits". The tiny capsules that contain the particles are non-uniform and smaller than the grid of electronics. See picture linked to the post you are answering

Originally Posted by John F

At 300 dpi, isn't that good enough for hinting to be helpful?

The higher the resolution, the less need for hinting.
An old monitor running at 640x480 had pixels much more visible to the naked eye than on a 6" screen with 1430x1080 pixels.

[GeoffR]

If you're not sure about the hinting the best thing is just to try the font with and without hints and see which looks better to you.

I haven't yet found a font that looks better with hinting, but I have found some that look much much better without hinting. Edit: For most of them the hinting has no noticable effect one way or the other, so I might as well remove the hinting to save some memory.

[GERGE]

Maybe we had a bit of miscommunication there but what I mean by interpolating the pixels is the same thing you are saying. Hinting alignes to the grid, plays with the stem weights... As far as I am aware, hinting changes which pixels the glyphs are rendered upon.

So, this is interpolating, interpolation means creating new data points by using known data; that is, changing the pixels it is rendered upon.

And while the roots of cells geometrically aligned, I don't think this means much in the end. It can be likened to holding many helium filled balloons in your hand. You can keep the strings in your hand pretty well organized, but how would the balloons look? I am aware that this is not a good analogy, but the relationship between the electronic grid and capsules in the screen aren't so dissimilar.

Not even the size of capsules are similar on epaper, here is another picture: https://c2.staticflickr.com/4/3101/2...c1d423bf_m.jpg (I have no idea which ereader this is, but this is clearly epaper)

[sherman]

So I found another issue with fonts last night, I don't know whether this is a known issue or not.

It seems that if you have two fonts named like so:

Alegreya
Alegreya SC

and install them on the kobo, then RMSDK at least does not like it. I did not test ACCESS. In my case, when I installed the Alegreya SC font, it started started displaying in place of the standard Alegreya variant, despite the standard variant being set in the menu.

To solve this, I simply had to change the font name of the small caps variant to remove the space.

So it would seem that if you have to versions of a font, and the names up to the first whitespace are identical, there will be problems.

[GeoffR]

Originally Posted by sherman

So I found another issue with fonts last night, I don't know whether this is a known issue or not.

It seems that if you have two fonts named like so:

Alegreya
Alegreya SC

and install them on the kobo, then RMSDK at least does not like it. I did not test ACCESS. In my case, when I installed the Alegreya SC font, it started started displaying in place of the standard Alegreya variant, despite the standard variant being set in the menu.

To solve this, I simply had to change the font name of the small caps variant to remove the space

I have seen something similar, but I'm not sure exactly what the rule is.

I have "Gentium Basic" and "Gentium Book Basic" installed and have no problems at all.

I also have "Tex Gyre Adventor", "TeX Gyre Bonum", "TeX Gyre Pagella", and others which have no problems.

But I tried "Courier Prime" and "Courier Prime Sans" and had problems, only the Sans could be selected in the EPUB reader.

So it would seem that if you have to versions of a font, and the names up to the first whitespace are identical, there will be problems.

Perhaps the rule is that the font can't be selected if there is another that has the same name apart from extra words at the end?