Broken on-screen rendering of synthetically emboldened fonts

• Feb 15, 2019 - 19:20
Reported version
3.0
Priority
P1 - High
Type
Graphical (UI)
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project

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:

notbold_camera.png

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.)

notbold.png

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:

notbold-musescore2.png

Attachment Size
notbold_title.mscz 10.85 KB

Comments

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

Chris writes in https://musescore.org/en/node/281601#comment-889251 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:

Screenshot_20190513_154134.png

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 https://musescore.org/en/node/290148 and even worse https://musescore.org/en/node/290149 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:

dpif5.pdf

DPI_F = 1: most everything else broken:

dpif1.pdf

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