[smufl-discuss] Re: Private use area?

[Grzegorz Rolek]

Emil B. Wojtacki wrote:

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

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? Because as I understand things,
neither Unicode nor SMuFL don't encode characters in context, only the
characters themselves.

> - 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, both technically and historically (following the
  metal-era founts of type),

* 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.

Microsoft is experimenting with linking separate font files by a custom
size-range entry [1]. Fonts that do have their size-specific variants
ready are switched if needed, fonts that don't are scaled as usual.
Maybe a similar linking should be provided within the metadata in SMuFL.

Daniel Spreadbury wrote:

> A number of different solutions are possible without arbitrarily
> assigning clef changes special status (...)

Fair enough. Bravura's use of the stylistic sets that OpenType spec's
reserved for type designers to use, is really just a more convenient
variant on the separate fonts path, but as any other, it's still just an
intermediate solution in lack of a proper one, sort of like the use of
Unicode's PUA by SMuFL.

Regards,
Grzegorz Rolek

[1] http://typedrawers.com/discussion/comment/6251/


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