Dynamics: formatting lost when character copied/cut/pasted in same object
S4 - Minor
MS 3.3 RC2.
- Apply an FP dynamic symbol, say;
- Cut the "F" then paste it in the same place.
Expected result: Dynamic keeps the same formatting. And this is the behaviour in MS 2.3.2.
Actual result: The "F" loses its formatting.
And when you apply a dynamic, the "Remove Custom Formatting" bar is active in the Inspector. Pressing this button causes a change of formatting but according to the text toolbar (under the document window) there has been no change. Surely, there is no need for custom formatting of dynamics in the first place—it should all be in the Style declaration?
Similar issue with tempo text, #295155: Tempo text: Improve default formatting?
Dynamics are special in that those aren't just regular "f" and "p" characters in a standard font - they are thir own unique characters with their own special codepoints in the "musical text font" you have specified. And anything with special characters in it by definition involves custom formatting - the formating required to switch to the musical text font and insert those special characters. And that is what the "remove custom formatting" is removing, so that much is by design.
It's a known issue that special formatting like this (or even just changing to italics) is lost on copy/paste within a text element (not seeing the issue for it right now, but I know it's out there). So chances are pretty good that what is going on here is a duplicate. But whatever portion is not, is easily solved - the recommended way to add these special symbols is with the shortcuts (Ctrl+Shift+letter) or the special characters dialog.
From what I can see copy/paste of text doesn't support formatting at all in either direction (e.g. if you copy formatted text from Word or another program into MuseScore, the formatting isn't preserved - and when you copy from MuseScore only plain text is put on the clipboard). While
Windows supports "rich text format" for the clipboard I don't know how this will work on Mac/X-Windows etc., I guess it's down to whatever Qt supports. Will look into it anyway.
In reply to From what I can see copy… by Dylan Nicholson1
Ok so Qt definitely supports rich text for copy/paste, in fact that's how QTextEdit behaves by default but we're not using it when editing staff text, rather a custom control Ms::TextExit that implements it's own copy/paste, and doesn't support formatting (in fact the paste function specifically removes any HTML tag characters in any plain text on the clipboard!). I'm happy to have a go at using QMimeData with rich text etc. but I don't know how feasible it will be, and can't easily test on Mac or X-windows etc. The other alternative it just to support limited HTML in the plain text (but then it won't interact well with other apps that support rich text on the clipboard).
In reply to Ok so Qt definitely supports… by Dylan Nicholson1
Looks like it'll be much simpler/safer just to use the built-in limited-HTML support. I guess it depends how useful it is to be able to copy and paste rich formatted text into/out of MuseScore.
In reply to Looks like it'll be much… by Dylan Nicholson1
So with a bit of refactoring I was able to re-use the code that computed the layout so I can paste in, e.g.
norm<i>ital</i><b>bold<i>boldital</i></b><font size="20">size 20</font>endand have it display almost as expected. I say almost because the
</font>end tag is not honoured, and I've noticed that this is true in general with the pseudo-HTML used for storing formatting info in mscx files etc. so I'm loathe to change that as it may break existing scores.
Just need to implement the "copy" side of things now, which I assume won't be too hard.
But yeah, while it's fine if copying/pasting between another text editor where you're editing HTML it's not great otherwise.
<b> & <i>considered accessibility no-no's, with
<strong> & <em>being preferred instead (as they're not purely about the visual styling, which is irrelevant to blind users etc.)?
In reply to So with a bit of refactoring… by Dylan Nicholson1
I have "copy" working now so that the text on the clipboard includes the basic HTML formatting tags.
But there's definitely difference between System Text and Staff elements, as the former render "ScoreText" at a larger point size for some reason. Will investigate later.
In reply to I have "copy" working now so… by Dylan Nicholson1
BTW I can improve it somewhat by treating "select all" as a special case, and just taking the XML text in that case. Note then it doesn't transfer the formatting of the style from the source element - you have to set that yourself, but arguably that's a good thing.
However it's not always doing what I want when pasting over existing text. There are lot of a corner cases to cover depending on how accurate we want it to be.
In reply to BTW I can improve it… by Dylan Nicholson1
More importantly I haven't fixed the original bug. If I select just one "f" from an fp or ff dynamic marking it copies
<font size="11"/><font face="ScoreText"/>to the clipboard, and pasting this doesn't work as expected, still need to figure out why.
By default, score symbols render at 20 pt or whatever the nominal size defined by SMuFL is. That's the size at which they appear the same size they would be expected to in a score. So chances are there is some logic somewhere that is kicking in and making your symbols render at that size even though you don't want it to here.
In reply to By default, score symbols… by Marc Sabatella
It's also an issue that when pasting into a dynamic field it seems to think the current font style is Italic, even though the standard dynamic markings shouldn't be shown with italic set as they're already italicized. In fact just fixing that (by forcing the cursor's style to "normal" for Dynamic-type elements when pasting) and ensuring that the font face is "ScoreText" fixes the original bug.
I still haven't fully worked out what this "ScoreText" pseudo font family is yet though, it seems to change the size and kerning etc.
In reply to It's also an issue that when… by Dylan Nicholson1
BTW, I would almost expect when editing a dynamic mark you should be able to type in m f p etc. as regular letters and have them convert to dynamic markings, but I suppose you could argue that for something like molto f that's not what you'd want, and perhaps that's why the default style is italic. Problem with my fix now is that copy and pasting molto f to the clipboard then pasting into another dynamic marking doesn't preserve the italic!
In reply to BTW, I would expect when… by Dylan Nicholson1
Ok that's all fixed, and basically everything is working now as I'd hope - except if you delete all the text and then hit Ctrl+Z - a bug that also exists in MS 3.6.2. In the end it seems the trick was to turn off bold/italic when pasting anything in font family "ScoreText", which is how it seems to work internally when it first initialises the textedit element.
In reply to Ok that's all fixed, and… by Dylan Nicholson1
Found what's causing that undo bug, but it was a specific change made to fix another issue (where it tried to make the current font "ScoreText" which screwed up other things), so I had to put in a bit of a workaround, but it does the job.
As part of this I noticed another bug, that if you edit a text element, delete all the text (by any means, including one character at a time), then exit edit mode, undo doesn't work. I'll look at fixing but I'm not sure it's related.
In reply to Found what's causing that… by Dylan Nicholson1
Have put up a PR https://github.com/musescore/MuseScore/pull/8301 but currently copy/paste is completely broken in MU4 so it can't even be tested.
Fixed in branch master, commit 91035f9164
[MU3] fix #296212 - formatting lost when copying/pasting text
Automatically closed -- issue fixed for 2 weeks with no activity.