Wrong offset used for text elements with non-default text styles

• Feb 17, 2020 - 20:17
Reported version
3.4
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

See https://musescore.org/en/node/301214 for a forum report that finally helps me clarify some things have long bothered me. There are a few different aspects to this I have discovered, but they all have the same root cause: confusion over which style setting to use for the offset on text elements where the user has overridden the default text style. For example, consider a staff text that has been set explicitly to use the "Chord Symbol (Alternate)" text style.

Case A - offset reverts to original style on reload
1) add a staff text
2) set it to chord symbol (alternate) text style (thus raising it higher above staff)
3) save score
2) close
3) reopen
Result: offset has reverted to the staff text default

Case B - offset reverts to original style after any style change
1) add a staff text
2) set it to chord symbol (alternate) text style
3) change font
4) set as style
Result: offset reverts to the staff text default

Case C - "set as style" affects wrong style
1) add a staff text
2) add another
3) for one of them, set it to chord symbol (alternate) text style
4) manually change the offset to move it further from staff
5) set as style
Result: the other staff text moves to the new position even though it has the default staff text style

Case "A" I feel I might have broken at 3.1 https://github.com/musescore/MuseScore/pull/4827 although I'm not positive. "B" I stumbled on in investigating this. "C" is the one I've known about the longest, and I sort of accepted that is just how it is, but I now realize it isn't supposed to be. And in fact, it isn't that way except for those text element types that have separate above & below offset style settings.

Cause is clear, fix is simple but will require review and testing. PR forthcoming.

Comments

• Feb 18, 2020 - 20:19

I have also seen Case C, but found it difficult to pin down a series of steps to repeat. I assumed the three cases were all interlinked to the same root cause so I will wait for the fix before reporting any more. I notice that you are using staff text when I was using system text, but I assume the same issue affects both.

Reply

• Feb 18, 2020 - 20:28

The issue affects all text elements that support separate above/below placement settings for their offsets. This includes staff & system text, also dynamics, tempo, rehearsal marks, and sticking. Also lyrics although a bit differently since lyrics have automatic alignment going on also.

Root cause in all of these cases is that there is code to apply the proper offset according to whether the text is above or below the staff, but the code doing that wasn't checking to see if you had overridden the text style. So it was applying staff text above or staff text below for all staff text even if it was set to use a user style. Fix is to just add that check, so we actually use the user style offset.

Reply

• Apr 28, 2020 - 12:51
Status PR created ⇒ fixed

Fixed in branch master, commit a780a36dea

_fix #301259

Resolves: https://musescore.org/en/node/301259

See also https://github.com/musescore/MuseScore/pull/5728/

The problem occurs in several different overrides to
getPropertyStyle() for various different text classes.
The function is supposed to determine
which Sid to use for Pid::OFFSET, based on placement above/below.
But that calculation should only be relevant
if the element is using the default text style for its type.
Otherwise it should use the offset in the current text style.

This code removes the overrides for getPropertyStyle() in each class,
instead modifying TextBase::getPropertyStyle() to check
if the element is using its default text style or not,
and then only if so does it use the placement to select a Sid.
Otherwise it uses the offset of the current text style._

Reply

Fix version
3.5.0