I can reproduce this too (Windows 7), and it has nothing to do with lyrics or turning off the scaling option specifically. My steps to reproduce are quite simple:
1) click anywhere in Promenade example
2) Ctrl+T
3) Type any two lines of text
I get way too much vertical space, just as shown in the examples above. This applies to any multi-line text anywhere, any text style, any font.
I won't have the opportunity to check into this further until next week, but I'm happy to try debugging. Any clues as to where I might set some breakpoints?
I don't see anything either (Win8 64bit, git 2a8e234). I've tried with Promenade, a new score, playing with the Text properties controls, staff text, lyrics...
you probably want to debug this section https://github.com/musescore/MuseScore/blob/master/libmscore/simpletext…
and print the value of lh, the line height. Problem is that this line height is given by Qt and QFontMetricF and I guess that it will be different on your system and mine... I hope I'm wrong...
Finally able to take a look. After the call to lineheight(), lh = 16 for staff text in a newly created score on my system. Yet the vertical spacing is definitely way too much. Will try to investigate further later.
Nice! I wonder, was this fix a convenient side effect of the change from physical to logical DPI, or was the cause of this discovered and fixed separately? I had investigated a bit and gotten nowhere, but it was on my list to revisit this weekend. It had occurred to me, however, that these could be related - the line spacing could reflecting a different DPI than the text itself.
Comments
I cannot reproduce this on linux.
I can't reproduce on windows either. Windows 8 5d605294b3 Do you have any more details?
No specific details. I'm using the default font and have not made any changes to the text style.
See #22112: Font of instrument name larger than nominal
I can reproduce:-
Latest build based on commit 62803b8
OS Windows 8 Pro
I assume it is connected to the fontscaling problem I reported in #22323: Font scaling is incorrect when not using "size follows space unit"
I can reproduce this too (Windows 7), and it has nothing to do with lyrics or turning off the scaling option specifically. My steps to reproduce are quite simple:
1) click anywhere in Promenade example
2) Ctrl+T
3) Type any two lines of text
I get way too much vertical space, just as shown in the examples above. This applies to any multi-line text anywhere, any text style, any font.
And I still can't reproduce http://www.screenr.com/vYlH
so what's different?
I won't have the opportunity to check into this further until next week, but I'm happy to try debugging. Any clues as to where I might set some breakpoints?
I don't see anything either (Win8 64bit, git 2a8e234). I've tried with Promenade, a new score, playing with the Text properties controls, staff text, lyrics...
you probably want to debug this section https://github.com/musescore/MuseScore/blob/master/libmscore/simpletext…
and print the value of lh, the line height. Problem is that this line height is given by Qt and QFontMetricF and I guess that it will be different on your system and mine... I hope I'm wrong...
For a staff text, lh = 20 on my system...
Finally able to take a look. After the call to lineheight(), lh = 16 for staff text in a newly created score on my system. Yet the vertical spacing is definitely way too much. Will try to investigate further later.
Problem is that this line height is given by Qt and QFontMetricF
This makes me very suspicious that it is a QT bug.
The fact that this appeared immediately after the change to QT 5 makes me even more so.
This seems to have been fixed with the latest nightly 3045e9c. Thanks!
I'm using Windows 7.
Nice! I wonder, was this fix a convenient side effect of the change from physical to logical DPI, or was the cause of this discovered and fixed separately? I had investigated a bit and gotten nowhere, but it was on my list to revisit this weekend. It had occurred to me, however, that these could be related - the line spacing could reflecting a different DPI than the text itself.
it is my understanding that is is indeed related to that DPI issue
Automatically closed -- issue fixed for 2 weeks with no activity.