[smufl-discuss] Re: Private use area?

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

[smufl-discuss] Re: Private use area?

Emil B. Wojtacki
Grzegorz Rolek wrote:
> I don't want to open another can of worms, espacially that I'm no
> expert in standard notation, but I have to ask: Isn't the clef change
> just a presentational aspect of a regular clef, one that depends
> solely on context? In other words, aren't there no other functional
> differences between the two except they being scaled differently
> depending where exactly they're placed in the score?

Well, I would say rather, that the "regular clef" is an "initial
variant" of a changing clef, i.e. a kind of flag, or reminder.
E.g. a lot of clef changes from bass to tenor clef may occur in bassoon
part; and it is clef changes that have real meaning (they define the
textual content of the score -- you cannot omit them, even if you
engrave the whole piece as a single system on a long ribbon). Similarly,
if the bassoon part is quoted as a cue, clef changes may be included (or
adjusted, at engraver's/editor's discretion).

> Because as I understand things, neither Unicode nor SMuFL don't encode
> characters in context, only the characters themselves.

I think the difference between full-sized clefs and change-sized clefs
is similar to initial and middle letterforms in Arabic. Now, Unicode
does encode all four variants of Arabic letters. I know they are in
Unicode from legacy encodings and Initial/final letterforms are
currently supposed to be substituted automatically via OpenType or
similar mechanisms. However, it is possible for rendering devices to
perform glyph substitutions for Arabic, since typesetting relies on text
strings. But engraving does not. Scoring applications engrave music by
outputting single characters at different positions, not by outputting
text strings (except for textual annotations, like tempi or lyrics).
This is a way of thinking similar to manual engraving, like with steel
punches in plates from tin and lead. One punch, one character, one
codepoint. And contextual glyph variants cannot be substituted
automatically by rendering device (no text strings = no context), they
must be picked explicitly by an application.

There are even ligatures encoded in SMuFL at explicit codepoints
(dynamic symbols pppp-ffff). And they are there, because of the existing
practice of scoring apps: one symbol, one codepoint. It may seem awkward
for someone who had to deal with complex scripts. But still: scoring
apps normally do not output music as text strings. They do output  sets
of characters. A font layout for scoring apps must have this issue in
its scope.

>> - 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.
> This whole issue reminds me of a problem of 'optical sizes' as we know
> it from the type industry. It's a well established practice among type
> founders to distribute different optical sizes of their typefaces as
> separate font files, exactly because:
>
> * such more or less parallel glyph sets fall quite naturally into
>    separate fonts, ...
>
> * no mainstream font subsystem supports any of the optical sizing
>    mechanisms implemented as a single font file (the technology itself
>    did exist from both Adobe and Apple, but they were made obsolete).
>
> In publishing in general, optical sizing is one of the finest features
> of typesetting these days, and it's being done simply by selecting
> different font, by hand. Not very convienient for clef changes etc., but
> here the app should be able to at least do it automatically.
Thank you for posting that.
In engraving, this can work for different staff sizes (obviously). And,
in fact, it is not necessarily good solution for clef changes.

Maybe clef changes are similar to ordinal indicators (º, ª): one does
not change font, just uses the encoded symbol (for some languages, like
Italian) or alternate glyphs (other languages, like French). For scoring
apps, fixed code points are simply much more convenient.
By the way: font designer may wish to adjust the shape of changing clef
precisely on the staff lines. Therefore, clef change may vary slightly
in shape from the corresponding 'optically-sized' clef. In other words,
one may draw the C-clef slightly different, if it is crossed by five or
by four straff lines.

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