4 ms·

Is it too late to add separate code points for the chinese, japanese, and korean versions of the han characters ?

lifthrasiir 5y ago
In principle there is a designated "disunificiation" procedure when it's desirable. More accurately speaking, each CJK character is thought to represent not a single or a few glyphs listed in the code chart but rather a glyphic subset, and the disunification splits that set into partitions. But this is generally applied to a few selected characters and only when it's safe to do so. Massive disunification was to my knowledge never suggested or proposed, and that would surely prompt a large scale disruption throughout CJK users (say, how about existing texts?).
- rrobukef 5y ago
  So it's possible to modify the skin tone of emoji but impossible to disunify CJK characters? There are RTL modifiers for Arabic languages, it's impossible for CJK? It shouldn't be harder than existing unicode handling.
  - lifthrasiir 5y ago
    Everything boils down to the interoperability and compatibility. Emoji was added because Apple and Google had to deal with (then-)Japanese emails, and skin tones were not specified. It were implementations that impose certain skin tones (that do not even match the original Japanese emojis) and as a result Unicode had to introduce a mechanism to change skin tones and mandate the default emoji without that mechanism to be neutral. RTL "modifiers" are actually formatting characters closely tied with the Unicode Bidirectional Algorithm [1]. Until then texts with both RTL and LTR fragments were handled incoherently, for example legacy character sets were still struggling with logical vs. visual order issues. So they are indeed Unicode inventions, but necessary ones that do not alter existing texts. For CJK characters Unicode now provides ideographic variation selectors that select the exact glyph (or more accurately, a restricted glyphic subset of the base character). They do not disunify characters but they do provide a strong hint to display those characters in a specified way. In this way they do not cause an additional issue to existing Unicode systems (as they should already do normalization and collation in the Unicode way). The disunification by comparison would almost instantly break existing texts. [1] https://unicode.org/reports/tr9/ https://unicode.org/reports/tr9/
    - account42 5y ago
      > Unicode had to introduce a mechanism to change skin tones and mandate the default emoji without that mechanism to be neutral. Adding skin tones was a choice, there was no immediate need for it.
      - musicale 5y ago
        The default seems to be yellow though, like original Lego minifigs (which I assume was one of the original plastic brick colors, and a nod to the bright yellow makeup that was popular at the time in Denmark.)
      - lifthrasiir 5y ago
        > there was no immediate need for it. You are incorrect. See the original design document [1] for skin tones and other diversity improvements, especially the "Sources of input" section. [1] https://www.unicode.org/L2/L2014/14172r-emoji-enhancements.pdf https://www.unicode.org/L2/L2014/14172r-emoji-enhancements.p...

In principle there is a designated "disunificiation" procedure when it's desirable. More accurately speaking, each CJK character is thought to represent not a single or a few glyphs listed in the code chart but rather a glyphic subset, and the disunification splits that set into partitions. But this is generally applied to a few selected characters and only when it's safe to do so. Massive disunification was to my knowledge never suggested or proposed, and that would surely prompt a large scale disruption throughout CJK users (say, how about existing texts?).

rrobukef 5y ago
So it's possible to modify the skin tone of emoji but impossible to disunify CJK characters? There are RTL modifiers for Arabic languages, it's impossible for CJK? It shouldn't be harder than existing unicode handling.
- lifthrasiir 5y ago
  Everything boils down to the interoperability and compatibility. Emoji was added because Apple and Google had to deal with (then-)Japanese emails, and skin tones were not specified. It were implementations that impose certain skin tones (that do not even match the original Japanese emojis) and as a result Unicode had to introduce a mechanism to change skin tones and mandate the default emoji without that mechanism to be neutral. RTL "modifiers" are actually formatting characters closely tied with the Unicode Bidirectional Algorithm [1]. Until then texts with both RTL and LTR fragments were handled incoherently, for example legacy character sets were still struggling with logical vs. visual order issues. So they are indeed Unicode inventions, but necessary ones that do not alter existing texts. For CJK characters Unicode now provides ideographic variation selectors that select the exact glyph (or more accurately, a restricted glyphic subset of the base character). They do not disunify characters but they do provide a strong hint to display those characters in a specified way. In this way they do not cause an additional issue to existing Unicode systems (as they should already do normalization and collation in the Unicode way). The disunification by comparison would almost instantly break existing texts. [1] https://unicode.org/reports/tr9/ https://unicode.org/reports/tr9/
  - account42 5y ago
    > Unicode had to introduce a mechanism to change skin tones and mandate the default emoji without that mechanism to be neutral. Adding skin tones was a choice, there was no immediate need for it.
    - musicale 5y ago
      The default seems to be yellow though, like original Lego minifigs (which I assume was one of the original plastic brick colors, and a nod to the bright yellow makeup that was popular at the time in Denmark.)
    - lifthrasiir 5y ago
      > there was no immediate need for it. You are incorrect. See the original design document [1] for skin tones and other diversity improvements, especially the "Sources of input" section. [1] https://www.unicode.org/L2/L2014/14172r-emoji-enhancements.pdf https://www.unicode.org/L2/L2014/14172r-emoji-enhancements.p...