[MU4 Issue] Custom formatting of text objects lost in copy and paste operations

[rgreen5]

Describe the bug

When a text object is copied and pasted, and it contains a SPACE with a custom font-size, the space disappears! Same thing happens if you save and reopen the file without copying the object

To Reproduce

1. Open a score
2. Click on a note say, then press Ctrl + T to add staff text.
3. Enter the characters "Greater than", SPACE, "Less than" (i.e. "< >")
4. Copy the text object to another fretmark, say. RESULT: All font properties are preserved as expected.
5. Select the space in the text object and increase its font-size to 30, say. Then copy the object again. RESULT: The space has disappeared.

Expected behavior

All font-properties, whether object-level or character-level, should be preserved during cut/copy/paste operations (and any other operations such as saving to a palette, or saving the file).

Platform information OS: Linux Mint 20.1, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-2829968415, revision: github-musescore-musescore-2d21253

[rgreen5]

Additional issue There is also an allied problem with lost formatting when copying text objects in imported MS3 files.

1. Open the attached MS3 file in MS4. harmonics.zip
2. Copy and paste a harmonic symbol (not the fretmark) from one of the existing fretmarks in measure 1 onto a corresponding fretmark in measure 2. RESULT: Custom formatting is lost during the operation and the harmonic symbol no longer fits the fretmark.

Expected result

All style and character formatting should be preserved during operations.

[its-not-nice]

Something else I have found triggers a reset of custom formatting: resetting (unrelated) styles to default. See video. I have, however, not been able to reproduce this consistently.

https://user-images.githubusercontent.com/20604032/190986882-ef84a406-ccc7-41f6-8143-d4c8c1482fbf.mp4

[bkunda]

I can add to this issue that custom offsets for page numbers are reset to 0 when a file is closed and re-opened. (Obviously not a copy-paste operation, but possibly related to a potentially broader problem of customisations being lost in particular circumstances).

[MarcSabatella]

Actually, unless something has changed since MU3, it's not meant to be possible to directly modify any properties of page numbers at all, since page numbers aren't saved with the score - they are generated on the fly during layout. I can see that the MU4 inspector shows you properties, but unless there was also code added to handle how the modified page number would be saved, it's not surprising it wouldn't work. Probably best to just disable the Properties for page numbers unless it really is meant to be supported and there's just a bug preventing it from working as intended.

[bkunda]

You're right @MarcSabatella. Indeed, page numbers in MS4 should not be modifiable from the properties panel at all. In terms of our release timeline, we are unfortunately well past the point of implementing an elegant solution to this now (i.e. making the properties panel show something sensible when a page number is selected), so I think the most straightforward solution in the immediate-short term is to make sure they are not selectable in the first place. I'll raise this as a separate issue.

[MarcSabatella]

Agreed. For most of MuseScore's existence, page numbers were not selectable, and there's nothing at all you can do with them once selected (at least in MuseScore 3), so no great loss. I believe the only reason they end up being selectable at all is that code was added for one of the relatively recent 3.x releases to allow you to double-click the page number (or anything else in the header) to jump directly to the header style setting.

BTW, the one thing I notice you can attempt to do with a page number after selecting it in MuseScore 3 is press "V" to make it invisible. Which then has the same issue as here - it looks like it worked (once you deselect it anyhow), but that's lost on save/reload, because page numbers aren't actually saved at all.

[cbjeukendrup]

It looks like this issue got even worse recently: now any kind of formatting is lost on copy paste. This seems to be caused by the styleChanged call that @mike-spa added in Score::undoAddElement.

So I've researched this a bit and found that there are two problems here:

• styleChanged() erases all formatting (this is why currently all formatting is lost, and probably also the cause of the variant that Simon found)
• There is a bug inside XmlReader::readXml() which causes that the space character is lost, as mentioned in the original issue. This seems not to be caused by XmlReader::readXml() itself, because the space character is not seen in that method, so it must be lost deeper inside XmlStreamReader. (Also, note that the space character is not only lost when copy-pasting, but also when saving+reopening.)

To solve problem 1, we need a way to determine when to reset the formatting and when not. In MuseScore 3, it seems like things work completely differently, namely formatting can be set in multiple ways: (1) in the Inspector, there is a "base formatting" that applies to the whole text object until the character where you have applied special formatting; (2) you can also override the formatting per character. The relation between these two is not entirely clear to me; it seems that when the "base formatting" is unmodified (i.e. bound to the style value) and you have never made any per-character changes, only then the formatting will be reset when the style changes. That doesn't hold in all cases though... Anyway, that was better than what MS4 does now, so I'll attempt to bring back that behaviour to some extent.

To solve problem 2, we need to dive deep into XmlStreamReader. I believe that's mainly @igorkorsukov's area...

[mike-spa]

What surprises me is that styleChanged() only acts on STYLED properties, i.e. properties which follow the score general style. Normally, when an item is customized, the connected property becomes marked as UNSTYLED so it shouldn't be involved in styleChanged(), hence the user customization should be preserved. So I would assume that the problem is that, when modifying text formatting, we forget to set the connected property as UNSTYLED. I can look into that. One thing I can definitely do, for now, is restrict the call to styleChanged() in Score::undoAddElement to the case where the origin score is different than the target score (i.e., we're cloning to/from an excerpt). This at least will solve the problem of lost formatting when copy-pasting within the same score.

[MarcSabatella]

I suspect this is also connected to https://github.com/musescore/MuseScore/issues/14557. I reported that as, size adjustments being lost on save/reload. But I can confirm they are also lost on copy / paste, which makes sense since they use the same basic read/write code I believe. For chord symbols, though, the problem is both on copy/paste and save/reload, whereas for other text, it seems only save/reload.

[mike-spa]

So, I've been looking into it. It seems that part of the problem(s) comes from here: https://github.com/musescore/MuseScore/blame/master/src/engraving/libmscore/textbase.cpp#L2296-L2297 @wizofaus could you explain why that particular change was made? We are intentionally excluding some property tags from the xlm. Let's say I create a staff text and make it bold. This is the resulting xml we get now: and this is the resulting xml if I remove the exclusions and let those properties be written. You could say that in the second case the "bold" information is duplicated, as it is both written as a global property of the object and within the xlm string itself. But that global <bold> tag lets Musescore know that that property has been user-modified, which lets the rest of the program handle it properly. This appears to solve the copy-pasting problem, the additional problem reported by @oktophonie, and also #14557 reported by @MarcSabatella. But before I go ahead and do the fix I want to make sure that this wouldn't cause nuclear accidents elsewhere

[MarcSabatella]

FWIW, I assume it relates to the original issue https://github.com/musescore/MuseScore/issues/8652 and you'd want to check that it doesn't break that. But, I think it's already partially broken again as per https://github.com/musescore/MuseScore/issues/13344.

[wizofaus]

The text formatting code is rather fragile unfortunately - are you able to find the pull request associated with that change? Essentially though we got rid of object- level formatting properties - they all only apply at the character level now.

[cbjeukendrup]

Essentially though we got rid of object- level formatting properties - they all only apply at the character level now.

But that sounds scary! These properties are still controlled by style settings, using the usual system with Pid and PropertyFlags and all that. So if the properties have been (apparently partly) removed but the style settings still try to control them, we can expect strange situations.

[wizofaus]

Yes, there were definitely some issues with styles, but there were worse such issues in v3.6. I found the PR here https://github.com/musescore/MuseScore/pull/8815 but unfortunately it didn't shed any light on what exact problem I was solving with that modification, but I definitely wouldn't have included it if it weren't needed! At any rate, it seems to me if there's already sufficient information in the xml, then the fix to should be the logic that's currently not working rather than adding extra redundant info to it (what happens, for instance, if you try to copy/paste text that starts bold but ends not bold? Or if you paste text that's fully bold, then try to add non-bold text after it...) Looking now at the bug report, I'd suggest the fact that spaces disappear on copy if they have custom font-sizes is a relatively minor annoyance, but it would be worth understanding if the underlying bug might be having other consequences. As it is my PR did contain a fix for the situation where a space would go missing if, for instance, it was marked as underscore, as per the comment:

"this is a bug in MU3, it causes space to go missing from text in some circumstances (e.g. if you mark just the space between words as underline), but I don't know when this isWhitespace() ever is needed, probably need to check git history to determine why it was added"