Dynamics: formatting lost when character copied/cut/pasted in same object

• Oct 28, 2019 - 15:12
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

MS 3.3 RC2.

  1. Apply an FP dynamic symbol, say;
  2. 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.
    dynamic_1.png
    Actual result: The "F" loses its formatting.
    dynamic_2.png

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?

Comments

• Oct 28, 2019 - 16:49
Severity S3 - Major ⇒ S4 - Minor

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.

Reply

• Jun 6, 2021 - 23:01

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.

Reply

• Jun 6, 2021 - 23:25

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).

Reply

• Jun 7, 2021 - 00:09

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>end and 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.
Also aren't <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.)?

Reply

• Jun 12, 2021 - 03:15

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.

Reply

• Jun 12, 2021 - 17:33

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.

Reply

• Jun 13, 2021 - 02:48

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.

Reply

• Jun 13, 2021 - 03:02

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!

Reply

• Jun 13, 2021 - 05:26

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.

Reply

• Jun 13, 2021 - 05:52

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.

Reply