MuseJazz Text Producing Corrupted Bold Text in Chord Symbols

• Jan 7, 2021 - 21:33

Using 3.5.2 unstable on several Debian Buster installations.

Create a new score and add a Chord Symbol:
Screenshot_2021-01-07_21-16-47.png

Change font to MuseJazz:
Screenshot_2021-01-07_21-17-20.png

Make it bold:
Screenshot_2021-01-07_21-17-38.png

Deselect it:
Screenshot_2021-01-07_21-17-59.png

As you can see, it's very bold and cropped at the edges.

Example score attached.

Kind regards,
Terry.


Comments

Do you by chance have a version of MuseJazz Text installed "normally" on your system (eg, not just the private version used within MuseScore)? That is known to cause problems. The AppImage should contain its own version that should work OK and does for me. It could also be some other library on your system has a version mismatch with what is expected, although the AppImage tries to isolate itself from those problems. There was a known issue with earlier versions of MuseScore, but that was fixed prior to 3.5.2 - see #284218: Broken on-screen rendering of synthetically emboldened fonts. Not sure what you mean by "unstable", though - 3.5.2 is the current stable version (3.6 coming soon).

In reply to by Marc Sabatella

Thank you for your reply Marc.

I'm not using AppImage. I'm running from the 3.5.2 source ball on a Debian system that has/had 2.3 and 3.2.3 on it. I've removed the other two versions and am still seeing the font corruption. I'm seeing an identical problem on a recently installed debian buster with musescore 3.2.3 hence my attempt at an upgrade.

"3.5.2 unstable" is the version displayed having compiled the 3.5.2 source.

I'm running from the source as I'm hoping to contribute a few patches so it would be rather nice to get it working properly first.

In reply to by Terry Glanfield

My guess is your 3.2.3 installation installed the font globally, so you'll have to find and remove it. I'm not familiar with the details of font management on debian, but assume a web search will turn up info. Although, I'm not really very confident that will turn out to fix the problem. If you follow the trail in the issue I linked to above, you'll see the fix applied for 3.5 was in the code itself, not the font, so if you are truly building from 3.5.2 sources, it should work even with an older version of the font. But it definitely wouldn't be a bad idea to find and delete the font anyhow, as right now it's an uncontrolled variable that would be better to remove from the equation.

In the comments in the source attached to the fix, there is reference to specific Qt versions. Right now we build MuseScore against 5.9. More recent versions may or may not work. Again, with the AppImage, that shouldn't be an issue, but anyhow, do be sure to use 5.9 in your own builds.

And yes, it is probably normal that you'd see an "unstable" label on builds you attempt yourself. Compiling MuseScore is unfortunately very tricky as there are many complex dependencies and the build files are attempting to do reasonable things on Windows and macOS as well. So we always recommend the AppImage as we build that ourselves can do our best to guarantee it works. But indeed, you'll need to be able to build for yourself in order to contribute to the development, so hopefully you do get that sorted out as well.

FWIW, though, my system is debian buster as well (a minimal installation running in a container within Chrome OS), and the AppImage works just fine here, as do my own builds when following the build procedure in the developer handbook.

In reply to by Marc Sabatella

Hi Marc,

I've tried the AppImage and that also showed the font corruption. That's on two different machines. I'll build a clean VM image, try it there and report back.

I'm not seeing any evidence of remnants of 3.2.3 remaining after I removed it. I'm not seeing any other font files either.

In reply to by Terry Glanfield

To be clear - you checked your global font folders (I did a web search, I guess they are /usr/share/fonts) to be sure the font does not exist there?

I see also in the comments that depending on your Qt version, there is an environment variable that could be relevant here. Do you have QT_MAX_CACHED_GLYPH_SIZE set? Try unsetting it if so.

Other than that, I'm not sure what else to check. Maybe do "env | grep QT" and report everything you see there, maybe something else will seem relevant. FWIW, I have this:

QT_ACCESSIBILITY=1
QT_XCB_NO_XI2=true
QT_QPA_PLATFORMTHEME=gtk2
QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
QT_AUTO_SCREEN_SCALE_FACTOR=1

I think I set most of those myself, although I don't actually remember QT_QPA_PLATFORMTHEME.

In reply to by Marc Sabatella

One other thing to check is your screen resolution & zoom settings. With everything configured properly, 100% zoom (as per the main toolbar) should show your score life-size - same as when printed. If not, something is off, and you may need to play with that QT_AUTO_SCREEN_SCALE_FACTOR setting and/or the "-D xxx" command line option (where "xxx" is your actual screen resolution in DPI) until it does scale properly.

I mention this as possibly relevant because I can confirm that if I zoom way small - like 30% or less - then the bold MuseJazz does not do so well. It looks fine anything close to 100% though, or larger. And I can force it to happen at 100% if I deliberately misrepresent my screen resolution to be much less than it is. Then my score is tiny by default, and I do see the glitch.

EDIT: I can also see the glitch at "normal" zoom settings at certain point sizes - 27 pt seems to show some of the problem even at 100%. But it corrects itself at higher zoom. In any case, it's an onscreen glitch only - PDF export is fine, so is image capture.

In reply to by Marc Sabatella

You're on the right lines I think. To test the scaling I increased the point size. Here it is at 54 point:
Screenshot_2021-01-08_18-09-56.png

And here at 55 point:
Screenshot_2021-01-08_18-10-14.png

Suddenly a threshold is reached and the character scales properly.

I tried all of your QT parameters (I didn't have any set) with no change.

-D 100 allowed the character to remain uncorrupted down to 47 point.
-D 120 ... 40 point
-D 240 properly scaled the character all of the way down to 1 point but the experience is quite odd as the toolbar is huge:
Screenshot_2021-01-08_18-18-47.png

The result of this experiment leads me to think that the font corruption is algorithmic and correctable.

In reply to by Terry Glanfield

You should be using the actual DPI of your monitor as the "-D" parameter. This will result in your score being life-sized - same size as when printed - at 100% zoom.

And yes, as I indicated earlier, the changes made to improve the rendering of these fonts is in the code, and obviously it's not perfect still. We're trying to work around bug in the the underlying font rendering libraries we rely on. Really, we need the libraries themselves fixed I think.

Anyhow, I would say at this point the mystery is about as solved as it is going to be - the on-screen rendering is dependent on font size, zoom, and screen resolution, so different people will indeed see different results. The defaults should work reasonably well on most systems, but certain combinations of settings and systems can still be problematic.

A fuller solution would be to provide a "true" bold version of MuseJazz rather than depending on the libraries to approximate it on the fly. But even that would only fix it for MuseJazz, not for other fonts that you might want to use that lack a bold variant.

Anyhow, you mention wanting to get involved with development, if improving any of this in any way interests you, I think maybe you've found your first potential contribution :-)

In reply to by Marc Sabatella

Actually, I think it may be simpler than this, I think. On my system at least, I can only reproduce this effect with chord symbols, no other type of text. If you are seeing the same, then I think a reasonable conclusion is that the fix itself is good, but the special rendering of chord symbols (they are handled much differently than other types of text) isn't taking advantage of the fix. So we would just need to fix that.

In reply to by Marc Sabatella

For completeness, I installed the AppImage version and am still seeing font corruption! Where should I start trying to track this down?

Here's the log though it doesn't look very interesting:

/usr/lib/x86_64-linux-gnu/libjack.so.0
/usr/lib/x86_64-linux-gnu/libnss3.so
libGL error: failed to authenticate magic 1
libGL error: failed to load driver: r600
qrc:/qml/TelemetryPermissionDialog.qml:37: ReferenceError: globalStyle is not defined
qrc:/qml/DialogButton.qml:74: ReferenceError: globalStyle is not defined
qrc:/qml/DialogButton.qml:74: ReferenceError: globalStyle is not defined
QXcbConnection: XCB error: 3 (BadWindow), sequence: 823, resource id: 22761129, major code: 40 (TranslateCoords), minor code: 0
qrc:/qml/DialogButton.qml:74: ReferenceError: globalStyle is not defined
qrc:/qml/DialogButton.qml:74: ReferenceError: globalStyle is not defined
qrc:/qml/TelemetryPermissionDialog.qml:37: ReferenceError: globalStyle is not defined
qml: STATE CHANGED HOVERED
QXcbConnection: XCB error: 3 (BadWindow), sequence: 2959, resource id: 22765655, major code: 40 (TranslateCoords), minor code: 0
qml: STATE CHANGED
Failed to compute left/right minimum bearings for "micro.pcf"
Failed to compute left/right minimum bearings for "micro.pcf"
Failed to compute left/right minimum bearings for "micro.pcf"
OpenType support missing for "Newspaper", script 13
qml: STATE CHANGED HOVERED

In reply to by Jojo-Schmitz

I removed the two versions each of which had MuseJazz.mss in them. I've searched the filestore for anything that looks like a jazz font without finding anything. If there was an old font there what would it be called?

Note that the other machine I mentioned was a clean install so wouldn't have anything old on there.

Do you still have an unanswered question? Please log in first to post your question.