[ Home | Freetime works | FreeBSD | KFUG ]

프로그램세계 1999년 8월호

오픈 소스 유닉스에서의 한글 구현 - 넷스케이프와 한국어 처리

최준호, 한국 FreeBSD 사용자 그룹

넷스케이프는 현재 개발이 진행되고 있는 버전 5.0을 제외하고는 오픈 소스 프로그램이라 말할 수는 없다. 하지만 현재 프리웨어 형식으로 제공되고 있는 넷스케이프 커뮤니케이터 버전 4는 최근의 유닉스 사용에서는 빼놓을 수 없는 중요한 프로그램인데, 오픈 소스 유닉스를 중심으로 이에 대한 한국어 처리 방식에 대해 알아보자.

넷스케이프 커뮤니케이터

현재는 Seamonkey라는 코드명으로 진행되고 있는 넷스케이프 커뮤니케이터는 웹브라우저인 네 비게이터와 전자우편/뉴스 통합 클라이언트인 메신저 등이 제공되는 유닉스용 단일 어플리케이 션중에서는 가장 큰 것중의 하나이다. 이는 현재 정식 릴리즈인 버전 4는 오픈 소스 프로그램은 아니지만 작년부터 프리웨어 형식으로 누구나 사용할 수 있고, 버전 5는 이미 오픈 소스화 되어 모질라 프로젝트 홈페이지(http://www.mozilla.org)에서 소스 코드를 다운로드 받을 수 있다.

이미 98년 10월에 특집으로 다루었지만 커뮤니케이터는 유닉스에서 가장 잘 국제화된 프로그램 중 하나로 꼽히는데, 유닉스(즉 X윈도우) 버전에서는 모티프 위젯의 국제화 기능을 잘 활용하고, 내부적인 언어와 인코딩 처리를 가장 국제화 환경에 맞도록 하는 프로그램의 하나이다. 넷스케 이프는 2.0의 등장과 함께 한국어 환경도 지원하기 시작하였는데, 최근 버전인 4.61까지도 그 기본은 바뀌지 않았다(버전 5는 유니코드를 기반으로 하므로 많이 달라졌다).

그림: FreeBSD용 한글 넷스케이프 4.61

오픈 소스 유닉스에서는

그러나, 넷스케이프가 인터넷을 사용하는 오픈 소스 유닉스 사용자들에게는 거의 필수적이며 유 일한 선택이 되는 프로그램임에는 분명하지만 화면상에서 한국어 웹페이지를 읽을 수 있다는 부 분을 제외하고는 너무나 문제가 많았다. 일부 상용 유닉스에서는 OS가 나올 때 이러한 한국어 처리가 가능한 넷스케이프를 제공하거나 별도로 다운로드받을 수 있게 하는 방법으로 해결이 가 능하였지만 오픈 소스 유닉스에서는 불과 작년까지도 자유로운 한글의 입출력이 불가능한 상태 였다. 이는 최근의 몇가지 노력에 의해 거의 해결되어 가고 있고, 나머지 문제는 이미 모질라가 오픈 소스가 되어버렸기 때문에 공은 사용자에게 넘어왔다고 볼 수 있다.

문제점과 해결 방법

넷스케이프 버전 4를 중심으로 한국어 처리 방식에 대한 개요와, 나타날 수 있는 문제들에 대해 서 알아보자.

한국어 출력

이 연재에서 계속 설명하였지만, 한국어 출력에 대해서는 대체적으로 국제화 방식과 지역화 방식으로 나눌 수 있다. 하지만 넷스케이프는 지역화 방법은 전혀 사용하지 않으므로 제외하고, 국제화 방식을 기준으로 생각해 보자. 먼저 주의할 것은, 넷스케이프는 GUI의 기반 위젯으로 상 용의 모티프(Motif) 1.2.4를 사용하고 있으며, 모티프 위젯은 X11의 국제화 방식에 따른 국제화 기능을 제공하고 있으므로, FontList에 의한 다국어 출력과 XIM을 통한 입력기를 별다른 프로그 래밍 없이 로케일을 지정하고 글꼴을 지정하는 것으로 해당 언어를 지원할 수 있는 기능을 갖고 있다.

화면 출력

대체적으로 화면 출력은 다음의 두가지로 나눌 수 있다.

웹페이지 내 출력
웹페이지 외 출력

웹페이지 내의 출력은 사용자가 보는 HTML페이지에서의 출력이다. 이는 모티프 위젯과는 별도 로 넷스케이프의 레이아웃 엔진에서 처리하는 것이며, ksc5601.1987-0의 글꼴을 사용한다. 어 떤 글꼴을 사용할 것인지는 Edit - Preference - Appearance - Font에서 지정할 수 있다. 다 만 대체적으로 유닉스용 넷스케이프에서는 다양한 한글 글꼴의 모양을 볼 수 없는데, 이는 대략 적으로 두가지 원인으로 나누어 볼 수 있다.

다양한 모양의 글꼴 부족
영어(또는 Latin-1)과 한국어의 글꼴 분리

글꼴의 부족은 크기 문제이기 보다는 한 글꼴에 대해 Medium, Italic(또는 Oblique), Bold, Bold-Italic으로 제공되는 네가지의 글꼴 모양(보통 이를 face라고 한다)을 제공하고 있는 한국어 글꼴이 거의 없기 때문이다. X-TT와 같은 트루타입 변환 엔진을 사용하면 위와 같은 효과를 모 두 거둘 수는 있으나, 여전히 그 모양이 별로 좋지 않다는 단점이 있다. 크기도 중요한데, HTML 에서 기본적으로 제공하는(FONT SIZE태그나 CSS에서 제공하는 것은 더 복잡하므로 논외로 하 고) 글꼴 크기에 맞는 모든 글꼴을 제공하는 글꼴도 거의 없기 때문이다. 최근에 이와 같은 문제 를 해결하고자 공개된 글꼴을 만들려는 노력들이 있다.

또 하나는 X11은 인코딩에 따라 글꼴을 분리하여 사용하는데, 이는 영어와 한국어가 뒤섞이거 나, 단순히 한국어와 반각 숫자나 특수기호등이 뒤섞인 문장인 문장에서는 ASCII(또는 KSC5636)과 KSC5601**인코딩이 혼합되어 사용되는데 ***, 이들 문장을 온전하게 표시하기 위 해서 X11은 인코딩별로 다른 글꼴을 사용한다. 즉 태그 등에서 "Helvetica"등 의 태그는 ISO8859-1글꼴에서 지정된 것이 있으므로 그것을 사용하면 되지만, "굴림" 등으로 지 정해 버리면 일차적으로는 한글 이름으로 된 굴림이라는 글꼴이 없으므로 그것을 표시할 수 없 고, 이 글꼴이 사용하는 인코딩이 무엇인지를 알 수 없으므로 제대로 된 것을 표시할 수 없다는 문제가 있다.

KSC5601은 현재 KSX1001이라 부른다. 기술적으로 X윈도우에서 KSC5601대신 KSX1001글 꼴을 사용하는 문제는 없지만, 현실적으로 동일한 내용이나 이름만 다른 두 인코딩을 모두 지원 해야 하는지에 대해서는 하위 호환성과 관련해 회의적인 시각이 있다.

순수하게 KSC5601에서 정의된 글자만으로 이루어지는 문장은 거의 없다고 보아도 된다. 예 를 들어 한국어 문장에서 빈칸(0x20) 하나만 넣게 되어도, 0x20은 KSC5601의 문자가 아니라 ASCII(또는 KSC5636)의 문자이므로 이는 순수하게 KSC5601로 된 문자라 할 수 없고, 이렇게 표현된 문장의 인코딩을 가리켜 보통 EUC-KR이라 부른다. 따라서 표준적인 한글 텍스트 문서 가 갖게 되는 인코딩은 EUC-KR이라 부르는 것이 맞으며, 이는 ASCII(또는 KSC5636. ASCII와 KSC5636의 차이는 백슬래시를 원화 기호로 부르는가의 차이이다. 한글 윈도우의 굴림체 등은 백슬래시 대신 원화 기호로 된 글꼴을 갖고 있다)와 KSC5601에서 MSB를 1로 한 인코딩(일반적 으로 완성형이라 부르는)이 혼합된 문장을 가리킨다.

현재 넷스케이프는 EUC-KR과 ISO-2022-KR(KSC5601의 경우 2바이트 표현만 가능)로 된 텍스 트 문서를 제대로 해석하여 화면에 보여줄 수 있는 능력을 갖고 있다. 따라서 조합형으로 된 문 서나 통합 완성형 등의 한글 문서는 제대로 보여줄 수 없다. 대부분의 HTML문서가 EUC-KR을 만족하므로 큰 문제는 없지만, 장기적으로 EUC-KR로 표현할 수 없는 글꼴을 표현하는데는 큰 문제를 안고 있다. 이는 표준적으로 사용할 수 있는 한국어 글꼴의 부재와도 연관된다.

또한, UTF-8인코딩을 선택하는 경우, 넷스케이프는 내부적으로 자동 인코딩 합성 방법을 통해, 유니코드 문서를 보여줄 수 있다. 이는 UTF-8을 해석하여 ISO8859-1영역은 미리 정해진 ISO8859-1글꼴을 통해, KSC5601영역은 KSC5601.1987-0글꼴을 통해, JISX0208영역은 JISX0208.1983-0글꼴을 사용하는 식이다. 이런 경우는 유니코드 2.0으로 된 텍스트 문서도 웹 브라우저를 통해 볼 수 있다는 장점이 있지만, 위와 같은 방법에 의하면 KSC5601에는 있으나 유니코드에는 없는 글자의 경우 글꼴이 없으므로 근본적으로 보여줄 수가 없다는 문제가 있으므 로, 제대로 된 유니코드 표시 방법과는 거리가 있다.

웹페이지 내에서는 위와 같은 한국어 인코딩 처리 방법에 영향을 받지 않는 부분이 있는데, 바 로 <FORM>태그의 여러 가지 폼 형태에서 사용하는 버튼에서 사용하는 부분이다. 이들은 모두 표준적인 KSC5601.1987-0 인코딩 글꼴을 사용하지 않고 KSC5601.1987-1글꼴을 사용하며, 이 또한 넷스케이프의 글꼴 설정 메뉴에서 x-ksc5601-11이라는 조금은 이상한 글꼴 인코딩의 선 택을 통해 지정할 수 있다. 이는 웹 게시판이나 검색 엔진 등의 입력기 사용에서 필수적이므로, 사용 가능한 KSC5601.1987-1글꼴 몇가지 정도는 갖고 있는 편이 좋다. X11의 화면 인코딩과 관련된 로케일 정의 파일을 조정하면 KSC5601.1987-1 글꼴 없이도 사용 가능하다.

웹페이지 외부의 한국어 사용은 또 다시 두가지로 나누어 볼 수 있다.

HTML <TITLE> 태그의 내용

메뉴 등

<TITLE>태그에 적은 내용은 웹브라우저의 타이틀에 사용하는데, 이 부분은 어플리케이션이 관여 하는 영역이 아니라 윈도우 관리자의 영역이다. 따라서 이 부분에서 한국어 제목을 보고 싶다면 국제화되거나 지역화된 윈도우 관리자를 사용해야 한다. 최근에 널리 사용되는 WindowMaker를 사용하고 있다면 한국어 글꼴과 로케일 지정 만으로 큰 어려움 없이 볼 수 있을 것이다.

메뉴 등에서 한국어는 모티프의 영역이므로 모티프 위젯에 맞는 방법으로 사용해야 한다. 보통 넷스케이프의 원본을 그대로 설치한 경우 웹페이지 등에서의 한국어 문제는 없지만 한국어 메뉴 등을 표시할 수는 없는데, 한국어 로케일을 지정하고, 메뉴 등에서 사용하는 X리소스 이름을 알 아내어 한국어 글꼴을 추가로 지정해 주고, 마찬가지로 X리소스에 지정되어 있는 메뉴 이름을 번역해 주면 한국어로 된 메뉴나 옵션, 책갈피 등을 볼 수 있다. 예를 들어, 메뉴 바의 글꼴에 한국어를 지정해 주고 싶다면, X리소스에 다음과 같은 내용을 추가한다.

  Netscape*menuBar*fontList: \
          -*-lucida-medium-r-normal-*-*-120-*-*-*-*-iso8859-*;\
          -*-kodig-medium-r-*-*-*-120-*-*-*-*-ksc5601.1987-*:

즉 인코딩별 글꼴을 ;으로 나열하고 끝을 :으로 닫으면 된다. 이는 모티프 위젯의 지정 방식이 다. 메신저 등에서 제목 등을 나열하기 위해서는 여기에 글꼴 모양 등이 추가된 방법을 사용하 는데, 이는 다음과 같이 지정하면 된다. XmGrid위젯은 전자우편이나 뉴스의 제목 목록을 나열하 기 위해 사용한다.

  Netscape*XmLGrid*fontList: \
          -*-helvetica-medium-r-*-*-*-100-*-*-*-*-iso8859-*;\
          -*-kodig-medium-r-*-*-*-120-*-*-*-*-ksc5601.1987-*:NORMAL,\
          -*-helvetica-bold-r-*-*-*-100-*-*-*-*-iso8859-*;\
          -*-kodig-medium-r-*-*-*-120-*-*-*-*-ksc5601.1987-*:BOLD,\
          -*-helvetica-medium-o-*-*-*-100-*-*-*-*-iso8859-*;\
          -*-kodig-medium-r-*-*-*-120-*-*-*-*-ksc5601.1987-*:ITALIC

프린터

한국어 프린트 출력에 대해서는 지난 6월호 연재 기사에서 자세히 설명하였으니 기술적인 내용 은 생략하기로 하자. 넷스케이프에서 한국어가 혼합된 문서를 프린터로 출력하는 방법은 크게 두가지가 있다.

Save as... 명령으로 저장한 경우
PostScript로 저장한 문서에서는 인코딩 정보가 없어지고, 모든 문서는 Latin-1으로 작성되 었다고 가정한다. 이 경우에 출력된 PS파일의 한글을 되살리려면 nhpf나 nhppf와 같은 지역 화된 몇가지 특수한 필터를 사용해야 한다. 필터를 사용하면 한글 글꼴로 복구할 수 있지 만, 레이아웃 엔진에서 Latin-1 글꼴에 맞게 계산된 글꼴 폭을 모두 무시하게 되므로, 한 문장 내에서 고정폭과 가변폭 글자를 혼합하는 경우나 표 등의 사용에 있어서 문제를 일으 킬 수 있다. 즉 출력에 있어서 원하는 결과를 얻을 수 없게 되는 경우가 있다.
Print... 명령으로 출력/저장하는 경우
이 경우 저장한 PS문서에는 인코딩 정보가 반영되어 있지만, Latin-1이 아닌 글자들은 모두 문자에 대한 속성 정보를 잃는다. 즉 이탤릭이나 볼드, 밑줄과 같은 속성 정보가 사라지는 데, 이는 Latin-1에는 한 글자를 표시하기 위해 4가지 글꼴(Medium, Italic, Bold, Bold-Italic)을 제공하는데 비해 비 Latin-1문자에 대해서는 한가지 글꼴만을 제공하기 때문 이다. 이는 복구할 수 없는 정보이기 때문에, 한국어는 경우를 막론하고 모두 한가지 글꼴만 사용하게 된다. 넷스케이프는 기본적으로 SMgoJ라는 완성형 PS글꼴을 사용한다고 가정하 고 PS파일을 만들게 되는데, 넷스케이프의 CJK 출력 글꼴의 경우 모든 글자의 메트릭을 고 정되었다고 계산하기 때문에 이를 리소스에서 정할 수가 있다. 예를 들어 공개된 CID글꼴 (OCF글꼴과 마찬가지로 사용할 수 있는)을 사용하기 위해서는 다음과 같이 지정하면 된다.
```
  Netscape*documentFonts.EUC-KR*psname:           Munhwa-Regular-KSC-EUC-H
  Netscape*documentFonts.EUC-KR*pscode:           euc-kr
  Netscape*documentFonts.EUC-KR*pswidth:          1000
  Netscape*documentFonts.EUC-KR*psascent:         1150
```
pswidth와 psascent는 해당 글꼴의 모든 글자에 대해 동일하게 적용되며, 레이아웃 엔진이 출력하는 PS문서에서 위치의 세밀한 조정을 위해 사용한다. 따라서 정확한 값을 글꼴 정보 를 통해 알고 있거나, 경험적 방법에 의한 조정에 의해서 이 값을 제대로 맞출 수 있다. nhpf와 nhppf 필터 프로그램은 OCF/CID 형식으로 공개되어 사용할 수 있는 글꼴이 없을 때 만들어진 프로그램으로, 어느 형태에도 대응할 수 있지만 메트릭 계산은 소홀히 하므로, 이러한 필터를 사용할 때에는 출력시에 글자가 겹치거나 너무 떨어지는 현상을 볼 수 있다. 마찬가지로 위와 같이 리소스에 특정 글꼴을 지정하는 경우, 정확한 값을 지정하지 않으면 고정폭과 가변폭이 섞이는 경우에 겹치거나 너무 글자 사이가 떨어지는 현상을 볼 수 있다. 이는 고정폭 글꼴로 된 문장이 지나가다가 가변폭으로 된 문장이 나타날 때 레이아웃 엔진 이 글꼴 위치를 다시 지정하기 때문인데, 따라서 같은 가변폭 문장이라면 한글과 영문이 섞 이더라도 이런 현상을 찾기는 힘들다. 대신 출력 문서의 오른쪽 끝에서 잘리는 현상이나 너 무 남는 현상을(nhpf의 경우 많이 볼 수 있다) 경험할 수 있다.

같은 문서라도, Save as...와 Print...의 출력은 조금 다르다. 예를 들어

      한글은 아름답다. Hangul is Beautiful

이라는 HTML문서를 포스트스크립트로 저장해 보면,

Save as....의 경우

아래와 같이, 한글은 모두 \xxx(16진수)와 같이 표시된다. 이는 곧 글을 모두 ISO8859-1로 취급한다는 의미이다. 앞의 8 f0에서 8은 크기, f0는 글꼴인데, 보통 크기의 글꼴을 나타낸다.

  0 712.8 moveto
  8 f0
  (\307\321\261\333\300\272 \276\306\270\247\264\344\264\331. Hangul is beautiful.
  ) show

Print... 의 경우

Print의 경우 현재 창 인코딩에 따라 출력 인코딩이 결정되므로, 한국어로 맞 추어 두고 출력하면 다음과 같은 결과를 얻을 수 있다. /of 프로시저는 한글 글꼴을 지정하는 것 이고, 이후를 잘 살펴보면 KSC5601 코드가 나올 때에는 글꼴을 of로 지정하고, ISO8859-1코드 가 나올 때에는 f0으로 글꼴을 바꾸어 주는 것을 볼 수 있다. 그러나 ISO8859-1 글꼴의 경우 f0-f7까지 존재하는데(각각 가변폭 medium, bold, italic, bold-italic, 고정폭 medium, bold, italic, bold-italic을 나타낸다), 그 이외 인코딩의 경우 무조건 /of로 지정하므로 글꼴 스타일에 대한 정보는 복구할 수 없게 된다. 하지만 적절히 지정한 경우 레이아웃은 맞게 된다.

  /of { /Munhwa-Regular-KSC-EUC-H findfont exch scalefont setfont } bind def
  ...
  
  0 753 moveto
  8 of
   show
  8 f0
  ( ) show
  8 of
   show
  8 f0
  (. Hangul is beautiful.) show

한국어 입력

한국어 입력의 문제는 비교적 최근에 제기되었고 지금도 활발하게 노력이 진행되고 있는 문제이 다. 이렇게 된 것에는 몇가지 이유가 있지만, 가장 큰 것은 리눅스의 경우 libc5에서 glibc2의 전 이, 그리고 glibc 2.0에서 glibc 2.1로의 전이, FreeBSD의 경우 xpg4라이브러리의 동작 방식에 대한 연구, 그리고 무엇보다도 XIM프로토콜을 지원하는 쓸만한 한국어 입력기의 등장이 큰 기폭 제가 되었다. 때가 맞물려 같은 문제로 고민하던 일본에서 여러 가지 성과를 내놓았는데, 이들의 소식이 우리에게도 동일하게 적용되던 것이었기 때문에 큰 도움이 되었다.

이는 기본적으로 X11의 로케일 모델과 동작 방식, 그리고 넷스케이프와 모티프가 어울려서 여러 가지 예상치 않았던 문제를 일으키게 되었다. 이 문제에 대해서 자세한 분석은 지면이 허용하지 않으므로 어렵지만, 원인과 해결 방법을 중심으로 접근해 보자.

웹페이지 내

웹페이지 내에서의 한국어 입력부는 크게 두가지로 나누어 볼 수 있다. 모두 <FORM>상에서의 입력 인터페이스이지만, 하나는 검색 엔진 등에서 주로 사용하는 한줄짜리 입력창이고(INPUT TYPE=TEXT), 또 하나는 게시판 등에서 사용하는 여러줄 짜리 입력창이다(<TEXTAREA>). 이 둘의 동작은 같아야 하지만, 모티프의 문제에 따라서 달라진다. 처음에 우리가 고민하던 문제는, 한국어 입력기가 없다는 것이었고, 입력기가 등장하고 나서는 어떻게 한국어 입력기 가능한 환 경으로 만드는가에 대한 것이었다. 게다가 초기의 넷스케이프는 X라이브러리와 정적으로 링크되 어 있었는데, X11R5 라이브러리와 링크되어 있던 이 넷스케이프는 Xsi방식의 국제화를 사용하는 X11R5 라이브러리와 링크되어 있어 입력기조차도 만들기 어렵다는 문제를 안고 있었다.

그림: 두가지의 입력창 종류. 이 화면은 ami-0.2.0과 FreeBSD-3.2를 사용한 입력 장면이다

X11R6의 경우 하나의 표준화된 국제화 인터페이스를 갖고 있었지만, 국제화 개념이 최초 로 소개된 X11R5의 경우, FontSet 등의 인터페이스는 통일되어 있었지만, 입력기 프로토콜과 인터페이스를 포함한 실제적인 구현에 대해서는 표준이 없었다. 이에 따라 두가지의 구현 방식 이 존재하였는데, 각각 Ximp와 Xsi라 부른다. 이중 Ximp는 이후 X11R6의 구현 방식의 모태가 되지만 Xsi는 일부 유닉스에서의 구현을 제외하고는 사라지게 된다. X11R5/Xsi방식과 링크되어 있던 넷스케이프 3.0 이전 버전의 경우 한국어 입력을 위해서는 Xsi방식의 한글 입력기를 필요 로 하는데, 오픈 소스로 된 그런 입력기는 지금까지도 존재하지 않는다. 또한 한국어 메뉴 등의 출력을 위해서는 Xsi방식으로 된 별도의 로케일 정의 파일(nls디렉토리)이 필요하였다.

리눅스의 경우 이는 한글 입력기 KIMS를 만든 김범철님의 홈페이지(참고자료 참조)에서 자세히 알아볼 수 있다. 이는 기본적으로 제대로 된 한국어 지원이 되지 않는 상태에서, X라이브러리가 로케일을 인식하기 위한 조건인 setlocale()함수의 성공을 보장하기 위해 특별한 동적 라이브러 리(liblocale.so 또는 현재 대부분의 배포본에서 libBrokenLocale.so)를 미리 띄우는 식이었다. 이는 일본 쪽에서의 성과를 반영한 것이라 할 수 있다. 그러나 이와 같은 접근 방법은 제대로 된 로케일 처리 방식을 필요로 하는 모티프에서는 오동작을 일으키는 것으로, 한줄짜리 입력창 에서도 제대로 된 입력이 어려운 경우가 많았다.

그러나 이후 제대로 된 한국어/일본어 로케일 구현을 하고 있다는 glibc2 + libwcsmbs가 등장 한 이후, 그리고 FreeBSD의 경우 EUC를 지원하는 xpg4라이브러리를 사용하는 경우에도 이 문 제는 좀처럼 풀리지 않았는데, 이는 결국 넷스케이프의 기반이 되는 모티프 라이브러리의 문제 로 밝혀지게 된다. 모티프에서 여러줄 입력창을 처리하는데 있어서 버그가 있다는 것이었다. 버그의 내용은 넷스케이프 커뮤니케이터에 링크된 모티프에 버그가 있어, 특히 TextField(한줄짜 리 입력창) 위젯에서 부르는 내부적인 변환 함수를

   wcstombs(s, 와이드 문자열, ...)

의 형식으로 호출해야 하지만 실제로

   wcstombs(s, 멀티바이트문자열, ...)

과 같이 잘못 부르고 있어서 문자열을 잃어버리게 되는 것이다. 이 문제를 해결하는 것은 직접 wcstombs함수를 가로채어 wcstombs 함수 내부의 두번째 인수가 와이드 문자열인지 멀티바이 트 문자열인지를 알아보아서, 멀티바이트 문자열이라면 변환하지 않고 그대로 s에 다시 복사한 다는 것이다.

이는 결국 두가지 문제의 해결 방법을 필요로 하게 된다.

버그가 수정된 모티프와의 동적 링크된 넷스케이프: 이는 모든 문제를 깔끔하게 해결할 수 있지만, 모티프는 상용 라이브러리인 관계로 소스를 구입하지 않고는 구할 수 없다는 문제가 있으며, FreeBSD에서는 동적 링크된 넷스케이프를 제공하지 않았다. 모티프 버그 수정 패치 는 http://www.on.cs.keio.ac.jp/~yasu/linux/Motif-1.2.4.patch에서 구할 수 있다.
넷스케이프 위에 얹을 수 있는 동적 라이브러리 형태로의 버그 수정: 이는 모티프가 일으킬 수 있는 버그의 경우에 따라 올바른 동작으로 고정해 버릴 수 있도록 가로챌 수 있는 C라이 브러리의 몇몇 함수들(wcsmbs관련 함수)를 가로채는 수법이다. 모티프 함수는 정적 링크되 어 있으므로 가로챌 수 없다. 이는 현재 사용하고 있는 해결책이다.

후자의 해결 방법으로는, 리눅스의 경우 일본쪽에서 만들어낸 libmozillafix.so(glibc 2.0.x+wcsmbs, glibc 2.1.x), FreeBSD의 경우 libansi(FreeBSD 2.x), 포트의 japanese/libxpg4-ns (FreeBSD 3.x)를 사용하는 방법이 있다. 또한 이와 같은 효과를 내지만 다르게 구현된 방식으로, 국내에서 박원규님이 만들어낸 xwcsmbs가 있다(참고자료 참조). 이들 대부분은 모티프의 버그를 C라이브러리에게 가려주는 역할을 한다. 이를 통하면 한줄 또는 여러 줄 짜리 입력창에서 원하는 대로의 한글 입력을 가능하게 할 수 있다. 아직 완벽한 수준은 아니 지만 최근에 이런 방법을 탑재한 한글 리눅스 배포본이나 FreeBSD를 사용해 보면, 문제가 거의 해결되었다는 것을 알 수 있다. 그러나 아직도 종종 다운되는 경우나, 메일 주소창에서의 문제, 파일 선택 다이얼로그 등에서 가끔 문제를 나타내는 경우가 있다.

웹페이지 외

웹페이지 외에서는 별 문제될만한 것이 없다. 왜냐하면 입력할 부분이라는 것이 거의 없기 때문 인데, 가능한 곳은 URL입력창, 파일 저장 다이얼로그의 파일명, 그리고 페이지내 검색 다이얼로 그에서의 입력 부분 정도이다. 이들은 모두 모티프의 XmTextField 위젯의 영향을 받으며, 웹페 이지 내의 입력이 성공적이었다면 모두 문제 없이 해결될 것이다. 그러나 네비게이터 화면에서 상단부의 URL 창에서는 한국어 인코딩의 글꼴을 지정하면 넷스케이프가 시작시에 스플래시 화 면(넷스케이프 제작사와 저작권자 정보를 나열해 보여주는 화면) 이후에 다운되어 버리는 현상이 있는데, 이는 URL입력창이 단순한 입력이 아니라 내부적으로 히스토리 관리가 되기 때문에, 이 와 관련해서 ISO8859-1이외의 인코딩을 처리할 때 문제를 일으키는 것으로 알려져 있다. 이 문 제를 해결하는 방법은 명시적으로 해당 위젯에서 한국어 글꼴을 지정하지 않는 것이다.

  Netscape*mainForm.toolBox.urlBarItem.urlBarMainForm.urlComboBox.Text.fontList:\
          -*-helvetica-medium-r-*-*-*-120-*-*-*-*-iso8859-*

이 문제를 꼭 해결해야 할까? 필자는 그렇지 않다고 본다. 기본적으로 URL에서는 한국어 인코딩을 허용하지 않고(CGI등에서는 한국어 문자를 %xx와 같이 16진수 형태로 인코딩한다), 정말 URL에 한국어 인코딩이 들어있을 때 문제없이 보고 입력할 수 있는 브라우저는 한글 윈도 우에서밖에 없다. 최근의 IE 5에서는 한국어로 된 URL을 제대로 처리할 수 없었다는 보고도 있 었는데, 기본적으로 URL에는 한국어를 쓰지 않는 것이 맞으므로 그렇게 하도록 하자. 왜 그런지 알기 위해서는 URL을 정의하고 있는 RFC문서를 보기 바란다.

또 하나는, 파일 다이얼로그에서 경로명이 제대로 표시되지 않는 경우가 있다는 것이다. 이는 완 전하지 않은 로케일 구현과 모티프의 버그, 그리고 다이얼로그를 예쁘게 표시하려는(?) 넷스케이 프의 다이얼로그 위젯의 수정 사항 때문에 발생하는 문제로 알려져 있다. 이 문제를 해결하려면 넷스케이프의 해크를 사용하지 않도록 하면 된다.

  Netscape*nsMotifFSBHacks: false

그외

이제 큰 문제에 대해서는 거의 살펴 보았다. 종종 만나게 되는 성가진 문제 몇가지에 대해서 생 각해 보자. 특히 넷스케이프에서 지정한 글꼴(보통의 경우 ISO8859-1과 KSC5601.1987-0 또는 1) 범위 밖에 있는 문자를 입력하거나 표시하려 할 경우 넷스케이프는 다음과 같은 에러를 내는 데, 이 문제는 해결할 수 있는 것도 아니고 대단히 성가신 문제 중의 하나이다.

  Warning:    Name: Text    Class: XmTextField
      2054-xxx Character 'h' is not supported in Font. It is discarded

만약 글꼴 지정이 잘못되었다면 지정하면 되지만 일반적으로는 그렇지 않은 경우에도 발생할 수 있다. 예를 들면 자바스크립트를 사용하여 웹페이지 내의 입력 창을 열고 그 안에서 문자를 스 크롤하는 경우가 있는데, 이 경우에는 대부분 위와 같은 에러를 연속적으로 내게 된다. 이는 글 자 단위로 스크롤해야 함에도 바이트 단위로 스크롤하기 때문에 한국어의 2바이트 중 반만 걸치 게 되는 경우가 대부분이다. (솔라리스의 경우 시스템의 문제로 발생하기도 한다. 이때에는 적절 한 X서버 패치를 사용하기 바란다) 이럴 때에는 에러 메시지가 연속적인 다이얼로그로 표시되는 데(넷스케이프는 표준 출력이나 표준 오류를 다이얼로그에 바꾸어 출력할 수 있는 기능을 제공 한다) 연속적으로 이 다이얼로그를 닫는 것도 상당히 불편한 일이다. 이때에는 다음 리소스를 지 정하면 다이얼로그가 아니라 터미널에 출력하도록 할 수 있다.

  Netscape*useStderrDialog:               False
  Netscape*useStdoutDialog:               False

모질라 5 - Seamonkey

작년의 넷스케이프 분석 기사를 모두 소용 없게 만드는 것은(적어도 국제화 관련과 레이아웃 엔 진, X 프론트 엔드에 대해서는!) 바로 작년 말부터 시작된 XP 툴킷, 유니코드, GTK 기반의 새로 운 모질라 프로젝트 때문이다. 코드명 Seamonkey라 이름붙여진 이 프로젝트는 국제화 부분의 경우 완전히 새로운 독자적인 로케일 인터페이스와 X11의 경우 GTK 위젯 기반으로 코드가 새로 이 작성되고 있다. 최근에 발표된 Milestone 7(M7)의 경우 기존의 모질라와는 완전히 다른 새로 운 모습을 보여주고 있다.

그림: 모질라 Milestone 7 화면(FreeBSD 3.2)

이 새로운 레이아웃 엔진은 HTML 4, CSS Level 2등을 모두 지원한다는 야심찬 계획 아래 진행 되고 있다. 그렇다면 한국어 처리는? 필자가 M7을 컴파일해 보았을 때에는 한국어 메뉴는 있지 만 실제로 화면이나 프린터 출력은 볼 수가 없었는데, 그렇지만 최근에 EUC-KR 변환기가(변환 기가 필요한 이유는 유니코드로 다시 변환해야 하기 때문이다) M6에서 추가되었고, 프린트 출력 이나 화면 출력 등에서 천천히 논의가 되고 있으므로 관심을 가져 보아도 좋을 것이다.

끝으로

지금까지 넷스케이프에서 한국어 사용에 대한 문제에 대해 알아보았다. 넷스케이프 어플리케이 션 하나에 대해 이렇게 문제가 많다는 것도, 그만큼 자세하게 분석이 되었다는 것도, 해결책도 자세히 나와 있다는 것도 모두 이 킬러 어플리케이션의 유용성과 관심도를 반영하고 있을지도 모른다. 앞으로는 버그 없는 모티프와 링크된 넷스케이프 버전 4의 새 버전을 기대하는 것이 좋 을까 아니면 GTK를 사용하는 모질라 5의 새 버전을 기대하는 것이 좋을까? 현실적인 선택은 버 전 4의 새 버전이 되겠지만, 넷스케이프사가 언제까지 두 영역에서 모두 일하는 개발자들을 동 원하여 두가지의 프로그램 개발에 힘을 쏟을지는 알 수 없는 노릇이며, 그다지 바람직하지도 않 다는 생각이다. 넷스케이프의 핵심 개발자인 Jamie Zawinski는 Mozilla.org를 그만둘 때 이 문제 (중복 개발)에 대해 심히 불평하기도 하였다. 어쨌거나 넷스케이프는 우리의 일상적인 인터넷 사 용에서 여전히 핵심적인 프로그램이므로, 관심을 갖고 지켜보도록 하자.

참고 자료

How can I view Hangul world wide web pages under Unix/X window? - by Jungshik Shin: http://pantheon.cis.yale.edu/~jshin/faq/qa36.html
넷스케이프와 한글: http://www.kr.freebsd.org/~cjh/freetime/mozilla/netscape-ko
glibc와 Netscape 한글화: http://www.mizi.co.kr/software/hanIM/hanIM-ns.htm
한글 입력기 KIMS 홈페이지: http://members.iworld.net/bumchul/kims.html
박원규님의 홈페이지(Xwcsmbs): http://chem.skku.ac.kr/~wkpark/linux/xwcsmbs.html
mozillafix (일본어): http://www.geocities.com/SiliconValley/Grid/8453/

$Id: index.shtml,v 1.1.1.1 2001/05/23 03:11:32 cjh Exp $

[ Home | Freetime works | FreeBSD | KFUG ]