[smufl-discuss] Re: Additional Glyphs

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

[smufl-discuss] Re: Additional Glyphs

dspreadbury
Administrator
Mark wrote:

> For example, I would like to see
> room for  at least three styles of clefs and noteheads. Clefs and
> noteheads, more than other elements in a music font, help to define the
> overall look of a document. Inclusion of several styles of noteheads and
> clefs would allow users to easily create their own style.  In our
> instance, for example, users could easily switch between standard
Maestro
> noteheads, MaestroWide noteheads, or a third style of notehead.

My proposal for how we should handle this is through the use of stylistic
alternates. For a given glyph, e.g. the normal black notehead used by
quarter notes and shorter durations, there is a single codepoint (U+E0B6,
glyph name uniE0B6), and then fonts are free to provide as many
alternatives for this as they wish (using names like uniE0B6.salt01,
uniE0B6.salt02, etc.). Some previous discussion on the list has suggested
that for ease of access by a wide range of APIs, these alternate glyphs
should also be given explicit codepoints, and my suggestion for this is to
set aside a suitable capacious range somewhere in the PUA and allow these
codepoints to be used privately by each font developer as they see fit
(since we can't predict how many alternates might be needed, or which
glyphs will and will not have alternates in a given font).

> Repeats: add the stylized coda sign favored in Japanese music fonts.

Yes, probably a good idea. There is likewise a stylised segno that is
rotated clockwise compared to the normal appearance. My suggestion would
be to make these stylistic alternates, since they are simply alternative
appearances for the same symbol and hence shouldn't get their own
codepoints.

> Clefs: In addition to adding several variations of clefs noted above,
for
> TAB clefs, I would suggest including both serif and non-serif versions,
> both with bold and non-bold options. All of these options are in fairly
> common use.

I'm agree here, too, though I think these too should be implemented as
stylistic alternates. In fact, I think I should probably remove the "tall"
versions of the 6-string and 4-string clefs as currently encoded and move
those, too, to stylistic alternates (since they are the same symbol, just
different appearances).

> Noteheads: add several more variations for x noteheads, circle x
> noteheads, and diamond noteheads. These are used in many different
genres;
> the diamond notehead favored by handbell choirs for hand chimes is
> definitely not the same as the diamond notehead favored by guitarists
for
> harmonics, which may or may not be the same as the diamond notehead
> favored by percussionists.

If we can enumerate the different e.g. diamond noteheads that have
different purposes and different appearances, we should definitely include
them. Perhaps you could post up a picture somewhere (since you can't
attach anything to the list directly, alas) with your proposal?

> Note Clusters: add combining glyphs that enable users to create clusters
> of any size. Both square and rounded versions could be included.

This has already been mentioned, I think, but it feels like including a
large number of glyphs to construct clusters is the same kind of "hack" as
would be needed to make it possible to render chord symbols or Roman
numerals in their full generality, and perhaps it's not the right place to
encode this?

If we do as a group find it necessary, how do we constrain "any size",
because I'm not sure how we could actually make the size completely free?

> Notes: add a whole note notehead that uses single line wings, as is
> commonly used in modern chant notation. I would also add square breve
and
> double breve characters to this category.

The single-vertical line vs. double-vertical line double whole notehead
should be a stylistic alternate, I think, since it is the same symbol as
the version with two vertical lines.

> Tremolos: include a 4-line tremolo, we are asked for this character from
> time to time and see it in use in a number of scores we have developed
for
> SmartMusic.

This could be added, but if we're going to add 4-line tremolos we should
probably add at least 5-line tremolos as well. I imagine that most scoring
applications will choose to create these either by drawing primitives
(since they can be drawn in a similar fashion to beams) or by repeating
the 1-line tremolo at an appropriate vertical interval (since this allows
the interval to be varied).

> Flags: add a few variations on the 8th flag and internal combing flag
> glyphs. I would also suggest including characters that can be used as
> angled straight flags, like those used in old Boosey scores.

Yes, I agree about straight flags. My sense is that these could be added
as stylistic alternates for all of the existing flags, up to 512th note
for both stem up and stem down notes.

> Accidentals: I would suggest supporting several more systems of
microtonal
> notation along with the inclusion of some more old style notation
> standards, i.e. a double sharp made up of two sharps and a triple sharp
> and triple flat.

By all means propose new ranges of microtonal accidentals and we can add
them. I've already got the AEU scheme used by Turkish and Arabic maqam,
and I have seen a number of other schemes (e.g. Marc Sabat's Extended
Helmholtz-Ellis JI Pitch Notation, Sagittal, etc.). If we can agree on
which schemes to include, I'm very happy to include them.

> Rests: add left and right characters that combine with a numeral to form
a
> multi-measure. These are commonly created as text items and used at page
> turns.

No problem.

> Dynamics: I would strongly recommend including the full range of
> characters from fortissississimo on down. The fs used to form a
> fortississimo are not necessarily the same as an f used to form a forte.
> In some fonts, when combining several fs or ps, weight is taken out of
the
> body of the individual characters in order to achieve a more elegant,
less
> chunky look.

My suggestion here is that "ff" etc. should be encoded as ligatures, e.g.
a glyph named uniE202_uniE202 would be the ligature for "ff", which could
also then be encoded at a separate explicit (private) codepoint if
required by the consuming software.

> Ornaments: add trills combined with accidentals. I would also suggest
> leaving much more room for more types of mordents.

We could encode trills with sharp, flat and natural above. Are double
flats and double sharps needed? What about microtonal accidentals?

If you have concrete proposals for more types of mordents, please share
them.

> Brass Techniques: I would suggest leaving several open slots after each
> symbol. I imagine that this standard would also accommodate handwritten
> fonts like Jazz. Handwritten fonts typically have many variations of
each
> of these techniques.

Yes, I've been exploring this a little bit over the last few days myself.
I am not sure whether a "long fall" should be encoded separately to a
"short fall", for example. Perhaps it should.

> Wind techniques: Maybe not the best place to put them, but I would
include
> characters with two, three, and four dots, sans the slur.

What is the meaning of these symbols? Is this to suggest tonguing
individual notes in a measured tremolo, or something else?

> Tuned Mallets: add a blank zero-width trapezoid allowing users to create
> variations on the abbreviations or use a different text font if desired.

This seems reasonable.

> Bells: add a handbell pictogram.

Do you have an example?

> Cymbals: add a Chinese cymbal pictogram.

Again, do you have an example?

> Percussion Technique: I'd suggest adding a larger variety of dovetailing
> line symbols. These should include small and large circular motion
> segments, both above and below, various waveforms and characters that
can
> be combined and used as scribbles. All are common to modern percussion
> notation.

If you have concrete proposals to share, that's great.

> Handbells: add variations on the J echo and gyro. My discussions with
the
> English Handbell Ringers Association indicate that some of their
engravers
> prefer the light version of these glyphs, like you have in Bravura,
while
> others prefer a much thicker version. There are several other characters
> missing from this category.

Please provide details of the missing characters, and I can add them.

In terms of lighter versions of the included characters, they can be
handled by way of stylistic alternates.

> Guitar: include enclosed string numbers with serifs to accompany the
> san-serif version.

Again an ideal use of stylistic alternates.

> I would suggest a category for shape-notes. While these noteheads are
> similar to the geometric noteheads found in Noteheads, they typically
are
> heavier and more stylized in dedicated shape-note fonts.

Okay, though as far as I know many of the shaped noteheads in the existing
range are only ever used for shape note music, so I would be wary of
unnecessary duplication. Perhaps it would be more correct to embolden or
modify some of the shapes in the existing range instead?

> Add many more brackets and braces, including double high parentheses and
> brackets to accommodate stacked chord symbols. I would also suggest
> creating spaces for the various types of text enclosures typically used
in
> handwritten fonts.

We've discussed chord symbols a little bit, and my feeling is that we
shouldn't try within a symbol font to include glyphs that are going to be
suitable in general for chord symbols, since there is so much variation in
how they appear. Creating parentheses (in particular) that would be a good
fit with an arbitrary text font used for chord symbols is challenging.

> I would suggest including a category dedicated to noteheads containing
> solfege abbreviations and note names similar to KidNotes and Finale
> AlphaNotes.

This could be done. If you can share a concrete proposal for the exact
glyphs needed, we can create a suitable range.

> A miscellaneous category should contain a do-not-copy glyph and some
> eyeglasses glyphs.

This has also been suggested to me. What is the ideal appearance of the
"do not copy" glyph, as far as you're concerned? I assume there are
alternative versions out there other than the Opus "photocopier"
pictogram.

> I'd also add accidentals to support Persian and Turkish notation.

I believe we have got the Turkish accidentals, at least of the AEU system,
covered; if you know of others that should be included, please share them
with me.

Thanks!

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