Mac: Too wide spacing in dynamics with more than one character (ff, mp etc.)

There is a slight difference under Windows 7 too:

The difference between thewm is that the dynamics palette combines 2 f glyphs, whereas in the symbols palette the ff is a single glyph.
This is true for master too, and there too is a small gap between them (but it is smaller than in 2.1)

.

Ah yes, the symbol palette's ff is Bravura's, there is no Emmentaler version, for some strange reason

The too tight ff happens also when you use the Pdf converter on Musescore.org (using a Mac to do the Musescore "typing if that matters in any way)".

See #75026: "sff" not kerning properly with Bravura and MuseJazz. I don't have a Mac to verify if this is the same issue or not, but I guess it probably is.

Not the same issue, a) this here is mainly Mac and b) here it is ff, which looks good in the other

After an intensive investigation, I think I found the origin of the problem, for both Windows and Mac.
The dynamics are drawn in the score through a drawText instruction, therefore they rely upon a QFont loading the corresponding font (mscore.ttf, Bravura.otf or Gootville.otf).
I wrote a simple test Qt script (it can be opened and compiled via QtCreator) which prints the kerned pairs of mscore.ttf with kerning disabled (top row) and enabled (bottom row). The script is attached in the zipped folder. "mscore.ttf" is the original font from GitHub (for the other font in the folder see below).
The results of the script, for mscore.ttf and Qt 5.4.2 (the one used for 2.x branch), are the following:
Linux Mint 18.2

macOS High Sierra

Windows 10

As you can see, Freetype rendering correctly kernels the font, while the font engine of Mac completely ignores it, and Windows behaves strangely.
By comparing the three fonts, I found that Bravura and Gootville have "kern" table as well as GPOS table, while mscore.ttf (Emmentaler) only has a "kern" table (without GPOS table).
I thus opened the font in FontForge (under Windows) and re-exported the font with both "OpenType" and "Old Style 'kern' " enabled in the options:

this is the font in the zipped archive "mscore_kern_GPOS.ttf".
I ran again the Qt script and these are the results:
Linux

Mac

Windows

I therefore think that, in Qt 5.4.2, the drawText relying on a QFont is not able to properly read and use the 'kern' table under Windows and Mac, but it relies on the GPOS table.

Note: the font in my attachment should not be directly uploaded to GitHub, since I remember that saving a font with FontForge under Windows gives problems in the output font, but it must be saved again under Linux

Could this be related to #117191: [Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2, like having the same cause, just for a different (set of) font(s)?

@ Jojo-Schmitz : I don't think so, since #117191: [Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2 is actually related to the dimension of the text (it disappears if the text size is increased and becomes worse if the size is decreased) and appears also for fonts with both a 'kern' and a GPOS table. I think #117191: [Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2 is related to an integer truncation in the character advance, given by the font libraries used by Windows; that's why it is less visible for large font sizes.
EDIT: This also appears under Mac, while #117191: [Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2 is Windows-only.
But, to say the truth, I had the same doubt, and that's why I spent some time trying to isolate the underlying cause.

I had previously gone through some of the same trial and error regarding MuseJazz. Maddeningly, it seemed that some kern tables worked better on some OS's and there was no way to have a single version of the font that kerned correctly on Windows, macOS, and Linux, so we might have actually shipped that way for one release (1.2, maybe), but then I think with a new Qt version this changed and I was able to get a single font to kern on all three.

So yeah, if setting it up this way works currently, great, we should make sure we ship our fonts built this way (FreeSerif too?). But we should also put some procedure in place to be sure we test this before each release.

Even without a formal PR there is a patch that needs review, isn't it?
Which is to rebuild mscore.ttf (Emmentaler) on Linux to additionally have a GPOS table.
Maybe, for master, MuseJazz too? Or is master (using Qt 5.8 or later) not affected at all?

Great research again. So we need:

• generate a mscore.ttf file on Linux with Old Style Kern on and commit it both in master and 2.2.
• check that MuseJazz has this flag on.
• Make a release check list (we don't really have a public one...) and add a test to make sure that kerning of text fonts is correct on 3 platforms.

I will try to do these tasks next week.

Maybe I announced the victory too soon: I tried to use the font with the GPOS+kern tables in a Windows self compiled 2.2-dev version, but the kerning of "ff" does not display correctly. I could not try with a Mac build.
If I remember correctly, an embedded version of freetype is used to load the font symbols of the score: could this affect also the font when used for texts?

If I remember correctly, an embedded version of freetype is used to load the font symbols of the score: could this affect also the font when used for texts?

That's correct indeed. Normally, no... the texts are layouted and rendered by Qt.

And in the end the analysis was indeed correct, I was simply using the wrong font: the dynamics use the MScore Text font instead of the MScore font. I saved MScoreText.ttf with both Open Type and Old Style 'kern' flags and, at least under Windows (I couldn't test under Mac), the kern font problem disappears :-)

From what I can see, in 2.2 the following fonts have only the old-type 'kern' table:
mscore/mscore.otf
mscore/mscore.ttf
mscore/MScoreText.ttf
musejazz/Musejazz.otf
musejazz/MuseJazzText.otf

In master branch, however, MScoreText.ttf (and only it among the previously mentioned fonts) has both GPOS and old-style 'kern' tables (the font was modified and re-saved in 2015, while in 2.2 branch the last modification to the font dates back to 2014). That's probably why the bug does not appear in master.

@lasconic: Any progress on this? You planned to do it about a month ago ;-) (see https://musescore.org/en/node/266144#comment-811827)

In case it could help,
here is a version of MScoreText saved with FontForge under Linux Mint 18.3 with both kern flags. I ignored the warnings that FontForge issued when exporting the sfd to ttf (namely: the em-size is not a multiple of 2, and some glyphs have wrong direction , or missing points at extrema, or non-integral coordinates, mostly "missing points at extrema"), mainly because I don't know how they should be corrected.
I tested it under Windows and the dynamic kerning seems to work correctly.

Ciao,
ABL

BTW, random bit of information regarding the importance of getting this right:

There is a Facebook group "Music Engraving Tips", populated by some fairly serious folks. There is a general feeling there that MuseScore is not professional-quality, but very little to back that up. The couple of times I've seen discussions of specifics, it was surprising to me how many of the complaints basically boiled down to text kerning issues. I understand we've already addressed a big part of this for 2.2, seems like this is needed also to complete the job?

Yes, please. I haven't been able to use Emmentaler Text for ages.

Can this one still make it into 2.2?

I say again, yes, PLEASE!

See https://github.com/musescore/MuseScore/pull/3558

We will need heavy tests on this one this week. I tested quickly on macOS, it works great.
@ABL can you confirm that you did the ttf with the sfd from the 2.2 branch ?

My dev environment is set up for master, and I can't compile 2.2. Can you share a Mac build?

Fixed in branch 2.2, commit 79a36fdff0

fix #266144: Mac: Too wide spacing in dynamics with more than one character

Fixed in branch 2.2, commit 92595cd3cf

Merge pull request #3558 from lasconic/fix-266144

fix #266144: Mac: Too wide spacing in dynamics with more than one cha…

I don't see the problem on master. Reopen if needed.

Thanks for merging! I'll test as well as I can.

This changes also affects Windows?

It's still not quite right:

The kerning should be tighter, making the cross stroke continuous, as in this example of Bravura:

@lasconic : yes, I used the 2.2 sfd definition for the font.
@Isaac Weiss : actually, that is how the kerning is defined inside the font. Now it should behave in the same way under all the different OSs, and indeed under Linux (which was the one under which the kerning was really working) you can see that small gap.
See here (even if there I was using the mscore font instead of mscoreText), the second line of dynamics for each case: https://musescore.org/en/node/266144#comment-810993
In order to change it the font itself should be corrected (i.e. the kern properties of f dynamic).

Under master there were some kerning changes, and then the font was already re-compiled with both kern tables, that's why the discrepancies between the different OSs cannot be seen in master (for Emmentaler, Gootville and Bravura, at least).

Automatically closed -- issue fixed for 2 weeks with no activity.