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

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

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

Grzegorz Rolek

On Jun 2, 2013, at 8:17 PM, David Webber wrote:

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

Please notice, that you still differentiate the two clefs by the context in which they appear, and this doesn't matter as far as Unicode is concerned. Take the context out, and the bare meaning of both clefs is one and the same: a given pitch reference.

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

This only underlines that context shouldn't be taken into account when encoding the clef.

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

David, I think you're missing one thing, so please bear with me for a moment. You want the small clef to be a character with a code point, because you want it to be included and accessible in the font along with the regular clef. But having no code point does not mean a glyph can't be included in a font; you can have both of them included, one, the default, accessed by a code point, and the other by some font feature or a glyph index.

That's because font is not a collection of characters — it's a collection of glyphs, some of which should be encoded, some shouldn't. That's exactly what Unicode tried to ensure when banning ligatures or mere glyph variants from having its own code point: that you could have in a font just any glyph or a variant of, but only the ones with a semantically distinct, default meaning will be transmitted as bare text.



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