Talk:Z-variant

message: Oh no. Now I will have to grep for two characters instead of one. Say where they keep the master list of them.
Mention if color/colour is like X,Y, or Z variants.
—Preceding unsigned comment added by 210.201.31.246 (talk • contribs) 16:34, 15 March 2006
: It's fundamentally impossible to unify Chinese so everyone will be happy. Like everything else in real life text processing, code is going to have to be sensitive to the issues, just like code is sensitive to casing issues. The Unihan file from the Unicode ftp site has some of this information.
: There's been enough bad analogies already. Making superficial comparisons to English isn't going to clear anything up; to understand the issue, you'll have to understand some of the concepts behind Chinese writing.--Prosfilaes 22:15, 15 March 2006 (UTC)
thread_title:  no more simple "grep 不" 

message: There might be some confusion as it's not always obvious how to precisely apply Unicode's definitions, sometimes looser definitions like the one on :wikt:z-variant might be used, and the Unicode itself isn't perfectly rigorous. But whatever the confusion is about, the section  seems to only add to it and make it more confusing to the reader. It shows two pairs of Unicode characters neither of which are z-variants of each other by Unicode definitions, and there is nothing in referenced Unihan database that would suggest otherwise. Yet it erroneously claims they are both examples of z-variants.
Code points  and  are compatibility variants, which means they do not differ on Z axis at all; they are identical on all the X-Y-Z axes. They are essentially considered duplicate encodings of the same variant that exist only for round-trip compatibility with KS X 1001 where K0-5D55 (61-53) has a reading  and maps to  while K0-5C74 (60-84) reads  and maps to  and both have exactly the same reference glyph. But  has both readings and  canonically decomposes to it. In many places it's not even possible to use  without it getting converted to . On the other hand, because the distinction exists only in Korean, the compatibility character  unambiguously refers to the Korean variant while  unifies all the other variants in addition to this one so it might be displayed slightly differently than  when font or language setting other than Korean is used. There is a standardized variation sequence  that can be used to select the  variant using  as a base character (your fontage may vary). Calling them font variants is certainly imprecise (not a Unicode term anyway), but you can see where it comes from.
Code points  and  are semantic variants which differ on Y-axis—their abstract shapes are not unifiable in the first place, so they cannot be z-variants. This pair is even explicitly mentioned in UAX #38 Unihan as an example of y-variants. The fact that the referenced draft mentioned these two as examples of "zVariant" shows how confusing it might be, but does it matter given that it never made it to the final version?
Can we get rid of the section? It makes no sense whatsoever in its current shape and I don't see how could it be improved. – MwGamera (talk) 14:45, 18 August 2022 (UTC)
thread_title:  Confusion?