[MU4 Issue] MuseJazz bold renders poorly in some situations

[MarcSabatella]

Describe the bug
MuseJazz renders poorly in bold in some situations

To Reproduce
Steps to reproduce the behavior:

1. Create a score using jazz lead sheet template
2. Add a tempo marking and "swing" text (both will be bold by default)
3. Save
4. Go to Home tab (may need to quit/restart first so it appears)
5. See error: bad rendering of the tempo/swing text in the thumbnail

Expected behavior
MuseJazz bold should render normally

Screenshots

Platform information

• OS: Linux

Additional context
This is one way to see the issue. But it also happens directly within MuseScore on some platforms if you try underlining the text, or if you try downsizing it. This has been an issue on and off in the past and apparently still is in at least this case. I can't reproduce any other effects on my current system with MU4 but I've seen it in the past and there is a current report of this in MU4(#12714). I believe the issue is probably bad metrics on the font, or bad options generating the OTF or TTF file, or bad choice of rendering library, or something specific to the way font scaling is performed within MuseScore.

[Tantacrul]

@oktophonie - have you even the slightest idea why this might be happening? 😄

[oktophonie]

None whatsoever!

[MarcSabatella]

I remember that there were similar issues in the past so I did a little digging and have at least some idea of what is happening.

Because MuseJazz doesn't have a true bold variant, it relies on "synthetic" boldening done in the rendering engine. This has been a problem for a long time, not just with MuseJazz, but other fonts. See https://musescore.org/en/node/284218 and https://musescore.org/en/node/281601. Apparently, there is some sort of bug in Qt and/or the FreeType rendering engine causing this. In the past, a hack was found to work around the problem, resulting in #5794, which allowed MU3 to work.

Whatever is responsible for generating those previews probably needs to deal with this as well. The thing is, the Qt bug this was working around was supposedly fixed in Qt 5.12, so it shouldn't still be affecting us. But maybe we are applying it somewhere we shouldn't be?

Anyhow, the relevant code in MU4 seems to be

MuseScore/src/engraving/libmscore/textbase.cpp

Line 764 in 6fa543e

void TextBase::drawTextWorkaround(mu::draw::Painter* p, mu::draw::Font& f, const mu::PointF& pos, const String& text)

. Either this function isn't doing what it needs to be doing here, or it isn't being called at all, or it's being called when it shouldn't be.

[AntonioBL]

Ciao.
If I remember correctly, it should be solved in Qt 5.12 if we set an environment variable before (or maybe during?) the initialization to avoid font caching (and we use the normal painting method instead of the hack).
See #5794 (comment)
and here
(and this should solve also issue #12714 which is actually caused by a special case outside the workaround otherwise there were problems with the underline)

[AntonioBL]

I think the main problem is the fact that the diagonal memeber of the painter matrix are not always 1.0, i.e. we scale the coordinate system instead of the elements when doing the zoom.
When the diagonal elements are 1.0 (i.e. no coordinate system scale) there is no bad font rendering.

[Jojo-Schmitz]

FWIW: same issue with 3.x and its startcenter