Broken on-screen rendering of synthetically emboldened fonts

• Feb 15, 2019 - 19:20
Reported version
Graphical (UI)
S2 - Critical

When I install a font like Gentium that does not have a Bold weight, I have a display problem in 3.0.2 which worked in 2.3.2: the font normally is artificially emboldened by Freetype (I have set it up to do so, but I think this is now the default in most distros, and even Qt does so?), and this works if I export a score to PDF or take a screenshot with the Camera icon:


It, however, does not work on-screen, where it looks clunky. (Somehow, it works sometimes in the lyrics, but not in the reproducer dummy score I attached.)


I have no idea why this does not work in 3.0.2 but does work in 2.3.2; again, both use the exact same Qt version as this is Debian unstable. Proof: export as MusicXML, import in 2.3.2, screenshot follows:


Attachment Size
notbold_title.mscz 10.85 KB


I believe this is a different issue from #281601 even if they have the same underlying problem.

Chris writes in that the problem is that sometimes, synthetically boldened and/or italicised fonts are used. (And that those are then rendered bad.) Instead of the (apparently existing) non-synthetic ones.

This issue is about a synthetically boldened font being rendered bad, but in this case, there is no “Gentium Bold”, so the synthetic emboldening is actually required (it just should not look bad).

Funnily enough, it works in the PDF export and screenshot tools, just not in the editor, and only in version 3.

Actually, I found it is exactly the same issue; with Gentium font I can reproduce it under Linux Mint 19.1.
And unfortunately, the trick of setting QT_MAX_CACHED_GLYPH_SIZE to a user value by mean of an environmental variable works only for Qt >= 5.12.1, so it won't work for MuseScore in the first post (Qt 5.11.3, Debian unstable, if I understood correctly) nor in official Appimages (Qt 5.9.3).
I tried with a personal build with Qt 5.12.2 and export QT_MAX_CACHED_GLYPH_SIZE=1 before launching MuseScore makes this bug disappear.

Severity S3 - Major S2 - Critical

Screenshot from two PDF readers side by side, on the PDF exports from the same MSCZ:


It’s also broken in PDFs (left MuseScore 2.3.2, right MuseScore 3.0.5) ☹

I can believe it being a dpi/rendering issue. The synthetic emboldening would use the “internal” resolution (the one which was increased by factor 5 in MS3), and thus the distance between the original and the copy (synthetic emboldening works by rendering the font twice, with a very tiny distance, to make it appear fatter) would be much too small to appear in the actually-meant dpi.

Is there a knob (ideally run-time option, but for testing, compile-time would also work) where we can test this (an A/B test where the only difference is that in the B build of 3.0.5, the factor 5 is reduced to factor 1)?