MuseJazz Text Producing Corrupted Bold Text in Chord Symbols
Using 3.5.2 unstable on several Debian Buster installations.
Create a new score and add a Chord Symbol:
Change font to MuseJazz:
Make it bold:
Deselect it:
As you can see, it's very bold and cropped at the edges.
Example score attached.
Kind regards,
Terry.
Attachment | Size |
---|---|
Screenshot_2021-01-07_21-16-47.png | 3.18 KB |
Screenshot_2021-01-07_21-17-20.png | 3.59 KB |
Screenshot_2021-01-07_21-17-38.png | 3.63 KB |
Screenshot_2021-01-07_21-17-59.png | 3.24 KB |
Untitled.mscz | 6.54 KB |
Comments
The font is actually MuseJazz Text, not MuseJazz if that makes a difference.
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 Do you by chance have a… 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 Thank you for your reply… 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 My guess is your 3.2.3… 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 Hi Marc, I've tried the… by Terry Glanfield
I've created a brand new debian buster VM image and ran the 3.5.2 AppImage. I'm still seeing the font corruption.
In reply to Hi Marc, I've tried the… 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 To be clear - you checked… 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 One other thing to check is… 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:
And here at 55 point:
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:
The result of this experiment leads me to think that the font corruption is algorithmic and correctable.
In reply to You're on the right lines I… 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 You should be using the… 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 Actually, I think it may be… by Marc Sabatella
Agreed. See my follow up at the end of this thread. It's chords only. Can you please save me a little time and point me at the chord symbol rendering code. I'll have a poke at it.
In reply to To be clear - you checked… by Marc Sabatella
> 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?
Confirmed.
In reply to Do you by chance have a… 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 For completeness, I… by Terry Glanfield
Did you remove the MuseJazz font, as it had been (implicitly) mentioned?
In reply to Did you remove the MuseJazz… 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.
In reply to I removed the two versions… by Terry Glanfield
Mss is a musescore style file, not a font.
Look for MuzeJazz*.otf
In reply to Mss is a musescore style… by Jojo-Schmitz
I'm not finding anything even similar to that name on either machine so that's not the issue. Note that the issue is happening with the AppImage as well.
Here's another data point. I'm sure I've not covered all of the text but it appears as though only the chord symbols are affected:
The bug is the same as the old #284218: Broken on-screen rendering of synthetically emboldened fonts
Please see PR https://github.com/musescore/MuseScore/pull/7212 and please test its artifacts.
Edit:
- Windows artifacts: https://github.com/musescore/MuseScore/actions/runs/475791265
- Linux artifacts: https://github.com/musescore/MuseScore/actions/runs/475791268
In reply to The bug is the same as the… by ABL
Sorry, I don't understand your artifacts or what you're asking.
However, I'm now running 3.x and the problem is still apparent there. #284218 fixed most text but not Chord Symbols.
Kind regards,
Terry.
In reply to Sorry, I don't understand… by Terry Glanfield
These 'Artifacts' are (like) development builds, you can download and run them on your PC to test them, they don't replace whatevcer version you do have installed.
@ABL's Pull Request is not (yet) in those 3.x builds, so no wonder that still shows the issue
In reply to These 'Atrifacts' are (like)… by Jojo-Schmitz
Got it. Thank you.
In reply to The bug is the same as the… by ABL
Running with the Linux artifacts, I'm seeing no corruption in the Chord Symbols at any point size.
To confirm, this is using MuseJazz Text with Bold.
Thanks ABL.
In reply to The bug is the same as the… by ABL
Confirmed working in today's 3.x. Thanks Antonio.
In reply to Confirmed working in today's… by Terry Glanfield
You are welcome. Many thanks to you for reporting the bug and testing the builds.
:-)