Custom alignment of text in lines is being lost
Reported version
3.0
Type
Functional
Severity
S3 - Major
Status
closed
Regression
No
Workaround
Yes
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 26ad655
See attached score. The line is in measure 5.
- In MS 2.3, the guitar barre line in measure 5 was applied from a custom palette (workspace attached below). It looks like this:
- However, when the score is opened in MS 3.0.0, the same line looks like this:
It appears that the program is not honouring the original customised alignment of the text in the line. In MS 2.3 this is shown as "Align right edge etc." in the line's text properties. In MS 3.0.0 this has been reset to "Align left edge etc."
P.S. This problem has also appeared in previous versions of MuseEdit.
Attachment | Size |
---|---|
marble_halls.mscz | 35 KB |
my_workspace.workspace | 5.71 KB |
Comments
I'm taking a look at this
Fixed, PR: https://github.com/musescore/MuseScore/pull/3985
It doesn't look like much - one line needed to be changed - but it took bloody ages to trace it back through the code. Thanks for reporting it.
This bug may be related. See attached score.
Expected result: No change.
Actual result: The text-line has returned to left-aligned again!
In reply to This bug may be related. See… by geetar
Yes, I'd say it's likely that that bug is related. I'll create a separate issue for it, and I'll take a look at fixing it? Thanks.
New issue: #276587: Style lost for default alignment of TextLines
Del.
Fixed in branch master, commit 8a247995b8
fix #276423: custom alignment of textline lost
Fixed in branch master, commit 59594beec6
Merge pull request #3985 from jthistle/276423-custom-alignment-of-textline-lost
fix #276423: custom alignment of textline lost
Automatically closed -- issue fixed for 2 weeks with no activity.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4095, revision: 5859662
The appearance of the text lines is still wrong—there is now a large gap between the end of the text and the line:
In 3.0-dev:
In 2.x:
This text-alignment needs to be set to LEFT in the Inspector (3.0-dev) to correct the appearance. But the same-looking line in 2.x has a RIGHT text alignment.
In reply to Unfortunately this hasn't… by geetar
Is this for a right aligned textline? If it is, isn't that expected behaviour, and also the same as it was in MS2? I thought right aligned textline were meant to have a gap there...
I've just edited the previous text. Does this answer your question?
I think so, you're saying that for a right aligned text line in MS2 there is no large gap between the text and line?
Just to reiterate. To get this line in 2.x, you have to set the text-alignment to RIGHT:
But to get the same-looking line in 3.0-dev you have to set the text-alignment to LEFT.
Further investigation needed?
P.S. The attached score may be useful.
You'll notice that in MS2, if you set the alignment of one of the textlines in the attached score to 'left' instead of 'right', there is an overlap between the text and the line. Because of this, I think that MS2's behaviour is buggy and incorrect, and MS3's behaviour is correct and expected. So, to fix this, should we set any right aligned textlines to be left aligned when reading a 2.x score? Or should we just leave things as they are, and accept a difference in appearence? MS3 doesn't always aim to lay things out exactly the same as in MS2 - if something can be laid out better, that is the goal.
TheOtherJThistle wrote, "So, to fix this, should we set any right aligned textlines to be left aligned when reading a 2.x score?"
On second thoughts, this seems like the best option.
Del.
In reply to There's something else going… by geetar
Sorry, I've seen you do this before - what do you mean by 'Del.'?
"Delete". As you can't delete a comment, and not empty it either
Do the following observations shed any more light on the issue?
Result: The text-line retains its correct left-alignment.
Result: The alignment changes unexpectedly to right-aligned.
Just to summarise. This fix is needed to maintain the correct horizontal alignment of text lines in imported 2.x files.
Automatically closed -- issue fixed for 2 weeks with no activity.