[MU4 Issue] The string "Nr." turns into "№" when using Edwin

[Jojo-Schmitz]

The string "Nr." in a vertical frame turns into "No" (with the o being underlined and superscripted), when using the Edwin font.
Same happens with staff-and system text and lyrics, even in instrument names, probably more.

To Reproduce
Steps to reproduce the behavior:

1. Take any score, from 3.6 or later, or create one from scatch.
2. In the Title Frame make sure there's the String "Nr.", e.g. in a Subtitle.
3. Make sure it is using the (default) Edwin font (no other font shows this behavoir).
4. See the error, "Nr." turns into "№" (but "No." does not!?).

Expected behavior
The string should not get changed and stay "Nr.".

Screenshots
This is what it looks like:

This is what it should be (or rather stay, like it does for 3.6.2):

Desktop:

• OS: Windows 10

Additional context
Same issue is seen with the current 3.x branch. So the culprit got to be one of the commits to that after 3.6.2 got released, and one that also got ported over to master.
Note that in the status bar it still shows "Subtitle: Nr. 330"

[Jojo-Schmitz]

See also MuseScoreFonts/Edwin#5

[maximebochon]

I expressed a contradictory point of view in the Edwin issue you mentioned: MuseScoreFonts/Edwin#5

[Jojo-Schmitz]

I'm not against that glyph, but against the automatic conversion of "Nr." into that glyph, as this is plain wrong. Doing the same for "No." might be OK though, not sure.

Many years ago there had been a long discussion about converting "(C)" into "©", the final decision was to not change stuff under the users' feet, out of the users' control. Not even only for the copyright field!

[maximebochon]

I understand. For sure the user should have the choice. It would be sad that a user get rid of Edwin just because of that, so giving her the choice would definitely be a good thing.

[maximebochon]

Actually, it's strange because I don't reproduce that phenomenon on my MuseScore version and OS:

• Windows 10 (10.0), Arch.: x86_64,
• MuseScore version (32-bit): 3.6.2.548021803,
• revision: github-musescore-musescore-3224f34

[Jojo-Schmitz]

Indeed, the issue is only with the development version from the 3.x and the master branch. I stated that in the initial post...

Why using a 32-bit version of MuseScore on a 64-bit version of Windows (x86_64)?

[maximebochon]

I don't have admin rights on the Windows 10 of that computer so I run a portable version of MuseScore. Is there a 64-bit portable version? Or a way to install it without having admin rights?

[Jojo-Schmitz]

Ah, I see, no, indeed the PortableApp is 32-bit

[maximebochon]

I don't reproduce here neither:

• OS: Ubuntu 18.04.5 LTS, Arch.: x86_64,
• MuseScore version (64-bit): 3.6.2.548021370,
• revision: github-musescore-musescore-3224f34

(Latest official AppImage)

[Jojo-Schmitz]

Again: 3.6.2 is not affected by this issue, only later 3.x and master development versions