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

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.

30-points gap should solve this problem. You're right. Flags doesn't look good with this small gaps.

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.

Ok, ok, ok. Not all at once :D Here is file: http://musescore.org/en/node/24199 with fixes - gaps, dot, letters.

For me too the upstems are too far out of the note head, not too far in. Using the Promenade example and switch to Gonville:

And this with the latest update, 8200c84

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.

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).

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:

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?

A guess: the others have notehead widths that actually are close an integer in width?

Automatically closed -- issue fixed for 2 weeks with no activity.