MuseScore 2.0 support for *any* SMuFL font

• Dec 6, 2014 - 16:21

Hello all!

I am the developer of the November font (and also a long-term freelance developer for Finale etc.)

I am currently giving the finishing touch to a major update to November (2.0), which amongst other things is SMuFL compliant (for the record, I think it is going to be the first commercial font compliant with SMuFL...)

Since I realized that MuseScore 2.0 beta supports Bravura - hence SMuFL is the background - I was wondering how I could make November 2.0 work with it, too.

I understand that Style/General/Score was an interesting place to look up, but the font list seems to be hardwired...
So I tried to hack a bit the score file by editing the tag, but MuseScore crashed on me... I suppose that was not enough!

Perhaps a support for fonts that are not within the application packages could be added at some point? (with the assumption of SMuFL compliancy, or course)

November will be released soon, with SMuFL, Finale & Sibelius advanced support in the first place, and I am wondering how easy it could be to open up MuseScore 2.0 to 'any' SMuFL fonts.

If something can be done, that would be awsome.

Best,
Robert Piéchaud

Comments

• Dec 6, 2014 - 18:36

Hi Robert,

As you find out MuseScore currently support SMuFL internally. The 3 musical and the 3 text fonts are SMuFL compliant. However it's not possible to use external fonts (SMuFL or not).
I would be open to add more "hardwired" fonts in the next versions of MuseScore (after 2.0) if they are licensed under an open license compatible with MuseScore.

Regarding supporting external fonts, MuseScore currently support external text fonts and external "soundfonts". In both cases, it has been shown several times that this support breaks the portability of MuseScore files since one can send a score to someone else who doesn't have the font installed. We could embed fonts in MuseScore files, but we might face legal issues with fonts that shouldn't be embedded...

For these two kind of fonts, the tradeoff is ok. Text and sound are not what MuseScore is supposed to convey and silently fallback to the default text font or Soundfont is ugly but ok. But the musical font being the core and soul of a score it would be a pity to have MuseScore files floating on the internet not displaying notes because the font is not installed on the system. Again, we could fallback silently to a internal font but it might destroy the layout. Existing solution, like the warning one can see when opening a PSD file in photoshop, are not user friendly at all. For these reasons, I currently don't see a good way to support external music fonts, and keep a good experience. MuseScore is WYSIWYG, it would be great if we could make it "what you see, others will see it too", without installing/buying/downloading another font.

My understanding is that the current version of November is proprietary, sold for $70. Will the SMuFL version be available under the same condition?

Reply

• Dec 8, 2014 - 00:14

Hi,

Thank you for the response!

Yes, the upcoming SMuFl-compliant November 2.0 is a commercial product, although it is going to be cheaper than the current price (but still not free, not free to distribute.)

I now understand more clearly that the web model is crucial to MuseScore, so it is a bit pointless to ask for a compatibility with "any" SMuFL compliant font as I did.
The situation is of course different for programs such as Finale or Sibelius.

Thanks again,
Robert

Reply

• Apr 3, 2015 - 00:05

Just want to pipe in, I for one would really like to see MuseScore open things up for external fonts. even if you only provide the possibility to use external fonts for printing only and no web use, etc..it would be useful. I own November v1 also. I notice that lilypond is able to use November, so obviously they aren't concerned about it, but just make it so that only the built in fonts can be used for your web score viewing stuff and meanwhile we can print out PDF's to our heart's content with just about any music symbol font we want.

Reply

• Apr 3, 2015 - 01:05

I think lasconic may be also thinking about people just generally sharing .mscz files, in contexts other than musescore.com, when he says "... it has been shown several times that this support breaks the portability of MuseScore files since one can send a score to someone else who doesn't have the font installed. We could embed fonts in MuseScore files, but we might face legal issues with fonts that shouldn't be embedded..." Myself, I'd simply like to see more fonts built in.

Reply

• Apr 3, 2015 - 01:28

That has always been the case with any commercial fonts of any kind, textual or musical, no different. Anyone using a word processor with custom commercial fonts would face the same exact issues. I don't really see that as a justifiable reason to prevent the capability altogether. I say don't allow external fonts to be embedded in the mscz files. Anyone that wants to share their score file can either make sure the other person has the font or use one of the built in fonts, no problem. At least we could use other fonts we intend to print and share with nobody else.

Reply

• Apr 3, 2015 - 02:50

It *is* different with music, because text fonts are almost invariably used linearly only and don't require the sort of complex horizontal and vertical positioning that is required in music fonts. That is, simply substituting one text font for another might change things like how many characters fit on a line, but it's a trivial simple matter for the text to reflow and everything will look just fine. Not so with music. All sorts of detail of the layout of a score might depend on the specifics of the spacing of the particular font used.

Not to say this in itself is a reason not to support letting people try; just pointing out that it really is *quite* different from the situation with text fonts, where it is ganerally harmless to substitute another font.

Meanwhile, of course, one of the wonderful things about MuseScore being open source is that if you really want your own private version of MuseScore that can use your own private font and produce scores that won't look right when shared with others, you have the means to make this happen. Still, my feeling is, I'd rather see effort go toward making other free and open source fonts available that *could* be incorporated within MuseScore, so *everyone* benefits.

Reply

• Apr 20, 2015 - 09:19

I have to criticize how dismissive your last paragraph is. I don't think the discussion needs to end there, with "We considered it. It breaks portability. So no."

For one, sharing .mscz files isn't a primary use-case for many users, such as myself. I want my scores to look good, yes, but if I were to share it with someone, I'd sooner offer a different file: if they want the musical programming, MusicXML, so they can use it in the scorewriter of their choice; if they want the sheet for playing, a PDF, so they can see it exactly the way I intended it to look. I'd much rather keep a .mscz for myself, and I would ensure I had my system set up to support them.

Second, MuseScore's priorities have always been notation first. I praise it for supporting such a variety of notational elements, but why must they each appear in one of three ways? There is no way to create, say, a handwritten looking score. A SMuFL-compliant cursive musical font would allow for exactly that. I feel like MuseScore is missing out on a valuable opportunity to stand out from the competitors.

Further, musical font can be an extremely expressive device. If the notation really is the heart and soul of the score, it shouldn't be stifled with a preset font. Yes, it solves the problem of potentially losing layout details, but is it worth the price of limiting detail on a more macroscopic level? Besides, I thought a standard is designed so that anything complying with it should work as an alternative.

Don't get me wrong, I understand there are inherent difficulties with implementing support for external fonts. But I don't think lack of portability of scores should stop them from being considered at all. A few good built-in fonts and graceful error-handling for missing ones sounds like a reasonable compromise, where users who want .mscz portability could use the built-ins, and those who don't can use whatever font they want (without having to fork the repo).

Reply

• Apr 22, 2015 - 16:41

Hi Marc,

A second thought...
Font diversity seem to be the direction that music notation programs are taking these days.
It would a pitty for MuseScore not to do so mid-term (I understand that you have a lot on your plate already, and some limited resources...)
I believe one benefit of SMuFL is precisely to 'reduce the noise' upon font swapping.
Besides, SMuFL metadata are aimed to reduce this noise even more, whether as (global) engraving specifications or as glyph-based extra information.

Robert

Reply

• Sep 10, 2018 - 20:05

A high-quality, handwritten font, free like MuseScore, would be a great addition to the program, and the longevity of the thread speaks to the community interest. Has anyone considered crowd-funding the creation of such a font? The fund collection could even bundle in a % donation to MuseScore proper, to reduce the temporary drain on the donor pool. A professionally-designed font, specifically designed to be compatible with MuseScore, would hopefully integrate with minimal additional work for the MuseScore team.

Reply

• Apr 3, 2015 - 14:47

It really concerns me to see how closed an open source project can be.
Its the same thing with themes! Leading up to 2.0 there were several rejected patches that reenabled this. The silent but awesome main dev of the program and his right hand lasconic enforce features they want and kill ones they don't. I guess they can do that, its their project, but it doesn't seem to fit in the usual way FOSS programs are developed(to reject a working patch? ok... to reject an idea because it wouldn't be good for default? ok... to reject the plan to make aforementioned idea opt-in? hmm...)

Reply

• Apr 3, 2015 - 15:44

Regarding the inclusion of "features", if there is no control on what go in and what go out, MuseScore could become feature creep and/or unmaintable and/or hard to support.

The main development team does take decision, but we are also the ones answering questions all day long on the forum, writing code all day long, and merging pull requests. You could probably count on a single hand the number of PR that we didn't merge because we think it would be a problem in term of maintenance or usability while we merged over 1500 PR for MuseScore 2.0. Open source development is not a democracy. While user/developer input is valued, someone has to steer the ship.

That being said, we *do* value user and developer input, and I think it's an important discussion we are having right now on external SMuFL font, and I would like to hear everybody out. So please do not use this thread for another round on theme. Feel free to reach me on IRC #musescore on freenode.net or create another forum post if you want to make a point on theme or feature management. Or better, write more code and participate more, to make your voice heard.

Reply

• Apr 3, 2015 - 17:13

I for one am just incredibly happy that MuseScore is even what it is right now, all from donated developer time. Its honestly quite an achievement and Sibelius, Finale, Notion, Overture and all the rest should be shaking in their shoes about now, because though MuseScore has a ways to go before it will ever really do all the things some of those programs do, it does do quite a lot, an incredible lot...and it is also not a financially based company that will dissappear someday. As long as there are motivated people contributing to the open source cause, it will live on.

I was not aware that a theme patch had been provided and rejected. Don't want to derail this thread, but where can I read all the reasons why it was rejected?

Anyway for my part, I intend to contribute to this project eventually, just no time this year. Most likely I will contribute some significant plugins, but its not out of the question I might try to fork the project and modify the actual program, but less likely because I guess I don't want to risk wasting a lot of time and having the patch rejected. Need to understand more about what criteria is used to decide if a patch will be accepted or not, besides the personal preferences of the inner circle of a few founders. I totally get the need and desire to control quality of the project.

Reply

• Apr 3, 2015 - 23:35

@Lasconic, I am sorry for bringing it up again. I read the official statement about themes before.
Also I guess you are right about FOSS not being a democracy, and about the weight of a voice being determined by the weight of contributions.
My only contribution to 2.0 was commenting out a line and a bunch of annoying threads, as well as "evangelizing" (I hate that term) the program, so I see your point.
Maybe one day when I finally wrap my head around C++, I can contribute more. First year university :)
Greetings, Rafael.

Reply

• Nov 12, 2015 - 02:04

An idea, FWIW... How about a plugin that enabled this feature? Then it would not be part of the core app, and users would understand that extra steps are needed for it to work correctly. Then those that want to use different fonts at least have the option to take those extra steps.

Reply

• Jul 10, 2017 - 02:01

Hi folks!

As a graphic designer / musician, the look of a chart is very important to me.

Thus, I deeply, deeply wish you will consider some process of modifying/changing the Chord fonts. None of the three existing font choices offer a robust-enough looking chord font for my tastes/needs.

I was able to dig inside one of the MuseScore fonts via an old version of Fontographer. Then, I substituted a solid boldface font (a variant of Franklin Condensed) in the place of the ABCDEFG characters and altered the boldness of the flat, sharp, and natural signs but, sadly, my modification only partially works. I get the big, bold Franklin Condensed character for the letter of a chord but in any key that uses a flat, like Bb or Eb, MuseScore ignores my version of the flat symbol. Instead, some really thin symbol gets used and, worse, the kerning is a mile away from the chord letter. (Please see the sample attached.)

As one of the folks earlier in the thread pointed out, if I want to share a chart with someone, 99% of the time I send it in a PDF format so that it will for sure look the way I want it to. In the rare case where I share the MSCZ file itself, I just make sure that the user gets the font that I have modified. (And then help the person get it installed properly when they don't know how to do that! (smile)

At any rate, I want to underline that I know this request is asking a lot so I don't make it lightly. As a print font designer, I can easily imagine how difficult it is to make a complex thing like a music font.

That said, isn't the XML file the glue that holds together all of a music font's parts?

I would be delighted to offer you a free custom-designed font if you folks were willing to drizzle on it the magic glue that would make it functional in MuseScore. Actually, what I would offer up would be your own Emmentaler Jazz chord font modified with bolder shapes and characters.

By offering at least one bold chord font you will be making MuseScore that much more attractive an alternative to the expensive programs like Finale, etc.

Thank you!

Attachment Size
musescore flat prob example 1.jpg 44.08 KB

Reply

• Jul 10, 2017 - 02:32

To be clear: we already support the ability to use any font you like for chord symbols. You just need to make sure it is SMuFL compliant. If your font provides flat signs in the proper codepoint locations, then these will be used. At most you might need to provide your own chord description XML file.

But if you have in improvements you'd like to suggest for MuseJazz, feel free to make them and share a sample version. Since MuseScore is open source, you can even submit this for consideration directly.

Reply

• Dec 5, 2021 - 18:32

Hello! I just discovered this thread.

I am planning to implement this feature for MuseScore 4. I can't guarantee that I'll find the time to do that (since there is a lot of higher priority work to do for the release of MuseScore 4.0), nor I have explicit approval for this yet from the other developers, but at least I have the intention.

I implemented this a while ago in a very primitive way for MuseScore 3 (but it has never been included in any release, because we decided then that there would be no releases anymore until MuseScore 4.0).
For who can't wait: you can download a test version for Windows from https://github.com/cbjeukendrup/MuseScore/actions/runs/1521907303 (see the bottom of the page). Let me know if you would like to have a macOS or Linux version.

This test version requires some accompanying instructions:

  1. Click the download link at the bottom of the page mentioned above.
  2. If you get a .ZIP file, make sure to unzip it, which should give you a folder. This can be done using builtin Windows Explorer functionality. If you already got a folder, then your browser has already unzipped it for you in the background.
  3. In that folder, there is a .7z file. Uncompress this file using the 7-zip utility (which can be downloaded from https://www.7-zip.org).
  4. That should give you another folder. Inside that folder, there is a folder called "bin", and inside the "bin" folder, there is the MuseScore3.exe file. This is the program you need to run.

Then, installing a custom font goes like this:

  1. Create a folder somewhere on your computer where you will store your music fonts.
  2. In this folder, create a subfolder for each music font you want to use. The name of the subfolder needs to match the family name of the font.

  3. Inside those subfolders, put the following:
    a. The .otf or .ttf file for the SMuFL font in question. The filename needs to match the family name of the font.
    b. The metadata.json file that accompanies the SMuFL font. The filename of this file needs to be just metadata.json, without anything else.
    Schermafbeelding_2021-05-31_om_18.22.25.png

  4. Open MuseScore and go to Edit > Preferences.

  5. In the bottom left area of the "General" page, you will see a new textfield called "Score fonts". In that textfield, enter the path to the music fonts folder (the one you just created with the subfolders for the fonts).
    Schermafbeelding_2021-05-31_om_18.26.29.png

That should work!
Now, if you go to Format > Style..., the music fonts dropdown list should also let you choose your custom fonts.

If it doesn't work, you can try restarting MuseScore, and make sure that you put all files in the correct folders under the correct names.

If you have any questions or remarks, please let me know!

Note: it is undefined what happens when you open a file in this test version and then in a stable version again. So it is recommended to use only copies of your files!
It is also undefined what happens when you send a score with a custom font to anyone else who does not have that custom font. In MuseScore 4, this situation will be handled gracefully.
Uploading files to MuseScore.com is disabled in this version (because MuseScore.com uses a stable version of course).
You use this test version at your own risk.

Reply

Do you still have an unanswered question? Please log in first to post your question.