Re: commit 1a63a9fc30e7a1f1239e3cedcb5041e5ec1c5351

Re: commit 1a63a9fc30e7a1f1239e3cedcb5041e5ec1c5351

[James Cloos]

> also special-case ß (U+00DF) ... unicode added an uppercase version of
> this character but does not map it, presumably because the uppercase
> version is not actually used except for some obscure purpose ...

For the record:

ẞ (U+1E9E) is not mapped as ß’s majuscule because Unicode’s (really MS’s)
idea of stable is »no bug fixes« and a preference for SS by some, not
because of lack of use.

The legacy of using SS as ß’s majuscule continues in most contexts, but
from what I hear, ẞ is gaining ground.  Especially in text which is set
without miniscules, such as street and commercial signage.

Even without a global ß→ẞ mapping, it might be true that such a mapping
already might be preferred for de_AT text.  (The earliest sightings of
ẞ which were mentioned on unicode@ were, IIRC, in Austria.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Re: commit 1a63a9fc30e7a1f1239e3cedcb5041e5ec1c5351

[Rich Felker]

On Sun, Apr 29, 2012 at 03:02:22PM -0400, James Cloos wrote:
> > also special-case ß (U+00DF) ... unicode added an uppercase version of
> > this character but does not map it, presumably because the uppercase
> > version is not actually used except for some obscure purpose ...
> 
> For the record:
> 
> ẞ (U+1E9E) is not mapped as ß’s majuscule because Unicode’s (really MS’s)
> idea of stable is »no bug fixes« and a preference for SS by some, not
> because of lack of use.
> 
> The legacy of using SS as ß’s majuscule continues in most contexts, but
> from what I hear, ẞ is gaining ground.  Especially in text which is set
> without miniscules, such as street and commercial signage.
> 
> Even without a global ß→ẞ mapping, it might be true that such a mapping
> already might be preferred for de_AT text.  (The earliest sightings of
> ẞ which were mentioned on unicode@ were, IIRC, in Austria.)

Thank you for the information. I'm also aware of (and generally
disagree with) Unicode's policy of not fixing bugs. While I'd like to
see some more opinions (from both "sides", if there are sides to the
issue) what you're saying makes a lot of sense, and it would
definitely clean up naive case mapping quite a bit (i.e. de-uglify the
result of applications performing naive uppercasing).

One potential argument I can think of against the case mapping is that
uppercasing would map Latin-1 text outside of Latin-1. But this is
really a problem of the folks still using Latin-1, and not terribly
relevant to a 100% UTF-8 system like one built on musl.

Rich


P.S. Thanks for writing ẞ out in the email and thereby bringing to my
attention the fact that it's missing in uuterm's ytty font. This is
probably sufficient to get me to move the uuterm repository to git on
git.etalabs.net and make the first commit in years.