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()?

I fear that the cause of this, the internal magnification, is also breaking underlining (without bold, but in PDF not just on screen).

Compare LibreOffice vs. MuseScore with comparable font magnification:


In MuseScore, the underline is barely there (grey means it’s very very very thin) and much too close to the letter.

This can be explained by MuseScore doing the rendering in 5× magnification, but doing the underlining without that. If you render in 5× magnification in LibreOffice…


… and scale that down, you get good enough underlines…


… but if you use the underlines from the 1× magnification, which are thinner and in less distance from the glyphs, you get what I see in the PDFs, making underline (just like superscript and subscript, which scale down by too much making the superscripted/subscripted letters illegible) totally unusable in MuseScore.

@ABL wdyt?

In reply to by mirabilos

It’s probably bad if I start wondering whether I can somehow postprocess the PDF file, with sed or qpdf in QDF format or so, to fix this… but importing the first page into Inkscape pointed out an interesting thing:


The stroke-width CSS property of the underline is exactly 0.2 and setting it to 1 brings a look quite similar to the one from LibreOffice’s underlining, above.

I don’t think I can guesstimate the position offset right, though :/ but this is another point in favour of that theory.

Perhaps the way text fonts are rendered in MuseScore is systematically wrong from the ground up? That being said, where would that be?

Ciao mirabilos,
I don't remember the details because some time passed since I last worked on this.
I remember I had tried to investigate the behavior of underline and bold, and it was a problem coming directly from Qt and the fact that the zoom in MuseScore was scaling the "wrong" properties of the painter (MuseScore <=3.x is scaling the diagonal elements of the painter matrix for the zoom). If I remember correctly, it was not possible to scale the thickness of the underline to match the behavior of the fonts.

See here a discussion about underline under Windows, before the switch to Freetype (the same engine used under Linux) for font rendering:

If I remember coorectly, pdf should export fine if the resolution is 360 dpi (this value basically makes the daigonal elements of the transformation matrix of the font painter equal to 1.0). Which resolution are you using?

The bug about bold + underline is this one:
The "poor man" solution was to disable the workaround for bold+underline case.


In reply to by ABL

Huh, so the underline is somehow totally bogus. Interestingly, the Windows problem that “goes away” when switching to Freetype is related to the one I have on GNU/Linux with Freetype.

The underline is not only rendered too close to the letter but also too thin, so I’d not say it works.

Scaling the… wrong property of the painter? How does that even work out? Why not draw everything at the right dpi?

And yes, I’m using 360 dpi for PDF export and it still looks catastrophic: (this from 3.2.3, but a portable 3.6.2 on Windows results in the same problem in the PDF (but, for some reason, slightly wider texts with the SAME font‽))

Fix version