Kerning — 1 step forward, 2 steps back
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?