Kerning — 1 step forward, 2 steps back

• Sep 22, 2014 - 11:22

Yesterday I started investigating some kerning issues I am having with MuseScore 2.0 beta. This was starting to overwhelm another thread, so I'm starting this new one here.

First, let me point out this is the first version of MuseScore I have used, so I don't know how the feature set or rendering compares to earlier MuseScore releases. Secondly, I am on Windows 7 Home 64bit. Thirdly, this is with regards to all output... screen, print and PDF.

With that out of the way...

My understanding is that Qt 5 is the engine underneath that's dealing with font rendering, for screen and print. From what I can make out, then, everything from font-heads to stems, barlines to articulations, all goes through Qt.

Qt seems to do a pretty go job of placing things correctly. I'm finding that note-heads are generally pretty well aligned, and tails etc. are all looking pretty good. It seems to me this kind of micro-positioning is tweaked in the font's metadata.json, right?

So far, so good.

The problem arises when we start inputting two or more glyphs which have kerning data associated with them. Be that dynamic text, or a composer name, or lyrics, or whatever... if that text has within it a pair of glyphs which has assoiciated kerning data, things start becoming unpredictable. What I'm trying to establish is whether Qt has issues, or whether MuseScore's implementation of Qt has issues.

I can say with some confidence it is a kerning issue, because using fonts with no kerning data (e.g. monospace fonts), everything renders correctly and consistently, regardless of size/scaling.

From what I can discern, all kerning is left to Qt. What I mean, MuseScore is not doing any kerning trickery. So, if we have a text field, Qt is interpreting and rendering that as it sees fit, according to the font and its embedded kerning table. Outside of the font file itself and Qt, it would seem the MuseScore developers aren't doing any additional tweaking to kerning, leading, or anything like that.

That's great. Except something is going weird. Depending on the size (relative scale) of the font, the kerning is either too loose, too tight, or a mixture of both. And it doesn't degrade consitently. For example, letters with a font-size 15 may have better kerning than 16 and 17.

So, what's going on? Well, Qt is definitely reading the kerning data, we have established that. But the algorithm is, well... it's not working as it should.

What can we do to sort this? Can anyone else shed some light on this? Is it a known bug? Win 7 problem only?


Well, first it would help if you could
1/ link to the thread you mention ealier
2/ Explain which font and text are you specifically talking about.

MuseScore relies on Qt to draw text, any text. Most of the graphical element in the score are text like noteheads, articulations, clef etc... other are not, like stems, barlines etc.... These last ones are lines, drawn by MuseScore (also using Qt). For the former, kerning makes not really sense since most of the symbols are single symbols (an exception being some mordents). These elements are drawn with the Score Font. Only a few field in metadata.json are used by MuseScore currently. See here
The attachment of stems, beams, flag etc... is done by asking Qt the bounding box of the musical glyphs.

Then, MuseScore uses a musical text font. This font is used for symbols in text elements. The font is used in dynamics, coda, segno, tempo text etc...

Last, MuseScore default text font, for title text, staff text etc... is FreeSerif.

For these two last fonts, kerning is indeed useful. In a nutshell, MuseScore will ask Qt to draw a given text with a given font at a given time. Qt is supposed to deal with the kerning etc...

What can we do to sort it out?
1/ Use a nightly and not the beta.
2/ Create a very minimal example of the problem you encounter.
3/ Attach the score and a screen capture of what you see. Also the font you are using. Explain what is wrong. That will enable other people to test on their own OS, their own version of Qt etc...
4/ If we find out it's a Qt problem, file a bug in Qt. If it's a MuseScore bug, fix it in MuseScore. Could also be a bug in the font itself.
5/ Eventually fix the bug in Qt.

In reply to by [DELETED] 5


Thanks for this very thorough and thoughtful reply. It gives me a really clear understanding of the different element groups and how (and by what) they are being handled. It's exactly the information I was interested in.

So, it sounds like where I'm seeing issues is with what you call the "musical text font" and the "default text font". No matter what font I choose (be it default FreeSerif, or any number of other fonts OTF or TTF), there are these kerning issues and discrepancies I described.

I'll do exactly as you suggest and really hope I can help us get to the root of the issue.

  • Using MuseScoreNightly-2014-09-22-1409-daf130a
  • Using default font (FreeSerif) in the Title area
  • Windows 7 Home, 64bit



This is a quick example using the first kerning pairs that sprung to mind. The number is for the font size I chose. So, notice, in particular...

We: Space between W and e varies between too tight (08), to too wide (21) and everything in between, in no particular order. Same applies to "To". Look at 20... it's nicely kerned. 12? Too wide. 08? Again, too wide.

Here's a weird one... look at 07... the W|e is too wide, the T|o is too narrow.

To my eye, almost every one has slightly different kerning, some acceptable, some worse than others, but always variable.

Look at 22. I'm seeing Wha|t. Same for 20. On the other hand, 13 (and 07, for that matter) seems to read W|hat.

Anyway, I hope this demonstrates the problem. As I said, text with kerning pairs, placed anywhere on the score with any text style or any font is showing this problem.

EDIT: And worth reiterating, it's not just on screen, but on print and PDF out too.

In reply to by [DELETED] 5

Ah, okay. So kerning in MuseScore is taken care of by a sixth party app ;)

Joking aside, I think your Mac screen grab looks super consistent, although sort of strange that the W|e is never kerned!?

The Win8.1 Qt 5.4 one: pretty good, except again, no kerned W|e, until we get down to 13, at which point it become more and more tight to the W.

The last Win8.1 Wt 5.2: some inconsistencies there, like variable kerning on the W|e. Compare 22 to 16, for example.

I'm going to hazard a guess here and say there's either the "W|e" has no kerning data in the original FreeSerif font, and in Qt 5.2, it's trying to be smart and do it's own optical kerning. Qt 5.4 and above is deciding to respect the kerning of the original file, expect when it gets below size 13 or below, at which point it start applying it's own optical kerning. What do you reckon?

Would you mind trying this with a different OTF font (one that you know has well defined and thorough kerning) and see if the results are the same?

But, I got to say... they ALL look better than mine. Which is a relief. So it sounds like all I need to do if find a new operating system!

In reply to by douglas81

FWIW, I know there are multiple different ways kerning info can be encoded in a font - OpenType tables, "Apple" tables, "old style" tables - and tha'ts just for TTF. Then OTF has its own set of kerning standards I guess. Qt seems to handle the same kerning differently depending on how it is stored in that some of those tables work on one OS but not another, or work with one version of Qt but not another. I'm talking, kerning info is *compeltely ignored* for some combinations of Qt version / OS / table type. So I guess i'm not terribly surprised or disappointed when I see fairly minor inconsistencies like this. most people would never notice such subtleties. Still, if there is a relatively easy way to improve things (eg, wait for Qt 5.4), I'm all for it.

In reply to by Marc Sabatella

"most people would never notice such subtleties"

Yeah, I know what you mean. But if that's a reason to not bother getting it right, then we'd all just be using v1.0 and not worry about it.

The point is, kerning may seem minor, but it is these cumulative minor differences which make things look either professional or amateur. Also, it would almost be okay if it were consistently bad, but it's the unpredictability of it which make it difficult to manually fix.

My personal view is that any text on the score should look just as beautiful and refined as the notes.

In reply to by douglas81

Don't worry, I'm not trying to suggest that it's not worth *trying* to get it right. It's more about gauging cost / benefit should it turn it out that Qt 5.4 does *not* fully fix this. If "getting it right" for MuseScore means implementing our own text rendering from scratch, or even just adapting MuseScore aspects to use different libraries for this (which I suspect would not be trivial either), then to me it's not worth it. Better to simply keep on the Qt folks - and perhaps MuseScore users with the necessary technical skills could go in and help. But this wouldn't be worth holding up the release of 2.0 for in my opinion.

For background, I'm not *just* thinking of this, but also recent debates about the merits of TTF versus OTF and embedding fonts in PDF files and using Qt rather than some other third-part solution for generating PDF. Realistically, any release of any software will go out with certain known minor issues that are just not worth fixing. Otherwise, no one would ever be able to release anything. The trick is in making the right calls.

Do you still have an unanswered question? Please log in first to post your question.