Subject: [precis] terminology question

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 04 Dec 2013 14:17:54 -0700

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:

   Identifying one character as a compatibility variant of another
   character (or sequence of characters) suggests that in many
   circumstances the first can be remapped to the second without the
   loss of any textual information other than formatting and layout.

and:

   Fullwidth variants of the ASCII digits are simply compatibility
   variants of regular digits and should be treated as regular Western
   digits.

See also Chapter 2:

   Compatibility variants are a subset of compatibility characters, and
   have the further characteristic that they represent variants of
   existing, ordinary, Unicode characters.

   For example, compatibility variants might represent various
   presentation or styled forms of basic letters: superscript or
   subscript forms, variant glyph shapes, or vertical presentation
   forms. They also include halfwidth or fullwidth characters from East
   Asian character encoding standards, Arabic contextual form glyphs
   from preexisting Arabic code pages, Arabic ligatures and ligatures
   from other scripts, and so on. Compatibility variants also include
   CJK compatibility ideographs, many of which are minor glyph variants
   of an encoded unified CJK ideograph.

It seems to me that following the Unicode Standard here would be best,
unless we have a good reason not to do so.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 05 Dec 2013 02:45:04 +0100

* Peter Saint-Andre wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>

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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 05 Dec 2013 03:16:52 +0100

> 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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 05 Dec 2013 15:37:10 +0100

>  (canonical mapping, and compatibility mapping are subtypes of this)

Right, the Unicode database property name is `Decomposition_Mapping`. In
UAX15 long forms like "canonical Decomposition_Mapping values" are used.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Dec 2013 09:58:27 -0700

On 12/5/13 7:37 AM, Bjoern Hoehrmann wrote:
> * Florian Zeitz wrote:
>> 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 
> Right, the Unicode database property name is
> `Decomposition_Mapping`. In UAX15 long forms like "canonical
> Decomposition_Mapping values" are used.

You are right. Sentences like "map to decomposition mappings" sound
ugly, but let's use the correct term.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/