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