3 ms·

Before that, there was the case of ÿ and Ÿ in the base IBM character set (see https://en.wikipedia.org/wiki/Ÿ https://en.wikipedia.org/wiki/Ÿ). The former exist

Before that, there was the case of ÿ and Ÿ in the base IBM character set (see https://en.wikipedia.org/wiki/Ÿ https://en.wikipedia.org/wiki/Ÿ). The former exists in a handful of proper nouns in French and Hungarian (as in about five proper nouns), but only as a y with a diæresis, which would normally be handled with a Unicode modifier symbol. It is also used in a couple of endangered languages in South America, which would not have influenced the character getting in to a PC character set. It is thought that possibly it was supposed to represent the Dutch "ij" character, but apparently that is never written as "ÿ" in print. Ÿ seems to not be used by any language.

pseudohadamard 2mo ago
Great, so they added Ÿ but not n̈, making it very difficult to write music reviews. (Not sure how the latter will render in your browser).
- ComputerGuru 2mo ago
  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 2mo 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 2mo 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 2mo 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 2mo ago
- cryptonector 2mo ago
  n̈ renders fine on my browser, but there is no compose-key sequence for it on my system. I suspect the reason it renders fine is that 'n' in the font I'm using is small enough that the combining mark can be rendered by "overstriking" a diaeresis.
  - pseudohadamard 2mo ago
    It seems to be font-related, when I edited the text it rendered fine but viewing the resulting page has the unlauts floating in space after the n.
    - cryptonector 2mo ago
      I also see the same, and I suspect it is due to the lack of a precomposition for n̈.
mostlylurks 2mo ago
> Ÿ seems to not be used by any language. Surely those aforementioned non-initial cases would sometimes find themselves in a piece of all-uppercase text? You'd have found such things in print media even before the advent of computers.
- NegativeLatency 2mo ago
  Not everything is upper/lower convertible like ß for example (as far as I know) At least until 2017, I imagine there are others though. > In 2017, the Council for German Orthography officially adopted a capital form ⟨ẞ⟩ as an acceptable variant, ending a long debate. https://en.wikipedia.org/wiki/%C3%9F https://en.wikipedia.org/wiki/%C3%9F
- tengwar2 2mo ago
  Sure, but I've never heard of a diæresis being added to a capital letter.
  - seszett 2mo ago
    It is on signs when entering L'Haÿ-les-Roses at least. Every letter in French must have a capital version.
    - tengwar2 2mo ago
      Yup. Just checked on Streetview.
WhyNotHugo 2mo ago
I've seen Dutch comics for kids which use ÿ instead of ij. E.g.: "mÿn". In typical comic font (which is closer to handwriting), it looks similar to ij, but it's clearly ÿ.
cryptonector 2mo ago
> but only as a y with a diæresis á (á) is also an 'a' with a diacritical acute accent. If you mean that ÿ should not have a precomposition in Unicode, well, why not, especially if it really is used in "a handful of proper nouns in French and Hungarian". Remember, the reason we have combining marks is that that is in fact how many of these characters were composed in actual use, especially with typewriters. Heck, 1966 US-ASCII / ECMA-6 (1985), section 5, describes the use of backspace/overstrike in US-ASCII for composition of such characters! That comes from typewriter use. And that's where compose-key sequences generally come from, too. So it's not at all surprising that given that ÿ has _some_ use, therefore a) it is a valid glyph to construct with combining diaeresis, and b) that it has a precomposed codepoint in Unicode.

pseudohadamard 2mo ago

Great, so they added Ÿ but not n̈, making it very difficult to write music reviews. (Not sure how the latter will render in your browser).

ComputerGuru 2mo ago
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 2mo 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 2mo 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 2mo 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 2mo ago
cryptonector 2mo ago
n̈ renders fine on my browser, but there is no compose-key sequence for it on my system. I suspect the reason it renders fine is that 'n' in the font I'm using is small enough that the combining mark can be rendered by "overstriking" a diaeresis.
- pseudohadamard 2mo ago
  It seems to be font-related, when I edited the text it rendered fine but viewing the resulting page has the unlauts floating in space after the n.
  - cryptonector 2mo ago
    I also see the same, and I suspect it is due to the lack of a precomposition for n̈.

mostlylurks 2mo ago

> Ÿ seems to not be used by any language. Surely those aforementioned non-initial cases would sometimes find themselves in a piece of all-uppercase text? You'd have found such things in print media even before the advent of computers.

NegativeLatency 2mo ago
Not everything is upper/lower convertible like ß for example (as far as I know) At least until 2017, I imagine there are others though. > In 2017, the Council for German Orthography officially adopted a capital form ⟨ẞ⟩ as an acceptable variant, ending a long debate. https://en.wikipedia.org/wiki/%C3%9F https://en.wikipedia.org/wiki/%C3%9F
tengwar2 2mo ago
Sure, but I've never heard of a diæresis being added to a capital letter.
- seszett 2mo ago
  It is on signs when entering L'Haÿ-les-Roses at least. Every letter in French must have a capital version.
  - tengwar2 2mo ago
    Yup. Just checked on Streetview.

WhyNotHugo 2mo ago

I've seen Dutch comics for kids which use ÿ instead of ij. E.g.: "mÿn". In typical comic font (which is closer to handwriting), it looks similar to ij, but it's clearly ÿ.

cryptonector 2mo ago

> but only as a y with a diæresis á (á) is also an 'a' with a diacritical acute accent. If you mean that ÿ should not have a precomposition in Unicode, well, why not, especially if it really is used in "a handful of proper nouns in French and Hungarian". Remember, the reason we have combining marks is that that is in fact how many of these characters were composed in actual use, especially with typewriters. Heck, 1966 US-ASCII / ECMA-6 (1985), section 5, describes the use of backspace/overstrike in US-ASCII for composition of such characters! That comes from typewriter use. And that's where compose-key sequences generally come from, too. So it's not at all surprising that given that ÿ has _some_ use, therefore a) it is a valid glyph to construct with combining diaeresis, and b) that it has a precomposed codepoint in Unicode.