<날개셋> 한글 입력기가 8.0이 나온 뒤 거의 4개월 만에 8.2로 버전이 올라갔다. 1.0 이래로 개발 10주년을 자축한 지가 엊그제 같은데 벌써 15주년이 됐다. ㄷㄷㄷㄷ 이번에도 여느 버전업 때와 마찬가지로 온갖 부분에서 자잘한 개선과 변경 사항이 생겼다. 이 8.2는
- 1.0 이래로 개발 15주년 돌파
- 전체 소스 코드가 7만 줄 돌파
- 32비트 msi 배포 패키지가 정확히 2MB 돌파
- 32비트 ngs3.dll 커널 크기가 700KB 돌파
라는 여러 기록을 보유하게 되었다.
타자연습은 변화 사항이 없지만 API 구조와 폰트 로딩 방식의 변경 때문에 불가피하게 재컴파일 업데이트를 하게 됐다. 입력기는 8.2인데 타자연습은 구버전을 계속 사용한다면, 실행은 되겠지만 이제 글꼴 리스트에 글꼴들이 제대로 표시되지 않을 것이며, '고급 입력 스키마/입력기'는 로딩이 되지 않을 것이다. 그러니 타자연습도 부득이 같이 업데이트를 해야 한다.
1. Windows 10 지원
이번 8.2는 Windows 10에서 정식으로 테스트된 최초의 버전이다.
Metro UI에서는 제어판이나 텍스트 필터처럼 데스크톱 GUI를 사용하는 기능들을 모두 사용할 수 없게 막았다. 이건 뭔가 새로운 기능을 추가한 것도 아니고, 지금까지는 굳이 필요하지 않던 안전 체크 오버헤드만이 추가된 것일 뿐이다. 본인은 개인적으로 Metro UI는 왜 존재하는지 모르겠다.
명령 프롬프트에서 한글 입력이 더 진행되지 않던 문제를 고쳤고, 그 상태에서 제어판이 동작하지 않던 문제도 해결했다. (명령 프롬프트는 Metro 앱이 아니기 때문에 제어판 접근이 가능해야 한다.) 두 문제 모두 Windows 10의 명령 프롬프트는 예전 버전과는 영 다른 방식으로 동작하기 때문에 발생했었다.
이 정도 보완만 해 주면 되는 듯하나, Edge 브라우저에서 페이스북의 댓글란에 한글 입력이 제대로 안 되는 것은 기술적으로 해결 불가능한 문제로 남았다. 도대체 입력 문자를 어떻게 넘겨 줘야 MS IME 와 동일하게 동작할 수 있는지 현재로서는 알 수 없다. Edge의 버그에 더 가까운 것 같다.
늘 느끼는 것이지만, Windows에서 한글 입력기를 만드는 일은 프로토콜이 IME에서 TSF로 바뀌면서 무질서도와 난관이 한 10배 가까이 뛰고 더 복잡하고 어려워졌다. 예전에는 뭔가 static하고 write-only이기만 하던 고정 프로토콜에다가 문자열을 넣어서 메시지만 쏴 주면 됐지만 지금은 스레드 동기화부터 시작해서 온갖 복잡한 COM 객체 관리, 게다가 레거시 프로그램에 대한 호환 유지, 스펙대로 동작하지 않는 프로그램에 대한 보정.. 등 지저분함이 이루 말로 표현할 수 없다.
극소수 프로그램에서 드디어 텍스트의 임의 조작이 가능해진 것은 분명 큰 발전이지만, 그것 말고 똥싸 놓은 걸 치워야 하는 것도 많다.
2. 입력 패드에 후보 변환 기능 추가
요 근래엔 <날개셋> 한글 입력기의 제3의 구현체인 입력 패드가 장족의 발전을 거듭해 왔다.
7.9에서는 '화면 키보드' 기능에 눌린 글쇠 표시 기능이 추가되었으며, 이 작업을 발전시켜 8.0에서는 입력 패드가 여타 구현체와 대등한 수준으로 키보드 입력이 가능해졌다. 그리고 이번 8.2에서는 조합 중인 글자 하나에 한해서 한자 후보 변환까지 가능해졌다. 그리고 이 기능을 구현하기 위해 후보 변환 프로토콜을 전반적으로 재설계· 확장하는 대공사가 선행되었다.
지금까지 <날개셋> 한글 입력기가 내부적으로 사용하는 프로토콜은 중간에 후보 변환 요청이 있는 경우, 사용자가 무슨 후보로 변환할지 완전히 응답을 해야(취소하는 것도 포함해서) 다음 단계로 진행이 되는.. 일종의 순차· 동기적인 진행만을 지원했다.
이것은 편집기처럼 한자 후보 목록이 별도의 modal 대화상자로 출력되는 구현체에는 곧장 적용 가능한 만한 반면, 외부 모듈처럼 (1) 후보 목록이 뜬 채로 key 입력을 계속 받아들여야 하는 구현체에는 적합하지 않은 구조였다. 그렇기 때문에 동일 코드의 중복 같은 지저분한 편법이 필요했다. 그런데 외부 모듈과 비슷하게 동작하는 구현체(= 입력 패드)가 또 추가되고, 적합하지 않은 프로토콜을 여기에 또 적용할 수는 없기 때문에 이 기회에 리팩터링을 왕창 하게 되었다.
또한, 기존 프로토콜은 한자 후보 선택을 받은 뒤에 cursor를 이동시키거나 텍스트를 조작할 수만 있었지, (2) 반대 순서의 동작을 시킬 수는 없다는 한계도 지니고 있었다. cursor를 이동시켜서 다른 위치에 있는 글자에 대해 후보 변환을 할 수가 없었다.
아래아한글이나 MS IME에서 '토선생'이라는 단어를 입력해서 '생'을 조합하고 있는 상태로 한자 키를 누르면.. 앞의 '토선'이 선택되고 土船이 후보로 제시된다. 그거 변환을 하고 나면 cursor는 다시 '토선'이 아니라 '생'의 뒤로 딱 되돌아온다.
그러나 <날개셋> 한글 입력기는 cursor 위치는 변함이 없고 뒷부분의 '선생'이 선택되고 先生이 후보로 제시된다. 전자와 같은 동작은 프로토콜 차원에서 근본적으로 구현할 수 없기 때문이었다.
8.2부터는 드디어 이런 한계가 없어졌다. 내 프로그램 역시 MS IME와 완전히 동일한 방식으로 자유자재로 텍스트를 조작하면서 원하는 때에 후보 변환 UI를 modal 형태든 그렇지 않은 형태든 꺼낼 수 있다. 단, 실제로 MS IME와 동일한 방식으로 동작하는 기능 자체는 당장 반영되지 않았고 <날개셋> 한글 입력기의 소스 내부에 #ifdef ... #endif의 형태로 막혀 있다. 일단은 이론적으로 구현 가능해졌다는 것만 입증하고 넘어갔다.
<날개셋> 입력 패드에 후보 변환 기능은 이런 최신 프로토콜을 기반으로 구현되었다. 외부 모듈에 존재하는 후보 선택 UI를 그대로 가져다 쓰는 것을 고려했지만 현실에서의 여러가지 문제점으로 인해 그렇게 하지 않고 또 자체 구현을 했다. 외부 모듈의 후보 선택 UI는 운영체제의 프로토콜과 맞물려서 패드에는 필요하지 않은 오버헤드가 너무 많기 때문이었다.
입력 패드의 후보 선택 UI는 <날개셋> 한글 입력기의 GUI 엔진이 자체 제공하는 리스트박스 컴포넌트를 이용하여 최대한 간결· 단순하게 구현되었다. 외부 모듈의 것과 거의 동일하지만 확장 모드(tab 키)는 지원되지 않으며, 세로쓰기 모드의 지원도 기술적으로 불가능하지는 않으나 구현을 과감히 생략했다.
그 대신 입력 패드의 후보 리스트는 스크롤 막대를 마우스로 누르거나 끌어 보면, 줄 단위 스크롤이 가능하여 좀 더 직관적이라는 차이가 존재한다. 외부 모듈의 그것은 언제나 페이지 단위 스크롤만 된다. 물론 마우스가 아니라 키보드 화살표로 선택막대를 움직이면 페이지 단위로 스크롤된다. 페이지 단위로 이동 후 1~9 숫자를 선택하는 동작도 여전히 고려했기 때문이다.
후보 UI를 구현할 때 같이 구현돼야 하는 중요한 요소 중 하나는 후보 윈도우를 어디에다 표시할지를 결정하는 것이다. cursor 근처 아래에다가 표시해 주는 게 원칙인데, 이걸 hook 프로시저를 통해 알아 와야 한다. 이때는 IME 쪽 인터페이스만 사용하는 게 아니라 오버헤드를 감수하고라도 정확도의 향상을 위해 TSF 인터페이스도 사용한다. 훅킹으로 응용 프로그램에서 TSF edit session까지 요청해 보는 것은 처음이어서 프로그래밍이 굉장히 흥미로웠다. 32비트와 64비트를 구분 없이 모두 잘 지원하는 건 물론이고.
단, 이미 사용하고 있는 시스템의 IME가 한영 내지 한자 키를 가로채고 있으면 키보드 입력 모드에서도 이 입력 패드가 그 key들을 가로챌 수 없다. 그러므로 입력 패드에서 한자 변환을 하려면 F9 같은 다른 위치에다가 C0|0x82 같은 후보 변환 기능을 배당해 놓고 있어야 한다.
3. 글꼴 쪽의 변화
'한메가는본문'이라고 타자기 자형처럼 생긴 한글 글꼴이 지금까지 있었다. 개인적으로는 이것과 Lucida Console 영문 글꼴이 같이 잘 어울린다고 생각했는데, 이번 8.2에서는 이것과 같은 계열인 '한메굵은본문'이 추가되었다. 도스용 한메한글이 출력하던 글꼴을 그대로 재현한 것이다.
한메 계열 글꼴은 초성 5, 중성 2, 종성 3벌로 되어 있어서 도깨비 8*4*4보다 구조가 더 간단하다. 특히 '고'의 ㄱ과 '공'의 ㄱ이 동일해서 더욱 타자기 글꼴 같은 느낌이 나지만, 그렇다고 진짜 샘물이나 타자기 계열만치 과격한 모양은 아니다. 또한, '한솔바탕'과도 좀 비슷해 보이지만 그래도 엄연히 차이가 느껴진다.
그리고 이번에 굵은본문을 분석하고 추가하는 과정에서, 기존 가는본문의 조합 규칙이 몇 년째 잘못되어 있던 것도 같이 발견하여 고쳤다. 당장 '메' 자를 보면 차이를 발견할 수 있다.
잘 알다시피 <날개셋> 한글 입력기는 컴퓨터에서 한글을 '입력'하는 모든 아이디어와 기술을 구현하는 기반 시스템이다. 그런데 편집기는 다른 구현체와는 달리 독자적인 한글 글꼴 출력 시스템도 갖추고 있으며, 특별히 과거에 존재했던 다양한 독창적인 비트맵 글꼴들을 몽땅 한데 재현하는 일에도 덤으로 관심을 두고 있다. 아래아한글, Windows 3.x, mshbios 등. 입력 방식뿐만 아니라 글꼴도 보존 가치가 있는 옛날 데이터가 또 발견된다면 얼마든지 채택되고 추가될 것이다.
그리고 이번 버전에서는, 겉으로 차이가 느껴지지는 않겠지만 글꼴의 전반적인 로딩 방식을 memory-map 기반으로 바꿨다. 그래서 여러 프로그램에서 <날개셋> 한글 입력기 외부 모듈을 사용하고 있고 여러 프로그램들이 동일한 한자 글꼴 같은 걸 중복해서 로딩하더라도, 메모리가 제각각 따로 할당되는 게 아니라 1파일 1메모리가 보장되어 더 효율적으로 동작하게 했다. 뭐, 요즘처럼 메모리가 넘치는 환경에서는 겨우 16*16 비트맵 글꼴 나부랭이는 중복 로딩을 한다 해도 별 부담이 되진 않겠지만 말이다.
4. 변수 N의 의미 확장
기본 입력 스키마가 글쇠배열에다 제공하는 변수로는 P (caps lock 여부), N (num lock 여부), T (오토마타의 조합 상태), D~F (입력 중인 한글 자모)가 있다. T, D~F는 정수인 반면 P와 N은 일종의 0 아니면 1의 boolean값이었다.
그런 키보드 램프의 상태에 따라 서로 다른 문자를 되돌리고 싶으면 해당 변수 값을 토대로 ? : 조건부 수식을 지정하면 된다. caps lock은 그렇다 치더라도 num lock의 경우, 세벌식 글쇠배열의 숫자 자리를 키패드처럼 바꾸는 용도로도 활용할 수 있어서 매우 편리하다.
본인은 이 생각을 아주 오래 전부터 했기 때문에 저건 <날개셋> 한글 입력기의 1.0때부터 있던 기능이었다. 단지 그때는 지금 같은 입력 스키마와 문자 생성기의 계층 구분이 없었기 때문에, 그 기능이 입력 스키마의 변수가 아니라 그냥 입력 옵션 중 하나로 제공되었을 뿐이다.
그런데 이번 버전에서는 옵션을 추가로 줄 경우, N에 num lock (비트 1)뿐만 아니라 scroll lock (비트 2)도 같이 줄 수 있게 했다. 이 옵션이 지정되어 있으면 N은 앞으로 키보드의 상태와 관련된 다른 유의미한 비트 플래그가 도입될 경우 4, 8, 16 같은 식으로 의미가 계속 추가될 것이다.
scroll lock은 사실 굉장한 잉여 램프로 전락해 있으며 caps lock만치 문자 입력에서 중요한 역할을 하지는 않는 게 현실이다. 그렇기 때문에 별도의 독립된 변수를 할당하지는 않고 기존 N에서 비트만 추가하는 것으로 의미를 정했다.
그래도 기능을 일단 만들어 놓으면 이것도 아주 창의적으로 활용하는 사용자가 분명 있으리라고 생각된다.
따라서 이 옵션을 켠 상태에서 num lock만 인식하려면 글쇠 수식을 N ? A: B 이렇게 작성할 게 아니라 번거롭지만 N&1 ? A: B라고 써 줘야 한다.
세벌식 키패드 수식을 생성해 주는 빠른설정 기능은 여기에 맞춰 &1이 추가되도록 알고리즘이 수정되었다.
5. 키보드 드라이버 보정
이번 버전에서는 입력기나 편집기 계층이 아니라 시스템 계층에서 꽤 참신한 기능이 하나 또 추가되었다. 바로 키보드 드라이버의 글쇠 인식을 인위적으로 변조하는 기능이다.
내 프로그램의 내부에는 Shift+Space를 '한영'으로 바꿔서 인식하는 type-3 키보드의 동작을 도로 무효화하는 보정이 있었다. 그런데 이 로직이 편집기와 외부 모듈과 패드의 구현체에 몽땅 중복으로 존재하며, 이것도 켜거나 끌 수가 있게 해야겠다는 생각에 별도의 계층으로 빼냈다.
그리고 type-3 보정뿐만 아니라 type-1 보정도 추가했다. 바로, 오른쪽 Ctrl/Alt를 한영/한자가 아니라 있는 그대로 인식하는 것 말이다. 이로써 한국어 키보드에서도 Ctrl/Alt의 좌우 구분이 가능해졌다. 물론, 아무 보정을 하지 않는 것도 가능하고 말이다. 왜 이런 유용한 기능을 진작에 넣지 못했나 하는 아쉬움이 느껴진다.
그리고 여기서 키보드 드라이버 보정을 한 것은 물론 응용 프로그램이 아니라 <날개셋> 한글 입력기 내부에서만 통용된다. type-1 보정을 했다고 해서 오른쪽 Alt로 응용 프로그램의 메뉴를 바로 열 수 있는 건 아니다.
시스템 계층 설정에는 지금까지 글꼴과 관련된 설정과 기능 몇 가지만 있었는데 '보정 없음, type 1, type 3'이라는 세 항목 중 하나를 선택하는 UI도 추가되었다.
시스템 설정의 내용은 사용자 컴퓨터의 레지스트리에 저장되지, ist/st 같은 파일에는 저장되지는 않는다. '미저장 확인'을 누르면 해당 프로그램이 실행되어 있는 동안만 유효하니, '확인'을 눌러야 레지스트리에까지 저장되어 다음에 프로그램을 재실행할 때도 반영된다.
6. 키패드 글쇠와 키보드 글쇠의 구분 기능
Scroll lock 지원과 키보드 드라이버 보정. 이번 버전엔 어쩌다 보니 키 입력 인식과 관련된 기능이 여럿 추가됐는데, 이것만 들어가기에는 좀 아쉽다.
이번 8.2에서는 <날개셋> 한글 입력기의 개발 역사상 최초로 일부 글쇠에 대해 키패드 글쇠와 키보드 글쇠를 구분해서 인식할 수 있게 되었다.
그 대상은 바로 상하좌우 화살표(4) + Home/End/Pg Up/Pg Dn(4) + Ins/Del(2) + 엔터 이렇게 총 11개이다.
단축글쇠 배당 대화상자를 열어서 이들 키를 누르면.. 오른쪽에 종류를 묻는 콤보 상자가 추가로 뜬다. 사용자는 종전처럼 "구분 없이 아무 거나 인식"을 선택해도 되고, 키보드 것만 혹은 키패드 것만 인식하게 설정할 수 있다. 문자 키와 키패드 사이에 따로 몰려 있는 구역도 '키보드' 영역이다.
그리고 고급 입력 스키마에서는 바로 N 변수에서 1(num lock), 2(scroll lock)에 이어 4가 이 글쇠의 변별을 담당한다.
Windows의 키보드 메시지에서 extended key 플래그가 바로 여기에 전달된다. 다른 글쇠들은 키보드 글쇠일 때 플래그가 켜져 있지만, 엔터만 유일하게 키패드 글쇠일 때 플래그가 켜져 있다. 여기에는 사연이 좀 있다.
extended key란 예전의 84/86키 키보드에는 없다가 지금과 같은 101/103키 키보드에서 중첩되어 새로 추가된 key를 나타내는데, 예전에는 키패드에 엔터가 없다가 나중에 키패드에 새로 추가됐기 때문이다.
그 반면, 나머지 home, end 같은 건 원래 키패드에만 있다가 나중에 별도의 구역이 또 추가된 것이기 때문에 '키보드'에 속하는 구역의 글쇠들이 extended이다.
아무튼 이런 옵션과 변수를 통해서 단축글쇠와 고급 입력 스키마에서 모두 키보드와 키패드를 구분해서 글쇠를 인식할 수 있다.
7. 보조 입력 도구
끝으로, 사소한 사항으로는..
보조 입력 도구인 '부수로 한자 입력'에서 부수나 한자를 우클릭했을 때 해당 글자를 클립보드에 복사하는 명령을 추가했다. 지금까지는 이 명령이 문자표에만 있지 부수 한자 입력에는 없었다.
그리고 문자표에는 알다시피 문자를 운영체제의 특정 글꼴로 출력하거나 내장 비트맵 글꼴로 출력하는 옵션이 있는데, 제어판의 시스템 계층에서 설정된 그 후보 출력용 글꼴을 지정하는 옵션도 추가했다. 지금까지 이런 기능이 왜 없었는지 모르겠다.
이들 보조 입력 도구는 지금으로부터 5~6년 전, 5.5x 시절에 처음으로 도입되었다. 참 격세지감이다.
위의 신규 기능들을 구현하는 과정에서 꽤 황당한 버그가 오랫동안 남아 있던 것을 발견했다.
원래 날개셋 제어판을 열었다가 '확인'을 눌러서 닫으면 입력 설정만 저장되는 게 아니라 모든 플러그 인들의 설정도 파일로 저장된다. 텍스트 필터들의 내부 설정들이 여기에 포함되며, 문자표는 사용자가 예전에 선택한 글꼴과 view 모드를 이 방식으로 기억하고 있는다.
그런데 64비트 에디션은 그런 플러그 인 기능들을 설정을 변경한 뒤 사용하고, 날개셋 제어판을 '확인'을 눌러서 닫았는데도 해당 프로그램(편집기 같은..)을 재실행했을 때 예전 설정이 보존되어 있지 않았다. 파일 오프셋과 관련된 착오가 있는 것을 확인해서 즉시 고쳤다.
Posted by 사무엘
