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

1. 잉카 제국과 한글

작년 한글날 무렵엔 무려 페루에서 사시는 외국인이 내 프로그램으로 한글 로마자 입력 방식을 잘 사용하고 있다고 감사 겸 문의 연락을 주신 적이 있었다. 먼 옛날에 중남미에 사시는 교민에게서 연락이 온 적은 있었지만 중남미 현지인으로부터의 연락은 처음이었다.
게다가 이분은 말로만 듣던 마추 픽추 유적지 근처에 사신다고..;; 잉카 제국이 만들어지고 마추 픽추 도시가 건립된 시기가 한글이 창제된 시기와 얼추 비슷하다는 얘기를 해서 나도 놀라움에 입을 쩍 벌렸다. (다들 1440~1460년 부근.. 오옷~!)

하지만 잉카 제국은 고유 문자가 없었다. 자기네 생활 노하우와 문화, 기술이 후세에 제대로 전수되지 못하고 그대로 소실됐다.
조선은 정반대로 기록 덕후여서 온갖 것들을 미주알고주알 실록으로 남기긴 했다. 단지, 한글을 적극적으로 사용하지 않고 여전히 한문으로 기록했을 뿐..

이런 얘기를 들으면서 한글 로마자 입력 방식은 국제적으로 굉장히 인지도와 수요가 높다는 것을 실감할 수 있었다.
페루 현지에서는 마추 픽추도 그냥 흔한 학교 수학여행 코스일 뿐이랜다. 우리나라로 치면 경주처럼 말이다.
그러고 보니 페루는 나스카 지상화 불가사의가 있는 나라이기도 하네~ 신비롭다. 나는 언제 저런 곳에 가 볼 일이 있을지 모르겠다.;;

2. 유아의 한글 타자

하루는 SNS에서 육아를 하고 있는 지인의 근황을 접했다.
아들이 한글을 배워서 폰으로 카톡도 하는데.. 도깨비불 현상을 이해하지 못하고 심리적으로 부담스러워해서 각 글자들을 일일이 띄어서 친다는 얘기가 개인적으로 아주 인상적으로 다가왔다.

그렇다니까~~ 두벌식은 근본적으로 직관적이지 못하다. 이런 영· 유아에게나, 한국어를 처음 배우는 외국인에게나, 아니면 기계치 어르신들한테 말이다.

타자기이든 컴퓨터이든 불문하고 한글 입력은 세벌식을 원칙으로 하고 두벌식을 보조로 삼는 쪽으로 갔어야 했다. 아무리 기계의 성능이 향상된다고 하더라도 이런 본질적인 차이가 변하지는 않는다.

3. 위험한 곳에서 사는 동포에게서

이 얘기는 오랫동안 마음속으로만 간직하고 있다가 시간이 한~~참 지난 뒤에야 꺼내 본다. 당사자의 신변의 안전을 위해서다.
하루는 한글을 조선글이라고, (글쇠)배열을 배렬이라고, 프로그램을 프로그람이라고 부르는 사람에게서 너님이 개발한 한글 입력기를 오랫동안 잘 쓰고 있다는 연락이 메일로 왔었다. 개인적으로 굉장히 놀랐다.

(1) 그 사람은 폐쇄적인 본토에서 인터넷에 직통으로 접속한 건 물론 아니고, 외화벌이를 하러 대륙으로 파견 나가 있었다. 메일 계정은 대륙의 모 포털 사이트 기반.

(2) 유 관순이 누군지, 삼일절이 뭔지 잘 모르더라. 그냥 어디서 집단 봉기를 일으켰다가 진압된 날.
쉽게 비유하자면.. 삼일 운동의 인지도가 그로부터 10년쯤 뒤인 1929년 11월 3일 광주 학생의 날의 인지도와 비슷한 수준이다. 여러분 중에 혹시 '박 준채'라는 학생 기억하시는 분 있나요? 유 관순이 그 수준이라는 거다.

(3) 무심코 내가 툭 던졌던 "주말 잘 보냈냐/쉬었냐"라는 인사를 완전 어색해했다. 그렇게 말하는 사람이 너님이 처음이었다나.
일요일에 탱자탱자 놀거나 종교 활동 하는 건 상상도 할 수 없는 사치이고.. 이때 군인이나 공무원들이나 하는 각종 환경미화와 마을 인프라 보수에 주민들이 동원된다. 주말이란 게 없다.

그 사람이 나에 대해서 느낀 점이라며 털어놓은 말은..

• 국가관이 아주 투철하고 자기 나라를 사랑하는 분 같다. 나도 너님 앞에서 함부로 우리 공화국을 뒷담화 하지 않겠다. (ㅍㅎㅎㅎㅎㅎㅎ 내가 뭔 말을 했었길래..)
• 종교 쪽으로 독실한 게 영화에서 본 가톨릭 신부 같다. (개인적으로 복음도 전해 봤음..)

이었다. 믿거나 말거나~~~
난 그 전까지 "국가보안법"만 있지 "남북교류 협력에 관한 법률"이란 게 있는 줄 몰랐는데, 이 일을 계기로 찾아보게 됐다.
그리고 '주 성하'라는 탈북 언론인이 있다는 걸 그쪽에서 알려 줘서 알게 됐다.

내가 한글 입력기를 개발하지 않았으면 세계 사람들로부터 이런 경험 할 일이 도무지 있겠는가..;;
후원금도 여전히 용돈 수준이나마 찔끔찔끔 들어오고 있고.. 액수보다도 빈도가 더 고마운 노릇이다. 내 프로그램이 여전히 잊혀지지 않았다는 뜻이니까.

Posted by 사무엘

2021년 하반기는.. 호박에 멧돼지에, 여친으로...
내 관심사가 너무 분산되는 바람에, 정작 직장은 그리 심하게 바쁘지 않았음에도 불구하고 한글 입력기의 개발 속도는 역대 최저를 찍었다.

그래서 반 년 만에.. 한 해의 끝을 앞두고서야 날개셋 한글 입력기 다음 버전이 나왔다. 타자연습은 변화 사항이 없으며, 바이너리 호환성도 동일하다.
지난 8월 이후로 새로 추가되거나 바뀌고 개선된 사항들을 나열하면 다음과 같다.

1. Windows 11 지원

가장 먼저.. 시대가 시대이니 새 버전은 Windows 11을 정식 지원한다. 이 버전에서만 날개셋 편집기에서 발생하는 자잘한 오동작/glitch를 좀 해결했다.
그런데 11도 API를 호출해서 얻는 내부 버전 번호는 여전히 10의 연장선일 뿐이다. 그렇기 때문에 레지스트리를 뒤지는 비공식 야메 방법을 동원하지 않으면 10과 11을 구분할 방법이 없다. 마소에서 버전 관리를 왜 이렇게 지저분하게 하는지 모르겠다.

(1) 편집기: 듀얼 모니터 환경에서 프로그램 창을 최대화 시켰다가 최소화 시키고, 이걸 taskbar의 제목을 클릭해서 다시 원상복구(= 최대화) 시켰을 때.. 가끔 최대화된 창이 모니터에 꽉 차지 않고 잘못 표시되는 문제가 있어서 해결했다.
엄밀히 따지면 내 프로그램이 특이하게 동작하는 버그가 맞긴 하지만.. 기존 로직도 Windows 10까지 한 번도 문제가 된 적이 없었다.;; 이상한 노릇이다.

(2) 편집기: 문서창의 테두리가 제대로 칠해지지 않고 지저분한 잔상이 남는 문제를 해결했다.
이 역시 XP 이래로 10까지 전혀 문제가 발생하지 않던 테두리 그리기 API가 11에서만 이상하게 오동작을 일으킨 것이었다. 어쩔 수 없이 이를 회피하는 로직을 넣어야 했다.

(3) 외부 모듈: 제어판 고급 옵션에는 자신과 연결되는 키보드 드라이버를 변경하는 기능이 있는데.. 어찌된 일인지 운영체제에 설치된 키보드 드라이버 목록이 뜨지 않고 있어서 조치를 취했다. 지금까지 아무 문제가 없던 부분이 11에서만 동작이 좀 달라져 있었다.

2. 편집기: 블록 색깔 지정

텍스트와 배경의 색깔이 각각 (x, y)일 때 블록의 색깔을 (1) 시스템 색상(그 특유의 파란 바탕), (2) RGB 반전(~x, ~y), (3) 역할 반전(y, x) (4) 열은 시스템 색상 중 하나로 사용자가 customize할 수 있게 했다.
이전까지는 원래 배경이 시스템 색상(운영체제 표준)일 때는 블록 역시 ‘시스템 색상’이 강제 지정됐고, custom 색일 때는 언제나 RGB 반전이 강제 지정되곤 했다. 이를 수동 지정 가능하게 했으며, 그러면서 ‘역할 반전’도 같이 추가한 것이다.

한 방식으로 계산된 블록 색깔이 모종의 이유로 인해 원래의 배경색과 너무 비슷할 수 있다. 특히 회색 배경은 RGB 반전을 시켜도 여전히 원래 배경과 비슷해서 구분이 안 간다. 이럴 때 ‘시스템 색상’이나 ‘역할 반전’을 선택하면 도움이 될 것이다.

운영체제의 표준 에디트 컨트롤은 전통적으로 ‘시스템 색상’을 사용 중이며, 리치 에디트 컨트롤은 한동안 ‘RGB 반전’을 사용해 왔다. 한편으로 요즘은 시스템 색상을 약간 옅게 적용한 옅은 파랑이 블록 색깔로 유행이다. 이것들을 모두 선택할 수 있게 했다. 간단한 작업만으로 프로그램의 첫인상과 사용 경험이 크게 달라질 수 있게 됐다.

3. 편집기: 나머지 자잘한 UI 변화

(1) 날개셋 편집기는 1.0 시절부터 지난 20여 년 동안 상태 표시줄에 "삽입/겹침"과 "글자/낱자"라는 구획이 있었다. 두 구획을 "삽입/겹침/[겹침]"이라고 하나로 통합했다.
ins 키와 마찬가지로 이 구획을 Shift+클릭하면 낱자 겹침 모드로 진입할 수 있다. 우클릭하면 아예 메뉴가 뜬다.
지난 10.x 버전부터 삽입/겹침 모드 전환 방식이 조금씩 바뀌기 시작했는데, 드디어 편집기와 외부 모듈이 모두 키보드/마우스까지 일치하게 됐다.

(2) 텍스트에서 블록을 잡으면 아시다시피 잡힌 영역의 색깔이 반전된다. 그런데 블록이 다음 줄에까지 계속 이어지는 경우, 앞줄은 텍스트의 실제 길이보다 한 칸 더 길게 반전된다. 텍스트가 없이 빈 줄이라도 블록에 속해 있음을 알 수 있게 하기 위해서이다.
그런데 줄이 바뀌는 게 진짜로 줄 바꿈 문자가 있기 때문이 아니라 단순히 화면으로 보기에만 wrap이 돼서 바뀐 것이라면 블록 영역이 한 칸 더 추가되지 않게 했다.

(위의 그림을 보면.. "초기화할", "선택하" 다음에는 블록도 더 잡혀 있지 않은 반면, "다." 다음에는 줄이 진짜로 바뀌기 때문에 블록도 한 칸 더 길게 잡혀 있다. 참고로 "관련", "알" 다음에는 진짜로 공백이 있기 때문에 블록도 이를 반영한 것이다.)

알고 보니.. 15년도 더 전, 2.x 버전의 편집기는 원래 '한 칸 추가'가 이렇게 조건부로 동작하고 있었다. 그런데 3.x부터는 웬일인지 '무조건 한 칸 추가'되기 시작해서 현재에 이른 것이었다. 참 신기한 노릇이다.

4. 한글 로마자 입력 빠른설정의 버그

(1) 현필 방식은 글쇠배열에 ㅡ가 없음에도 불구하고 E+U로 ㅡ를 만드는 규칙이 지금까지 지정되지 않았다. 즉, 얘로는 중성 ㅡ와 ㅢ를 입력할 수 없었다. 이 문제를 개선했다.

(2) 코리언 라이터(KW)는 한글 로마자 입력법으로서는 꽤 특이하게도.. ㄲㄸㅆㅃㅉ 쌍자음들이 모두 단독 글쇠가 할당되어 있다. 단자음의 연타나 shift가 아니니 매우 수월하게 입력할 수 있다. 음절 경계 구분 같은 입력 로직을 간소화하기 위해 이런 설계를 했나 보다.
이 특성을 살려, KW 방식에서는 초성 쌍자음에 대한 연타 결합이 들어가지 않게 했다. ㄱ+ㄱ을 하지 말고 그냥 ㄲ을 바로 누르라는 뜻에서다. 단, 초성만 그렇고 종성 ㄲㅆ은 여전히 연타로도 입력 가능하다.

(3) 지난 9.5 버전에서는 공진청 방식이라는 템플릿이 추가됐는데, 얘는 shift를 쌍자음 입력 용도로 사용하는 방식이다. 그럼에도 불구하고 이 템플릿을 골랐을 때 shift 처리가 제대로 되지 않는 경우가 있는 걸 뒤늦게 발견하여 문제를 해결했다.
shift를 쌍자음 입력 용도로 사용하는 템플릿은 공진청 방식과 북한 방식 이렇게 둘이 있다.

(4) 북한 방식은 ㅒ와 ㅖ를 Shift 자리가 아니라 ㅣ+ㅐ, ㅣ+ㅔ로 입력하도록 규칙을 수정했다.
북한은 일반 국규 글쇠배열도 쌍자음은 Shift로 입력하는 반면, ㅒ와 ㅖ는 Shift 자리가 아니라 ㅑ+ㅣ, ㅕ+ㅣ 조합으로 입력하게 돼 있다. 자음은 초성 종성 구분 때문에 어쩔 수 없이 Shift를 쓰지만, 모음은 일반 현대어와 로마자 방식 모두 의도적으로 no-shift를 추구한 것 같다. 그런데 현대어는 ㅣ가 말단에 등장하는데 로마자는 y를 의식해서인지 ㅣ가 앞에 등장한다는 차이가 있다.

한글 입력 방식은 용도랄까 성향, 이념에 따라 현대어 일반, 로마자, 옛한글.. 이렇게 크게 나뉘긴 하는 것 같다.
대부분의 경우는 현대어 일반만으로 충분하겠지만, 한글 글쇠배열을 잘 모르는 외국인에게는 로마자가 유용할 것이고, 고전을 다루는 일부 계층에서는 옛한글도 필요할 것이다.

5. 복합 낱자 입력 로직 생성기

(1) 글쇠배열 정보가 업데이트되지 않는 버그
현대 한글밖에 지원하지 않는 입력 설정에다가 옛한글까지 포함된 대결합을 지정하고 로직을 생성해 보면.. 옛한글 대결합은 지금 입력 설정으로는 접근 가능하지 않아서 쓰이지 않았다는 안내문이 쭉 나타난다.

그런데 그 상태로 대화상자를 '취소'로 닫은 뒤, 글쇠배열을 옛한글 방식으로 바꾸고 나서 로직을 생성하면 이전에 발생했던 안내문이 사라지지 않고 또 나타난다.
이건 이 입력 설정으로부터 입력 가능한 낱자들 정보를 cache 형태로 저장해 둔 것이 갱신되지 않아서 발생하는 문제였다. 이 버그를 고쳤다.

(2) 오토마타 연계 방식의 개선
이 빠른설정이 세팅해 주는 기능 중에는 허용 한글 범위 제약과 관련하여 오토마타 수식을 수정하는 것이 있다. 그냥 A, B, C 변수가 모두 0인 실패 상황일 때 단순히 0을 되돌리는 게 아니라 T==xx ? -3 어쩌구 하는 조건이 추가된다.

한글 입력 오토마타를 ‘이어치기’ 같은 단순한 걸 사용하고 있을 때는 고쳐야 할 지점이 명백하기 때문에 자동 수정이 가능하다. 하지만 그것 말고 더 복잡한 custom 오토마타를 사용할 때는 저런 수정이 정확하게 되지 않을 수 있다.

그렇기 때문에 이 빠른설정은 custom 오토마타에 대해서는 수식을 직접 건드리지 않는다. “T==xx 등등 요런 조건을 현재 오토마타의 0번 상태 수식의 끝에다가 사용자가 수동으로 추가해 주세요”라고 안내만 하는 식으로 동작해 왔다.
하지만 이번 버전에서는 반쪽짜리 동작이 다음과 같이 바뀌었다. 사용자에게 귀차니즘을 유발하지 않도록 말이다.

• 오토마타의 0번 상태 수식이 A, B, C 변수를 모두 사용하고 있고 마지막이 ? : 0 으로 끝나면 그 0 부분에다가 새로운 조건이 언제나 자동으로 추가된다. 이미 T 변수를 참조하는 부분이 있다면 그 구간이 통째로 바뀐다.
• 단지, known/stock 오토마타가 아니라 custom 오토마타라면 수식이 이렇게 바뀌었으니까 맞는지 확인하라는 말만 표시해 준다.
• 0번 상태 수식이 저런 최소한의 조건을 만족하는 상태가 아니라면 오토마타를 통째로 제일 기본적인 이어치기 모드로 바꿔 버린다. 그러고 나서 새로운 조건을 추가해 준다.

사실, 허용 한글 제약이 걸려 있는데 이어치기가 아닌 다른 복잡한 custom 오토마타를 사용할 일은 거의 없다. 그러니 빠른설정 차원에서 오토마타 자동 수정을 시도해 보고, 안 되겠다 싶으면 이어치기로 강제 지정을 하는 게 더 합리적인 선택으로 보인다.

6. 수식 계산 기록

'수식 계산 기록' 도구에서 수식을 찍으면.. 이 수식의 문맥에서 쓰이는 대문자 변수의 의미가 화면 우측 하단에 같이 나타나게 했다.
날개셋 제어판에서 이 수식을 지정하는 입력란에 들어갔을 때 풍선 도움말로 표시되는 바로 그 문구이다. 그 도움말을 저 입력 도구에서도 상시 볼 수 있게 한 것이다.

저 로그에서 제일 많이 보게 될 수식은 글쇠배열, 한글 입력 오토마타, 자판 전환 세 종류를 크게 벗어나지 않겠지만.. 그래도 수식을 분석하고 변수값의 의미를 파악하는 데 큰 도움이 될 것이다.

* 알려진 문제: PowerPoint 2013(과 그 이후)에서는 입력 패드가 동작하지 않음

MS Office 제품 중에 TSF를 가장 먼저 지원한 프로그램은 아무래도 텍스트 입력에 제일 특화된 Word이었고, 그 다음으로 Outlook (Word 엔진 기반), Publisher, OneNote 같은 프로그램이 뒤를 이었다.
그랬는데 2013 버전부터는 PowerPoint도 내부의 텍스트 입력 엔진이 다시 만들어졌는지 TSF를 완벽히 지원하고 심지어 Word처럼 Ctrl+드래그로 블록을 여러 개 잡을 수도 있게 됐다.

덕분에 이제 파워포인트에서도 단어 단위 한글-한자 변환이 되고 bksp 달라붙기 같은 기능도 사용할 수 있게 됐는데..
그 대신 외부 모듈 말고 입력 패드는 동작하지 않는다는 것을 최근에야 뒤늦게 발견했다. 문자표 같은 걸 꺼내서 문자 입력을 시도해도 아무 반응이 없다.

입력 패드는 TSF보다 훨씬 더 단순한 IME 방식으로 프로그램에다가 문자 입력을 전달한다.
파워포인트는 2010년대가 돼서야 TSF 인터페이스를 구현하다 보니, 구형 IME 인터페이스를 받아들이는 부분을 과감하게 다 삭제해 버렸나 하는 생각이 든다.

입력 패드는 근본적으로 편법으로 동작하는 프로그램이다 보니 이렇게 잘 동작하지 않는 프로그램 환경이 앞으로 더 늘어날 수 있다.
문제를 해결할 방법이 없는지, 혹은 여기는 동작하지 않는 환경이라는 걸 미리 감지라도 할 수 없는지.. 이런 것들을 차차 연구해 봐야겠다.

Posted by 사무엘

날개셋 한글 입력기의 다음 버전은 올해 연말 정도 공개를 목표로 개발 중이다. 늘 그렇듯이 여러 기능들이 추가되고 자잘한 버그들이 잡혔다.

1. 복합 낱자 입력 로직 생성기에 허용 한글 데이터를 '내장형'으로 연계하기

지난 9.0 버전(4년 전~!)에 사실상 완성되어서 더 변화가 없었던 '복합 낱자 입력 로직 생성기'가 오랜만에 외형이 살짝 바뀌고 자잘한 옵션이 추가되었다. 얘가 뭘 하는 물건인지부터 먼저 복습을 좀 하자면 다음과 같다.

이 빠른설정은 2016년경 8.x 버전 시절부터 슬슬 개발과 구현의 필요성을 느껴서 2017년 초, 8.8 버전에서 드디어 첫 버전이 도입됐었다.
다음 버전인 8.9에서는 허용 한글 범위 제약 기능과 연계해서 로직을 생성하는 기능이 추가되었으며, 그 다음 9.0 버전에서 지금과 같은 세부 기능들이 모두 완성되었다.

다른 빠른설정들은 두벌식, 세벌식, 한글 로마자처럼 특정 문자 입력 방식을 새로 세팅해 주는 물건인 반면..
얘는 기본 자모만 입력 가능한 한글 입력 설정을 받아서 겹받침이나 이중모음 같은 복합 낱자들을 입력 가능한 설정을 세팅하며, 그 과정에서 발생할 수 있는 모호성이나 논리 오류를 찾아내고 바로잡아 준다.
대화상자를 네 단계나 거칠 정도로 설정할 것이 많으며 빠른설정들 중에서 덩치가 압도적으로 제일 크다.

얘는 이미 있는 입력 설정의 동작을 더욱 심화시키는 역할을 한다는 점에서 다른 빠른설정과는 성격이 근본적으로 다르다.
이건 개인적으로 날개셋 한글 입력기의 개발 내력에서 차지하는 의의가 매우 큰 중요한 기능 중 하나라고 생각한다. 현실에서는 한글 입력 엔진 하나만 갖고 이 정도로 미친 수준의 추상화나 잉여질을 생각하는 기업이나 연구소는 딱히 없기 때문이다.;;; 어쨌든 날개셋 한글 입력기에는 이런 기능이 있다.

이 빠른설정은 필요한 경우, 로직 생성 결과를 '지정된 데이터에 들어있는 한글'이라는 허용 한글 범위 제약 기능에서 인식하는 데이터의 형태로 생성해 준다.
가령, KS X 1001 2350자를 기준으로 동작한다면 '썅'은 있는데 중간 입력 과정인 '쌰'가 누락됐다는 것을 찾아내며, '쌰'가 포함된 허용 한글 데이터를 별도로 생성한다는 것이다.

'지정된 데이터에 들어있는 한글'은 별도의 파일에 저장된 데이터를 읽어들여서 동작하곤 했는데.. 지난 10.0 버전부터는 작은 데이터는 그냥 입력 설정에 포함된 내장형으로 동작할 수도 있게 됐다.
하지만 '복합 낱자 입력 로직 생성기'는 이런 변화가 반영되지 못하고 저 허용 한글 범위 제약 기능을 언제나 예전처럼 외장형으로만 운용해 왔다.

그러던 것이 이번 버전에서 드디어 개선될 예정이다. 이 빠른설정도 사용자가 옵션을 지정한다면 내장형을 적극 활용하게 된다.
기존 외장형은 큰 데이터를 부담 없이 취급할 수 있으며 한 파일을 여러 입력 항목이 공유할 때 메모리 공간이 절약된다는 것이 장점이다. 그 반면, 내장형은 덕지덕지 데이터 파일을 들고 다닐 필요가 없으니 관리가 편하다는 장점이 있다.

가장 먼저 대화상자의 외형이 미묘하게 개선되었다는 것부터 언급하도록 하겠다.
세로 길이가 예전보다 아주 약간 작아졌으며, '중간 과정 글자의 표현 방식'과 '낱자 결합 최적화' 콤보 상자의 배치가 삐딱삐딱 제멋대로이던 것을 저렇게 가지런하게 맞췄다.

그리고.. (1) '생성된 데이터가 n KB 이내로 작으면 내장시킴'이라는 옵션이 추가된 걸 볼 수 있다. UTF-16 기준이므로 한글 약 500여 자가 1KB라고 생각하면 된다. KS X 1001 2350자 테이블은 5K 이상은 돼야 내장형으로 들어갈 수 있다.
내장형을 전혀 사용하지 않으려면 숫자를 그냥 0으로 지정하면 된다.

(2) 아울러, 빠른설정을 적용하는 원본 입력 설정에 이미 '지정된 데이터에 들어있는 한글' 제약이 적용되어 있는 경우, 여기 '기본 허용 범위'에도 '현재 지정된 범위 그대로'라는 옵션이 생긴다.

얘를 지정하면 그 입력 항목에 현재 적용되어 있는 한글 데이터가 분석 대상으로 곧장 연계된다. 내장형이건 외장형이건 가리지 않고 자동으로 처리된다.

분석을 통해 새로 생성된 허용 한글 데이터가 내장형과 외장형 중 어떤 형태로 처리되었는지는 이렇게 결과 페이지에서 확인할 수 있다.

2. 화면 키보드 '실제 입력 문자 표시' 옵션의 동작 개선

'화면 키보드'에는 사용자가 누르거나 뗀 글쇠를 별도의 색깔로 알려 주는 '눌린 글쇠 표시' 옵션이 있고, 이 글쇠를 눌렀을 때 실제로 입력되는 문자를 매번 동적으로 다시 계산해서 알려 주는 '실제 입력 문자 표시' 옵션이 있다.
후자는 복벌식/신세벌식처럼 글쇠의 의미가 오토마타 상태에 따라서 달라지는 입력 방식을 사용할 때 매우 유용하다.

그런데 실제 입력 문자는 글쇠에 따라서는 capslock이나 numlock 같은 램프의 점등 여부에 따라서 달라질 수도 있다. 대소문자가 바뀌는 영문 글쇠배열이 대표적인 예이다.
하지만 이건 입력기 오토마타에 직접 들어가는 글쇠가 아니기 때문에 '실제 입력 문자 표시' 옵션만 켰을 때는 바로 바로 업데이트가 되지 않았다. '눌린 글쇠 표시' 옵션까지 같이 켜야 업데이트가 됐다.

이건 이 두 옵션이 구현된 이래로 굉장히 오랫동안 존재해 왔던 한계이다. 그러다가 이제는 '실제 입력 문자 표시' 하나만 켰더라도 키보드 램프 상태가 바뀌어서 달라지는 입력 문자도 맞게 반영되게 했다.

3. 낱자 단위 검색 기능의 버그 수정

날개셋 편집기의 찾기 기능에는 한글을 낱자 단위로 검색하는 옵션이 있다. 그런데 특정 낱자 또는 아무 낱자 말고, 낱자가 없는 것(없는 낱자) 자체를 조건으로 명시하기 위해서 내 프로그램은 초중종성별로 U+F800~F802라는 특수 낱자를 사용하고 있다.

그래서 U+F802 하나만 입력했다면 현대 한글과 옛한글을 막론하고 종성이 없는 한글을 아무거나 찾아내야 하는데.. 지금까지 그 기능이 옛한글 및 미완성 한글에 대해서는 정확하게 동작하지 못했다. 'ㅎㆍㄴ' 같은 글자도 받침이 없는 글자로 잘못 판정했다. 그 이유는.. 글자를 탐색하는 단위가 잘못 지정됐기 때문이었다.

'ㅎㆍㄴ' 자체는 받침이 없는 글자가 아니기 때문에 조건을 만족하지 않아 걸러진다.
그런데 그 다음 지점으로 이동할 때 코드포인트 3개를 이동하는 게 아니라 여느 문자를 검색할 때와 마찬가지로 2개씩만 이동했다.

그러니 다음 글자는 ㅎ만 건너뛰어서 'ㆍㄴ'이 되는데.. 이게 초성 filler가 없고 정규화 규칙을 만족하지 않기 때문에 얘는 실제로는 ㆍ와 ㄴ으로 찢어져서 인식된다.
ㆍ는 종성이 없는 단독 낱자이므로 얘 때문에 'ㅎㆍㄴ'이 통째로 걸려드는.. 뭔가 아햏햏한 결과가 연출되었다.

이게 역방향으로 검색할 때는 더 골치 아픈 문제가 되는데, 어쨌든 문제를 해결은 했다. 다음 버전에서 고쳐질 예정이다. 이 버그는 정 재민 님께서 찾아내서 알려 주셨다.
그렇잖아도 한글에 종성은 별도의 filler가 존재하지 않기 때문에 '받침이 없는 옛한글' 이런 것만 찾기가 약간 난감한데, 날개셋 편집기로는 이걸 그럭저럭 수월하게 할 수 있을 것이다.

4. 블록 잡은 상태에서의 한자 변환 지원

날개셋 한글 입력기는 단어 단위로 한글을 한자로 변환하는 동작이 MS IME와 거의 동일하게 맞춰져 있다.
한자어는 무조건 한글로만 바꿔 버리지, 한글을 거치지 않고 다른 한자어로 바꾸는 기능 정도만이 미구현이다. 이건 뭐 그렇게 크게 이질적이거나 불편한 사항이 아닐 것이다.

내 프로그램이 오랫동안 지원하지 않았던 건 블록을 잡은 상태에서의 한자 변환이었다. 이 상태에서는 무조건 단어의 맨 앞까지 한글을 탐색하는 게 아니라 블록으로 잡힌 영역만 탐색해서 한자나 한글로 변환하면 된다.
하지만 내 프로그램은 텍스트에 블록이 잡혀 있을 때는 한자/한글 변환 기능이 어떤 형태로든 전혀 동작하지 않았다. 그런 상황에 대한 고려가 되어 있지 않았으며 고려할 필요성도 느끼지 못했다.

한글 입력기가 내부적으로 사용하는 텍스트 입출력 프로토콜 자체가 애초에 블록의 존재 가능성에 대한 고려가 전혀 없었다. 날개셋 한글 입력기가 이런 기본적인 동작에 대해 이토록 오랫동안 out of 안중이었다는 게 스스로 생각해 봐도 믿어지지 않을 지경이었다. 뭔가 발상의 전환 같은 걸 경험해서 블록 안 텍스트에 대한 한자/한글 변환 동작을 추가 구현했다.

* 그 밖에

(1) 한글 낱자 하나를 입력받는 자체 콤보박스에.. 내 프로그램에서만 PUA 영역을 사용해서 표현하는 비표준 낱자를 나타나지 않게 하는 옵션을 추가했다.
검색할 때 '없음'을 나타내는 용도로 사용하는 특수 낱자라든가, 원래 초성과 종성 중 한쪽에만 존재하는 낱자의 맞은편 성분 버전 같은 것이 이 범주에 속한다. (초성 ㄱㄴ, 종성 ㄱㄷ 따위)

(2) 편집기의 영문 UI에서 용지 여백이 Margine이라고 잘못 적혀 있던 것-_-, 기본 글자판 빠른설정에서 두벌식 옛한글의 글쇠배열 미리보기에 shift+J(채움 문자)와 shift+M(음절 분리) 자리가 잘못 표시되어 있던 사소한 오류도 뒤늦게 발견해서 고쳤다.

(3) 날개셋 한글 입력기의 제어판에는 글쇠배열 편집기가 있고 한글 낱자 선택 전용 콤보박스가 있다. 글자를 한 칸에 달랑 한 글자밖에 입력받지 않는 자그마한 물건이어서 존재감이 별로 없지만.. 그래도 이들 컨트롤에서도 자체 에디트 컨트롤과 완전히 같은 방식으로 날개셋 자체 입력 엔진 또는 외부 모듈(운영체제 IME, 빈 입력 스키마)을 통해 문자를 입력할 수 있다.
그런데 이들 컨트롤에서 운영체제 IME를 통한 문자 입력이 오랫동안 제대로 되지 않고 있던 것을 뒤늦게 확인하여 고쳤다.

(4) 편집기에서 단어 단위 한자 변환 대화상자를 꺼냈을 때, 변환 영역이 블록으로 지정되었다면 그 영역이 블록 색깔로 표시되어 시각적으로 변별이 되게 했다.

(5) 편집기의 찾기 대화상자에 '한글 방점 무시' 옵션을 추가했다.
방점 없이 한글만 입력해도 방점이 덕지덕지 섞인 텍스트를 검색할 수 있으니 아주 편리하다. 이런 기능을 지금까지 왜 생각하지 못했나 모르겠다.
'공백 무시', '한글 낱자 단위로', '음이 같은 한자도 검색' 같은 옵션과 함께 사용하면 검색 기능이 더욱 강력해질 것이다.

Posted by 사무엘

날개셋 한글 입력기 10.2 이후로 약 3개월 만에 다음 버전인 10.21을 공개하고자 한다. 그리고 타자연습도 오랜만에 버전업을 해서 3.93이 나왔다. 하지만 둘 다 0.01밖에 증가하지 못했다.

개인적으로는 한글 입력기는 (1) 보조 입력 도구(화면 키보드, 문자표 등)들을 구동하는 엔진 개선, 그리고 (2) 세벌식 동시치기 기능 강화.. 이 둘을 10.x 중반에서 마무리 짓고 나서 내부적인 자체 기능 개발은 이제 진짜 끝을 내려 한다. 이것 말고 ARM64 지원이나 크롬 브라우저 이슈(미래에 또 발생한다면) 같은 건 외부 이슈들이다.

이번 버전은 지난번 개발 근황 글에서 언급했던 것처럼 크롬 브라우저 보정 내역 업데이트, 보정 UI의 보강, 여러 UI 개선과 버그 수정이 있었다. 그때 이후로 추가로 발생한 변화 내역은 다음과 같다.

1. 설치 UI에서 간략한 입력 설정 초기화 기능 제공

프로그램을 설치할 때 다음과 같은 선택 단계를 추가했다.

물론 이것들은 설치를 마친 뒤에 날개셋 제어판을 꺼내서도 얼마든지 할 수 있는 작업이다.
하지만 사용자가 원한다면 프로그램을 제거/재설치하면서 입력 설정도 같이 싹 리셋 가능하게 했다.

그리고 한글 로마자 입력 방식은 사용자가 원한다면 특별히 이렇게 바로 지정 가능하다. 제어판을 꺼내서 로마자 입력기 빠른설정을 번거롭게 불러올 필요조차 없다. 안 그래도 내 프로그램은 아직 영문 도움말도 없는데(UI만..) 외국인이 Windows 환경에서 한글 로마자 입력 방식을 더 간편하게 쓸 수 있게 했다.

2. 한글 출력 치환 관련

한글 출력 치환은 문자 생성기를 ‘고급’으로 지정했을 때 사용 가능한 기능으로, 내부적으로는 한글 입력 상태이지만 겉으로 비한글 문자가 섞여서 표시되는 처리를 담당한다.
여기서 비한글 문자라는 건 한글 자모를 여러 자로 풀어서 표현하는 것도 포함된다. 간단하게는 히라가나/가타카나 같은 일본어 문자를 한글로 입력하는 것(글자 단위 치환)부터 시작해 한글 한 글자의 범위를 넘어서는 온갖 복잡한 한글 입력 동작을 이 기능으로 구현할 수 있다.

한글 한 글자라는 경계를 기본 입력과 고급 입력으로 구분한 것은 개인적으로 오랜 연구와 고민의 결과였다. 그렇잖아도 고급 입력기는 통상적인 한글 조합과 무관한 사용자 정의 조합을 자체적으로 제공하기도 하니, 한글을 조합하고 있을 때는 이런 customization을 제공하는 것이 논리적으로 이치에 맞기도 하다.

아무튼.. 이 기능이 지금까지는 아무 낱자도 입력되지 않은 상태인 0낱자에 대해서는 치환이 지원되지 않았는데, 이번 버전에서는 이것도 가능하게 했다. 즉, 글쇠가 아직 눌러지지 않은 성분에 대해서 기본적인 치환 문자열이 미리 표시될 수 있게 한 것이다.

그리고 이 출력 치환 기능은 ‘기본’ 입력기에서 이미 제공하고 있는 가상 낱자와 같이 맞물려서 동작한다. 출력 치환이 걸리고 있는 낱자는 대부분의 경우, 자기가 원래 있던 자리에서는 0으로 치환되어서 아무것도 표시되지 않아야 한다.

그래서 제어판 UI에서 물리적인 낱자가 존재하지 않는 300, 500 같은 영역에서 문자열 치환을 지정했다면, 그 낱자 자신은 0으로 치환되도록 가상 낱자 규칙도 자동으로 추가되게 UI 동작을 개선했다.
이제 낱자 단위 출력 치환 설정을 한 뒤에, 가상 낱자에다가도 0치환을 추가하는 번거로운 두벌일을 하지 않아도 된다.

그리고 타자연습은..

• 기본 연습글에 UN 세계 인권 선언문을 추가했다. 수백 개의 언어로 번역되어 인간의 존엄성과 기본권이라는 개념을 세계 각국의 법률에다 각인시킨 역사적인 텍스트이기 때문이다. 하지만 우리말 번역이 심하게 길고 어색하고 장황한 번역투인 것은 좀 아쉽다.
  
  
• 내 프로그램은 인터넷 유행어와 개드립이 연습글로 수록되어 있는=_=;;; 게 조금씩 입소문을 타면서 주목받고 있다. "안녕히 계세요 여러분"..;; 과 "독일의 과학력은 세계 제이이이일!!"을 추가했다. 김 성모 어록, 세스코 질답 모음, 부산 운전 후기, 클레멘타인 영화 감상평, 어둠에다크에서 따위는 한참 전부터 이미 있었던 것들이고..
  
  
• 사소한 사항이지만.. 긴글 연습 입력란을 감싸는 두꺼운 테두리도 고전 기본 스타일이 아니라 다른 창들과 마찬가지로 테마가 적용된 새끈한 형태로 변경했다.

요 근래에 타자연습 프로그램이 바뀌어 온 건 멀티모니터 지원, 1픽셀 여백 반영, 그리고 테두리 모양.. 이렇게 정말 소소한 것들밖에 없는 듯하다.;; 그런데 아무 의미가 없는 건 아니기 때문에 언젠가는 반영하고 버전업을 해야 한다.

이상이다.
2021년 현재까지도 공 병우 박사의 정신을 이어받아 세벌식 자판을 사용하고 10년 이상 날개셋 브랜드 프로그램들을 애용해 주시는 분들께 감사드린다. 정말 느리고 몇 번이나 양치기 소년 같은 불발탄 선언으로 그치긴 했지만, 이 프로그램의 주된 기능 개발도 정말 끝이 보이고 있다.

한글처럼 알파벳이나 한자와는 완전히 다른 독특한 문자가 애초부터 아예 없었다면 모를까, 기왕 있다면 그 한글의 구조적인 장점을 잘 활용하기 위해서 세벌식 자판을 사용해야 한다는 것은 결코 변하지 않을 것이다.

인터넷 검색을 하다가 우연히.. 윤디자인에서도 한글 IME를 만들었다는 걸 알게 됐다. 오.. 2019년이면 한컴에서 IME를 만든 때와도 얼추 비슷해 보이는데?
내가 대학교 말년, 날개셋 버전 3.x 시절에 TSF라는 규격을 만지면서 낑낑거리고 나서 한 13~15년쯤 뒤에야 다른 싸제 TSF 기반의 한글 IME도 조금씩 만들어져 나오기 시작했다. 작년에는 잘 알다시피 ‘나빌’이라는 입력기도 나왔고..

유튜브에다가 새마을호 Looking for you 동영상을 올리던 시절에만 해도 이런 마이너한 곳에 한국어 댓글이 달릴 일이라고는 없을 것 같았는데 지금은 댓글 천지가 됐듯이..
중국? 일본이 아니라 한국에서 TSF 쪽 API를 파는 사람은 전국에서 나밖에 없을 줄 알았는데 그래도 이런 IME도 개발되어 나온다니 일면 반갑다.

IME들 간에 평범한 기능들은 결국 다 비슷비슷하게 제공되고 격차가 없어져서 상향평준화 수렴진화할 것이다.
하지만 타 IME들이 결국은 이미 있는 글자판이나 옵션들 몇 가지만 지원하는 반면, 날개셋 한글 입력기는 세벌식에 특화돼 있고 입력 동작의 모든 면모를 프로그래머 수준으로 customize 가능하다는 점에서 다른 제품들과는 근본적인 차별화 요소를 지니고 있을 것이다.;;

Posted by 사무엘

날개셋 한글 입력기의 다음 버전은 6월 언젠가 정도로 계획하고 있다.
획기적인 새 기능까지는 아니지만 지금까지 자잘하게 개선된 사항들, 그리고 새 버전 정식 공개 전에 미리 알릴 필요가 있는 변화 사항들을 나열하면 다음과 같다.

1. 크롬 브라우저 버그가 이제 크롬 쪽에서 해결된 듯

오~ 크롬 브라우저--요즘은 같은 엔진 기반인 Edge도 포함해서--가 어째 정신을 차렸는지..
지난 4월 하순쯤의 버전 90대 최신 업데이트를 받고 나니, 한글 조합 중에 딴 데를 클릭했을 때 자기 혼자 조합이 덧나는 등의 잡다한 오동작이 싹 없어졌다.
그래서 이제는 내 입력기에서 기본적으로 제공하던 보정 옵션은 "반대로 꺼 줘야" 조합이 사라지는 오동작이 발생하지 않겠다.

지난 9.x 대 후반부터 거의 2년 동안 크롬과 내 입력기와의 악연이 계속돼 왔다.
물론 내 입력기도 마소 기본 IME하고는 다르게 동작하는 게 있긴 했겠지만.. 그래도 내 입력기에 대해서도 지금까지 그렇게 동작한 특이한 프로그램은 역사상 크롬(크로뮴 엔진)밖에 없었다.

IME/TSF 담당 개발자가 수시로 교체되기라도 했는지.. 크롬은 혼자서 여기저기서 갖~가지 자잘하고 기괴한 오동작들을 일으키면서 날 귀찮게 해 왔다.
한때는(1년 전쯤 버전??) 누가 언제 소스의 어디를 건드렸는지, 메트로 앱이 아닌데도 메트로 앱이라고 IME에게 거짓 보고를 하기도 하고, TSF를 제대로 지원하지 않는데 지원한다고 거짓 보고까지 했었다. (지금은 다 고쳐짐)

그럼에도 불구하고 크롬은 날개셋과는 비교가 되지 않는, 그야말로 전세계 전지구 넘사벽급 메이저 프로그램이라는 게 문제.. 내 프로그램이 수동 보정으로 크롬의 동작에 맞춰 주는 수밖에 없었다.
그랬는데 드디어 크롬 쪽에서 문제를 해결한 것으로 보인다.

심지어는 지난 3~4월 사이엔 한글 조합을 종료하면 이전에 입력했던 글자들이 쭈루룩 삽입되는 오동작도 가끔 발생한다고 본인에게 버그 신고를 하신 분이 있었다.
이걸 본인도 잠깐 확인하긴 했다. 하지만 정확한 재연 경로를 파악하지 못했으며, 특히 업데이트를 받은 뒤부터는 그 문제를 다시는 재연하지 못하고 있다. 그래서 이건 일단 '공소권 없음'으로 사건을 내사 종결하고자 한다. 혹시 크롬 최신 버전 + 날개셋 10.2에서 저 문제를 또 재연 가능하신 분은 알려 주시면 좋겠다.

이로써.. 혼자서 독보적인 수동 보정 옵션을 필요로 하는 특이한 프로그램의 끝판왕으로는 사실상 Windows Terminal밖에 남지 않았다. 얘는 버전업도 하지 않는지, 오동작 현상을 처음으로 확인했던 1년 전이나 지금이나 변함없다.

수동 보정 옵션이 갈수록 내용이 적어지고 궁극적으로는 필요 없어지는 날이 왔으면 좋겠다.
그럼에도 불구하고 이번 버전에서는 수동 보정 UI를 이렇게 쇄신했다. 증상, 조건, 주 적용 대상을 일목요연하게 나열하고, 보정 대상인 이상 동작을 심지어 움짤로도 표시하게 했다.

2. 확대 배율(DPI)이 서로 다르게 지정된 다중 모니터 환경에 대한 지원

결론부터 말하자면.. 날개셋 외부 모듈에서 제어판을 꺼냈는데 이 창을 DPI가 다르게 설정된 모니터로 옮겼을 때 각종 컨트롤들 배치가 엉망이 되는 문제를 "일단은" 해결했다. 알고 보니 이건 Windows 10의 대략 2017~18년도 버전 때부터 존재해 온 문제였다.

옛날에 컴퓨터 모니터의 해상도가 낮던 시절에는 확대 배율이라는 건 거의 건드릴 일이 없었으며, 그냥 시각 장애인을 위한 잉여 옵션에 지나지 않았다. 이걸 바꾸려면 운영체제 재부팅/재로그인도 해야 했다.
그랬는데 2000년대 이후로는 이게 재부팅 없이 간편하게 설정 가능한 옵션으로 바뀌었으며, 심지어 모니터별로 서로 다르게 지정도 할 수 있게 됐다. 응용 프로그램에 요구되는 준비 수준도 점점 더 높아졌다.

• (1) 가변 DPI 자체를 지원할 것: 이를 지원하지 않는 프로그램은 100% 외의 배율에서는 창 크기가 기계적으로 확대되어 뿌연 저화질로 표시된다.
  
• (2) 프로그램 실행 중에 DPI 설정이 바뀌는 것을 유동적으로 지원할 것: 이를 지원하지 않으면 DPI 설정 변경 뒤부터는 역시 보정 샌드박스가 발동되어 뿌연 저화질크리.
  
• (3) 이 모니터에 있던 창을 저 창으로 옮김으로써 DPI 설정이 바뀌는 것을 유동적으로 지원할 것(창 크기 변경까지 포함!!). 아예 한 프로그램 안에서 윈도우별로 DPI 설정을 따로 관리할 것.

그런데 날개셋 한글 입력기는 주요 UI에서 16 아니면 24픽셀로 크기가 고정된 비트맵 글꼴을 사용한다. 둘 중 하나를 고른 뒤에는 다른 걸로 변경이 전혀 불가능은 아니지만 좀 난감한 형태이다.

그리고 이것보다 더 큰 문제로.. 날개셋 제어판은 창 크기를 사용자가 유동적으로 조절 가능하며 대화상자 안에 또 대화상자가 들어있는 꽤 복잡 정교한 물건이다. 다른 프로그램들은 도대체 어떻게 동작하는지 모르겠지만, 이런 데서 화면 DPI가 바뀔 때마다 내부적인 수치 계산을 정확하게 다시 해 주는 것, 그리고 운영체제가 대화상자에 대해서 내부 컨트롤들을 바뀐 크기와 위치대로 재배치하는 것이 영 정확하게 연계해서 동작하지 않았다.

이 두 가지 난관 때문에 날개셋 편집기 등의 프로그램들은 가변 DPI를 어쩔 수 없이 최소한의 기본인 (1) 수준만 지원하고 있다.
허나, 날개셋 외부 모듈은 메모장, 크롬 등 가변 DPI를 (3) 수준까지 다 지원하는 프로그램에서도 동작해야 하는데.. 대화상자 창 크기가 바뀌었을 때 자체적으로 컨트롤을 재배치하는 기능과 운영체제가 DPI 변화로 인해 컨트롤을 재배치하는 기능이 충돌해서 정말 굉장히 이상한 오동작이 발생하고 있었다.

둘을 조화를 이루는 방법을 아직까지는 못 찾았다. 그냥 운영체제의 기능을 꺼 버리고, 어느 모니터에서나 가변 DPI를 고려하지 않고 동일한 픽셀 크기로 대화상자가 표시되게 함으로써 오동작을 회피했다. (3)은 이제 어떤 경우에도 뿌연 저화질 대화상자가 표시되지 않는 모드이기 때문에 이것 말고 다른 선택의 여지가 없다.

3. 나머지 자잘한 개선 사항

(1) 날개셋 한글 입력기에는 "지정된 데이터에 들어있는 한글"만 입력 가능하게 하는 제약 기능이 있는데.. 그 데이터는 후보 변환 데이터와 마찬가지로 직접 입력해서 내장시킬 수도 있고, 외부의 텍스트 파일을 지정할 수도 있다.
그런데, 텍스트 파일을 지정하고 나면 그 파일의 내용도 설정 대화상자에서 곧장 표시되어서 확인 가능하게 했다. 아래 스크린샷을 참고할 것.

(2) "부수로 한자 입력" 도구가 호환용 한자는 크기를 약간 줄여서 표시하게 했다. 호환용 한자는 대부분 검정색 상용 한자에 있지만, 아주 드물게 그렇지 않은 것도 있다.
그리고 특정 부수에 속하는 한자들이 모두 표시된 경우, BMP 한자 한정으로 이 한자가 부수를 제외한 획수가 몇 획인지도 툴팁에 같이 나오게 했다.

(3) 제어판의 시스템 계층에 있는 "... 자동으로 띄울 입력 도구" 목록은 체크를 하다 보면 선택 막대가 자꾸 진하게 덧칠되는 문제가 있었다. 이건 엄밀히 말하면 오로지 Windows 10만의 버그이다. 그 전의 XP, 7, 8.1 등 그 어떤 버전에서도 이런 현상이 없었다.

그랬는데.. Windows 10에서도 이 현상을 회피하는 방법을 우여곡절 끝에 찾아내서 그걸 내 프로그램에다가 적용했다.
허나.. 그 방법은 이젠 공용 컨트롤 6이 적용되지 않은 옛날 레거시 프로그램에서는 또 다른 화면 잔상 부작용을 일으키는지라, -_-;; 이건 조건부로 제한적으로 적용해야 했다. 살다 살다 이런 지저분한 버그는 참 오랜만에 다시 본다. -_-

(4) 날개셋 편집기에서 따옴표(") 다음에 한 줄의 길이보다 더 긴 영어 알파벳을 늘어놓으면.. 단어 전체가 다음 줄로 밀려나고 원래 줄에는 따옴표 하나만 달랑 남던..-_- 이상한 문단 정렬 방식을 개선했다.
15년도 더 전, 2.x, 3.x 버전 시절부터 이렇게 동작했던 것을 바로잡았다.

Posted by 사무엘

날개셋 한글 입력기가 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 사무엘