[smufl-discuss] Re: SMuFL 0.9 and Bravura 0.9 released

[Michael Scott Cuthbert]

The BravuraText font is going to be an INCREDIBLE contribution to the use of musical symbols within descriptive text, etc. I’ve been playing with it for the past hour and I can’t believe how much this font and the specification are going to change what I am able to work with with publishers, etc.  KUDOS! I think that even designers who think primarily about placement of symbols in score space will benefit immensely from being able to seamlessly integrate text and musical symbols

I do think it’s going to need another round of size tweaking before 1.0. The main criteria I’d consider is — what are the symbols that are likely to be used together (in which case the sizes should match) and what symbols are likely to be separate in a text environment (in which case, they should be scaled so that the largest of them takes up the full space).


Some of the things that I’ve noticed quickly (not complaining! At all! but figured you want to get this right…)
* Several of the dynamics (mostly involving fffs) have too much space after them.  Several are perfect.
* The dynamics are a tiny bit too large based on the x height of either Times New Roman or Adobe Garamond Pro — I think that the former is a good reference height (they’re too small w.r.t. a large lowercase font like Verdana).
* In general, I’d aim for less space after symbols than more.
* The <> hairpin symbols are a bit high — I’d prefer their start/end points to be x line aligned even if it means being a slight descender at the ends.  
* Some of the ornaments are rather small — if a person is discussing the use of a mordent, it will probably want to be bigger.
* Sost. is very small. Should be full height.
* Pedal marks (\uE65E-E660) could be aligned with capitals.
* Harp pedal diagrams can take advantage of the full space.
* Should accidentals be elevated above the baseline or not? When elevated, they look great in the context of Bb and C# but much less good on their own or in the context of bb and c# (as in a minor key specification) or on their own (this is a flat: b...).  I think that a default of baseline would be a bit better.
* Treble clef looks amazing at the scaled height.
* The percussion ideograms are rather small in look and actually have a height (empty space) that changes the line spacing in Word.
* Grouping symbols (E875-E878) should be smaller probably.
* Some things just won’t work without scaling — figurings, accordion registration, etc.  Can’t be helped. It’s amazing how much IS clear at 12pt!
* Most of the tweaks above I imagine might be automatically generateable from the Bravura font with a script? There are some that would be more work that might not be worth it.  For instance the Petrucci F clef (E904) would be much clearer if there was more space between the two component symbols.
* Mensural symbols would be better to scale so that the O matches the same height as a capital O.  E91B-E91F are lower than the preceding mensural symbols (problem in Bravura too?)
* Similarly E92A-F could be significantly bigger — in Ciconia I was able to make them clearer.
* Mensural symbols E950 - E961 would look better if they sat on the baseline. While E970-E98F would work better if they were higher (i.e., if the default start position were set so that the top of the glyph hit the x height).
* Chant symbols (E990ff) are much too small for using in text.
* Dasiaen notation has scaling problems and changes the line height. Could be scaled so it’s the same height as a capital F or I.
* Figured bass symbols are too small — either should match the number height of surrounding text or superscript/subscript size.  I’d vote for the former (so that I can say “The symbol [4slash] means that same as #4”). Font designers can create ligatures to stack them or users can use equation-editor, etc., if they’re planning on using chord symbols in text. (ideally, ligatures for the most common: 53, 63, 64, 65 etc. would be provided; but you have a lot to do).
* EAC0-EACA could be scaled so that the largest is O height.

Actually, I realized a visual example would be easier to follow; so I’ve continued with comments there.
https://dl.dropboxusercontent.com/u/21626762/bravuratext%20test1.pdf
https://dl.dropboxusercontent.com/u/21626762/bravuratext%20test1.docx

It’s really amazing — I hope that the examples make clear to designers who have questioned SMuFL’s applicability to text why some of us in that world are so excited about it.

Best,
Myke







On Apr 17, 2014, at 17:45, Daniel Spreadbury <[hidden email]> wrote:

> We are pleased to announce the release of SMuFL 0.9, which marks what we
> anticipate will be the final milestone on the way to a stable 1.0 release.
> As such, SMuFL 0.9 may be considered a release candidate for the final 1.0
> release.
>
> Since SMuFL 0.85, released in March, more than 200 new glyphs have been
> added, including four new ranges. A comprehensive review of LilyPond's
> Emmentaler font has led to the addition of many new glyphs, and survey of
> important instrumentation handbooks by Ertuğrul Sevsay (Bärenreiter, 2005)
> and Karl Peinkofer & Fritz Tannigel (Schott, 1976) have led to the
> addition of a number of new percussion pictograms. New ranges for Kodàly
> hand signs, Simplified Music Notation and lyrics also provide a good
> number of new glyphs. As always, a complete list of the changes and new
> glyphs is available in the version history:
>
> http://www.smufl.org/versionhistory
>
> Our hope is that no further glyphs will be added to SMuFL before version
> 1.0. The deadline to request new glyphs passed at the end of March, and
> since then the focus has been on completing the work relating to producing
> guidelines for SMuFL-compliant fonts intended for use with text
> applications, and the development of a reference font embodying these
> guidelines.
>
> A set of guidelines for SMuFL text fonts has been completed and can be
> found in the Notes for implementers section in the SMuFL 0.9
> specification. The Bravura 0.9 distribution now includes Bravura Text, a
> reference font for text-based applications, in addition to the existing
> Bravura font, a reference font for scoring applications. The distribution
> also includes a usage guide for Bravura Text, describing how to insert
> Unicode characters from the font into applications on Windows and OS X,
> and providing details of specific features of the font, such as the use of
> ligatures to allow hundreds of symbols (including noteheads, accidentals,
> articulations, etc.) to be displayed at multiple vertical positions.
>
> Bravura and Bravura Text are now supplied in Embedded OpenType (EOT)
> format, in addition to OpenType with PostScript outlines, WOFF and SVG.
>
> There have also been significant developments in the richness of the JSON
> metadata supplied, both at the level of SMuFL itself and in font-specific
> metadata. The SMuFL metadata distribution now includes a new ranges.json
> file, which provides information about the glyph ranges as they appear in
> the SMuFL specification. The glyphnames.json file has been enhanced to
> include the human-readable description for each glyph in addition to its
> canonical camel case name.
>
> The specification for font-specific metadata is significantly enriched,
> with new structures to help expose the repertoire of optional glyphs (in
> the range U+F400–U+FFFF) of a SMuFL-compliant font to applications,
> including descriptions of ligatures, stylistic alternates, and stylistic
> sets. Font-specific metadata may also include a bounding box for each
> glyph, which could in time help MakeMusic provide automatic Font
> Annotation (FAN) files for SMuFL-compliant fonts used in Finale.
>
> Full details of all of the improvements in these metadata files is found
> in the Notes for implementers section within the SMuFL specification.
>
> SMuFL 0.9 can be downloaded here:
>
> http://www.smufl.org/download
>
> Bravura 0.9 can be downloaded here:
>
> http://www.smufl.org/fonts
>
> With the release of SMuFL 0.9 there are no remaining known work items
> standing in the way of a stable 1.0 release. If you believe there is
> something significant that must be considered before SMuFL reaches version
> 1.0, please raise the issue with the community as soon as possible via the
> smufl-discuss mailing list.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
> Phone: [phone] | Fax: [phone] | www.steinberg.net
> President: Andreas Stelling | Managing Director: Hiroshi Sasaki, Hirofumi Osawa
> Registration Court: Hamburg HRB 86534
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list <[hidden email]>.
> To unsubscribe, E-mail to: <[hidden email]>
> To switch to the DIGEST mode, E-mail to <[hidden email]>
> To switch to the INDEX mode, E-mail to <[hidden email]>
> Send administrative queries to  <[hidden email]>
>

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>