FreeSerifs kerning for the (small) letter f does not work properly (MuseScore 3.x)

Some additional data.

First, I am using the 3.3 AppImage on Linux Mint 19.1 (<= Ubuntu 18-04). It took me some magic, but finally I discover that the AppImage does not contain any font, evidently relying on system fonts. So the FreeSerif (in this case, bold-italics) I see in MuseScore is the same system font coming with my distro and used by other applications too. As the OP did not declare his system, I do not how this translate in his case.

I think very probable that it is an unrecognised kern issue.

This is how the same word / same font looks in MuseScore (not very solemnly...):

This is how the default FreeSerif looks in LibreOffice and in InkScape (this is more solemn!):

(note the different spacing between f and e and possibly between r and l with respect to MuseScore example).

This is how the MuseScore own version, as contained in the github repository, looks once opened in FontForge (one is the .sfd and one is the .ttf):

Which match quite well the LibreOffice/InkScape display.

Note however that FF has some trouble with kern data: it shows a kerning of 0 between f and e, but font lookup data show that it is actually -130, which , as afar as one can appreciate by eye, corresponds to what FF itself is showing in the metric window. Might this be related with our problem? As far as I now all kern data are equal in nature and there should be no reason for some to work and some not to work (or be listed) in some context (the same '0' value is listed in metric window for the system FreeSerifBoldItalic.ttf, so it is not an artifact of MuseScore font variant).

Finally, both my system FreeSerifBoldItalic.ttf and MuseScore own FreeSerifBoldItalic.ttf contain both the kern table (“old style kern” in FontForge parlance) and the GSUB kern table so, in principle, it should be readable by ‘old’ and ‘new’ font stacks (whatever ‘old’ and ‘new’ may mean).

I hope this might be useful.

EDIT: of course, I was wrong! The AppImage does contain the fonts, which are embedded in the mscore-portableexecutable.

So, the one used in MuseScore is its own variant and the one used in other apps is my system variant. They seem to be equal for the relevant matters (kern data), but I'll try to check to see if swapping them changes something (not sure how to swap fonts inside the MS executable, though...).

There is kerning by direct pair, and kerning by character classes. That could be a difference.

Ligatures in MuseScore: On my system (Linux Mint 19.1), MuseScore 3.3 definitely does not use existing ligatures in FreeSerif.
Ligatures in other programmes: both InkSpace and LibreOffice definitely use standard ligatures like “ffl” and “ffi” for all styles of FreeSerif.
Other ligatures: FreeSerif does not contain many other ligatures (at least, not ones we are likely to use, as those for Thai...); for instance the "ch" digraph is not among them, so we cannot blame any software for not rendering it, as it is not in the font in the first place.

However, ligatures are an additional problem, possibly related but different. The point of this issue is that kern for very mainstream fonts as FreeSerif is not working well (or not at all) in MuseScore.

Both ligatures and kerning are working fine in Campania, though. So there is definitely more to this than just "kerning and ligatures don't work in MuseScore". I know there has been a lot of confusion over the various different formats that can be used for storing this info in the font files - "old style kern" on vs off, "Apple" on vs off, "OpenType" on vs off, etc.

«So there is definitely more to this than just "kerning and ligatures don't work in MuseScore"»: you are correct, but if you check, you'll see that I tried to define the application of my remarks to FreeSerif or to very mainstream fonts like FreeSerif and both sentences are essentially true.

Referring to Campania, there is another quite big variability: the difference between .TTF and .OTF (CFF), to which applications may react differently.

Here is a small Qt example demonstrating the problem. To run it, simply open font_kerning.pro inside QtCreator, compile and run. I ran it under Linux Mint 19.2, with Qt 5.12.5.
I found that if the Font calls itself "FreeSerif", then Qt loads the system font instead of the embedded resource font and I cannot see the right kerning. You can see it in the example: there two identical fonts in which only the (internal) font name is changed FreeSerif.ttf and FreeSerif5.ttf. If line 15 of the example is changed so that FreeSerif5.ttf is loaded instead of FreeSerif.ttf, then the widget displays the correct kerning.
I made FreeSerif5.ttf by playing around with MuseScore FreeSerif with FontForge until Qt decided to show the correct behavior. I found that, at least in my system, I have to delete all the tables in GSUB and all the table in GPOS not concerning kerning (to inspect it, load the font in FontForge, Element->FontInfo->Lookups) for this kerning to work, as you should see with FreeSerif5.ttf in the example.
So it apparently another font bug of Qt.
As a side note, I don't think Qt supports OpenType GPOS kerning out of the box, see https://doc.qt.io/qt-5.12/qrawfont.html#LayoutFlag-enum

I have not yet investigated if Campania font behaves properly in Qt.

I found this interesting discussion:
https://github.com/fontforge/fontforge/issues/3435
and indeed if I drop the GPOS table with ttx then the kerning is correct in the simple example I posted above.
ttx -x GPOS FreeSerif2.ttf
ttx FreeSerif2.ttx
(where I changed all "FreeSerif" references to "FreeSerif2" inside the font)

I also found that if I force Qt to use the old harfbuzz implementation for its font engine by setting the environment variable
export QT_HARFBUZZ=old
before launching MuseScore, then the kerning is correct.

And indeed, it is a bug of Qt. See: https://github.com/qt/qtbase/commit/cc4087b18a488ffb02105d31da6f05acad6…
This commit is present only from Qt 5.14.0.
Qt text rendering engine calls harfbuzz (at least, under Linux) and it tries to use the OpenType kerning info, but the harfbuzz script used for the text "feierlich" is currently (for Qt 5.12.6 for example) set to HB_SCRIPT_COMMON instead of the correct one HB_SCRIPT_LATIN, so the harfbuzz shaper does not use that kerning information at all.

Hopefully that fix then also makes it into Qt 5.9 and 5.12