About SMuFL creation

Discussions about our next-generation scoring application, Dorico.
teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

About SMuFL creation

Post by teacue »

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: https://w3c.github.io/smufl/gitbook/index.html without duplicating any glyph?
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

LSalgueiro
Senior Member
Posts: 1039
Joined: Tue Oct 18, 2016 12:51 am
Contact:

Re: About SMuFL creation

Post by LSalgueiro »

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.

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

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.
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

LSalgueiro
Senior Member
Posts: 1039
Joined: Tue Oct 18, 2016 12:51 am
Contact:

Re: About SMuFL creation

Post by LSalgueiro »

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.

Knut Nergaard
Junior Member
Posts: 199
Joined: Thu May 19, 2016 2:13 pm
Contact:

Re: About SMuFL creation

Post by Knut Nergaard »

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.

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

@ 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?
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

Knut Nergaard
Junior Member
Posts: 199
Joined: Thu May 19, 2016 2:13 pm
Contact:

Re: About SMuFL creation

Post by Knut Nergaard »

teacue wrote:
Sun Mar 04, 2018 8:05 am
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).

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

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.
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

LSalgueiro
Senior Member
Posts: 1039
Joined: Tue Oct 18, 2016 12:51 am
Contact:

Re: About SMuFL creation

Post by LSalgueiro »

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.

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

LSalgueiro wrote:
Sun Mar 04, 2018 2:32 pm
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.
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 :)
LSalgueiro wrote:
Sun Mar 04, 2018 2:32 pm
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.
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 :)
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Canonic glyph name or Unicode value

Post by teacue »

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.
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

Knut Nergaard
Junior Member
Posts: 199
Joined: Thu May 19, 2016 2:13 pm
Contact:

Re: Canonic glyph name or Unicode value

Post by Knut Nergaard »

teacue wrote:
Wed Mar 07, 2018 12:53 am
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.

tisimst
Junior Member
Posts: 79
Joined: Mon Aug 08, 2016 6:19 pm
Contact:

Re: Canonic glyph name or Unicode value

Post by tisimst »

Knut Nergaard wrote:
Wed Mar 07, 2018 1:23 pm
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.
Music Typeface Designer & Engraver
LilyPond | Dorico | Sibelius | Finale | MuseScore | SMuFL | Inkscape | FontForge

http://www.musictypefoundry.com

Knut Nergaard
Junior Member
Posts: 199
Joined: Thu May 19, 2016 2:13 pm
Contact:

Re: Canonic glyph name or Unicode value

Post by Knut Nergaard »

tisimst wrote:
Wed Mar 07, 2018 5:23 pm
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.

composerjk
New Member
Posts: 14
Joined: Sun Oct 30, 2016 5:33 am
Location: SF Bay Area, California, USA
Contact:

Re: Canonic glyph name or Unicode value

Post by composerjk »

Knut Nergaard wrote:
Wed Mar 07, 2018 1:23 pm
teacue wrote:
Wed Mar 07, 2018 12:53 am
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.

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.
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.
Typeface designer, Composer, Pianist, Analog synths, Dancer
https://1403.slantedhall.com/ | https://slantedhall.com/

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

Thanks to all for your interesting informations.
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Is space between stems and noteheads possible?

Post by teacue »

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:
stems-far-from-heads.jpg
(170.35 KiB) Not downloaded yet
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/spe ... 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:
PaulWamsley wrote:FYI the 'splitStems' properties are used for these: https://steinberg.help/dorico/v1/en/dor ... ems_r.html
Last edited by teacue on Sat Mar 10, 2018 1:59 pm, edited 1 time in total.
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

User avatar
Daniel at Steinberg
Moderator
Posts: 17732
Joined: Mon Nov 12, 2012 10:35 am
Contact:

Re: About SMuFL creation

Post by Daniel at Steinberg »

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.

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

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:
stems-far-away-01.jpg
(74.15 KiB) Not downloaded yet
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 :)
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

Bastis
New Member
Posts: 22
Joined: Sun Jan 07, 2018 3:36 pm
Contact:

Re: About SMuFL creation

Post by Bastis »

That is really cool, can't wait to see your progress on this!

User avatar
PaulWalmsley
Steinberg Employee
Posts: 2031
Joined: Tue May 17, 2016 9:24 pm
Location: Steinberg, London
Contact:

Re: About SMuFL creation

Post by PaulWalmsley »

FYI the 'splitStems' properties are used for these: https://steinberg.help/dorico/v1/en/dor ... ems_r.html
Architect & Developer - Steinberg London

LSalgueiro
Senior Member
Posts: 1039
Joined: Tue Oct 18, 2016 12:51 am
Contact:

Re: About SMuFL creation

Post by LSalgueiro »

I commend you, teacue. Nice one!

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

@Bastis
Thank you .

@PaulWalmsley
Thank you for this information.
There is quite a lot to learn about SMuFL, any help is welcome.

@LSalgueiro
Thank you.
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

composerjk
New Member
Posts: 14
Joined: Sun Oct 30, 2016 5:33 am
Location: SF Bay Area, California, USA
Contact:

Re: About SMuFL creation

Post by composerjk »

As long as you stick with single notes (instead of chords), the disconnected stem look will work. Currently, with a chord, the base of the stem would be separated but then continue through the rest of the noteheads, so it won't seem disconnected. fyi.
Typeface designer, Composer, Pianist, Analog synths, Dancer
https://1403.slantedhall.com/ | https://slantedhall.com/

teacue
Member
Posts: 513
Joined: Mon Mar 07, 2011 10:42 am
Location: Germany
Contact:

Re: About SMuFL creation

Post by teacue »

composerjk wrote:
Sat Mar 10, 2018 7:41 pm
As long as you stick with single notes (instead of chords), the disconnected stem look will work. Currently, with a chord, the base of the stem would be separated but then continue through the rest of the noteheads, so it won't seem disconnected. fyi.
Oh, you are right!
I did not look so far.
It's a pitty but thinking a little bit about this it would probably be very difficult to implement such short stems for every kind of situations.
For example how should it look like with two notes with a bigger intervall than a third?
But indeed for a melody it can feet quite well.
So this find must not be completely unusable but only limited.
Thanks for noticing this.
Cubase Pro 10 - Dorico 3.0 - Finale 25 - Windows 10 Pro 64bit
teacuemusic (Musicals)
youtube

Post Reply

Return to “Dorico”

Who is online

Users browsing this forum: No registered users and 7 guests