[smufl-discuss] Re: Towards SMuFL 1.0

[Steven Horn]

I’ll send you some print outs (scanned) from unknown sources on lute notation this weekend. Currently visiting family and away from my resources.

On Jan 8, 2014, at 3:28 AM, Daniel Spreadbury <[hidden email]> wrote:

> Dear SMuFL community,
>
> I started work on SMuFL almost exactly a year ago, though at the time I
> didn't realise it. Steinberg's in-development scoring application needs
> music fonts, so I started to build one. Having worked on music fonts for
> another scoring application for many years and been hamstrung by retaining
> compatibility with third-party fonts that originated in the 1980s, and
> hence not being able to properly use Unicode and OpenType features, I
> quickly decided to make a clean break with the past, and not design our
> new fonts to be Sonata-like.
>
> As work progressed on designing the look of the font that would eventually
> come to be called Bravura, it became obvious that a new approach to
> organising the glyphs in the font would be needed. I shared my early
> thoughts on the standard with a handful of expert music engravers and
> editors in the following weeks, and it quickly became clear that more
> heads were better than one: this should really be a community effort, and
> it could conceivably provide a real, designed solution to the problem of
> using different fonts in different music software (rather than the
> imperfect *de facto* solution that had been in place since other font
> designers started copying Cleo Huggins' mnemonic glyph layout for Sonata).
>
> Progress to date
> ==========
> After announcing SMuFL at the Music Encoding Conference in Mainz in May of
> last year, it has been exciting to see the community start to take off. A
> few statistics:
>
> * There were around 800 recommended glyphs in the first public release
> (0.4) of SMuFL. The current version (0.7) defines more than 1850
> recommended glyphs, and hundreds more recommended ligatures and stylistic
> alternates.
> * More than a dozen subject area experts around the world have contributed
> to the selection of glyphs to be included in SMuFL to date.
> * There have been more than 330 messages on the SMuFL mailing list to
> date, and the list has more than 70 subscribers.
>
> SMuFL has also received support from software developers large and small.
> For example, the developers of MuseScore (www.musescore.org) have already
> started work on integrating it, and it is expected to be a part of the
> forthcoming MuseScore 2.0 release. I have also been contacted by several
> other developers, who have expressed their intention to support SMuFL in
> their applications.
>
> Our reference font, Bravura, has also been downloaded from our web site
> hundreds of times, and is already being used in the current versions of
> Rising Software's ear training and music theory applications, Auralia and
> Musition, on both Windows/Mac and iOS.
>
> If you are working on an implementation of SMuFL or are using Bravura in
> your software, please let me know, as I am very interested to track the
> progress of these projects.
>
> SMuFL 0.8
> ======
> As things stand, version 0.8 of SMuFL (and Bravura) currently includes the
> following changes since version 0.7:
>
> * Based on community feedback, added clarification that code points for
> glyphs may change until SMuFL reaches version 1.0, after which point
> existing code points will become immutable.
> * Glyphs in SMuFL encoded in the primary range of U+E000–U+F3FF are no
> longer considered “mandatory”, but rather they are “recommended”: in order
> to be considered SMuFL-compliant, a font need not implement every
> recommended glyph, just as a text font need not implement every Unicode
> code point in order to be considered Unicode-compliant. Fonts need only
> implement those glyphs that are appropriate for their intended use at the
> correct SMuFL code points in order to be considered SMuFL-compliant.
> * Changed guidelines for metrics of text-like glyphs (e.g. dynamics,
> D.C./D.S. markings in repeats) in fonts intended for use in scoring
> applications, such that it is recommended that the x-height of such glyphs
> is around 1 staff space (0.25 em).
> * Added Ivan Wyschnegradsky’s system of 72-EDO accidentals.
> * Added Britten’s curlew sign for a pause of an indeterminate length.
> * Added push/pull signs for accordion.
> * Added slashed sharp/flat accidentals used by John Tavener in his
> Byzantine-inspired choral works.
> * Added separate noteheads for white mensural notation.
> * Added quasi-random wiggly lines (wiggleRandom1, wiggleRandom2,
> wiggleRandom3, wiggleRandom4) to multi-segment lines range.
> * Added flipped and large versions of constant circular motion
> (wiggleCircularConstantFlipped, wiggleCircularConstantLarge,
> wiggleCircularConstantFlippedLarge) to multi-segment lines range.
> * Added combining top/middle/bottom segments for black and white
> rectangular note clusters.
> * Added 2, 3, 4 and 6-dot divisi indicators for measured tremolos
> (tremoloDivisiDots2, tremoloDivisiDots3, etc.) to tremolos range.
> * Added clavichord bebung glyphs for 2, 3, and 4 finger movements
> (keyboardBebung2DotsAbove, keyboardBebung3DotsBelow, etc.) to the keyboard
> techniques range.
> * Added double-height parentheses and brackets (csymParensLeftTall,
> csymParensRightTall, csymBracketLeftTall, csymBracketRightTall) to the
> chord symbols range.
> * Added recommendation for stylistic alternates for time signature digits
> 0–9 suitable for use as large time signatures shown above/between staves
> (timeSig0Large through timeSig9Large).
>
> Due to the nature of the additions, there are a substantial number of code
> point changes between SMuFL 0.7 and 0.8.
>
> Next steps
> =======
> The goal, then, is to release version 0.8, and then to reach version 1.0
> as soon as possible, so that the code points can be stabilised and
> developers can implement support for SMuFL with confidence. Per recent
> discussion in the community, once SMuFL reaches version 1.0, neither code
> points nor canonical glyph names for recommended glyphs will change.
>
> This means that if more glyphs remain to be added to a given range in
> future than unused code points remaining in that range, new non-contiguous
> ranges will have to be created elsewhere in the Private Use Area to
> accommodate these glyphs. (This is not really a problem, since ultimately
> the actual code point used for a given glyph is arbitrary, but for the
> sake of tidiness, if nothing else, it is appealing to group all
> generically similar glyphs together if possible.)
>
> In my view, the two things that stand in the way of reaching version 1.0
> are the following:
>
> * Implementing outstanding requests for glyphs to be included.
> To my knowledge, the only specific requests outstanding at present are
> from Mark Adler and Michael Good at MakeMusic, and SMuFL 0.8 will resolve
> those requests. There are a couple of non-specific outstanding issues
> (e.g. Maurizio Gavioli has expressed that perhaps there is more to be done
> in the area of Medieval and Renaissance notation, and Steven Horn has
> suggested that there may be more glyphs to add relating to lute notation
> and tablature), but otherwise at present there are no significant known
> omissions.
>
> * Creating glyph registration and metrics guidelines for fonts intended
> for use in text-based applications.
> To date I have focused on fonts intended for use in scoring applications,
> but I believe defining the guidelines for fonts intended for use in
> text-based applications should be completed (and a reference font
> produced) before SMuFL reaches version 1.0.
>
> I am interested to hear from the community whether anything else should be
> added to this list.
>
> Likewise, if anybody in the community is harbouring any requests for new
> glyphs or ranges of glyphs to be added, please do not delay in making
> those requests as soon as possible.
>
> And, of course, if anybody in the community would like to volunteer to
> assist with the definition of the design guidelines for fonts intended for
> use in text-based applications, that help would be greatly appreciated by
> me.
>
> My proposal is that I set a deadline (perhaps the end of March 2014, if
> that is not too soon) for the community to submit proposals for
> consideration for SMuFL 1.0, and then finalise the 1.0 release as soon as
> possible after that, though at the present time it's difficult to estimate
> how long that might take without knowledge of what proposals I might
> receive.
>
> Thanks once more to everybody in the community for their contributions to
> date. I am looking forward to reaching the milestone of a version 1.0
> release.
>
> Daniel
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
> Phone: [phone] | Fax: [phone] | www.steinberg.net
> President / Managing Director: Andreas Stelling
> Managing Director: Kazunori Kobayashi, Hiroshi Sasaki
> 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]>