우분투 devel 메일링에서 BetterCJKSupport가 논의되고 있습니다

scim이 상당히 매력적이긴 한데, 3벌식이 지원이 별로더군요.
수세9.2버전에서 scim이 기본이었고 저는 세벌 390을 쓰는데,
숫자쓰기나 기호같은것들이 잘 지원되지 못했던걸로 기억됩니다.

scim은 다른 것은 별 불만이 없는데, CTRL+SPACE가 불편해요.

다국어 입력기 중에는 scim이 그나마 제일 나은 것 같은데요... ;;
iiimf는 깔끔하긴 하지만 기능이 적은 듯 하고, uim은 한글 입력이 잘 안되었습니다.
페도라 코어 5에서도 iiimf 대신 scim을 쓰기로 했다고 합니다.

검은해 wrote:

위키에 MP3 태그에 대한 얘기가 나온 김에, 줏어들은 이야기지만 간단히 적어봅니다.

ID3v1의 경우 공식적으로 ISO 8859-1만 지원합니다. 윈도용 프로그램에서 한글을 태그에 넣을 경우 보통은 시스템 코드페이지에 맞춰 인코딩되는 것 같습니다.

ID3v2의 경우 버젼에 따라 ISO 8859-1, UTF-8, UTF-16 등을 지원하지만, 상당수의 프로그램이 멀티바이트 지원을 제대로 하지 않고 ISO 8859-1 필드에 역시 시스템 코드페이지에 맞춰 인코딩한 내용을 채워넣는다고 합니다. 제대로 한다면 UTF-16 전용 필드 같은 곳에 넣어야 하겠죠.

단순히 ISO 8859-1 필드의 표시 문제를 땜빵한다고 근본적으로 해결될 문제는 아니리라 생각합니다.

id3v1 의 경우 문자 인코딩을 정하는 필드가 아예 스펙에 없습니다. 무조건 iso 8859-1 인코딩으로 집어넣으라고 되어있죠. (사실 id3v1 은 스펙도 제대로 없긴 합니다. 워낙 간단하구요 ;; )

그리고 id3v2 의 경우 2.3.0, 2.4.0 의 경우가 다른 걸로 알고 있습니다. 2.3.0 의 경우 문자 인코딩을 지정하는 필드에 iso 8859-1 혹은 utf-16 을 지정할 수 있습니다. 2.4.0 의 경우에는 필드에 iso 8859-1, utf-16, utf-16LE, utf-8 4가지 인코딩을 지정할 수 있습니다.

윈도우 프로그램 중에서 현재 id3 태그를 유니코드로 가장 잘 지원하는 프로그램은 itunes 라고 생각합니다. itunes 로 mp3 태그 고치고 태그를 뜯어보면 스펙대로 잘 되어 있습니다. 잘못 안코딩 된 태그를 유니코드 태그로 잘 바꿔주는 편이구요. 푸바도 그럭저럭 괜찮은데, 널 문자를 안 넣는 경우가 있었습니다.

국내에서 유통되는 mp3 id3 태그의 90% 이상이 cp949 로 문자열을 인코딩되어 있습니다. 물론 인코딩 지정 필드에는 iso-8859-1 로 되어 있구요. 보통 이런 파일이 일반적인 mp3 플레이어에서 잘 보입니다.

결국 mp3 플레이어가 태그 인코딩에 대해서 처리 해 주는 수 밖에는 없는 실정입니다. 몇몇 리눅스 계열 프로그램도 id3 태그를 읽을 때 iso 8859-1 을 특정 인코딩으로 인식하라는 옵션이 있습니다. 아니면 그냥 현실을 인정하고 cp949로 인코딩 하고 처리하는 방법이 있는데 그다지 깨끗해 보이지는 않습니다;; 그래서 저는 윈도우즈에선 itunes 와 foobar 만 사용합니다. 인코딩만 utf 로 잘 되어 있으면 리듬박스나 아마록에서는 잘 보입니다. 그리고 제 기억에 아마록은 iso 8859-1 를 euc-kr 등으로 읽어들이는 걸 지원합니다.

scim이 상당히 매력적이긴 한데, 3벌식이 지원이 별로더군요.
수세9.2버전에서 scim이 기본이었고 저는 세벌 390을 쓰는데,
숫자쓰기나 기호같은것들이 잘 지원되지 못했던걸로 기억됩니다.

scim을 쓰게 된다면, en_US.UTF-8만 설정한 상태에서도 한글 또는 다른 언어의 입력기를 활성화 키를 눌러 동작시킬 수가 있나요? 나비에서는 이것이 되므로 저는 locale은 en_US.UTF-8으로 설정을 하고 한/영을 쓰고 있습니다. 그리고, scim이 기본 설정으로 포함이 된다면 한글 입력기 관련한 요구 사항들을 정리해 주실 분 계신가요?
.
.
또한, 플래시와 자바의 글꼴 설정은 어떻게 풀어가야 하는지도 보충 의견 부탁 드립니다.

Quote:

Concerning Korean input, SCIM actually has some usable input modules for Hangeul (both romanized and using a Korean keyboard layout), but I don't think it has any methods for inputting text with Chinese characters, which will also be useful in certain academic contexts, for instance. The only input method I know of is "Ami", which is a XIM-based method that has to be run under a ko_KR.eucKR locale or something in that order.

nabi와 imhangul에 대한 정보를 주는 것이 시급하다는 생각을 했습니다. (작년에 페도라를 쓰면서 IBM의 5250 Linux 터미널에 문제가 있어 개발자와 메일을 주고 받을 때도 수세를 쓰는 개발자는 ami 밖에 몰라 nabi를 check out 할 것을 권한 적이 있었습니다.)

xinit:
A script has to be add into /etc/X11/Xsession.d/, and it should be able to automatically set $XMODIFIERS, $GTK_IM_MODULE, $QT_IM_MODULE and $XIM_PROGRAM according to system locale, or read user's personal setting and change these variables accordingly.

위의 firefly patch에서 usegamma 부분만 다시 원상태로 하고 빌드를 하면, 굴림에서 한글과 영문이 나오는 것 아무 차이가 없습니다. 영문 글꼴은 약간 노란 색이 낀 것 처럼 보입니다. 컹커러의 문제는 동일하게 고쳐집니다. 그런데, 문제는 파폭에서 큰 굵은 한글 글자들에 대해 매 두번째 글자마다 약간씩 올라가는 것이 보입니다.
아무래도 페도라에 있는 패치를 적용해 보아야 하겠습니다.

그런데, 페도라의 패치 이름을 읽다보니 그 패치가 cvsfixes던데 freetype cvs 버전인가요? 그렇다면 다음 버전의 freetype이 나올 때까지 배포판에서는 cvs에서 소스를 댕겨다 쓰면 문제가 해결이 된다는 이야기인데... 아무튼 우분투에는 페도라의 패치를 테스트 해달라고 요청을 했고 이게 고쳐지면, 다음에 "글자 안 나오는 것" 그리고 "고정폭 글꼴" 등등해서 하나씩 버그 보고를 할 생각입니다.

우리도 불나방이 몇 날아다니면 좋겠습니다. :wink:

한영키 문제를 잠깐 다시 정리하면, 여긴 두 가지 문제가 있습니다. 첫번째는 한영키의 키코드가 아예 인식이 안되서 우분투에서 setkeycodes로 설정을 해주어야 한다는 것입니다. 이 문제는 커널의 키보드 드라이버의 문제인 것으로 보이며 설정을 어떻게 바꾼다고 해결되는 문제가 아닌 듯 합니다. 작정하고 커널 소스를 들여다봐야 해결이 될 것 같습니다.

두번째는 한글 키보드 설정이 없기 때문에 setkeycodes로 키코드를 인식해도 한영키가 심볼로 매핑이 되어 있지 않다는 것입니다. 그래서 xmodmap으로 설정을 해주는 방식으로 땜빵해서 쓰고 있죠. 이 문제를 해결하려면 xkb에 ko 키보드에 대한 설정을 추가해야 합니다. 이 부분 때문에 XKBConfiguration 관련 문서를 보고 있는데 그다지 어렵지 않게 추가할 수 있을 것 같습니다. 이 설정들을 우분투 xkb 패키지에 포함시키면 될 것입니다.

이 문제는 kbd패키지 및 키보드의 커널부분을 담당자에게 Japanese keyboard관련 문제로 여러차례 메일이 커널 메일링리스트에서 오갔던 것으로 기억합니다만, 커널 2.6이후에 필요하게된 setkeycodes를 사용하는 것이 정답입니다.

이 문제를 한영키의 인식 문제로만 인식하는 것은 좁은 시각입니다.
커널을 고쳐서 한영키를 인식하게 하는것은 인류 공영에 그다지 이바지 하는 것이 아닙니다.
특수한 키보드나, 다른 아직 알지 못하는 나라의 특별한 키보드를 사용하기 위한 도구를 만들고 그 설정을 제공하므로서 K만 아닌 CJKXXXXX 가 사용할 수 있는 프로그램을 만들어 부트 과정에서 사용하게 하는 것이 보다 적절한 방법이겠지요, 그리고 이런 방법이 프로그램 개발에서 한국에만 매몰되지 않는 방법이구요.

예전에는 어떠했는지 잘 기억이 나지 않습니다만 ㅡㅡ;; 모든 키보드모델에 대해서 한영, 한자키의 X11상의 keycode값이 일치하지가 않습니다. 그러므로 xkb를 만들어도 그다지 효용성이 없습니다. 저마다 다른 키보드에 대해서 자동으로 인식하는 키보드 매니져같은게 없는 이상, xkb를 만들어 봐야 무용지물입니다.

Quote:

이 문제를 한영키의 인식 문제로만 인식하는 것은 좁은 시각입니다.
커널을 고쳐서 한영키를 인식하게 하는것은 인류 공영에 그다지 이바지 하는 것이 아닙니다.
특수한 키보드나, 다른 아직 알지 못하는 나라의 특별한 키보드를 사용하기 위한 도구를 만들고 그 설정을 제공하므로서 K만 아닌 CJKXXXXX 가 사용할 수 있는 프로그램을 만들어 부트 과정에서 사용하게 하는 것이 보다 적절한 방법이겠지요, 그리고 이런 방법이 프로그램 개발에서 한국에만 매몰되지 않는 방법이구요.

여기에 대한 의견도 위와 같습니다. 스캔코드값을 읽지 못하는 것과 읽은 것을 무시하는 것은 다른 문제입니다. setkeycodes를 하지 않으면 스캔코드값조차 모른다는 건 거의 버그에 가깝다고 봅니다.

Quote:

예전에는 어떠했는지 잘 기억이 나지 않습니다만 ㅡㅡ;; 모든 키보드모델에 대해서 한영, 한자키의 X11상의 keycode값이 일치하지가 않습니다. 그러므로 xkb를 만들어도 그다지 효용성이 없습니다. 저마다 다른 키보드에 대해서 자동으로 인식하는 키보드 매니져같은게 없는 이상, xkb를 만들어 봐야 무용지물입니다.

그건 그렇지 않습니다. 자동으로 인식할 필요는 없죠. 키보드를 사용자가 선택하면 되니까요. 제가 알고 있는 대부분의 OS가 설치 시 키보드 종류를 물어보고 선택한 키보드를 인식합니다. '한글 106 key type 1' 이런 식으로 선택하면 한영키가 한영키로 기능하게 하는 것이죠. 이런 건 지금 XKB의 구조상 충분히 가능합니다. 일본은 이미 그렇게 하고 있구요. 보시면 아시겠지만 한국 외에 대부분의 국가가 다 자국의 XKB 세팅을 갖고 있습니다. 그리고 KDE나 그놈에는 이미 키보드맵을 선택할 수 있는 설정이 있습니다.

krisna님, 키코드가 다르게 오면 입력기 언어 변경은 어떻게 처리를 하시나요? 하드 코드 되었으리라고는 생각하지 않고 어떤 환경 변수와 비교하는 부분이 있나요?

im-switch로 입력기를 바꾸고 입력기가 바뀔 때 위의 환경 변수(?)가 정해지는 식으로 된다면 사용자가 키코드 값을 편집하는 현재의 경우를 피할 수 있게 될 수 있는지가 궁금합니다. 그래도 여전히 사용자가 한 번은 키코드 값을 넣어줘야 하나... 아니면 그 때 스캔코드를 가져와서 변환할 수 있나요 :?

Quote:

예전에는 어떠했는지 잘 기억이 나지 않습니다만 ㅡㅡ;; 모든 키보드모델에 대해서 한영, 한자키의 X11상의 keycode값이 일치하지가 않습니다. 그러므로 xkb를 만들어도 그다지 효용성이 없습니다. 저마다 다른 키보드에 대해서 자동으로 인식하는 키보드 매니져같은게 없는 이상, xkb를 만들어 봐야 무용지물입니다.

그건 그렇지 않습니다. 자동으로 인식할 필요는 없죠. 키보드를 사용자가 선택하면 되니까요. 제가 알고 있는 대부분의 OS가 설치 시 키보드 종류를 물어보고 선택한 키보드를 인식합니다. '한글 106 key type 1' 이런 식으로 선택하면 한영키가 한영키로 기능하게 하는 것이죠. 이런 건 지금 XKB의 구조상 충분히 가능합니다. 일본은 이미 그렇게 하고 있구요. 보시면 아시겠지만 한국 외에 대부분의 국가가 다 자국의 XKB 세팅을 갖고 있습니다. 그리고 KDE나 그놈에는 이미 키보드맵을 선택할 수 있는 설정이 있습니다.

사실 한국의 키보드는 미국 스타일의 표준(?) 키보드와 가장 가까운 키보드입니다. 프랑스나 독일, 스페인, 이탈리아 어디를 가도 다 자국의 키보드 변형이 있고 그 변형 정도는 한국보다 심합니다. 이런 키보드가 특수한 키보드로 취급 받아서 스캔코드조차 인식 안되는 상황이 전 싫습니다. 머, 어쨋든 이 문제는 제가 시간이 나는대로 대안을 마련해보도록 하겠습니다.

뭔가를 혼동하고 계신데, 스캔코드에서 키코드 변환 테이블에서 한영전환에 대한 키코드 맵이 빠졌다는 얘기가 스캔코드를 읽지 못한다는 얘기랑 같습니다. setkeycodes는 단지 한영키를 이 변환 테이블에 추가해주는 기능만 할 뿐이죠. 그때서야 비로서 스캔코드를 emit합니다.

한글 키보드만을 위해서 여러개의 키보드 세팅을 둔다? 네, 단 몇개정도의 키보드 세팅이라면 충분히 반영할 수 있을것입니다. 그래서 어떤 형태의 다른 키보드가 있는지를 조사하려 했던 것인데, 얼추 3개 이상의 다른 키코드를 가지는 여러 키보드가 존재합니다. 세팅을 미리 만들어둔다고 해도 일반 사용자들이 그것들을 고르기에는 쉽지않은 형국이 됩니다. 반영되기도 쉽지 않겠죠.

윈도우 같은경우는 보통 자동으로 세팅됩니다. 적어도 키보드를 판독해서 "자동으로 인식된 키보드는 어쩌고 입니다" 라고 제시해주죠.
또, 키보드 타입 1,2,3중 몇개는 아예 한영키가 없습니다. 조금 스토리가 다른 얘기죠. (한영키가 없는 경우의 키보드도 있는데, 이 글타래에서는 한영키가 아예 없는 경우에 대해서는 간과하고 있습니다)

krisna wrote:

...
이 것은 사용자가 키보드를 선택하더라도 문제가 있습니다. 동일한 키보드에 대해서 한영키의 키코드가 다르게 오기 때문입니다. 데비안에과 페도라의 한영키 키코드 값이 다릅니다.

설마 그럴리가요. 키보드 한영키문제는 커널 2.6 이후의 문제고,
커널만 같다면 같은 X11키코드가 나와야 정상이 아닌가요?
좀 더 분명하게 확인해야 할 듯.

좀더 구체적으로 이야기 하면 커널단에서 오는 키코드와 X에서 사용하는 키코드는 서로 같은 값이 아닙니다. 커널에서 오는 키코드는 동일한데, 이상스럽게도,
X에서 보여주는 키코드값이 다릅니다.

제가 사용하는 데비안 Xfree86에서는 '한/영'키의 키코드로 122가 오고
다른 많은 fedora 사용자들이 리포팅한 것으로는 210이 온다고 합니다.

구체적인 확인과 원인파악이 필요한 것 같습니다.