Hello everyone.
Here I would like if someone could contribute to explain how to create a SMuFL compatible font.
1. It would be good if we can have a template of SMuFL in FontForge.
2. It would be good to know which of all these symbols are "common" and which are variants. For example, the regular is at U+XXXXX, and so on. This is because the SMuFL is extremely long and for beginners it is truly hard to orientate.
OCTO wrote:Hello everyone.
Here I would like if someone could contribute to explain how to create a SMuFL compatible font.
1. It would be good if we can have a template of SMuFL in FontForge.
2. It would be good to know which of all these symbols are "common" and which are variants. For example, the regular is at U+XXXXX, and so on. This is because the SMuFL is extremely long and for beginners it is truly hard to orientate.
Thanks. O.
1. Do you mean that you would like a dedicated codepage with backgrounds, names and all?
As SMuFL has yet to be adopted by Unicode, I don't think this is currently possible. However, with the exception of duplicate code points in the Musical Symbols range, SMuFLs entire symbol set has been located to the Private User Area (PUA) range in the Basic Multilingual Plane (starting at code point U+E000).
2. The glyph tables make it pretty clear which is which in terms of main symbols and semantically identical variants or 'stylistic alternates'. But of course there are a lot of symbols – even entire ranges – that easily can be considered pretty obscure. Some ranges also include duplicates of symbols in other ranges.
If you want to create a font for your own personal use, I'd suggest going through the ranges and decide which ones might be relevant to the scope of your font. None of the symbols in SMuFL are mandatory, so you can freely pick and choose which symbols you want to include (decisions that really can't be made without some understanding of each symbol's relative obscurity or common usage).
To give you a general idea and a starting point for symbol selection, Maestro's symbol set is spread over the following ranges (from what I can remember):
That is wonderful, Knut.
So basically I can open an empty FontForge document, name each glyph and create the symbols I need (clefs, noteheads...). Is that a correct way to do?
Freelance Composer. Self-Publisher. Finale 27.5 • Sibelius 2024.3• MuseScore 4+ • Logic Pro X+ • Ableton Live 11+ • Digital Performer 11 /// MacOS Monterey (secondary in use systems: Fedora 35, Windows 10)
OCTO wrote:That is wonderful, Knut.
So basically I can open an empty FontForge document, name each glyph and create the symbols I need (clefs, noteheads...). Is that a correct way to do?
If you are using FF, I'd open up the latest version of Bravura and copy all the glyphs' foreground layer to the background layer for reference (there's a quick menu option to do that), then go about replacing the foreground outlines of the glyphs you want and deleting the rest after you're done.
OCTO wrote:That is wonderful, Knut.
So basically I can open an empty FontForge document, name each glyph and create the symbols I need (clefs, noteheads...). Is that a correct way to do?
Basically, yes.
The naming could be an issue, though, since SMuFL recommends using AGLFN (Adobe Glyph List For New Fonts) naming conventions inside the font file. AGLFN stipulates generic unicode names (uniXXXX, where XXXX is the unicode number) for glyphs in the PUA range. FontLab has a comment field for each glyph which can be used to transfer names from the font file to the metadata.json file with a dedicated script. I don't know if FontForge has a similar feature, or if any of the available scripts written to perform the task in FontForge does it in a similar way. If not, you could always name the glyphs according to the SMuFL glyph list, only to batch rename them according to AGLFN after the metadata file has been generated.
I would suggest you ask tisimst how best to approach this since I'm not familiar with FontForge.
Thanks for starting this, OCTO. And thanks to Knut and tisimst for offering their valuable insights. Given the current situation with Dorico impending, this is a very important thread.
M1 Mac mini (OS 12.4), Dorico, Finale 25.5, GPO 4, Affinity Publisher 2, SmartScore 64 Pro, JW Plug-ins, TG Tools, Keyboard maestro
John Ruggero wrote:Thanks for starting this, OCTO. And thanks to Knut and tisimst for offering their valuable insights. Given the current situation with Dorico impending, this is a very important thread.
You're very welcome, John.
I really encourage anyone who wants to create SMuFL compliant fonts, or those who simply want to better understand how Dorico potentially will take advantage of font technology in a much more advanced way than the current software, to take a look at the SMuFL specification. If anything isn't easily understood, I will be happy to help, as I'm sure tisimst will as well.
Knut wrote:The naming could be an issue, though, since SMuFL recommends using AGLFN (Adobe Glyph List For New Fonts) naming conventions inside the font file. AGLFN stipulates generic unicode names (uniXXXX, where XXXX is the unicode number) for glyphs in the PUA range. FontLab has a comment field for each glyph which can be used to transfer names from the font file to the metadata.json file with a dedicated script.
Thanks for this info. Is it something that is common in music font creation, such as Maestro or Opus? Does Finale need AGLFN?
Knut wrote:The naming could be an issue, though, since SMuFL recommends using AGLFN (Adobe Glyph List For New Fonts) naming conventions inside the font file. AGLFN stipulates generic unicode names (uniXXXX, where XXXX is the unicode number) for glyphs in the PUA range. FontLab has a comment field for each glyph which can be used to transfer names from the font file to the metadata.json file with a dedicated script.
Thanks for this info. Is it something that is common in music font creation, such as Maestro or Opus? Does Finale need AGLFN?
No, this applies only to characters in the PUA (Private User Area) unicode range. Finale and Sibelius have most of their glyphs mapped to the basic unicode ranges, so they do not need to be encoded according to AGLFN. Lilypond, on the other hand, does make extensive use of the PUA in their fonts, but nevertheless do not follow the AGLFN recommendations.
This is chiefly a question of reliability. SMuFL compliant fonts are typically meant to be used across many applications and platforms, and therefore need to follow these guidelines exactly to ensure reliable results. Lilypond's font do not have this issue. Your fonts may very well work fine in Dorico (or Finale when they launch their SMuFL support) even without following these guidelines. But then again, they might not.
I'm trying to convert my own music fonts to SMuFL using fontforge. There's a python script by Robert Piéchaud that should automatically generate the required font metadata (https://github.com/w3c/smufl/tree/gh-pa ... /fontforge).
I have never used any sripts in fontforge before and so far I haven't been able to get the script to work. Does anybody on this forum know how to set up fontforge and/or python correctly on Win 10 so python sripts can be run inside fontforge? Or can anybody point me out to where I should look for information about this? I found quite a bit about python scripts and fontforge, but so far nothing that helped me with setting up the basic requirements.
I'd be grateful for any help!
Best
F