Add .otf back in for KDE users who want gamma-corrected rendering

[taprobane99]

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.

[tonsky]

Interesting! Do you have any docs that confirm that the file extension is the primary cause of this?

[taprobane99]

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?

[taprobane99]

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.

[tonsky]

I am confused as well, but according to this: #939 (comment) 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?

[taprobane99]

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.

[taprobane99]

zoomed in. ttf second

[tonsky]

Interesting! Can you try it on the latest version too, please (attached)? Just to confirm that file extension is the trick

Fira Code v6.zip

[taprobane99]

ttf 2nd. same thing. blacker/harsher blending with .ttf

[kenmcd]

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.

[taprobane99]

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.

[tonsky]

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

Fira Code v6 unhinted.zip

P.S. is your primary problem with TTF its width? Have you tried Retina weight? Does it work better for you?

[taprobane99]

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.

[HanabishiRecca]

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.

[AchillesBoi]

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.

[HanabishiRecca]

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

[cdock1029]

Interesting! Can you try it on the latest version too, please (attached)? Just to confirm that file extension is the trick

Fira Code v6.zip

@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

[tonsky]

@cdock1029 this must be two different weights. No way TTF and OTF look that different

[HanabishiRecca]

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.

[tonsky]

Okay I see

[cdock1029]

@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

[HanabishiRecca]

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.

[tonsky]

Wait these links suggest that .otf is blurry and lacks hinting, but ttf was good. Fira Code has TTF (good one)

[cdock1029]

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.

[HanabishiRecca]

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.

[cdock1029]

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.

[HanabishiRecca]

Btw, for anyone who wants to convert arbitrary fonts from TTF to OTF, you could do the following:

1. Install FontForge (usually it is a fontforge package in your distro's repo).
2. Place your .ttf fontset 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.

[cdock1029]

@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).

[HanabishiRecca]

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.

[tonsky]

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?

[HanabishiRecca]

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.

[tonsky]

Well this that OTF hinting resides in rasterizer rather than in the font. So we still have to provide TTF for Windows users.

But I can add back OTF for stem darkening alone

[HanabishiRecca]

Well yeah, TrueType is definitely preferred for Windows as it is a Microsoft's own technology. I won't be surprised if OTF rasterizer in Windows is an afterthought.

So there are no reasons not to provide all TTF/OTF/WOFF(2) as it is kinda a standard. See Source Code Pro for example.

[xalt7x]

@HanabishiRecca

This is called Stem Darkening, a FreeType feature which work only with OpenType/CFF (.otf) fonts.
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.

Unfortunately it does not work for me. With the variable set, difference is still very noticable:

- TTF - OTF

Well, according to the FreeType documentation:

auto-hinter's module name is ‘autofitter’ for historical reasons.

So, I guess, "autohint" needs to be explicitly enabled to have "stem-darkening" with TTF. (edit: incorrect, please see below)
The quick way to test is to apply globally
sudo ln -s /usr/share/fontconfig/conf.avail/10-autohint.conf /etc/fonts/conf.d/

In case that works well, consider removing file (because it will likely bring regressions for other fonts/applications)
sudo rm /etc/fonts/conf.d/10-autohint.conf

and creating a separate font config
sudo nano /etc/fonts/conf.d/99-fira-code.conf

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
<fontconfig>
   <match target="font">
     <test name="family" compare="eq" ignore-blanks="true"><string>Fira Code</string></test>
     <edit name="autohint" mode="assign"><bool>true</bool></edit>
   </match>
</fontconfig>

P.S. One of the possible "autohinter" regressions is kerning, and OTF version still looks different...

[HanabishiRecca]

So, I guess, "autohint" needs to be explicitly enabled to have "stem-darkening" with TTF.

Can you guys actually test your advices yourself instead of guessing? I tried that all already - it does not work.

The quick way to test is to apply globally

I'm fully aware how to deal with fontconfig.

[HanabishiRecca]

Here is the test setup.

fonts.conf:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <match target="font">
        <edit name="hinting" mode="assign">
            <bool>true</bool>
        </edit>
        <edit name="hintstyle" mode="assign">
            <const>hintslight</const>
        </edit>
        <edit name="autohint" mode="assign">
            <bool>true</bool>
        </edit>
    </match>
</fontconfig>

Freetype environment settings:
(set for all modules just in case, intentionally high values to pronounce the effect)

export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0 cff:darkening-parameters=0,500,0,500,0,500,0,500 autofitter:darkening-parameters=0,500,0,500,0,500,0,500 type1:darkening-parameters=0,500,0,500,0,500,0,500 t1cid:darkening-parameters=0,500,0,500,0,500,0,500"

Results:

TTF

OTF

YES - this is the same font with the same weight - Fira Code Regular.

[xalt7x]

Ok, looks like my assumption about "autohint" was incorrect. According to FreeType developer some time ago:

"Slight" hinting means autohinting for TTFs and native (and light) hinting for OTFs, so the TTF hinting interpreter isn't even started.

And also from the mentioned above article:

Setting ‘slight’ hinting usually leads to FT_LOAD_TARGET_LIGHT. This mode implied the auto-hinter before and has now been changed to mean “Use native vertical-grid-only-snapping if driver and font supports it and vertical-grid-only auto-hinter otherwise”. Right now, only the OpenType/CFF driver is supported. In the future, this will hopefully include the TrueType engine once full support for ClearType arrives.

So "autofitter:no-stem-darkening=0" still makes a difference for TTF fonts even without forced via config "autohint".

Though, it won't have the same effect as "cff:no-stem-darkening=0" for OTF fonts.
This is confirmed on the current documentation:

For the auto-hinter, stem-darkening is experimental currently and thus switched off by default (that is, no-stem-darkening is set to TRUE by default). Total consistency with the CFF driver is not achieved right now because the emboldening method differs and glyphs must be scaled down on the Y-axis to keep outline points inside their precomputed blue zones. The smaller the size (especially 9ppem and down), the higher the loss of emboldening versus the CFF driver.

[tonsky]

Added in #1614