[smufl-discuss] Re: Private use area?

[Emil B. Wojtacki]

Alex wrote:

> ... Just like David I think that omitting a dedicated set of smaller
> clefs for this purpose would be a grave mistake. ...
>
> Not providing at least an opportunity (like as a stylistic
> alternative) to have dedicated clef change symbols is also a
> short-sighted snub to font designers: anyone trying to create a font
> that provides a unified typographical approach is denied control over
> a vital aspect of appearance. Keep in mind that we are not talking
> about some obscure special symbol. Clef changes belong to the basic
> grammar of Standard Notation. How is a designer to accomplish a
> consistent and harmonious typographic concept while having no fine
> control over glyph size for a completely common-place use case?

I second that.

Additionally, in some output conditions, there is sometimes an issue
with scaled objects, which appear too thin. For instance, at some staff
sizes and resolutions, the width of the hair stroke of a treble clef is
rendered with two pixels line, whereas a scaled clef (at clef change,
75%) has its hair stroke rendered with just one pixel line (way too
thin). This should be avoided, and including the glyphs for changing
clef is the most elegant solution. (if you try to address this issue
with hinting, there is always some size/resolution, for which it will
not work).
Think about handwritten fonts: type designer or engraver may wish clefs
and clef changes to have exactly the same stroke width -- as if they
were written using the same pen. Other thing is to avoid white wedges
between clef's strokes and stafflines (as they are avoided between beams
and stafflines). Again, most elegant solution is to have different glyph
for clef change.

It could be addressed with OpenType. Ideally, glyphs for clef changes
should be available under a dedicated OpenType feature (like 'cfcg', by
analogy to small caps or superiors/inferiors). However, since there is
currently no scheme for handling open type alternates within apps,
separate code points are better.

My suggestion is to encode:
- changing G-clef
- changing C-clef
- changing F-clef
- control character 'changing clef' (this is to avoid duplicating all
the clefs, while enabling to use dedicated glyphs e.g. for clefs with
ottava bassa, as sometimes seen in double bass parts).

Please note that there are two kinds of arguments supporting assigning
slots for these glyph:
- the first is technical, as brought up by David. But it is not about
the handling fonts by app, it is more about the logical representation
of written music in the process of drawing it with computer. This kind
of arguments includes usage of clef changes glyphs within in text
applications.
- the second kind is related purely to graphical representation of
music, to engraving. It's simple: one cannot achieve finest possible
engraving without separate glyphs for clef changes.

These two kinds of arguments are perfectly in accord with one another in
this case. Many of the symbols included in SMuFL has supporting
arguments from only one of these kinds. Therefore, including the four
characters in SMuFL is at least justifiable, I think. On the other hand,
omitting them may seem to be inconsistent with its goals, at least as
some of us appear to understand them.

Emil


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