About SMuFL creation

Dorico
21

FYI the ‘splitStems’ properties are used for these: https://steinberg.help/dorico/v1/en/dorico/topics/notation_reference/notation_reference_stems_altered_unisons_split_stems_r.html

22

I commend you, teacue. Nice one!

23

@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.

24

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.

25

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.

26

In the Metadata for SMuFL-compliant fonts specification one can read:

The optional “glyphBBoxes” structure contains information about the actual bounding box for each glyph.
…
This data is provided primarily for MakeMusic Finale, which requires bounding box data for certain graphical and spacing calculations performed by the software.

https://w3c.github.io/smufl/gitbook/specification/glyphbboxes.html

I am not sure about the meaning of the expression “primarily for MakeMusic Finale”.
I have read and understood that Finale needs these informations and that they are otherwise stored in FANs files for Finale.
But doesn’t Dorico also need these informations?
Or does Dorico read these informations somewhere else? Directly from the font?
And does it mean that for a font that should work only in Dorico, there is no need to provide the glyphBBoxes settings in the metadata file?

27

Dorico doesn’t use those bounding box values, as it reads them directly from the font. They should be easy to calculate, however: scripts for FontForge and FontLab are provided in the SMuFL repository that can be used to write out these values so you can add them to the metadata file.

28

Thank you for your answer, this is very usefull for me at the moment trying to understand the metadata.
This leads me to another similar question concerning other metadata categories.

In the SMuFL specification one can read about the “glyphsWithAlternates”, the “ligatures” and the “sets” that these data are usefull for “Applications that cannot access advanced font features like OpenType stylistic alternate/ligatures/sets …”

Can I assume that Dorico has acces to the Open Type Advanced Features (Stylistic Alternates, Ligatures and Sets) and thus does not need these additional Data in the metadata json file?

29

Dorico doesn’t read these fields directly from the metadata, but it also does not directly read the OpenType features of the font: instead, things like optical variants and stylistic alternates are handled in other ways by the way the choice of glyph is determined.

30

Thanks for these informations.

I deduce then from your answer that “glyphsWithAlternates”, “ligatures” and “sets” are absolutely not necessary for Dorico itself but are they are necessary for third party apps.

Is the way Dorico knows about these data mostly through the canonical glyph name and the code point?

I guess I should mention one of the aim of my questions about the metadata at this moment.
Beside of the general understanding I also would like to create the necessary metadata file for a specific font I made.
But I don’t want to simply copy an existing metadata file I don’t understand.
I am also aware that a metadata file containing only the “fontName” and the “fontVersion” is enough at first.
But I really aim to understand which metadata are necessary for Dorico, what they do and which are not necessary but only there for third party apps.

The last results are;

  1. Dorico uses the “engravingDefaults” if the font designer wants to give specific engraving settings for his font.

  2. Dorico uses the “glyphsWitchAnchors” if the font designer gives specific settings for the placement of glyphs.

  3. Dorico does not use the “glyphsWithAlternates”, the “ligatures” and the “sets”.
    Dorico has it’s own way to know about them.
    These data are there for third party apps.

  4. Dorico does not use the “glyphBBoxes” data.
    Dorico reads these informations directly from the font.
    These data are there for third party apps (mostly for Finale)

  5. I did not ask about the “optional"Glyphs” but I assume that it behaves like “glyphsWithAlternates” but with one difference: in case the font designer includes completely new characters (completely private to the particular font) then Dorico needs to identify the name, code point, and optional class (or classes) for each optional glyph in the font.

To sum up here are the necessary metadata for a font that should be working with Dorico only:
. engravingDefaults (if the designer chooses to suggest specific settings)
. glyphsWithAnchors
. optionalGlyphs (if the designer includes some)

Please correct me if I am still wrong!