Allow switching between ordinary and oversized notehead variants

Issue type

Engraving bug (incorrect score rendering)

Description with steps to reproduce

MuseScore fails to honor the explicit stem attachment points defined in the glyphsWithAnchors section of SMuFL metadata JSON files for third-party fonts.
This causes ugly stem alignment issues with specific third-party fonts like MTF-Cadence (where upward stems render shifted towards the center of the notehead).

Steps to Reproduce

Install a third-party SMuFL font.
Open the font's metadata .json file and manually change the glyphsWithAnchors coordinates for noteheadHalf to absurdly extreme values.
Open MuseScore Studio and create a new score.
Go to Format → Style and load the modified SMuFL font.
Input a half note into the score.

Expected behaviour

The stem should be heavily offset and detached from the notehead, following the high coordinate values injected into the JSON.

Actual behaviour

The stem remains locked in its original position.

Supporting files, videos and screenshots

video.mp4

In the attached video, I tested two different fonts. Eugene can be downloaded for free at https://mikkopatama.com/eugenefont/, while MTF-Cadence is a commercial font. Please note that the beam thickness was altered solely to demonstrate that MuseScore is indeed interpreting the font's JSON metadata file but ignoring the stem anchor adjustments.

In which versions of MuseScore Studio is this issue present?

4.6.1 (4.6.0 was not tested) - 4.7.4 and 4.7-/master-nightlies

Regression

I was unable to check

Operating system

Windows 11

Additional context

A similar issue was previously reported in #29734 and closed as completed in #29838, but this bug still exists.

Checklist

This report follows the guidelines for reporting bugs and issues
I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
I have attached all requested files and information to this report
I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

'glyphBBoxes' values seem to be ignored as well, since changes for noteheadHalf have no effect.

Might relate to #29879/#29882

Update: Cause identified

Contrary to my initial assumption, the JSON values for the stem anchors are not being ignored — they are simply being overwritten by the values of the oversized variants.

This behavior stems from the GLYPHS_WITH_ALTERNATES array in engravingfont.cpp. Here, the oversized noteheads are explicitly mapped back to the standard notehead base IDs, which overwrites all previously correctly parsed standard SMuFL metrics.
I suspect this was an intentional design decision! While it works quite well for some fonts (like Bravura), it breaks completely for others (like MTF-Cadence).

I see the following ways to address this issue:

JSON-Tinkering (User): Manually modifying the font's JSON file to delete all oversized variants (fastest, but a bit hacky).
Local fork (User): Modifying the source code to globally remove these substitutions (not ideal, as it affects all scores and all fonts).
Whitelisting (Developer): Extending the source code to determine which fonts should leave standard noteheads untouched (hard to maintain).
Style Setting (Developer): Exposing a style setting (e.g., "Use oversized noteheads"). This option could also be imported via stylesheets: MTF-Cadence is shipped with a dedicated .mss file, allowing designers to package and enforce this preference cleanly (best option imho).

Implement option for oversized noteheads (#34797)

I implemented a checkbox to opt in or out of oversized noteheads and submitted it as a suggestion via Pull Request #34895. Feedback and reviews are very welcome!

Without (naming) a freely available font to reproduce this issue, a fix can't get verfied, MTF-Cadence is not free(ly available)

Yes, that's true. Unfortunately, I'm not (yet) aware of any other font that has such broken rendering in oversized mode as MTF-Cadence.

My approach in this PR was to first allow choosing the notehead mode and disable oversized mode by default (assuming this provides a satisfactory rendering for the majority of fonts). You can test the checkbox functionality with Bravura and for example Eugene (OFL).

If MTF-Cadence is the only font, better report it against that font.

I'm not sure whether I explained this clearly (and if I did, I apologize in advance 😅).
When I first opened this issue, I thought it was a MuseScore bug where certain SMuFL values were simply not being taken into account. I then found out that the actual cause is that MuseScore loads the oversized noteheads and their metrics by default. As a result, the SMuFL values I initially tested are not taken into account because the corresponding oversized variants are used instead.

The override essentially happens through the lines below:

engravingfont.cpp

static const struct GlyphWithAlternates {
    const std::string key;
    const std::string alternateKey;
    const SymId alternateSymId;
} GLYPHS_WITH_ALTERNATES[] = {
…
    { std::string("noteheadBlack"),
      std::string("noteheadBlackOversized"),
      SymId::noteheadBlack
    },
    { std::string("noteheadHalf"),
      std::string("noteheadHalfOversized"),
      SymId::noteheadHalf
    },
    { std::string("noteheadWhole"),
      std::string("noteheadWholeOversized"),
      SymId::noteheadWhole
    },
    { std::string("noteheadDoubleWhole"),
      std::string("noteheadDoubleWholeOversized"),
      SymId::noteheadDoubleWhole
    },
    { std::string("noteheadDoubleWholeSquare"),
      std::string("noteheadDoubleWholeSquareOversized"),
      SymId::noteheadDoubleWholeSquare
    },
…

This was apparently a deliberate decision at some point, because otherwise Bravura looked too thin. Since the other internal fonts don't have oversized variants anyway, it was not a problem. But this means that external fonts which do provide such variants (especially the more elaborate ones) are loaded with those oversized variants exclusively and by default. This also affects the beforementioned Eugene font, for example.
I think that even if the regular glyphs are not going to become the default because of the Bravura rendering, there should at least be a way to choose between the variants. That's what my PR is trying to address.

My hope is that this will make more fonts usable in MuseScore — particularly fonts that provide oversized oversized variants, which would otherwise extend far beyond the staff lines — while also giving users more control over how the font is rendered.

So, what started out as a suspected bug has evolved into more of a feature request / small architectural redesign.

The initial trigger for looking into this was that MTF-Cadence looks particularly bad (because of the shifted stem in the oversized variant). This could be an issue with the font itself or with MuseScore; I wasn't able to determine which. However, this is no longer the main focus of the PR.

Would it make more sense to rename this issue, or should I even open a new one so that the original issue doesn't become confusing?

I tested both noteheadBlackOversized and noteheadHalfOversized in Dorico and Finale v27 using the modified SMuFL JSON anchors, and guess what? The stems are now misaligned in both applications!

Ha! Fix the problem in MuseScore, and you break it in Dorico and Finale v27. You just can't win!

Come on, MuseScore developers! How hard can it be to let users choose between regular and oversized noteheads? Seriously!

MuseScore forces oversized noteheads by default, and their stemUpSE and stemDownNW anchors can produce incorrect stem alignment. Modify those anchors to make MuseScore happy, and suddenly the same noteheads no longer align correctly in Dorico and Finale v27.

So now font developers are supposed to compromise perfectly functional SMuFL metadata just to accommodate MuseScore? Ridiculous!

Give users the choice between regular and oversized noteheads, and fix the stem-alignment behavior properly instead of forcing everyone to rely on application-specific workarounds.

Dorico and Finale handle these fonts correctly with their original metadata. Why can't MuseScore? It's not rocket science, folks!

21. I tested both noteheadBlackOversized and noteheadHalfOversized in Dorico and Finale v27 using the modified SMuFL JSON anchors, and guess what? The stems are now misaligned in both applications!

Which modified SMuFL JSON anchors? As far as I can tell nobody here was mentioned to modify them (other than to reproduce the issue)? Nor does PR #34895 do this?

Which font did you test with?

Hi Jojo,

I think there's an important misunderstanding here. MTF-Cadence is certainly not the only font affected by this issue!

I'm the developer of almost all the third-party SMuFL music fonts distributed through Notation Central, including my NorFonts collections. I've also reviewed and maintained all the MTF and LS Iris fonts, so I've spent considerable time investigating these stem-alignment problems across different notation applications.

Recently, I encountered the same problem with MTF-Gutenberg 1939 in MuseScore 4.6.7. After modifying the stemUpSE and stemDownNW anchors for noteheadBlackOversized and noteheadHalfOversized, the stems finally aligned correctly in MuseScore. Wonderful, right? Well, not quite! When I tested those same modified JSON files in Dorico and Finale v27, the oversized noteheads became misaligned in both applications!

So we fix MuseScore, and suddenly we break Dorico and Finale. How is that a proper solution? ;-)

The real issue is that MuseScore automatically substitutes oversized noteheads for the regular variants, leaving font designers and users with no control over that behavior. This should not be treated simply as a defect in MTF-Cadence or any other individual font.

I strongly support the proposed option to choose between regular and oversized noteheads. A properly structured SMuFL font and its JSON metadata should work consistently across notation applications, without requiring MuseScore-specific modifications that compromise compatibility elsewhere.

As for testing, the proposed switching functionality can already be verified using freely available fonts such as Bravura and Eugene. The fact that MTF-Cadence is commercial shouldn't prevent this broader issue from being addressed.

Best,
—Nordine

I think there's an important misunderstanding here. MTF-Cadence is certainly not the only font affected by this issue!

I didn't say that, at least didn't mean to, but an issue that so far is not reproducible by using free fonts, can't get fixed by any developer not having acces to it.

Recently, I encountered the same problem with MTF-Gutenberg 1939 in MuseScore 4.6.7. After modifying the stemUpSE and stemDownNW anchors for noteheadBlackOversized and noteheadHalfOversized, the stems finally aligned correctly in MuseScore. Wonderful, right? Well, not quite! When I tested those same modified JSON files in Dorico and Finale v27, the oversized noteheads became misaligned in both applications!

Yet another commerial font...

So we fix MuseScore, and suddenly we break Dorico and Finale. How is that a proper solution? ;-)

It isn't, of course

The real issue is that MuseScore automatically substitutes oversized noteheads for the regular variants, leaving font designers and users with no control over that behavior. This should not be treated simply as a defect in MTF-Cadence or any other individual font.
I strongly support the proposed option to choose between regular and oversized noteheads. A properly structured SMuFL font and its JSON metadata should work consistently across notation applications, without requiring MuseScore-specific modifications that compromise compatibility elsewhere.

As for testing, the proposed switching functionality can already be verified using freely available fonts such as Bravura and Eugene. The fact that MTF-Cadence is commercial shouldn't prevent this broader issue from being addressed.

As far as I can tell Bravura doesn't have the issue in the first place, so how could it get used to verify the fix?

You're absolutely right, Joachim! Bravura doesn't reproduce the stem-alignment issue, so it wouldn't help verify a fix for that particular problem. I was referring to testing the option to switch between regular and oversized noteheads in PR #34895, which is a separate matter. For the actual stem-alignment issue, I understand that developers need a freely available font to reproduce it.

—Nordine

Thanks to both of you for looking into this. I'm the publisher of the MTF (Music Type Foundry) and LS Iris fonts at Notation Central, including MTF-Cadence.

You were right that the misplaced stems were on our side. In our metadata, the noteheadBlackOversized and noteheadHalfOversized anchors had been copied from Bravura (stemUpSE [1.316, 0.188]) rather than measured from our own glyphs. Because MuseScore substitutes the oversized variants and uses their anchors, this affected MTF-Cadence and several other MTF and LS Iris fonts. We corrected the anchors and released updated metadata today, November 6, 2026. With the corrected files, MuseScore Studio 4.7.6 places the stems correctly.

What remains is the question this issue now asks. For our fonts, the oversized noteheads are separate designs (in MTF-Cadence they're about 12% wider than the regular ones), and MuseScore users currently have no way to choose the regular noteheads. We'd welcome #34895, and its default of using oversized noteheads only for Bravura looks right to us.

Implement option for oversized noteheads (musescore#34797)

Thanks to both of you for looking into this. I'm the publisher of the MTF (Music Type Foundry) and LS Iris fonts at Notation Central, including MTF-Cadence.

You were right that the misplaced stems were on our side. In our metadata, the noteheadBlackOversized and noteheadHalfOversized anchors had been copied from Bravura (stemUpSE [1.316, 0.188]) rather than measured from our own glyphs. Because MuseScore substitutes the oversized variants and uses their anchors, this affected MTF-Cadence and several other MTF and LS Iris fonts. We corrected the anchors and released updated metadata today, November 6, 2026. With the corrected files, MuseScore Studio 4.7.6 places the stems correctly.

What remains is the question this issue now asks. For our fonts, the oversized noteheads are separate designs (in MTF-Cadence they're about 12% wider than the regular ones), and MuseScore users currently have no way to choose the regular noteheads. We'd welcome #34895, and its default of using oversized noteheads only for Bravura looks right to us.

Thank you very much!! I tried the new version 3.113 of MTF-Cadence right away and can confirm that everything works as expected. With this, the only remaining points for this issue and my corresponding PR are the availability of the option to choose between regular and oversized noteheads, as well as the default value.

Navigation Menu

Repository navigation

Allow switching between ordinary and oversized notehead variants #34797

Issue type

Description with steps to reproduce

Steps to Reproduce

Expected behaviour

Actual behaviour

Supporting files, videos and screenshots

In which versions of MuseScore Studio is this issue present?

Regression

Operating system

Additional context

Checklist

Update: Cause identified

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow switching between ordinary and oversized notehead variants #34797

Description

Issue type

Description with steps to reproduce

Steps to Reproduce

Expected behaviour

Actual behaviour

Supporting files, videos and screenshots

In which versions of MuseScore Studio is this issue present?

Regression

Operating system

Additional context

Checklist

Activity

MichaelGerecke commented on Sep 3, 2026

Jojo-Schmitz commented on Sep 3, 2026

MichaelGerecke commented on Sep 8, 2026

Update: Cause identified

MichaelGerecke commented on Sep 11, 2026

Jojo-Schmitz commented on Sep 11, 2026

MichaelGerecke commented on Sep 12, 2026

Jojo-Schmitz commented on Sep 12, 2026

MichaelGerecke commented on Sep 12, 2026

NorFonts commented on Nov 5, 2026

Jojo-Schmitz commented on Nov 5, 2026

NorFonts commented on Nov 5, 2026

Jojo-Schmitz commented on Nov 5, 2026

NorFonts commented on Nov 5, 2026

nycmusic commented on Nov 6, 2026

MichaelGerecke commented on Nov 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions