Broken on-screen rendering of synthetically emboldened fonts
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 |
Comments
See #279766: MuseJazz text messed up on import 2.x => 3.0 and #281601: Musescore 3 FreeSans bold text rendering is bad. I'm assuming these are all related, but I simply cannot reproduce any such problem myself on WIndows 10 (not with MuseJazz nor FreeSans nor Gentium).
In reply to See #279766: MuseJazz text… by Marc Sabatella
The test score I attached was created from scratch in 3.0.2, in order to exclude import/conversion issues.
I’ve also tried a patch to make font handling more closely resemble 2.3.2; that does not work, though ☹
@mirabilos : can you please try the (possible) workaround described here: https://musescore.org/en/node/281601#comment-906725 and see if it solves this problem?
In reply to @mirabilos : can you please… by ABL
Ciao ABL, exporting
QT_MAX_CACHED_GLYPH_SIZE=1does not make any difference at all.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=1before launching MuseScore makes this bug disappear.In reply to Actually, I found it is… by ABL
Ciao ABL,
ah, okay, thanks for the in-depth research.
But, what does 3.x do different from 2.3.2 to cause this behaviour? They use the exact same Qt libraries (indeed 5.11 in Debian unstable, running the both of them in parallel), and I had a hard time finding anything different wrt font handling (see https://musescore.org/en/node/284218#comment-895684 for my experimental patch), and even that wasn’t it.
Ciao.
I think the main change was the change of dpi: the actual dpi in 3.0 is basically 5 times larger than in 2.x, governed by this factor:
https://github.com/musescore/MuseScore/blob/8920c762e99b445e5ddd7d1dfbd…
and this determines a scaling of the painting matrix which gives this strange behavior (but I still didn't find if we can somehow keep the high dpi and scaling the matrix in a different way).
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)?
Basically, the rendering ought to always be done at the real “destination” dpi…
In reply to Basically, the rendering… by mirabilos
For testing, if you can compile MuseScore in your system, you can simply change the factor DPI_F I pointed out in https://musescore.org/en/node/284218#comment-907050.
In reply to For testing, if you can… by ABL
Ah okay, so that one-liner is all of it?
I’ll try that then, thanks!
@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 = 5are rendered badly by a build withDPI_F = 1but 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_Fscaling is done, especially in the file format, which makes this “fix” a non-solution.Hi there,
Is there a solution for this yet?
Best,
F
no
See https://github.com/musescore/MuseScore/pull/5794
Came up again in https://www.facebook.com/groups/musescore/permalink/4328627920496826/
Including it in 3.5 would be golden.
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:
[Platforms]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.
Related to #302647: Bold Text is blurry
In reply to Related to #302647: Bold… by Sunny2019
Of course it is, that's why it got closed as a duplicate if this here.
Fixed in branch 3.x, commit d5e7249f9a
fix #281601 and fix #284218 [workaround]: broken on-screen rendering of synthetically emboldened fonts
Fixed in branch 3.x, commit eb33bfa833
_Merge pull request #5794 from AntonioBL/boldfont
fix #281601 and fix #284218 [workaround]: broken on-screen rendering …_
Automatically closed -- issue fixed for 2 weeks with no activity.
I am not sure about the details, but it seems this fix is not as complete as hoped. See https://musescore.org/en/node/315267#comment-1050966 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?
Bold+Underline seems to also be quite wrong (on screen; in PDF they’re “normally” broken).
In reply to I fear that the cause of… 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-widthCSS property of the underline is exactly0.2and 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: https://musescore.org/en/node/276566
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: https://musescore.org/en/node/307075
The "poor man" solution was to disable the workaround for bold+underline case.
Ciao,
ABL
rather #276566: [Windows] underline too close to (lyrics) letters and #307075: [Windows, Linux] Bold and underlined text is not displayed properly ;-)
In reply to Ciao mirabilos, I don't… 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: http://www.mirbsd.org/music/free/Hughes%20--%20Calon%20L%C3%A2n.pdf (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‽))