Switch size changes with staff space settings does not affect styles individually

This is currently by design - these particular styles shared that setting. It wasn't thought there would be any real world use cases where you would need to change this setting for those styles. Can you explain if there is an actual reason you need to be doing this, or if it's just testing things out to see ow things work?

Sorry, I think I misunderstood something in the original report. To be clear: I do agree it's to be expected that header, footer, and title would not scale with spatium, whereas the others would. So it does seem to be a bug that header and foot don't get this turned off. The fatc that the others share settings is more of a don't care for me.

This also affects custom styles (User1, User2, etc), which is particularly important because those are the most likely ones that the user will want to change it for. For example, I create custom styles called "Work Title", "Movement Title" and "Song Number" for OpenScore editions because I don't want to change the default style for "Title".

> The fatc that the others share settings is more of a don't care for me.

There shouldn't be any special behaviour for individual text styles, the option should work the same for all of them.

If the styles are going to share settings then that needs to be via a separate global control because it is extremely unintuitive that enabling/disabling an option for one text style also enables/disables it for the others, and the fact that the behaviour is different depending on which style you edit makes it even worse.

If you do want to try to make the decision for the user, here are the situations where "size changes with staff space" should be enabled or disabled:

Always enabled for:

• All text that is attached to a staff or something inside a staff.
  • Tempo markings, lyrics, chord symbols, staff/system text, etc.
• Text in a horizontal frame that appears to the left or right of a staff.
  • See movement names in this score: https://imslp.org/wiki/File:BWV0825.pdf

Always disabled for:

• All text in vertical frames or text frames.
  • Page headings, dedications, libretto, extended stage directions/scene descriptions
• Text in a horizontal frame that is within a vertical frame.
  • Multi-column text frames (e.g. lyrics verses written out in full at the beginning or end of the score)

Exceptions to the above rules

The only exception I can think of is directions/instructions/annotations that refer to the very start or very end of the piece. These are considered part of the music, so they must scale with spatium, but they are positioned relative to the page, which means using a text frame.

The following examples use text frames with right- or left-aligned text and "size follows spatium" enabled:

Example 1: Initial direction (beginning of 1812 Overture)

(As it happens I ended up using ordinary staff text in the OpenScore Edition rather than a text frame because the text frame would have to be inserted after the final measure in the system, which would cause the frame to be in the wrong place if the music ever needs to reflow (e.g. in the parts). The annotation logically belongs at the beginning of the piece, so what we really need here is an option to display text frames below the system rather than above it.)

Example 2: Final direction (something like this happens at the end of Holst's The Planets)

(The text is left-aligned in OpenScore Edition because I didn't think of right-aligning it until just now ;)

Example 3: THE END

It could be argued that, rather than using text frames, what we really need is some new kinds of staff/system text:

• System text before system
• System text below system
• System text after system

If we had those then it might allow us to get rid of the "scales with spatium" option and rely solely on the rules I outlined above to decide when to scale and when not to.

Fixing this for header, footer, and all user styles is just a matter of adding a few Sids. It would be easy enough to do the same for all other text styles, but perhaps there is some benefit to having this as a shared setting.

If it is going to be a shared setting then it needs to appear elsewhere in the UI. If each text style has its own checkbox, as they do now, then the checkbox must only affect that style, period.

While I appreciate that people are trying to make text styles simpler, we have yet to be shown evidence that a single user has ever been confused by this option. Users that don't need this option simply wont use it, so there is no harm in it being there for all text styles. However, there is harm in treating some styles differently to others without giving any indication of this in the UI.

BTW @mattmcclinch, I notice your commit makes the user styles not follow the spatium by default. I'm not sure that's what is wanted here. We need to be able to turn it off (and this needs to be preserved when the file is saved and loaded) but do we really want the user styles to be spatium-independent by default?

It was off before the addition I think, so should be after, I would guess?

I wasn't sure at first which to use for the default, but now I am thinking it should probably indeed be true, which is the default for Sid::defaultFontSpatiumDependent. As for all of the rest of the text styles, I don't mind giving each of them their own Sid, but I wanted to further the discussion first.

If you want another opinion, each style should have it's own setting and their control should be independent. The default in an empty score should be to turn it on. When importing version 2 scores it should be the same as was in the version 2 score.

I went ahead and added a separate setting for this option for each text style. For default values, I used whatever the default was in MuseScore 2. This means that most text styles are spatium dependent by default. The exceptions are:

Title
Subtitle
Composer
Lyricist
Instrument Name (Part)
Metronome
Translator
Frame
Header
Footer

New user text styles were not spatium dependent by default in MuseScore 2, but it seemed appropriate to make the 6 user text styles in MuseScore 3 default to being spatium dependent. That said, this option is handled correctly when importing styles from MuseScore 2. PR is here: https://github.com/musescore/MuseScore/pull/4528.

@mattmcclinch, thanks very much!

Have you checked that the setting is preserved when a file is saved, closed, and reloaded? I have a sneaking suspicion that the MSCX tag <stylenameFontSpatiumDependent>VALUE</stylenameFontSpatiumDependent> will be ignored when VALUE is 0 rather than 1.

I checked, and the setting is indeed preserved when a file is saved, closed, and reloaded. MSCX tags are only ignored when the value is equal to the default, and the default varies according to the style.

In MuseScore 2, sizeIsSpatiumDependent is only written if it is true, which is why it should be initialized to false in read206.cpp.

Matt - this was the conclusion I came to after looking at #279585: Frame gap wrong in score imported from v2, it should be initialized to false, but then the problem is that user styles share the same Sid for this with all the other text styles. So, if a user text style has the Spatium Dependent flag set to false, then this is set for all text styles that use the Sid::defaultFontSpatiumDependent, which is most of them.

Only just saw your PR, that seems to be exactly the fix I was imagining :)

Fixed in branch master, commit 32a0d0223d

fix #280523: Switch size changes with staff space settings does not affect styles individually

Fixed in branch master, commit 96dfd55c80

Merge pull request #4528 from mattmcclinch/280523-spatium-dependent

fix #280523: Switch size changes with staff space settings does not affect styles individually

Automatically closed -- issue fixed for 2 weeks with no activity.