tonsky
Add .otf back in for KDE users who want gamma-corrected rendering
KDE qt5 does gamma-corrected rendering of fonts, but only .otf.
On my system I have font hinting turned off completely.
Can you add .otf back in to the release, so that I can have proper gamma-corrected Fira Code on my desktop?
More info:
TTF (e.g. Noto Sans, Ubuntu)
No stem darkening and no gamma corrected alpha blending
Fonts appear too thin on dark backgrounds (e.g. dark themes, terminal applications)
Fonts appear too bold on light backgrounds
Prone to color fringing when using subpixel antialiasing
OTF (e.g. Cantarell)
Stem darkening and gamma corrected alpha blending (this is how it is done on macOS and Windows)
Fonts look nice on both light and dark backgrounds
Color fringing is not an issue.
Interesting! Do you have any docs that confirm that the file extension is the primary cause of this?
This is the doc from the qt foundation confirming that only otf's are treated this way
"Enabled stem-darkening and gamma-correction on OpenType fonts on platforms that use FreeType, if supported."
https://doc.qt.io/qt-5/whatsnew59.html
I am not an expert, but my understanding is that a .otf file can contain .ttf or .otf, but not the reverse. It's not the extension that's important, but that the font has to be OpenType in the first place. Is Fira Code an otf font?
Also "The correct way of rendering a glyph image on a surface is to alpha blend it onto the surface in linear space and then apply gamma correction to translate the linear coverage map to something that is correct for our screens.1 No toolkit in the Linux ecosystem does it by default, even though Qt5 and Skia can and will do it on other platforms. Windows and Mac OS X do it natively. "
https://www.freetype.org/freetype2/docs/text-rendering-general.html
I think it is turned on in more recent versions of KDE Plasma.
I am confused as well, but according to this: https://github.com/tonsky/FiraCode/issues/939#issuecomment-640757377 yes, .ttf has opentype font, but truetype outlines and truetype container.
Can you confirm that when you switch between otf/ttf from e.g. https://github.com/tonsky/FiraCode/releases/tag/4 it turns gamma correction on/off? Maybe attach some screenshots?
Hi. Yes a definite difference. Tested with v4. Look how much darker the .ttf is [2nd image]!
I think you will need to download these and zoom in
Also, this is on a white background. On a coloured or black background the problems with .ttf will be even greater, which is why alpha blending and gamma correction are important.
Interesting! Can you try it on the latest version too, please (attached)? Just to confirm that file extension is the trick
FiraCode OTF-TT files have extensive hinting. Of course they look darker than some Freetype canned rendering for OTF-PS files. There is no "defect" in FiraCode fonts which needs to be fixed here. It is just different. Just like the rendering on the Mac is just different. Your personal preference for the minor differences resulting from a different rendering engine is not a reason to resurrect the OTF-PS files - and all of the other baggage that comes with it.
I have hinting turned off so there is no auto-hinting above. It is darker because it is incorrectly blended to the background.
Alpha blended and gamma corrected rendering is the correct method. It is used in Windows and OS X for both .ttf and .otf. Especially if you have a non-white background, or non-black text, then you just end up with an uneven mess without it. Unfortunately Linux support is limited to .otf
Screenshots are a poor way of showing what I am talking about, but there is a definite difference switching between the two formats. I attach photos of my 4K screen with a solarised background theme. It will be even worse on a 1080p screen.
I'm sure many Linux users will be using Fira Code with coloured or black background, in which case they are currently experiencing an inferior rendering of it. Look at the details lost in the letters i , r, and g in the ttf.
(ttf second)
Also I have noticed that some Linux apps when needing bold, apply a false-bold to the regular .ttf version instead of using the bold version, even though it is available. With .otf the bold version is used.
It will be shame if you cannot fix this.
Ok, (hopefully) last thing so that we get to bottom of this. Can you compare these two for me? I turned off hinting in both, so that we can make sure it’s the file format and not anything else
P.S. is your primary problem with TTF its width? Have you tried Retina weight? Does it work better for you?
Photos of unhinted font (ttf second). Again the .ttf is generally less evenly rendered and there is a loss of small details. It's hard to convey this in photos, but it is obvious when viewing directly. It doesn't get better with other weights.
None of this is surprising. It's just that Freetype currently uses Adobe's CFF high quality rendering engine for .otf which includes the features mentioned earlier, and a less sophisticated engine for .ttf.
so that we can make sure it’s the file format and not anything else
This is called Stem Darkening, a FreeType feature which work only with OpenType/CFF (.otf) fonts. https://freetype.org/freetype2/docs/hinting/text-rendering-general.html
One of the reasons why otf is preferred on Linux.
This is called Stem Darkening, a FreeType feature which work only with OpenType/CFF (.otf) fonts. https://freetype.org/freetype2/docs/hinting/text-rendering-general.html
One of the reasons why otf is preferred on Linux.
Hi there @HanabishiRecca, stranger passing by. I believe stem darkening is also available for TTF through AutoFitter. I have an environment variable that enables stem darkening system-wide for all fonts including OTF and TTF and it works:
FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0"
Add this to /etc/environment and restart the computer.
I believe stem darkening is also available for TTF through AutoFitter.
Unfortunately it does not work for me. With the variable set, difference is still very noticable:
- TTF
- OTF
Interesting! Can you try it on the latest version too, please (attached)? Just to confirm that file extension is the trick
@tonsky Just to add feedback, @taprobane99 insights on this has led me to try to replace as many .ttf fonts with .otf on KDE as I can. To me, .otf looks much better:
TTF
OTF
@cdock1029 this must be two different weights. No way TTF and OTF look that different
No way TTF and OTF look that different
They do, as already was shown multiple times in previous comments. End result depends on values from cff:darkening-parameters.
But the main point here was that freetype's stem darkening does not work with TTF at all. So OTF variants can be useful for users.
@cdock1029 this must be two different weights. No way TTF and OTF look that different
It's surprising isn't it? Makes you wonder why this isn't more understood and why at least for say hiDPI setups OTF font's aren't made available within repos for KDE distros. It's rather annoying honestly given how divergent the rendering is.
openSUSE switched Noto to OTF and many hated it as it was blurry for low dpi so they reverted. Would be nice to have choice of either without having to override all the default package fonts. Probably there are some tweaks or subtle details here but for my setup I like the OTF better.
https://www.reddit.com/r/openSUSE/comments/uxphgr/after_the_update_the_notosans_font_became_bolder/
https://bugzilla.opensuse.org/show_bug.cgi?id=1199938
for KDE distros
Btw, I don't know why this topic is so fixated on KDE. This is a whole Linux-wide issue. Basically everything on Linux uses FreeType for font rendering.
Wait these links suggest that .otf is blurry and lacks hinting, but ttf was good. Fira Code has TTF (good one)
Wait these links suggest that .otf is blurry and lacks hinting, but ttf was good. Fira Code has TTF (good one)
For low dpi screens that require strong hinting. If you use a 4k or better screen OTF will be better.
This is a matter of preference. Stem darkening generally makes fonts softer and bolder. Again, consider reading the actual technical info instead of random rants: https://freetype.org/freetype2/docs/hinting/text-rendering-general.html (The link I already posted above back in 2022, which seemingly you did no bother to read.)
Btw, this is a Mac feature initially. They also disable hinting and use grayscale antialiasing (instead of subpixel). Which does look blurry on regular low res monitors (FullHD and below), but looks great on HiDPI monitors.
But again, matter of preference.
Agree don't take my word for it or anyone else's.. and as evidenced, technical arguments maybe aren't convincing, best to just try it yourself and see.
Btw, for anyone who wants to convert arbitrary fonts from TTF to OTF, you could do the following:
- Install FontForge (usually it is a
fontforgepackage in your distro's repo). - Place your
.ttffontset into a directory and run this script in it:
for f in *.ttf; do
fontforge -lang=ff -c 'Open($1); Generate($2); Close();' "${f}" "${f%.ttf}.otf"
done
That's it. You will get .otf copy of every font in the directory.
@HanabishiRecca thanks, very useful there's no real issue if it's that easy. Is there nothing lost in translation with this technique, same as building OTF by itself? (I don't anything about how fonts are made).
Is there nothing lost in translation with this technique, same as building OTF by itself?
Well, that's complicated. TTF and OTF have major format differences. But I think it is not so different from building OTF directly. Especially if you disable hinting. At least I can't spot any difference with a naked eye.
So
- TTF does hinting, but not stem darkening, best for low-dpi screens
- OTF does no hinting, but does stem darkening, best for hi-dpi screens
Is that an accurate summary?
No. OTF do support hinting. It just have different kind of it. OTF is a superior format in effectively every way (more). And for anyone who does not like the stem darkening, it can be disabled globally in the system.