lyrics align is wrong on lyrics containing numbers and space
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
Lyrics with lyrics dash or melisma are getting left aligned to the notehead's left border.
Licurs with a (stanza) number (e.g. "1. While") are supposed to get left alinged so the 1st 'real' lyrics character is left aligned to the left border of the note head and are in 2.x
In 3.0 however they seem to align to that space, so are off by some 0.5sp
Workaround is to tweak the x-offset in Inspector. That does only work for odd lyrics though, see #279774: x-offsets applied to even lyrics lines don't stick (don't survice save/close/open)
Attachment | Size |
---|---|
lyricvs-align.mscz | 3.27 KB |
Fix version
3.2.0
Comments
But MuseScore 2.3.2 seems to do the same. Here is the screenshot:
Space bar seems to be not so wide but otherwise the result looks similar.
the difference is subtle, in 2.3.2 the left edge of the 1st letter after the space seems aligned to the left edge of the notehead, in 3.0 the left edge of the 1st letter after the space seems aligned to the center of the note head.
So a 0.5sp difference.
Not the case with melisma and lyrics dash, there it is left aligned, just like it should.
Possibly that this is due to a wider space.
Another screenshot from 2.3.2 containing the dash:
Wider space looks like the only difference.
Not for me, 2.3.2:
Freetype difference on Windows? Similar to the underline issue?
Subtle but present. I suspect most people will live with it, but we do want to correct this soon to avoid people making manual adjustments that need to be revisited later.
Eventually I found that lyrics layout indeed does an attempt to adjust lyrics position according to the leading part width. However this width seems to be calculated not accurately as the calculation does not consider that the width of the given chunk of text may depend on which characters are placed next to the given part of the text line. At least whitespace seems to be wider when being in the middle of the line rather than in the end of the line. I tried to correct these calculations (this commit) and got something like this:
However this will probably work only for the case if font does not change during the lyrics syllable. This makes this issue somewhat related to #279376: Inconsistent underlining of tempo text: we seem to need a way to correctly calculate dimensions of any parts of text elements based on
TextBase
in order to be able to align them all correctly.The original code to calculate the amount of "leading" space was kind of a hack, a compromise based on a series of discussions about what should be ignored and what shouldn't. Meanwhile, the treatment of verse numbers themselves also changed a couple of times - they were separate elements for a while, etc. Eventually we should probably really revisit this whole algorithm.
came up again in https://musescore.org/de/node/290358
Compare 2.3.2:
with 3.1:
created with the attached sample score snippet. IMHO pretty clearly MuseScore 2 looks better here, an X offset of -0.3sp for the lyrics syllable seems to be needed in MuseScore to get the same layout.
How about this?
With that the above example looks the same as it did MuseScore 2.
Looks good even after looking at many of my scores.
See https://github.com/musescore/MuseScore/pull/5107
I haven't gone through in detail, but that indeed looks like the right sort of adjustment to make, so if it works I'd say you got it! Did you try both melisma and non-melisma syllables, to catch both the left & center cases?
Erhm... let me check again with melisma ;-)
Yes, looks OK with that too:
Fixed in branch master, commit e129be0137
_fix #279770: fix aligning of lyrics with leading/trailing numbers
The previously used method did not take into account the fact that
width of some characters (e.g. whitespaces) may vary depending on
the surrounding context. This commit corrects leading/trailing parts
widths calculation by making use of TextBlock::xpos() function which
is used also for text cursor placement in text editing mode._
Automatically closed -- issue fixed for 2 weeks with no activity.