googlefonts / googlefonts/fontmake
OTF export looks...awful?
- Dominant language
- Python
- Stars
- 888
- Forks
- 97
- Avg merge
- 4d 52m
- Merged PRs (30d)
- 1
Description
I have a UFO source which I am trying to export using `fontmake`. The `ttf` looks great, but the `otf` looks horrendous! At small sizes, not only is it greyscale (which I never specified—the `ttf` has proper subpixel rendering) but it is pixelated and looks way heavier than it should. I would just run with `ttf`, but I feel like `otf`, being more modern, should be the better of the two! I would prefer to use `otf` anyway because the filesize is smaller and I drew the font using cubic curves, meaning the quadratic conversion is at play with the `ttf`.
This screenshot shows: (left) TTF export with `fontmake`, (middle) OTF export with `fontmake`, and (right) OTF export from FontForge.

The FontForge OTF export used to look like the `fontmake` OTF export, but I fixed the issue by manually setting StdHW, StdVW, StemSnapH and StemSnapV (they were previously "guessed" by FF). Mysteriously, *removing* these values from fontinfo.plist in the generated UFO improves it significantly:

However, it is still in greyscale in the font viewer, which isn't right. I also feel that removing this information must be detrimental to the rendering in some way.
Another thing I noticed is that all of the OTFs become a dark mess when rendered at smaller and smaller ppem sizes, even with the stem-snap values removed:

but the TTF seems to retain a more sensible (and consistent) color at the same size (ignoring the bold text—the font currently only has regular weight):

This is even more apparent in apps like LibreOffice, with the difference being visible even at normal reading sizes.
Are these problems just inherent to `otf`? Is this how it's supposed to be? Am I doing something wrong, or is there something `fontmake` can do to make `otf` render as well as `ttf`?
Contributor guide
Assessment
This issue has not been assessed yet.