XKB로 한글 입력 구현 가능할까요?
원래는 UIM을 사용해서 리눅스 콘솔에서 한글을 입력하려고 했는데 안 되더라고요? 어떻게 하는지 도저해 모르겠더군요. 이게 관리가 안 돼서 망가진 건지 가상 터미널에서 작동하라고 만들어진 게 아닌 건지, 뭐가 뭔지 모르겠어요... 벼루 입력기나 모자이크 입력기가 작동 중이라고 가장 아랫줄에 써 있긴 한데, 입력은 계속 QWERTY로만 나오니 어쩌지도 못하고 있는 상황입니다.
이에 대한 대안으로, 서양권 친구들이 사용하는 입력 방식인 XKB로 한글을 입력할 수 있을지 의문을 가지게 됬어요. 지금은 XKB에서는 한/영 키랑 한자변환 키만 담당하고 있는데, XKB만 사용해서 (세벌식 완성형처럼 입력하는 거 말고) 평범하게 입력하는 게 가능할지 궁금해요.
제 미숙한 눈에는 가능할 거 같던데요... 국제 키보드로 ¯와 `를 chained dead key로 사용해 ḕ를 입력할 수 있듯이, 한글도 충분히 입력 가능할 거 같은데 말이죠.
과연, 세벌식이나 마지막 세대 타자기처럼 Shift 키 눌러서 초성이나 종성을 입력하는 방식 말고, 저희가 보통 입력하는 방식(ibus란 통합입력기를 통해 ibushangul이란 입력기를 사용하고, 그 입력기 내부적으로는 libhangul이란 걸 쓰는 걸로 알고 있어요. 틀린 부분은 적극적으로 정정 부탁드립니다.)과 같이, 아무 생각 없이 평범한 두벌식 키보드로 쳐도 제대로 잘 나오게 구현 가능할까요?
dead_acute (´)와 같은 데드 키(Dead key 혹은 prefix key; latching key라고도 한다고 어디선가 읽어본 거 같은 느낌적인 느낌)를 "ㄱ, 가, 각"등과 같은 각 글자에 적용해 libxkbcommon의 symbols에 추가하고, 각 데드 키로 만드는 한글 조합을 libxkbcommon의 xkb_compose_table에 추가해 주고 하면 되지 않을까요? xkbcommon-compose 어딘가에다가 한글 데드 키 입력을 취소할 때 입력했던 부분까지 조합하도록 어떻게든 할 수 있을 거 같은데...
undead_choseong_gieug(ᄀ) ---vowel---> undead_hangul_ga(가)
ㄴ--other letter-> print(ㄱ) + undead_choseong_nieun
ㄴ------else-----> print(ㄱ)
undead_hangul_ga(고) ----consonant---> undead_hangul_gog(곡)
ㄴ-----vowel-----> undead_hangul_gwa(과))
ㄴ--other letter-> print(고) + undead_choseong_nieun
ㄴ------else-----> print(고)
ㄴ---backspace---> undead_choseong_gieug(ᄀ)
undead_hangul_gog(곡) ----consonant---> undead_hangul_gog(곣)
ㄴ-----vowel-----> print(고) + undead_hangul_gi(기)
ㄴ--other letter-> print(곡) + undead_choseong_nieun(ᄂ)
ㄴ------else-----> print(곡)
ㄴ---backspace---> undead_choseong_gieug(고)이렇게 된다면 한글을 입력할 때 IME를 쓸 필요가 없어져서 운영체제에서의 한글 사용이 간단해지지 않을까요?
근데 안 되려나요? 그렇다면 왜 안 되는 걸까요?
리눅스 콘솔이라 함은 X윈도우, wayland 에
리눅스 콘솔이라 함은 X윈도우, wayland 에 진입하기 전을 말씀하시는 건가요? 예를 들자면 컴퓨터 부팅했을 때 텍스트 모드를 말씀하시는건가요?
텍스트 모드에서 한글 입력을 원하시면 libhangul 이나 자작 오토마타로 한글 조합하여 출력하는 기능을 만드시면 되고, 출력이 유니코드로 되니 터미널용 한글 유니코드 폰트가 있으면 되겠네요.
아니면 옛날에 사용하던 jfbterm, hanterm 이런게 있는데 그런 방식으로 작업하셔도 됩니다. jfbterm, hanterm 이 현 시점에서 수정없이 작동 가능한지는 모르겠네요.
XKB 말씀하셨는데, xkb 라는 이름 때문에 XKB 랑 libxkbcommon 라이브러리랑 헷갈리신 거 같은데,
XKB 는 https://www.x.org/releases/current/doc/xorg-docs/input/XKB-Config.html 이런 게 XKB 입니다. 참고로 https://nimf-i18n.gitlab.io/docs/how-to-set-hangul-hanja-key/ 이런걸 하는게 xkb 옵션입니다. 그래서 XKB 옵션은 wayland 환경에는 적용되지 않습니다. 그러나 libxkbcommon 를 사용하여 wayland 환경에서 그러한 기능을 제공하는 것이 가능하지만 클라이언트 환경마다 개별적으로 적용을 해야 한다는 단점이 있습니다. 예를 들자면, gnome + wayland, DE1 + wayland, DE2 + wayland ... 등, 각각의 데스크탑 환경(DE)이 각각 다른 방식을 사용할 수 있습니다.
libxkbcommon 는 X 뿐만 아니라 wayland 에서도 사용할 수 있는 범용 라이브러리입니다.
이거는 XKB 기능이 아니라 libxkbcommon 라이브러리에 있는 기능입니다. XKB 와는 관련이 없습니다.그리고 한글 입력 방법은 libhangul 뿐만 아니라 m17n-db 에도 들어 있습니다.
님께서 말씀하시는 한글 입력 방법이 결국에는 IME 에요. IME 가 없으면 입력을 못합니다. ḕ 이런거 조합해서 화면에 출력하는 방법이 일종의 IME 에요. 그걸 사용하기 편리하게 ibus, fcitx, uim, nimf 이렇게 거창하게 만드는거죠. 참고로 nimf 는 GUI 가 모듈(플러그인)로 분리되어 있어서 소스코드를 약간만 수정하면 GUI 가 없는 환경에서도 사용할 수 있게끔 설계되었습니다. 무슨 얘기냐면, GTK, Qt, X, Wayland 가 없는 환경에서도 작동한다는 의미입니다. GTK, Qt, X, Wayland 가 없는 환경에서 입력을 원하시면, nimf 에 text 모드용 인디케이터 플러그인, text 모드용 한자창 플러그인을 만들어서 기존에 있던 플러그인과 교체를 하면 됩니다. 또는 교체할 수 있는 옵션을 nimf 에 추가하면 되겠죠. nimf 는 GUI 가 모듈(플러그인)으로 완전히 분리되어 있습니다.https://www.nongnu.org/m17n/manual-en/m17nDBData.html
/usr/share/m17n/ko-han2.mim 이거를 참고하세요.
jfbterm
https://jfbterm.osdn.jp/#NEWS 보니 최근 글이 2003년. 오래 전에 중단된 것 같네요.
세벌 https://sebuls.blogspot.kr/
뭔가 답글 하나 작성하는 게 너무 오래 걸린다 싶었더니 내용이 길어서 그랬군요. 죄송합니다.
제가 글을 명확히 작성하지 않은 거 같네요. 최대한 정정하고, 묻고자 하는 바를 조금 더 명료하게 설명하려고 노력해 볼게요.
일단, 기본적으로는 리눅스/그누 환경에서 Ctrl + Alt + F4 같은 걸로 들어갈 수 있는 가상 터미널 환경을 기준으로 리눅스 콘솔이라고 했던 거고요. 그냥 가상 터미널이라고 하면 되지만 가상 터미널이란 말을 한국어로 사용하는지 잘 모르겠어서 햇갈리던 중 그냥 아무 말이나 사용했던 거 같네요.
XKB 옵션을 사용해 한글을 입력하려는 것이 아니고, libxkbcommon 라이브러리 자체의 기능을 한글 입력이 가능하도록 확장해서 사용하는 게 가능할지 여부를 묻는 질문이었습니다. 이 문서(https://wayland-book.com/seat/xkb.html)에서는 xkbcommon을 사용하는 걸 가지고 XKB를 사용한다고 표현했기에, 이러한 표현이 관용적으로 허용될 것이라고 생각했는데, 그렇지만은 않은 거 같네요.
IME를 사용하지 않아도 된다는 말은 틀린 거 같으니 정정하도록 할게요. 제가 하려던 말은 "독자적인," 따라서 운영체제를 설치했을 때 언어 입력기 설치를 따로 해야 하는 IME을 사용하지 않아도 된다는 거였어요. 일본어나 중국어의 경우, 입력 중 한자를 선택해야 하는 선택 환경에 아주 자주 놓이게 되는데 이런 기능은 데드 키 정도나 지원하던 일반적인 키보드 입력 방식과 확연이 다른 기술이 필요하기 때문에 이런 기능을 담당하는 부분을 "흔히는" IME라고 부르는 걸로 알고 있어요. 물론 사전적으로 따지자면 libxkbcommon을 사용하는 것도 입력 방식 편집기라고 할 수 있겠죠. 그렇지만 개인적으로는 CJKV와 같은 언어의 문자 입력기를 제외한 입력기 또한 IME라고 부르는 경우를 본 적이 없어서, IME라고만 하면 libhangul을 사용한 ibus-hangul이나 uim-byeoru처럼 ibus, uim, fcitx와 같은 IME 프래임워크를 통해서만 사용 가능한 입력기라고 이해해줄 거라고 생각했요.
제가 여쭈고자 하는 것은 ibus-hangul과 같은 완전한 "한국어" 입력기가 아니고, 비교적 간단할 "한글" 입력기의 구현이 가능한지 여부입니다. 기존의 한국어 입력기는 한자와 병용하던 시절부터 개발된 윈도우즈 한국어 IME와 같이 한자 기능을 기본적으로 탑재하고 있고, 한자 기능을 넣기 위해서는 xkb 관련 기능과는 거의 완전히 별도로 IME를 구성해 사용하는 게 필수적이니 지금과 같이 ibus-hangul과 같은 프로그램을 사용해야 합니다. 하지만 요즘 한자 안 쓰잖아요? 2020년이 되도록 지원이 완전하지 않은 IME 프래임워크를 사용하느니, 한자 입력이 지원되지는 않지만 운영체제를 설치하자마자 바로 사용할 수 있는 libxkbcommon에 연속 데드 키?(chained dead key가 한국어로 뭘까요)를 사용해 아예 한글 입력 기능을 추가하는 것이 리눅스 환경에 익숙하지 않은 사용자 입장에서 더 바람직할 거라고 생각하거든요.
한글은 중국어, 일본어, 한자와는 달리 알파벳입니다. 단어나 글자를 완성할 때마다 메뉴가 나와서 입력할 내용을 선택하고, 조합완료 버튼을 눌러 줘야 하는 글자 체제가 아니잖아요. 그런 한글은 중국이나 일본과 같이 자동완성기능 같은 게 들어가는 별도의 특화된 IME를 사용해서 입력할 필요는 없다 생각합니다.
대신에, 같은 조합형 알파벳을 사용하는 베트남어와 한 배를 타는 게 맞다고 생각합니다. 근데 리눅스에서 베트남 분들이 실재로 사용하는 베트남어 입력기가 얼마나 잘 구현돼 있는지 알지 못하기 때문에 확언할 수는 없지만, 리눅스에 기본 내장돼 있는 베트남어 입력기 기준으로 말하면 구려요. 한글에 그대로 가져다 쓸 생각조차 못 하겠더라고요. 이게 libxkbcommon의 한계를 맛 본 베트남 분들의 결론인 건지, 아니면 그냥 잘 못 만든 거 뿐인 건지 구별이 안 가서 과연 이게 가능한 건지 궁금해지더라고요.
각설, 폰트 관련해서는 fbterm (frame buffer terminal; https://github.com/izmntuk/fbterm)이나 그 wayland 쪽에서 만들던 kmscon 프래임 버퍼 터미널도 사용해 볼까 고려는 해 봤지만 너무 오래 전에 개발이 중단된지라 실험해보지는 않았어요. GNU Unifont(bdf-unifont)에서 한글 위주로 개량된, 데비앙에서 내놓은 bf-utf 폰트를 쓰려고 하긴 한데 어떻게 사용하는지 몰라서 찾아보던 중이었답니다.
nimf는 개발자 분이 막 짜증내면서 개발을 포기하신 걸로만 알고 있어서 재미로조차 고려하지도 않고 있었어요. 근데 하모니카에서 포크해 갔더군요. 추천해주셔서 감사해요! 혹시 관리가 되고 있을 지도 모르니 써 볼게요.
첨언: 전 "누구나" "아주 쉽게" 사용할 수 있는 한글 입력기가 있었으면 좋겠어요. 리눅스 커널에 한국어 지원이 된다면 얼마나 기분이 상쾌하겠어요?
첨언 2: m17n 라이브러리의 존재에 대해서는 전혀 모르고 있었어요. 알려주셔서 정말 감사합니다. 혹시 더 알려주실 게 있다면 언제든 얼마나 많든 다 던져 주세요! 근데 제 우분투 20.04의 /usr/share/ 폴더에는 m17n이 없더군요. 별로 많이 사용되는 게 아닌가 보네요?
정정: 하모니카에서 관리하는 nimf에 한국어/한글로 된 설명이 가득하다는 내용이 원문에 있었어요. 영어로 된 README 파일이 있더군요. 왜 멀쩡한 영어 원문이 있는데 굳이 접근성이 떨어지는 한국어 README로 바꾼 건지... 덕분에 사용 시도조차 안 했잖아요? 이래선 한국어 사용자를 완전히 갈라파고스화 하려는 것처럼 보이는데 말이죠. 하모니카는 뭐 하는 커뮤니티인지 모르겠어요. (그냥 하는 말이 아니고 정말 몰라요)
정정 2: 중2병스러운 문구 지웠습니다. 뭐 이미 밑에 박제당했지만...
libxkbcommon 있는 기능이 https:/
libxkbcommon 있는 기능이 https://en.wikipedia.org/wiki/Compose_key 여기 있는 방식일 겁니다. 컴포즈키를 지정하고, 컴포즈키를 누르고 'a 이렇게 치면 á 이렇게 나오는 방식이죠. 그런 방식으로 한글을 입력하는게 불편할 수 있습니다. 예를 들자면,
컴포즈키 + rk ==> "가" 이런 식으로 출력하는 방법을 생각할 수 있는데, 기존에 있던 조합 규칙과 겹치는 부분이 있는가에 대해 생각해봐야 하고,
화면에 "가나다"를 출력시킨다고 할 때,
컴포즈키 + rkskek 이렇게 입력하는 방법을 생각해볼 수 있는데,
조합 중인 글자(preedit)를 화면상에 rkskek 이렇게 보여주느냐, 아니면 "가나다" 이렇게 보여 주느냐, 아니면,
ㄱ가간나... 이렇게 보여주는냐.. 하는 문제 preedit 를 한글자씩 다루느냐, 아니면 스페이스하면 commit 하고 새로 조합을 시작하느냐.. 하는 문제들을 고려해야겠죠.
기존/현재 한글 입력 방법처럼 한글자씩 다루면, 한글자 입력할 때마다 컴포즈 키를 매번 눌러야 되겠죠.
여러 고민을 하다보면 libxkbcommon 에 한글 오토마타를 탑재시키는게 더 나을 거에요. 그런데 이미 libhangul 이라는 한글 오토마타가 있는데 libxkbcommon 에 한글 오토마타 기능을 탑재시키는 것은 불필요하다고 생각합니다. 그리고 libxkbcommon 측에서 받아줄지도 의문이고요. 이러한 방식으로 해결을 하려는 것은 좋은 방법이 아니라고 생각합니다.
이게 다 배포판 또는 GNOME 환경에 기본 탑재된 ibus 불량 때문에 그런거 아닙니까. 즉, ibus 를 고치던가, 그게 어렵다면 배포판 또는 GNOME 에서 ibus 말고 다른 입력기를 탑재해서 다국어 입력을 지원하는게 바람직한 방법입니다.
입력기 때문에 한글 입력 불편한 문제는 배포판, 데스크탑 환경 프로젝트들의 정책 문제라고 생각합니다. 하모니카에서는 nimf 를 기본으로 채택했기 하모니카를 설치하면 바로 한글을 사용할 수 있는 것으로 알고 있습니다.
그리고, libxkbcommon 은 오토마타, 다국어 입력을 위한 프로젝트가 아닙니다. libxkbcommon 를 다국어 입력을 위해서 쓰면 당연히 불편할 거고, 그거는 libxkbcommon 의 한계라 보기는 어렵습니다.
m17n 프로젝트는 다국어 입력을 위한 프로젝트이고, 이미 여러 기능들이 m17n 에 있으므로 두벌식 한국어를 위한 별도 작업은 필요하지 않습니다. 그러나 m17n 만으로는 중국어, 일본어 입력에 문제가 있습니다. 그래서 결국에는 ibus, fcitx, uim, nimf 같은 식으로 가는 거죠.
커널 레벨에서 다국어 입력을 지원하는게 현실성이 없습니다. 유니코드, 폰트만 해도 용량 많이 잡아먹을텐데요. 머리 굴려서 다국어 입력 기능을 커널 모듈 형태로 제공한다고 해도, 결국에 용량 문제 때문에 그걸 별도로 설치하는 옵션 방식으로 가겠죠. 다국어 입력 문제는 배포판에서 해결해야 할 문제입니다. 우리가 해외 어플, 해외 배포판에 의존하다보니 당연히 불편함을 느끼죠. 하모니카라는 배포판이 한국 실정에 맞게 나온 배포판으로 알고 있습니다.
그렇군요
제가 현재 쓰고 있는 자판인 English (intl., with AltGr dead keys)에서는 VT에서도 "AltGr+` e"로 è가 입력됩니다. 이건 그럼 다른 방식으로 입력되는 건가 보네요. 어떤 방식인지 궁금해지는군요.
한편으로 여러모로 제가 m17n에 대해 알아야 할 이유가 늘어가네요. m17n에서의 중국어와 일본어 입력에 어떤 문제가 있는지, m17n가 지금은 어떤 방식으로 쓰이고 있는지 등 궁금하군요.
운영체제 정책 면에 있어서 ibus 선택은 어쩔 수 없을 거 같아보이는데요. 그 쪽이 가장 활동이 활발해 보이고, 다른 대안이 없지 않나요? 크리어 사용자, 중국 대륙인 등의 입장에서 보면 nimf가 어떻게 더 좋을지 궁금하네요.
아무튼 하모니카는 적어도 당분간은 시도조차 안 할 거 같아요. 일개 국가 전용 배포판을 사용하는 것에 대해서는 저는 거부감이 있거든요. (원래는 상세한 이유를 적었는데 너무 지나치게 상세해져서 길어진 바람에 그냥 통째로 지웠습니다)
커널 레벨에서 다국어 입력을 지원하는 게 현실성이 있는 거 아닌가요? 유니코드 폰트와 같은 게 용량을 많이 잡아먹겠지만 어짜피 다 모듈러하게 만들어져서 옵션 방식으로 갈테니까, 커널에 넣는 거 자체는 문제가 없잖아요. 어짜피 옵션인데요. 어짜피 옵션인 거, 따로 관리하느니 커널에 합쳐서 넣는 게 낫지 않을까요?
> "AltGr+` e"로 è
> "AltGr+` e"로 è
이런 방법은 옛날부터 사용되던 조합 규칙을 구현해서 만드는거죠. 직접 자작해도 되고, libxkbcommon 함수를 사용해도 되고요. 그건 X윈도우의 XKB는 아니에요.
m17n에서의 중국어와 일본어는 한자 변환에 문제가 있죠. 그래서 중국어,일본어를 위해서는 rime, anthy 같은 걸 쓰는게 좋죠.
ibus 의 대안으로 nimf 가 있죠.
https://nimf-i18n.gitlab.io/architecture/
궁극적으로는 통합 입력 api 가 제정되어야 합니다.
> 커널 레벨에서 다국어 입력을 지원하는 게 현실성이 있는 거 아닌가요?
현실성이 없습니다. 유사 문제 또 발생할거고, 응용 어플 api 를 모두 새로 작성해야 합니다.
다만, 자작 커널 모듈 레벨에서 마우스 클릭을
다만, 자작 커널 모듈 레벨에서 마우스 클릭을 다룬다면, 응용 어플이 마우스 클릭할 때 입력기를 reset 하지 않아서 발생하는 끝글자 버그에 대응할 수 있습니다. 현재의 nimf 는 X어플이 마우스 클릭할 때 입력기를 reset 하지 않아서 발생하는 끝글자 버그에 대해 회피를 하지 못하는데, 자작 커널 모듈 레벨에서 마우스 클릭을 다룬다면 그 버그까지 회피할 수 있게 됩니다.
하모니카
세벌 https://sebuls.blogspot.kr/
하모니카, 티맥스 오에스, 구름OS 외에도 배포판을
하모니카, 티맥스 오에스, 구름OS 외에도 배포판을 만들려는 시도는 앞으로 계속 되어야 한다고 생각합니다.
첫술에 배부를 수 없습니다.
하모니카, 구름과 같은 시도는 계속되는 것이 좋다고
하모니카, 구름과 같은 시도는 계속되는 것이 좋다는 말씀에 동의합니다.
이런
(대략 몰라뵀다는 내용의 댓글)