Format / Style / Text Styles showing incorrect size values for some styles

• Feb 17, 2019 - 01:11
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project

Version: 3.0.2

Some styles behave weird. When I go to Format → Style, select Text Styles, I end up with Title preselected at Gentium 24 pt (in my style). Then I go to Volta, and I still see Gentium 24 pt. It saves as Free Serif 8 pt though. If I change the size, it sometimes(?) seems to stick. I haven’t exactly figured out what all is wrong and what all works, and what all styles are affected.

Editing the .mss fixes this, though, which is what I did.


Comments

Are you saying Gentium 24 pt is not correct for Title in your score? Or it is correct for Title but not for Volta? Can you attach a score and precise steps to reproduce a problem?

In reply to by Marc Sabatella

It’s correct for Title, but not for Volta. I changed the font but kept the sizes (mostly, but in all the styles relevant for this issue, I did).

The problem is basically that, when you switch from a “working” style (such as Title) to a “non-working” one (such as Volta), some things from the previous style are kept.

Priority P0 - Critical

OK, I see what you mean. From Format / Style / Text Styles, first click Title, then click Volta - the text size info does not change as it should. This is true for most of the text styles from TextLine down to Hairpin. The other fields do seem to update, just not the size.

Probably a question of some styles inheriting the overall text default.

The problem is that the font settings for the lines (voltas etc) are handled a bit differently as there are no actual text elements using these styles - instead, line text settings control text within the lines (potentially different texts for begin, continue, and end). It's that handling that is a bit off in this dialog. But the issue as far as I can tell is only with what is displayed on screen, the actual behavior seems correct if you try editing the style - it correctly (?) sets the BEGIN text style.

I think the simple fix is to handle Pid::BEGIN_FONT_* properties in the switch statement in EditStyle::textStyleChanged(), perhaps just doubling up on the handling of the corresponding "regular" properties (eg, combine handling BEGIN_FONT_FACE and FONT_FACE). But, smarter might be to actually set all three style variants (begin, continue, and end) when making a change here? Or not. Right now, I think the only way to control the continue and end styles is via the set as style buttons in the Inspector?

In reply to by Marc Sabatella

Running MuseScore 3, OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.5.5992, revision: 58dd23d.

I can confirm the dialog box doesn't save any modifications made to the Volta style (at Format, Style, Text Styles).

Worse, even if we don't edit it, when we do a second export for a style.mss file, the Volta style is changed on the exported file: On a new score, export the style to a style.mss file, check there is no VoltaAlign tag, import the file, export it again, check that now there is a voltaAlign tag with a value left,top that can only be edited by hand on the style.mss file, as the dialog box doesn't work.

One thing is that it also doesn't handle Pid::OFFSET. It makes sense that FONT_FACE, FONT_STYLE, FONT_ALIGN, and FONT_SIZE, but the OFFSET part is a little bit more difficult to understand. I looked into it a bit more and it seems like there's a ton of inconsistencies with those. Most text elements have Pid::OFFSET assigned to the actual offset like it should be, but these elements don't even have an assigned style for OFFSET. This is fine in practice since it's already handled as an inherited property from Element, but it means that the UI stuff fail since they use element styles to fill in the fields. At this point, I'm not super sure what's a good way to go about this. I'm thinking, though, that maybe properties inherited from Element.cpp should be set outside of the switch (Offset and Color). For the rest of the elements, I think we should set all three for the time being and just load begin text. From the user perspective, I'd think that would be the expected behavior for me.

Oops, nevermind. For some reason my mind skipped past the idea that this was for text styles. There's no need to worry about the offset and color of the Volta itself since we're only worried about the text of the Volta.

I got a working solution, but it's all pretty hacky right now. I think there's fundamentally a bit of an issue with everything and it's hard to fit this in cleanly. There are definitely some clean "solutions" that fix this issue, but that creates other issues since there are some consistencies all around the code that have quite a bit of code to make everything fit. I'm not really knowledgeable enough of all the other parts of the code to clean up the inconsistencies though. I thought about pushing my changes, but it a lot of code to just do a little bit and I'm a bit reluctant to add on to the issues.

Severity S4 - Minor S3 - Major

I'm running MuseScore3 Ver. 3.2.2.2288 Rev c893c61 on an iMac OS High Sierra v 10.13.6. I try to edit the text size for footnotes and the edits do not change the font size in the document. When I accidentally clicked the ^ arrow next to the text size more that once it highlighted the number in the box and started increasing it uncontrollably. (i.e. it got stuck in a loop with no end). To stop it I had to cancel the window. I was able to cause this to happen again when I again tried to increase font size.

Can you attach the score you are having trouble with? Increasing footer sizer works fine for me. You are using Format / Style / Text Styles / Footer?

Marc,
Yes I was using the format/style/text styles/footer. I relaunched and this time the changes worked, as long as I type in the font size. but if I try to use the up arrows on the text size box it still starts increasing the size until it maxes out at 99.99.
It wasn't a particular score, it happened to two different scores I was working with but i'm attaching the score that now seems to work, sort of.