[smufl-discuss] Re: Glyph Registration and Graphical Metadata

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

[smufl-discuss] Re: Glyph Registration and Graphical Metadata

Emil B. Wojtacki
W dniu 31-05-2013 06.18, Mark Johnson pisze:
> David sed:
>> (b) They're very quick for font designers to produce - just copy the main one and
>> change size to 75% or whatever.
> That is exactly why there is no point in multiple-encoding them!

Well, as an engraver I’d like to say, that in some fonts they should
have a slightly adjusted shape or stroke contrast. And I use not a
strict 75% scaling, but a range of 66–80%, depending on the shape of the
clef (and function, because I also use slightly smaller clef-changes for
cues than for the played music).

> If
> you want scaled glyphs, it's cheaper and SO much less confusing to
> just use the font in a different size the way current software has
> been doing for decades. To me the whole point of having smaller
> change-clefs as alternate glyphs is so they can be designed, like
> small caps, with strokes comparable to the full-size glyphs, not
> merely scaled.
>
> A clef change has the same function as a clef on the
> left side: setting the pitch on the staff.

I think the clef change is more important, as it is clef _change_ that
defines the pitches (clef changes are something, that can be referred as
_charater_ to, in terms of Unicode). The clefs on consecutive staves are
just a kind of flags or reminders (and you never put a clef change at
the start of system, always at the end of previous one; in some music,
you don’t draw a clef on consecutive staves).
The very first clef can be considered just as the initial form of a clef
change.

> Capital and lowercase
> letters have many different functions, one of which is semantic
> distinction (the others are typographical). And where Unicode has
> small cap letters as separate codepoints, they are for non-alphabetic
> functions – IPA and other phonetic extensions.
>
> Having separate glyphs for clef sizes is part of the larger issue of
> optical sizing. Large OpenType families nowadays have 3 or 4 optical
> sizes as separate fonts. As far as I know there is still not a
> standard automated method of choosing appropriate optical sizes.

And, as I suppose, there never will be one (at least well working one).
There were attempts by Adobe (Multiple Masters fonts, or OpenType 'size'
feature), but automatic substitution is confusing for users. And for
some purposes (printing technique, kind of paper) it is sometimes more
than desirable to utilise a version of the font designed for other size.
When it is done automatically, you loose some of flexibility.


> I want SMuFL to set (or at least suggest) a standard method for optical
> sizing in music (and of course the new software to the be the first to
> implement it). This is why we must define the character set right the
> first time. Style alternates vs. more codepoints = vertical vs.
> horizontal; I'm for the former.

The most convenient way, I think, is to suggest, that stylistic sets,
say 10-20,  contain variants for different rastral sizes, if the font
has only one version. But even then, one can imagine that in cello part
of a string quartet, the bowing signs in cue-staff are not scaled but
set in the full size, because this can be the information of the crucial
importance for a player (because of synchronisation). Automatic
substitution could make it more difficult (if you draw a sign designed
for a smaller size, i.e. with less contrast and thicker strokes, resized
up, then it gets something too thick, and it can be time consuming to
engraver to do it on a proper way).

E.W.

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