On 05.12.2013 02:45, Bjoern Hoehrmann wrote: > * Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> When talking about mapping of fullwidth and halfwidth characters >> (e.g., U+FF01 to U+0021), RFC 5895 uses the term "decomposition mappings": >> >> 2. Fullwidth and halfwidth characters (those defined with >> Decomposition Types <wide> and <narrow>) are mapped to their >> decomposition mappings as shown in the Unicode character >> database. >> >> In the PRECIS documents, we somehow used the term "decomposition >> equivalents": >> >> ... width mapping >> is in general RECOMMENDED because allowing fullwidth and halfwidth >> characters to remain unmapped to their decomposition equivalents >> would violate the principle of least user surprise. >> >> The Unicode Standard seems to use the term "compatibility variants", >> e.g., consider the following text in Chapter 5: > > Quick usability check: if the "decomposition mapping" of X is `NFD(X)` > then the Unicode term is the least obvious and should be avoided. If > it's something else entirely, both "decomposition" terms are bad. > The terminology used in the RFC 5895 quote is definitely correct. However, for the PRECIS documents we might have to go on a case by case basis.
There are (AFAIK) generally these different concepts: * "decomposition mapping": This is defined in the UnicodeData.txt file, and maps a single codepoint, to one or multiple codepoints (canonical mapping, and compatibility mapping are subtypes of this) * "(canonical|compatibility) decomposition": This is NFD() and NFKD() respectively. Notably these are defined on strings, not on single codepoints * "compatibility variants": These are closely related to the "decomposition mappings", but most importantly always just a single character/codepoint. For an exact definition Section 2.3 of Unicode is helpful. Full-/halfwidth characters do fall into this category, but it is not more correct to use this term than referring to the "decomposition mapping" property IMHO. Regards, Florian _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
