[smufl-discuss] Re: Some additions and other suggestions

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[smufl-discuss] Re: Some additions and other suggestions

dspreadbury
Administrator
Emil wrote:

> I don't think it is a good idea to move the ornament strokes into the
> multi-segments lines range.

I am open to revising the existing ornaments range into a series of
smaller sub-ranges, and to reviewing the use of pre-composed "cadences" in
favour of a greater variety of strokes, a la Perry's existing strokes. I
will give this some more thought.

> >> 4.Creating a new range for vertical positioning of noteheads in
running
> >> text (16 may be not enough, so I suggest 32)
> > I'm not sure about this, or the use of further control characters in
> > general. I haven't ruled out adding this range, but nor have I added
it in
> > 0.5.
>
> It is about the usage in running text, but also (at least to some
> extent) about the compatibility with existing solutions.

Perhaps I might be more persuaded if I knew more about the existing
solutions you mention: could you tell me more about them, or point me in
the right direction? Which existing fonts/applications are using this kind
of technique?

> >> 5.In the figured bass range, the name for digit five with slash may
be
> >> misleading. I think the simple names like “Figured bass digit five
with
> >> slash” would be better. I also suggest to add two combining
characters
> >> for alterations: rising stroke and backslash (for diminished
> > fifth/twelfth).
> >
> > I have added these suggested combining characters in SMuFL 0.5.
>
> Thank you. I would like to maintain the suggestion to rename the fifth
> with backslash: the symbol is not necessarily a raised fifth, it is used

> (mostly?) for diminished fifth (even if there is no actual alteration).

I will revise the glyph description.

> [...]
> By the way: In the ornaments range, there are glyphs (oriscus, two
> quilismae -- what is actually the difference between them, and why they
> have names "3" and "4" while there is no "Quilisma 1"?) that seem to be
> used solely for transcription of gregorian chant. Perhaps it would make
> sense to move them to the Gregorian Chant range (or creating a range for

> transcription of Gregorian Chant)? Additional glyphs for liquescentes in

> modern notation would be then helpful, too.

I think creating a range for the glyphs used in the transcription of
Gregorian chant is probably a good idea. I've made a note of this for
inclusion in a future update.

> [...]
> > - Small noteheads for grace notes (I'm still considering how best to
> > handle this requirement)
>
> There is an additional argument for including them: they are sometimes
> used for a detailed multiphonic notation (so it makes sense to have
> glyphs for semibreve and breve, too), like here:
> http://www.amuz.krakow.pl/docs/zych-bagatele-przyklad_nutowy.pdf (sx 2
> in bar 11 and the same sound in the last bar on the page).

I am still of the opinion that small noteheads should not be encoded at
explicit code points but rather as stylistic variants of the standard
noteheads, where needed. Otherwise we end up making arbitrary decisions
about which of the different notehead shapes encoded at explicit code
points are worthy of being encoded again at a smaller size. And scoring
applications can very easily render noteheads at different sizes in just
the same way they can render clefs at different sizes.

> [...]
> And still, I kindly ask you to add codepoints for control characters for

> placing accidentals above/below ornament and accidentals for ornaments.
> I am sure, that at least some application developers (independent form
> Uniscribe) will find it very useful (with a well-designed font one can
> let the font shaping engine to make the job of placing the accidentals,
> so just a single text object is required for a "double-altered" turn;
> this, in turn, can simplify the implementation of correct behaviour when

> transposing music containing ornaments with accidentals).

I wonder whether the use of ligatures, as opposed to control characters
and OpenType anchor points, might be an alternative approach that is more
widely supported by text APIs and applications? I.e. a similar approach to
that taken for the wide variety of transposing G clefs that you proposed
earlier on.

Daniel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net
Managing Director: Andreas Stelling, Kazunori Kobayashi
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]>