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

• Nov 23, 2017 - 10:24
Reported version

Spacing of dynamics (2+ characters) is too wide for fortissimo, mezzo piano etc. in macOS (see attached screenshot). This seems to occur only with Emmentaler font. The only way to bypass this problem is to use the dynamics from special characters palette.
Tried also nightly build 2.2.0 (6f2d6fe) and this bug still exists in the version for macOS, but seems fixed in MuseScore 3 (2a1a352) nightly.
BTW I'm using macOS High Sierra and the current stable version of MuseScore 2.1.0 (871c8ce).

Attachment Size
Emmentaler_fortissmo_macOS_bug.png 100.96 KB


Severity S4 - Minor  

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)

Attachment Size
ff.png 4.32 KB

In reply to by Jojo-Schmitz

I would assume, that the version of the symbols palette is not Emmentaler, but Bravura — it has a different shape (look at the top and foot of the f ). The symbol palette is possibly not changing it's font, when changing the font in Style–General.... The gap between f and f in macOS is definitely too far. The (Windows 7) gap above is okay, I think it is only the difference of Emmentaler's style and Bravura's style. Bravura uses a ligature of f and f, whereas Emmentaler has a gap like it is usually done with two consecutive letters. I attached a sample of Lilypond's output, since Lilypond uses Emmentaler as well. The two f's are also divided by a little (=normal) gap:

PS I use both, Windows and macOS. Normally I set my score with my Windows 10 machine, but since there is a (text) font kerning issue in stable MuseScore for Windows, I used the Mac for generating the output (pdf/print) ...until I discovered a modified 2.2.0 (695f653) version of MuseScore, which seems to fix the font kerning issue for texts/lyrics so far, but the two f's in fortissimo are too close together/overlapping there:
fortissimo in 2.20_695f653.png

I know, it's not the most urgent issue, but it does not look very pretty compared with what it should look like and I wanted it not to be overlooked.

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

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

In reply to by Marc Sabatella

No, not the same issue, more like an inversion of my problem with Musescore 2.1 (871c8ce) for Mac. The problem does only occur in the Mac version, not under Windows, which I use more frequently.
This is what Emmentaler looks like, the spacing within combined dynamic marks is too wide:

..and Bravura (same for MuseJazz & Gonville), which looks fine:

Using Emmentaler it seems that every dynamic mark following a f is too far away, but there is no problem, when a single f is the last sign, like in mf. Probably it's forte's fault?!

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:

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

Attachment Size 48 KB

In reply to by Jojo-Schmitz

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

In reply to by ABL

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.

Status (old) active patch (code needs review)
Status active  

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 :-)

In reply to by ABL

From what I can see, in 2.2 the following fonts have only the old-type 'kern' table:

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.

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.


Attachment Size 27.25 KB

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?

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 ?

In reply to by Isaac Weiss

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

In reply to by Isaac Weiss

@Isaac Weiss: NO it should definitely not be tighter! This is Emmentaler not Bravura. In Bravura those fortissimos are ligatures, whereas in Emmentaler they are two discrete letters. Emmentaler/Feta is also used in Lilypond and this is the way fortissimo does look (see image below):
Bildschirmfoto 2018-03-20 um 08.58.24.png

@ABL Emmentaler has not to be corrected (this sounds as something is wrong with this font), it's only a different style. If you don't like "Times New Roman" for example, you are not changing it, but you will probably pick a different font. It is the same with fonts for typesetting musical scores. There is still Bravura and Gonville if someone does not like Emmentalers's style.

For me Emmentaler dynamics seems nearly OK now in the current 2.2 build (OS: OS X 10.13, Arch.: x86_64, MuseScore version (64-bit): 2.2.0, revision: 3d20279) for Mac. "Nearly" because it is maybe a little bit too tight – this makes it look as it should be a ligature fortissimo which it is not by design.