Problems with kerning—too little space to the left of, too much space to the right of "f" dynamics in Emmentaler text

Also see #53876: Emmentaler text font spacing - "sfz" and all dynamics including "f"

Note that all the problems seem to be caused by a single letter, "f." Fix that one letter, and you've fixed all the kerning issues.

We'd need to fine a way to fix this kerning for Mac without breaking it for Windows and Linux, which don't have an issue with it currently...

Well, what's changed in terms of kerning musical text since 1.3? That would be a good place to start.

Qt. Well, also, perhaps the version of FontForge used to generate the TTF files. Kerning is a highly complex and annoyingly OS-dependent affair. It's unfortunately not at all uncommong that something that imrpoves kerning on one platforms makes it work on another.

Has the font itself changed at all? Because Gonville Text and Bravura Text show no issues, nor does any letter in any font in any context except the "f" in this one unique music text font.

Okay, here's something I just noticed. Bravura and Gonville ("Gootville") are OpenType. Emmentaler ("mscore") is TrueType. Significant? Coincidence? I don't know.

Possible origin: #25229: Some dynamics have too much internal space (no kerning)

I see this issue on Windows, too.

Indeed, I receive (with Windows7/Emmentaler) two different result:

- With the last Nightly: a23ef38

- With the 2.0.2:

After checking, probably a side effect of this commit: https://github.com/musescore/MuseScore/commit/053afc3e36a878083e6624dad…

EDIT: Maybe it would be better to open a new issue specific to Windows?

Yes, please. Another issue.

The Windows issue (and apparently also Ubuntu) is at #74536: [Windows] Too much space between the "f" dynamics in Emmentaler text. .

This should be fixed now together with #74536: [Windows] Too much space between the "f" dynamics in Emmentaler text.

Nice fix!

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

I'm not sure how long this has been broken, but the problem is definitely back in 4ae9ef8 (2.0.3 branch).

Have you done the Revert procedure to be sure you are using fresh palettes? I take it you are seeing this on Mac. Things look fine for me using a current 2.0.3 build on Ubuntu.

I had not, but I did just now (I love how easy it is!), and the problem has nothing to do with the palettes.

Can you post a screenshot so we can see what you are seeing? Is the problem on the palette itself, on the score, or both?

Is this a self-built 2.0.3 or a nightly? What does Help / About Qt report for your Qt version? Apparently the fix requires 5.4 or later (see https://musescore.org/en/node/74536#comment-341386).

Score only, because the palettes display in Bravura; nightly; Qt 5.4.2.

And to be sure: you don't have the MScore or MScore1 fonts installed on your system?

Good thought, but no.

Can anyone else on Mac - or any OS for that matter - reproduce this? Not sure how close we really are to release, but this seems like a potential showstopper if it isn't just something really unique about your configuration.

To be clear, though this represents a regression in the code, it's no different from the previous released version—it's been the same (on OS X) since @heuchi reported it in September 2014. It was present all the way through until being fixed well after the release of 2.0.2. So hardly a showstopper.

Really? The original issue report is against a nightly build, and all other cpmments refer to otherr nightly builds. So I have been assuming this was a post-2.0.2 regression. Ceertainly it was good on Windows in 2.0.2, as per comment #22.

I guess if Mac has the same issue in 2.0.2, then it's not a regression indeed. Still, seems like something we should be trying to figure out.

I see only one relevant commit since this bug was supposedly fixed: https://github.com/musescore/MuseScore/commit/036d1b75e4de4ce7aceaf9d89…. Is it possible the TTF file was saved with the wrong options? As I recall, getting a single TTF file to work on Mac, WIndows, and Linux is a bit of a headache; there is like one magic combination of options to use when saving the file in FontForge thsat works but everything else fails for some platform.

It was definitely there on Mac in 2.0: https://musescore.org/en/node/53876
Then, as you can see above, in some nightly after 2.0.2 it ended up the same for other systems, at which point it was fixed for all systems.

I can reproduce the bad kerning in MuseScore 2.0.2 and current 2.0.3 nightly on Mac OSX.
But I can't reproduce with master.
Said differently, it's not a regression and this bug has never been fixed in 2.0.3 branch. Still, this bug is considered fixed because it's fixed in master branch.
The font in master is different (e278201b49), so it's no just a matter of copying the ttf files.
I'm not sure we want to risk to change the font just a few hours before 2.0.3...

I checked if I could do something but sfd file for the font in MuseScore 2.0.3 branch is quite old... my font forge can't read it properly...

Okay, no worries. Thanks.

As far as printing goes, there is a solution I discovered by accident: Upload the file to musescore.com, then download as Pdf. This corrects this problem. Check this thread for problems you may encounter and solutions thereto: https://musescore.org/en/node/97726

However, the next release of MuseScore, along with a corresponding update to MuseScore.com, is imminent, and the problems in question soon shouldn't happen any more: https://musescore.org/en/node/87861

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