Changing any property on a text line resets all styled properties to default
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
Make score, add text line, add some text to that line, and play around with resizing the text along with offsetting it.
I specifically am working with "above" instead of "auto" for its alignment. For example:
This behavior makes MS seem kind of crazy :)
Fix version
3.6.0
Comments
Update: The font face is also being reverted here after attempting to change font names and then offsets. With that in mind, this seems a little more than minor so I'll switch it to major, especially since 3.x series deserves better before it's finalized.
Update: for those who may benefit from having more precise steps:
1) Create New Score in recent 3.6.x branch. I'm doing this in a Nightly again as of today (2021.01.13)
2) Create a text-line
3) Edit the text and change the font to something besides Edwin: here I'll use FreeSerif. Saving the score, this is the status of the included file .mscz file.
4) Click the text line
5) Edit the text to be something different (press 'A' for example)
or 5) press "B"old button
or 5) increase/decease X Offset
Result: Doing any of those things, the font face of the text-line reverts to Edwin. To make matters worse, undoing doesn't bring it back to FreeSerif. When the font-face first reverts, it seems that the font-name in the inspector doesn't get updated until clicking the line again, so it can be slightly confusing depending upon to what the user is paying attention.
Verified that this doesn't happen in 3.5.2. Obviously it can't since Edwin isn't involved with it, but I mean to say that changing from FreeSans and then doing the 4th/5ths steps will not revert to what the text was previously (FreeSerif by default). In that sense, I'll mark this as a regression.
Here's another demonstration:
I can confirm, editing the text etc resets the font. Workaround is to change it back. Only seems to apply to text lines that have their font set to something other than the style default.
Title updated to reflect a better understanding of the issue. It isn't just about font. You can see the same if you change another styled property - like flipping placement below - then change some other property, like end hook height. The placement will be reset to above. That's because of a call to initStyle() within TextLine::undoChangeProperty() that was added as part of the system line support.
Luckily, it only applies to actual text lines, not (as far as I can tell), for other classes derived from TextLineBase such as pedal, ottava, volta, etc. But it does mean you can actually only change one styled property of textlines away from the style default.
In reply to Title updated to reflect a… by Marc Sabatella
If you are limited to change only one property how can you say that there is a workaround ?
Fixed in branch 3.x, commit 6d1f1e57c9
_Fix #314828 Changing any property on a text line resets all styled properties to default
Remove unnecessary initStyle from TextLine::undoChangeProperty()._
Fixed in branch 3.6, commit 8f99c44cc7
_Fix #314828 Changing any property on a text line resets all styled properties to default
Remove unnecessary initStyle from TextLine::undoChangeProperty()._
Doesn't matter any more of course, but for the record, I mentioned the workaround before realizing the issue affected all styled properties. I probably should have unchecked the workaround flag at that point. But it's also worth nothing, only styled properties were affected - in the builds with the issue, you could change as many unstyled properties as you wanted with no problem. In any case, again, should be moot now.
Automatically closed -- issue fixed for 2 weeks with no activity.