[smufl-discuss] Re: Proposing the removal of the wind fingering charts ranges from SMuFL 1.0

[Michael Scott Cuthbert]

Dear Daniel,

I’m sympathetic to the needs of Steinberg and other notation developers and can’t begin to say I understand the problems that zero-width fonts in your applications. However, I do know that there are dozens of wind fingering chart fonts out there (I’ve myself made one for clarinet fingerings) and it would be amazing to be able to switch one for another without needing to retype lots of examples.  The amount of effort in making the specification is to be applauded and it would be terrible to have this disappear.  You note that “Bravura is likely to be used in scenarios where the precise horizontal and vertical positioning and measurement of glyphs is critical,” but not every use of SMuFL (or indeed Unicode) is likely to be that.

My proposal is to keep these ranges but put a note in that actual implementation of these code points in a font that needs to have precise positioning is impossible with current font technologies. Then omit them from Bravura — as you’ve noted, a font does not need to implement every glyph or every ligature pair in SMuFL to be SMuFL compliant. I know that the goal of Bravura was to be a font that has every one of them, and it’s a noble goal. But I think that it would be better to have the system in place for a time when font technology makes this possible and not have Bravura implement them.  (or perhaps any font? But I know I’ve got reasonable results with my font and would rather have the code points and occasionally have pixel-level artifacts than not have any system at all).

A system, however, could use the code points to encode precise fingerings in a translatable manner and then render the code points in a different way than using fonts.

SMuFL and the Unicode-code pages that we hope eventually come out of it will be with us for the long-haul. That’s one of the greatest assets of the proposal. But it also gives an obligation not to omit a musically important set of glyphs from the specification because they’re too hard to render in a current font. I would rather have them be blank spaces in Bravura (just as I believe “Daesian Music Notation” will be in SMuFL compatible versions of many fonts out there) than not have them at all.

Steinberg may decide that a separate font just for the rendering of glyphs with zero-width characters needed is the better way to use the work that has already gone into this than throwing it away.  I would welcome it.

Thanks for asking for community feedback on this matter.

Best,
Myke

(p.s. — wanted to share the happy news that I recently received tenure at MIT in musicology; so it is possible that creative technical work can be rewarded).



On May 27, 2014, at 5:40, Daniel Spreadbury <[hidden email]> wrote:

> Dear community,
>
> Further to my last message concerning the current state of progress
> towards 1.0, the remaining issue concerns zero-width characters, i.e.
> characters that have an advance width of zero. The tl:dr version is that I
> propose removing the wind fingering charts ranges from SMuFL in order to
> eliminate the use of zero-width characters (likewise removing them from
> Bravura and instead releasing them as a separate font under the SIL Open
> Font License), and ask that any strong objections or counter-proposals are
> made before this Friday, 30 May. Please do read on for the full story,
> however.
>
> Advance width is the amount by which the input caret advances when you
> enter a character in e.g. a text editor or a word processor; normally, the
> full horizontal width of a glyph as measured from its origin to the origin
> of the next glyph on the line, including the side bearings on both sides.
> Having an advance width of zero allows glyphs to be overprinted when they
> are entered successively in a run of text. This is very useful for some
> applications: for example, Bravura Text makes use of zero-width characters
> to allow staff lines to be drawn behind notes and other musical symbols.
>
> Using zero-width glyphs can cause problems in different situations,
> because their behaviour tends to vary by application, operating system and
> drawing/shaping API. The use of zero-width glyphs is practically
> unavoidable in Bravura Text (because of the requirement for overprinting
> described above), but for Bravura it would definitely be desirable to
> eliminate their use. Bravura is likely to be used in scenarios where the
> precise horizontal and vertical positioning and measurement of glyphs is
> critical, so it is definitely preferable to have glyphs that render
> reliably in as many contexts as possible.
>
> Bravura 0.9 currently uses zero-width characters in the following
> situations:
>
> 1. Control characters with empty paths (e.g. timeSigNumerator,
> staffPosRaise1, controlBeginTie).
> 2. Percussion beater glyphs tilted leftwards (e.g.
> pictBeaterSoftXylophoneLeft and its ilk).
> 3. Certain characters in the 'Beamed groups of notes' range (e.g.
> textCont8thBeamShortStem).
> 4. The ligated time signature digits positioned to be the numerator of a
> time signature (e.g. timeSig4Numerator, at code point F54D).
> 5. All of the glyphs in the wind fingering chart ranges.
>
> Taking each of these use cases in turn, #1 presents no real problem:
> control characters aren't designed to print anything anyway, so having an
> empty, zero-width glyph is acceptable.
>
> For #2 and #4, it's possible to achieve the same results through judicious
> use of pair kerning. The intended use of the left-tilted beaters is to be
> overlapped with the right-tilted beater, to show which beaters should be
> held by a player. To achieve this result using pair kerning, the
> left-tilted beater can have its regular advance width, and when used
> adjacent (either before or after) the right-tilted beater, the pair can be
> kerned such that they overlap as intended. Likewise, for the time
> signature digits, when the appropriate pair of glyphs appears (e.g.
> timeSig4Numerator followed immediately by timeSig4Denominator), the pair
> kerning can be set such that the second glyph is kerned leftwards to the
> point that it sits directly underneath the first glyph.
>
> For #3 it's more complicated, because it's useful to be able to have a
> zero-width character, like the above-mentioned textCont8thBeamShortStem,
> and either use a space character to advance or put another glyph at the
> same position, e.g. a rhythm dot, to make a dotted 8th-16th figure, or
> whatever. To achieve good results with kerning will require around 400
> kerning pairs to be defined, but it's within the realms of practicality to
> achieve this.
>
> However, eliminating zero-width characters from the wind fingering charts
> (#5) really seems to be a non-starter. Each fingering chart contains
> dozens of glyphs, which could be typed in any order, which means that the
> kerning pairs required to ensure that the filled or half-filled glyphs are
> correctly registered with the blank fingering chart will number into the
> thousands. Using zero-width characters really is the simplest way to
> achieve the right result, and unfortunately even making the advance width
> of each glyph 1 du won't produce good results when that 1 du "rounding
> error" in registration is multiplied out over a dozen or so glyphs in a
> single completed fingering chart. It is possible that there is another
> advanced glyph substitution or glyph positioning feature tied to a
> particular font technology (OpenType or AAT) that would provide a solution
> to this problem, but in general we are trying to avoid the use of
> font-technology-specific solutions to these kinds of problems in SMuFL.
> (Pair kerning, by contrast, seems to be common to enough font formats etc.
> to be possible to recommend.)
>
> My proposal therefore is the following:
>
> 1. Specify that SMuFL-compliant fonts intended for use in scoring
> applications should only use zero-width glyphs for control characters.
> 2. Recommend the use of pair kerning to achieve overprinting effects for
> beaters, ligated time signatures, and beamed groups of precomposed notes
> set in a run of text.
> 3. Eliminate the wind fingering charts from SMuFL, since it is not in
> general possible to achieve the correct result without the use of
> zero-width characters.
>
> Although the wind fingering chart ranges would be eliminated from SMuFL,
> the work done on them would not be wasted: I would release a separate font
> containing those glyphs, together with documentation for how to use them,
> under the SIL Open Font License so that they can be used by anybody
> interested in using them.
>
> Unless there are strong objections expressed before this Friday, 30 May,
> to the above proposal, I will go ahead with this plan for SMuFL 1.0.
>
> Daniel
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 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]>
>

---                                                             ---
Michael Scott Cuthbert

Homer A. Burnell Career Development Professor, MIT
Associate Professor of Music                     [phone]
[hidden email]                           http://www.trecento.com





#############################################################
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]>