Text styles: the displayed font-size in the Inspector does not match the actual value
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S3 - Major
Status
closed
Regression
No
Workaround
No
Project
Win 10 / MS 3.0.0, f8bb446
See attached file, which formats correctly in MS 2. Nominally, the font-size for "Subtitle", "Composer", and "Lyricist" text has not changed from MS 2. However you can see that the same text elements in the nightly are being displayed at a larger font-size than that displayed in the Inspector.
There are two issues: (1) The font-size of text items has unexpectedly increased in the nightly (compared to MS 2). (2) The displayed font-size is incorrect.
| Attachment | Size |
|---|---|
| text_styles_lost.mscz | 26.67 KB |
Comments
I don't see this for Title, Subtitle or Composer, only for Lyricist, which had a non-standard size and font in 2.x already (13.2pt and Time New Roman)
I've reset the Lyricist style (see attached score), but the issue is as before: (1) The on-screen font-size has increased for "Subtitle", "Composer", and "Lyricist." (2) The Inspector is displaying the correct font-size values but this does not match the on-screen sizes.
P.S. The styles in question were customised in MS 2. But, MS 3.0-dev seems to be resetting the font-sizes to the default values.
OK, confirmed:
![2.png]( "2.png")
![3.png]( "3.png")
Also the just recently fixed offset of Subtitle (#277369: Title and Subtitle superimpose one another, abc08ac) looks wrong (but different than before that fix)
The flag "font size follows spatium changes" is not imported right and set to true for title, subtitle etc. This might explain the wrong size. Also the text offset is interpreted as mm if the flag is false and spatium if true.
fixed with a31736d (unless I read that commit wrongly)
The flag is fixed in a31736d7b.
Win 10 / 3.0.0, 77b832b
Subtitle and Composer are OK. But "Lyricist", although it shows the correct font-size in the Inspector (and the text toolbar), is still showing on-screen with a larger font (probably 13pt?) in MS 3.0-dev.
P.S. Is this issue connected? #277639: Frames are not read correctly 2.x->3.0.
As far as I understand inspector doesn't show any font size anymore, does it?
And font sizes are equal for me in 2.3.2 and 972e2ae.
for some text it doesn't (title/subtitle/lricist/composer/lyrics) any longer, for others it does (rehearsal marks), and there indeed still is a mismatch:
![sample.png]( "sample.png")
Both at 14pt as per text edit bar (and for the rehearsal mark as per Inspector too)
It seems that text size in inspector does nothing if some text size was set for the given element in text editing mode. And it is even logical given that one can set different font sizes for different parts of one text line.
Concerning mismatch, how to reproduce it? For me equal font sizes are displayed pixel-by-pixel equally in 2.3.2 and current master.
@geetar could you please check the scenario again and let us know whether it is fixed or not.
I can tell you it's not fixed. If you enter text, put it into edit mode and use ctrl+a to select all of the text and change the font, size using the text toolbar at the bottom of the screen does not change the inspector. The text tool bar allows you to mix text styles, which is often useful. I can understand if only a part of the text is changed that the styles remain shown in the inspector, but if you use ctrl+a to select the entire text item, the inspector should update and give you the option to revert to the default style by making the circular arrows black.
@mike320 thank you for the follow up.
@Jojo-Schmitz Does launching MuseScore with these parameters help to avoid displayed font sizes mismatch? There seem to be some Qt-related issues with fonts rendering on Windows.
mike320, unless I am missing something (which is always possible), I think what you are describing is something entirely different from what is being discussed here. Feel free to file a separate issue for what you are talking about. To me, it's a Suggestion - a suggestion that we treat custom formatting added by the toolbar differently depending on whether the user does Ctrl+A first or not. Custom formatting is different from a property applied to the text element as a whole. The former is removed via Remove Custom Formatting, the latter via the individual reset buttons in the Inspector. This is just as it was in 2.x as well, except of course you needed to use Text Properties instead of the Inspector to apply properties to the text element as a whole. But again, as a suggestion for a future feature, I could see us doing some magic behind the scenes to treat custom formatting applied via Ctrl+A as if it were an actual text property. Wouldn't work for subscript or superscript, of course, since those aren't even available as text properties.
In reply to mike320, unless I am missing… by Marc Sabatella
I was looking at Jojo's "Swing low" example and the contradiction between the inspector and tool bar. I realize that text issues are complex due to the many ways to adjust them. It seems very illogical to me to see a 14 point times new roman font displayed on scree and the inspector calls it a 10 point freeserif.
@dmitrio95 no, but I now see that the difference between the texts I compare /Subtitle and Reherasal mark, both shown as 14pr, in Inspector and the text edit toolbar) have different settings for "Sizes follows staff space settings" and making those the same results in same size text, as does reseting that score to the default staff space of 1.764mm. So I don't see the issue anymore (or rather have a valid explanation for it)
Automatically closed -- issue fixed for 2 weeks with no activity.