Broken on-screen rendering of synthetically emboldened fonts

• Feb 15, 2019 - 19:20
Reported version
P1 - High
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)?

@ABL I’ve tried it, and it fixes the bold fonts (the tempo “Andante con moto” in the attached PDFs), but it’s broken: the testsuite fails and even worse and the files stored by a build with DPI_F = 5 are rendered badly by a build with DPI_F = 1 but see for yourself: everything offset is wrong, the noteheads are smaller, …

DPI_F = 5: bold fonts broken:


DPI_F = 1: most everything else broken:


My recommendation is to open both in PDF viewers, make both to full screen, scale to page width, then quickly switch between the two fullscreen windows, this way you can easily visually spot the differences. (Sorry for the length, I had a shorter score that exhibited the problem but it’s copyrighted by someone else so can’t upload, and I don’t have many 3.x scores yet.)

I guess there are really many places where implicit DPI_F scaling is done, especially in the file format, which makes this “fix” a non-solution.

Attachment Size
dpif1.pdf 141.03 KB
dpif5.pdf 141.64 KB

Unfortunately, the proposed fix is not the solution.
It fixes the appearance of the single characters, but it breaks their relative positioning. In particular, it badly reopens issue #117191: [Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2.
The problem is a bug of Qt when using freetype font rendering engine.
The only possible solutions I see are:
1- somehow re-implement drawing of texts, or at least bold texts when freetype engine is used.
2- or use Qt > 5.12.1 and set QT_MAX_CACHED_GLYPH_SIZE to 1 in the main function before launching the Qt application, but possible performance regressions could appear.

Note that under Windows it is possible the workaround of deleting the following:
WindowsArguments = fontengine=freetype

from bin/qt.conf (it can be done with any text editor), but then issue #276566: [Windows] underline too close to (lyrics) letters would be reintroduced.
But under Linux the only possible font rendering engine is freetype.

I am not sure about the details, but it seems this fix is not as complete as hoped. See and surrounding discussion and examples.

From my own experiments, it seems perhaps the fix is not being applied to chord symbols, perhaps because chord symbols go through different code paths. Maybe we could factor out the workaround code and use it within both TextFragment::draw() and Harmony::draw()?

Fix version