Re: SMuFL clarifications

Good to hear from you, Owen. Here are some answers to your questions:


  1.  It is indeed intended that you should not need access to OpenType features in order to access all of the alternate glyphs in Bravura; Dorico, for example, doesn’t have access to OpenType features because the Qt framework it’s built upon doesn’t currently provide APIs for them. So we refer to these alternate glyphs via their code points, which are indeed encoded in the JSON metadata file.
  2.  There is no particular significance to the number in the .saltXX suffix, other than that we wanted them to be unique.
  3.  You can use whatever naming system you like for the glyphs in your SMuFL-compliant version of Emmentaler. We recommend following the AFGL standard because the recommendations we received from experts in the font design community was that AGL glyph names have superior compatibility with PostScript-speaking applications, but it’s quite possible that these days those issues are less likely to occur. I believe some SMuFL-compliant fonts are not following the AGL recommendations and I’m not aware of any specific problems. If you do decide to follow the naming convention we use in Bravura, there’s no need whatsoever to match up the .salt01 glyph to the equivalent alternate in Bravura.
  4.  It means consistent within the font, but again if it makes sense to use one of the existing names that we’re using in Bravura, it would probably be helpful to do so.
  5.  I believe it would be fine to use an .otc if you wish. So far as I know this has good operating system support.
  6.  We did explore the idea of embedding the font metadata directly in the font as a custom table, but it was felt at the time that this would make the metadata hard to access for several environments where the fonts might be used. At best it would have to be offered as an alternative approach to using a separate JSON file.

All the best,

Daniel

From: Owen Lamb <owendlamb@gmail.com>
Date: Thursday, 18 June 2020 at 10:53
To: "public-music-notation@w3.org" <public-music-notation@w3.org>
Subject: SMuFL clarifications
Resent from: <public-music-notation@w3.org>
Resent date: Thursday, 18 June 2020 at 10:52

Hello,

I'm currently working on adding SMuFL compliance to GNU LilyPond as a Google Summer of Code project. However, SMuFL's published specification and the example fonts left me unsure about a few things. Here's a list for now; I may have more later.

  1.  I noticed that, while Bravura has many alternate and ligature lookups in its GSUB table, Petaluma has none. Both, however, include JSON files with stylistic alternates and ligatures. Is it reasonable for a SMuFL-compliant program to assume that the JSON metadata file includes everything that might also be specified through OpenType features? (In other words: can we drop OpenType support without risking missing any font features?)
  2.  From what I can tell in the Bravura font, the stylistic alternates are spread across 'ssXX' subtables, and then only those that aren't part of a styleset are placed in the 'salt' subtable. So, when a stylistic alternate is recommended, for example E0A0.salt01, what significance does the number 01 have? Does it only determine the orders of alternates in the JSON files?
  3.  (This one depends on the previous question, I suppose.) Emmentaler, LilyPond's default font, which I plan to convert to SMuFL, has a very different set of alternates from either Bravura or Petaluma. Must I stick to the recommended 'salt' number for a particular glyph's alternate (e.g. salt03) if it's in the specification, even if Emmentaler doesn't have versions of the glyph's lower numbered recommended alternates (e.g. salt02, salt01)?
  4.  The specification for the "glyphsWithAlternates" JSON object states that "Font designers are encouraged to use a consistent naming scheme for alternates." Does this mean consistent within the font, or consistent within the entire corpus of SMuFL-compliant fonts?
  5.  The SMuFL specification recommends creating two versions of a music font, one for scoring and another for text. Would it be acceptable to package these two fonts under an OpenType Collection to avoid file clutter?
  6.  In LilyPond's current in-house font format, some .scm metadata files are embedded as generic TTF/OTF tables, providing an easy way to bundle a text-based file in a low-level readable format. Is it acceptable to embed the JSON metadata file in that sort of table to avoid file clutter? (Or might that option at least be explored in future revisions of SMuFL?)
Thank you in advance for your help,
Owen Lamb

Product Marketing Manager
Phone: +44 20 3696 1811

Steinberg Media Technologies GmbH
Beim Strohhause 31, 20097 Hamburg, Germany

President: Andreas Stelling | Managing Directors: Masahiro Ikeda, Jun Nishimura
Registration Court: Hamburg HR B 86 534 | VAT ID: DE118677139

Visit the Steinberg website<http://www.steinberg.net> or connect with us on Facebook<http://www.facebook.com/Steinberg>, Twitter<http://twitter.com/steinbergmedia>, Instagram<http://www.instagram.com/steinbergmedia> and SoundCloud<http://www.soundcloud.com/steinbergmedia>.
Watch our Cubase<https://www.youtube.com/cubase>, Dorico<https://www.youtube.com/dorico>, Mobile Apps<https://www.youtube.com/mobile_apps_steinberg>, Nuendo<https://www.youtube.com/nuendo>, Steinberg<https://www.youtube.com/user/SteinbergSoftware>, Audio Interfaces<https://www.youtube.com/audiointerfaces>, VST Instruments & Plug-Ins<https://www.youtube.com/VSTinstrumentsplugins> and WaveLab<https://www.youtube.com/WaveLab> videos on YouTube.