Re: SMuFL clarifications

Hi Daniel,

Thank you so much! This clears a lot up. I'll let you know if I have more
questions.

--Owen

On Thu, Jun 18, 2020 at 5:05 AM Daniel Spreadbury <D.Spreadbury@steinberg.de>
wrote:

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