Why isn't MUSICAL SYMBOL NULL NOTEHEAD default ignorable?

[Ken Whistler]

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) 
rather later.

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.

--Ken