Why isn't MUSICAL SYMBOL NULL NOTEHEAD default ignorable?
kenwhistler at att.net
Thu Sep 15 20:13:48 CDT 2016
On 9/5/2016 5:34 PM, Charlotte Buff wrote:
> It has just come to my attention that U+1D159 MUSICAL SYMBOL NULL
> NOTEHEAD is not default ignorable, even though it has no visible glyph
> appearance and no advance width in text, just like the various Hangul
> jamo fillers that *are* default ignorable. Is there a technical reason
> for this or is it just an oversight?
Well, the proximate reason is that it is General_Category=So, so that
unless it were special-cased for the derivation of the Default_Ignorable
property, it will end up Default_Ignorable=No in the UCD.
As to why it wouldn't be special-cased to force it to end up
Default_Ignorable=Yes, I don't think there was a whole lot of special
thinking that went into this when the musical symbols were first added
in Unicode 3.1 way back in 2001. Default_Ignorable was not even a formal
property as of Unicode 3.1. That property was added (and rationalized)
As to why Default_Ignorable=No is probably the correct value for U+1D159
anyway, think of it this way. The null notehead is essentially a musical
notation specialized version of a non-breaking space -- it is
essentially just a base for applying the various combining stems and
flags for a display without showing a particular notehead, analogous to
applying a generic combining mark to a NBSP to show that combining mark
in isolation. It isn't clear that the null notehead should have no
advance width, and in general, if you don't have a rendering system that
displays such combinations correctly in context, it would arguably be
better to show that there is some *thing* there, rather than to just
omit any visible display at all. Such a situation is also roughly akin
to the various synthetic virama characters in the standard, e.g., U+17D2
KHMER SIGN COENG, which is essentially a subscript consonant stacker.
But if you can't display Khmer conjuncts correctly, it would be better
to display a visible glyph at that point than to just ignore it for
display altogether. So U+17D2 is also not Default_Ignorable, even though
it has no well-defined glyph of its own (hence the dotted box shape
shown in the code charts). And in the case of U+17D2, when correctly
rendered, it definitely would *not* have its own advance width, yet it
is still not Default_Ignorable=Yes.
More information about the Unicode