custom palettes and fonts
I'm having problems using the fonts I want when I create items in my custom palettes. I set a style for staff text and text line in a temporary score, then create palette items (barre lines, straight lines, and plain staff text) with given text and a specified font to replace the default "free serif". But when I drag the item onto the new palette, the text reverts to free serif. What's going on? Is it simply that some fonts won't work for Musescore palettes?
Temporary test score, custom palette and Goudy OldStyle font attached so people can replicate my problem (or not, which will also be informative). All items in palette are currently free-serif but were dragged onto the palette with Goudy OldStyle font specified in Text Properties and showing on the score.
| Attachment | Size |
|---|---|
| customPalettetTest.zip | 43.89 KB |
Comments
I believe tThe way to get custom text settings to be honored in a palette is to them using Text Properties (right click menu), as opposed the text toolbar at the bottom of the main window. Did you try that?
In reply to I believe tThe way to get by Marc Sabatella
I didn't even know about a text option down there. As I noted above, what I've been doing is setting a global text style so I don't have to go into each element and change the font as I create custom-palette items. However, your comment caused me to do some experimentation. Here is what I've found. I don't know if it should be classified as a bug or not, but it should certainly be documented:
If you wish to create a custom palette item with a certain font, you must not create it in a score that specifies that same font for that item's global style of text. In other words, if you want to create a straight text palette item, Staff Text is the applicable style, and your desired font must NOT be specified as the global style for Staff Text in that score. Likewise, if you want to create a line with text, Text Line is the applicable style, and you must not set your desired font as the global style for Text Line in that score. If you attempt to create an item and modify it under these conditions, the item will certainly display as desired in the score itself. But when you attempt to add it to your custom palette by dragging it onto the palette (Ctrl-Shift), the font want will be lost, reverting instantly to free serif (Musescore's default font).
Furthermore, as long as you have the same font specified as the global text style for that type of element, it will do no good to right-click on the item's Text Properties and attempt to specify the font. That font is already displaying in Text Properties because you've set it as the global style, and attempting to re-specify it again in the Text Properties dialog does no good. I suspect that when you click OK in Text Properties, Musescore checks to see whether the newly requested font is already specified as the style, and if it is, the program simply does nothing, thus saving a few system resources. There must be some flag set by a successful Text Properties font change, a flag which of course would not be set if Musescore decides that the operation is redundant and refuses to perform it.
As a result, before you create your custom-palette item, you must either A) change the global text style for that element (doesn't seem to matter to what, just some font other than the one you wish your element to display), or B) create the palette item in some other score that has a different font specified for the relevant text style. Only then will the (hypothetical) Text Properties flag be set for your desired font. Once that occurs, that font will finally work in your custom-palette item.
At least this is how it's working on my system so far with a couple of brief experiments. If further usage reveals different or additional results, I'll report back.
In reply to I didn't even know about a by Ironword
If I understand what you are saying, it is indeed meant to be a feature. What gets recorded as the text properties in a custom palette element are the things that *differ* from the standard. It's not a perfect system, but it does cover the majority of use cases well.
In reply to If I understand what you are by Marc Sabatella
That's a perfectly fine programming design decision, then. No bugfix necessary.
However, as I said, a warning about this issue should certainly be given in the Handbook. It makes sense once you point out the design decision, but unless you're a Musescore programmer, there's no particular reason to suspect that the above conditions obtain unless someone tells you. There's nothing that would warn a general user that you can only create an item with a non-default font if that font is not specified as a style; it all depends on how Musescore works under the hood. The app could certainly be written to simply accept any font displaying in text properties, no matter whether specified as a style or not, and permanently apply that font to the palette item. I'm no technical dummy (I'm not in application development but I have done some programming) but that's what made the most sense to me.
In reply to That's a perfectly fine by Ironword
Feel free to do some experimenting, figure out how it makes makes sense to describe, and contribute the documentation yourself - such is the beauty of open source software!
The problem with the use model you describe is that most of the time it would not be what you want. Consider, you create a text item where the *only* thing that differs from the default is the size. It would be nice if you could apply that same element to any score regardless of what it's own default was, and the aspects of yhe original default you hadn't changed would pick up the defaults from the specific default in the score you are applying it to. That's the general idea. The devil is in the details, though.