김 용묵의 절대공간 - 블로그

날개셋 한글 입력기가 10.1 이후 4개월 만에 다음 버전(10.2)이 나왔다.
아아.. 개발자의 역량의 한계로 인해 날개셋 한글 입력기의 개발 속도가 점점 느려지는 것 같다. 변화 내역을 보니 옛날 같았으면 버전을 0.1만치 올릴 분량이 안 되는 것 같은데.. -_-;;

그래도 시간이 4개월이나 지났고 아이템들이 마냥 사소한 것만 있지는 않으며, 나름 버전이 10.x인데 굳이 소수점 둘째 자리를 건드릴 필요는 없다는 점을 감안하야 다음 버전을 10.1x 대신 10.2로 정했다.
두 달 전에 소식을 먼저 전했던 바와 같이 외부 모듈의 동작 방식이 개선된 것이 가장 큰 자랑거리이며, 제어판의 외부 모듈 관리 페이지가 동작이 개선된 것도 개인적으로 뿌듯하게 생각한다. 그것 말고 다른 변화를 열거하자면 다음과 같다.

1. 외부 모듈에 자체적으로 겹침 모드 지원

날개셋 한글 입력기 외부 모듈에서 도구모음줄의 버튼들의 종류와 역할은 거의 3.x 버전 시절부터 15년 가까이 변화가 없었다. 그랬는데 이번에 마이너한 버튼이 하나 추가되었다. 바로 자체적인 삽입/겹침 모드 전환이다.

삽입/겹침 모드는 바로 전 10.1 버전부터 이제 날개셋 제어판에서 지정하는 설정이 아니라 각 구현체들이 자체적으로 관리하는 상태로 위상이 바뀌었다.
편집기(= 날개셋 자체 에디트 컨트롤)은 ins 키 내지 상태 표시줄을 클릭해서 삽입/겹침을 지정할 수 있는 반면, 외부 모듈은 그런 게 없었다. 그래서 10.2에서는 이를 보완하는 별도의 버튼이 추가된 것이다.

물론 이 모드는 TSF가 제대로 지원되는 환경에서만 의미를 가지며, 90% 이상의 상황에서는 그냥 삽입 모드로 동작한다. 궁극적으로는 응용 프로그램이 제공하는 겹침 모드와 외부 모듈이 동작하는 겹침 모드가 서로 자동으로 연계되는 게 가장 좋지만.. 그렇지 못한 현 상황에서는 이렇게 아쉬운 대로 겹침 모드를 지정할 수 있게 했다.

아울러, 날개셋 편집기는 1.0 이래로 ins는 삽입/겹침 상태만 전환하고 shift+ins는 낱자/글자만 전환했었다.
그러던 것을 Shift+ins를 누르면 곧장 '낱자+겹침' 모드로 진입하고, ins를 누르면 곧장 '글자+삽입' 모드로 전환되게 동작을 수정했다. 필요할 때 낱자 겹침 모드로 곧장 진입했다가 신속하게 이전 모드로 복귀할 수 있게 한 것이다. 구체적인 동작 로직은 다음과 같다.

아 참.. Windows 10에서는 도구모음줄 버튼들이 저렇게 길게 표시되지 않으니 삽입/겹침 모드도 저렇게 우클릭 메뉴에서 선택해야 한다.
이거 손보는 김에 전자/반자 버튼에 해당하는 메뉴도 수정했다. 지금까지 체크 표시 달랑 하나로 전/반 모드를 나타냈는데.. 그걸 별도의 팝업 메뉴를 통해 선택하고 라디오 버튼 모양을 통해 현재 모드를 나타내게 했다.

정보량이 1비트라고 해서 아무데서나 체크 UI를 사용하지는 말아야 하기 때문이다. 가령, 남/녀 성별을 ‘여자임 체크’ 이런 식으로 지정해서는 안 될 것이다. ㄲㄲㄲ
그나저나 상태 표시줄과 입력 도구모음줄이 동시에 나타나 보이는 버그는 Windows 10 [2004] 버전에서도 고쳐지질 않고 있구나. 이쪽은 아예 out of 안중인 걸까..?

2. 단어 경계 인식 방식 개선

그리고 편집기에서 역시 10년 넘게 변함없던 단어 단위 식별 방식을 개선했다.
일정 길이 이하의 짧은 단어에 대해서는 알파벳, 밑줄, 숫자를 한 덩어리로 인식하게 했다. 이건 텍스트의 더블 클릭 내지 Ctrl+(좌우 화살표/bksp/del)에서 동작을 확인할 수 있다.

이렇게 하니 프로그램 소스 코드에서 16진수 상수나 변수 명칭들이 정확하게 한 단어로 인식되기 때문에 프로그램의 사용성 내지 편의성이 훨씬 더 나아졌다. 문자의 종류가 바뀐다고 괜히 그 안에서 멈출 필요가 없었다. 왜 진작부터 이런 조치를 취하지 않았나 모르겠다.

3. 나머지 자잘한 변화

다음과 같이 여러 자잘한 부분이 수정되고 개선됐다. 심지어 여기에 기록되지 않은 더 자잘한 사항도 있다.

• 휠을 눌렀을 때 나타나는 동그란 자동 스크롤 패드 그림의 가장자리에다 그림자 효과 추가
  
• 편집기 파일 메뉴의 최근 사용 파일 목록에서 현재 열려 있는 파일은 체크 표시
  
• 24픽셀 크기에 대해 U+1D00~U+1FFF 비트맵 글립 추가
  
• 편집기의 색깔 구성표에 '민트색'도 추가
  
• 제어판의 입력 항목 정보 페이지에서.. 외부 키보드 드라이버 같은 파일을 열었던 내역이 날아가 버리던 문제 해결. 다음에 열기/저장을 할 때 보존되게 함
  
• 제어판의 '입력 일반' 탭에서 사용자 정의 제2/제3 후보 관련 설정 UI를 더 직관적으로 개선함
  
• 입력 도구를 닫았다가 다시 열 때, 무조건 이전 위치가 아니라 현재 존재하는 모니터의 영역도 감안해서 표시되게 개선

※ 넋두리: 디지털 서명의 필요성

2020년대를 맞이하여 날개셋 한글 입력기가 내부의 기능 개발 말고 외부 환경과 관련하여 앞으로 이뤘으면 하는 과업이 두 가지 있다. 하나는 ARM64 지원, 그리고 다른 하나는 디지털 서명이다.;;
전자를 하려면 아무래도 개발용 기기를 구매해야 하는데 본인이 딱히 그걸 들여다 볼 여유가 없다.

그리고 후자도.. 인터넷을 찾아보니 사업자 등록증 없는 개인 개미 개발자에게도 인증서를 발급하는 기관이 있긴 하다. 하지만 이것도 어떤 형태로든 돈이 10만원 이상씩 깨지며, 그것도 한 번만 내고 끝이 아니라 지속적으로 홈페이지 유지 비용만치는 지불해야 한다.

아직까지 디지털 서명 없이 버티고는 있지만.. 이걸 안 하니 각종 게임이나 운영체제의 보안 솔루션에 의해 내 입력기가 강제 종료되거나 심지어 강제 삭제된다는 신고가 심심찮게 들어온다. 이것도 언제까지나 방치할 수는 없는 사항인데 좀 고민된다. 이와 관련하여 최근에 있었던 일을 좀 소개하고자 한다.

하루는 어느 온라인 게임 개발사에서 메일이 왔다. 자기들 게임에서 님하의 입력기를 구동했더니 자꾸 뻗는다면서 crash 덤프 파일을 몇 개 보내 줬는데..
일단, 3년도 더 전에 나왔던 9.5부터 포함해 9.6, 9.8x 등 구버전이 아직도 많이 쓰이고 있다니 놀랐다. 10.0이나 10.1 덤프는 없었다.

하긴 내 프로그램은 자동 업데이트 기능이 없고 딱히 사용 내역 데이터 수집 같은 걸 하지도 않으니, 내 프로그램이 사용자들에게 어떤 형태로 쓰이는지는 나도 전혀 알지 못한다.
뭐, 사용자도 내 홈페이지를 일부러 들어가지 않는다면 프로그램 새 버전을 전혀 접할 수 없을 것이다.

버전은 그렇다 치고.. 내 입력기가 뻗는 이유는 커널인 ngs3.dll이 디지털 서명을 받지 않았다는 이유로 출처가 의심돼서.. 그 게임 내부의 보안 솔루션이 로딩과 실행을 차단했기 때문이었다.
파일이 아예 없는 경우라면 내 입력기도 대비가 돼 있어서 동작을 전혀 못 할지언정 뻗지는 않게 돼 있는데..
뻔히 로딩이 된 뒤에 보안 솔루션이 개입해서 ngs3.dll을 없애 버리는 듯했다.

흐음.. 보안 솔루션이 키보드 드라이버의 동작을 바꿔서 한글 IME의 동작까지 교란시키는 경우는 이미 잘 알려졌지만, 아예 이런 식으로 디지털 서명이 없는 DLL의 로딩에도 관여할 수 있다는 걸 알게 됐다.

Posted by 사무엘

현재 날개셋 한글 입력기 10.2 또는 10.3이 올해 봄(3월 중) 정도를 목표로 개발 중이다. 간단한 개발 근황과 소식을 다음과 같이 몇 가지 전하고자 한다.

1. 외부 모듈의 동작 방식 개선

이번 버전에서는 이제 변경이나 개선의 여지라고는 도저히 없을 거라고 여겨지던 외부 모듈의 기본 동작이 바뀌었다. 겉으로 드러나는 결과는 동일하고 딱히 문서화돼 있지도 않던 내부 동작을.. 정밀 디버깅 끝에 MS IME와 더 비슷하게 일치시켰다.

덕분에 지난 9.82 버전부터 도입됐던 “프로그램 호환성” 보정의 필요가 훨씬 줄어들었으며 보정 내역이 단순해졌다.
이제 2021년 현재 실질적으로 보정이 필요한 부분은 (1) 크로뮴 기반 브라우저(크롬/Edge)에서 한글 입력 중에 조합이 강제 종료되었을 때, 그리고 (2) MS Word에서 한자 후보 변환 기능이 취소되었을 때, (3) Windows Terminal 문제 정도밖에 없다(‘학교’를 입력할 때 ‘ㅎ학ㄱ교’로 덧남).

(1)과 (2)는 한글 입력하고는 직접적인 관계가 없는 동작이어서 심각성이 훨씬 덜하다. 그나마 좀 크리티컬한 건 (3)밖에 없는데.. 내가 아는 프로그램 중에서 저렇게 유별나게 동작하는 프로그램은 오로지 쟤가 유일하다.

심지어 마소 한글 IME조차도 Windows Terminal에서는 내부적으로 살짝 다르게 맞춰 보정해서 동작하는 것까지도 확인했다. 하지만 도대체 무엇을 근거로 왜 그렇게 동작하는지는 도저히 알아내지 못했다. 그래서 얘는 문제에 대한 완벽한 해결책이 발견될 때까지는 지금 같은 인위적인 수동 보정의 영역에다 불가피하게 남겨 뒀다.

그래도 사소한 보정 말고 중대한 보정이 인위로 필요한 프로그램은 이제 사실상 딱 하나 Windows Terminal밖에 남지 않았다. 상황이 예전보다 많이 좋아진 셈이다.
날개셋 한글 입력기는 이제 MS Word의 겹침 모드(2007 이상)와도 그럭저럭 잘 호응하여 동작하며, IE 기반의 키보드 보안 ActiveX가 쓰이는 일부 사용자 인증 페이지에서도 제대로 동작하지 않던 문제도 덩달아 같이 해결되었다. 전부 단일 로직으로 말이다. 야호~!

2. 제어판 외부 모듈 목록 기능의 강화

사용자가 실제로 볼 일은 드물겠지만.. 제어판의 시스템 계층에서 제공되는 ‘외부 모듈’ 목록에 “상태에 이상이 있는 입력기”를 별도의 카테고리(그룹)에다 표시하는 기능을 추가했다.
지금까지 이미 존재하던 “활성화되지 않은 입력기”란 당장 win+space를 누르거나 입력 도구모음줄을 클릭했을 때 목록에 나타나지 않을 뿐, 컴퓨터에 설치는 돼 있는 입력기이다. 제어판/설정에 들어가서 얘들이 목록에 나타나도록 추가만 해 주면 된다.

그 반면, 상태 이상이란 운영체제에 IME로 등록은 돼 있지만 프로그램의 경로가 존재하지 않는 것(정보 없음), 혹은 그 경로에 지정된 파일이 존재하지 않는 것(파일 없음)을 일컫는다. 파일만 없어서 입력기의 아이콘을 얻을 수 없으면 텅 빈 윈도우 아이콘이 나타나지만, 정보 자체가 존재하지 않는 입력기에 대해서는 ( ! ) 모양의  아이콘이 표시된다.

대부분의 경우 상태 이상은 그 입력기의 설치나 제거가 제대로 되지 않았음을 의미한다. 아니면 64비트 운영체제에서 32비트만 지원하는 IME가 이렇게 표시된다. 설치나 제거가 완전히 끝나지 않은 상태라면 재부팅/재로그인을 하고, 입력기의 비트수를 제대로 확인해서 프로그램을 재설치하면 이 문제를 해결할 수 있다.

개인적으로 의미 있는 작업이었다. 이런 것도 진작에 구분해서 표시해 주면 더 좋았을 걸~ 위의 상태 이상 스크린샷은 일부러 파일을 지우고 32/64비트 중 한쪽의 등록을 날리는 등의 연출을 해서 얻은 것이다. 그리고...

외부 모듈의 세부 기술 정보를 보여주는 대화상자에서..
선택한 입력기와 class ID 내지 구동 파일이 동일한 입력기가 있으면.. 요렇게 목록에 같이 한꺼번에 표시하게 했다.

이게 흔한 경우는 아니지만 TSF라는 체계에서는 한 입력기, 프로그램 파일, class ID는 서로 완전히 별개로 일대일 대응하는 개념이 아니다. 한 프로그램이 여러 입력기를 등록할 수 있고, 여러 입력기가 동일한 class ID를 공유할 수도 있다.
이것도 아주 간단한 작업에 비해 운영체제에 설치된 입력기들의 관계를 파악하는 데 도움이 될 것이다.

※ 알림: 최신 운영체제에서 TSF 지원 임시 확장 기능의 변화

꽤 의외의 사실인데.. 요즘 운영체제에서는 날개셋 한글 입력기가 2008년, 무려 4.82 버전부터 지원해 왔던 "TSF 임시 확장" 옵션의 동작의 폭이 크게 좁아졌음을 뒤늦게 알린다.

얘는 원래 TSF를 지원하지 않던 운영체제의 (1) 표준 에디트 컨트롤, 그리고 (2) 서식을 지원하는 리치 에디트 컨트롤, (3) IE 웹브라우저 내부의 입력란에다 가상의 중간 계층을 추가하여 TSF를 지원하게 하는 기능이다. 그래서 글자가 아닌 단어 단위로 한자 변환이 가능해지고, 이미 완성된 글자도 낱자 단위로 지울 수 있게 된다. 운영체제에서 제공하는 기능을 한글 IME가 직접 요청도 해야 이 기능을 사용할 수 있다.

하지만 언제부터인지는 모르겠지만 19.. 20..급 버전의 Windows 10에서 우연히 테스트를 해 보니 (2)와 (3)은 TSF 임시 확장 기능이 없어졌다.
먼저 (3) IE는.. 최후이자 마지막 버전인 11이 TSF를 자체 지원하기 시작했기 때문에 임시 확장이란 게 의미가 없어지긴 했다. 10 이하의 구버전 또는 '호환성' 보기 모드에서만 동작을 확인할 수 있다.

하지만 지금은 IE 11 자체가 마소에서도 버리고 버전업을 중단한 레거시인데, 하물며 그 IE에서도 호환성 보기??? 정말 구닥다리 퇴물 중의 퇴물이다. 임시 확장 기능을 없앨 만도 하다.

그리고 (2) 리치 에디트 컨트롤도.. 최신 버전인 4.1 내지 5에서는 진작부터 TSF를 지원하기 시작했기 때문에 역시 임시 확장의 지원을 중단할 만도 하다. 하지만 구닥다리 버전 2 내지 3을 사용하는 프로그램도 여전히 많이 쓰이고 있으며, 최신 버전이라도 해당 응용 프로그램이 TSF를 지원하라는 플래그를 지정하지 않으면 TSF 기반으로 동작하지 않는다. 그러니 리치 에디트는 일괄 확장 옵션을 아예 없애 버리기에는 좀 아쉬움이 남는다.

하지만 리치 에디트의 TSF 임시 확장 기능은 한글을 처음 입력하기 시작했을 때 조합이 와장창 깨지고 문자가 이상하게 입력되는 버그가 있었다. 이건 끝내 고쳐지지 않은 채 기능 자체가 없어지는 것으로 논란이 종결된 듯하다. 즉, 해당 응용 프로그램 차원에서 제대로 지원하든가, 아니면 아예 지원하지 않든가 둘 중 하나인 것이다. 억지로 불완전하게 승격시키는 것을 뺐다.

그래서 2020~21년 현재, TSF 임시 확장 옵션은 오로지 메모장과 각종 대화상자의 입력란 같은 (1) 표준 에디트 컨트롤에서만 지원되고 있다. 뭐 얘만 해도 쓰이는 곳이 장난이 아니니 지원할 명분은 충분하긴 하지만.. IE는 몰라도 리치 에디트는 좀 아쉬움이 남는다.
사실 '고급 시스템 옵션' 탭 자체가 일반 사용자가 건드릴 일이 거의 없는 옵션들로만 가득하다. 이제는 그 아래의 '프로그램 호환성' 탭도 들여다볼 일이 더욱 없어질 테고 말이다.

Posted by 사무엘

올해도 벌써 한 달이 채 남지 않았다. 이 시국에 날개셋 한글 입력기가 10.0 이후로 또 다음 버전 10.1이 거의 반 년 만에 나왔다. 이제 얘도 개발 20주년을 돌파했고, 전체 소스 코드는 드디어 9만 줄을 넘었다. (직전 10.0은 9만 줄에서 700줄 정도 부족)
이번 버전은 문자 입력 쪽으로 완전히 새로운 기능이 추가된 것은 없지만 다음과 같은 몇몇 분야에서 변화가 생겼다.

• 전반적인 UI: 지난 9월 말에 근황을 전했던 바와 같이 자체 에디트 컨트롤 내부에 여백을 1픽셀 추가했다. 이것 말고도 여러 자잘한 개선점이 있었다.
  
• 편집기: 인쇄 및 미리보기 기능이 크게 개선됐으며, 파일 열기 관련 동작도 추가로 개선됐다. 지난번 글에서 이미 언급한 바 있다.

그 다음으로 변화가 생긴 곳은 주로 보조 입력 도구 쪽이다.

1.
'화면 키보드'가 다음과 같이 강화되었다.

• shift, ctrl, space, bksp 같은 잡다한 글쇠들을 모두 숨기고 문자 배열만 표시하는 옵션을 추가했다.
  
• 투명도를 지정하는 옵션을 추가했다. 흐리게 표시했더라도 마우스 포인터를 글쇠배열로 가져가면 그 동안은 잠시 짙어진다.
  
• 글쇠 버튼들이 평소에는 배경이 회색이지만 마우스 포인터가 가리키고 있을 때는 배경이 희게 바뀌게 했다.

이로써 화면 키보드는 날개셋 한글 입력기가 제공하는 입력 도구들 중에 투명도 지정이 가능한 유일한 도구가 되었다.

2.
'수식 계산 기록' 도구에서 왼쪽의 수식 리스트와 오른쪽의 세부 정보 표시란 사이에 좌우 분할 splitter를 추가했다. 얘는 폭 비율을 지금처럼 무조건 반반으로만 할 게 아니라 사용자가 customize할 수 있어야 했는데 그게 이제야 가능해졌다. 이 도구가 처음으로 추가된 9.3 이후로 무려 2년 반 만의 일이다.

이 splitter라는 건 이 입력 도구 하나에만 필요한 기능은 아니므로 날개셋 한글 입력기가 기본 제공하는 UI 컨트롤 중 하나로 추가되었다.

3.
그 외에도 보조 입력 도구를 제공하는 GUI 엔진 자체에 다음과 같이 기능이 추가되거나 동작이 개선되었다.

• 이제 리스트박스에서 마우스 휠을 누르면 자동 스크롤까지 가능하다. (문자표, 부수 한자 입력 등)
  
• 리스트박스의 테두리 색깔이 약간 더 진해졌다. 운영체제의 실제 컨트롤의 테두리 색깔과 일치시켰다. Windows XP~7 시절에는 차이가 없었지만 10은 지금까지 미세한 차이가 존재했다. (아래 움짤에서 미묘한 차이를 참고할 것)

기존 입력 도구에 적용된 건 없지만, 버튼도 누르고 있는 순간만 이벤트를 보내는 것, 누른 채로 다른 버튼으로 포커스가 이동하는 것(현재 스마트폰 글자판들의 UI) 같은 옵션과 동작을 추가했다. 그리고 split 버튼도 추가했다.

4.
타자연습은 기능이 추가되거나 바뀐 것이 전혀 없고 10.0 시절에 비해 ABI 호환이 깨진 것도 전혀 없지만.. 불가피하게 새 버전이 나오게 됐다. 날개셋 에디트 컨트롤 내부에 1픽셀씩 여백이 추가된 것, 그리고 125% 배율에서도 24픽셀 비트맵 글꼴이 사용되는 것에 맞춰.. 타자연습 역시 내부 컨트롤의 배치가 어긋나게 된 것을 보정해야 하기 때문이다. 아래 짤방을 참고하시기 바란다.

바로 직전 버전만 해도 바뀐 것이 멀티 모니터 관련 아주 자잘한 패치밖에 없는데 이번에도 아주 자잘한 사항 때문에 업데이트를 하게 됐다. 버전을 올리지는 않고 잠수함 패치만 한 채 프로그램을 다시 올렸다.

5.
편집기에서 삽입/겹침 모드, 그리고 겹침의 경우 낱자/글자 단위 설정은 날개셋 제어판에서 조절하여 저장도 되는 설정에서 제외되었다.
이제 날개셋 편집기는 언제나 삽입 모드에서 실행되며, 낱자/글자 단위는 언제나 글자 단위로 맞춰진다. 그리고 삽입/겹침뿐만 아니라 낱자/글자도 모든 입력 항목에게 동일하게 적용된다.
이건 날개셋 1.0 첫 버전부터 변함없는 형태이던 것이 더 현실에 맞게 바뀌었다.

6.
날개셋 한글 입력기는 내장하고 있는 변환기 유틸리티를 통해 운영체제의 키보드 드라이버(kbd*.dll) 파일도 글쇠배열 내지 입력 설정으로 가져올 수 있다. 다만, 64비트 에디션에서는 64비트 dll만 읽을 수 있고,  32비트 에디션에서는 32비트용 dll만 읽을 수 있다.

64비트 Windows는 키보드 드라이버도 64비트용과 32비트용이 따로 있는데.. 여기서 쓰이는 32비트용 dll, 일명 WOW64용 dll은 순수 32비트 Windows에서 쓰이는 dll과는 구조가 달라서 날개셋 변환기의 32비트 에디션에서도 읽을 수 없었다. 즉, WOW64는 32비트와 64비트 두 에디션에서도 모두 버림받은 것이다.

그러다가 이번 버전에서는 10년 넘게 이어졌던 이 관행에 변화를 줬다. 32비트 에디션에서는 WOW64용 dll도 읽을 수 있게 했다. 물론 요즘 PC에서는 64비트 dll만 쓰면 되니 이게 그렇게 큰 의미를 지닌 변화는 아닐 것이다.

Posted by 사무엘

한글을 입력할 때 ㄷ, ㅂ, ㅈ 같은 자음을 연타해서 각각 ㄸ, ㅃ, ㅉ을 만드는 건 명백하게 초성 문맥에서 행해지는 일이다. ㄸㅃㅉ은 종성에 쓰이지 않기 때문이다(현대 한글 기준). 그리고 ㄲ과 ㅆ은 비록 종성에서도 쓰이긴 하지만 얘도 가능한 한 초성 문맥에서 처리하는 게 동작의 일관성 차원에서 더 좋다.

이들과는 반대로 ㄱ+ㅅ으로 ㄳ, ㄹ+ㅁ으로 ㄻ 등을 입력하는 건 종성 문맥이다.
세벌식은 초성 글쇠와 종성 글쇠가 물리적으로 서로 다르기 때문에 초성의 결합이 가능한 상황과 종성의 결합이 가능한 상황이 아주 명확하게 구분된다. 하지만 두벌식은 어떻게 구현하느냐에 따라 초성과 종성을 뭉뚱그린 자음의 결합 가능 여부가 달라진다.

세벌식 구현하듯이 두벌식을 구현한 프로그램(아래아한글, macOS, 날개셋 기본 설정)이라면 초성 입력 문맥에서는 ㄸㅃㅉ의 결합만 가능하다. 그리고 두벌식 기반 옛한글 입력 환경이라면 역시 무조건 이런 식으로 동작하게 된다.

한편, 마소 한글 IME는 초성 쌍자음의 연타 결합을 지원하지 않고 ㄳㄶㄻ 같은 겹받침을 단독으로 입력할 수 있다. 초성까지도 언제나 종성 문맥에서만 동작하기 때문이다. 이 개념은 날개셋 한글 입력기도 오래 전 6.X 후반 버전에서 두벌식 종성이라는 개념으로 뒤늦게 수용한 바 있다.

그런데 문제는.. 초성의 결합과 종성의 결합을 모두 지원하는 프로그램도 있다는 것이다.
초성과 종성의 구분이 없는 두벌식에서 ㅂ+ㅂ는 ㅃ, ㅂ+ㅅ는 ㅄ가 되면서 그 상태로 ㅏ를 누르면 각각 ‘빠’와 ‘ㅂ사’(ㅄㅏ가 아님!)가 된다.
내가 아는 프로그램으로는 새나루, 그리고 먼 옛날(2003년..)에 남북 합작으로 개발됐던 Unicode CJK IME도 이 범주에 든다.

이 동작을 날개셋으로 구현하는 건 가능할까?
결론부터 말하자면 가능은 하다.
하지만 이건 날개셋 한글 입력기의 내부 구조라는 관점에서 보면 초성 문맥이 갑자기 종성으로 널뛰기 하듯이 바뀌는 굉장히 예외적이고 변칙적인 동작이다. 그래서 평소에 잘 쓰이지 않는 설정을 많이 바꿔 줘야 한다. 이 글에서는 날개셋에서 “ㅃ빠”와 “ㅄㅂ사”의 입력이 모두 가능한 두벌식 입력 설정을 만드는 걸 실습해 보겠다.

먼저, “기본 글자판 설정” 빠른설정을 이용해서 종성 지향이 아닌 일반적인 두벌식 입력 설정을 세팅한다. 자음 처리 방식을 “성분별로 따로”로 지정하고, 쌍자음의 연타 입력은 “모두 허용”을 지정하도록 한다.

그 다음으로 우리가 할 일은 (1) 초성 문맥에서 ㄴ 다음에 ㅈ, ㅂ 다음에 ㅅ 따위가 입력됐을 때 조합 중인 글자를 초성이 아닌 종성으로 한꺼번에 바꾸는 것이다. 이건 글쇠배열 수식이 담당해야 한다. ㅅ의 경우, 수식은..

T<=1 ? D==1 ? H2|_GS|0xFFFA : D==36 ? H2|_RS|0xFFFA : D==86 ? H2|_BS|0xFFFA : H2|S_ : H2|_S

으로 가장 복잡하다. 원래 ㅅ만 초성 또는 종성 형태로 곱게 입력하는 T<=1 ? H2|S_ : H2|_S 라는 수식에서 초성 문맥에 대해

T<=1 ? {블라블라블라 ? XXXXX :} H2|S_ : H2|_S

이라는 항이 길게 추가된 것이다. ㅅ을 입력하는 자리에서는 ㄳ, ㄽ, ㅄ을 담당해야 해서 수식이 가장 길다.
입력된 글쇠의 초중종성 값은 A~C에 들어있고 현재 조합 중인 글자의 초중종성 값은 D~F에 들어있다. D의 값 1은 ㄱ을 나타내고 36은 ㄹ, 86은 ㅂ을 의미한다.

그때의 리턴값은 H2|_GS|0xFFFA 이런 꼴인데.. H2는 이 글자가 다음에 중성이 이어졌을 때 도깨비불 현상을 일으키고 초성 문맥으로 넘어가는 두벌식 한글임을 뜻한다. 그리고 밑줄로 시작하는 GS, RS, BS 같은 명칭은 종성을 뜻한다.
0xFFFA는.. 해당 성분, 여기서는 초성을 무조건 0으로 바꿔서 없애는 특수 낱자이다. 그래서 초성 ㄱ 다음에 이런 부류의 수식이 입력되면 종성 ㄳ으로 바뀔 수 있다.

이런 식의 변형을 ㄱ(ㄺ), ㅎ(ㄶㅀ), ㅁ(ㄻ), ㅂ(ㄼ), ㅈ(ㄵ), ㅌㅍ(ㄾㄿ)에 모두 해 줘야 한다. 가령, ㅈ 자리는 다음과 같다.

T<=1 ? D==12 ? H2|_NJ|0xFFFA : H2|J_ : H2|_J

이렇게 해 주면 날개셋에서도 초성 ㄴ 다음에 ㅈ을 입력했을 때 글자가 갑자기 종성 ㄵ으로 바뀌는 걸 볼 수 있다.
하지만 이 상태로 중성을 입력해도 ‘ㄴ자’가 되지는 않으며 중성이 지금 조합 중인 글자에 접수된다.

이걸 보정하려면 먼저 (2) 오토마타를 수정해 줘야 한다.
초성을 없애는 0xFFFA도 오토마타의 관점에서는 nonzero, nontrivial인 초성이다. 그렇기 때문에 초성 첫 타가 입력된 뒤인 1번 상태의 수식 A ? 1 : B ? 2 : C ? 3 : 0을..
A&&A<=255 ? 1 : B ? 2 : C ? 3 : 0

정도로 수정해 줘야 한다. 그래야 초성 입력만으로 ㄳㄵㄻ 등이 입력됐을 때, 오토마타의 상태가 종성인 3번으로 바뀌며 다음 중성이 현재 글자가 아닌 다음 글자로 가게 된다.

그리고 마지막으로.. (3) 특수 도깨비불 규칙을 수정해야 한다. (제어판의 ‘낱자 처리’ 탭)
이렇게 초성에서 종성으로 인위적으로 강제로 바뀐 겹받침은 한글 입력기의 관점에서는 입력 과정에서의 개연성이 파악되어 있지 않다. 즉, ㄳ을 ㄱ+ㅅ으로 분할해야 한다는 것을 알지 못하기 때문에 도깨비불 현상이 발생하더라도 ㄳ을 통째로 뒷글자 초성으로 보내 버린다. 이는 올바른 결과가 아니다.

그렇기 때문에 현대 한글 겹받침에 대한 규칙이 등록되어 있어야 하는데.. 이건 내정값을 살펴보면 ‘현대 겹받침’이라고 ㄳ부터 ㅄ까지 11개가 이미 등록된 게 있다. 그걸 불러오면 된다. 겹받침을 원래대로 종성 문맥에서만 입력한다면 기재할 필요가 없는데 초성 문맥에서의 입력 때문에 필요해진 것일 뿐이다.

이런 작업을 해 주면 날개셋에서도 두벌식의 초기 상태에서 초성 ㄲ와 종성 ㄳ을 동시에 처리할 수 있다.
왠지 좀 비효율적이고 삽질스러워 보이지만.. 날개셋의 현 체계에서는 이보다 더 깔끔하게 동일 동작을 구현할 방법은 존재하지 않는다. 초성이 갑자기 그렇게 종성으로 널뛰기로 바뀌어야 할 논리적인 근거가 없기 때문이다.

한글 입력기 중에는 두벌식과 세벌식, 그리고 현대 한글과 옛한글의 입력 로직이 프로그램 코드 차원에서 완전히 분리되어 있는 편이다. 마소 IME는 그럴 거라고 추정되며, 오픈소스인 libhangul도 그러하다. 그래서 초성에서의 종성 겹받침 결합이 두벌식 현대 한글을 위한 별도의 로직으로 구현돼 있다.

하지만 날개셋의 경우 두벌식이건 세벌식이건 모두 범용적인 동일 로직으로 처리되고, 초중종 성분별로 낱자 결합 규칙이 존재할 뿐이다. 그렇기 때문에 초성을 종성으로 갑자기 바꾸는 건 선뜻 수용 가능한 동작이 아니다.
뭐, 굳이 넣자면 초성만을 위해 0xFFF? 같은 특수한 의미를 갖는 코드값을 추가할 수는 있다. 하지만 내 프로그램에 그런 걸 넣지는 않을 것이고 그냥 이렇게 우회해서 동일 동작을 구현 '가능'하다는 것만으로 놔둘 생각이다.

이런 두벌식에 비해 세벌식은 도깨비불 현상 없고 한글의 모아쓰기 구조와 직관적으로 대응하기 때문에 입력 방식으로서 처리하기가 얼마나 편한지를 알 수 있다.
물론 초성과 종성에 같은 자음을 사용한다는 점 때문에 두벌식 사고방식이 편한 것도 있다. 하지만 현실에서는 초중종성을 한데 모은다는 특성을 살리는 게 더 편리하다.

Posted by 사무엘

날개셋 한글 입력기가 10.0 이후로 10.2 버전 정도가 올해 연말 완성을 목표로 개발 중이다.

1. 자잘한 UI 개선

(1) 날개셋 에디트 컨트롤의 내부 가장자리에 좌우상하로 1픽셀씩 여백을 추가했다. 그래서 텍스트가 좌측 상단에 너무 답답하게 딱 붙은 게 아니라 약간이나마 더 여유로워 보이게 했다. (왼쪽: before, 오른쪽 after)

운영체제의 에디트 컨트롤은 진작부터 여백이 적용되어 있다. 그렇기 때문에 내 컨트롤에다가도 여백을 넣고 싶다는 생각을 아주 오래 전부터 하고는 있었다.
하지만 이런 여백이 있으면 좌표 계산과 스크롤/클리핑 등 내부 처리가 꽤 복잡해지기 때문에 지금까지 이를 반영하지 못했었다.

(2) 지금까지는 운영체제의 화면 확대 배율이 정확하게 150% (144 dpi) 이상일 때만 24픽셀 글꼴이 쓰였는데, 그보다 낮은 125% (120 dpi)일 때도 시스템 글꼴이 '맑은 고딕'처럼 자체 높이가 충분히 있을 때는 24픽셀 글꼴이 쓰이도록 로직을 수정했다.
이미 경험적으로 보셨겠지만 125%이더라도 대화상자는 에디트 컨트롤이 24픽셀 글꼴이 들어가고도 남을 정도로 커져 있으며, 16픽셀 글꼴은 보기에 너무 작게 느껴진다.

(3) 그리고.. 날개셋 1.0 이래로 20년째 좀 엉성한 모양이던 상하 스핀 컨트롤의 모양을 이제야 왼쪽의 에디트 컨트롤과 제대로 융합된 형태로 바로잡았다..;; 이걸 내가 왜 지금까지 그냥 놔 두고 있었나 모르겠다.
편집기의 화면 설정과 쪽 설정 대화상자, 줄 번호 찾아가기, 날개셋 제어판의 입력 항목 순서 같은 UI에서 스핀 컨트롤을 확인할 수 있다. (위: before, 아래: after)

(4) 편집 화면 설정 대화상자에서 사용자 정의 색상 4가지를 지정한 것과는 별개로, 색깔 선택 대화상자에다가 사용자 색상(최대 16개)을 지정한 것이 다음에 색깔 대화상자를 열 때에도 계속 보관되고 유지되게 했다. 다만, 이 색상은 이 프로그램 인스턴스가 살아 있는 동안에만 보관된다. (레지스트리에는 콤보 목록에 나타나는 배경-글자색 pair 4쌍의 값만 저장)

지금까지 별로 티가 나지는 않았겠지만 custom 색상이 제대로 저장되지 않았을 뿐만 아니라 미세한 메모리 범위 초과 오류까지 굉장히 오랫동안 존재했는데.. 그걸 이제야 발견해서 고쳤다.

2. 수식 관련

(1) 상수의 범위 초과 감지
날개셋 한글 입력기의 수식 처리기는 부호 있는 64비트 정수를 기반으로 동작한다. 그러니 2^63 - 1에 해당하는 9223372036854775807까지만이 인식되고, 1 더 큰 …5808은 부호 여부와 관계없이 음수로만 인식된다. 마치 0은 부호와 관계없이 동일한 0인 것처럼 말이다.
그리고 …5809 이상부터는 수식 파싱 차원에서 constant too big 에러로 처리되고 접수가 거부되게 했다. 16진수 상수도 마찬가지이다.

이제 11111111111111111111 같은 수를 입력하면 숫자가 제멋대로 짤리고 엉뚱하게 접수되는 게 아니라 처음부터 접수가 거부된다. 날개셋 한글 입력기가 거의 완결 단계에 들어서니 이런 정말 사소한 부분까지 완성도를 신경 쓸 여력이 생긴 듯하다.
물론, 이런 상수 자체 말고 계산 과정에서 발생하는 overflow나 underflow는(예: 곱셈 내지 bit shift) 여전히 프로그램이 감지해 주지 않는다.

(2) 계산기 필터 숫자 음수 부호 인식
수식은 글쇠나 오토마타처럼 날개셋 한글 입력기의 엔진 내부뿐만 아니라 사용자의 편의 기능으로도 쓰인다. 특히 입력된 텍스트의 내부에 있는 숫자나 수식을 일괄 계산해 주는 “계산기”라는 텍스트 필터가 오래 전부터 추가돼 있었다.

얘는 계산 대상을 인식할 단위로 텍스트 전체, 각각의 줄 전체, 중괄호나 따옴표로 둘러싸인 부분 등을 지정할 수 있다. 그리고 그냥 단독으로 등장한 숫자들을 모두 개별적인 계산 단위로 인식하게 할 수도 있다. 이렇게 하면 “2 3 5 7” 이런 숫자 리스트에 대해 일괄적으로 5를 더한다거나 2을 곱한다거나 하는 변형을 가할 수 있다.

그런데 이런 “개별 숫자 인식” 옵션이 지금까지 숫자 앞의 부호를 같이 인식하지 않는다는 점을 뒤늦게 발견하여 개선했다.

3. 문자 표현 방식 단일화 필터

지난 1~2년 남짓한 시간 동안 날개셋 한글 입력기는 보조 입력 도구에만 기능이 잔뜩 추가되었고 텍스트 필터 쪽은 거의 변화가 없었는데.. 이번에 또 자그마한 변화가 생겼다.

“한자 표현 방식 단일화”라고 텍스트 중의 호환용 한자를 표준 영역 한자로 변환해 주는 필터가 있는데.. 이건 무려 2011년, 6.3 버전부터 존재했던 기능이다.
이게 “문자 표현 방식 단일화”라고 더 범용적인 명칭으로 바뀌고, 변환 기능이 3종류가 더 추가됐다.

컴퓨터에는 기술적· 역사적인 우여곡절로 인해 동일한 문자를 표현하는 방식이 둘 이상 존재하는 경우가 많다. 특히 그 문자가 여러 부분문자들이 합쳐져서 구성되는 합자라면 더욱 그러하다. 특이한 액센트 부호가 붙은 알파벳 변형 문자가 대표적인 예이고, 한글도 낱자라는 부분문자들이 합쳐지는 형태이기 때문에 이런 범주에 든다.

합쳐진 전체 문자를 단독으로 취급하여 코드값을 부여하느냐, 아니면 부분문자들만 등록하고 이것들을 한데 묶어서 표현하느냐의 문제인데.. 이게 서로 장단점이 있기 때문에 딱 부러지게 정해진 답이 없다. 과거에 컴퓨터가 성능이 부족하고 소프트웨어의 국제화와 글꼴 출력 기술이 발달하지 못했던 시절에는 문자를 최대한 전자처럼 취급해야 했지만 오늘날은 후자 지향적인 처리도 얼마든지 가능해져 있다.

하지만 중요한 것은 정보 교환을 위해서는 동일한 문자는 합자 지향이든 부분문자 지향이든 한 방식으로만 표현되어 있어야 한다는 것이다. 동일한 문자가 일관된 방식으로 표현되어 있지 않으면 사람이 같다고 인식하는 문자가 컴퓨터에서는 같다고 인식되지 않고 검색이나 비교, 심지어 보안 같은 데서 큰 혼란이 생긴다.

한자는 글자의 생성 원리와 조합 가능성이 너무 판타스틱(..)하기 때문에 애초부터 분해를 포기하고 몽땅 무식하게 완성형으로 처리되고 있다. 그러니 합자냐 부분글자냐 하는 원론적인 문제를 겪지는 않고 있지만.. 한중일 국가별로 여러 지저분하고 구린 사정으로 인해 동일한 글자가 둘 이상의 코드값에 중복 배당되어 있다. 한국의 경우 독음 바리에이션 때문에 그렇다. (부/불, 악/낙/락 따위)

호환용 한자를 표준 영역의 대표 한자로 모두 바꾸는 것은 동일 문자를 동일한 코드값으로만 표현되게 하는 단일화, 정규화 작업 중의 하나이다. 이와 같은 맥락으로, 합자 지향 또는 부분문자 지향으로 변환하는 기능(각각 NFC 정규화, NFD 정규화)을 자체 구현이 아니라 운영체제 API 호출을 통해 수행하는 옵션을 여기에다 추가했다.

그러니 이 기능은 기존의 “한글 형태 정규화” 필터가 하는 일도 같이 하는 셈이다. 한글뿐만 아니라 유럽의 액센트 문자들도 같이 다루니 기능이 더 많다.
하지만 날개셋 한글 입력기는 한글을 전문으로 취급하는 프로그램이므로 한글의 형태만 바꿔 주는 전용 필터는 여전히 별도로 남아 있을 것이다. 더구나 얘는 자체 구현이다.

(1) 호환용 한자 제거, (2) NFC, (3) NFD 이렇게 세 가지는 설명이 됐고, 마지막 남은 변환은 (4) ‘리가처’ 문자를 부분문자로 분해해 주는 기능이다. æ를 실제 알파벳 ae로 바꾸는 식이다.
유니코드에는 도대체 무슨 용도인지는 모르겠지만 Nj, Lj 같은 글자가 한데 뭉친 리가처가 있으며, U+FB0?대에도 fi, ffl 같은 글자가 합쳐진 리가처가 있다. 리가처는 분해하는 기능만 있고, 일반 알파벳으로부터 다시 합성해 주는 기능은 없다.

4. 편집기: 파일 열기 관련

(1) 날개셋 편집기는 파일을 원형 그대로 제대로 열지 못해서 이대로 다시 저장하면 파일의 원형이 손실될 우려가 있을 때, 이를 에러 메시지로 표시해 준다. 원형 그대로 열지 못하는 조건으로 현재 문자 인코딩이 잘못 지정된 것, 줄 바꿈 문자가 일관성 없게 지정된 것 두 가지가 존재하는데 이 뿐만 아니라 null 문자가 존재하는 것도 추가되었다. null 문자 이후 부분은 인코딩과 무관하게 아예 잘리기 때문이다.

물론 null 문자는 텍스트 파일에는 존재할 이유가 전혀 없는 문자이며, 이게 존재한다는 것은 날개셋 편집기에다가 실행 파일처럼 편집 대상이 아닌 파일을 잘못 지정했기 때문일 가능성이 높다.

(2) 파일 메뉴 끄트머리에 있는 최근 사용 파일 목록에서 현재 접근 가능하지 않은 파일은 뒤에 (?)가 붙어 표시되게 했다. 단, 경로가 하드디스크에 있어서 존재 여부를 빠르게 확인 가능한 파일만으로 한정이다. 네트워크/USB 메모리/광학 디스크 따위는 포함되지 않는다.

(3) 최근 사용 파일을 열었는데 그 파일이 현재 존재하지 않는 경우, 그냥 파일이 없다는 에러만 표시하는 게 아니라 이 경로가 지정된 빈 문서를 새로 생성할 것인지를 묻게 했다. 일부 텍스트 에디터들이 행하는 관행을 날개셋 편집기도 따르기 시작했다.
다만, 파일 이름만 없을 때로 한정이다. 드라이브나 디렉터리 자체가 존재하지 않는 경우에는 여전히 예전과 같은 에러 메시지가 표시된다.

5. 편집기: 인쇄

날개셋 편집기에 인쇄 기능은 잉여에 가깝긴 하지만... 다음과 같은 작업이 행해졌다. 용지의 가로/세로 배치와 텍스트의 가로쓰기/세로쓰기 배치를 자유롭게 할 수 있게 했다.

• 텍스트를 다단(!!) 형태로 배치하는 기능을 추가했다. 너무 많이는 아니고 최대 4단까지 가능하게 했다. 그리고 용지 크기와 글자 크기, 단 간격을 감안해서 한 단의 폭이 전각 12자보다 작아지지는 않는 한도 내에서만 단을 나눌 수 있다.
  
• 용지의 인쇄 방향(세로 portrait, 가로 landscape) 같은 설정이 인쇄 대화상자를 닫은 뒤에도 저장되고 미리보기 같은 것에 반영되게 했다.
  
• 세로쓰기일 때는 화면 인쇄의 양쪽 보기 기능도 좌-우가 아니라 우-좌로 페이지를 표시하며, 다음 페이지로 스크롤도 오른쪽이 아닌 왼쪽 화살표로 되게 했다! 이렇게 고칠 생각을 지금까지 왜 못 했나 모르겠다.
  
• 페이지의 마지막 줄은 굳이 줄 간격까지 고려할 필요 없이 글자가 들어갈 공간만 있으면 인쇄되어 표시되게 했다.
  
• 머리글과 바닥글은 굴림 대신 맑은 고딕으로 출력되게 했다. (정확히는 현재 대화상자 GUI용 글꼴)

그 밖에,

• 확대 배율을 급격히 축소하고 나서(500%에서 150% 같은) 마우스 드래그로 스크롤을 할 때 화면 잔상이 남음
• 미리보기 때는 이상이 없는데 실제로 인쇄를 하면 머리글과 바닥글이 가끔 엉뚱한 각도로 기울어져 출력됨 (always는 아니고 컴퓨터에 따라 케바케로 발생하는 듯..;; )
  
• 약간의 resource leak

요런 버그도 고쳤다~!

위의 인쇄 미리보기 스크린샷은 이번 버전에서 바뀐 사항들을 모두 보여준다. (다단, 세로쓰기에서 2페이지 우-좌 배치)

*. 희망 사항: ARM64 지원

마소에서는 잘 아시다시피 Windows Phone/Mobile 같은 모바일 제품군은 안드로이드와 iOS 대비 승산이 전혀 없다고 판단되어 그냥 접고 포기를 선언한 바 있다. 하지만 그 대신, 요 몇 년 전에는 데스크톱용 Windows 10을 그대로 모바일 CPU인 ARM64용으로 포팅하는 굉장히 참신한 시도를 했다. Visual C++ 2017/2019를 통해 ARM64용 컴파일러와 라이브러리도 무료로 제공하면서 이 플랫폼을 적극 지원하는 중이다.

그래서 Windows 10 on ARM의 사용자로부터 날개셋 한글 입력기도 ARM64 에디션이 좀 나왔으면 한다는 요청이 있었다. 반디집은 진작에 ARM64용이 나왔으며, 본인은 저런 플랫폼이 있다는 것 자체를 반디집을 통해서 들었다.

얘는 x64 이후로 거의 15년 만에 접하는 새로운 아키텍처이다. 과연 ARM64가 x86 계열로 천하통일이 돼 있는 데스크톱 시장에도 잘 안착할 수 있을까? 만약 그게 성공한다면 데스크톱과 모바일의 경계가 한층 모호해지는 계기가 되겠지만.. 성공 여부는 성능과 가격 같은 기술적인 요인보다는 그냥 마케팅과 호환성, 사용자들의 경로의존성 관성 같은 social한 요인에 더 크게 좌우될 것 같다.

쟤도 ARM64뿐만 아니라 32비트 기반의 레거시 ARM이 있긴 하다. 하지만 Windows 10 운영체제 자체는 처음부터 64비트로 개발됐으니, x86 환경에서처럼 프로그램을 번거롭게 32비트와 64비트를 지저분하게 다 고려하지 않아도 될 것으로 보인다.
보아하니 ARM64는 x86 코드를 에뮬레이션으로 실행하는 기능이 있지만 물론 속도가 느린 건 감수해야 한다. 그리고 x64는 지원하지 않는다.

ARM64라는 새로운 환경이 어떨지 기대되긴 하지만.. 날개셋 한글 입력기를 여기에 맞게 빌드해서 테스트 해 보려면 나도 기기가 필요하다.;; -_-
직장을 포함해 주변에서 Windows 10 on ARM 기기를 한 번도 구경을 못 해 있다.

Posted by 사무엘

오랜만에 날개셋 한글 입력기와 타자연습의 새 버전이 나왔다.
한글 입력기의 32비트 배포 패키지가 드디어 날개셋 타자연습보다도 덩치가 더 커졌다.
타자연습이야 게임의 리소스와 MFC 라이브러리의 오버헤드 때문에 큰 편이었는데 입력기는 정말 순수하게 내가 작성한 코드와 내가 준비한 데이터만으로 덩치가 이렇게 커졌다.

날개셋 한글 입력기라는 걸 만들어 온 게 고3과 대학 시절 이래로 어언 20년이 됐다. 내 인생의 20대, 30대 나이와 함께했다.
한글 입력기뿐만 아니라 한글 글꼴도 새로운 걸 만들고 싶은 게 있는데 입력기만 너무 오래 끌었다. 그래도 덕분에 옛날에 도저히 상상하지 못했던 방향으로 입력기를 더 발전시키기도 했다. 10.0을 찍고 나니까 이제는 너무 터무니없이 거창한 것 말고는 프로그램을 만들 만치 충분히 다 만들었다는 생각이 든다.

1. 조합 안에 조합 생성 입력 도구에 문자열 자동 완성

지난번 개발 근황글에서 짤막하게 언급한 바와 같이, 이번 10.0 버전에서는 '조합 안에 조합 생성' 입력 도구에 후보 문자열의 뒷부분 자동 완성 기능이 추가되었다. 이 입력 도구가 수행하는 기능이 무엇인지를 감안한다면 진작에 들어갔어야 할 기능인데 다소 늦은 감이 있다. (이 입력 도구가 처음 도입된 건 2년 전의 9.3부터!!)

자동 완성 단축키는 tab/shift+tab 계열, 또는 ctrl+space 이렇게 두 종류이다. Windows와 유닉스 계열의 명령 프롬프트에서 경로/파일을 자동 완성해 주는 tab 키, 그리고 Visual Studio 개발툴에서 명칭을 자동 완성해 주는 ctrl+space 이들의 동작에서 모티브를 따서 다음과 같은 형태로 동작이 구현되었다.

후보 목록에 다음과 같은 문자열이 있고, 사용자가 a 또는 aa까지 입력했다고 치자.

aabbccccc
aabbdd
aabbddee

이 상태에서 ctrl+space를 누르면 후보 목록들의 공통 접두사인 aabb까지가 자동 완성된다. 이런 공통 접두사가 없는 상태에서 또 ctrl+space가 들어오면 그냥 맨 앞 또는 선택막대가 가 있는 문자열이 자동 완성된다.
물론 aabb 상태에서 d를 수동으로 입력한 뒤 ctrl+space를 누르면 dd와 ddee가 순서대로 완성된다. 즉, ctrl+space의 관점은 순차적인 진행, 전진이다.

그 반면, aa까지 친 상태에서 tab을 누르면 곧바로 맨 앞 항목인 aabbccccc가 자동 완성된다. 또 tab을 누르면 aabbdd, aabbddee의 순으로 순환하게 된다. shift+tab은 역순으로 순환한다.
tab/shift+tab의 결과로 인해 입력 중인 문자열이 달라지고 후보 목록의 내용이 달라질 수 있다. 그 상태에서 ctrl+space를 눌러서 추가적인 전진을 할 수도 있다.

그리고 후보 목록은 알파벳 순서뿐만 아니라 타자 길이가 짧은 것도 우선시해서 출력되는 반면, 이 tab 순환은 전전으로 사전 순으로만 진행된다.

사실, 날개셋 한글 입력기에서 기본으로 제공하는 영단어나 한자 새김 입력 정도만으로는 자동 완성 기능이 그렇게 막 유용하게 느껴지지는 않을 수도 있다. 자동 완성을 하느니 후보 목록에 n순위로 뜬 항목을 번호로 곧장 선택하는 게 더 빠르기 때문이다. 그래도 이 입력 도구에서도 명령 프롬프트(터미널)나 개발툴 에디터 같은 정도의 최소한의 편의 기능은 있어야겠다는 논리적 당위성 때문에 이 기능이 구현되었다.

참고로 자동 완성은 '새김으로 한자' 또는 '영단어' 입력일 때만 가능하다. '한글 단어를 한자로' 변환은 유일하게 자동 완성 기능이 전혀 지원되지 않는다. 입력한 한글보다 더 긴 길이의 한자어를 제시하는 동작이 없는 관계로, 자동 완성이라는 걸 제공할 여지가 없기 때문이다.

2. 한자 관련: 한글 독음 표시

UI에서 한자의 훈과 음을 표시할 때, 호환용 한자(독음의 바리에이션)에 대해서는 원래 한자의 음이 같이 병기되게 했다. '요'뿐만 아니라 '이, 인, 여, 노, 난, 열' 같은 글자에 대해서도 재미있는 결과를 볼 수 있다. 한국어의 두음법칙이 생각보다 까다롭다는 걸 느끼게 될 것이다.

그러므로 외국 사이트 같은 데서 한자를 입력할 때는... 이 글자보다는 가능한 한 {}로 둘러싸여 있는 음에서 동일 모양의 글자를 찾아 입력하는 것이 권장된다. 호환용 한자는 마치 UTF-8 텍스트의 BOM만큼이나 장기적으로는 사용이 권장되지 않는 deprecated 요소이기 때문이다.

물론 현실적으로는 이미 잔뜩 구축된 호환용 한자들과 기존 한글 IME들의 동작을 무시할 수 없을 것이고, 컴퓨터 소프트웨어들이 호환용 한자들을 알아서 정규화해서 처리해야 할 것이다.
먼 옛날 KS X 1001 상용 한자에서 서로 다른 독음에 대해서 똑같은 한자를 중복 배당한 것부터가 편법이고 원죄이긴 하지만... 그 시절에는 그렇게라도 해서 한자에 담긴 독음 정보를 보존해야 할 필요 또한 있었다.

그런데 金의 경우 도대체 왜 '성 김'이 본가이고 '쇠 금'이 호환용 한자로 연결되었는지, 不도 왜 '부'가 본가이고 '불'이 호환용인지는 나로서는 알 길이 없다. 날개셋은 별다른 이유 없이 그냥 마소의 데이터를 따르고 있을 뿐이다. 따지고 보면 '가'에 대해서 家부터 먼저 시작하는 마소 특유의 한자 빈도수 데이터부터가 출처가 무척 궁금해진다.

3. 부수로 한자 입력

(1) '부수로 한자 입력' 도구가 "한중일 통합 한자 확장 B, C, D"에 있는 U+20000 ~ U+2B81D 사이의 약 47000자에 달하는 한자들의 부수까지 추가로 조회해서 입력할 수 있게 했다. 단, 우클릭 메뉴에서 옵션을 선택해야 한다.

독음으로 한자를 입력하는 건 기본적으로 4888 상용 한자만 가능하고, 편집기 계층에 있는 '확장 한자 옵션'을 선택하면 BMP 영역 것까지 모두 가능해진다.
그 반면, 부수로 한자 입력은 기본적으로 BMP 영역이 가능하고, 별도의 옵션을 선택하면 확장 평면 것까지 사용 가능해진다.

날개셋 한글 입력기에서 확장 평면 한자는 짙은 초록색으로 표시된다. 지금까지는 이 색깔을 볼 일이 거의 없었지만 앞으로 "부수로 한자 입력 도구"에서 이 색깔을 적극적으로 볼 수 있을 것이다. 용 룡(龍) 자가 4개 붙은 그 극악의 64획짜리 한자(U+2A6A5)도 드디어 입력할 수 있다.

물론 확장 평면 한자들은 날개셋 한글 입력기 엔진이 공식 지원하는 한자는 아니다. 그렇기 때문에 이 한자들은 훈과 음 정보가 전혀 제공되지 않는다.
내가 보아하니 저 많은 확장 평면 한자들은 출처가 대체로 옛 문헌들인 것 같다. 기괴한 모양의 글자들이 많이 눈에 띄지만, 그렇다고 간체자 스타일의 획이 그려진 글자는 딱히 보이지 않기 때문이다.

내가 듣기로 CJK 확장 한자가 벌써 E, F, G에까지 도달했다고 하는데 도대체 아직까지 추가할 게 무엇이 있는지 궁금하다..;; 그래도 처음으로 확장 평면이란 걸 개척하면서 무려 4만 자가 넘게 한꺼번에 추가됐던 확장 B가 존재감이 압도적이다. C와 그 이후 영역들은 B보다는 규모가 훨씬 작으며, 수백~수천 자씩만 추가되고 있으니 말이다.

한중일 통합 한자 확장 E, F, G 따위도 데이터가 공개돼 있으니 지원할 수는 있다. 하지만 이들 영역은 당장 Windows 10에서도 글꼴이 기본 제공되지 않아서 글자가 제대로 표시되지 않으니, 내 프로그램에서도 지원할 필요를 아직 느끼지 않는다. 날개셋 한글 입력기는 한글 입력이 전문이지 굳이 이런 '부가적인 기능'을 운영체제보다 더 앞서 지원할 필요는 없을 것이다.

다만, 나중에 데이터 파일만 업데이트 하면 프로그램 코드를 수정하지 않아도 D 이후의 확장 영역을 추가로 지원할 수 있게 준비는 시켜 놓았다. 지원하는 확장 한자의 전체 개수를 하드코딩해 놓지 않고 파일로부터 값을 런타임으로 얻는 변수 형태로 처리했다는 뜻이다.

말이 나왔으니 말인데, 이모지 문자표도 이번 기회에 데이터 파일을 수정하면 동물, 자연, 음식, 활동 같은 카테고리까지 확장 가능하게 구조를 수정했다. 이모지도 마치 한자처럼 새로운 게 계속 추가되고 있는 영역이니 말이다.
이모지 문자표 내지 입력기를 제대로 만들려면.. 얼굴 이모지에서 피부색 바리에이션을 선택하는 UI도 들어가야 한다. 하지만 그건 현재 그냥 생략하고 있다.

(2) 확장 한자 지원 얘기가 좀 길어졌다만, 깨알 같은 변화가 하나 더 있다.
현재 얘는 부수를 클릭했을 때 보다시피 근처의 총획수가 동일한 부수들이 빨간색으로 표시되는 기능이 진작부터 존재했다. 그런데 현재 선택된 부수와 동일한 부수 소속인 글자들은 획수와 무관하게 하늘색으로 더 먼저 구분되어 표시되게 했다. 예를 들어 己를 선택했다면 巳와 已, 田을 선택했다면 由, 申, 甲, 그리고 4획의 王을 선택했다면 5획의 玉도 같이 말이다.

(왼쪽에 하늘색으로 흩어져서 표시된 그물 망 제부수자들을 볼 것)
적용해 보니 굉장히 편리하다. 이런 동작을 왜 지금까지 생각을 못 하고 있었나 모르겠다. 간체자까지 생각하면 획수가 다른 동일 부수 바리에이션이 더 많이 존재한다.
이 기회에 오리지널 제부수자보다 획수가 적은 제부수자들의 획수가 잘못 기재되어 있던 것들도 바로잡았다. 15년~20년 전 유니코드 DB에는 데이터가 잘못돼 있었던 것 같다.

그나저나 같은 한자의 획수 세는 방식도 절대 고정불변이 아니라 한국 중국이 서로 차이가 있다는 걸 알 수 있었다. 특히 1획으로 볼지 2획으로 볼지 굉장히 모호한 획 말이다.
중국이 대체로 획수를 더 적게 세는 쪽으로 바뀐 것 같다. 다시 말하지만 간체자로 형태가 완전히 바뀐 것 말고 동일한 한자가 말이다.

4. 허용 한글 범위 제약 기능 관련

(1) '현대 한글만 허용'이라는 간단한 기능이 추가됐다. 현대 한글 자모는 미완성 한글 형태라도 입력을 허용하지만, 초중종 중 어디라도 옛한글이 포함된 채로 두 성분 이상 결합하는 것은 허용하지 않는다. 옛한글 낱자는 단독으로만 입력과 결합을 허용한다. 언뜻 보기에 간단하지만 기존 오토마타나 다른 제약 기능을 이용해서 쉽게 구현 가능하지 않다고 여겨져서 이것만 직통으로 수행하는 기능을 추가했다.

(2) '지정된 파일에 들어있는 한글' 기능에 지금처럼 데이터를 파일 경로로 지정하는 외장형뿐만 아니라, 데이터 자체를 직접 갖고 있는 내장형으로도 동작하는 옵션을 추가했다. 그래서 이름도 '지정된 파일' 대신 더 범용적인 '지정된 데이터'로 바꿨다.
입력을 허용하는 한글의 수가 수십~수백 자 수준으로 아주 적거나 "현대한글 + 아주 소규모의 옛한글" 이런 식이어서 데이터가 작다면.. 번거롭게 외부 파일을 준비할 필요 없이 내장형이 더 나은 선택이 될 것이다.

5. 편집기의 색상 구성표

편집기에서 텍스트 편집창의 색상을 설정하는 UI에.. 다음과 같이 다양한 색상 구성표들이 추가되었다.

흑백, 호박색, 터미널 이렇게 어두운 그룹은 과거에 흑백 모니터를 사용하던 경험을 고스란히 재현해 줄 것이다. 날개셋 편집기는 그렇잖아도 옛날 추억의 한글 글꼴들을 한데 구경할 수 있는 프로그램인데, 색깔까지 복고풍 configuration을 제공하는 것은 나름 의미 있는 일이 될 것이다.

도스용 에디터, 칠판, 아래아한글 1.x 색상은 오래 전부터 제공되고 있었다. 외국에서는 아래아한글이 인지도가 없으니 영문 명칭은 무의미한 HWP 1.x 대신 그냥 시원한 바다색 Ocean이라고 바꿨다.

그리고 밝은 그룹인 레몬, 연보라, 베이지는 쌩 white보다 눈부심이 덜하고 편하기 때문에 역시 쓸모가 있을 것이다. 요 색깔들은 macOS의 터미널에서 제공되는 색상을 차용한 것이다.
이런 색상들을 간단히 가져와서 쓸 수 있는 것은 날개셋 편집기의 활용성에 긍정적인 기여를 할 것이다.

6. 외부 모듈에 보정 옵션 추가

바로 며칠 전에 어느 사용자께서 날개셋 한글 입력기가 Windows Terminal이라는 메트로 앱에서 조합 중인 글자가 자꾸 덧나면서(ㄱ가ㄴ나ㄷ다 같은..) 제대로 동작하지 않는다는 버그 신고를 하셨다.
이미 존재하는 보정 기능으로는 “ㄱ가나다”까지는 바로잡을 수 있지만 첫 글자가 덧나는 것은 막을 수 없었다.

엄밀히 따지자면 이 프로그램도 IME로부터의 문자 입력 접수에 제대로 대응하지 못하고 버그가 있다. 조합을 끊어서 전하든 기존 조합을 늘이고 옮겨서 전하든 겉으로 드러나는 결과는 아무 차이가 없는 게 맞는데.. 한편으로는 마소 IME는 괜찮은데 또 내 프로그램만 저러는 이유는 알 길이 없다.;;
이 때문에 프로그램과 통신하는 방식에 옵션이 하나 더 추가됐다.

예전부터 있었던 A 방식과 B 방식은 “연속 입력”에 대해서 기본 방식 또는 대체 방식을 지정하는 것이었다.
이번 10.0에서는 “최초 입력”에 대한 방식도 세분화됐다. Windows Terminal의 오동작을 해결하려면 두 입력에 대해 모두 “대체 방식”을 선택하면 된다.

7. 타자연습과 세벌식 파워업

입력기는 그야말로 0.1 이상으로 굉장히 많은 것이 바뀐 반면, 타자연습은 작년 여름에 나온 3.9 이후로 바뀐 것이 거의 없다. 입력기 10.0과 함께 타자연습도 4.0으로 같이 올라가면 참 좋았겠지만, 도저히 그럴 수 없어서 타자연습은 3.91이 됐다.

타자연습과 세벌식 파워업은 딱 한 가지... 무조건 주 모니터에서 창이 뜨는 게 아니라 자신을 실행시킨 GUI의 모니터를 기준으로 뜨도록 수정된 것이 전부이다.
지난 2017년~18년 사이엔 이들 프로그램이 고해상도 dpi를 제대로 지원하도록 수정되곤 했는데, 그 다음으로 multi-모니터를 제대로 지원하도록 수정이.. 참 굉장히 늦게=_=;; 행해졌다.

이상이다.
컴퓨터라는 기계가 있고 한글 같은 문자, 알파벳만치 마냥 단순하고 가볍지 않으면서 한자만치 무겁지도 않고 조합을 글자 단위로만 만들면 되는 단순한 문자가 있을 때.. 이런 문자의 입력을 위해 존재할 수 있는 모든 아이디어를 담을 수 있고 모든 형태로 실현 가능한 소프트웨어--이것이 지금까지 날개셋 한글 입력기의 개발 목표였다.

이제 앞으로는 날개셋 한글 입력기에 치명적인 버그 수정이나 자잘한 기능 추가 같은 유지보수 말고.. 기상천외한 기능이 새로 추가된다거나 프로그램 내부 구조가 바뀐다거나 하는 변화는 당분간 없지 싶다.
2020년대부터는 한국어/한글 정보 처리 쪽으로든, 철도 쪽으로든 내 인생이라는 연극의 다음 장, 다음 막이 진행됐으면 좋겠다.

지금까지 긴 세월 동안 날개셋 한글 입력기를 변함없이 사용하고 성원해 주신 분들께 감사드린다.
말을 이렇게 써 놓으니 내가 무슨 시한부 인생이라도 살고 있고 앞으로 날개셋 개발 다시는 안 할 것 같은 느낌도 든다만.. 이런 글 올려 놓고는 또 두어 달 뒤에 언제 그랬냐는 듯이 10.01 정도는 또 자잘한 버그 수정과 개선 명목으로 또 나올 수도 있다. ㅎㅎ

Posted by 사무엘

2020년은 2~40년 전쯤에 만들어졌던 각종 소설과 SF물에서나 다루던 까마득한 미래 시점이다. 그게 현실로 찾아왔다니 감회가 새롭다.
하지만 현실의 2020년은 코로나19라는 웬 신종 바이러스 때문에 교회 예배가 중단되고 학교 개학과 심지어 올림픽까지 연기되는 초유의 사태와 함께 시작되었다. 세상의 그 어떤 소설과 SF물도 이런 걸 예측하지는 못했을 것이다.

2020년은 날개셋 한글 입력기도 개발 20주년에 진입한 시점이다. 그리고 무려 10.0 버전이 현재 개발 중이며, 이게 9.x 시절부터 지금까지 수 년째 미뤄지고 또 미뤄졌던 파이널이다.
원래 9.5를 파이널로 삼으려고 했다. 9.5 이후로도 1년 반 동안 9.6, 9.7, 9.8x 등 새 버전이 도대체 몇 개가 더 나왔던가?? =_=;; 그러던 게 이제야 드디어 제동이 완전히 걸렸다.

이 글에서는 개발 중인 10.0에서 이미 작업이 완료된 것, 더해지고 고쳐지는 것들이 어떤 것이 있는지 잠시 소식을 전하도록 하겠다.

1. '기본 글자판 설정' 빠른설정에 no-shift 두벌식 세팅

10.0 버전에서 본인이 가장 먼저 알리고 싶은 소식은.. 날개셋 한글 입력기의 제어판에서 사용자가 가장 자주 접하게 될 UI인 '기본 글자판 설정' 빠른설정에 no-shift 두벌식을 간편하게 세팅하는 기능이 추가됐다는 것이다. 바로 여기에 말이다.

지금까지 사용자들로부터 받은 피드백을 종합해 보면.. 두벌식에서 shift 없이 쌍자음을 언제나 연타로 입력하는 것에 대한 수요가 제법 많다는 걸 알 수 있었다. 하지만 별 생각 없이 낱자 결합 규칙만 추가해 놓으면 '이끼, 바삐, 앗싸, 홀씨' 같은 단어에서 뒷글자에 등장하는 쌍자음을 연타로 입력할 수 없다. 음절 경계 모호성에 걸려서 '익기, 밥비, 았사, 홄시' 따위와 구분이 안 되기 때문이다.

이런 모호성을 해소하려면 그런 쌍자음은 어쩔 수 없이 shift를 동원해서 입력하거나.. 아니면 capslock 같은 글쇠를 눌러서 앞 글자의 조합을 수동으로 끊는 수밖에 없다. 옛한글 글쇠배열이야 모호성이 훨씬 더 많이 발생하기 때문에 대놓고 조합 중단 글쇠가 배당돼 있기도 하다.

하지만 그런 고전적인 방법 말고 타자 시간 간격을(타이머) 이용해서 음절 경계 구분을 할 수도 있다.
이건 구버전에서도 진작부터 지원돼 왔으니 기술적으로 새로운 기능은 전혀 아니다. 하지만 사용자가 일일이 설정을 하는 게 마냥 간단하고 쉽지 않다. 수요가 많은 상징적인 설정을 곧장 세팅해 주는 기능을 빠른설정에다가 도입한 것은 그 자체만으로도 버전업의 명분이 될 수 있다.

더구나 타이머를 적용하는 방식도 두 가지 중 하나를 선택할 수 있다.

• 통상적인 방법(가-까 타이머): 뒷글자가 쌍자음이면 앞글자를 다 입력한 뒤 한 박자 쉰다(이-끼 → 이끼). 쉬지 않으면 예전처럼 ‘익기’가 된다.
• 다른 방법(각-가 타이머): 위와 반대로, 쌍자음을 지연 없이 빠르게 치고, 자음이 앞뒤 글자에 분산돼 있을 때 한 박자 쉰다(익-기 → 익기). Google 단모음이 이런 방식을 사용한다.

각 방식이 어떻게 구현됐는지를 살펴보면.. 전자는 중성까지만 입력됐을 때도 타이머가 발동돼야 하며 오토마타도 상태가 두 개 더 필요하다.
후자는 오토마타 상태가 하나만 있으면 되지만 특수 도깨비불 규칙과 다단계 입력 분리(65531) 낱자 결합이 추가로 필요하다. ‘밝’까지 쳤다가 도로 ‘발ㄲ’을 만드는 것은 명백하게 더 과격한 동작이기 때문이다.

그래도 사용자의 타자 행동 관점에서 두 방식에 절대적인 우열은 없으니 그냥 자기에게 편한 방식을 골라서 쓰면 된다.
기본으로 설정되는 시간 threshold는 0.5초(500밀리초)이다. 타이머 설정에서 이 값을 더 늘리거나 줄일 수 있다.

2. “조합 안에 조합 생성” 입력 도구

얘는 여러 글자로 이뤄진 단어 같은 덩어리를 다른 형태의 문자로 변환하는 핵심 인터페이스이다. 한글 단어나 훈으로 한자 입력하기, 그리고 T9 방식으로 영단어 입력하기 기능이 제공되고 있는데..

• 변환에 쓰이지 않는 문자는 애초에 조합창에 들어가지 않고 바로 본문으로 삽입되게 인터페이스를 개선했다.
• Ctrl 내지 Shift 클릭을 좀 다르게 인식하게 했다. T9 영단어 입력의 경우 마침표 and/or 공백을 뒤에 같이 삽입하게 했고, 한글-한자 변환의 경우 지금 외부 모듈이 지원하는 것처럼 "한자(漢字)" 내지 "漢字(한자)" 형태의 삽입이 되게 했다.
• 여러 독음 후보들이 존재하는데 이들이 길이가 길고 앞부분이 상당수 일치한다면 명령 프롬프트나 개발툴 에디터에서 하는 것처럼 앞부분의 ‘자동 완성’이 되게 했다. 타이핑 수고를 상당 부분 덜 수 있을 것이다. 자동 완성 단축키는 tab 또는 Ctrl+space 중에서 선택 가능하다.

3. 편집기: 자잘한 개선

날개셋 편집기에서 파일을 읽고 쓰는 아주 기본적인 동작과 관련하여 다음과 같은 강화· 개선 작업이 이뤄졌다.

(1) 파일을 제대로 불러오지 못한 상태에서 저장을 시도하거나, 아까 전에 제대로 저장하지 못한 상태에서 창을 닫으려 하면 확인 질문을 하게 했다.
여기서 ‘제대로’ 열기나 저장을 못 한 상황이란.. 인코딩이 잘못 지정되어서 깨진 문자가 발생했고, 현재 메모리에 존재하는 문서와 파일 형태로 존재하는 문서 내용이 서로 일치하지 않는 것을 말한다. 그 상태로 저장을 하면 문서를 변경하지 않았더라도 원래 있던 정보는 소실될 것이고, 창을 닫으면 마찬가지로 깨진 문자가 원래 무엇이었는지 알 수 없게 될 것이다.

(2) 저장 옵션을 통해서 파일의 인코딩을 변경했다면 문서 내용을 대놓고 변경하지 않았더라도 창을 닫을 때 파일을 다시 저장할지 묻게 했다.

(3) 아울러, 문서창의 시스템 메뉴에 ‘파일 이름 변경’이라는 기능을 추가했다. 이걸 실행하면 ‘다른 이름으로 저장’과 비슷한 대화상자가 나타나며, 여기서 파일 이름을 새로 지정하면 문서창을 열어 놓은 상태에서 프로그램 상의 이름과 디스크 상의 이름을 그걸로 간단히 바꿀 수 있다. 탐색기에서 따로 이름을 바꾼 뒤에 다시 불러온다거나 하는 번거로운 수고를 하지 않아도 된다.

4. 외부 모듈: Chrome 브라우저에서 추가적인 보정

크롬 브라우저는 과거에 자신이 데스크톱 앱인데도 돌아가는 IME에다가는 자신이 메트로 앱이라고 잘못 알려주는 문제가 있었다. 그 버그는 얼마 안 가서 수정됐지만, 그 다음으로 또 약간 알쏭달쏭 아리까리하게 동작하는 게 있다(2020년 3월의 80 버전 기준).

마소 Edge와 Firefox는 TSF를 온전히 지원하는 브라우저이다. 그러나 IE와 Chrome은 그렇지 않다.
TSF를 지원하지 않는 프로그램에서는 앞뒤 글자를 요청한다거나 caret 이동 같은 지시를 내리면 어차피 실패한다. 내 프로그램은 실패에 대한 대비는 물론 돼 있다. 그리고 처음부터 앱을 가려가며 동작하는 게 아니라, 이런 실제 기능의 성공 여부를 토대로 동작한다.

그런데 크롬의 경우, 앱의 종류를 식별해 보면 "TSF 미지원"이라고 나오지만, 앞뒤 글자 요청이나 caret 이동 등의 지시를 내리면 마치 TSF 지원 프로그램처럼 수행되고 성공했다는 리턴값이 돌아온다. 하지만 그게 제대로 올바르게 correctly 수행되어 있지는 않다.

크롬에서 '대한민국' 같은 단어를 입력하고 단어 단위 한자 변환을 시도해 보면 마소 한글 IME는 안 되지만 날개셋은 된다. 하지만 변환을 해 봤자 '大韓民國'이 아니라 '대한민국大韓民國' 이런 식으로.. 정확하게 동작하지 않는다.
더구나 낱자 단위로 달라붙기 옵션을 사용하면서 bksp를 눌러 보면 caret이 앞 글자로 제대로 가지 않고 계속 자기 자리에서 머무른다.

여러 정황상 인접 글자의 fetch는 되지만 텍스트 selection을 변경하는 건 안 되는 것 같다.
결정적으로 크롬이 대외적으로 자신을 "TSF 미지원"이라고 보고를 하므로 날개셋 역시 크롬에 대해서 "오동작을 하느니 아예 동작을 안 하도록" 조치를 취하는 게 바람직해 보인다.

요 보정을.. "데스크톱 앱으로 인식"이라는 보정 옵션에다가 추가했다. 이 옵션이 켜져 있고 앱이 자신을 "TSF 미지원"이라고 표시한 경우, 내 프로그램은 텍스트 고급 조작 지시를 시도조차 하지 않고 방어적으로 동작하게 된다. "TSF 지원"이라는 명시적인 정보가 있을 때만 고급 조작을 하게 된다.

5. 도깨비 한글 글꼴

옛날 도스 시절의 한글 바이오스 유틸인 '한글 도깨비'의 최종 버전  5.1에서 제공되었던 고유한 둥글동글한 글꼴, 일명 '둥근도깨비'체가 날개셋 한글 입력기의 다음 버전에서 제공될 예정이다.
"둥근모, 한솔바탕, 도깨비고딕, 한메굵은본문"을 한데 섞은 듯한 인상이지만 어느 것에 딱 떨어지지 않는 변별성과 독창성이 있고, 모양이 상당히 예쁘기도 한 편이다.

내부 구조를 살펴보니 얘는 놀랍게도 일종의 완조형이었다.
'가'부터 '히'까지 받침이 없는 글자는 완성형으로 각각의 글자들이 일일이 그려져 있고, 받침이 붙었을 때의 '가'~'히'도 마찬가지이다. 그 뒤 받침은 ㅗㅛㅜㅠㅡ용 아니면 나머지.. 이렇게 두 벌만 있다. 이런 형태의 글꼴은 난생 처음 봤다.

이 글자들로부터 초성과 중성을 일일이 decompose한 뒤, 뭔가 반복· 규칙과 패턴을 찾아내어 3차원 조합 테이블을 복원하고 날개셋 편집기에서 읽을 수 있는 11172자 조합형 한글 글꼴로 얼추 재구성했다. 어렵지만 흥미진진한 작업이었다.

ㅏㅑㅓㅕ 같은 모음은 거의 판에 박은 듯이 똑같지만, ㅘㅙ 같은 복합 중성 및 이와 결합한 초성들은 자형이 의외로 제각각 임의로 그려져 있었다. 그래서 규칙을 찾기 어려웠다.
요런 모양의 글꼴을 이런 복잡한 완조형 말고 8*4*4벌로 간소화(?)된 형태로도 옛날에 봤던 것 같기도 한데 정확하게 기억은 안 난다.

도깨비 말고도 1990년대까지 도스 시절에 텍스트 모드에서 쓰였던 유명한 한글 바이오스 유틸로는 태백한글, 한메한글이 있다. 태백과 한메는 제품 이름 겸 개발사의 이름이기도 하지만, 도깨비의 경우 개발사가 '한도 컴퓨터'여서 제품명과 일치하지 않는다.

한글 도깨비의 개발자인 최 철룡 씨는 정말 대단한 분이었다. 1980년대에 IBM 호환 PC의 내부 구조를 모두 마스터하여 한글 바이오스를 만들었을 뿐만 아니라.. 사실은 안 철수와 거의 비슷하게 브레인 바이러스 백신까지 자작했었다. 처음에는 마이크로소프트웨어 잡지의 기자로 재직하다가 나중에는 성이 안 차서 자기 회사를 차리게 된다.
날개셋 한글 입력기는 아래아한글과 마소 도스/Windows뿐만 아니라 태백, 한메, 도깨비에서 제공하던 글꼴들도 한 종류 이상씩은 courtesy 차원에서 제공하고 있다.

6. 그 밖에

• 프로그램 UI를 여러 군데 찔끔찔끔 수정했다. 기억에 남는 것으로는.. 이모지 문자표에다가도 우클릭 메뉴에 '복사'를 추가하고 전용 도움말을 넣었다.
• 지난 8.8부터 9.0대 기간 동안 심혈을 기울여서 구현했던 '복합 낱자 입력 로직 생성기' 빠른설정이 언제부턴가 제대로 동작하지 않고 적용 후에 프로그램이 뻗던 문제를 뒤늦게 발견하여 고쳤다. 직전인 9.9보다 전부터 존재했던 문제로 보인다. 처음에 구현이 잘못된 건 아니고, 나중에 소스 코드를 리팩터링을 잘못 했기 때문이다.
• 24픽셀(화면 확대 배율 150% 이상) 환경에서 날개셋 제어판을 꺼내서 ‘낱자 처리’ 탭에서 ‘낱자 코드 번호 병기’ 옵션을 켰는데.. 자그마한 낱자 번호가 초-중-종성별로 세로 위치가 차이가 나지 않고 언제나 같은 위치에 찍히던 문제를 뒤늦게 발견해서 고쳤다.
• 이 외에도 그 밖에 24픽셀 비트맵 글꼴을 표시하는 목록에서 줄 간격을 1픽셀에서 2픽셀로 늘렸으며, U+200?대에 있는 특수한 공백과 줄표에 대한 글립도 16픽셀일 때와 마찬가지로 추가했다. 또한 외부 모듈에 24픽셀용 아이콘을 추가했다. 고해상도 24픽셀 환경에 대한 지원을 여러 방면에서 강화한 셈이다.
• 외부 모듈의 ‘프로그램 호환성’ 탭에 현재 화면에 보이지 않는 몇몇 Metro 앱이 불필요하게 목록에 표시되어 있던 것을 감췄다. 그리고 ‘모두 원래대로’ 버튼의 원래 의도는 프로그램의 기본 보정 방식으로 되돌리는 것인데 그러지 않고 설정을 몽땅 삭제만 해 버리던 것을 고쳤다.
• 정말 사소한 것이지만.. 立의 한자 훈이 '설 립'(stand 서다)이 아니라 '설사 립'(??!!!)으로 잘못 등록돼 있던 것을 고쳤다. 2020년 현재 마소 한글 IME의 한자 데이터에도 동일한 오류가 있으며, 그게 날개셋에도 그대로 전해진 것 같다.

이상이다. 이 정도면 9.9에서 0.1이 더해진 10.0에 딱 어울리는 수준의 변화로 손색이 없다고 여겨진다.

대략 9.x 초기 시절에.. Windows 10의 특정 버전 내지 특정 게임에서 한글 입력이 안 될 때 내 프로그램을 쓰면 된다는 소문이 퍼졌으며, 날개셋 한글 입력기의 다운로드 트래픽이 폭증하여 내 홈페이지가 며칠 연속으로 셧다운 됐던 적이 있었다.
그래서 한동안 다운로드 링크를 내 홈페이지 서버가 아닌 Google Drive 링크로 제공했는데.. 요즘은 그런 시절도 지났는지 구글 드라이브를 안 써도 트래픽 초과가 뜨지는 않는다.

요즘은 프로그램 관련 문의를 메일로만 받고 있지만 그래도 여러 사용자에게서 문의와 버그 의심 신고 연락이 종종 오곤 한다. 정말 꿈에도 상상할 수 없던 곳에서 내 프로그램을 잘 쓰고 있다는 연락을 받은 적도 있었다. 덕분에 이번 버전도 자잘한 개선 중에는 메일을 통해 접수된 사용자 피드백이 반영된 게 무척 많았다.

내 프로그램을 사용하면서 개인 메일까지 보내서 질문이나 건의를 남겨 주는 분들이 계시니 고마운 일이 아닐 수 없다. 어서 새 버전이 완성되어서 새 기능들이 두벌식과 세벌식 사용자에게 모두 큰 도움이 되었으면 좋겠다.

Posted by 사무엘

1. 날개셋 한글 입력기 9.9

이미 확인한 분도 계시겠지만 날개셋 한글 입력기의 차기 버전인 9.9가 지난주, 지난 1월 말에 완성되고 공개되었다.

버전 9.9와 10.0 중에서 고민하던 끝에 아쉽지만 9.9를 선택했다. 비록 9.8x 이후로 많은 작업이 진행되고 많은 것이 개선되긴 했지만 외형은 지난달에 올렸던 개발 근황 이후로 크게 달라진 게 없기 때문이다. 그래서 새 버전 소식도 이렇게 소박하게(?) 전하고자 한다.
9.9라는 숫자에는 본인의 그런 아쉬운 심정이 담겨 있다. 그래도 얘는 9.x대의 마지막 버전이며, 진짜 10.0이 한 3월 말쯤으로 계획돼 있다.

(1) 9.82에서 프로그램별 수동 보정 기능이 추가됐는데, 몇몇 사용자 분들에게서 온 피드백을 들어 보면 그게 실제로 도움이 된 듯하다. 그거 설정을 바꾸는 것으로 새로운 프로그램에서의 오동작을 해결했기 때문이다. (예: Visual Studio Code 에디터)

(2) 한편, 크롬 브라우저가 버전 78에서는 자신이 데스크톱 앱인데도 IME에다가는 메트로 앱이라고 알려주는 버그가 있어서 9.82 당시에는 이를 임의로 보정하는 설정이 들어갔었다. 하지만 지금의 79에서는 그게 고쳐졌기 때문에 날개셋에서도 보정 설정이 제거되었다. 하지만 보정을 하더라도 딱히 다른 문제나 부작용은 없다.

그러므로 현재로서는 본인이 아는 한도에서는 “강제로 데스크톱 앱으로 동작” 보정이 필요한 프로그램이 없다는 것을 도움말에도 언급해 놓았다. 그냥 미래에 또 이런 일이 발생할 수 있다는 걸 염두에 두고 보정 설정을 남겨 뒀다.

공식적으로 문서화되지 않은 변화 사항으로는 남은 메모리 양을 표시할 때 내가 직접 단위 계산을 하는 게 아니라 운영체제의 깔끔한 API를 쓰게 한 것, 변환기 대화상자가 프로그램을 실행시킨 쪽의 모니터에서 표시되게 한 것, 인코딩 목록에서 UTF-7은 이제 거의 쓰이지 않으니 맨 뒤로 밀어낸 것 등.. 아주 사소한 것 위주이다.

그런 것 말고 좀 유의미한 작업이 진행된 것도 있는데, “조합과 후보 자동 완성”과 “조합 안에 조합 생성” 입력 도구에서 각종 후보 목록은 백그라운드 스레드에서 생성될 수 있게 내부 공사를 진행해 놓았다. 전자는 타이핑에 랙을 야기하지 않으면서 목록이 다 완성되면 한꺼번에 짠 표시하는 것만 담당하지만, 후자는 마치 웹 페이지 로딩하듯이 일단 자그마한 목록부터 띄운 뒤에 후보를 여기저기 incremental하게 실시간으로 추가하는 것까지 가능하다. 다만, 이것도 이를 실제로 활용하는 기능이 아직 없기 때문에 존재감이 없다.

입력기에 적용된 사소한 개선 사항이 타자연습에도 같이 반영된 것이 있긴 하지만.. 너무 사소하고 자잘한 것이기 때문에 타자연습은 아직 정식으로 버전업을 하지 않았다. 이번 9.9는 타자연습 3.9와도 API가 호환되니 그대로 같이 사용 가능하다.

새 버전을 유용히 사용하시기 바란다. 페이스북 플러그인은 고장난 지 한참 됐기 때문에 프로그램 다운로드 페이지에서도 완전히 제거했다. 그래서 본인의 이메일 주소만 기재해 놓았다.

2. 레거시 프로젝트 파일 정리

새해 기념으로.. 날개셋 한글 입력기의 소스에서 구닥다리 구버전 Visual C++용 솔루션/프로젝트 파일들을 드디어 완전히 삭제했다. 이를테면 *.vcproj (200x용), 그리고 심지어 *.dsp/*.dsw (6!!) 말이다.

사실, 소스 코드에 C++11 문법을 도입하던 순간부터 내 프로젝트들은 VC++ 2010 이전 버전과 연을 완전히 끊은 거나 마찬가지였다.
그리고 VC++ 역시 딱 2010부터 지금과 같은 솔루션/프로젝트 파일과 버전 관리 체계가 정착했고, IDE와 컴파일러 툴킷, 플랫폼 SDK 계층이 깔끔하게 분리되기도 했다. 그러니 그 이전 버전은 이제 신경 쓸 필요가 없다.

본인의 개인적인 소신은 더 쓰이지 않는 파일이어도 요즘이 하드 공간이 부족한 시대도 아니고, "굳이 일부러 찾아서 지우는 수고까지 할 필요는 없다" 주의였다. 하지만, 그것들이 보는 사람을 괜히 헷갈리게 하고 무질서도를 높이는 부작용에 대해서는 지금까지 생각을 못 하고 있었다.

이건 물건 정리와도 비슷하다. 언젠가는 다시 쓸 일이 생길지도 모르는 물건이 분명 있겠지만.. 너님의 생활 습관상 그럴 일 없으니 좀 버려야 하는 물건도 있다.
비슷한 맥락에서.. 사용되지 않는 코드도 무작정 주석이나 #if 0 처리만 해서 누더기처럼 덕지덕지 남겨 두는 게 장땡이 아니다. 재사용할 가능성이 정말 희박하고 남 보기에 정신 사납게 하는 역효과가 더 큰 것들은 그냥 완전히 지워 없애 버리는 미덕을 발휘하는 것도 필요해 보인다. 그 '정도'와 경계는 개인 취향에 달린 문제이겠지만 말이다..

아울러, 소스 코드들이 DB 데이터라면, 이들을 빌드하는 방식을 명시하는(각종 컴파일러· 링커 옵션들) 프로젝트 및 복잡한 빌드 스크립트는 DB 스키마 또는 아주 복잡한 쿼리와 비슷한 물건일 것이다. 이것도 날렸다가 다시 구성하는 건 소스 코드 자체를 날리는 것 만만찮게 골치아픈 일이 될 것이다.

3. 3D 그래픽 시연 프로그램

끝으로.. 최근에 이걸 만들어 봤다.
3D 컴퓨터그래픽을 공부하는 사람이라면 모를 수가 없는 그 유명한 '유타 주전자'를 3차원 그래픽 시연 프로그램의 예제 데이터로 추가했다. 이게 지난 10여 년 동안 제공되지 않고 있었다니.. 송구스럽기가 이루 말할 수 없을 지경이다.

이 주전자를 구성하는 3D 좌표 데이터야 이미 대외적으로 널리 공개돼 있다. 하지만 이걸 3차원 그래픽 시연 프로그램이 곧장 읽을 수 있는 무식한 직선의 나열로 변환하려면 베지어 곡선을 넘어 베지어 곡면이라는 것을 적당히 근사해서 와이어프레임 형태로 표현할 수 있어야 한다.

3차 베지어 곡선이 4개의 점(시작점 + 끝점 + 제어점 2개)으로 구성되고 t=0..1 사이의 인자를 받는 매개변수 함수로 표현된다면..
3차 베지어 곡면은 그런 베지어 곡선을 4개나 모아서 평면을 이루며, 0..1 사이의 인자 매개변수도 하나가 아니라 2차원답게 둘을 받는다.

전자가 함수값을 구하기 위해 계수와 제어점 사이의 곱셈과 덧셈을 4회 수행한다면, 후자는 그 제곱인 16회나 수행한다. 아니, 각각의 항 자체도 계수*제어점이 아니라 계수x*계수y*제어점으로 곱셈의 횟수가 더 많다. 계산량이 정말 장난이 아니더라.

이 세상의 많고 많은 글꼴들이 모두 베지어 곡선으로 표현되듯, 자동차나 비행기처럼 인간이 디자인한 기계류의 그 '유체역학적인' 부드러운 곡면도 다 이 공식을 이용해서 기술된다. 옛날에 베지어 곡선이라는 걸 고안한 사람인 '피에르 베지어'가 직업이 무엇이었는지를 생각해 보면 답이 명확해진다.

암호 같은 베지어 곡면을 인터넷을 통해 알게 된 공식대로 직선들로 쫙 풀어서 표현해 주니.. 내 프로그램에서 '유타 주전자'의 와이어프레임이 거짓말처럼 짠 나타났다. 정말 신기했다.
이런 유형의 계산은 양만 많지 패턴이 워낙 규칙적이니, 캐시 적중률 높고 병렬화에도 유리하다. GPU가 괜히 진작부터 만들어져 쓰인 게 아닐 것이다.

일반적인 3D 그래픽 렌더러라면 내 프로그램처럼 가냘픈 선이 아니라 폴리곤을 기본 단위로 취급할 것이고, 와이어프레임조차도 폴리곤을 기반으로 렌더링 방식만 변경해서 표시하는 것일 테니 삼각형 단위로 선들이 더 조밀하게 나타날 것이다. 하지만 내 프로그램은 그냥 베지어 평면의 각 격자 단위로만 선을 그었기 때문에 기본 단위가 사각형 형태로 나타난다.

정말 신기하게도.. 이 유타 주전자 데이터를 구성하는 선의 개수와,
기존 예제 중에서 원형 튜브(Torus)의 선의 개수가 서로 정확하게 일치한다. 2304개이다.
둘은 내부 구조나 데이터 생성 방식이 서로 완전히 다르고 관련이 없는데도 말이다.

Posted by 사무엘

날개셋 한글 입력기 최신 버전이 나온 지가 또 벌써 두 달이 돼 가는데.. 현재는 9.9 내지 10.0이 개발 중이다.
현재의 최신 버전인 9.82에서는 이 버전만의 고유한 버그가 발견된 것은 현재까지 없다. 그럭저럭 잘 만들어진 것 같다. 그 대신 오래된 버그가 발견된 게 여럿 있어서 개발 중 버전에서 이들을 잡는 중이다.

1. 각종 UI에 표시되는 글자들의 크기 체계화

날개셋 한글 입력기에는 한자 후보 선택 UI라든가 각종 입력 도구들처럼(화면 키보드, 문자표 등) 글자를 일반 비트맵 글꼴이나 표준 UI 폰트(굴림/맑은 고딕 9)보다 약간 더 크게 찍는 곳이 여러 군데 있다.
내가 날개셋 버전 10이 임박한 시기에 이 부분을 건드리게 될 줄은 전혀 생각을 안 하고 있었으나.. 갑자기 필이 꽃히면서 다음과 같이 대대적으로 수술을 했다.

(1) 첫째, 그런 글자들을 대 아니면 소라는 두 그룹으로 나누고, 반드시 그 둘 중 하나에 소속된 통일된 크기로 표시되게 했다.
큰 글자는 버튼이나 정사각형 셀 하나에 글자 하나가 큼직하게 표시되는 상황으로, 문자표, 부수 한자 입력, 이모지 등이 해당된다.
작은 글자는 외부 모듈이나 입력 패드의 한자 선택 UI, 그리고 '조합 자동 완성', '조합 안에 조합 생성' 입력 도구가 해당된다.

(2) 날개셋 제어판의 시스템 계층에다가 이 두 그룹의 실제 크기를 사용자 정의할 수 있게 했다.
단위는 운영체제 표준 UI 폰트의 크기(100%)에 비례하는 백분율이며, 기본값은 '대'는 200%, '소'는 134%이다. 100%보다 더 작은 값을 줄 수는 없고, 최대 500%까지 줄 수 있다.

외부 모듈의 한자 후보 선택 목록에 글자가 너무 작으니 좀 키워 달라는 요청이 지금까지 몇 건 접수된 게 있다. 겨우 그 기능만을 위한 UI를 구현하는 것은 번거로워서 반영되지 못하고 있었는데 이 큰 작업을 하면서 저것도 이제 덩달아 가능해졌다. '작은 크기'를 150%~200%대로 키우면 된다.

그 반면, '큰 크기'를 200%보다 더 키우면 화면 키보드, 한손 입력기, 12키 입력기 등 비슷한 크기의 글자를 사용하는 입력 도구들의 덩치도 한꺼번에 키울 수 있다. 단, 이미 화면에 띄워진 도구는 말고, 다음에 새로 생성되는 도구부터 말이다.

(3) 맑은 고딕은 구닥다리 바탕· 굴림 같은 글꼴과 달리 글자의 종횡비가 정확한 1:1 정사각형이 아니며, 자체적으로 줄 간격 여백이 크게 잡혀 있기도 한 글꼴이다. 그래서 바탕· 굴림을 지정하던 곳에다가 맑은 고딕을 지정하면 글자가 너무 작게 찍히는 문제가 여러 곳에서 있었다.
이번에 그 문제도 완전히 해결했다. 크기가 동일한 값으로 주면 바탕· 굴림이건 맑은 고딕이건 상대적인 크기가 비슷하게 지정되며, 단지 맑은 고딕은 줄 간격만 더 길게 벌어지게 했다.

글자 크기를 지정하는 제어판 UI는 이렇게 구현되었다.
이전에 글꼴을 선택하는 옵션이 있었으니 거기에다가 크기를 지정하는 옵션도 한 그룹으로 엮어서 같이 넣는 것이 자연스럽다.

UI를 어떤 형태로 만들지 결정하기가 어려워서 고민을 많이 했다.
시스템 계층 탭은 안 그래도 공간이 비좁아져 있는데, 글꼴이니 키보드 드라이버니 입력 도구니 하는 것들은 서로 관련이 전혀 없고 따로 노는 아이템들이다.

더구나 글꼴의 종류에 이어 크기를 지정하는 옵션이 들어갔다면 이제는 미리보기(preview) 창도 슬슬 만들어야 할 때가 됐다. 하지만 지금 저 탭에 미리보기 창을 넣을 공간 따위는 전혀 없다.
상황이 답이 없는 지경으로 흘러가니, 이제 글꼴과 관련된 옵션들은 별도의 탭으로 분리라도 해야 하나 싶었다. 하지만 그건 너무 번거로우며 들인 노력 대비 결과가 좋지는 않아 보인다.

최종적으로는 보다시피 '미리보기'라는 링크를 넣고, 사용자가 이걸 클릭하면 아래에 "입력 도구 자동 구동 목록"이 있던 영역이 글꼴 미리보기 창으로 바뀌게 했다. 미리보기 창의 디폴트 크기도 저 정도가 딱 적당하고.. 이게 여러 모로 최선의 선택인 것 같다.

2. 후보 UI에 표시되는 글자의 폰트 체계화

날개셋 한글 입력기의 모든 구현체(편집기, 외부 모듈, 입력 패드)에는 한자 변환 후보를 표시하고 선택받는 UI가 있다. 별도의 옵션이 없으면 그냥 운영체제의 기본 글꼴로 글자를 표시하지만, 특정 글꼴을 써서 표시하라고 사용자가 지정도 할 수 있다.
다음 버전에서는 이 글자의 크기뿐만 아니라 글꼴과 관련해서도 다음과 같은 변화가 생길 예정이다.

(1) 정규 후보 변환 UI뿐만 아니라 “조합과 후보 자동 완성”, “조합 안에 조합 생성” 입력 도구도 후보 목록을 출력하는 부분에서는 저 글꼴 설정이 반영되게 했다.

(2) 그리고 저 글꼴 설정과는 완전히 별개로, 코드값이 특정 영역에 드는 문자는 무조건 이 글꼴로 출력하게 하는 일명 fallback 글꼴 조건을 추가로 지정 가능하게 했다. 그 조건은 별도의 텍스트 파일로부터 읽어들인다.

2번이 아주 참신한 기능이다.
지금 사용 중인 운영체제보다 시기적으로 유니코드에 더 늦게 찔끔 추가된 문자는 그 운영체제에서 글꼴을 제대로 잡아 주지 못한다. 가령, 일본의 새로운 레이와 연호 마크(U+32FF) 같은 것 말이다. 10여 년 전에는 ‘우편번호’ 마크, 20여 년 전에는 유로화 마크도 그런 부류에 속했다.

그리고 아예 대놓고 특정 custom 글꼴을 써야만 제대로 표시되는 사용자 정의 영역 문자도 있다.
그런 것들은 글꼴 설정과는 별개로 무조건 이런 전용 글꼴을 써서 출력하라고 수동으로 고정해 놓는 게 좋을 것이다.

이건 사용자가 막 자주 사용할 만한 옵션은 아니지만, 특수한 상황에서 굉장히 유용하게 쓰일 수도 있어 보인다.
새굴림 같은 옛날 글꼴이 있다면 한양 PUA에 있던 구결을 그 글꼴을 써서 출력하라는 지시를 예제 차원에서 남겨 두었다.

3. 휴대전화 입력기

휴대전화 입력기가 제공하는 4가지 모드 중, 영문과 기호 모드에서는 한 버튼에 3개의 문자가 배당돼 있다. 그리고 이들 중 하나를 버튼을 연타해서 골라서 입력하게 돼 있다.
그런데 이 방식은 동일한 글자를 연달아 입력하거나 같은 버튼 그룹에 속한 문자를 이어서 입력하기가 불편하다. 매번 SEP 버튼을 누르는 식으로 조합을 끊어야 하기 때문이다.

이 불편을 덜기 위해 이번 버전에서는 다음 두 방법이 추가되었다. 우클릭 메뉴를 통해 편한 것을 선택하면 된다.

• 타이머: 버튼을 누르고 나서 0.5초 정도 반응이 없으면 조합이 자동으로 종료된다.
• 길게 누름: 버튼 자체를 0.5초 정도 길게 누르면 이 글자는 다음 글자로 넘어간 상태로 삽입된다.

'길게 누름'은 한글· 영문 같은 모드에서 해당 버튼에 해당하는 숫자를 입력하는 용도로도 쓰이는 편인데, 기왕 '길게 누름'을 인식하는 김에 저렇게 동작하는 옵션도 같이 추가되었다.

4. cursor가 가리키는 글자를 표시하기

날개셋 한글 입력기가 제공하는 입력 도구들 중 "문자표, 부수로 한자 입력, 이모지 문자표" 이 셋은 고정된 테이블을 기반으로 문자를 입력하는 대표적인 도구이다.
그런데 새 버전에서는 이들에게 문자를 입력하는 기능뿐만 아니라, 역으로 cursor가 가리키는 문자를 자기 문자표에서 찾아서 표시해 주는 기능도 동시에 추가될 예정이다.

각 입력 도구들은 우측 상단에 ↔ 화살표가 그려진 자그마한 버튼이 추가되었으며, 이를 누르면 cursor 뒤에 있는 글자를 찾아서 표시하게 된다. 즉, "가|" 가 아니라 "|가"일 때 '가'에 대한 정보가 나타난다. 해당 입력 도구의 테이블에 존재하지 않는 문자이면 아무 일도 일어나지 않거나 짤막한 비프음이 난다.

이 기능을 '부수로 한자 입력'에서 사용하면 낯선 한자의 부수와 획수가 무엇인지를 곧장 확인할 수 있어서 좋다. 이모지 같은 다 문자표와도 연계하면 이 문자와 관련된 주변 다른 문자들을 곧장 조회할 수 있다.
물론 이 기능은 날개셋 편집기 내지, 외부 모듈의 경우 TSF를 지원하는 프로그램에서만 사용 가능하다. 실제로 글쇠 입력을 받는 문자 생성기 말고, 입력 도구가 문자를 밖에서 보내기만 하는 게 아니라 바깥 문자를 역으로 얻어 오는 동작이 구현된 것은 이번이 처음이다.

5. 기타 자잘한 개선

(1) 날개셋 한글 입력기의 GUI 중에는 편집기의 글꼴 목록이나, 제어판 시스템 계층의 외부 모듈 목록처럼 백그라운드 스레드를 사용해서 내용을 표시하는 것이 좀 있다. 그런데 스레드의 준비 작업이 다 끝나지 않았을 때 ESC를 눌러서 해당 대화상자를 잽싸게 닫으면 응답이 몇 초 내지 무기한 멎어 버리는 문제가 있었다. 이 오랜 지병을 이번에 완전히 해결했다.

(2) TSF를 지원하지 않는 프로그램에서 구현 가능하지 않은 특수글쇠(앞 글자 조합 상태, 특정 낱자를 앞으로 보내기 따위)를 눌렀을 때 프로그램이 얼어붙는 문제도 해결했다.
사실 이 문제 자체는 5년도 더 전 7.7 버전에서 해결되었지만, 훗날 9.8에서 크롬 브라우저 버그를 해결하기 위해 새로 만들어진 보정 로직에서 동일 문제가 재발하게 되었다.

(3) 최신 아래아한글의 글쇠배열 편집기에서 저장한 ukl 파일도 날개셋 제어판에서 읽을 수 있게 내 프로그램의 변환기 로직을 수정했다.
아래아한글에 지금과 같은 형태의 글쇠배열 편집기가 도입된 건 먼 옛날 2004부터인데, 그때는 파일 포맷 시그니처가 1.0이었다. 그게 어느 샌가 2.0으로 바뀌었기 때문에 내 프로그램에서 인식되지 않았다.
하지만 확인해 보니, 시그니처만 그렇게 살짝 바뀌었지 파일 내부 구조는 바뀐 게 사실상 없었다. 그래서 안심하고 시그니처를 인식하는 부분만 수정했다.

아래아한글의 글쇠배열 편집 기능은 customize 범위가 매우 제한적인 건 그렇다 치더라도.. UI도 왜 이렇게 만들었을까 고개를 갸우뚱하게 만드는 게 좀 있다. 글쇠배열의 이름을 지정하는 게 편집 화면이나 별도 UI로 있는 게 아니라 저장 대화상자에서 하게 돼 있고..;;
Shift 윗글쇠 부분을 편집하는 것도 마우스나 메뉴를 통해 가능하지 않고 키보드 space를 눌러야 한다고 도움말을 직접 참고하지 않으면 알 수 없다. 차라리 저 shift 그림을 클릭해서 전환이 가능하다면 훨씬 더 직관적일 텐데..

(4) 그리고 날개셋 제어판의 글쇠배열, 입력 유형(ist)을 열었는데.. 자체 고유 포맷 말고 내부적으로 변환을 거치는 파일을 가져왔을 때는.. 나중에 열기 대화상자를 눌렀을 때 이전 파일의 위치가 기억되지 않는 사소한 문제가 있었다.
여러 파일을 하나씩 연달아 살펴볼 때 불편할 수 있는 문제이기 때문에 수정했다.

(5) MS Word에서 문자표 계열 입력 도구와 '조합과 후보 자동 완성' 도구로 문자 입력이 가끔 제대로 되지 않던 문제를 해결했다. 얘만 좀 특이하게 동작하는 게 있어서 그랬다.

여기에다가 입력 도구와 관련, 그리고 세벌식 동시치기 관련 기능 강화 작업까지 마무리 되면 날개셋 한글 입력기는 9.9를 넘어서 10.0에 무난히 진입할 수 있을 것으로 보인다.

Posted by 사무엘

1. 크롬 브라우저

Google 크롬 브라우저는 뭔 바람이 들어서 디자인이 갑자기 동글동글하게 바뀌었나 모르겠다. 탭과 각종 버튼들, 주소 입력란의 테두리가 말이다. 본인이 변화를 감지한 건 대략 버전 69(작년 9월쯤)부터이니 벌써 1년 남짓 됐다. 탭 모양이 저렇게 바뀌니까 크롬이 아니라 다른 브라우저를 쓰는 것 같다.

혹시 기억하는 분이 계시려나 모르겠는데, 크롬은 원래는 탭이 각진 사다리꼴 모양이었다.
Edge도 탭의 테두리가 그냥 직사각형 모양이다가 차기 베타 버전은 약간 둥글어져서 "edge"가 좀 무뎌졌다. 그에 반해 FireFox는 직사각형을 고수하고 있는 것 같다. 아무튼..

크롬은 그렇게 외형이나 HTML 파싱 및 렌더링 엔진, JavaScript 엔진이나 개선하면 될 것을.. 한중일 문자 입력을 받아들이는 IME 계층까지 지난 1년간 왜 이렇게 널뛰기 하듯이 바뀌는지 모르겠다. 나의 오랜 소감을 말하자면, 크롬은 IME 지원이 파이어폭스보다 더 열악하고 버그가 더 많으며 더 불안정하다. 현재 Firefox는 TSF도 완전히 지원하지만 크롬은 여전히 그렇지 않다.

(1) 크롬 버전 71(작년 12월 중반)쯤에는.. 주소창에서 바로 한글 검색어를 입력하기 위해서 네이버나 위키 등의 주소를 자동 완성한 뒤 바로 탭을 눌렀는데, 한글 첫 타는 조합이 끊기는 현상이 발생했던 적이 있다. 'ㅎㅏㄴ글' 이렇게 말이다.
MS, 날개셋 모두 동일하게 발생하기 때문에 외부 모듈 쪽 문제가 아니다. 단, 이건 버전 73쯤부터 해결된 듯하다.

(2) 저거보다 더 오래되고 심각한 문제로.. 크롬은 대략 2016~17년이니 굉장히 오래 전부터(50대 버전), 주소창에서 한글을 조합하는 중에('고') 마우스로 주소창 딴 곳을 클릭해서 조합을 끊으면.. 내부적으로 조합 종료가 제대로 처리되지 않아서 조합이 덧나는 버그가 있었다. 새로 cursor 위치가 바뀐 곳에서도 기존 한글 조합이 계속되었다. ('ㅏ' 대신에 '과'로..)

날개셋만 그런지 MS IME도 그런지는 기억이 안 난다만.. 오래 전부터 알려진 문제였기 때문에 내 프로그램의 도움말에다가도 이 현상을 언급해 놓았다.
고급 옵션에서 "하드웨어 가속 기능 사용"을 켰을 때만 발생하는 문제라는 것도 굉장히 괴이한 점이었다. 그래픽에서의 하드웨어 가속이랑 IME의 동작이 도대체 무슨 상관이 있단 말인가?

그랬는데 버전 74쯤에서는 다행히도 이 문제가 '사라졌다.' 역시 크롬에서 자체적으로 이 버그를 수정한 것이었다. 모든 일이 해피엔딩으로 끝나는 듯했다.

(3) 허나, 올해 상반기 크롬 75쯤부터는 상황이 최악으로 나빠졌다.
고쳐진 듯하던 '고과' 문제가 재발했으며, 한글을 입력하던 중에 비한글 문자를 입력하다 보면 프로그램이 그냥 뻗고 꺼져 버렸다. 도대체 뭘 건드렸길래.. >_<

크롬 카나리아 77의 경우, 한글을 조합하던 중에 마우스로 딴 델 찍으면 조합 상태는 초기화되지만 그 조합 문자열이 두 번 덧나곤 했다. '가가'가 되었다. 그러면서 프로그램을 쓰다 보면 뻗는 건 동일했다.
그래도 어쩌겠나. 크롬은 그야말로 세계구 급인 프로그램인데 내 입력기가 크롬의 동작에 맞춰야지.. >_<

덕분에 날개셋 한글 입력기 9.8은 크롬에서 최소한 프로그램이 뻗지는 않게 개선되었다. 그리고 사실은, 이걸 작업하면서 Firefox에서 자잘하게 오동작하던 문제, IE + 키보드 보안 ActiveX이 돌아가는 모 사이트에서 내 입력기가 뻗던 문제까지 덤으로 해결됐다. 그러니 내 프로그램도 일말의 개선의 여지가 있긴 했던 모양이다.

(4) 크롬이 같은 75.x 버전대에서 또 잠수함 패치된 뒤부터는.. '고과' 문제는 없어졌으나, 한글 조합 중에 Alt+D나 마우스 클릭 같은 행동을 하면 카나리아 77처럼 '가가'로 덧나는 문제가 발생하기 시작했다. 크롬 본버전과 크롬 카나리아의 동작이 동일해진 것이다.
날개셋 9.8은 뻗는 문제까지만 해결됐지 '가가' 문제는 여전히 갖고 있다. 이건 지난 9.81버전에서야 추가로 조치가 취해졌다.

세상에 같은 조작 요청을 했는데 굳이 저렇게 이상하게 동작하는 프로그램은 난 지금까지 크롬밖에 못 봤다. 크롬 최신 버전은 조합이 외부에 의해 종료됐을 때 그때 IME에서 조합 문자열을 딴 걸로 변경하면 정신을 못 차리는 것 같았다.

그게 지금의 78 버전에까지 이어지고 있고, 78은 바로 지난번에도 언급했듯이 갑자기 겉으로 메트로 앱인 것처럼 동작하는 것 같다. 내부는 딱히 달라지지 않았는데도 말이다. 뭐가 자꾸 많이 바뀌는 중이다.

2. MS Word에서의 겹침 모드 지원

운영체제의 GUI에서 제공하는 기본적인 텍스트 입력란(컨트롤? 위젯?)은 대개 삽입 모드만 존재한다. 그러나 본격적인 텍스트 에디터나 워드 프로세서들은 ins 키를 이용해서 겹침 모드라는 것도 같이 제공하곤 한다.

일반적인 영문 입력에서야 겹침 모드를 구현하는 건 일도 아니며, 한글 입력 정도만 돼도 반드시 1글자씩만 조합했다가 덮어써지는 것이 명확하기 때문에 일이 그리 어렵지 않다.
특히 Windows에 문자 입력 프로토콜이 재래식 IME밖에 없던 시절에는 텍스트 입력란을 제공하는 응용 프로그램이 겹침 모드를 그리 어렵지 않게 재량껏 구현할 수 있었다. IME는 확정된 형태의 문자열과 조합 형태 문자열을 알려 주기만 하지, 이걸 본문에 삽입하는 건 응용 프로그램의 재량이었기 때문이다.

물론 중국어· 일본어 IME는 임의의 길이의 문장을 조합으로 잡아서 한꺼번에 내보낼 수 있기 때문에 겹침 모드라는 게 사실상 별 의미가 없다. 그렇다면 그냥 1~2글자씩만 주고 받을 때나 한국어 IME일 때만 겹침 모드를 지원하는 식으로 프로그램이 동작하면 됐다.

그런데 TSF라는 새로운 프로토콜이 도입되면서 상황이 다소 복잡해졌다.
TSF는 cursor 위치를 옮기고 거기에 무슨 텍스트가 있는지 얻어 오고, 텍스트의 일부 구간을 블록을 잡고 거기를 새로운 내용으로 대체하는 등.. 삽입/겹침이라는 모드별로 행해지는 동작을 저수준으로 직접 기술을 할 수 있다. (비록 모든 프로그램에서 이 정도로 자유로운 조작이 가능한 건 아니지만)

그렇기 때문에 이 체계에서는 겹침 모드에 따른 동작을 응용 프로그램이 아니라 해당 외부 모듈이 달리 처리하는 게 바람직하다. 텍스트 에디터의 삽입/겹침 상태가 TSF compartment 값으로 주어지기 때문에 외부 모듈은 이 값을 참고할 수 있고 말이다. 하지만 마소에서 프로그램을 그런 식으로 개발하지는 않은 것 같다.

MS Word의 경우, 먼 옛날 97~2000까지는 내 기억이 맞다면 IME 기반으로 그냥 trivial한 방법으로 겹침 모드를 제공했었다. 한글 입력에 대해서도 겹침 모드가 없지는 않았다.
그러다가 TSF로 바뀐 XP부터는 한글에 대해 겹침 모드가 사라졌다. 2003에서는 "한글 입력에 대해서는 겹침 모드가 지원되지 않습니다"라고 에러 메시지도 나타났다.

그랬는데 2007인가 2010에서는 TSF 기반으로도 한글 겹침 모드가 잠시 구현되었다. 외부 모듈이 아닌 Word에서 자체적으로 말이다.
아마 외부 모듈이 요청하는 문자 삽입 요청을 재구성하여, 요런 패턴을 만족하는 것은 진짜 삽입이 아니라 뒷글자를 대체하는 식으로 동작하게 인위적인 보정을 했던 것 같다.

게다가 이건 특정 외부 모듈, 아니 특정 패턴을 대상으로만 불완전하게 동작했다. 똑같이 한글을 삽입하고 한글 다음에 비한글 문자를 집어넣는데, 같은 마소 IME에서만 겹침 모드가 동작하고, 날개셋이나 한컴 IME 같은 3rd-party IME에서는 동작하지 않았다.
겹침 모드로 인식되게 하는 패턴을 개인적으로는 찾아내어 파악했다. 하지만 당장 날개셋 외부 모듈의 동작을 그렇게 고칠 수는 없다. 수많은 다른 부작용에 대한 우려 때문이다.

그리고 결정적으로는..
최근에 MS Office의 기간제 구독형 에디션인 365를 설치해 봤는데.. Word에서 겹침 모드로 지정해도 이제는 마소 기본 IME도 겹침 모드가 전혀 인식되지 않고 언제나 삽입 형태로만 동작했다. 몇 번이나 확인해 봐도 그렇다. 설마 365랑 정규 에디션인 201x가 동작이 서로 다를 리는 없을 테고..

겹침 모드를 저렇게 무리수로 구현하는 건 영 아니다 싶어서 도로 뺀 것 같다. 본가인 마소에서 포기했으니 날개셋 역시 겹침 모드에 대해서는 전혀 신경 쓸 필요가 없어졌다.
이야기가 좀 찝찝하게 끝난 것 같은데.. 다시 말하지만 내 생각은 TSF 환경에서는 삽입/겹침을 각 외부 모듈이 알아서 처리하는 형태가 됐으면 좋겠다. 날개셋 한글 입력기의 엔진은 그걸 가정하고 개발되었기 때문이다. 지금 텍스트 입력 모드가 겹침 모드라는 것을 알 수 있다면 당장 그렇게 동작할 수 있다.

날개셋 외부 모듈은 처음에는 언제나 겹침 옵션이 꺼져 있고 삽입 모드로만 동작한다. 날개셋 편집기를 쓸 때처럼 ins 키가 지원되지는 않으니 날개셋 제어판을 열어서 '겹침 모드' 옵션을 수동으로 골라 줘야 한다. 그리고 이 옵션은 TSF를 지원하는 프로그램에서만 사용 가능하다.

Posted by 사무엘