[Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2

• Jul 3, 2016 - 20:23
Reported version
2.2
Type
Functional
Severity
S4 - Minor
Status
closed
Project
Priority (old)
normal
Status (old)
closed
Component (old)
Code
Category (old)
bug report

Similar, but not the same as
https://musescore.org/en/node/82021

The kerning issues in 2.03 were so bad I downgraded back to 2.02, which is acceptable.

The problem are fairly consistant over a large variety of common fonts, professional ones, that don't have glaring issues in 2.02.

MuseScore users should not be limited to FreeSans and FreeSerif. Those fonts are OK, but they aren't great.

The kerning issue should just get fixed.

The lyric font in these samples is MScore Text. Your font.

System Text seems to have different kerning issues, and System Text problems appear the same in 2.02 and 2.03.

Here is a sample (score attached) with some big issues very clear to see in 2.03.

MScore_Kerning_203.jpg

Here is the same sample in 2.02 with no changes, and while it clearly has problems with l and i, that's a problem with the MScore Text Font only.
Most professional sans serif fonts look just fine on this sample in 2.02, but look terrible in 2.03.

MScore_Kerning_202.jpg

The biggest issues are:
There is way too much space after a, v, and y.
There's way too little space c, i, l, and m.
And it looks like general garbage in 2.03 and did not in 2.02,

The Staff Text font is Century Schoolbook Bold Italic, because it is commonly available in packages like Windows, OpenOffice, MS Office, etc. and frequently used for this purpose, but those kerning issues may be unrelated to whatever happened to the lyric text between 2.02 and 2.03.

I built a Musescore kerning stress tester based on Kern King by Leslie Cabarga (lower case only) (also attached.)

Attachment Size
203_kerning_sample.mscz 5.29 KB
Font_Kerning_Stress_Tester.mscz 34.92 KB

Comments

Try the attached files and change the lyric font to a few fonts you think should be decent, open with 2.02, then open with 2.03. You'll see exactly what I'm talking about,

Looks fine on Ubuntu as well [ EDIT:, no, not fine, actually kerning doesn't work for several fonts, but it doesn't have the weird too-close issues either). I tried installing a copy of the third-party proprietary Arial font I found online and it too kerns just fine for me [ EDIT: no, not fine, but not weird either ] on 2.0.3 on Ubuntu. So maybe a Window-specific bug in FreeType? Or, I wonder if perhaps you have some sort of third party font manager installed on your system that is causing conflicts for you? Can someone else running Windows check to see if you have kerning issues with Arial?

BTW, I don't think "MScore Text" is really intended to be used for general purpose text, it's more for internal use as far as I know.

I can install Musescore on another Windows machine, and try Arial, Univers, and a couple others I tried that didn't seem to work with 2.03. (I tried Univers special because it's the most recent professional font I have, maybe 4 years old- my big expensive Adobe packages are older. I'm out of that world, now and I'd have to buy them myself now.)

It might be a Windows 7 thing.

I can also try on XP.

I have a couple Linux boxes, but they've been in the basement for years, I think Debian and Ubuntu, but I really don't want to have to fire them up just for MuseScore. I'm not even sure they'd have the supporting packages required.

I think Arial might be a good one to check on another 7 box since it's easy.

I also have the PS1 Arial pfm and pfb files I can try if Windows doesn't go bonkers if Arial otf disappears and see if it's the way Windows handles ttf and otf. I know I have them right now, just they're not installed.

Also Win7 here, no special font stuff installed as far as I know (except MS Office which does come with some of its own versions of fonts).

I see identical results as the screenshots from OP with MScore Text at size 11.

This is Arial at 11:
117191_Arial_11.png

And this is also Arial, but now at the used-to-be-default-fontsize-for-everything-in-the-world of 12:
117191_Arial_12.png
which looks a lot better imo

As a comparison the same text in Arial at 11 and 12 in Word2007:
117191_Arial_11_and_12__Word2007.png

So yes, I would suspect a FreeType issue on Windows

Title Font kerning issue with lyrics in 2.03 not present in 2.02. [Windows] Font kerning issue with lyrics in 2.03 not present in 2.02.

Now I'm looking, and the file I gave you doesn't seem to have the same issues with Arial at 11 or 12, but with Arial at 9 point (and other fonts, as well.)

That's what I've used on all my scores, you can see it very clearly on those.

And you do not see it on 2.02.

I created the sample file as a show and tell, but I should have changed the lyric style to 9 point first.

The problem at 11 or 12 point showed up with MScore Text, not so bad with Arial

But the problem is STILL there. And with more than just Arial. I verified this before I created the other files.

Check the attached.

Attachment Size
FontCheck.mscz 4.96 KB
203_kerning_sample.mscz 5.56 KB
Ten_Commandments_Song.mscz 28.57 KB

In Win 7/10. The word "cafe" (for example):

Times New Roman (seems OK):
times.png times_italic.png

FreeSerif (excess space between "f" and "e"):
freeserif.png freeserif_italic.png

Speaking of Times New Roman...

Here it is in 2.03:

Times_New_Roman_203.jpg

And now, for 2.02

Times_New_Roman_202.jpg

I even tried installing the XP (2004 TTF) version over the Win7 (2014 OTF) version with no effect.

Here is genuine Adobe Times Roman Postscript Type 1 (1996 version) under 2.03

Times_Roman_203.jpg

The screen fonts on the postscripts aren't great, but they print beautifully! Much better, I mean GOBS better than FreeSerif. I'll send pictures of this score's printed output in Adobe Times and FreeSerif under 2.03 later.

I should have mentioned I verified this on an almost vanilla (had MS Office installed) Win7 machine.

Here's pics of the printed output.

FreeSerif under 2.03: (I wrote FreeSans but it is FreeSerif)

FreeSerif.JPG

Adobe Times Roman Postscript Type 1 under 2.03:

TimesRoman.JPG

Geneva. The issue I'm describing with MuseScore ignoring kerning tables shows up in Geneva.

Attached is the MuseScore file.

Make sure to change sizes and watch the kerning change.

I can't attach Geneva or Arial, etc.

You might need an old driver for your Xerox printer you can get here,

http://www.helpjet.net/Fs-83872896-94487940-80791914-extract.html

and nose around in the utility/sfont/NT40/ directory to see what you downloaded and make sure it's safe..

Attachment Size
203_kerning_sample Geneva.mscz 5.26 KB

Let us know if you can reproduce the issue with a font you *can* attach, so we can test further. My guess, though, is that it will turn out to be some sort of incompatibility between the version of FreeType we use and the specific way the kerning info was stored in that version of that font, with symptoms that differ between OS's. Which is to say, short of reporting to issue to the FreeType team, there may be nothing we can do about it. But we'd need to be able top reproduce it oursleves as a first step to understanding it.

That is the default if you do not have the prescribe font installed on Windows.

It also sometimes happens after uninstalling, say, a TrueType font to install a Postscript.

If you are testing on Windows 7, (Not XWindows and KDE, Not Wine), just use Arial. It comes with the OS. Or Times New Roman. Those are great examples.

I worry about using free fonts because they will likely have issues fonts from professional foundries will not have.
If you really need a downloadable example I'll take a look at FontSquirrel and see what I can find that acts the same way, sometimes good foundries have free samples in a couple weights.

I think the problem is exclusive to Windows. Which is what most MuseScore users are using. I can't imagine why the Postscript fonts seem to work fine, that's kind of getting very old school outside of specific graphic design applications, and newer TTFs are not working right.

For OTF I think the issue is dependent on the source. Some embed as Postscript in applications like Acrobat. I suspect these are the ones that work, it would take me some time to test that theory.

The other Win7 system I confirmed the problem on was pretty vanilla save for MS Office 2002 and Acrobat Reader DC installed. Which is a pretty typical installation.

Maybe get a beater on eBay with Win7 license, image it after MS updates, and use it for testing for oddball situations like this?

I doubt this is the only Windows exclusive bug out there.

Personally I prefer Linux, it just doesn't work well for my current applications. Most people are using some version of Windows, likely XP is still common.

The novelty in MuseScore 2.0.3 was the use of Freetype to get the metrics of the musical fonts, so we can layout the musical symbols (notehead, accidentals etc...) more precisely and with the same metrics on all platforms. This is about the musical font and so it should be irrelevant for the problem at hand.

As far as I understand, Freetype is not used for text rendering in MuseScore 2.0.3 on Windows. It's only use on Linux, through Qt. On Windows and Mac, again as far I understand, Qt uses native API to do the text shaping and rendering.

Now, the weird bit. MuseScore 2.0.2 and MuseScore 2.0.3 both use Qt 5.4.2...
Still I see the rendering is different, but not sure if it's a kerning issue or a different hinting. In both case, it shouldn't happen though... since the library is exactly the same. (Left 2.0.2, right 2.0.3)

shot_160712_145046.png

(PS: @SeasonPsalt, I'm one of the core developer, and the packager on Mac OSX and Windows, so I do own a PC running Windows, no need for ebay, but thank you for the suggestion)

I think it is related to one of these Qt bugs. If the QPainter's transformation matrix is not identity, then some strange pixel alignment happens in GDI, causing bad kerning with small fonts. When I dug into the code changes since 2.0.2 I remember seeing some transform changes that might be behind this regression. I don't know if it's something that we can fix though...

https://bugreports.qt.io/browse/QTBUG-20900
https://bugreports.qt.io/browse/QTBUG-21377

I too just downgraded from 2.1.0 to 2.0.2 after experiencing bad, ugly kerning on Windows 7, unacceptable for professional scores, in a variety of fonts. It's not just lyrics and staff/system text, but titles, subtitles, text elements in vertical frames, everything.

Here's an example in Palatino Linotype, 12 point, snapshots from exported PDFs.
Palatino bad kerning example.png

Please let us know when the underlying Qt bug (?) is resolved and it's "safe" again to install updated MuseScore versions!

@grinningcat if you downgrade, go to 2.0.3 instead of 2.0.2.

As you have commented on this issue, you will get notified once it's fixed.

In reply to by Jojo-Schmitz

Severity S5 - Suggestion S4 - Minor

Yesterday evening I ran an extensive "git bisect" to understand when this bug first appeared.
I had some problems because of non-compiling commits, but I finally verified that:
- https://github.com/musescore/MuseScore/commit/839527aef9e4d5af266b159d9… is the last "good" commit before the bug introduction that I can compile
- and https://github.com/musescore/MuseScore/commit/279f4dd7d9075887d0bf09753… is the first "bad" commit after the introduction of the bug that I can compile (with a couple of hacks).

Therefore, I strongly think that this bug was introduced when including freetype 2.6.1 code in MuseScore code.
I tried to substitute the freetype code with the most updated one (2.8.1), but the kerning problem didn't change.

I strongly suspect that in order to solve this bug we need to compile freetype with the Harfbuzz dependency (see: https://www.freetype.org/freetype2/docs/glyphs/glyphs-4.html ), but I don't know how to try it.
Indeed, when using the external freetype library (as in the last "good" commit) the bug disappears.

Great find!
It seems that we don't have the same problem in master though right? Would an update to Qt 5.9 fix the issue too?

In reply to by lasconic

I managed to pinpoint the actual culprit!
The problem is not related to the use of freetype, but to the change of DPI to a constant, i.e. this commit:
https://github.com/musescore/MuseScore/commit/3abb4586809f4d694c62f93d5…
I cherry-picked this single commit and applied to the last "good" commit, and then reverted the freetype-related part of the commit. After compilation I can see the effect described in this bug report!

Sorry that I sent everybody on a false track with my previous post, but the change with freetype and this DPI-related change were a little entangled.

Very weird. Are you sure about it ? because I don't really see how the DPI change could affect the kerning. In worse case, I could imagine that it would amplify kerning issues, but that's it.

In reply to by Jojo-Schmitz

And moreover, I may be wrong, but I think that this effect strongly depends on the font size:
if you try the above mentioned passage: "Then they said among the nations" with font size 1 or 2 you will see kerning problems under Windows, but not under Linux (actually I could not test the very same font under both because I don't have Palatino Linotype uner Linux). For large font size (e.g. 20 or 40) there is no more problem even under Windows.
Therefore I think it could be an integer vs real value problem (maybe scaled by the dpi resolution).
See also:
#82021: Text hinting causes ugly output

Title [Windows] Font kerning issue with lyrics in 2.03 not present in 2.02. [Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2

Fwiw though, we have long had problems with kerning that depends on the for at of the kern tables. Every time I generate a new version of MuseJazz - going back to before 2.0 - I need to be careful to get the right option score kern tables on Mac vs Linux vs Windows because the kerning would be ignored on one OS or another otherwise. And I've seen the same with various versions of the FreeSerif fonts. So it is important we test our shipped fonts with respect to kerning on all three platforms.

Indeed, before 3abb45868 the DPI was taken from the screen settings and in my case this was 96, while after that commit it is 72.
I tried to increase the DPI to 720 in the code, but this resulted into extremely tiny texts. However, if I increase this text size of a factor 10, the text becomes what I would expect and there are no kerning issues.

Something similar happens for master: when viewing a text with small font size (#82021: Text hinting causes ugly output) I can see kerning issues similar to those presented in this (and that) bug report; when I increase the value of DPI_F in mscore.h, here: https://github.com/musescore/MuseScore/blob/6eb58d5b53b3661383775ac2a76… , this problem disappears (and the text doesn't become tiny as in 2.2 branch).

I tried a first attempt to solve the problem in:
https://github.com/musescore/MuseScore/pull/3298

I still have a problem in the fretboard palette, but I don't know how to solve it (solving it gives a bad text dimension in the score and viceversa).
Tests are needed.
I couldn't test the result on monitors with different dpi to see if does not introduce bad side effects somewhere.

In reply to by Jojo-Schmitz

I updated the pull request.
I think that everything (or most of things) should scale as in 2.1, but maybe more tests should be performe, also on different pc configurations (e.g. screen dpi, etc...)
Fretboard diagrams and maybe figured bass, and their relations with spatium scaling and custom scaling should eb double-checked against the current 2.1 behavior.
Svg export should work correctly now (even if the exported file contains an additional transformation to scale down everything to the correct page size), but I think sideways ( https://musescore.org/en/user/61963 https://github.com/sidewayss ), if available, or someone else with good knowledge of svg, should probably double check it.

If needed, I can provide a Windows build of 2.2 with this PR for tests.

Just tested this and found that it does render a score of mine slighly wider, so that I had to reduce stretch on 3 system and on top had to tweak some setting in Style/General/Measure to make it even narrower, in order for all the system fitting like they did in 2.1. I'm pretty sure it is related to lyrics, i.e. text.
I'd need to compare that with a 'regular' 2.2 nighly to verify whether it is a 'normal' 2.2 issue or related to you change.
Edit: 2.2 nightly 71c7bbb does render it the same as 2.1, as does the latest 072c135, so something is going on with your patch that isn't what it should be.

In reply to by Jojo-Schmitz

@Jojo-Schmitz : could you please share the score or a reduced version of it (if you can isolate a group of measures which changes layout with the patch)? In case, you could also send me a private message (there is a "Contact" button in the user page).
Thank you for your help.

Thank you :-)
I found what was causing the discrepancy: in the original text.cpp the font size was set as
font.setPixelSize(lrint(m));
and m (the spatium-depending size) is 10.377 for some of the texts of the file (e.g. the lyrics), therefore it was rounded to 10.
With my change
font.setPixelSize(lrint(m * DPIFACTOR));
since I used DPIFACTOR=10, the font size was set to 104 (rounding 103.77) instead of a simple scaling of a factor DPIFACTOR=10 of the old size (i.e. 10 x 10 = 100). This was causing all spatium-depending texts (lyrics, staff/system text, etc.) to be roughly 4% larger.
This can be solved by using
font.setPixelSize(lrint(m) * lrint(DPIFACTOR));
but even with this correction, I found a subtle discrepancy in text positioning between the current Windows Nightly behavior (1), the PR behavior under Windows (2), and the behavior of the current Nightly under Linux (3). None of these three are exactly superimposable on top of each other.
The kernings of (2) and (3) now coincide (except for texts with font size < 2; by increasing DPIFACTOR this can also be solved), but the (x,y) positioning of texts is not exactly the same: I think that the problem is a rounding to integer pixel also in this case (maybe related to text width). I will investigate further during the weekend.
In particular, I will try, if possible, to reproduce the exact spacing of MuseScore under Linux also under Windows so that a score would appear exactly the same under different operating systems.

I updated the PR: it now touches only text handling (I found that increasing the DPI was producing bad effects elsewhere, for example in the snapshot tool).
A test build is here (I updated the archive):
https://drive.google.com/open?id=0BxjayMZiuupOaXlNdXBrYUZxYTA
From the tests I performed, the spacing and kerning for spatium-dependent texts are basically identical under Linux and Windows with this build. Spatium-independent text vertical positions are still different (but they are different also without this PR, and, except for footnote texts where the situation is slightly worse, it is closer to the Linux output for the other cases with this PR).

Note: I tried to apply a DPIFACTOR larger than 1 also under Linux, but at small zoom levels (i.e. score zoomed out) I was obtaining artifacts (huge texts), which disappeared when zooming in, after a certain level of zoom (depending on the font size).

Go on!
Your Test Build looks very encouraging! Hopefully this will find a way into the official Windows Builds and make Musescore usable for Quality Scores on Windows!

Reported version 2.1 2.2

bad_kerning.png
It appears this issue still occurs with chord symbols in MuseScore 2.2.1 on Windows 10. The attached picture shows a staff text on top of a chord symbol with Times New Roman size 8.

In the default case (FreeSerif size 12, only a few characters), the bug is almost unnoticeable, but the issue is more pronounced when attempting to use a different font.

Rendering of chord symbols is indeed handled very differently from ordinary text due to all the special things we do in parsing and formatting. For the text that is actually intended to be part of a normal chord symbol, this will be a non-issue because we position everything individually, kerning has no effect. But for chunks of text that cannot be parsed as a chord symbol, they are output as strings like any other and could conceivably be kerned, so it would be nice to pick up the improvements made for other text. Still, be aware that's not really a good use of chord symbols.