Grapheme cluster
= Grapheme cluster
A <grapheme cluster> is a sequence of <Unicode> <code points> treated as a unit by a text-segmentation rule. Default extended <grapheme clusters> approximate user-perceived characters, supporting operations such as moving a text cursor or deleting a visible unit. They are not a universal linguistic definition of a <text character>; boundaries can require language-specific tailoring.<Unicode Text Segmentation by the Unicode Consortium>[Sections1,3 and3.1.1: purpose, extended clusters and default boundary rules]{ref}
For example, `e` followed by the <combining character> `U+0301 COMBINING ACUTE ACCENT` contains two <code points>, but forms one default extended <grapheme cluster>. Its <UTF-8> representation has three <bytes>: `65 CC 81` in <hexadecimal> notation. The precomposed `U+00E9` also forms one <grapheme cluster>, with two <UTF-8> <bytes>, `C3 A9`. The two representations correspond under the canonical rules of <Unicode normalization>.<Unicode Normalization Forms by the Unicode Consortium>[Sections1.1–1.3: canonical equivalence, decomposition and composition]{ref}
A <glyph> count answers another question: <text shaping> can represent the two <text characters> `f` and `i` by one <typographic ligature> even though their default <grapheme cluster> boundary remains. <Byte> offsets, <code point> offsets, <grapheme cluster> boundaries and <glyph indices> therefore serve different purposes.
\Image[/grapheme-cluster-codepoints.png]
{title=One <grapheme cluster> with different <Unicode> <code points> and <UTF-8> <bytes>}
{description=Original encoding comparison for the accented letter é. Blue groups each contain one default extended <grapheme cluster>; <Unicode normalization> relates the precomposed and decomposed representations. The letter column shows the abstract letter represented, rather than a measurement of a particular <text shaping> engine.}