Talk:Han unification

message: "This might make some sense because the Unicode is a vast improvement over the chaotic system of Chinese encoding, which contains two main systems (GB 2312 and Big5) and numerous variants and extensions."
:I don't like this sentence much. Not only is "vast improvement" POV-tastic, but the Japanese encoding situation is hardly less chaotic. You've got Shift-JIS, EUC-JP, and ISO-2022-JP, not to mention various other JIS variants. I'll probably remove this altogether unless someone has a better idea. DopefishJustin (・∀・) 03:38, 5 Jun 2004 (UTC)
replies: text: Please note that while Shift-JIS, EUC-JP and ISO-2022-JP are different encodings, they encode identical character *sets* (JIS X 0201+0208), with some minor exceptions. So it can hardly be said to be "chaotic". The Chinese situation is different in that GB2312 and Big5 developed entirely independently, and are not only different encodings, but also different *sets*. 221.254.245.147 08:48, 14 April 2006 (UTC)
thread_title:  POV phrase 

message: Thanks DopefishJustin for that paragraph - that is my understanding, too (though I'm not sure support for this is widespread enough.)
Similar issues crop up with things such as LATIN LETTER S WITH CEDILLA, which (by my understanding) should display as s-with-cedilla in Turkish texts and s-with-comma-below in Romanian texts since those glyphs were unified as one grapheme. However, a subsequent revision of Unicode included an explicit s-with-comma-below, so now there are two different characters vying for the role of the Romanian letter (similarly with t-with-diacritic), and there's controversy regarding which one of them is "correct". A sticky situation. -- pne 13:13, 6 Jun 2004 (UTC)
replies: text: It's just as you say with s-cedilla/s-comma and t-cedilla/t-comma. Due to the fact that encoding converters already mapped these characters used in Romanian to the cedilla variants, the specifically comma variants are rarely used. I'd bet that search engines and search & replace and spell-checking functions in most applications are also confused by the issue or ignore the new characters. Google didn't do well last time I checked. — Hippietrail 08:20, 8 Jun 2004 (UTC)

text: It's not really true that s with cedilla should be rendered as s with comma below in Romanian texts. I've got a Romanian book to teach children how to write, and I would think there of all places, they would go out of their way to get it right if there was a difference. But in fact, the book switches back and forth between s with comma and s with cedilla. The distinction, whether real or not, was pushed by the Romanian Standardization body, which is the only reason the comma-below variants were included. --Prosfilaes 05:34, 17 Nov 2004 (UTC)
thread_title:  Graphemes vs. glyphs 

message: What's with Vietnamese? Shouldn't there also be some information given on Chữ nôm script?
If there's anyknow knowledgable about this he or she might step forward and add something.
:The vietnamese variant of the Chinese script seems to be completely obsolete now, and so I guess it wasn't considered worth mentioning. 惑乱 分からん 01:24, 30 April 2006 (UTC)
thread_title:  Vietnamese 

message: this article doesn't give any information on the rationale for this descision when other visually identical and semantically very similar characters (e.g. some greek and latin stuff) where not unified. Plugwash 11:04, 21 April 2006 (UTC)
replies: text: See .--Prosfilaes 21:04, 25 April 2006 (UTC)
replies: text: Allocation of memory size seems to be an important part of it. 惑乱 分からん 01:25, 30 April 2006 (UTC)

text: By the way, greek and latin characters are given separate code points in Japanese (JIS) character sets, including characters such as 'A', and distinguishing between them is thus required for round-trip compatibility to JIS. Amusing, no? :-) 130.233.22.111 18:53, 17 May 2006 (UTC)
thread_title:  why 

message: After digging miscellaneous sources of information, it seems to me that there are many things that could be improved. In particular, a few times, only the less sophisticated criticisms of Unicode are addressed.
 
Now a few topics that could be improved:
* The Han-unification rules.
* The West-vs-East controversy, such as: "This rendering problem is often employed to criticize Westerners for not being aware of subtle distinctions, even though Unification is being carried out by Easterners". It seems to me, that this controversy (including some Japanese criticisms) must go further than just simple pleasure of criticizing Westerners:
** First, a clarification, it's unclear to me to what extent, Unification has been carried out by Easterners - I already corrected the text, to the effect that the decision to use Unification was taken by the Unicode consortium (California-based American companies), and then got endorsed by ISO, as apparently as a collateral damage of the push for the merge Unicode and ISO; as you can guess from , Han unification did not seem to be a major topic of the merger - the only time, where it could have been removed. Second, even though everywhere it is written that unification is carried by Easterners in several places, the history of Unicode shows clearly that the first Unicode unification database was created by those companies . Was it thrown away, and re-created from scratch by IRG? If not, it seems to me only half-true to claim "it is carried out by Easterners". See also: 
** Second, if you look at history, CCCII character set actually predates Unicode. The message  includes a passing mention that it was used later as basis for the American EACC by the RLG  but with the axiom "one glyph = one code". Later RLG was involved in the Unicode, Unihan unification. Why is this relevant, you may ask... well the point is that CCCII includes a feature (namely the character/variant/glyph property, see below), which is sometimes advocated as superior . This puts a new light on the West-vs-East controvery, since you can argue that: some Westerns took an (Asian) Taiwanese standard, CCCII with good features, modified it, removed some good features, created a new standard without feedback from the initial Asian experts (Unicode-pre-1990), and strong-armed international organizations (precisely ISO), into accepting it (with the merger), and later delegated the task of figuring out the details to a subgroup (of ISO: the IRG). Hence the legend that Westerns didn't understand Asian languages well, and messed up.
* Non-unification: the article did not mention non-Han unification as a possibility. In fact it is perfectly possible to perform no unification: this is the approach of ISO-2022 where character sets are not unified . Escape sequences are used to switch between characters sets (for instance switch to this Japanese standard, or this Chinese standard). There are drawbacks but also advantages. Hence ISO-2022, even though it is not popular, deserves some mention (I added it). After all, like all design choices, the decision of Han-unification can be best appreciated, not only by its own advantages/drawbacks but also by those of the alternatives. 
 
* There are several issues about the principle of differenciating the concept of character from the concept of glyph (this is for the Controversy section):
** As mentionned in the article, there is some misunderstanding because Unicode publication was only showing some glyph versions of the Chinese characters, which caused people to assume that they were the mandated representations. Unicode aims at giving a code to a character only, and the idea is that a Japanese font would be used for Japanese text, a Chinese font would be used for Chinese text, ect...
** This is reinforced by the fact that, Japanese text, and Chinese text, for instance, use different styles (different fonts) even for identical characters. Hence, to properly represent a text to a Japanese, it is not only necessary to properly display the characters which look different, but even all the other characters should be displayed in with a Japanese fonts. This would call for not only dis-unifying Japanese versions of the variants, but in fact, total dis-unification of the Japanese/Korean/Chinese (with software problems: what happens if in a WYSIWIG editor, you select Chinese text and change the font to some Japanese font? On the other hand, according  there are some fonts universally acceptable in CJK countries. Then you would want to have the Japanese-version of some character, and the Chinese-version of the same character in the Universal font. For which Unicode isn't enough.
** This "universal CJK font" problems, hilights the problem of the "character/glyph" principle: in an universal font, you would want two versions of the characters. And indeed, in view of the older standard CCCII (using it even before Unicode was on the drawing board), a better principle could have been "'One Character has one or more Variants, which have many Glyphs'" as indicated in  with the comment "Unfortunately, many of those arguing in favor of Unicode have, historically, been non-users of Han characters who have tended to just assume that differences between character variants are generally insignificant display-level details, like differences between fonts". Then then the Japanese-version, the Chinese simplified-version, the Chinese-traditional version, the Korean version, could be variants of the same characters (when different). Each variant would have exactly one different glyph in an universal CJK font. A Japanese font could include the same glyph for all the variants. It is not clear, however, if one can draw definite boundaries.
** The consequences of Han-unification are also an issue: it is not possible to have "plain text". "Plain text" appears in places such as filesystems (directory and file names), or Web forms (even though there is some locale information exchanged at HTTP protocol level). It creates additional problem for information exchange (for instance, cut and paste between applications), as the language (font?) should be exchanged along with the Unicode string data. It is not possible to create an Unicode font (as mentionned previously). 
::: Sure it is. You just have to accept either a Chinese font or a Japanese font, and as you agreed above Japanese users tend to write Chinese in Japanese texts using Japanese fonts. This isn't true for Fraktur; English or Esperanto or French in German or Norwegian Fraktur texts were always typeset in Roman, never in Fraktur.--Prosfilaes 06:28, 10 August 2006 (UTC)
replies: text: The point is "plain text" doesn't have information to select the variant, how to write "黛" for instance. Of course, you're right, everything can be displayed in a way of another. --213.41.133.220 23:41, 13 August 2006 (UTC)
replies: text:  OpenType instead of Unicode????? What is that supposed to mean? Mlewan 11:07, 10 August 2006 (UTC)
replies: text:  Actually not "instead of", but "in complement of" it, additional mechanisms - such as those present in OpenType - allow the choice of a proper variant based on some context (language, ...): . --213.41.133.220 23:41, 13 August 2006 (UTC)

text:  That's not at all true. Simplified and traditional characters aren't unified, because they're different.--Prosfilaes 06:28, 10 August 2006 (UTC)
replies: text:  Ok I stand corrected, only "identical" character are unified (and normally not those who one or a few different strokes). Also, I checked  samples on several dozen Chinese[Simplified/Traditional]/Japanese fonts... one conclusion, is that some of the critics of the page are in fact due to sometimes to poor quality of the font used for the Unicode site for some characters, since the other Chinese and Japanese glyphs for the character look pretty similar otherwise. Second conclusion, is that indeed there is some amount of variation in Chinese fonts (Ming, Song, Hei, Kai, ...), but little in the Japanese fonts (Mincho, Gothic): hence it makes complete sense to unify the character for Chinese... (since it is exactly the same character from the same language in a different font). Then quite often the Japanese variant looks very similar to one of the Chinese fonts variant (exception I found: "黛"), so I guess the logical conclusion is to unify also as Japanese and Chinese characters are in the same code-space. This means that unification in one language can have implications for the unification of another language OR result inconsistent mapping to duplicate characters. -- 213.41.133.220 23:41, 13 August 2006 (UTC)
thread_title:  Reassessing the content of the page 

message: What is "generic Chinese"? I understand that other columns are different national standards, but what is "generic Chinese" supposed to be? --Voidvector 01:35, 28 June 2007 (UTC)
replies: text: I believe it's labeled as "generic" because the language given in the markup is simply "zh" (Chinese) as opposed to "zh-Hans" (specifying Simplified) or "zh-Hant" (specifying Traditional).  Nothing in the article explains this, I had to view the source to figure it out.  I suppose it should be clarified, but these are my own assumptions...   In my browser, an unqualified "zh" defaults to Simplified. 198.175.154.212 (talk) 16:01, 25 January 2013 (UTC)
thread_title:  Generic Chinese? 

message: Article says that "入" (enter) has different variants which are not encoded into Unicode. Then it goes onto say something like "内" (simplified Chinese) and "內" (traditional Chinese) are derivatives of the before mentioned character. As far as I know, this is wrong because: 
 入 (enter)　+ 冂 (a radical) = 內 (inside, traditional Chinese) 
 人 (person) + 冂 (a radical) = 内 (inside, simplified Chinese)
--Voidvector 02:22, 28 June 2007 (UTC)
thread_title:  Wrong statement in the article about "内" 

message: Hey, this page is interesting, but the character comparison tables are tto dependant on the reader's font. For example on Linux ubuntu 7 with Firefox, many characters are the same. The other problem is that the browser will use two fonts with different design (say a thin "pencil-like" one and a square "print-like" one) to render the subtle differences between C,J or K versions, so it is not clear at all. Having someone with good full unicode font making a screen shot and uploading this to the article would certainly help a lot. Just a suggestion.  —Preceding unsigned comment added by 220.231.37.106 (talk) 04:36, 4 June 2008 (UTC)
replies: text: Yeah, it would be very helpful to have at least some of this comparison be an image or SVG. In my browser (Firefox on Debian), the 5 columns in the "examples" section are identical for all characters. --Delirium (talk) 14:01, 15 February 2009 (UTC)

text: Agree. I tested 3 Windows browsers (Firefox, Chrome and Internet Explorer 8): The five columns are exactly the same in all three. Firefox shows "pencil-like" strokes, Chrome shows "print-like" strokes (comparable to sans-serif if you like), and IE shows nothing at all, just empty squares. Alvaro --79.145.92.180 (talk) 22:25, 6 December 2009 (UTC)

text: I also agree. When I first loaded this article, all I got were boxes. So I found the article on getting CJKV support, followed all the steps, and... now all the characters in the different columns look the same. XP SP3, FF9. 173.206.137.186 (talk) 21:34, 22 January 2012 (UTC)
thread_title:  Make those characters pictures 

message: The Unihan database makes reference to "ku", "ten", and "min". "kuten" means row and column of JIS tables but "min" does not seem to be defined anywhere on the unicode site or on Wikipedia. It is used only for later versions of JIS. Could there be 3-byte JIS standards where "min" means page? — Hippietrail (talk) 04:58, 8 January 2009 (UTC)
thread_title:  kuten and min 

message: This whole article and discussion strikes me as a bit like spitting into the wind. The Unicode Consortium has been trying for over a decade to get anyone in Asia to pay attention to it. So far the silence has been deafening.
I once beta-tested a text-to-speech package's Chinese support, only to discover it spoke in gibberish because the developers only knew Unicode. At the time, real-world Chinese unicoded websites were scarcer than bikinis in January. Five years on, there's still no traction for unicode over here. Baidu.com, Asia's largest search engine, is GB. Xinhuanet.com and News.cn, Asia's largest news sites, are GB. Popular blogging sites such as Club.Tianyablog.com are all GB. (Substituting Big5 for GB, in Taiwan the situation is largely the same.) It's unicode support notwithstanding, Microsoft ships Chinese versions even of Windows 7 with GB support.
What's the point of Unihan if no one uses it?
Nathanael (Taiwan/Shanghai)  —Preceding unsigned comment added by CNJECulver (talk • contribs) 21:10, 15 December 2009 (UTC)
thread_title:  Tilting at windmills? 

message: Parts of the "Graphemes versus glyphs" section seem to convey the POV that "Unicode doesn't really do what they think they do". For instance:
:With the unified Han ideographs, the Unicode standard makes a departure from prior practices ... not simply explained by the oft quoted distinction between an abstract character and a glyph ... consider Unicode’s unification of punctuation and diacritics, where graphemes with widely different meanings (for example, an apostrophe and a single quotation mark) are unified because the graphemes are the same.
Now, I don't know of a single example of "unified appearance" punctuation or diacritics except  vs. . (Unless you want to count diacritics that are defined by their form, like . But that's a whole other issue, viz. "do these marks have any 'identity' to encode besides their shape?".) In short, the whole "sememe" section smacks of original research, stating a POV rather than describing it from external sources. It has two footnotes, which are not references supporting the claims; one is further explanation of a point, and the other is a reference in support of statements about Unicode's goals, rather than in support of the claim that Unicode failed to meet a goal. -- Perey (talk) 18:26, 2 March 2011 (UTC)
thread_title:  "Graphemes versus glyphs" revisited 

message: I tried adding Vietnamese characters to the charts, but reconsidered. For the other languages, the language tag is the only font identifier. But for Vietnamese, this displays the default font, i.e. simplified Chinese. Here are the "language-dependent characters" in various fonts, so you can judge for yourself:
:与今令免入全具刃化區外情才抵次海画直真空草角道雇骨 (default)
: (lang|vi)
: (lang|vi-nom)
:与今令免入全具刃化區外情才抵次海画直真空草角道雇骨 (HAN NOM A)
:与今令免入全具刃化區外情才抵次海画直真空草角道雇骨 (Nom Na Tong) Kauffner (talk) 07:46, 6 April 2013 (UTC)
replies: text: () BabelStone (talk) 12:49, 6 April 2013 (UTC)
replies: text: Cool. In other words, it brings up Nom Na Tong now. We can certainly do something with that. Kauffner (talk) 13:37, 6 April 2013 (UTC)
replies: text: It only works if the users get informed they have to install certain fonts to get the correct output. This means that the  template has got to be written. It is already included at the top of at least four article, but at this point it has no effect.
LiliCharlie 16:04, 6 April 2013 (UTC)
thread_title:  Vietnamese 

message: We have the language dependent character chart to compared fonts. So the non-unified ideogram chart should focus on comparing character variants with different codepoints using a single font. I rewrote it so that every character on this chart now appears in the default font. The earlier version of the chart showed how non-Japanese variants looked in Japanese font, non-Chinese forms in Chinese font, etc. I don't any of that was helpful to readers. Kauffner (talk) 08:50, 8 May 2013 (UTC)
thread_title:  Revised chart of non-unified characters 

message: There is currently a problem in Examples of language-dependent glyphs in that there is a mismatch between some of the codepoints and characters. For example the codepoint U+49FE matches the character (䧾) but the character used (者) has a codepoint of U+8005. I have left HTML comments that may be helpful in correcting this. Regards. – Allen4names (contributions) 18:19, 16 February 2016 (UTC)
thread_title:  Codepoint problem 

message: I am author of a project dedicated to normalizing the Unihan database, unihan-tabular. The project lives at https://unihan-tabular.git-pull.com/. It is about 4+ years old and permissively licensed.  I think this project is helpful to those who want to utilize the database's information, and it's goals are similar to libUnihan, which the article currently mentions. However, I am not sure how to gauge its relevance compared to libUnihan, since this is a niche area, and two, I am the author, so wanted to see what people thought first. --Git-pull (talk) 05:36, 22 May 2017 (UTC)
thread_title:  May I add a link to a project of mine? 

message: Wikifresc, your most recent edit causes all Chinese, Japanese, and Korean characters to be displayed using the same font in all browsers. (All except Vietnamese are now in HanaMin on my Firefox; Vienamese is excluded here because the  template defines its own fonts and overrides your font definitions.) This is so because your general, table-wide font definitions override font definitions of browsers, whether they are language-specific or not. For this table you must either define fonts by language (e.g. using code like *:lang(zh-Hans) { font-family: "MySimplifiedChineseFont", sans-serif; }), or not at all. Otherwise browsers will accept the specified font for any language if it provides gylphs for the character to be displayed, and only try to use language-specific glyphs if defined in this particular font, see https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#language-specific-support. A comparative table where all items to be compared look the same makes no sense. Love —LiliCharlie (talk) 17:59, 2 April 2019 (UTC)
thread_title:  Font and language markup in comparative Han character table 

message: …so as to be accurately displayed, independent of fonts or browser.--158.174.187.223 (talk) 16:10, 16 December 2020 (UTC)
replies: text: In February 2016 I created a scalable vector graphic for the corresponding German Wikipedia article Han-Vereinheitlichung. It shows typical national designs of the 27 characters and four locales that illustrate glyphic variation there. If two or more English Wikipedia users ask for a similar illustration of the 27 characters and six locales of our "Examples of language-dependent glyphs" table I am going to make it using the Han-Nom Gothic font for Vietnamese and localized Noto Sans CJK fonts for the rest. Love —LiliCharlie (talk) 06:32, 17 December 2020 (UTC)
replies: text:  I'd like to note my strong and fervent agreement! If ones fonts and/or browser doesn't "cooperate" with the article, then the current table will not be accurate, and will only serve to misinform.--155.4.221.27 (talk) 06:43, 1 November 2022 (UTC)
replies: text:  Agreed, preferably an English version image. EnTerbury (talk) 23:16, 24 March 2024 (UTC)
thread_title:  The examples need to be in the form of images 

message: Should zh-Hant column be replaced with zh-Hant-TW? I assume zh-Hant-HK was added later. Given that TW & HK have differences, "traditional Chinese" is ambiguous in the context of this article. --Nidaana (talk) 03:06, 1 April 2023 (UTC)
replies: text: Something should be done about it, they render the same on my end. EnTerbury (talk) 23:15, 24 March 2024 (UTC)
thread_title:  zh-Hant