XFree86 4.0.1에 포함된 Xterm은 현재 고정 문자 폭을 가지며 왼쪽에서 오른쪽 방향으로 써야하는 ISO 10646-1의 레벨 1만을 지원한다. 다시 말하 면, 터미널의 의미 연결 체계(terminal semantic)가 이제 UTF-8을 디코딩할 수 있고 16비트 문자에 액세스 할 수 있다는 것을 제외하면, 터미널의 의 미 연결 체계는 ISO 8859-1의 경우와 기본적으로 같다.
가장 최신의 xterm 개발 버전은 이에 두 가지 새로운 함수들( Robert Brady가 제공)을 추가한다.
선택된 일반 문자가 XY 픽셀 크기를 갖는다면
, xterm은 이제 부가적인 2XY 픽셀 크기의 폰
트를 로드하려고 시도할 것이다(AVERAGE_WIDTH 속성의 두 배
값을 갖는다는 점을 제외하면 XLFD와 같다).
Unicode Technical Report #11에 따르면
East Asian Wide(W) 혹은 East Asian FullWidth(F)의 폭
특성(Width property)을 갖는 모든 유니코드 문자들을 나타내기 위해서 xte
rm은 이러한 폰트를 사용할 것이다.
스페이스가 없거나(nonspacing) 둘러싸고 있는(enclosing) 결합 문자들( 예를 들면, 유니코드 데이터베이스안에 일반적인 카테고리 코드 Mn 이나 Me를 가지고 있는 문자들) 또한 현재 사용 가능하며 이것은 기본 -문자 glyph(base-character glyph)을 두 개의 결합 문자 glyph까지 단지 겹쳐쓰므로써(논리 연산자 OR-ing) 구현할 수 있다. 이것은 기본 라인 아래 에 액센트를 받아들일 수 있게 하고, 작은 문자 위에 액센트를 받아들일 수 있게 한다. 예를 들면 겹쳐쓰기와 함께 사용하기 위해서 특별히 설계된 태 국 폰트에 대해서도 또한 잘 동작한다. 그러나 특별히 "고정되고" 집단화된 폰트와 같은 어떤 폰트 안에서 키가 큰 문자 위에 액센트를 결합하는 것은 완전히 만족스럽지 않을 지도 모른다. 그러므로 미리 만들어진(precompose d) 문자들을 사용 가능한 경우에는 그것이 더 나은 결과를 낳을 것이다.
텍스트 모드 애플리케이션 프로그래머들이 주의해야 할 점:
xterm의 출력은 한중일어권의 한자와 결합 문자를 위한 지원으로써 보다 는 비례 문자처럼 반응할 것이다. 왜냐하면 라틴/그리스/키릴 등의 문자는 하나의 세로열 위치를 필요로 하는 반면, 한중일어권의 한자는 2개의 문자 를 필요로 하며 결합 문자는 하나도 필요로 하지 않기 때문이다.
오픈 소스 그룹의 단일 유닉스 사양은 하나의 문자가 얼마나 많은 세로열을 차지하고 있 는지를 애플리케이션이 테스트 할 수 있도록 하는 두 개의 C 함수 wcwidth()와 wcswidth() 를 명시하고 있다.
#include <wchar.h> int wcwidth(wchar_t wc); int wcswidth(const wchar_t *pwcs, size_t n);
Markus Kuhn 이 비 상용(free)으로 배포하는 wcwidth() 함수는 C 라이브러리가 아직 적합한 함수를 제공하지 않는 플랫폼의 애플리케이션에 의해 사용될 수 있 다.
xterm은 앞으로 다가올 미래에 더욱 복잡한 완전한 유니코드 렌더링 엔 진에서 당신이 기대할 지도 모를 다음의 기능들을 아마도 지원하지 않을 것 이다.
그러므로 유태어와 아랍어 사용자들은 유태어와 아랍 문자열을 터미널로 보내기 전에 문자열의 방향을 반전시키고 왼쪽을 채우는 애플리케이션 프 로그램을 사용해야만 한다. 다시 말해, 양방향 프로세싱은 xterm에 의해서 가 아니라 애플리케이션에 의해서 이루어져야만 한다. 유태어 및 아랍어와 관련된 상황은 미리 만들어진 glyph과 프리젠테이션 양식의 유효성에 있어 서 적어도 ISO 8859 이후 개선되고 있다. 지금으로써는 양방향 지원이 정말 로 xterm에 내장될 것인지 이것이 얼마나 정확하게 작동할 것인지 명확하지 않다. ISO 6429 = ECMA-48과 유니코드 bidi 알고리즘 모두 대안적인 시작 포인트(starting point) 를 제공한다. E CMA Technical Report TR/53을 보도록 하라.
만약 당신이 애플리케이션에서 양방향 텍스트 출력을 지원할 계획이라면 , 유니코드 Bidi 알고리즘을 비 상용(free)으로 구현한 Dov Grobgeld의 FriBidi 혹은 Mark Leisher의 PretBidi 알고리즘을 보라.
최근에 비록 Robert B rady가 bidi 지원을 위한 몇몇 초기 실험적인 패치를 발표하긴 했지만 xterm은 현재 아랍어, 한글 자모 및 인도 텍스트 포맷팅 알고리즘을 지원하 지 않는다. VT100 애뮬레이터에서 이러한 것들을 지원하는 것이 알맞은지 > 혹은 바람직한지 여전히 불명확하다. 애플리케이션들은 아랍어와 한글을 포 맷하는 알고리즘을 쉽게 애플리케이션 스스로 적용할 수 있다. 왜냐하면 xt erm이 애플리케이션으로 하여금 모든 필요한 프리젠테이션 양식을 출력하는 것을 허용하기 때문이다. 인도 서체에 관해서 X 폰트 메카니즘은 필수적인 연결선(ligature)을 대체할 또 다른 형태의 연결선을 위한 인코딩을 지금> 으로써는 전혀 지원하지 않고 있다. 그래서 제공할만 한 xterm이 전혀 없다 . 인도어 출력이 필요한 애플리케이션은 xterm과 같은 VT100 에뮬레이터 대 신에 Pango와 같은 적절한 유니코드 X11 렌더링 라이브러리를 사용하는 것이 더욱 좋다.