ports/118196: xterm-229 mishandles combining characters
Olaf Seibert
olafs at cs.ru.nl
Thu Nov 22 11:30:04 UTC 2007
>Number: 118196
>Category: ports
>Synopsis: xterm-229 mishandles combining characters
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Nov 22 11:30:03 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator: Olaf Seibert
>Release: FreeBSD 6.1-RELEASE amd64
>Organization:
>Environment:
System: FreeBSD twoquid.cs.ru.nl 6.1-RELEASE FreeBSD 6.1-RELEASE #2: Mon Mar 19 15:05:26 CET 2007 root at twoquid.cs.ru.nl:/usr/src/sys/amd64/compile/TWOQUID amd64
>Description:
If you cat the UTF-8 demo file from
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt to an xterm
started with "uxterm", the combining characters don't come out
combined. the part above the text
(The above is a two-column text. If combining characters are handled
correctly, the lines of the second column should be aligned with the
| character above.)
is misformatted, for instance.
NetBSD happens to have an older xterm which works right.
I tried version "XFree86 4.3.99.903(184)" which is quite old.
Version "X.Org6.7(184)" from a Linux version also works.
>How-To-Repeat:
See above.
>Fix:
By accident, I found a workaround, involving luit(1) and a
misspelling of the locale name. Apparently "utf-8" instead of
"UTF-8" causes luit to do an almost-identity mapping which
somehow avoids the problem:
LC_CTYPE=en_US.utf-8 xterm -lc -class UXTerm
-Olaf Seibert.
--
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list