[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

Emil B. Wojtacki
  Grzegorz Rolek:
> If we're discussing encodings and Unicode in particular, we would really want to have somebody from the Unicode Consortium or at least any related expert on-board. I'm not any of these, but although I'm pretty late to the party, I've seen few severe misconceptions expressed here already about how Unicode and the Consortium itself works.  ...
> 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.

As to my understanding, it is not our goal to create a range of Unicode
Standard for musical notation, so that a full score could be encoded in
Unicode. It is about assigning _glyphs_ (or perhaps some abstract
characters), that are required for musical notation (and for limited
text display). We are still talking about PUA.

If encoding music was our goal, we would end with something like a
hybrid of simplified MusicXML, Braille music and LilyPond input,
expressed in a form of listed codepoints (which perhaps would be useful,
but, in my understanding, beyond the scope of SMuFL).

I referred few times to Unicode, since various display devices are
designed to deal with text encoded in Unicode, so they provide support
for some OpenType features (required by some languages). If we talk
about PUA and *font_layout*, we can take advantages of these features.
It is like with the font Caeciliae - it does not conform any standard
encoding, but it is *useful* and relatively *simple* in use.  I used the
same approach to create a font for black mensural notation, and it works
relatively well, too.


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

If you are going to say, that for general bass figures, vertical
direction of writing should be involved, you are probably right. But I
think it is reasonable to have some kind of chord notation basing on
mark-to-mark feature, anyway. And it is simply because I think utilizing
OT features is more convenient (both for users and programmers) than
dealing with currently used fonts with multiple instances of the same
markings encoded in font, where the only difference is their vertical
position.

By the way, bass numbers, according to their semantics, are written from
bottom upwards. This writing direction is not provided in Unicode (last
time I checked, they had not boustrophedon, now I see they added it).

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

I would suggest, that only clef change (or to be more precize: new clef
in staff) should be considered as valid character, which has its initial
form at start of staff and an ordinary (smaller) form within the staff,
although the initial form is sometimes required at instrument change (in
percussion parts, mostly when switching from unpitched to pitched
instrument, but sometimes also from kettle drums to vibraphone). That
would be the most consistent way to encode clefs (in analogy to Arabic
letters), and it would conform recent practice and recommendations of
Unicode Consortium. Now, none of us (I suppose) wants the ordinary,
full-sized treble clef to be considered as "glyph variant".




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