text:
Talk:Han unification

Quick Fix, unsure of edit documentation
There is a comment in the page referring the disambiguation of the apostrophe and the single-quote character in Latin charset. That was resolved in Unicode 2.1: http://www.cs.tut.fi/~jkorpela/latin1/3.html#27 Suggetion: either remove the paragraph or identify another instance. (and then delete this section of the discussion.)

Check your browser
The "check your browser" section is a good idea, and it works fine on my browser, Mozilla 1.6, except that the two lines remain size 16, and the two lines of larger text overlap. Is there a way to increase the space between the two lines? I don't understand the markup method that is used to make that table. Gus 17:47, 2004 Apr 5 (UTC)

 * It's a bug in your browser. It is not necessary to specify the row height, because good browsers set it automatically so that all text is visible and there is no overlap. The table markup may be found here: and here: . — Monedula 21:59, 5 Apr 2004 (UTC)

It would be very handy to also include an image of the correctly rendered different versions so we have something to compare our browsers/fonts/OSes/rendering systems against.

 * What I really don't understand is what the output is supposed to look like. The first column has ma (horse) as a simplified character. The author wasn't expecting it to magically transmute into the "traditional" glyph in a Taiwanese font, was he? Why bother with what the simplified glyph looks like in a traditional font, or vice versa? It's like testing how your browser handles Cyrillic with a language tag of "English" — it makes no sense at all. — ajo, 21 Dec 2004

 * It's not ma (马), it's yu (与). No horse at all. — Monedula 11:40, 21 Dec 2004 (UTC)

 * Whoops. Isn't that still a simplified character? — ajo, 22 Dec 2004

 * Yes. The "Taiwanese font" thing is a red herring, though; the comparison is intended to be between Simplified Chinese (horizontal line at the bottom left, much like the simplified "ma") and Japanese (horizontal line longer, crossing the hooked line at the bottom right). -- pne 15:10, 26 Jan 2005 (UTC)

Also does anybody know if there exists a list of all such disputed characters? I think it would be a good idea to include them here too. Unless of course there are thousands, in which case a link would do. — Hippietrail 02:59, 2 Jun 2004 (UTC)

 * I don't know of such a list; I just added ones where I knew or thought that Chinese and Japanese differed in preferred style. I imagine some users will have created partial lists, but I'm not sure whether an "official" list exists. (There are undoubtedly lists of where Chinese, Japanese, and/or Korean source characters were merged, but I imagine they give no information about whether the forms were identical, similar, or "different but not different enough to consider them separate characters"—which is what we're after here, I believe.) -- pne 10:00, 2 Jun 2004 (UTC)

 * The link given in the article has a partial list. There do seem to be quite a few so they probably shouldn't be exhaustively listed here. DopefishJustin (・∀・) 02:35, 5 Jun 2004 (UTC)

I'm not really sure why but 10th character of Japanese kanji appears as a rarely used one for me. The one from Chinese generic character is more commonly used. Revth 03:23, 28 Jun 2004 (UTC)

Another observation: My browser (Firefox 1.5.0.1) renders the lines with identical fonts. However, when I move the table to a HTML document (not XHTML), differences appear. Funny... 84.189.186.5 01:22, 15 March 2006 (UTC)

POV phrase
"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)

 * 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)

Graphemes vs. glyphs
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)

 * 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)

 * 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)

Request for Explanation of Variants
I've just learned of the existence of "Z-variants" in Unicode. It's very difficult to find good explanations of what they are exactly, and whether it is another name for a "glyph variant", a type of glyph variant, a seperate issue to glyph variants entirely. Is it always a different issue to simplified vs. traditional or is the line blurred?

From what I can find, Unicode wanted to be able to convert to and from the major existing CJK character sets unambiguously. Some of these sets have two codepoints for what Unicode considers to be the same character. In these cases, Unicode also provides two codepoints. One is considered the usual codepoint to use, the other is considered a Z-variant.

I bet it's more complicated than that. I have requested an article Z-variant to make it clear. — Hippietrail 01:09, 27 Jun 2004 (UTC)

 * I haven't heard that term before. Unicode has what are called CJK Compatibility characters, which are in separate blocks and are only supposed to be used for round-trip encoding conversion purposes. Unicode 4.0 also introduces variant selector characters, which go after the normal character to provide a standard way of indicating that a particular numbered variant is needed, although few variants have been defined so far and I don't think anything supports it yet. DopefishJustin (・∀・) 17:46, Jun 27, 2004 (UTC)

 * Here's one extract from a document about Internationalized Domain Names:

Could someone also write about the difference between the traditional form 夠 and the simplified form 够 and why they look so similar? — Preceding unsigned comment added by Armantamzarian (talk • contribs) 15:41, 18 February 2020 (UTC)

 * They are variant characters before modern time. China and Taiwan simply standardized on different variations. See this blog in Chinese --Voidvector (talk) 16:35, 18 February 2020 (UTC)

Unicode encodes simplified and traditional glyphs separately
This is in part because Unicode encodes simplified and traditional glyphs separately (e.g. the ideograph for "dragon" is 龍 U+9F8D for Traditional Chinese and 龙 U+9F99 for Simplifed Chinese), because, in the general case, the glyph forms are distinct.

I would very much like to see a clearer statement on why Chinese was encoded into two entirely separate glyph sets, whereas Japanese got Unified. The argument used for justifying Unification is the Japanese "misunderstanding" of Unified glyphs, which supposedly do not require separate codepoints - even though that's exactly what was done in splitting Traditional and Simplified Chinese. It's pretty obvious that there must have been a not inconsiderable amount of politicking going on in the Unification process to end up with what we have now, in which case that should be noted rather than just dismissing the Japanese opposition to Unification as a "misunderstanding" on their part. 221.254.245.147 09:01, 14 April 2006 (UTC)

Has anyone a number for the cases where there is a separate simplified short sign encoded? --Pjacobi 10:01, 17 Nov 2004 (UTC)

Don't have a number, but this wikipedia page have a unicode traditional to simplified chinese (in chinese): http://zh.wikipedia.org/wiki/Wikipedia:%E4%B8%AD%E6%96%87%E7%B9%81%E7%AE%80%E4%BD%93%E5%AF%B9%E7%85%A7%E8%A1%A8

While Unicode Unify Japanese and Chinese characetrs, Simplified and Traditional Chinese are mostly separated with thousands(?) of duplication.

If 紅 U+7d05 and 红 U+7ea2 count as two characters (graphemes?) than the Japanese version of 草 U+8349 should be encoded differently. 纟 is just the "cursive" version of 糸, just a metter of calligraphy style. but in unicode all characters with the 糸 side also have a 纟 version. With that as precedent, characeters with 䒑, 艹, 艹 or 艹 should be encoded differently too.

 * A lot of what was and wasn't encoded in the BMP is due to what was encoded by the source standards and was really out of Unicode's hands. It was probably encoded that way for compatibility only. Don't try and use it for precedent. --Prosfilaes 06:58, 6 Jan 2005 (UTC)

 * So you argee there is a problem right? Lets do the finger pointing later. --Thu Jan 6 17:48:49 UTC 2005

 * There's a problem, because Unicode has to work in real life. If Unicode could have thrown out the old standards, it wouldn't have this problem. The point was, you can't use those as examples for what should be done, because they weren't supposed to be there in the first place. --Prosfilaes 03:54, 7 Jan 2005 (UTC)

 * The "lang" HTML attribute doesn't work in general like in plain text file right? The page claim "Note that most of the opposition to Han unification appears to be Japanese, because of increased sensitivity to the distinctions between Chinese and Japanese styles of letters. There has been very little opposition from Chinese speakers." The point is, Japanese got unified into Chinese, but unicode did NOT apply the grapheme philsophy to chinese at all. I can see why most Japanese object. Historical reason is not important here. For Chinese, Unicode is consider politically neutral because it's neither big5 nor gb not because of unihan. For that matter, OSs and programming languages support Unicode have notthing to do with unihan either. In any case, Chinese web sites use big5/gb not unicode. --Sat Jan 8 10:52:05 EST 2005

 * The question about plain text files is not beauty, it's the pure information with no font information. Virtually every type of marked up text includes some sort of language tagging. Unicode did apply the grapheme philosophy to Chinese; look at . Just because you don't agree with all the points, doesn't mean they didn't apply the policy. Historical reasons of course matter; you have to take everything in context. You can't demand that Unicode is broken because a character set that would have been useless in real life might have done something in a more ideologically pure method. --Prosfilaes 20:51, 8 Jan 2005 (UTC)

Here are just a few more samples (For the "Check you browser" section?) :

 * To be honest, I see zero difference between the rows other than what can be accounted for by typographic, stylistic variations. --Wing 14:20, 12 Feb 2005 (UTC)

Grapheme philosophy
I edited the page to remove the emphasis on the "controversial" philosophy of graphemes. As far as I know, every character standard defines the characters and not the precise shapes; that is, there can be more than one font. Simplified characters aren't a violation of the grapheme philsophy; page 11 of the Unicode standard says "These are both part of the IRG G-source, with traditional forms and simplified forms separated where they differ.". Unicode recognizes the concept of the limits of how much a character may vary and tries to use that to seperate characters in graphemes. --Prosfilaes 03:54, 11 Dec 2004 (UTC)

The problem is Unicode did NOT apply the grapheme philsophy to chinese at all. For example, 內 U+5167 is big5 #A4BA 内 U+5185 is GB #3658, 丟 U+4E1F big5 #A5E1 丢 U+4E22 gb #2210.

In fact, if multiple font set is part of the unicode design, there should be well defined method within unicode to specify country/language code without using html/xml "lang" attribute. -- Somebody

I'm not sure what you're trying to say here. Is your claim that those characters are not distinct in any character sets Unicode is round-trip compatible with, and that there are many more of such characters? As such the big5 and gb code points you list seem irrelevant. BTW, there is a way for specifying language without using external tags, though its use is discouraged in preference of proper tagging (Unicode is supposed to be plain text character set, not a rich text format). Considering that this is a FAQ and you seem ignorant of it, your assertion that the makers of the Unicode standard systematically ignored their own rules in classifying Chinese characters is rather suspect. 130.233.22.111 18:13, 17 May 2006 (UTC)

--213.41.133.220 03:52, 4 August 2006 (UTC)
 * The grapheme policy is not controversial, but saying things like the "Japan Kanji for Horse is just the Chinese Hanzi for horse, but written in a different font", is controversial. There is a whole possible continuum of changes of Hanzi so if you ever start to draw a limit, it will be arbitrary, and hence can never be fully satisfactory. So the opposite question, is why do we *need* Han unification? The initial motivation is clear, the people involved in Unicode (see first version 1988), wanted a 2-byte coding, hence Han unification was critical (and maybe necessary); and probably become the pet project of the initial Unicode designers. But that was lost, and worst, with the famous UTF-8 encoding, most Japanese Kanji need 3 bytes as far as I understood, so that reason is dead and buried.
 * What is controversial in my opinion, is that Han unification using the grapheme policy using was completly decided by the initial Unicode team, which included mostly American companies and organizations, way before Asian gov. representatives participated. But at the end of the day, only CJKV governements could legitimaly make decisions, so the good way would have been to grant different code ranges to each CJKV government, and later, as a optional bonus perform Han unification identification, for applications that need it.
 * What is very controversial is the *consequences* of the grapheme policy. If the same character is visually different in Chinese and Japanese, so as to be rejected by some people using one of those languages, then you cannot mix easily them. Hence you can't use Chinese and Japanese file names with UTF-8, and then properly display the list of the files. That's *BROKEN*. That's the exact reason why Unicode allocates different codes for different characters: you are no more supposed to mix Chinese and Japanese, than to mix Thai and Greek, so why not just reuse the Greek code for Thai, and leave external mark-up to decide if you are using Thai or Greek... i.e. why not codepages then ? Unicode tries to evade the issue by saying text isn't supposed to include language information, but the fact is, it should include enough information to represent it properly without ambiguity, and if that information is language, then it must be there, otherwise there are very annoying consequences. I don't understand how people can be happy with forcing those nasty consequences in the throat of the world, just because Han Unification happened to be the pet project of some American software engineers based on bogus 2-byte design constraints, while there is a simple alternative: no unification per default.

 * Thai and Greek is a bit of a strawman, since there's no connection. Unicode engineers have pointed out that Chinese quotes in Japanese texts are often in the same fonts as the surrounding texts, and Han unification follows the same principles as not including Fraktur as different from Latin.--Prosfilaes 05:46, 4 August 2006 (UTC)

 * Yes, but Chιnese, Japanese or even sometιmes Greek quotes ιn Eυropean texts are usιng the same font as surroundιng text for theιr roman transcrιptιons (be ιt Pinyin, Romaji, ...); that does not mean that the resultιng transcrιptιon ιs a 100%-acceptable way to wrιte normal texts ιn the original languages. I've never seen a Japanese booκ wrιtten in Romaji for ιnstance. So this argυment does not address the issυe that the υnified character does not have a representation that sυits every langυage that υses it.
 * The point about Fraktur is an excellent example, Antiqua is nowadays an accepted way to render text written in Fraktur and besides many books were printed indifferently with Antiqua/Fraktur fonts, because the underlying language, grammar, syntax, words and letters are identical since they are those of the German language, so it is really just a font. But Chinese is not written indifferently with Chinese/Japanese fonts (because there are many missing Hanzi characters). Japanese is not written indifferently with Japanese/Chinese fonts (because Chinese has no katakana, hiragana for starters).
 * So my point is not a strawman: the fact that there is or not connection between some Kanjis and Hanzis is irrelevant (except as an interesting academical exercice), what is relevant is whether there is a representation which can be 100% fully accepted by all users of the character. If there is no such representation, then the *consequences* of artificial unification (have to put stupid language markers in some way, somewhere) would be exactly the same as the consequences as articifically unifying Thai and Greek characters (by simple reuse of the code range). Annoying consequences.
 * Also you correctly underline that the Unicode group was consistent in following its principles. That's true, but then Unicode principles are broken. Indeed, the design blunder was to rigidly stick to academic principles when the only major principle that should be keep is to make Unicode easy to use (i.e. no annoying consequences). There was a quite pratical alternative to Han unification: no Han unification (and if necessary, have a sub-group working on identifying connected characters).
 * --213.41.133.220 14:41, 4 August 2006 (UTC)

 * Ok, I have reviewed a little bit of the point of views of the issue - and in fact it turns out that this issue is more complex, but much of it is not covered here ; a starting point is --213.41.133.220 03:42, 10 August 2006 (UTC)

about the character 'grass'
The character given in the text 草 is not the one with three or four strokes that the IBM article was referring to. As a single character meaning grass, it should look like 艸, a variant of 草 that has been abandoned in simplified Chinese, and is rarely used in print in traditional Chinese (I think). Though it is rarely seen as a character, it is a very common radical indicating 'plant,' and most of the time appears on top as 艹 (three strokes). In traditional Chinese, all those characters that have this radical should have the horizontal stroke broken right in the middle, making it a four-stroke radical. But I have never seen it on computer for some reason... --Liuyao 08:19, 11 Dec 2004 (UTC)

艹 and/or 䒑 are 3 strokes radical "grass", 艹 and/or 艹 are the 4 strokes.

 * 艸 = 艹 both are radicals, not a character. 草 is a character listed under 艸 Kowloonese 02:23, Jan 27, 2005 (UTC)

 * Not exactly; 艸 is both a character and a radical, and is the original (ideographic) form of 草 (which is a hybrid ideographic/phonetic character) but is rarely, if at all, used nowadays. I have an old dictionary which consistently uses 艸 instead of 草 (plus other archaisms, for example: 葉 for 頁 which is now used afaik only by librarians; or 括弧 for 括號 which is now used afaik only in colloquial Cantonese).

 * But then 艸 of course has 6 strokes, not 3 or 4... --Wing 18:14, 12 Feb 2005 (UTC)

 * I stand corrected. 艸 is a character and a radical and it has 6 strokes. 艹 is counted as 4 stroke.  For example, 艸 and 艾 are both listed as 6 strokes.  草 is 10 strokes, though you first have to look up the 艸 radicle listed as 6 strokes and then add the additional 6 strokes.  But 6+6=10 in this case because 艸 loses 2 strokes when it becomes the radical 艹.  Kowloonese 01:41, Feb 18, 2005 (UTC)

 * This conversation missed an important point. The quoted text correctly explains that Unicode does not define the glyphs associated with code points, but then goes on to say that " ... there is only one Unicode point for the grass character ( 草, )".  A glyph should not be shown here, because it implies that Unicode defines the glyph. I've removed it. Leotohill (talk) 18:06, 4 December 2008 (UTC)

Vietnamese
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)

why
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)

 * See .--Prosfilaes 21:04, 25 April 2006 (UTC)

 * Allocation of memory size seems to be an important part of it. 惑乱 分からん 01:25, 30 April 2006 (UTC)

 * 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)

biased page
why does this whole article read like an apology for han unification? fact of the matter is, a double standard is being applied. chinese don't care because their style of characters are the ones being used, not japanese. why didn't they take the same approach with japanese as they did with traditional chinese and simplified chinese? in most cases (like 99.9%) in traditional and simplified chinese, the characters and combination of characters even mean the same thing, but in japanese, the meanings diverged a lot.

also what is the point of saying east asians are the ones doing han unification? of course there aren't western experts capable of doing this kind of research. all you're saying is you paid people enough money that they'd do this for you. how does this mean that east asians accept what you're doing? --203.70.98.28 17:28, 3 June 2006 (UTC)

 * The meanings of Latin characters have also diverged a lot. The meaning is irrelevant. Traditional and Simplified Chinese aren't disunified; only those characters that are fundamentally different are disunified.

 * Unicode isn't paying anyone to do this; most experts are paid by their national governments if at all. It's hardly true that East Asians believe such and such; many Chinese have no problem with it, and I've met a Korean online that was annoyed at how disunified Unicode Han was. It's far from black and white.--Prosfilaes 17:41, 3 June 2006 (UTC)

Reassessing the content of the page
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)

 * 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)

 * The answer to the Unicode font argument, is that Unicode should not be used, but instead systems like Open Type. On the other hand, that does not prevent people from creating Unicode fonts: witness w; if they are out in the wild, people would have to cope with this.
 * OpenType instead of Unicode????? What is that supposed to mean? Mlewan 11:07, 10 August 2006 (UTC)
 * 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)

 * Inconsistency: as said, the Chinese simplified and traditional characters are not unified when different, even though they are clear-cut candidate for unification. They escape unification because of the round-trip conversion principles. But still this inconsistency make the whole Han-unification incoherent - if a Japanese character had a variant identical to a Chinese simplified character, then the Japanese variant would be have a code allocated for it, otherwise not. This makes differences in the characters inside the same country more important than differences of characters between different countries. In addition, judging from there are not so many Japanese variants, the question of why not have separate code for Japanese variants is unclear.

 * That's not at all true. Simplified and traditional characters aren't unified, because they're different.--Prosfilaes 06:28, 10 August 2006 (UTC)
 * 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)

--213.41.133.220 06:13, 10 August 2006 (UTC)
 * In fact, judging from some dis-unification is actually being carried out, to handle properly names at least.
 * Useful references:  "Michael Kaplan's" Blog, Unicode topics

on the check your browser section again
I'm wondering if this is all that useful. Does any browser change the glyphs depending on the specified language in the text? Perhaps a smaller table with fewer collumns would work better. Then we could use images to illustrate the way a particular Unicode code point would have different glyphs for each of the languages/locales. I don't have the language background to produce this, but I might be able to find some references that do it. Again, I think just enough columns to cover the normal width of the article (maybe 5 or 6). Then use image files instead of text characters to show how the different characters are rendered in each language. Then there could be a follow up table that just had the text. But as I said, I'm not aware of any browser that makes these sorts of glyph changes based on the language tags. —The preceding unsigned comment was added by Indexheavy (talk • contribs) 07:19, 5 May 2007 (UTC).

 * Firefox changes the display depending on language. I think there are more browsers where it works. You are right that the table is growing a lot. One solution might be to
 * a) create a separate page. "List of Language dependent Unihan characters" or something like that.
 * b) rotate the table so each language gets a column instead of a row.
 * Using images may be tricky as the look depends on which fonts you have installed. To keep a consistent look, we would have to decide which font to use, and there is not one single Asiatic font which is installed by default on all operating systems.
 * However, we could have one or two examples with images for users who do not have browsers where the language tag works. Mlewan 08:45, 5 May 2007 (UTC)

 * I think transposing the table is a good idea so that the languages become columns and the separate characters become the rows. I'lll probably go ahead and do that if there aren't any objections. However, what I think the article needs more than a 'check your browser" section, is a demonstration of how the glyphs differ in the different languages. With an image we have control over that sort of glyph display. With text, its anybody's guess what a reader sees when they load this article. Just looking at the first code point: U+4E0E (which according to the Unihan database means "and; with; to; for; give, grant"), I see very little variation in the glyph in Firefox on Mac (perhaps Fireforx on Mac doesn't select the correct font the way it does on Windows). So neither this glyph nor and none of the oters, have any significant difference from one row to the next. The glyph variation as I change fonts on my system is much greater than the differences displayed in firefox. I would imagine that there are some good examples of ideographs that would appear different in Japanese, Traditional Chinese and Vietnamese (and simplified Chinese if the character is also unified). Characters like that would serve as much better examples for illustrating the need for language sensitive glyph substitution. And that would require using images of the glyphs to be sure the illustration was getting across to every reader (not just the few readers who visit with Firefox on Windows, if even them). Part of the problem is that this may require someone who knows Japanese, Chineses and Vietnamese to be sure the glyph is displayed properly for each. Indexheavy 18:01, 5 May 2007 (UTC)

 * I am using Firefox on Mac, and I see "big" differences in the display of 与. It is possible that one has to know what to look for, but the horizontal line crosses the curved one in Japanese (and Korean), but it does not in the Chinese versions. On a Mac you can verify that the difference is consistent looking up the character in the Character Palette. Expand the "Font Variation" and see which fonts display which behaviour.
 * The character actually does not exist in Korean, and that may be confusing for a reader, but it is nevertheless good to know how it is displayed, if one types a Chinese word in the middle of a Korean text.
 * Most of the characters in the table show significant differences for someone who knows what to look for. However, if we rotate the table, we should probably also make room for an "explanation" column, where one describes in words or with images what to look for in each character, so even people without knowledge of the CJK languages know what the difference is.
 * (Vietnamese has not used Chinese characters for about 100 years. You probably mean Korean.) Mlewan 19:14, 5 May 2007 (UTC)

 * I use Firefox on Linux (Ubuntu 8.04) and I see no differences between all those characters. Any ideas? m_gol (talk) 12:30, 1 March 2009 (UTC)

Yes, you're right that I'm not familiar enough with the writing to notice the differences at first glance. I was looking more towards the middle of the table and though I see some subtle differences there too now, they still aren't as significant as the differences I see as I change through the fonts on my system. Also, I accidentally left off Korean, but I was referring to Vietnamese Chu nho, which I don't believe is completely obsolete. In Unicode documentation these days I often see the abbreviation CJKV instead of just CJK to extend to Vietnamese. Anyway, I think fewer examples with more exposition would bevery helpful to help readers understand the importance of font support for the unified characters. However, I still doubt the importance of the 'check your browser' section. Now that I tested FireFox on Windows, I see there are no differences at al (unless one also needs to have additional font support on the Windows install; I believe I'm testing it on a fairly basic installation). Also, I'm not so sure that FireFox is doing the appropriate thing here anyway. According to Unicode, they recommend following current practice where the glyphs used for ideographs are drawn from either the document's language or the reader's language. In that case a browser shouldn't switch fonts or glyphs due to changes in the language tag, but instad use the same glyphs thorughout the document unless the author changes fonts explicitly. For document's that have no declared language, they browser should use the environment language. So in summary, ther's only one browser who handles these characters in a way that the 'check your browser' section is checking for and it's not at all clear that FireFox is doing the right thing here.

I think this U+4E0E would serve as a decent example. I uploaded a glyph for this character that looks more significantly different than the ones I'm seeing in the table in FireFox. My thinking is that if we could match this glyph and the others to the various writing systems for this character (and maybe a few other characters with greater or lesser significant differences), it would provide a reference for readers to understand the issue. I don't have the link handy right now, but I know I"ve run across an example at the Unicode site, but it only relates to variations within Japanese alone (not across the writing systems). It might be a good idea to produce examples of both (intra-writing system unification and inter-writing system unification glyph differences). Indexheavy 20:31, 5 May 2007 (UTC)

 * The table is extremely useful. I have used it dozens of times in professional circumstances, and I have distributed the link to several of my colleagues. When you work with CJK web sites, you need to know which strings are sensitive to language issues. It is not enough to have one example. You need at least one example for each kind of difference, and the more examples you have, the better. We may not need a complete table within this article, but we need all examples somewhere. I would create a new page for it, if I had the time.
 * Provided you have the right fonts installed, at least both Firefox and IE handle this fine on Windows. I think Opera also does it. Safari 2.0 does not.
 * The whole point of Unihan is that you change font according to language. If you look in any bilingual Chinese/Japanese book, like language courses, you will notice that they always have different fonts for the two languages. Firefox and IE do this according to the rules. Mlewan 21:19, 5 May 2007 (UTC)

 * I think you're misunderstanding much of what I'm trying to say. First, I wasn't suggesting that we reduce the table to only one example. However, having several examples with some explantaory notes would be much more useful than all the examples we have with no explanation of the differences. Secondly, I understand the point of Unihan is to change fonts (changing glyphs to be more precise, even if they come from the same font). However, the issue is how one changes fonts. Unicode does not suggest changing fonts according to language tags; rather it suggests changing fonts according to the reader's user language environment (for plain text). For rich text, the fonts should be those specified by authors (or by a reader in the case of user stylesheets for example). Changing fonts when encountering different language tags is not recommended by Unicode and I think its bad practice in general (FireFox is the only browser I can see changing fonts, but it doesn't seem to necessariliy be in relation to producing the appropriate Unihan glyph).

 * Perhaps the solution is to leave the "chekc your browser" table as is, but add another smaller table before it that properly illustrates some differences between CJKV glyphs for each of few Unihan characters. Would you say that these characters included in the "check you browser" table are good potential candidates to illustrate those differences? One other question I had for you. Above you refer to " at least one example for each kind of difference". Could you say a little more about these different kinds. That too would be helpful exposition for readers ot he article (as well as me). Thanks for engaging in this discussion. Indexheavy 03:42, 6 May 2007 (UTC)

 * OK, you definitely seem to have understood the idea of font switching. I misunderstood you before. The only question is whether one should count the html-language tags as "rich text"-tags or not. All major browsers do (provided CJK is installed), and I think that settles it. It is also the best way to be sure to display for example 具 in a Japanese way in HTML. The alternative would be to specify fonts, but you do not know which fonts the reader has installed.
 * I was deliberately vague with "one example for each kind", and you spotted it. The problem is that there are so many kinds. When it comes to 具, it is a matter of connecting all parts of the character. When it comes to 今, it is a matter of an angle of a stroke. And so on. Mlewan 07:42, 6 May 2007 (UTC)

Made transpose changes to the table
I transposed the two tables. Please check to see that I didn't mess anything up. Alos, I didn't understand what the difference was in the two tables. Should they be combined into one? In the second table the code points were grouped into pairs (and sometimes threes). I didn't reproduce that in any visible way, though there is an extra row in wiki table syntax that doesn't get displayed (though its in the source for easy editing purposes). Finally, I think thre's plenty of room for an additional colum or two. For example if we need to add a glyph for Vietnamese (Chu_nho) or an annotation. Annotations that draw attention to the important differences in the glyphs or merely to include the kDefinition property from the Unihan database. Again, I think a much smaller table with some particularly good examples rendered with images would help illustrate this topic without a reader needing Asian fonts installed (my test of Windows basic install shows there's no differences in any browser: IE, FireFox and Opera). Indexheavy 05:32, 6 May 2007 (UTC)

 * Good work! Thanks a lot on behalf of all the readers!
 * However, yes, there were some things you missed. The pairs in the second table are there to illustrate the alternative solution to solve the problem. The only way to display the two variants of 入 is to change font (or language tag). However, for 內, there is the alternate character 内. This is somewhat silly, as the difference is (almost) equivalent. And then there are really confusing cases, like 兌, which can be displayed as 兑 both using another character or a language tag. So each row in a pair displays the "same" character but with different unicode codepoints.
 * When it comes to Vietnamese, I think it should be left out from the page entirely. We do not know of any single character where the Vietnamese language tag changes its display. I am not even sure that there are any dedicated fonts for Vietnamese forms of Chinese characters. Once such a font is identified and the problem is pointed out there, it could be added to the table.
 * I agree with a smaller table in addition, to further explain the principles. I made some more modifications, changed title and added some explanation. Mlewan 07:42, 6 May 2007 (UTC)

Generic Chinese?
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)

 * 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)

Wrong statement in the article about "内"
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)

Make those characters pictures
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)

 * 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)

 * 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)

 * 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)

kuten and min
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)

Tilting at windmills?
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)

"Graphemes versus glyphs" revisited
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)

Vietnamese
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)

I don't think lang|vi-nom does anything. Surely you mean template vi-nom as below:

 * (vi-nom) BabelStone (talk) 12:49, 6 April 2013 (UTC)
 * 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)

 * 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)

Revised chart of non-unified characters
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)

Codepoint problem
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)

May I add a link to a project of mine?
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)

First character
"Each respective variant of the first character has either 入 (U+5165) or 人 (U+4EBA). Each respective variant of the second character has either 入 (U+5165) or 人 (U+4EBA). Both variants of the first character got their own unique codepoints. However, the two variants of the second character had to share the same codepoint."

I'm confused, it's showing the same code point both times for the 1st character. Helping end world sexual repression. (talk) 09:46, 12 September 2017 (UTC)

 * Korean: 全內 (U+5168 U+5167, both have 入 as a component glyph)
 * Simplified Chinese: 全内 (U+5168 U+5185, both have 人 as a component glyph)
 * Though there is the same glyphic distinction between this pair of characters the first one is unified while the second one is not. Love —LiliCharlie (talk) 15:07, 12 September 2017 (UTC)

Font and language markup in comparative Han character table
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  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 ), 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)

The examples need to be in the form of images

…so as to be accurately displayed, independent of fonts or browser.--158.174.187.223 (talk) 16:10, 16 December 2020 (UTC)

 * 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)
 * 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)
 * Agreed, preferably an English version image. EnTerbury (talk) 23:16, 24 March 2024 (UTC)

zh-Hant
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)
 * Something should be done about it, they render the same on my end. EnTerbury (talk) 23:15, 24 March 2024 (UTC)

title: Talk:Han unification


text:
C++Builder

C++Builder is a rapid application development (RAD) environment for developing software in the C++ programming language. Originally developed by Borland, it is owned by Embarcadero Technologies, a subsidiary of Idera. C++Builder can compile apps for Windows (both IA-32 and x64), iOS, macOS, and Android (32-bit only). It includes tools that allow drag-and-drop visual development, making programming easier by incorporating a WYSIWYG graphical user interface builder.

C++Builder is the sibling product of Delphi, an IDE that uses the Object Pascal programming language. C++Builder combines the Visual Component Library (VCL) and IDE written in Object Pascal with multiple C++ compilers. C++Builder and Delphi can generate mutually compatible binaries. C++ methods can call Object Pascal methods and vice versa. Since both Delphi and C++ use the same back-end linker, the debugger can step from Delphi code into C++ transparently. In addition, C++Builder projects can include Delphi code. (The reverse is not possible.)

Technology
C++Builder uses the same IDE as Delphi, and shares many core libraries. Notable shared Delphi (Object Pascal code) and C++ Builder routines include the FastMM4 memory manager, which was developed as a community effort within the FastCode project, the entire UI framework known as the VCL, which is written in Object Pascal, as well as base system routines, many of which have been optimised for both Delphi and C++Builder through the FastCode project.

C++Builder projects can include Delphi code. The Delphi compiler emits C++ headers, allowing C++ code to link to Delphi classes and methods as though they were written in C++. The reverse (C++ code being used by Delphi) is not as straightforward but possible.

C++Builder originally targeted only the Microsoft Windows platform. Later versions incorporated Borland CLX, a cross-platform development visual component library based on Qt, that supports Windows and Linux, however CLX is now abandoned. The current version by Embarcadero supports cross-platform development using the new Firemonkey (FMX) library.

Editions
C++ Builder is available in four editions with increasing features and price:
 * Community: Available for free for one year but has a limited commercial-use license. Includes local database connectivity and some library source code.
 * Professional: Adds cross-platform compilation for macOS, (until version 10.2.2: iOS and Android requiring the purchase of the additional Mobile Add-On pack), more library source code, code formatting, and a full commercial license.
 * Enterprise: Includes the mobile target platforms and adds client/server database connectivity, Enterprise Mobility Services, and DataSnap multi-tier SDK.
 * Architect: Adds data modeling tools.

History
Traditionally, the release cycle was such that Delphi got major enhancements first, with C++Builder following, though recent versions have been released at the same time as their Delphi equivalents.

1.0
Borland announced the preview version of C++Builder 1.0 on January 7, 1997. The company released a retail version on February 26, 1997, in three editions: "Standard," "Professional," and "Client/Server Suite."

3.0
Borland skipped the 2.0 version number to align C++Builder with its Delphi version numbering.

4.0
New features include:
 * Integrated Inprise Corporation's VisiBroker 3.3 with event and naming services
 * New multi-standard flexible C++ compiler
 * Support for the latest ANSI/ISO C++ language specifications, including a host of compiler enhancements including Dynamic Compilation and Adaptive Compiler Technology (ACT), which radically speed compiler build processes; full ANSI/ISO template implementation; full ANSI/ISO STL (standard template library) support; and a high-performance 32-bit ANSI C++ native code compiler.
 * Fully customizable AppBrowser IDE
 * Latest support for Windows 98, 95, and NT including multiple monitors, common controls, docking forms and toolbars, and more.
 * New Code and Parameter completion, and the new ClassExplorer live structured class view and member creation wizards.
 * Exclusive C++ debugging tools, including remote debugging for distributed development (COM and CORBA); multi-process and cross-process debugging with debug inspectors, dynamic watch windows, and debug tooltips.
 * Internet tools, including ActiveForms for building Web browser C++ applications and WebBroker for building CGI, WinCGI, ISAPI, and NSAPI C++ applications and over 25 Internet protocol components for instantly adding HTTP, FTP, SMTP, POP, NNTP, HTML, and TCP/IP support to any C++ application.
 * Multi-Tier Database Development Services (MIDAS) Development Kit, including MIDAS 2.
 * Support for industry standards, including Oracle Corporation's Oracle8i database server; Microsoft Corporation's Microsoft Foundation Classes (MFC), Microsoft Active Template Library (ATL), Microsoft SQL Server 7 and MTS (Microsoft Transaction Server); and Inprise Corporation's Object Windows Library (OWL) and Visual Component Library (VCL).
 * EZ-COM, which simplifies C++ COM client development and One-Step ActiveX Control creation with new Data Binding support.

5.0
On March 22, 2000, Inprise Corporation announced the release of Borland C++Builder 5, available in Enterprise, Professional, Standard editions. New features include:
 * Support of Windows 2000.
 * Internet Express
 * XML and HTML4 Support for Full-featured Dynamic Clients
 * Active Server Objects for the Microsoft Internet Platform
 * TeamSource
 * Interbase 6.5

6.0
On February 5, 2002, Borland announced the release of C++Builder 6 on February 8, 2002, in three editions: "Enterprise," "Professional," and "Personal." 60-day free trial download of C++Builder 6 Enterprise was also planned. New features include:

 * Support of Windows XP
 * BizSnap e-business development platform with Web Services
 * WebSnap Web application development platform
 * Borland CLX component library (Professional/Enterprise)
 * dbExpress (Professional/Enterprise), Enterprise edition adds DB2/Informix/Oracle dbExpress drivers
 * NetCLX WebBroker WebBroker-compatible cross-platform Web application development framework for Windows and Linux (Professional/Enterprise)
 * MyBase XML data briefcases (Professional/Enterprise)
 * Borland C++ Compiler 5.5

Minimum supported operating system was changed to Windows 98.

C++BuilderX
On Sep 15, 2003, Borland Software Corporation announced the release of Borland C++BuilderX (CBX), which was also included as part of the latest Borland Enterprise Studio for Mobile. CBX was written using the same framework as JBuilder and bore little resemblance to either C++Builder or Delphi. This product was aimed at developing large programs for enterprises, but did not sell well.

On Sep 22, 2003, Borland Software Corporation and PalmSource, Inc. announced Borland has licensed the PalmSource software development kits (SDKs) and will support Palm OS development in the Borland C++BuilderX Integrated Development Environment (IDE) and latest Borland Application Lifecycle Management (ALM) solutions for C++.

At the end of 2004 Borland announced that it would continue to develop the earlier C++Builder and bundle it with the Delphi development suite, abandoning C++BuilderX.

2006
On Oct 10, 2005, Borland announced the release of C++Builder 2006 (previously codenamed "DeXter"). Minimum supported operating system was changed to Windows 2000.

About a year after the announcement, the company released Borland Developer Studio 2006, which includes Borland C++Builder 2006, with improved configuration management and bug fixes. Borland Developer Studio 2006 is a single package containing Delphi, C++Builder, and C#Builder.

2007
In 2006 Borland's Developer Tools Group, developers of C++Builder, was transferred to a wholly owned subsidiary, CodeGear.

June 5, 2007, CodeGear released C++Builder 2007, providing:
 * Full API support for Microsoft Windows Vista including themed applications and seamless VCL support for Aero and Vista Desktop
 * Increased ANSI C++ conformance
 * Up to 500% faster in-IDE build performance
 * Support for MSBuild, DBX4 database architecture, and "VCL for the Web" which supports Ajax
 * IDE, debugger, dbExpress, and VCL component improvements

CodeGear RAD Studio 2007 incorporates C++Builder 2007 and Delphi. Also in 2007 Borland revived the "Turbo" brand and released two "Turbo" editions of C++Builder: Turbo C++ Professional, and Turbo C++ Explorer (no longer available from CodeGear), based on Borland C++Builder 2006.

In 2008 CodeGear was purchased by Embarcadero Technologies, who continued development.

2009 and 2010
After purchasing CodeGear, Embarcadero Technologies bundled C++Builder with Delphi and other tools and released them as RAD Studio.

C++Builder 2009 was released on August 25, 2008, featuring:
 * Full Unicode support throughout VCL and RTL
 * Early adoption of the C++0x standard
 * Full ITE (Integrated Translation Environment) support
 * Native Ribbon components
 * Inclusion of the Boost library.
 * VCL and RTL enhancements
 * New DataSnap library for database applications.

C++Builder 2010 followed August 24, 2009, adding:
 * Touch and gesture support for VCL components
 * C++ specific class explorer
 * Code completion improvements
 * IDE updates

XE releases
Embarcadero changed the versioning scheme. Each new version of C++Builder was called XE#, where # is a sequential integer.

XE
C++Builder XE was released August 30, 2010 and included:
 * Multiple C++ language updates
 * New C++ compiler options
 * Multiple user-requested fixes

XE2
C++Builder XE2 was released August 31, 2011 and included:
 * New 'FireMonkey' library for creating cross-platform GUIs (Windows, macOS, iOS)
 * dbExpress to deliver new connectivity options with support for InterBase XE, FireBird 2.5, SQL Anywhere 12 and ODBC
 * DataSnap mobile support for iOS, Android, Blackberry, and Windows Phone
 * Expanded cloud computing integration with new data and deployment options to Amazon EC2 and Microsoft Windows Azure
 * LiveBindings for VCL and FireMonkey components
 * Multiple new reporting tools

XE3
C++Builder XE3 was released September 4, 2012 and added:
 * Windows 8 Style UI
 * Enhanced native UI control styling
 * 3rd party Pro-Designer UI Styles
 * Support for Mac OS X Mountain Lion & Retina
 * Project templates
 * Touch and Live Tile support
 * 1-click conversion for existing apps
 * Audio/Video Multimedia controls
 * Simple “Draw to bind” data and properties between objects
 * Quick app prototyping
 * Organize bindings with Layers

XE4
C++Builder XE4 was released April 22, 2013, and included:
 * 64-bit Windows compiler based on Clang 3.1. The 32-bit compiler was still based on Embarcadero's older technology.
 * FireDAC library for database access
 * Many new FireMonkey components and updates
 * Mobile Form Designer

XE5
C++Builder XE5 was released September 11, 2013, and included: C++Builder XE5 Starter Edition includes: Available editions include Architect, Ultimate, Enterprise, Professional, Starter.
 * Time Picker control for Windows and OS X
 * Built-in search filtering for TListView on Windows and OS X
 * FM Platform performance optimizations
 * Professional edition includes expanded FireDAC support for local databases, including Microsoft Access database, SQLite database, InterBase ToGo / IBLite, InterBase on localhost, MySQL Embedded, MySQL Server on localhost, Advantage Database local engine, PostgreSQL on localhost, Firebird Embedded, and Firebird on localhost
 * FireDAC integrated into the C++Builder install for Professional, Enterprise, Ultimate and Architect editions
 * REST Client support for simplified invocation of REST services
 * Authorization support including Basic Authentication, Plan Authentication, OAuth1, OAuth2
 * TRestClient, TRestRequest, and TRestResponse components
 * REST Debugger tool for testing REST calls and their parameters
 * Develop 32-bit Windows application using the C++Builder VCL and FireMonkey application platform
 * IDE and visual development environment
 * Hundreds of included components
 * License for use until user's individual revenue from C++Builder applications or company revenue reaches $1,000 US or development team expands to more than five developers

XE6
Released April 15, 2014, C++Builder XE6 included:
 * FireMonkey Android application support
 * Support for Windows 64-bit packages
 * C++ compiler improvements
 * IDE, Deployment Manager, and SDK Manager improvements

XE7
Released September 2, 2014, C++Builder XE7 added:
 * FireMonkey multi-platform support through "multi-device applications"
 * Runtime Library improvements for Bluetooth, parallel programming, XML, and web encoding/decoding
 * Enterprise Mobility Services to interface with DataSnap REST APIs and enterprise database data.

XE8
C++Builder XE8, released April 7, 2015, included the following new features:
 * GetIt Package Manager updates
 * Native iOS Presentation for FireMonkey components
 * Desktop web browser component
 * Interactive mobile maps
 * New media library options
 * Mobile app analytics
 * New C++ compiler for 64-bit iOS
 * Mercurial version control integration
 * New DUnitX testing framework

Subsequent releases
In 2015, Embarcadero once again changed the versioning scheme. Starting with version number 10.0, each version also received a nickname.

10.0 Seattle
Released August 31, 2015, Seattle updated the IDE with:
 * CLANG 3.3 C++ compiler suite with some exceptions
 * Windows 10 FireMonkey, CVL, and RTL support
 * VCL Windows 10 controls
 * New VCL Styles
 * Multi-monitor configuration improvements
 * Updates to the IDE, debugger, database and cloud libraries, and documentation

10.0.1 Update 1
Released November 2015, Update 1 added:
 * FMX Grid control for iOS
 * iOS native UI styling
 * New FMX feature demos
 * Platform support for iOS 10 and macOS Sierra

10.1 Berlin
Released April 20, 2016, Berlin added:
 * FireUI App Previews - Lets you preview your FireMonkey application on iOS, Android, OS X and Windows as you are designing the app
 * Android API 23 support
 * Improved Style Designer
 * Address Book for iOS and Android
 * DataSnap support for JSON streaming
 * FireDAC database improvements
 * Improved support for new Azure and AWS APIs
 * Runtime Library optimizations
 * iOS (32 and 64 bit) and Android debuggers

10.1.1 Update 1
Released September 2016, Update 1 added:
 * iOS native styling for TGrid
 * FMX ListView Item Designer and search filter
 * iOS 10 and macOS Sierra support

10.1.2 Update 2
Released December 2016, Update 2 added:
 * Windows Desktop Bridge deployment support
 * VCL QuickEdits
 * New Windows 10 styles
 * Improved GetIt package manager

10.2 Tokyo
Released March 22, 2017, Tokyo included:
 * Better support for debugging
 * Better Codegen in Clang-enhanced compilers
 * C++ Android applications can be built without requiring specific versions of the NDK
 * Linker utilizing up to 4GiB of memory
 * Improved exception handling
 * Improved app tethering
 * iOS and macOS debugger enhancements
 * High DPI fixes for VCL components

10.2.1 Update 1
Released August 2017, Update 1 added:
 * C++ compiler and linker quality fixes
 * Support for iOS 10.3 and XCode 8.3.3 when targeting the iOS App Store
 * Runtime Library and VCL enhancements
 * Android control rendering enhancements

10.2.2 Update 2
Released December 2017, Update 2 added:
 * FireMonkey QuickEdits
 * New VCL controls
 * Updated IDE look and feel
 * iPhone 11 and X support

10.2.3 Update 3
Released March 2018, Update 3 provided quality improvements and fixes for:
 * iOS 11.3 support
 * CodeInsight
 * C++ compiler 4k stack allocation
 * Context help
 * Android push notification

10.3 Rio
C++Builder 10.3 was released November 21, 2018 with new features:
 * C++17 Support
 * Improved code completion
 * Improved math performance for C++ functions
 * Error Insight preview of code issues
 * New libraries through the GetIt package manager
 * Improved IDE, dark theme
 * VCL High DPI component support
 * TWindowsStore component
 * Support for Android API 26
 * Android Z-Order, native controls, and new permissions model
 * iOS 12 support
 * Multiple database improvements
 * Improved REST architecture
 * Improved Azure and AWS S3 support

10.3.1 Update 1
Released February 2019, Update 1 added:
 * Expanded support for iOS12 and iPhone X
 * HTTP and SOAP Client Library enhancements for Windows
 * Bookmarks and Navigator IDE productivity tools
 * 15 custom VCL and FMX styles
 * Compiler improvements and bugfixes

10.3.2 Update 2
Released July 2019, Update 2 added:
 * C++17 support for Windows 64-bit
 * Improved Code Insight and Code Completion
 * Updates to the Android Firebase push notification support
 * Run Time Library optimizations
 * VCL, FMX, and IDE quality improvements

10.3.3 Update 3
Released November 2019, Update 3 provided numerous quality enhancements and bug fixes for:
 * C++ RTL and compiler
 * IDE, iOS/Android compatibility
 * FireDAC and Database tools
 * Web clients
 * Debugger

10.4 Sydney
Released May 26, 2020, Sydney improved the product by adding:
 * Unified memory management
 * Expanded C++ library support
 * Windows 64-bit debugging and linking improvements
 * New VCL Styles and control styling for high-DPI monitors
 * Metal driver GPU support for macOS and iOS
 * Enhanced parallel programming library support
 * Improved LiveBindings performance

10.4.1 Update 1
Released September 2020, Update 1 added:
 * Quality improvements to IDE, C++ Toolchain, FMX, VCL, and other libraries
 * Improved support for multi-monitor desktop layouts
 * Windows 64-bit debugger and linker enhancements

10.4.2 Update 2
Released February 2021, Update 2 added:
 * Advertising component for iOS, including AdMob support based on the Google Firebase SDK
 * VCL TControlList control, a flexible and virtualized list control, designed as a high-performance control for very long lists and a modern look and feel
 * VCL TNumberBox control, a modern-looking numeric input control, for integer, floating point numbers, and currency values
 * Updated Konopka Signature VCL Controls (over 200 additional Windows UI controls), available for download in the GetIt Package Manager

11 Alexandria
C++Builder 11 was released September 10, 2021.

11.1 Update 1
On March 15, 2022, Embarcadero released RAD Studio 11.1 with new features including:

 * Many IDE Improvements
 * Extensive High DPI IDE quality, plus improved use of the IDE with Remote Desktop
 * Improvements with High DPI designers for VCL and FireMonkey and the styled VCL form designer
 * GetIt Library Manager enhancements
 * Code Insight Across Delphi and C++Builder
 * The Delphi LSP engine saw big performance improvements
 * The Delphi and C++ compilers for the various platforms were improved in terms of stability and performance
 * Improved RTL, UI, and Database Libraries

11.1.5 C++ Code Insight Update
On July 14, 2022, Embarcadero released C++Builder 11.1.5 C++ Code Insight Update with a number of improvements and quality fixes for C++ developers using C++Builder 11.1 by adding:

 * New handling multiple navigation destinations
 * New delayed indexing to reduce CPU usage
 * New third option for LSP Code Insight
 * Performance improvements
 * Improvements display of code completion results
 * Improved navigation
 * An issue for users of the classic compiler
 * Issues saving all files in a project
 * More improvements and a variety of quality fixes

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: C++Builder


text:
Talk:Pin-up model

Wiki Education Foundation-supported course assignment
This article is or was the subject of a Wiki Education Foundation-supported course assignment. Further details are available on the course page. Student editor(s): Susiepew, Jpegallery.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 06:39, 17 January 2022 (UTC)

Untitled
Is there any evidence that this is correct? The user who created this page tried to vandalise the David Kelly page so I'm not I trust their bona fides. FearÉIREANN 04:46 22 Jul 2003 (UTC)

 * It certainly isn't the modern def - seems plausible enough... --mav

Not really related to the content of the article, but I must say the world "pulchritude" is used more on Wikipedia than anywhere else I've seen. I think I've seen it in three articles now. --Delirium 06:07 22 Jul 2003 (UTC)

'Tori Spelling'.....pin-up?
"A 'pin-up girl' is a woman whose physical attractiveness would entice one to place a picture of her on a wall." This is the definition given at the beginning of the "Pin-up girl" article. However, under the category of 'Famous Pin-Up Girls of 1990s and 2000s' appears the name 'Tori Spelling'. Tori's name appears with 24 other names in that category including; Pamela Anderson, Halle Berry, Paris Hilton & Dita Von Teese ([name] is in AfD). Tori's inclusion in this catorgory seems out of place. Obviously, beauty is in the eye of the beholder (& to be honest, I probably would anyway). Tori fits in with these iconic pin-up girls, like Dubya does with great political leaders. If Tori is to be included, then former 90210 colleagues, Shannen Doherty & Jennie Garth should also be included....before her. The point I'm trying make is that if Tori stays on that list, then the list should also include thousands of other moderately attractive, Z-list celebrities. Alyson Hannigan, although not my cup of tea, is better qualified to be a pin-up, due to her cult following, of people whom actually place pictures of her on walls. If people really do put pictures of Tori on their walls, I'm sure they are rare & isolated cases. Headcases. If in doubt, check http://en.wikipedia.org/wiki/FHM#100_sexiest_women with ten years multiplied by 100 sexiest women. No mention of Ms Spelling. She just doesn't have the pulchritude. Veej 03:35, 4 December 2005 (UTC)
 * Hello, I hope you will respect my censoring my full name from the above. I am not a "pin-up girl," I do not know why I was listed as one, and I do not appreciate this talk page appearing in my Google results (I have a VERY rare name).  Thank you for your understanding. 64.0.184.130 (talk) 19:06, 8 December 2010 (UTC)

This list is almost pathetic. Anyone who does a magizine spread is listed as a pin up. Bette Page is a Pin Up model. Janet Jackson? Tori Spelling? I don't think so.

Pin-up girl ratio
Should the pin-up girl BWH measurements be included in the article?

The bottom external link
Seems unnecessary to me.

Adding Hot Rod Surf to external Links
Adding Hot Rod Surf to the links they have a geat free pin up girl section on their sight with hot rods and pin ups as well a a great definition of the orgin. (Jmcrownpoint 11:20, 18 August 2006 (UTC)

 * 1) The link put in is the front page of the site, not directly relevent to pin up girls. 2) The pin-up sub page does have photos of a few gals-- but this is not supposed to be a comprehensive list of every site with a few photos of gals. Not an imformative addition to the article. 3) The majority of your contributions to Wikipedia seem to be to promote that particular site. Editing to help us build a better encyclopedia is welcome; spamming or trying to promote specific external sites is not. Reverting. -- Infrogmation 13:02, 19 August 2006 (UTC)

The 1970s to the 2000s.
Is a COMPLETE JOKE. As a fan of classic pin-ups. The list from the 70s to the 2000s is completely false as most of those people will NEVER be pin-ups. Fix the list and learn the history before putting random names up there. -- 03:51, 8 August 2007 74.122.179.76

 * Don't know why we can't include people such as Nastassja Kinski, Cheryl Tiegs, Bo Derek, and Farrah Fawcett, whose posters indisputably adorned many college dorm-room walls in the late 1970's / early 1980's... AnonMoos (talk) 11:50, 2 January 2008 (UTC)

Betty Brosmer
Should be something on Betty Brosmer -- she was apparently kind of a "supermodel" in the 1950's, and as famous as many actresses... AnonMoos (talk) 11:43, 2 January 2008 (UTC)

External link
Link to www.pinupwow.com removed: the site is commercial and the photos are not a good example of contemporary pin-up photography. Helvissa (talk) 12:24, 2 April 2008 (UTC)

Contemporary Pin-Ups
What about including a section on contemporary vintage-style pin-ups? I'm working on a page about Bernie Dexter - what do you think? NO Betty Page want to be people who photoshop the photo so much they have no nose like Bernie mmm don't do it sir.Helvissa (talk) 12:26, 2 April 2008 (UTC) I agree, Bernie Dexter is nothing but a Bettie Page wanna-be. There are too many Dexter photos (and movies!) out there that prove it was her sole intention to copy Bettie Page. The worst part is she won't admit it, so it is incredibly insulting to one's intelligence. There is one trait of Bettie's that Bernie didn't manage to copy....her grammar and spelling. Bettie was well educated and wrote with excellent grammar. Unfortunately, Bernie Dexter cannot say the same. Her posts usually contain misspelled words and poor sentences. I guess you can copy someone's style and mannerisms but you can't copy an intelligent, educated mind.

WTF
It seem that 90% of the women listed aren't pin-up models. They're actors. I'm pretty sure there's a difference. 76.181.232.187 (talk) 14:22, 29 May 2008 (UTC)

Image copyright problem with Image:Grable1.jpg
The image Image:Grable1.jpg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

 * That there is a non-free use rationale on the image's description page for the use in this article.
 * That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Media copyright questions. --04:40, 13 September 2008 (UTC)

 * I think it's a safe bet the copyright has since lapsed on this one. 68.49.138.170 (talk) 18:21, 24 March 2009 (UTC)

Definition of pin-up girl
Following up on the comments of a number of editors above:

Merriam-Webster defines "pinup girl" as "a girl or woman whose glamorous qualities make her a suitable subject for a pinup". Then, pinup as "a photograph or poster of a person considered to have glamorous qualities". (Starting 1941)

The Oxford American dictionary (a recent publication) defines "pinup" as "As poster showing a famous person or sex symbol, designed to be displayed on a wall. A person shown in such a poster."

This (perhaps too unreliable) site claims, however, that the "practice" goes back to the 1890s.

On the other hand, my "feeling" about pinup girls is that they have to do with WWII, and the WWII mentality that made naked women on calendars a feature of many typical garages for many years. That same feeling says "anybody can get their picture on a poster, these days". So there once was a concept which was (very loosely) akin to Wikipedia's later idea of notability.

Now, however, with great personal discipline, I have reviewed and carefully considered the pictures of Tori Spelling, Dita Von Teese and others, and have come to the conclusion that these women meet most definitions of "pinup girls".

But then, so did my grandmother, when she was in her twenties. Maybe my other grandmother, too. What's to say a person is "worthy"(if that's the word) to appear semi-clad on a wall? I'm not sure this article belongs in Wikipedia at all, but I am certain that making a list of every notable Wikipedia woman who someone out there considers attractive is unencyclopedic. Except for a couple examples to demonstrate the topic, the lists should go. Piano non troppo (talk) 01:14, 9 February 2009 (UTC)

 * I've been removing women from this list that haven't been specifically identified as a "pinup" in their respective biography articles. Having once been a model before being active in Hollywood does not seem to meet the generally accepted criteria for "Pinup". While being a traditionalist in that regard, this article will eventually need to move beyond the gender-based restriction of "girl". - JeffJonez (talk) 14:46, 23 March 2009 (UTC)

 * I also think that the modern pin ups like Bernie Dexter and others don't fit this definition ans should be removed. —Preceding unsigned comment added by 199.68.65.235 (talk) 18:13, 5 November 2009 (UTC)

 * What's the cutoff date for a "real" pinup girl? 1950s? Early '60s? No, I think any woman who sits for racy photos is a "pinup girl", but a one-shot in Maxim seems insufficient. - JeffJonez (talk) 20:45, 5 November 2009 (UTC)

 * I wonder if the history can't be pushed back past the 1890s. In Bleak House, chapter 20, the character Weevle decorates his room with portraits from a collection called "The Divinities of Albion, or Galaxy Gallery of British Beauty".  If the practice didn't spring entirely from Dickens's admittedly fertile imagination, it was around in the 1850s.  --Ammodramus (talk) 18:35, 19 December 2009 (UTC)

Global view
... needed. For example, Gravure idol could usefully be merged into this article. Kenilworth Terrace (talk) 18:49, 30 April 2010 (UTC)

blatant ads/unsubstantiated and unreferenced claims
Wow, I'm a bit bothered by many of the unsubstantiated implications in the following paragraph: "Pin-up style has emerged again as a trend in recent years, thanks in part to the popularity of Suicide Girls, an erotica website that features tattooed and pierced "alternative" models sometimes styled in 1950s-inspired pin-up looks. A rekindled popularity for Bettie Page, thanks in part to the biographical movie The Notorious Bettie Page (2005), and the celebrity status of Dita Von Teese have also contributed. A number of stores cater to this market, including PinUpGirlClothing.com, PinUpPeepShop.com, and BabyGirlBoutique.com. The clothing that they carry is specifically catered to exaggerated the hourglass shape pinup girls are adored for, and include such brands as Bettie Page Clothing, Dixiefried, Deadly Dames, and PinUp Couture. Many new publications have also emerged due to the growing popularity of the modern day pin-up. These publications feature the new looks and lifestyles of the modern pin up that may have tattoos, heavier make-up, and a hot-rod built with her own hands. The lifestyle of the modern day pin-up is a lot more independent than the more delicate pin-ups of yesteryear."

First, I'm don't think the credit to Suicide Girls is suitable considering the implied weight here, and I don't think this credit is appropriate especially as the site only started in 2001. Certainly there were a significant number of people and organizations that can be credited with the ongoing popularity of pin ups especially 50s styled imagery. This popularity and revival if anything started and carried through the 80s and 90s with the whole rockabilly and psychobilly revival scene. Similarly Bettie Page continued to be popular for decades and a recent film from 2005 only fed into the market and interest that already existed, sure, some new people may have been exposed by the result of it, but there was ample media produced and reproduced about her and her work through the 90s and earlier 2000s, if not earlier. Centerone (talk) 01:35, 10 August 2010 (UTC)

 * The short version: It's WP:OR and so it's out. - JeffJonez (talk) 03:13, 10 August 2010 (UTC)

Segregation
I have been researching the contribution of black soldiers in WWII, with particular reference to American segregated units and Caribbean troops serving in the UK forces. A recent obituary for Lena Horne mentioned that she was a faabvourite pin-up of black troops. Surely there must have been others, which just poses the question why are all the examples given white? - Pifkin (talk) 15:59, 14 August 2010 (UTC)
 * While not conceding that "all the examples" are white, your most productive course of action would be finding or writing articles that you feel are missing from this list. Be bold!, but in reviewing Lena Horne, I see no mention of her status of pinup, or a modeling career at all. - JeffJonez (talk) 00:08, 15 August 2010 (UTC)

Honor Blackman
I've removed her from 1930s pin-ups, on account of her being born in 1925. I imagine there may be a case for adding her to the list of 1960s pinups. Paul Brookes (talk) 00:34, 2 February 2011 (UTC)

Move to "pinup" to de-genderfy the entry
The origin of the "pin-up" is obviously the "pin-up girl", but we've had male pin-ups for quite a while now.

In order to best reflect this larger context, the article should be renamed "Pin-up".

Moving forward, how do we best objectify males in this article? :) - JeffJonez (talk) 19:19, 18 May 2011 (UTC)

 * JeffJonez -- I don't think that "pin-up" as commonly used is very gender-neutral, but the traditional corresponding term for depictions of males is beefcake... AnonMoos (talk) 18:48, 5 January 2013 (UTC)

Case for Gina Elise
If you enter "pin-ups" on the Google search page, the first suggestion you will see in the drop-down is Pin-ups For Vets, the not-for profit founded by Gina Elise. Since she has distributed thousands of calendars [with multiple period-type pictures each], posters, and t-shirts since 2006, I think a good case can be made that her name should stay in the 2000s category and the link to Pin-ups For Vets maintained.

Both keep being deleted. I put it back, so please will you consider keeping it there?

Dlschgo (talk) 07:35, 21 June 2011 (UTC)
 * The link redirects to an article about the effort, not the woman. Keep working on the article, and include a section specifically and exclusively about Ms. Elise and it should be a home run. - JeffJonez (talk) 15:39, 21 June 2011 (UTC)

Well, the article has referenced links that will surely lead you to Gina Elise. Btw, there was a Gina Elise Wiki article once upon a time that was disppeared by the powers that be. That is why the link leads where it does. Putting greater emphasis on Gina in the PUFV articles exposes it to the same danger of being challenged (I know, because of challenges when it was there.)

I will try to come up with something that will address your concerns and objections without threatening her organization's article. Thanks for your honest feedback! 99.140.197.216 (talk) 05:34, 22 June 2011 (UTC)
 * This page, for whatever reason, includes a list of pin-up girls.. not organizations. The best defense against removal of articles are sources that prove notability. Adding additional biographical information about a founder shouldn't make an organization's article more likely to be challenged, as long as that information isn't promotional. I never saw the article about Gina, but that's a common reason for arguments for deletion. I'll remove the link for now, since it's not currently relevant, but I'll keep an eye on the existing article. - JeffJonez (talk) 13:54, 22 June 2011 (UTC)

Varga girls, Bettie Page, Sun Page 3 girls, Playmate of the month centrefolds, etc.?
This article can and should be expanded, there's a lot of history there. OttawaAC (talk) 02:45, 20 October 2011 (UTC)
 * Hilda by Duane Bryers, another fictional pinup, like the many varga girls. the list of models includes too many who are mostly actresses. lets say it together: every single young attractive female actress of the late twentieth century has had images taken of them which qualify as "pinups", unless they somehow avoided publicity to become famous.Mercurywoodrose (talk) 02:34, 11 February 2014 (UTC)

Biased POV?
In the section on feminism: "In the early 20th century, these drawings of women helped define certain body images—such as being clean, being healthy, and being wholesome—and were enjoyed by both "normal" men and women; but as time progressed these images changed from respectable to illicit."

Should this should be fixed to at least indicate that it's an argument put forth by the source cited for it? The definition of "illicit" can vary wildly from culture to culture; what one in Sweden would consider OK, for example, may be seen as highly illicit in Saudi Arabia, for example. — Preceding unsigned comment added by Shrewmania (talk • contribs) 06:28, 23 November 2012 (UTC)

Notable contemporary artists..
If "Notable contemporary pin-up artists include Paul John Ballard, Elias Chatzoudis, Armando Huerta,Cris Delara and Chuck Bauman" then perhaps someone should work on Wikipedia entries for them. Centerone (talk) 03:59, 24 November 2013 (UTC)

What's a "pin-up gimmick"?
Quote: Also, Rayna Von Tosh, of SHIMMER fame had a burlesque pin up gimmick.

Whassat mean? Please clarify! Thanks, Maikel (talk) 11:12, 26 December 2014 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 2 external links on Pin-up model. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20131005000322/http://dazzledent.tumblr.com/post/9537692783/her-name-was-fernande-barrey-but-she-was-known to http://dazzledent.tumblr.com/post/9537692783/her-name-was-fernande-barrey-but-she-was-known
 * Added archive https://web.archive.org/web/20131004213236/http://home.comcast.net/~kb8gpo/fernande/ to http://home.comcast.net/~kb8gpo/fernande/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 07:42, 9 December 2017 (UTC)

Pin-up makeup style
The makeup section is lacking structure and needs so rewording. Also, there is only one citation. Im working on a draft.Jpegallery (talk) 01:39, 23 April 2018 (UTC)

Yank Magazine
Didn't the term "pin-up girl" originate with Yank: The Army Weekly? I can't find confirmation of that (yet), but it seems to be in my long-term memory. And since Yank was a major source of pin-ups during WWII, shouldn't there be a reference in the article - if, indeed, Yank had something to do with the term?

Isoruku (talk) 21:32, 31 July 2018 (UTC)

 * Yank must have had a big role in popularizing the term but they didn't invent it. According to the Oxford English Dictionary, the earliest documented use of the term was in Life magazine, July 7, 1941: "Dorothy Lamour is No. 1 pin-up girl of the U.S. Army." The first issue of Yank was published on June 17, 1942. Ewulp (talk) 00:54, 2 August 2018 (UTC)

Proposed merge of Beefcake into Pin-up model
Joyous! | Talk 03:50, 3 March 2023 (UTC) Pin-up model moved to be gender-neutral (instead of pin-up girl/cheesecake) back in 2016. Might as well finish the consolidation. VernoWhitney (talk) 18:50, 11 April 2022 (UTC)

 * Support. The beefcake article in nearly twenty years old and appears to be no more than start class. The pin-up model article already has specialist sections, such as African-American, so it should be able to accommodate the merger easily. -- Polly Tunnel (talk) 12:18, 19 May 2022 (UTC)

 * No, like no. A pin-up model should never be confused with a beefcake. Like end of story. I get that it's 2022 and there are plenty of dudes "pinning up" centerfolds from Playgirl of "Beefcakes" on their garage walls, but a pin-up girl/ model, should never be confused with a beefcake/ cheesecake, smh. Koskiryan (talk) 08:10, 18 July 2022 (UTC)
 * Pin-up dude; guy; male; ect., is 100% acceptable for Pin-up model, but never beefcake, like duh. Smh at whoever even proposed merging Beefcake into Pin-up model. Koskiryan (talk) 08:19, 18 July 2022 (UTC)
 * Agreed. It would make more sense to cross reference Beefcake and Cheesecake, without merging either into here. MatchesMalone (talk) 15:55, 3 September 2022 (UTC)
 * Koskiran, this is Wikipedia, we have some expected standards of civility and professionalism, we try not to treat others as dumb or talk like stereotypical teenagers. It makes it hard to take your argument seriously. Dronebogus (talk) 06:20, 22 November 2022 (UTC)
 * Oppose merge, given that Beefcake is one of several independently notable subset of pin-up models (Page 3 Girl, Sweater girl and Beefcake for example), suggesting that these topics are best discussed separately. Klbrain (talk) 12:41, 8 January 2023 (UTC)
 * Oppose I don’t know the point of this merge proposal besides merging stuff for the sake of it. Dronebogus (talk) 16:53, 8 January 2023 (UTC)

Is it time to close this discussion? The proposal has been open for nine months. I've been the only voice to support it and all others have been against. I'd like to withdraw my support and suggest that someone closes this discussion with the result being a consensus opposed to the proposal. Polly Tunnel (talk) 14:40, 11 January 2023 (UTC)

title: Talk:Pin-up model