5 ms·

iOS at least renders it as an n with dieresis; is that how it was intended (I’m unfamiliar with musical notation)? If so, what is so difficult about it? In fac

iOS at least renders it as an n with dieresis; is that how it was intended (I’m unfamiliar with musical notation)? If so, what is so difficult about it? In fact, (semantics aside, from a technical perspective) the preference should always be for modifiers rather than standalone characters because the chances of being supported by the viewer’s font are much greater: it doesn’t need a separate glyph explicitly drawn and add to the font file for the code point. Difficulties in entering it or typing it out should be mitigated with client-side affordances in the UI, shortcuts, etc.

YoshiRulz 1mo ago
I assume they meant https://en.wikipedia.org/wiki/Spinal_Tap_(band) https://en.wikipedia.org/wiki/Spinal_Tap_(band) not anything to do with notation.
cryptonector 1mo ago
> In fact, (semantics aside, from a technical perspective) the preference should always be for modifiers rather than standalone characters [...] Yes. But the font has to be designed to allow this. That means that a) lower-case letters must be small enough to allow "overstrike" with diacritical marks to render correctly, b) diacritical marks must be small enough too, c) if you want capitals to also render correctly then the font must have either a set of smaller capitals, or smaller/higher diacritics, and the renderer must scale the capitals and diacritics to fit, or change line spacing, etc. Also, the 'semantics' for the _human_ reader are the same whether you use pre-composed or decomposed codepoint sequences -- the semantics for the human are about the glyph as rendered and not the details of how that glyph was obtained. And to be super-pedantic (sorry!), what you call 'modifiers' are called combining marks in Unicode, and what you call 'standalone characters' are called precompositions in Unicode. And it's not necessarily true that the rendering will _in practice_ work better with the former than the latter, but in theory absolutely it is, and in practice it almost always is for _browsers_. > Difficulties in entering it or typing it out should be mitigated with client-side affordances in the UI, shortcuts, etc. I really wish Windows would adopt X11-style compose key sequences. Those are incredibly natural for all glyphs that can notionally be constructed via 'overstriking', and historically that is exactly how people did construct those with typewriters. (I don't know, but I suspect that for typesetting it was necessary to have a type for each modified character because having decomposed movable type would probably not have been robust enough.)
- ComputerGuru 1mo ago
  Thanks for the corrections, but I am specifically talking about semantics from the Unicode Technical Committee's perspective, of the underlying Unicode codepoint(s). There is a reason some end-user-viewable glyphs can be formed in multiple ways, sometimes with standalone codepoints (precompositions, sure) and sometimes via the use of combining marks. You have to go back to the Unicode project's actual founding vision, and its basis for accepting new codepoints or declining to do so. People are surprised to learn it has little to do with what the human-visible end result looks like.
  - cryptonector 1mo ago
    Can you fill us in on this history? My understanding is that decompositions for Latin scripts was just natural typewriter-style constructions, while precompositions for Latin scripts was also natural to simplify table-driven transcoding between Unicode and ISO-8859. Similar considerations probably applied in the case of Hiragana (I'm guessing) and other scripts. Besides, combining marks (decomposition) allow for creating new glyphs based on existing ones even where Unicode does not define them. Once two or more ways existed to write any given glyph the canonical equivalence problem immediately arose, and the UC was aware of it immediately, thus we get two basic NFs (NFD, NFC). When it comes to the semantics of glyphs, whatever the UC intended is one thing, but how natural language evolves to use those glyphs is another. So to some degree what the UC intended is a footnote, and what matters is how people use Unicode.

YoshiRulz 1mo ago

I assume they meant https://en.wikipedia.org/wiki/Spinal_Tap_(band) https://en.wikipedia.org/wiki/Spinal_Tap_(band) not anything to do with notation.

cryptonector 1mo ago

> In fact, (semantics aside, from a technical perspective) the preference should always be for modifiers rather than standalone characters [...] Yes. But the font has to be designed to allow this. That means that a) lower-case letters must be small enough to allow "overstrike" with diacritical marks to render correctly, b) diacritical marks must be small enough too, c) if you want capitals to also render correctly then the font must have either a set of smaller capitals, or smaller/higher diacritics, and the renderer must scale the capitals and diacritics to fit, or change line spacing, etc. Also, the 'semantics' for the _human_ reader are the same whether you use pre-composed or decomposed codepoint sequences -- the semantics for the human are about the glyph as rendered and not the details of how that glyph was obtained. And to be super-pedantic (sorry!), what you call 'modifiers' are called combining marks in Unicode, and what you call 'standalone characters' are called precompositions in Unicode. And it's not necessarily true that the rendering will _in practice_ work better with the former than the latter, but in theory absolutely it is, and in practice it almost always is for _browsers_. > Difficulties in entering it or typing it out should be mitigated with client-side affordances in the UI, shortcuts, etc. I really wish Windows would adopt X11-style compose key sequences. Those are incredibly natural for all glyphs that can notionally be constructed via 'overstriking', and historically that is exactly how people did construct those with typewriters. (I don't know, but I suspect that for typesetting it was necessary to have a type for each modified character because having decomposed movable type would probably not have been robust enough.)

ComputerGuru 1mo ago
Thanks for the corrections, but I am specifically talking about semantics from the Unicode Technical Committee's perspective, of the underlying Unicode codepoint(s). There is a reason some end-user-viewable glyphs can be formed in multiple ways, sometimes with standalone codepoints (precompositions, sure) and sometimes via the use of combining marks. You have to go back to the Unicode project's actual founding vision, and its basis for accepting new codepoints or declining to do so. People are surprised to learn it has little to do with what the human-visible end result looks like.
- cryptonector 1mo ago
  Can you fill us in on this history? My understanding is that decompositions for Latin scripts was just natural typewriter-style constructions, while precompositions for Latin scripts was also natural to simplify table-driven transcoding between Unicode and ISO-8859. Similar considerations probably applied in the case of Hiragana (I'm guessing) and other scripts. Besides, combining marks (decomposition) allow for creating new glyphs based on existing ones even where Unicode does not define them. Once two or more ways existed to write any given glyph the canonical equivalence problem immediately arose, and the UC was aware of it immediately, thus we get two basic NFs (NFD, NFC). When it comes to the semantics of glyphs, whatever the UC intended is one thing, but how natural language evolves to use those glyphs is another. So to some degree what the UC intended is a footnote, and what matters is how people use Unicode.