[smufl-discuss] Re: Discussing Unicode and encoding dilemmas

[David Webber]

From: Grzegorz Rolek

> Unicode indeed has in its repertory characters that are merely glyph
> alternates, or that are redundant in front of combining characters and the
> like, but those were added in the early days only to allow texts encoded
> in the legacy character sets to be transcoded into Unicode without a loss
> and their use is now discouraged.

Yes.  My understanding is that this applies to ligatures in combinations
like "fi"  "ae"  "oe" (to quote Latin script examples) and that further
single characters to replace any given joined pair, will not be introduced.

>Combining characters with multitude of their properties and related control
>points can be quite expressive, but also overused easily. Please let's take
>these into account when discussing things like stacks of bass figures or
>chord clusters. Exactly how they work and how they could be used, or
>misused, is clearly described in the Standard.<

> Size of any particular character without a difference in its semantics
> shouldn't matter in Unicode. If a clef bears a single meaning, that is, it
> simply sets a pitch reference on staff, then there's no reason why a clef
> in the middle of the line should be encoded separately. Unicode does not
> deal with contexts in which characters are used. If it's made smaller
> in-line only to fit it nicely within the reading flow, then this should be
> handled with a font feature or other higher-level implementation. That's
> unless, of course, the semantics indeed are different.<

My argument is that for clef changes, the semantics *are* very different.
The larger version of the clef goes at the start of line and always at the
start of lines.  On the first line it initialises the clef; on further lines
it is merely a reminder of the clef in force.   A clef symbol elsewhere on a
line is always a clef *change*, and is always the smaller version, with
unique meaning that the clef is no longer what it was.

As I've said, arguing for a font with missing clef changes, is like arguing
for one with a missing lower case s.  [I fact I'd argue that the semantic
difference between clefs and clef changes, is significantly greater, than
between an upper and lower case s.]

> I really encourage anyone interested in Unicode to read the core
> specification linked above, because it's very informative in how Unicode
> works in its entirety across different writing systems, what can be
> achieved with its current implementation, and how to think about future
> encodings.<

Indeed.

And in doing so the differences between music and text may become clearer.
One of the differences between music notation and 'writing systems' (at the
basic level - ie thinking about text rather than superscripts and
subscripts, and the principal music lines rather than cues) is that the
music symbols have various vertical and horizontal displacement from one
another.

Let me get off the abstract plane and discuss how the font symbols are
likely to be applied to the paper.

Mozart uses (and I assume other programs do) text drawing APIs to go from
the font to printed music, so it will do (schematically)

locate point for symbols
TextOut( "<symbol1><symbol2>...<symbol_n>");

where the <symbol> are the character code points.  [I'm using a windows API
name - but please think of it as generic.]

Some strings of symbols - eg "sfz" will be printed along a line, and kerning
(and maybe sometimes ligatures, but more likely diglyphs) can be employed.

But most often the 'string' of symbols will constitute just one symbol, eg a
clef, or a note, as each will tend to be positioned individually on the
basis of variable data stored in the file - not a fixed positional
relationship with the previous symbol.  Also the text drawing routines will
be interspersed with line drawing routines (as recommended by SMuFL) eg

locate point for note
TextOut("<note-head>")
locate ends of stem
DrawLine( stem )
locate point for tail flag
TextOut("<tail flag>")

though of curse it doesn't have to be done in that order.   If the stems
were always the same length, then it might be done more economically with
the connecting symbols, but they aren't.

The question is: if music drawing is essentially a sequence of drawing
single symbols at carefully computed positions, what is a 'font'?   (In the
traditional very general sense of the word.)  It has to be a collection of
characters from which one can draw the music.  And that means drawing each
symbol in the music from the font.   Not drawing almost all of the symbols
from the font but having one or two 'missing ones' (like a clef change)
where you have to go to another font (even from the same font family in
another size or style) to get it.

Following this argument leads me to believe that there will be very little
demand for ligatures and diglyphs in a music font.   The combining
note-heads and flags are for use in text rather than in music (as the SMuFL
spec notes) and I think there will be very little demand for
combining-symbols (the things shown with dotted circles), in actual music,
too.

[Even such simple common combinations as note+dot are far from trivial: the
dot can be in line with the note, raised slightly or lowered slightly
according to context.  And that context is surely for the music software
rather than the font to work out.]

My conclusions are (1) that simple will be best, and by far the most widely
applicable;  (2) that external metadata, of the sort discussed by Joe, will
ultimately be crucial to determine the geometric relationships, whatever
else you do.

Dave

David Webber
Mozart Music Software
http://www.mozart.co.uk/











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


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