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

• Dec 23, 2018 - 12:32
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

The switch "size changes with staff space settings" toggles a number of text styles simultanously.
If you change the setting for header than size of footer, lyrics, tempo and others change at tha same time.
Same happens for lyrics, footer, .. I did not try all of them.

The tilte text styles like title, subtitle, composes and lyricist seem to work as they should.


Comments

Severity S3 - Major S4 - Minor
Status active needs info

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?

I think there is a legitimate cause that header and footer don't automatically scale in the same manner as the musical part of the score.
a) This would be a change to Musescore 2 where header and footer don't scale with the staff space setting.
b) Header and footer in my perception are part of the frame around musical score together with item like title, subtile, composer... and shouldn't scale automatically together with the staff size.
I have a collection of more the 100 vocal score for two choirs and was very surprised when suddenly the footer with page numbers copyright, ... changed size from score to score. I don't think that look very aesthetic in a collection of scores and there is no workaround.

For all the text styles that are part of the staff content (lyrics, dynamics, tempo, ...) it might be resonable to have a common setting.

This should be visible somehow in the UI. In the current version, all text styles have the identical menu and it it not clear for the user, which styles have their individual switch for scaling and which ones share this with a larger group. I am afraid this would lead to some confusion and lot of unnecessary "Bug reports".

Addendum: I had a closer look at Musescore 2.0 behavior, It looks like all text styles have their individual switch. Even though I don't see a use case to set this individually for the text styles insides the staff (see previous comment) changing the behavior should have a clear benefit because the tradeof will be a messing up some MUS 2.0 scores which are uploaded to MUS 3.0 if they made use of this behavior for whatever good or odd case.

Priority P0 - Critical

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.

Thanks for the confirmation concerning header and footer.
I agree that for the other text-styles this is not important.

I strongly feel that this behavior needs to be reflected in the UI better than in the current version and remind that this is a change of the behavior to Musescore 2.0. Even though the feature is not important a feature change without a clear use-case is always problematic.

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.

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)

instrumentation_note.png

(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 ;)

final_repeat.png

Example 3: THE END

the_end.png

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?

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.

Status active PR created

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 :)

Fix version
3.0.1