[Windows] underline too close to (lyrics) letters

• Sep 25, 2018 - 09:43
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

Version 2.3.2 and current 3.0 dev.

1) Upload this file: AZ selection.mscz
(or complete version): AZ_CHTE_SE_PODMLADIA piano MP.mscz

2) Double-click a syllable, and in Text toolbar: click on the Underline symbol

  • Expected:
    Capture d'écran 2018-09-25 10.02.12.png

  • Actual and unexpected result: the underline almost clashes with the words base.

    mesure 10.jpg


Comments

This is the same problem we are having. What can be done about the unexpected display of the underline feature. We depend on it for our use. Are we stuck using an old version of Musescore?

Kenneth

Underline works, it just gets rendered (slightly) different (closer to the letters), I don't see a big issue here. It is an issue since MuseScore 2.2, you could of course use 2.1 instead to generate your PDFs if you really need those underlines with more distance to the letters.
The question is whether this is Windows only, or also Mac and Linux?
A short test with saving a score online seems to indicate that Linux (which is what musescore.com uses to render scores) doesn't have that issue. So there's another workaround :-)

Title [Windows] Unexpected display of underline feature [Windows] underline to close to (lyrics) letters
Frequency Few
Regression Yes
Reproducibility Always
Workaround No

It should be possible to fix, although I have no idea how

Severity S4 - Minor S3 - Major

Raised to Major Severity. And even if Normal was possible, I think Major would be adapted.
Because it' really an unexpected and ugly rendering. And not up to it, worthy of a major version release.

Title [Windows] underline to close to (lyrics) letters [Windows] underline too close to (lyrics) letters
Priority P2 - Medium P1 - High

I strongly suspect it could be a Qt bug.
I asked for help in Qt forum, here: https://forum.qt.io/topic/96900/strange-behavior-of-underline-when-scal…
Attached you can find my test program and the resulting svg under Windows 10, Linux Mint 18 and MacOS 13.
Under the hood, MuseScore is scaling up the text for better resolution (due to the antialiasing behavior under Windows) and then rescaling down the drawn text, but for large text size Qt draws the underline attached to the text base line under Windows: this is exactly what we are seeing here.
At the moment I do not have idea of what work-around we could use, except for re-implementing the drawing of underline (which could possibly be a hard task).

Attachment Size
font_underline.zip 762.68 KB

It definitely Qt's fault.
The underline position is calculated inside QPainter, starting form the value taken here:
https://code.woboq.org/qt5/qtbase/src/gui/painting/qpainter.cpp.html#62…
const qreal underlineOffset = fe->underlinePosition().toReal();
now, the QFontEngine fe is different among the different Operating Systems and the returned underlinePosition is also different.
Under Windows it calls QFontEngine::underlinePosition()
https://code.woboq.org/qt5/qtbase/src/gui/text/qfontengine.cpp.html#_ZN…
which calls lineThickness() from QWindowsFontEngine
https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/win…
I suspect that this lineThickness does not scale with the pixelsize, therefore resulting in the same underline distance even when the font is upscaled and thus determining basically "no space" for large pixel size (remember that now the fonts are actually upscaled in MuseScore rendering).
Under Linux it calls QFontEngineFT::underlinePosition()
https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/fre…
which, on the other hand, computes the position for the underline extracting the information from the font itself via FreeType:
https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/fre…

To cut a long story short, I think I found a workaround by forcing Windows to use the Freetype font rendering engine, similar to what is used under Linux. With the use of FreeType this bug is solved. However, I don't know if there could be side-effects. In principle we are already using FreeType for text rendering under Linux.
To activate freetype we can launch in the command line Musescore.exe -platform windows:fontengine=freetype
or, alternatively, add to bin/qt.conf these lines:
[Platforms]
WindowsArguments = fontengine=freetype

@Jojo-Schmitz : with 2.3 or current master?
Because the huge font problem is something I already saw under Linux when experimenting with https://github.com/musescore/MuseScore/pull/3298 and applying it also to Linux.
I don't know why it happens, but the texts appears correct when you zoom in. I think it could be a problem of some sort of max font size after which the font rendering engine is different. With https://github.com/musescore/MuseScore/pull/3298 the font size is actually 100 times the size you set, and it is then downscaled by a factor 100 (under Windows).
In master the correction factor is 5 ( https://github.com/musescore/MuseScore/blob/27a6d3a4a2393a51ec273169d3f… ) so I think even large texts should not enter this huge-rendering zone (at least, no one reported it for Linux up to now, I think).

Edit: I forgot to say that I was testing with master branch. Under 2.3 I see the huge text when using FreeType font engine.

Regression Yes No

I was getting emails on the conversations of you fellows trying to figure out this underline problem. Has a solution been found? If so, i would like to know so we can go to a newer version. Otherwise we are stuck on v 2.1.

Kenneth

Regression No Yes

This issue is closed, and got closed before 3.0, got released, so it is considered fixed.
Juyt try it out, MuseScore 3 and MuseScore 2 do peacefully coexist on the same computer