24. X11 R6.4 스펙과 유니코드에 어떤 문제점이 있는가?

X11 R6.4 릴리즈(1998)는 X 컨소시움이 개발한 X11 윈도우 시스템 표준에 맞는 샘플 프로그램의 최신 버전이다. 대부분의 현재의 X11 표준과 샘플 프로그램은 유닉스 환경에서의 유니코드에 대한 광범위한 관심을 일찍부터 불러일으키고 있다.

• UTF-8 잘라내기와 붙이기: ICCCM 표준은 선택한 UCS 문자열을 변환하는 방법을 명시하지 않고 있다. 몇몇 벤더들은 현존하는 COMPOUND_TEXT 메카니즘 (CTEXT)에 UTF-8을 또 하나의 인코딩으로써 추가하였다. 이것은 적어도 다음과 같은 이유에서 좋은 해결책이 아니다.

  • CTEXT는 다소 복잡한 ISO 2022 메카니즘이다. 그러나 유니코드는 CTEXT에 또 다른 추가 항목을 제공하는 것이 아니라 끔찍한 메카니즘 전체를 훨씬 간단하고 더욱 편리하며 동등한 능력을 갖는 무언가로 대체할 기회를 제공한다.
  • 존재하는 많은 애플리케이션들은 CTEXT를 통해 선택한 것과 통신할 수 있지만, 새롭게 추가한 UTF-8 옵션을 지원하지 않는다. CTEXT 사용자는 과거의 ISO 2022 인코딩을 사용할 것인지 새로운 UTF-8 인코딩을 사용할 것인지를 결정해야만 한다. 그러나 두가지를 동시에 사용할 수는 없다. 다시 말해서, CTEXT에 UTF-8을 신중히 추가한다고 할지라도 존재하는 CTEXT 애플리케이션의 하위 버전과의 호환성은 깨진다.
  • 현재의 CTEXT 스펙은 섹션 6에서 명확하게 다음과 같이 UTF-8의 추가를 금지하고 있다. "'다른 코딩 시스템'에 등록된 ISO는 컴파운드 텍스트에서 사용되지 않는다; 확장된 세그먼트들은 ISO 2022가 아닌 인코딩(non-2022 encodings)을 위한 유일한 메카니즘이다."

  Juliusz Chroboczek은 속성 형(property type)과 선택 목표(selection target)로 사용할 수 있는 새로운 UTF8_STRING 요소를 이용하여 UTF-8의 선택 여부를 다루기 위한 ICCM의 확장에 대해서, " 유니코드 텍스트의 내부-클라이언트 교환에 관한 제안 초안(Inter-Client Exchange of Unicode Text draft proposal)"을 작성하였다.

• 쓸모 없는 폰트 데이터 구조들: 폰트의 미터 단위 길이에 관한 정보를 나타내기 위해 사용하는 Xlib API와 X11 프로토콜 데이터 구조는 드물게 사용하는 폰트들(sparsely populated fonts)을 처리할 때는 대단히 쓸모가 없다. X 클라이언트에서 어떤 폰트에 액세스하는 가장 일반적인 방법은 XLoadQueryFont() 함수를 호출하는 것이며, 이것은 XFontStruct를 위해 메모리를 할당하고 서버로부터 그것의 내용을 불러온다. XFontStruct는 각각 12바이트인 XCharStruct 엔트리(entry)의 배열을 포함한다. 이러한 배열의 크기는 마지막 문자의 코드 위치 - 첫 번째 문자의 코드 위치 + 1 이다. 그러므로 U+0020과 U+FFFD를 모두 포함하는 임의의 "*-iso10646-1" 폰트는 65502 요소를 갖는 XCharStruct 배열이 할당되도록 할 것이다(심지어는 CharCell 폰트들에 대해서도 같은 결과가 발생할 것이다). 이것은 그 폰트가 오직 1000개의 문자들을 포함하고 있다 할 지라도 786 킬로바이트의 클라이언트-사이드 메모리(client-side memory)와 데이터 전송을 필요로 함을 의미한다.

  지금까지 거론해왔던 일과 관련된 몇몇 주변의 일들:

  • XFree86 4.0에 함께 제공되는 비-아시아권용 -misc-fixed-*-iso10646-1 폰트들은 U+31FF 이상의 영역에서는 어떠한 문자도 포함하지 않는다. 이것은 필요 한 메모리량을 153 킬로바이트까지로 제한한다. 이것은 여전히 좋지 않은 일이지만, 그렇게 나쁜 일도 아니다.(BDF 파일에서 나타나는 U+31FF 이상의 영역에서 유용한 문 자들이 실제로 존재하며, 이러한 문제가 해결될 그 날만을 기다리고 있다. 그러나 그 들은 현재는 -1로 인코딩되며, 따라서 X 서버에 의해서 무시된다.)
  • Bruno Haible은 서버에서 클라이언트로 압축시켜 XCharStruct를 전송하고, 같은 폰트를 로드하는 다수의 사용자를 위한 Xlib의 공유 메모리를 사용하는, XFree86 4.0을 위한 BIGFONT 프로토콜 확장자(extension)를 작성하였다.

  이러한 주변의 일들은 XFontStruct가 드물게 사용하는 폰트들에게 적합하지 않다는 잠재적인 문제를 해결해 주지 않는다. 그러나 그들은 API 혹은 클라이언트 소스 코드 를 변경할 필요 없이 중요한 효율 향상을 제공한다. 한가지 진정한 해결책은 XFontStr uct를 배열과는 대조적으로 문자를 저장하는 정렬 리스트나 해시 테이블을 포함하는 훨씬 유연한 무언가로 확장 혹은 대체하는 것이 될 것이다. 이러한 XFontStruct의 재 설계는 또한 결합 문자와 인도 문자의 연결선을 동시에 사용하기 위해 급히 필요한 대 비책이 될 것이다.

• Keysyms: 지금까지 정의된 바로는 keysyms는 단지 아주 작은 Unicode 목록 만을 포함한다. Markus Kuhn은 U-00000000 부터 U-00FFFFFF까지의 범위내의 모든 UCS 문자는 0x01000000 부터 0x01ffffff까지의 범위내의 keysym 값으로 나타낼 수 있다고 제안하였다(그리고 xterm에서 이것을 구현하였다). 이것은 널리 인정되고 있는 것처럼 전체 31비트의 UCS 공간을 지원하지 않는다. 그러나 이것은 UTF-16과 그 이상의 모드에서 나타낼 수 있는 U-0010FFFF까지의 모든 문자들을 지원하며, ISO가 더 큰 영역의 UCS 코드들을 할당할 것 같지는 않다(사실 미래에는 ISO 10646으로부터 U-0010FFFF를 넘는 코드 공간을 없애자는 제안이 있다). 따라서 유니코드 문자 U+ABCD를 얻기 위해서는 keysyms 0x0100abcd를 직접 사용할 수 있다. 또한 고전적인 keysyms와 UCS(X11 표준에 들어가야만 할 것 중의 하나이다) 사이를 변환시키기 위해 제안된 테이블에 관한 소스 코드인 xterm의 keysym2ucs.c 파일을 보라. Markus는 또한 X 프로토콜 표준 부록 A: KEYSYM 인코딩의 개정판 초안 을 작성했다. 그것은 UCS 상호 참조 테이블을 추가한 KEYSYM 인코딩( PDF)이다.
• 결합 문자: X11의 세부 사항을 보면 결합 문자를 어떤 식으로도 지원하지 않는다는 것을 알 수 있다. 폰트 정보에는 액센트를 자동으로 붙이는데 필요한 데이터가 부족하다(예들 들면, TeX에는 모든 폰트에 액센트를 자동으로 붙이는 기능이 있다). 다양한 사람들이 잉크를 가지고 문자의 왼편에 폭이 없는 문자(zero-width characters)를 사용하는 가장 간단한 결합 문자 겹쳐쓰기(simplest overstriking combining characters)를 구현하기 위해서 실험을 해왔다. 그러나 이것을 구현하는 방법에 관한 세부 사항은 실제로 명시되지 않고 있다. (예를 들면, CharCell과 모노스페이스 폰트(monospaced fonts)는 폭이 없는 문자를 허용하지 않는다.) 그러므로 이것은 아직 폭넓게 확립된 기술이 아니다.
• 연결선: 인도 서체는 연결선 치환을 지원하는 폰트 파일 포맷을 필요로 한다. 이것은 지금으로써는 결합 문자처럼 X11의 세부 사항에 포함되어 있지 않다.
• UTF-8 로케일: X11 R6.4 샘플은 지금으로써는 UTF-8 로케일을 위한 어떠한 지원도 포함하지 않고 있다. 과거의 UTF 로케일은 있지만, 그것은 불완전하며 현재에는 쓸모없는 UTF-1 인코딩을 사용한다. UTF-8 로케일을 구현하기 위해서는 일반적인 인코딩 변환 과정이 필요할 뿐만 아니라 여러가지 키보드 등록(entry) 방법, 존재하는 ISO 8859와 keysym 키보드를 UCS로 매핑하여 배치하기, 합성 키 (compose key)를 위한 극도로 확장된 지원 및 한글과 한자 등록 지원(entry support)을 입력하기 위한 임의 문자의 ISO 14755 16진수 등록이 필요하다.
• 샘플 구현(sample implementation): xterm, xfontsel, 윈도우 매니저등과 같은 고전적인 표준 툴을 위한 유니코드 지원 뿐만 아니라 수많은 광범위한 유니코드 표준 폰트들이 샘플 구현에 추가되어야만 한다. 이러한 부분에 관한 몇몇 연구들이 이미 XFree86 내부에서 이루어지고 있으며 그 밖의 일들은 이전의 중요 사안들이 아직 해결되지 않았다는 사실로 인해 현재 연기되고 있다.

이러한 이슈들을 연구하는 작업이 진행 중인가? 모르겠다. 나는 몇 일에 걸쳐 X 컨 소시움을 공식적으로 계승한 단체이자 X11 표준과 샘플 구현의 관리자 역할을 하는 Op engroup인 X.Org에 접촉하려 시도했지만, 그들로부터 아직 쓸모 있는 어떠한 대답도 얻지 못했다(X.Org의 한 멤버인 XFree86에도 접촉했지만, 역시 대답을 얻지 못했다).