[Gonville] Move note flags on X=0 Y=0

• Feb 19, 2014 - 15:06
Type
Functional
Severity
S4 - Minor
Status
closed
Project
Tags

If we keep gonville as a font in MuseScore, it needs to be SMuFl compliant. One thing that needs be done is to move the note flags on the X and Y axis. See http://musescore.org/en/node/23648#comment-95320


Comments

gonville seems to be lacking note flags entirely...

Oops, I see there are several changes in PR 689-693, all close 'prematurly,' by gootector, need to check which of these need to get merged.

flag for upstem notes (but their stems are a bit to far of the note head), it is just the downstem ones where the flags collide with the note head (bit these have the stem align with the note head nicely)

From the PNG I see a slight gap between flag and stem. Upstem stem position seems wrong, too far into the notehead, but downstem seems fine.

Gaps are identical - 32 points for all up and down flags. I can use 30-points gap.
"Upstem stem position seems wrong, too far into the notehead" - shepers - see Maestro and other music fonts.

Here's what I see using Gonville, with up/down stems and flags. There is definitely space between the flag and the stem, and yes upstem's are way off the notehead. The image used by Lasconic is somewhat different from mine.

Attachment Size
01.png 13.17 KB
02.png 20.44 KB

"Upstem stem position seems wrong, too far into the notehead" - shepers - see Maestro and other music fonts.

We are not talking about flags/hook and notehead but about notehead and stems. Do you think it's a bug in MuseScore and not in your font? Maybe metadata.json?

shot_140304_174436.png

Attachment Size
shot_140304_174436.png 6.03 KB

Lasconic, how come my pic of upstem (01.png from above) using Gonville is so different from yours? Mine barely has the stem attached to the notehead.

The issue with upstem being out too far seems to only affect 1.3 scores. Creating a new score in 2.0 (git 4af604c) shows upstem being only slightly out. See the attached pic.

Note, what I see is opposite what Lasconic is seeing. In his, the stems are too far into the head.

Attachment Size
01.png 21.89 KB

I think the problem of stem position is OS-dependent.
I tried with self-compiled versions of the same commit ( 673c2df ) under Windows 8.1 and virtual machines with other OSs; debug build, Qt 5.2.1.
Here is how they render the same two notes with Gonville font:
Windows 8.1
NOT FOUND: 1
Linux Mint 13
NOT FOUND: 2
Mac OS X 10.8.2
NOT FOUND: 3

[I had to use a workaround for the Linux screenshot because of a crash problem]
I can't reproduce the behavior lasconic is seeing.
@lasconic: what is the OS under which you are seeing that behavior?

It seems that the problem appears only under Windows and for upstem only (at least, in my laptop).

Attachment Size
win_gonville.png 1.86 KB
linux_gonville.png 1.85 KB
mac_gonville.png 1.84 KB

I *think* I found where the problem originates.
I made MuseScore print the notehead width for the 3 fonts in Windows 8.1, Linux Mint 13 and Mac OS X 10.8.5, commit 96f13211 , in function Note::headWidth() in libmscore\note.cpp:447
return symWidth(noteHead());
I obtain the results:
Mac
emmentaler hw=6.5625 ; bravura hw=6.625 ; gonville hw=6.3125
Linux
emmentaler hw=8.859375 ; bravura hw=8.953125 ; gonville hw=8.53125
Windows
emmentaler hw=9.0000056692913386 ; bravura hw=9.0000056692913386 ; gonville hw=9.0000056692913386

As you can see, under Linux and Mac the width is actually a real number, while under Windows I obtain a value rounded to the nearest integer (the 6th decimal values and following are probably due to int to float conversion).
As you can see, while the black notehead has roughly the same width for emmentaler and bravura, the width for gonville is smaller: therefore the note does not "attach" properly to the stem line.

I can't understand how to obtain actual real width under Windows: QFontMetricsF::width seems to return an integer value converted to float in this case.

It seems that the problem is due to how QFont treats the hinting preferences.
From Qt documentation:
http://qt-project.org/doc/qt-5/qfont.html#HintingPreference-enum
We have that under Windows, if DirectWrite is not enabled in Qt (and DirectWrite is not supported for Win XP; and by default it is not enabled in Qt), the behavior is the following:

Input:
PreferDefaultHinting PreferNoHinting PreferVerticalHinting PreferFullHinting
Actual behavior:
Full hinting Full hinting Full hinting Full hinting

So for every hinting preference it will give an integer number under Windows.
We solve this in many ways.
- For example, we could use FreeType library to obtain the metrics informations of the glyph. I tried with this, but I was not able to translate the metrics results from FreeType to the ones given by QFontMetricsF.
- We could try with QGlyphRun class. I tried with a quick example, but I was always obtaining 0 width in this case.
- I tried to implement a "dirty trick" to adjust the width. It is not the most elegant solution, but it seems to be working. Basically, I had MuseScore evaluate the width for a pixel size 100 times larger, and then divided this width by 100. You can see the commit in my github account here:
https://github.com/AntonioBL/MuseScore/commit/a92bb3272addb5e76a386039c…
As I said, it is not 100% accurate, but the error in the retrieved width is (much) smaller than 1% and it visually behaves ok. It also solves bug #25142: Stem slightly misaligned on upstem notes for Emmentaler and Gonville (which I think it is due to exactly the same Qt behavior in Windows).

@lasconic: can you try this changes in your Windows machine to see if the problem you see is related to this integer/real problem?

Ciao,
ABL

Thanks for that research! I was hoping this would turn out to be the same root cause as the other stem alignment issue (and a few pther off-by-a-pixel-or-two glitches I sometimes see on Windows). Hopefully one of these solutions will work out.

I assume we don't need to officially support XP, but not working at all doesn't seem like a good option. Would it be possible to set up the build so DirectWrite is enable for other Windows versions but not for XP, so we get the good alignment everywhere but XP?

I fear that DirectWrite support would require to re-compile Qt, and then I fear that it will not work under XP (probably because of missing DirectWrite dlls in the system).
Just to double-check, can you can try the version with the "dirty trick" and check if the misalignment problems disappear also for you?
I compiled it and uploaded here:
https://drive.google.com/file/d/0BxjayMZiuupOaHpNVFMyQUhQbVE/edit?usp=s…
sorry for the huge file dimension: it is a debug build based on 401f48fcd

It's a good fix from what I can see. This change makes Gonville much more attractive.

Question: why is this problem affecting Gonville more than others, particularly with stem location?

Thank you ABL for the investigation!
QGlyphRun is the future way to go. We tried in the past but it was not ready yet.
I tried the third approach (https://github.com/AntonioBL/MuseScore/commit/a92bb3272addb5e76a386039c…) on windows 8.1 with 401f48fcd7 and it works very well!
Would you want to turn this into a pull request? A comment in the code to point to #25142: Stem slightly misaligned on upstem notes and explain why we use a bigger font would be great.

Status (old) active fixed

Thanks to ABL, this bug is now fixed! We use the trick describes in 3. A nice side effect is that the tests are now working the same on windows and linux when it comes to x/y coordinates.
95b441b5dd