I like how the Unicode Consortium really doesn't want to accept any more flags, but you can still probably shoehorn them in if you're Apple or Google and you have a glyph sequence that is backwards compatible. One way of getting things done -- just do it.
I knew the details behind this because Windows 10 didn't include font with the trans flag by default, and so it always rendered as flag + trans symbol. I eventually installed the emoji font from the Windows 11 betas and found much of what I read to suddenly be a lot nicer looking.
That's true, they won't process any proposals for flags anymore. The first link in the linked post is a detailed FAQ from the Unicode people:
> Flags for countries with Unicode region codes [ie. recognized by ISO] are automatically recommended, with no proposals necessary! [...] the Emoji Subcommittee is no longer taking in any proposals for flags of any kind.
They have a section addressing new pride flags specifically near the end of the FAQ.
This is a thread about flag emojis, hardly tangential!
And it isn't flamebait to point out the f*cked up power dynamics in highly-government-influenced standards orgs. Especially the Unicode Consortium, since you can fit the alphabets of the official language of every country but one into a 16-bit space (no I'm not advocating Han Unification -- in fact precisely the opposite). The whole rest of the world has to deal with variable-length encodings and "grapheme cluster" nonsense just to keep one country happy.
dang, you have impugned my honor. I demand satisfaction in the form of a duel! Nerf guns at twenty paces.
There are no country flags in UTF. The flag you're seeing is the interpretation of a 2 character ISO country code by your OS.
> Although they can be displayed as Roman letters, it is intended that implementations may choose to display them in other ways, such as by using national flags. The Unicode FAQ indicates that this mechanism should be used and that symbols for national flags will not be directly encoded. This allows the Unicode consortium to avoid any issues surrounding which countries to include (and, de facto, recognize), instead leaving it entirely to the system implementation as to which flags to include (see: partially recognized state).
There is no flag in the encoding. Instead, there are codepoints for each of ISO 3166-1's "Codes for the representation of names of countries and their subdivisions": https://en.wikipedia.org/wiki/ISO_3166-1
Both the People's Republic of China and the Republic of China agree that there exists an entity called "Taiwan, Province of China" (TW). They have different views about what that entity's flag is (and many other things about that entity), but Unicode doesn't offer any opinions on that.
To clarify, 3166-1 is for countries, dependent territories (i.e. Guam), special areas (Taiwan, Hong Kong) i.e. TW gets a flag being in 3166-1 list but under UN resolution 2758, PRC gets to subsume TW as special area - "Taiwan (Province of China)". 3166-2 is for subdivisions (TW provinces, UNDER CHINA), i.e. all TW provinces are considered subdivisions of China/PRC. Same with HK. Unicode doesn't offer opinion in the sense the opinion is whatever UN recognize as countries, which will never include TW as long as PRC holds P5 veto.
In the meantime this arrangement works out since ROC constitution still legally asserts it's but part of One China polity, i.e. it doesn't matter what TWers think or DPP claims, or tries to legally engineer (additional articles /legal fiction limiting ROC political jurisdiction to "free area" of tw + islands). Until TW voters&politicians actually formally separates / declares independence, as in change ROC constitution by renounce claims on mainland, they'll lose 3166-1 designation because PRC gets to remove them, and won't get a new one because PRC veto. They'll lose their emojis (maybe iso codes, maybe domain depending on US/ICANN drama)... which TBH will be least of their worries.
Almost nobody in Taiwan would call it a "province of China" (some would if you redefine what China means, ie not PRC). But as usual standards bodies bend to whoever has power at the moment.
This is a clear tell that your knowledge of the situation is basically just Wikipedia plus media reporting. Approximately nobody in Taiwan views it that way. It is an obscure legal fiction of no relevance. It only persists because of a red line drawn by the PRC.
It’s kind of like how New Zealand is included as a province of Australia, technically, in their constitution.
I didn't saw anything about how people view this? As you state, it's a legal fiction, but it's quite useful in numerous contexts like this, because it lets Unicode de facto include the Taiwan flag without actually including the Taiwan flag.
While a previous government of Taiwan claimed that it was the legitimate ruler of China, the current government does not. It considers itself to be a separate sovereign state. The KMT that fought for control of China and fled the mainland is only a small fraction of Taiwan's population and only ruled over the majority by political suppression.
Taiwan is the last vestige of original ”China” and PRC already redefined it when Taiwan (ROC) lost the mainland to the communists in 1949 during the Chinese Civil War.
As much as I appreciate the expressiveness that comes from emojis and flags in Unicode, I am rather shocked by the growing technical complexity of decoding unicode into rwndwrable graphemes. Unicode was already worryingly complex before all of these new combinations were introduced. Properly parsing Unicode is close to obtaining this "don't roll your own" status that has has so far been reserved for the likes of networking and cryptography libraries. Unicode, even if UTF-8 encoded, is now such a far cry from the old 8 bit charsets that's still being inplicitly assumed by so many standard libraries of programming languages.
Those early software character sets had their own complexities (i.e. there was more than one), compared to the hardwired (you get one character set, and you’ll like it) set that shipped with early display adapters.
Having earned thousands of dollars fixing old systems to deal with new character sets, I can’t really complain.
Rendering Unicode was always this complex. Emoji don't do anything that some other language in real use doesn't also do. What emoji does is bring that visually to the forefront among contemporary English text. The assumption that 8-bit character sets of simple bitmaps are all you need mostly only ever worked for English (and then only if you didn't need nice print-like typography, or math formulas, or…).
This isn't exactly true. Emojis and other symbols introduced new notions like colors that were not present before. I'm no longer certain that it is feasible to handcraft a font thwt contains all the symbols for codepoints affected by color modifiers.
Also, 8 bit codepages, for all their problems (a different kind of hell), didn't break the assumption that each character is encoded as one byte. In that way, they didn't break software in interesting ways like UTF-encoded and possibly decomposed Unicode is able to do. Back then, it was something of a blessing at surface level, but the proliferation of string handling code and concepts that assume this one to one mappping just don't fit well with Unicode. And UTF-8 specifically gives the illusion to English speakers that using naive 8 bit string handling works.
> Emojis and other symbols introduced new notions like colors that were not present before. I'm no longer certain that it is feasible to handcraft a font thwt contains all the symbols for codepoints affected by color modifiers.
Color modifiers are just ZWJ sequences. Those existed before. The color modifiers themselves are not the most complicated things that get attached to ZWJ sequences among languages that Unicode supports.
OpenType today supports color tables that mean most emoji modified by colors aren't "handcrafted" but algorithmically constructed. (As many ligatures and other ZWJ sequences often are.)
> Also, 8 bit codepages, for all their problems (a different kind of hell), didn't break the assumption that each character is encoded as one byte.
That is broken in other 8-bit codepages as well, it was just seen as an exception/edge case rather than the rule. The big obvious exception has always been \r\n (carriage return then newline), but there's also ^H (control-H) and ^W (control-W) sequences (effectively backspace and delete word), and the entire gamut of things done with ANSI and/or VT100 escape seqences starting with Escape often stylized as ^[.
> And UTF-8 specifically gives the illusion to English speakers that using naive 8 bit string handling works.
Unless emoji are present, which is one of the great things about emoji and emoji becoming a very common form of punctuation in English text. Naive 8-bit string handling was always wrong. Emoji help make it visible how wrong it was. (In part by doing things other languages do such as ZWJ sequences and having code points out in the Astral Plane and other such features.)
So you agree that font rendering had to be extended to support color modifiers as specified in Unicode? That is the kind of completely creep that I am pointing out.
A bunch of control codes are historically part of character encodings, and their encoding is very consistent within codepages of the same family (ASCII/ANSI and EBCDIC). You don't have to have any awareness about the active codepage/language to handle them correctly.
Terminal escape sequences are a poor form of in-band signaling between devices (now virtualized), not text. I comsider that out of scope.
Anyway, as we get into the weeds here, I do not want to dispute the enormous practical utility of Unicode and I am glad that it exists and covers so many of the world's writing systems and alphabets. It is one of the central standards that connects people today. But from the purely technical perspective, the steady complexity creep is undeniable and brings somewhat hidden costs to software systems.
One byte equals one character was already incorrect in the pre-unicode days for east asian languages. UTF-8 is much easier to parse than something like Shift JIS, where splitting a string in between bytes of a codepoint results in a valid but incorrect string.
Written like this, emojis look a bit like stargate addresses [1F3F3 FE0F 200D 26A7 FE0].
I knew that emoji symbols have a way of using modifiers but this is the first time I’m getting a glimpse into the process of iterating on a proposal. Thanks for sharing!
Blimey! After I engaged reader mode, all was revealed 8)
The "spider" and the wandering particles are funky but everything else in gthe presentation conspires to exclude granddad (who has rather shite eyesight these days). On the bright side, you didn't go for a dark theme. I'm happy to sort out my very minor accessibility "problems" but it might be nice to cater for all, as much as you can.
I love how you have considered so many ways to ensure that it will degrade gracefully, as far as is possible for certain glyph handling capabilities.
Good skills ... how on earth does this work? I pasted your glyph quite a lot and found that backspace changes it into the other flag:
EDIT: Oh dear, HN strips out funky glyphs so this post looks a bit odd.
Man, Unicode is a complex thing. All sorts of directionality and reinterpretation to it. What a terrible beast to wrangle. Glad someone else is doing it and I can stick to ASCII.
Also, this website is delightfully hilarious. It's got music. I haven't seen that since the old days. Very nostalgic. I read in Reader Mode, but enjoyed the expression of self.
I'm waiting for Unicode to support something really fun or insane, like arbitrary 64x64 inline bitmaps, or entirely arbitrary flag support!
Really, it should have a full implementation of heraldry.
Unicode can only be complete when it is a full renderer. If I can't render my video game using one complete "glyph", what are we even doing in this world?
> all javascript on this website is optional (light/dark theme, particles background, and image lightboxing) and resides outside of the document body. localstorage is used to persist light/dark theme and mono/sans font state while surfing, as well as handle an over-18 check.
Hitting the reader mode of your favorite browser will help.
Usually it sounds like a weird advice and we'd want site owners to aim for readability...but TBH, blaming a site on a .pink domain on a page explaining the codepoints of an emoji flag to not be universally accessible seems beside the point.
I don't mind the dialogue, but if we're taking about the same author, some of the content gets diminished by the meandering waffling.
I realise it's a stylistic choice but there's been a few posts where I felt tired after reading their articles. And it also feels like one of those YouTube shorts sketches where one person pretends to be multiple people and it starts feeling a bit cheap/meh.
I think it would be fine if it they toned down on the interjections/interruptions
They might be talking about Xe Iaso's blog, although there the furry conversations are only for short supplementary asides sotto voce, while the bulk of every post is in ordinary text. I like it, personally, but maybe it grates on some people.
Why are flags part of unicode? I thought the point of unicode was to add something for every glyph ever written in every text so they can be stored digitally as plain text. Flags are... not text. And who decides what sorts of flags and valid which aren't? I mean... we know who.. .but humour me.
(didn't read the article because the website is deliberately unreadable. zero guilt)
The reason I've heard is because Japanese phone companies had invented their own version of emojis on their own encoding scheme pre unicode, and to switch over, they needed unicode to also include support for these emoji, which is why a lot of them are very Japan specific.
Emojis then blew up with the rest of the world once people worked out how to enable them on the iphone. And since unicode has unlimited space for new emoji, there is little reason to deny any widely used symbol an emoji representation.
The part i dont like is that country flags are encoded via country code, so if the regime changes (and adopts a new flag) all the flags in your document retroactively change.
This could have very different meaning. E.g. flag of Afghanistan before vs after the Taliban took over.
One of the points of Unicode was to replace every other existing text encoding. This requires enough fidelity to be able to round-trip the text back and forth to them so that you can receive data in another text encoding, store it in Unicode, and then spit it back out in that same other text encoding without anything having changed.
The classic IBM PC text encoding ("codepage 437") already contains the card suits, gender symbols, and box drawing characters which are not text glyphs, so any "non-text symbols" battle was lost before it even started.
The point of Unicode is to try and be the One True Encoding and remove the need for all other language encoding standards, so there's never any more "mojibake" or cross-border compatibility issues. In order to do this, every feature that has existed in other encoding standards has to be supported in Unicode, or else people will stick to that other encoding in some circumstances.
With emoji specifically, they were popular in Japan dating all the way back to the 90s, via carrier-specific encoding standards. The lack of emoji support in messaging was a reason that the iPhone and Android were slower than expected to take off in Japan, and so Apple and Google asked the Unicode Consortium to add emoji support, so they could have this feature on their phones while sticking to a universal encoding standard. IIRC, the Unicode Consortium was actually hesitant to do this and didn't want to be involved with standardizing pictograms into Unicode, but eventually relented.
I wish they stuck to languages only, instead of branching out into modern hieroglyphics. There are enough forces hacking away at literacy as it is. Flags are particularly wasteful, given that nations and movements can be highly ephemeral.
You'll be happy to learn that Unicode does not have one codepoint per national flag. It has 26 codepoints that form a special alphabet that two-letter country codes can be written with, and those are conventionally rendered as national flags.
I could give a shit about codepoints. Multilingual text is hard enough as it is. The icons-with-combiners were an unnecessary complication. The site we are commenting on rejects them, and rightly so.
I hate to be rude, but I found the writing quite difficult to follow in its technical aspects, and the pink and black glitter formatting was the last straw. I ended up dumping it into ChatGPT to rewrite the technical content in a form that’s easier to follow, in the hopes of elevating the discussion - I hope I don’t have to do this often on HN, but the technical story was interesting enough that it’s worth rescuing: https://gist.github.com/telotortium/58fe0c16f03455721420b768...
I like how the Unicode Consortium really doesn't want to accept any more flags, but you can still probably shoehorn them in if you're Apple or Google and you have a glyph sequence that is backwards compatible. One way of getting things done -- just do it.
I knew the details behind this because Windows 10 didn't include font with the trans flag by default, and so it always rendered as flag + trans symbol. I eventually installed the emoji font from the Windows 11 betas and found much of what I read to suddenly be a lot nicer looking.
P.S. I love the effects on this website :3
That's true, they won't process any proposals for flags anymore. The first link in the linked post is a detailed FAQ from the Unicode people:
> Flags for countries with Unicode region codes [ie. recognized by ISO] are automatically recommended, with no proposals necessary! [...] the Emoji Subcommittee is no longer taking in any proposals for flags of any kind.
They have a section addressing new pride flags specifically near the end of the FAQ.
https://news.ycombinator.com/item?id=44283231
China really doesn't want to accept more flag emojis. For fairly obvious reasons.
"Eschew flamebait. Avoid generic tangents."
https://news.ycombinator.com/newsguidelines.html
This is a thread about flag emojis, hardly tangential!
And it isn't flamebait to point out the f*cked up power dynamics in highly-government-influenced standards orgs. Especially the Unicode Consortium, since you can fit the alphabets of the official language of every country but one into a 16-bit space (no I'm not advocating Han Unification -- in fact precisely the opposite). The whole rest of the world has to deal with variable-length encodings and "grapheme cluster" nonsense just to keep one country happy.
dang, you have impugned my honor. I demand satisfaction in the form of a duel! Nerf guns at twenty paces.
I dont really think that makes sense as Taiwan flag is already there.
There are no country flags in UTF. The flag you're seeing is the interpretation of a 2 character ISO country code by your OS.
> Although they can be displayed as Roman letters, it is intended that implementations may choose to display them in other ways, such as by using national flags. The Unicode FAQ indicates that this mechanism should be used and that symbols for national flags will not be directly encoded. This allows the Unicode consortium to avoid any issues surrounding which countries to include (and, de facto, recognize), instead leaving it entirely to the system implementation as to which flags to include (see: partially recognized state).
https://en.wikipedia.org/wiki/Regional_indicator_symbol
Sure. My point still stands, you can already encode Taiwan's flag, so what is China allegedly objecting to?
There is no flag in the encoding. Instead, there are codepoints for each of ISO 3166-1's "Codes for the representation of names of countries and their subdivisions": https://en.wikipedia.org/wiki/ISO_3166-1
Both the People's Republic of China and the Republic of China agree that there exists an entity called "Taiwan, Province of China" (TW). They have different views about what that entity's flag is (and many other things about that entity), but Unicode doesn't offer any opinions on that.
To clarify, 3166-1 is for countries, dependent territories (i.e. Guam), special areas (Taiwan, Hong Kong) i.e. TW gets a flag being in 3166-1 list but under UN resolution 2758, PRC gets to subsume TW as special area - "Taiwan (Province of China)". 3166-2 is for subdivisions (TW provinces, UNDER CHINA), i.e. all TW provinces are considered subdivisions of China/PRC. Same with HK. Unicode doesn't offer opinion in the sense the opinion is whatever UN recognize as countries, which will never include TW as long as PRC holds P5 veto.
In the meantime this arrangement works out since ROC constitution still legally asserts it's but part of One China polity, i.e. it doesn't matter what TWers think or DPP claims, or tries to legally engineer (additional articles /legal fiction limiting ROC political jurisdiction to "free area" of tw + islands). Until TW voters&politicians actually formally separates / declares independence, as in change ROC constitution by renounce claims on mainland, they'll lose 3166-1 designation because PRC gets to remove them, and won't get a new one because PRC veto. They'll lose their emojis (maybe iso codes, maybe domain depending on US/ICANN drama)... which TBH will be least of their worries.
Almost nobody in Taiwan would call it a "province of China" (some would if you redefine what China means, ie not PRC). But as usual standards bodies bend to whoever has power at the moment.
Legally speaking, Taiwan is a province of China according to both the PRC and ROC. Of course, they both claim that they are the "China" in question.
This is a clear tell that your knowledge of the situation is basically just Wikipedia plus media reporting. Approximately nobody in Taiwan views it that way. It is an obscure legal fiction of no relevance. It only persists because of a red line drawn by the PRC.
It’s kind of like how New Zealand is included as a province of Australia, technically, in their constitution.
I didn't saw anything about how people view this? As you state, it's a legal fiction, but it's quite useful in numerous contexts like this, because it lets Unicode de facto include the Taiwan flag without actually including the Taiwan flag.
While a previous government of Taiwan claimed that it was the legitimate ruler of China, the current government does not. It considers itself to be a separate sovereign state. The KMT that fought for control of China and fled the mainland is only a small fraction of Taiwan's population and only ruled over the majority by political suppression.
Not very wrong but maybe at least half of population will not agree with that
Taiwan is the last vestige of original ”China” and PRC already redefined it when Taiwan (ROC) lost the mainland to the communists in 1949 during the Chinese Civil War.
Stop spreading fake news.
As much as I appreciate the expressiveness that comes from emojis and flags in Unicode, I am rather shocked by the growing technical complexity of decoding unicode into rwndwrable graphemes. Unicode was already worryingly complex before all of these new combinations were introduced. Properly parsing Unicode is close to obtaining this "don't roll your own" status that has has so far been reserved for the likes of networking and cryptography libraries. Unicode, even if UTF-8 encoded, is now such a far cry from the old 8 bit charsets that's still being inplicitly assumed by so many standard libraries of programming languages.
Those early software character sets had their own complexities (i.e. there was more than one), compared to the hardwired (you get one character set, and you’ll like it) set that shipped with early display adapters.
Having earned thousands of dollars fixing old systems to deal with new character sets, I can’t really complain.
Rendering Unicode was always this complex. Emoji don't do anything that some other language in real use doesn't also do. What emoji does is bring that visually to the forefront among contemporary English text. The assumption that 8-bit character sets of simple bitmaps are all you need mostly only ever worked for English (and then only if you didn't need nice print-like typography, or math formulas, or…).
This isn't exactly true. Emojis and other symbols introduced new notions like colors that were not present before. I'm no longer certain that it is feasible to handcraft a font thwt contains all the symbols for codepoints affected by color modifiers.
Also, 8 bit codepages, for all their problems (a different kind of hell), didn't break the assumption that each character is encoded as one byte. In that way, they didn't break software in interesting ways like UTF-encoded and possibly decomposed Unicode is able to do. Back then, it was something of a blessing at surface level, but the proliferation of string handling code and concepts that assume this one to one mappping just don't fit well with Unicode. And UTF-8 specifically gives the illusion to English speakers that using naive 8 bit string handling works.
> Emojis and other symbols introduced new notions like colors that were not present before. I'm no longer certain that it is feasible to handcraft a font thwt contains all the symbols for codepoints affected by color modifiers.
Color modifiers are just ZWJ sequences. Those existed before. The color modifiers themselves are not the most complicated things that get attached to ZWJ sequences among languages that Unicode supports.
OpenType today supports color tables that mean most emoji modified by colors aren't "handcrafted" but algorithmically constructed. (As many ligatures and other ZWJ sequences often are.)
> Also, 8 bit codepages, for all their problems (a different kind of hell), didn't break the assumption that each character is encoded as one byte.
That is broken in other 8-bit codepages as well, it was just seen as an exception/edge case rather than the rule. The big obvious exception has always been \r\n (carriage return then newline), but there's also ^H (control-H) and ^W (control-W) sequences (effectively backspace and delete word), and the entire gamut of things done with ANSI and/or VT100 escape seqences starting with Escape often stylized as ^[.
> And UTF-8 specifically gives the illusion to English speakers that using naive 8 bit string handling works.
Unless emoji are present, which is one of the great things about emoji and emoji becoming a very common form of punctuation in English text. Naive 8-bit string handling was always wrong. Emoji help make it visible how wrong it was. (In part by doing things other languages do such as ZWJ sequences and having code points out in the Astral Plane and other such features.)
So you agree that font rendering had to be extended to support color modifiers as specified in Unicode? That is the kind of completely creep that I am pointing out.
A bunch of control codes are historically part of character encodings, and their encoding is very consistent within codepages of the same family (ASCII/ANSI and EBCDIC). You don't have to have any awareness about the active codepage/language to handle them correctly.
Terminal escape sequences are a poor form of in-band signaling between devices (now virtualized), not text. I comsider that out of scope.
Anyway, as we get into the weeds here, I do not want to dispute the enormous practical utility of Unicode and I am glad that it exists and covers so many of the world's writing systems and alphabets. It is one of the central standards that connects people today. But from the purely technical perspective, the steady complexity creep is undeniable and brings somewhat hidden costs to software systems.
One byte equals one character was already incorrect in the pre-unicode days for east asian languages. UTF-8 is much easier to parse than something like Shift JIS, where splitting a string in between bytes of a codepoint results in a valid but incorrect string.
This is so cool!
Written like this, emojis look a bit like stargate addresses [1F3F3 FE0F 200D 26A7 FE0].
I knew that emoji symbols have a way of using modifiers but this is the first time I’m getting a glimpse into the process of iterating on a proposal. Thanks for sharing!
I love how you have considered so many ways to ensure that it will degrade gracefully, as far as is possible for certain glyph handling capabilities.
Good skills ... how on earth does this work? I pasted your glyph quite a lot and found that backspace changes it into the other flag:
EDIT: Oh dear, HN strips out funky glyphs so this post looks a bit odd.
Wow - this site is incredibly designed. Makes me remember how vivid and unique the internet of my youth used to be.
That's cool thank you.
I hope they add the bi flag one day.
Waiting for the day when Vampire BPD flag
Man, Unicode is a complex thing. All sorts of directionality and reinterpretation to it. What a terrible beast to wrangle. Glad someone else is doing it and I can stick to ASCII.
Also, this website is delightfully hilarious. It's got music. I haven't seen that since the old days. Very nostalgic. I read in Reader Mode, but enjoyed the expression of self.
I didn't read the blog yet because I clicked on cat pics and there weren't any!!!
I'm waiting for Unicode to support something really fun or insane, like arbitrary 64x64 inline bitmaps, or entirely arbitrary flag support!
Really, it should have a full implementation of heraldry.
Unicode can only be complete when it is a full renderer. If I can't render my video game using one complete "glyph", what are we even doing in this world?
I’m having a really hard time reading with the background particles.
> all javascript on this website is optional (light/dark theme, particles background, and image lightboxing) and resides outside of the document body. localstorage is used to persist light/dark theme and mono/sans font state while surfing, as well as handle an over-18 check.
https://hecate.pink/about/
Hitting the reader mode of your favorite browser will help.
Usually it sounds like a weird advice and we'd want site owners to aim for readability...but TBH, blaming a site on a .pink domain on a page explaining the codepoints of an emoji flag to not be universally accessible seems beside the point.
Run this in the JavaScript console:
You really need to add a toggle for the effects, it makes it hard to read.
At least this one isn't presented as a back and forth between two furry characters
You make that sound like it wouldn't make it even better uwu
Dialogue has been a form of presentation forever. (See, Plato and most of literature)
I don't mind the dialogue, but if we're taking about the same author, some of the content gets diminished by the meandering waffling.
I realise it's a stylistic choice but there's been a few posts where I felt tired after reading their articles. And it also feels like one of those YouTube shorts sketches where one person pretends to be multiple people and it starts feeling a bit cheap/meh.
I think it would be fine if it they toned down on the interjections/interruptions
So Is illustration as shown by hieroglyphics, this doesn't make me want it more. I can understand text just fine
The typeface is called `monofur`, so technically all the text is composed of furry characters.
Are you referring to a specific blogpost? Doesn't sound familiar.
They might be talking about Xe Iaso's blog, although there the furry conversations are only for short supplementary asides sotto voce, while the bulk of every post is in ordinary text. I like it, personally, but maybe it grates on some people.
Oh no, the horror.
Turning off javascript gets rid of the crazy.
And reading mode can be a good option too. Particularly if it's more about the styling/contrast.
No they don't, it's their website.
Just don't read the article and comment based on the headline.
Inspiring to see women getting into the far weeds of the unicode technical standard.
I have bad news for you.
what do you mean?
He's just showing his bigotry.
welcome to 2025?
Why are flags part of unicode? I thought the point of unicode was to add something for every glyph ever written in every text so they can be stored digitally as plain text. Flags are... not text. And who decides what sorts of flags and valid which aren't? I mean... we know who.. .but humour me.
(didn't read the article because the website is deliberately unreadable. zero guilt)
The reason I've heard is because Japanese phone companies had invented their own version of emojis on their own encoding scheme pre unicode, and to switch over, they needed unicode to also include support for these emoji, which is why a lot of them are very Japan specific.
Emojis then blew up with the rest of the world once people worked out how to enable them on the iphone. And since unicode has unlimited space for new emoji, there is little reason to deny any widely used symbol an emoji representation.
The part i dont like is that country flags are encoded via country code, so if the regime changes (and adopts a new flag) all the flags in your document retroactively change.
This could have very different meaning. E.g. flag of Afghanistan before vs after the Taliban took over.
One of the points of Unicode was to replace every other existing text encoding. This requires enough fidelity to be able to round-trip the text back and forth to them so that you can receive data in another text encoding, store it in Unicode, and then spit it back out in that same other text encoding without anything having changed.
The classic IBM PC text encoding ("codepage 437") already contains the card suits, gender symbols, and box drawing characters which are not text glyphs, so any "non-text symbols" battle was lost before it even started.
The point of Unicode is to try and be the One True Encoding and remove the need for all other language encoding standards, so there's never any more "mojibake" or cross-border compatibility issues. In order to do this, every feature that has existed in other encoding standards has to be supported in Unicode, or else people will stick to that other encoding in some circumstances.
With emoji specifically, they were popular in Japan dating all the way back to the 90s, via carrier-specific encoding standards. The lack of emoji support in messaging was a reason that the iPhone and Android were slower than expected to take off in Japan, and so Apple and Google asked the Unicode Consortium to add emoji support, so they could have this feature on their phones while sticking to a universal encoding standard. IIRC, the Unicode Consortium was actually hesitant to do this and didn't want to be involved with standardizing pictograms into Unicode, but eventually relented.
> Flags are... not text.
Neither is poop, and yet someone decided that was important enough to include.
I wish they stuck to languages only, instead of branching out into modern hieroglyphics. There are enough forces hacking away at literacy as it is. Flags are particularly wasteful, given that nations and movements can be highly ephemeral.
You'll be happy to learn that Unicode does not have one codepoint per national flag. It has 26 codepoints that form a special alphabet that two-letter country codes can be written with, and those are conventionally rendered as national flags.
I could give a shit about codepoints. Multilingual text is hard enough as it is. The icons-with-combiners were an unnecessary complication. The site we are commenting on rejects them, and rightly so.
I hate to be rude, but I found the writing quite difficult to follow in its technical aspects, and the pink and black glitter formatting was the last straw. I ended up dumping it into ChatGPT to rewrite the technical content in a form that’s easier to follow, in the hopes of elevating the discussion - I hope I don’t have to do this often on HN, but the technical story was interesting enough that it’s worth rescuing: https://gist.github.com/telotortium/58fe0c16f03455721420b768...
Your take is very subjective. I found the story captivating and technically clear.