Stem slightly misaligned on upstem notes

• Mar 26, 2014 - 20:53
S4 - Minor

Windows 7, GIT commit: d6ef079

1) create new treble score, add a half note with up stem
2) zoom way in

Result: notehead sticks out the back, and stem cuts into the inside of the oval. It's not by a huge amount, but I'll leave it to someone else to decide if this should be considered "minor". It's worse with Emmentaler than Bravura, but it does affect both to some degree. Downstem notes are fine in both fonts.

I know there have been similar issues submitted before, and some of those have been fixed. But if there is an existing report on this specific issue, I can't find it except for me mentioning it in another thread. Apologies if this is a duplicate and I missed it.


I did find #20869: Up-stem notes in Emmentaler font have stem a tiny bit too far to the left, but that's closed. Also #24763: [Gonville] Move note flags on X=0 Y=0, and indeed, Gonville is *way* off currently.

I should add that when I was working on the notehead layout code, I saw some rather odd-seeming calculations of stem position:…

I didn't touch any of that, and I noticed the misalignment in builds from before I started changing layout code, so I don't *think* any of my changes are relevant here.

I cannot confirm this for Emmentaler or Bravura: with both fonts, both half and quarter notes are apparently symmetrical up-stem or down-stem up to 1600% zoom.

With half notes, there are / might be some artifacts at stem junction, but may depend more on stem width than on anything else. For instance, if the stem width is larger than the min half head thickness, the stem shows up in the black *inside* the head. In any case, even these details are symmetrical between up-stem and down-stem.

Testing with Gonville gives a SIGFAULT on texttools.cpp (function TextTools::updateText()).

Context: today commit self-compiled under Linux Mint 14 (Qt lib 5.1.0, Qt Creator 2.7.2).


@Miwarre the crash with Gonville is reported here I tried to fix it in 4568fd6a88

The bug itself is probably due to the bounding box we are getting from Qt for each font. We know that the current way of getting them is not working the same on mac, windows and linux. We experimented with two solutions so far:

  • Use a lower interface QGlyphRun, new in Qt 4.8, not yet stable when we tried it last time. There is a compile flag to try it but it causes problem with PDF export. See #21906: Export to PDF on Windows produces small symbols.
  • Compute the bounding box on particular platform, and store the values internally so we use the same value on all platforms. It was the approach in MuseScore 1.x. Not sure it will work better though, since we know the glyphs are rendered more or less bold depending on the platforms. See the visual tests...

As far as I know I am using all defaults for stem width etc (I reset to factory settings just a few days ago). And the stem aligns with downstem half notes just fine, so it really does appear to be a placing issue, not a size issue. I guess it's possible that this is a floating point math issue and hence could be system-dependent and perhaps unavoidable. But for me me it is consistent. Here is how half notes look on my system:


Lasconic - our posts crossed, BTW. What you say makes sense. I guess you can judge for yourself from my image how important (or not) this is. At 1600% it's plain enough there is a misalignment. At smaller zoom levels on screen, ordinary screen scaling artifacts might mask it or make it look worse, and downstem notes are actually just as likely to appear misaligned for that reason. In a print at a standard size, I can see the misalignment if I look closely enough, but I rarely do.

My visuals have always been different for note stem positions. All three are reasonable for downstem, it's upstem that's a problem. This also extends to PDF. Here's pics of all three fonts:

Emmantaler has a slight shift _right_ for upstem

Gonville is way out, but still right

Bravura is more right than Emmantaler

Wingtips on system brackets are also bad, tips are typically not attached to the line.
Windows 8.1 64-bit

Attachment Size
001.png 7.26 KB
002.png 6.81 KB
003.png 8.41 KB