U+2329 and U+232A characters rendered too wide

[Ben Gamari]

Both gnome-terminal and xterm render the U+2329 (〈) and U+232A (〉) characters in two cells despite the fact that most other applications render it correctly. This appears to happen with both fixed- and variable-width fonts. I apologize for the incorrect package assignment; I really have no idea where in the stack this bug is.

[Egmont Koblinger (egmont-gmail)]

These characters seem to be defined double width by the Unicode standard.

http://www.unicode.org/reports/tr11/

"ED4. East Asian Wide (W): All other characters that are always wide. These characters occur only in the context of East Asian typography where they are wide characters (such as the Unified Han Ideographs or Squared Katakana Symbols). This category includes characters that have explicit halfwidth counterparts."

"Revision 8:
Change in header for Unicode 3.1.
Changed 2329..232A and 3008-3009 from N to A and W to A respectively. This is a result of their canonical equivalence."

... so apparently Unicode 3.1 changed them from Narrow to Ambiguous, and then ...

"Revision 10:
Changed 2329..232A, 3008..3009, and 301A..301B from A to W to reflect the addition of 27E6..27EB which are their Na equivalents."

which changed them to Wide. You might want to use 27E8 and 27E9 instead.

http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt

"2329;W # LEFT-POINTING ANGLE BRACKET
232A;W # RIGHT-POINTING ANGLE BRACKET"

(W for wide)

glibc's wcwidth() apparently also correctly reports a width of 2, resulting in this behavior in gnome-terminal and xterm.

What other applications (not terminals) do is pretty much irrelevant, that depends on the actual font where each character has its own width, plus there's kerning and stuff. Terminals are pretty much a different world, the width is defined by the Unicode standard, rather than by the particular font in use.

[Adolfo Jayme Barrientos (fitojb)]

See also bug 932958.