Slowly learning and analysing the rules for SMuFL I have a question:
Are the duplicated glyphs that can be found in a SMuFL font only there for compatibility with other notation programs?
If I intend to create a SMuFl font for use in Dorico only is it then enough to create glyphs following the glyph tables as introduced here: Please wait while you are redirected without duplicating any glyph?
Daniel will have to explain the duplicate codepoints (if that’s what you mean), but I can tell you that it has nothing to do with compatibility with other notation softwares since, well, that would render moot the point of a standard, or rather it would eliminate third parties’ motivation to adhere to the standard if SMuFL were catch-all.
To use a font with Dorico, you have to map the respective glyphs at the prescribed codepoints and that’s it, in a nutshell.
Thanks for your answer.
Yes I mean the Unicode code points.
For example in Bravura I see six Double whole (breve) noteheads.
Two of them U+E0A0 and U+ECD0 seem to me to be identical.
And the other four U+E1D0 / U+ECA0 / U+F4BA and U+1D15C are bigger and seem also to be identical.
The description in the SMuFL glyph table says for this notehead:
U+E0A0
noteheadDoubleWhole
Double whole (breve) notehead
The table for “Recommended stylistic alternates” says:
uniE0A0.ss01
noteheadDoubleWholeSmall
Double whole note (breve) (small staff)
and
uniE0A0.ss05
noteheadDoubleWholeOversized
Double whole note (breve) (oversized)
Just wondering how to understand these informations.
Oh. Those are, as the name says, stylistic alternatives, id est, variations on a base glyph that can be called upon depending on the context. For example, the first stylistic alternative is to be used on smaller staves (as the name says): when differently-sized staves coexist on the page, you want the contents of the smaller-sized one to appear consistent with the bigger staff, which naturally would not be the case if the glyphs were just drawn at a smaller point size. The Large noteheads, so characteristic to Bravura and Dorico’s default option, are in fact a stylistic alternative to the default noteheads. In other instances, these can just be different variations on a glyph — whether to draw a modern or old-style breve, for example. These sets are defined in the metadata. As for the actual duplicates, as I said, I’m afraid I don’t know.
SMuFL is structured according to semantic categories, each with a complete set of relevant glyphs. While many categories may contain identical glyphs as a result, they all serve a unique purpose with regard to usage and may have slight variations in design, registration or spacing. Even if some glyphs are completely identical, they are duplicated so that a font designer may easily choose which categories to cover, and then be sure that the font will be complete for its intended purpose.
As far as I can see, SMuFLs structural concept isn’t perfectly carried out. There are seemingly unnecessary duplicates in certain related categories (e.g., accidentals), while in others, certain glyphs are missing or misplaced. But in spite of this, the overall structure is very well thought out and very relatable from a design perspective, especially when considering the duplicate glyphs found in text fonts with extended language support or support for different OpenType features. Even though the many duplicates might be confusing at first, I even think users will find SMuFL’s structural concept to be very helpful, especially when trying to localise glyphs in a very large symbol set.
@ LSalgueiro
Thank you for these very interesting explanations.
@ knut Nergaard
Thank you, your answer helps me to better understand the whole concept.
It seems I made the mistake of analysing the glyphs position within the font alone without looking at the metadata.
Studying both at the same time, things begin to be a little bit clearer.
And indeed the more I understand the structure the more I begin to appreciate it.
A question comes to my mind:
In the metadata it is possible to give precise engraving default values for items which do not primary concern the font itself, for example staff line or ledger line thickness.
What is the relation between these values and the values set in Dorico itself?
The engraving defaults embedded in the metadata are intended to feed the notation programme certain key engraving settings that will comply with the overall font weight and the design of particular glyphs (e.g., staff lines).
OK but what is the underlying hierarchie?
I mean which value has priority and how the values made in Dorico and the values set in the metadata file are connected?
For example I just tried to change the value of “legerLineExtension” in the metadata file of a SMuFL font but it seems that it does nothing.
Only changes made in Dorico itself in "Engraving Options/Notes/Ledger Lines / Ledger lines protrude beyond noteheads by: " affect the ledger line extension.
So I am wondering in this particular case what is the meaning of the value in the metadata file.
Not all values are being consumed by Dorico at the moment, by the way. There are quite a few loose ends and roadblocks one still runs into, since not everything is finished or fully documented.
Values specified in the metadata are simply dumped into the Engraving Options when the font is loaded through Music Fonts. If you change one of the values afterwards, that value will stick. I’d dispute your claim that these are values which do not concern the font, since it is quite important that primitives are harmonious with the glyphs (in terms of thickness, for example). You can’t really consider one but not the other if everything is to look its best.
Ah, I see.
I just made some tests and these tests confirm what you write.
Dorico takes the values from the metadata but then the values can only be edited from Dorico itself.
If you change values in the metadata file afterwards it seems that Dorico will ignore this for projects which already use the font.
It makes sense.
I don’t know why but I first thought that if you changed the values in the metadata Dorico will re-read these values for existing projects.
This question is now answered, thank you 
Sure I also think that it’s a whole picture and of course the staff line thickness for example has a lot to do with the asthetics of a font.
What I meant with the word “primary” was from a technical point of view.
I don’t know how to express it better in englisch.
In french I would say something like “Au premier abord” or in german “Zunächst”.
I just wanted to know from a technical aspect what was the priority mechanism between values set in the metadata and values set in Dorico.
Now I know
When I open Bravura in FontForge and look at the Glyph Info the Glyph Name is always a unicode number instead of the canonical glyph name.
For example according to the “glyphnames.json” file the canonical glyph name of the Whole notehead is “noteheadWhole”.
The codepoint is “U+E0A2”.
The description is “Whole (semibreve) notehead”.
But in the “Glyph Info” in FontForge one can read:
Glyph Name: uniE0A2
Unicode Value: U+e0a2
Isn’t it redundant this way?
Is there a particular reason why the unicode value has been choosed as a name instead of the canonical glyph name?
I ask because in the process of creating a SMuFL font I just wonder if I should use the canonical glyph names or not.
SMuFL does not currently contain any guidelines with regard to the inherent glyph names of fonts. However, for reliability reasons, Bravura follows the naming conventions stipulated by Adobe Glyph List For New Fonts (AGLFN). According to this specification, glyphs in the PUA range of Unicode (where all of SMuFL’s glyphs are encoded) should be named with the prefix uni, followed by the four character unicode. Glyph names like noteheadWhole are to be used as an additional identifier when reading the metadata, and are not part of the font itself.
That said, your font may work just fine in Dorico even if you choose to use the SMuFL names to name your glyphs. Indeed, both November 2, designed by Robert Piéchaud, and all of Abraham Lee’s SMuFL compliant fonts does it this way. This may, however, be because of certain limitations in FontForge, which is both Abraham and Robert’s font editor of choice, but it is nevertheless not in accordance with what could be considered current reliable font design practice.
Just to be clear, this choice of naming was not due to some limitation in FontForge. Bravura shows up as expected with all glyph names according to AGLFN. Renaming all the glyphs to the canonical names rather than uniXXXX was merely preferential in my case (I can’t speak for Robert P.) because I understand those names better than those specified by AGLFN. Thankfully, Dorico doesn’t access the glyphs by name, so naming choice of glyphs isn’t an issue either way at the present time. My hope is that this will remain the case.
Actually, as I understand it, the reliability issue isn’t just related to applications, as arbitrary names can potentially result in conflicts with postscript interpreters and printer drivers as well. I have never encountered any such problems myself, though.
It should be perfectly fine to use glyph names like noteheadWhole as long as those names abide by the OpenType standard for glyph naming.
The primary purpose of the AGL and AGLFN was to be able to grab semantic information from PDFs for searching and copying by looking at glyphnames for understanding the text within a document when that semantic information was unavailable in the document. PDFs produced via a PostScript distiller, usually intended for printing, often are not searchable. So, with this naming, Adobe Acrobat, for example, may be able to figure out the text based on the glyphnames from the embedded cmap table.
Thanks to all for your interesting informations.
Not sure if it is a good idea but I ask.
At the moment I gather all kind of ideas before I create a concept for my own handwritten font.
When I look at all the manuscripts I wrote in the past there is definitely a leitmotiv on how I draw the stems - they almost never reached the noteheads.
Here is an example:
This is something surely quite common for composers to write this way and I thought this could give a font a particular timbre.
But as stems are not directly part of a font how would one achieve this in Dorico and SMuFL?
Is there somewhere a way to define the length of a stem so that it does not reach the head?
Edit
As this post originally contained too much wrong informations I thought it would be better to correct it to prevent any confusion!
I also removed an image which contained wrong infos.
Now the following informations are correct:
With these parameters it is possible to move a stem from the notehead:
“stemDownNW” and “stemUpSE”
Here is a picture describing what these parameters are:
https://w3c.github.io/smufl/gitbook/specification/glyph-registration-notes-flags.html
My first assumption was to use the parameters “splitStemUpSE”, “splitStemUpSW”, “splitStemDownNE” and “splitStemDownNW”.
But this was wrong and PaulWalmsley friendly pointed a few post down below to what these properties are used for:
I don’t think you’d be able to persuade Dorico to draw stems disjointed from the noteheads, even if you adjust the stem attachment points to try to stop them a long way away from the noteheads.
Thanks for your answer Daniel.
Well I tried again and … it works!
Dorico has been persuaded 
During my first try I choosed the wrong parameters.
Editing “stemDownNW” and “stemUpSE” for “noteheadBlack” leads to this:
I find this quite promising.
Of course the question remains wether these settings are enough to work consistently for all situations.
But it’s only the beginning
That is really cool, can’t wait to see your progress on this!