Chords in french notation are not formated correctly if accented letter expected

• Jan 3, 2019 - 14:44
Reported version
P1 - High
S3 - Major

When addind chord with french notation, the chord isn't formated correctly if accented letters is expected.

  1. Set in Style > Chord symbols "French notation" and disable automatic capitalisation
  2. In a score, add a chord (CTRL=K) and enter : "Ré" or "ré" : result = "Ré" -> OK
    But enter "Re", "re" or "RE", the result is : "Ré". Expected result : "Ré"


Status active needs info

I can't reproduce - works fine for me. What font are you using for chord symbols? A custom chord symbol style file, perhaps? Can you attach your score?

Frequency Once Few
Regression No Yes
Severity S4 - Minor S3 - Major
Status needs info active
Priority P1 - High

New score
switch to french chord symbols
start entering chord symbole, Ctrl+K
enter "Re"
hit Space

expected: this turns into "Rè"
actual: it turns into "Rã©"

Which actual font, though? Again, I can't reproduce, works fine for me right out of the box using the default empty score or a new one I create from Treble template (thus, FreeSerif). I'm on Windows 10, US English, using the built-in version of FreeSerif (that is, it is not installed on my system). I still would like to see someone post an actual score with the problem, so I can tell if it is something within the score itself that is different between our systems or not. That could be the case if there was a problem in the parsing code, for instance, or reading the XML file.

Seems to be a Windows issue, it isn't reproducible with Linux. No matter if I enter "re" or "Re", the result is always "Ré".

I indeed use Qt 5.12 for self build, release uses 5.9.x still (waiting for AppVeyor to support 5.12). Mac release uses 5.12
I'll try a 5.9.7 build tomorrow.

Yes, I am using MSVC and MinGW with Qt 5.12 on my desktop (all 64bit), but still have a MinGW/Qt 5.9.7 (32bit) setup on my laptop, which is where I wanted to try this, thanks for reminding, I had forgotten already

I see a change on last August 3 (or/and beginning August 4). The last nightly on August 2 works: 8366ff1 (and this one fails: e98043a)
There is a few commits about compilation under MSCV - don't know what it is exactly :) - but might be here (?)

OK, I can't reproduce with 32bit MinGW and Qt 5.9.7, nor with 64bit MinGW and Qt 5.12, but can with MSVC 64bit Qt 5.12. Latest master in all 3 cases. Missing case: MSVC 64bit (with Qt 5.12)

So it seems MSVC is the culprit?

Fix version