Live data from Hacker News

Unicode 18.0.0 Beta

unicode.org

61–68 of 68 posts

Re: Unicode 18.0.0 Beta

#61
post #60
post #52

Earlier quoted context omitted.

Also, the 1.1M limit is because of UTF-16. If UTF-16 was deprecated in favor of UTF-8, the limit could be much higher.

We need UTF-32. For the future.

UTF-32 already exists, but nobody uses it because it’s much less efficient for most textual data than UTF-8.

Re: Unicode 18.0.0 Beta

#62
post #56

Earlier quoted context omitted.

There are clients on Matrix that support custom emojii, such as Sable and Commet. Neither are absolutely perfect, but I know people who daily-drive one of the other (or both, which is where I'm at depending on the device). For the most part, now that Matrix is merging those Matrix 2.0 specs finally, and the 2.0 features are already out in the wild with excellent results, it has a really good base, and as expected we'…

That's positive. I think the other feature I wanted was embeds. I know prefetching content can be a security risk but it's super convenient.

Sable has opt-in embeds though I haven't tested the extent of supported websites, seems to work fine for Youtube for instance.

Commet has an open PR for this but not yet implemented.

Re: Unicode 18.0.0 Beta

#66
post #17
post #9

Earlier quoted context omitted.

Did they give a reason why it was declined? Was it some bureaucratic "form not filled in correct" thing, or are they actually against the concept of it?

That list only includes suggestions that were seriously considered and voted on. Since it's a vote, there is no single official 'reason' for rejection. If I had to guess: it would be confusing to anyone who didn't grow up with American TV shows.

what's the connection to american TV shows? i'm only aware of the tinfoil hat through cultural osmosis i guess, something about shielding from radio waves

it's a popular image/byword/archetype for conspiracy theorists, idk if it's a common enough symbol to justify emoji inclusion. the submitted proposals probably have analyses of that though :p

Re: Unicode 18.0.0 Beta

#67
post #54

Earlier quoted context omitted.

While I agree that Han Unification is not optimal (and fixing them is a welcoming development), it is already too late to reverse it. Even counter-proposals like TRON didn't work at all so far. IVD is the best compromise we can have in this situation. > cultural division and xenophobia perpetuate in East Asia By the way, I recently have seen multiple claims from Japanese Twitter users that Korea would have been bette…

> IVD is the best compromise we can have in this situation. Maybe, but no one is running an ivdfy-filter through every single Japanese documents and the issue keeps going. Maybe one way to make it happen is to make the Simplified forms singularly canonical to the CJK Unified Ideographs so to classify everything in that form as Chinese, and define Japanese script as being always flagged with IVDs, though I don't know…

(update: looks like there was someone/some groups ragebaiting Korean and Japanese Twitter users with Korean transition into the Hangul phonetic script for Twitter impression incentives money. Those tweets had not reached me at the time of writing above comment, and my opinion that bringing back Kanji/Hanzi could solve some translation/communication issues is not based on whatever they used as fuels, though I fear it might have been actually close to it)

Re: Unicode 18.0.0 Beta

#68
I see a significant folding tables size increase:

    13615  towctrans-5.h
    14889  towctrans-6.h
    15477  towctrans-7.h
    15815  towctrans-8.h
    16454  towctrans-9.h
    16460  towctrans-10.h
    16756  towctrans-11.h
    16955  towctrans-12.h
    17068  towctrans-13.h
    17456  towctrans-15.h
    17456  towctrans-14.h
    17701  towctrans-17.h
    17721  towctrans-16.h
    18620  towctrans-18.h
Made with cpan Unicode::Towctrans; for v in `seq 5 18`; do gen_wctrans --out towctrans.h -v $v --ud UnicodeData.$v.txt; done

These are already optimized folding-tables.

Post reply on HN