fix #280244 : [Workaround] User fonts not visible to MuseScore 3 (Windows 10)

[AntonioBL]

Resolves: https://musescore.org/en/node/280244

Because of QTBUG-73241 ( https://bugreports.qt.io/browse/QTBUG-73241 ), when using freetype engine under Windows 10 (after update 1809), fonts installed in the user-specific folder C:\Users\UserName\AppData\Local\Microsoft\Windows\Fonts cannot be found by Qt. This is solved for Qt 5.12.2. However, current MuseScore build still uses Qt 5.9.
This is a workaround to add those user-specific fonts to the application.

• I signed CLA
• I made sure the code in the PR follows the coding rules
• I made sure the code compiles on my machine
• I made sure there are no unnecessary changes in the code
• I made sure the title of the PR reflects the core meaning of the issue you are solving
• I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
• I made sure the commit message title starts with "fix #424242:" if there is a related issue
• [N/A] I created the test (mtest, vtest, script test) to verify the changes I made

[AntonioBL]

As @Jojo-Schmitz correctly points out, this could probably not work well if duplicates are present. However, in that case it was the user responsibility for locally installing a font with the same name of a font already installd in the system folder (if Windows allows this at all).
Prior to Windows 10 1809 fonts could be installed only in system location C:\Windows\Fonts.
This workaround, only for Windows >=10, adds also all the fonts present in C:\Users\UserName\AppData\Local\Microsoft\Windows\Fonts to the fonts known by MuseScore.

Note that the same workaround is also done by Inkscape (e.g. https://gitlab.com/inkscape/inkscape/-/commit/a456169068e7a1ca8715860715fbe912d6cf7fa5 )

[Jojo-Schmitz]

Well, I was not talking about fonts installed twice, for system and for user, but for systems pre Windows 10 1809, which see both sort of fonts by default and without the workaround already, and my question was whether these now seem them twice, once by default and a 2nd time due to the workaround.

[AntonioBL]

Ah sorry, I misunderstood your comments. 😅
For systems pre Windows 10 1809 fonts could be installed only in Windows/fonts (i.e. only at sytem level), so no problem. For them (but only if Win 10) this workaround could load additional fonts if the user (or some other programs) put them in AppData\Local\Microsoft\Windows\Fonts.
For systems post Windows 10 1809, for MuseScore 2.x local fonts are already loaded since the fontengine was not freetype (the switch happened for MuseScore 3.x); for MuseScore 3.x, only system fonts are visible, but with this workaround also local fonts are visible.

[jeetee]

Do we have someone that can test the possible duplication?
Although I'm not that worried if it turns out to be twice in the list for those systems; looking at the workaround and how the Fontwrappers work, they both should point to valid entries and thus work.

[AntonioBL]

I tested with two different fonts that I modified with FontForge so that they have the exact same name (including internal names). I then installed one in the user folder and one in the system folder.
Here are the behaviors I saw:

• Windows Settings -> Personalization -> Fonts shows the one installed in system folder
• LibreOffice 6.4.3.2 shows the one in current user folder
• MS Word 2010 shows the one in current user folder
• MuseScore 2.3.2 (portable) shows the one in current user folder
• Inkscape 1.0 shows the one in system folder (and the one in current user folder if the one in system folder is deleted)
  And finally:
• MuseScore with this PR shows the one in current user folder

Therefore in presence of a duplicate font (where the two copies have the exact same name, including the internal names) MuseScore with this PR behaves like MuseScore 2.3.2, MS Word 2010 and LibreOffice 6.4.3.2.

[Spire42]

Aside from this one small correction, this PR looks good to me.

I want to point out, however, that this is only a partial workaround. As I explained in this comment:

That workaround works only if the user has direct access to the font files.

In some cases the user does not have access to the font files. One popular example is the Adobe Fonts service, which is one of the benefits of an Adobe Creative Cloud subscription. Another popular example is SkyFonts, which is used by several large font providers, including Google Fonts. Fonts installed via services like these are usable in applications that use native Windows APIs for font handling, but the files themselves (e.g., .ttf and .otf files) are protected behind a DRM layer. This means that third-party font renderers, such as FreeType, cannot access them at all (and cannot even enumerate them). The only workaround for such fonts is to disable FreeType in MuseScore in favor of native Windows APIs.

In short, this workaround will fix fonts that are missing because they were installed per-user, but not fonts that are missing because they're DRM-protected.

The only way to fix the latter is to use native font rendering instead of FreeType. But that would make MuseScore's visual output different on Windows from other platforms, which would in turn break vtests under Windows.

[AntonioBL]

That workaround works only if the user has direct access to the font files.
In some cases the user does not have access to the font files. One popular example is the Adobe Fonts service, which is one of the benefits of an Adobe Creative Cloud subscription. Another popular example is SkyFonts, which is used by several large font providers, including Google Fonts. Fonts installed via services like these are usable in applications that use native Windows APIs for font handling, but the files themselves (e.g., .ttf and .otf files) are protected behind a DRM layer. This means that third-party font renderers, such as FreeType, cannot access them at all (and cannot even enumerate them). The only workaround for such fonts is to disable FreeType in MuseScore in favor of native Windows APIs.
In short, this workaround will fix fonts that are missing because they were installed per-user, but not fonts that are missing because they're DRM-protected.
The only way to fix the latter is to use native font rendering instead of FreeType. But that would make MuseScore's visual output different on Windows from other platforms, which would in turn break vtests under Windows.

In principle, we could return to using the native Windows Qt font engine, but I don't know if it behaves properly for those DRM-layered fonts. Moreover, it would reintroduce a bug for underlined words ( https://musescore.org/en/node/276566 ) and possibly hyphen position.
For that bug I could not find a working workaround.
Font handling in Qt is a mess, and patches are applied only to the most recent versions.

[Spire42]

In principle, we could return to using the native Windows Qt font engine, but I don't know if it behaves properly for those DRM-layered fonts.

I just did a quick test with several DRM-protected Adobe fonts (by setting the Qt renderer back to native), and they all seemed to work fine for me.

BTW, I want to be clear that I'm not at all suggesting that we change the default font renderer as part of this PR. (This PR is good as it is.) I'm just requesting that we consider this PR to be only part of the full solution. And now that I've learned that we actually used to use the native font renderer under Windows (as recently as 2018), and that we switched to FreeType to work around some bugs, I'm suggesting that we investigate the possibility of going back to it because of this issue.

I guess it would make the most sense to consider this PR to be a full fix specifically for the “user fonts” issue, and to open another issue for “DRM-protected fonts” — even though both issues are fixable by switching back to native rendering.

[Spire42]

This is a good working fix for the “missing user fonts” issue. We can consider the “missing DRM-protected fonts” issue a separate one to be addressed later.

[anatoly-os]

No need for master since we will probably use Qt 5.12 LTS version there.

[Jojo-Schmitz]

Maybe even Qt 5.15 LTS?